[MEncoder-users] MEncoder Creating "Snip-Its" of Audio, Video, and Subtitle files

[James Hastings-Trew]

On 13-06-12 10:04 AM, Christopher Hunt wrote:
>> Are you sure it still is? There are possibly issues in corner-cases,
>> but I think that -of lavf should actually be working (though just making
>> all steps together work in FFmpeg would be the better solution).
> ** MUXER_LAVF
> *****************************************************************
>     REMEMBER: MEncoder's libavformat muxing is presently broken and can
> generate
>     INCORRECT files in the presence of B-frames. Moreover, due to bugs
> MPlayer
>     will play these INCORRECT files as if nothing were wrong!
> **************************************************************************************
>
> This message still exists in the muxer_lavf.c code as of a February svn
> check out of MPlayer and the file produced by using the -of lavf flag is
> not playable in QuickTime however it is (as the message suggests) playable
> in MPlayer, but with the limited testing that I did with that option the
> output files were not even playable in VLC.
>
> I would do all the steps in ffmpeg if I hadn't spent development time in
> MPlayer adding further subtitle formats to subreader.c, had I noticed that
> passing a sub file with -subfile (rather than -sub) directed the decoding
> to the chosen demuxer (in my case ffmpeg) I would have added those formats
> to ffmpeg and been able to "burn in" those subs at that level and not need
> to use MEncoder however as hindsight is 20-20 and duplicating the code into
> ffmpeg is unadvisable at this moment I'm looking to see if it's feasible to
> do this through MEncoder.
>
>> I am not really sure that seeking in the audio file together with copy
>> will result in a valid file.
> In my test cases the audio files only contained lpcm data so the issue of
> decoding the audio from a valid starting point was not a concern but I
> agree that in compressed audio that would be a concern (or have I missed
> something).
Back when I still used mencoder, i used it to produce a raw h.264 
stream, and mux that with a separately encoded audio stream using mp4box 
because of that bug. Kind of a pain but the process did work, and as 
long as you don't drop frames in the process, the audio doesn't go out 
of sync. Since these are such short clips and you'd probably rather do 
your encode in one shot, I believe the best option is to not use bframes 
at all in the encode - it's not really going to make that much of a 
difference to the file size.