[MPlayer-dev-eng] [PATCH] -vobsub support for mencoder

[Uoti Urpala]

On Thu, 2010-02-11 at 13:50 +0100, Nicolas George wrote:
> Le tridi 23 pluviôse, an CCXVIII, Gianluigi Tiesi a écrit :
> > there is a way to pipe audio+video+subsorfriends from mplayer to ffmpeg
> > without reling on 1:1 timing?
> 
> As far as I know, no, there is not.
> 
> > yuv4mpeg is video only so how to mux with audio?
> 
> yuv4mpeg is not even video only: the output stream is reset when mplayer
> detects a framerate change, for example. A lot of NTSC content will be
> unusable.

Yes, at least a method for exporting video timestamps needs to be added
for the video output to be usable in any generality. A custom variant of
yuv4mpeg with timestamps would be trivial to implement but would require
adding support to reading applications (should again be trivial to do
but requires changing more programs); muxing to another container would
be a bit more work but make the results more generally usable. Writing a
separate timecode file such as understood by for example mkvmerge would
also be simple, but probably wouldn't work well if you want to use the
output immediately through a pipe. OTOH applying the correct timestamps
later _after_ encoding could work.

> I understood the original suggestion like this:
> 
> - Imitate -vo yuv4mpeg to implement -vo stream, which muxes the raw video
>   frames in a format more robust and complete than yuv4mpeg; maybe nut. At
>   the very least, it needs to support accurate timestamps and muxing with
>   audio.

I think it would work for many uses even without muxing audio in the
same file (though that would certainly be useful). In many cases either
the application used for further processing could read the audio track
directly from the original file, or a separate pcm track would be OK.
Though also for audio a container with timestamp support would be
useful.

> - Imitate -ao pcm:fast to implement -ao stream, which muxes the PCM samples
>   in the same stream as above.
> 
> - Use mplayer -vo stream:file=fifo -ao stream $input.

Yes overall this is pretty much what I meant, though as explained above
I think audio integration is more than the minimum usable functionality.