forums.ps2dev.org

Confirmed that no need to modify the mencoder/mplayer source code, just need to recompile the source with the patched x264. But it won't output the .txt containing the video info if going through the mencoder route. I created the following script to perform cropping, resizing, and also fps detection...

I've just confirmed that by modifying the /libavcodec/x264.c in mencoder to set the default values that jonny sets in the common.c of x264 (b_aud, b_pictiming, and i_level_idc), I'm able to run the mencoder to encode x264 directly. Apparently some libraries were not loaded correctly when I tried las...

I've tried encoding with encoder with the x264 function enabled, and it does provide me with the right number of frames. But I think I'm missing some important changes in mencoder/x264, since the resultant pmp file is not playable from the PSP... (invalid format error). I would be very interested to...

mystic_memories, have you tried with no -fps ${RATE}/${SCALE} option? In your pmp avc muxer output you've scale: 1, rate: 20 which is exactly 20 fps. Maybe there are rounding problems...? Doesn't it work fine if you do not specify frames-per-second explicitly? The -fps is derived from the comments ...

@ cooleyes

Could you possibly post the diff for the changes you made to mencoder and/or x264? Seems like mencoder is the only way to get it working properly on Linux. Your help would be greatly appreciated. Thanks.

@cooleyes

Did you actually have to modify the mencoder source or did you simply use the patched x264 and recompiled the mencoder?

@jonny Thanks for the tip. My findings are as follows: 1) Original Video (min:sec): 46:46 2) Extracted MP3: 46:46 3) {infile}.264: Going from the 55795 which I think is the number of frames. I get 46:30 which is about 16 seconds difference there. A snipplet of the output from the muxer is as follows...

I'm current using the following call to perform the encoding, and I'm experiencing some sync issues. It's not as bad with small flicks, but as the video gets bigger (~25mins), it goes to upwards of 43 seconds. From reading the thread, I have a feeling it could be solved by the "harddup" op...

Thanks for the code, it looks good (at rendering time).. I'll try it out tonight after it's finished rendering. (slow PC...) The following patch will fill .264.txt file when using yuv4mpeg input. I'm not completely sure if that is the correct code (as original one uses some values from AVI header). ...

Oh? Cool, looking forward to it. Thanks!

606u wrote:mystic_memories, jonny's patch works for avi/avs input only, hence you get an empty text file. I'll post a patch tonight.

It was a good tutorial, I got it converting in no time with this. But one problem, for some reason the txt file generated by the x264 doesn't contain anything (it's always 0 bytes). Shouldn't it contain info on the video or something? I already applied the two patches before compiling x264 with patc...

Has this bug been re-introduce recently? When I do a os.date("*t"), the hour doesn't seem to take my timezone into consideration. i.e. I get the GMT time rather than the time of my local timezone. I also tried os.date("!*t") as well, they both return the same result.