[MPlayer-dev-eng] Streaming output driver (was: -vobsub support for mencoder)

[Nicolas George]

Le tridi 23 pluviôse, an CCXVIII, Uoti Urpala a écrit :
> 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.

Custom ad-hoc formats are always the easiest way, but they can not be
handled with standard tools, and are therefore much less practical. I would
advise to use a format at the very least supported by lavf. Which raises the
question:

What format to use?

I may start to implement something in a near future, but I am not very
comfortable with the choice of the format.

Do you think NUT would be a good choice?

I have some hesitations about the implementation too: using an existing
library (lavf, or maybe libnut) requires less code, but adds a dependency,
and maybe annoying fail cases (for non-monotone timestamps for example).
Implementing a basic muxer with just the required features is probably a
better idea. That is what vo_yuv4mpeg does.

> 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.

Audio can indeed be processed separately, and therefore support for muxed
audio and video is less urgent. But processing the audio separately makes it
almost impossible to do everything in a single pipe sequence, so it would be
more practical to have both in the same stream.

At the very least, the selected streaming format should be extensible enough
to allow the addition of an audio stream at a later time.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100213/9c65ee0f/attachment.pgp>