[FFmpeg-devel] [PATCH] AVPacket.display_duration

[Uoti Urpala]

On Mon, 2008-09-08 at 21:50 +0200, Michael Niedermayer wrote:
> On Fri, Sep 05, 2008 at 05:35:13PM +0200, Aurelien Jacobs wrote:
> > For some subtitles track, each AVPacket must carry the display duration
> > of the contained subtitle.
> > The attached patch adds a dedicated AVPacket.display_duration field.
> 
> Iam not against this, but i would like to understand better for which cases
> it is needed.
> 
> plain UTF-8 and ASCII ?
> If so does mov, avi, asf, ... support plain UTF-8 and ASCII ?
> if yes how do they know the display_duration ?

In http://roundup.mplayerhq.hu/roundup/ffmpeg/issue588 you compare the
subtitle situation to video and do not see why it would need something
different. However the subtitle formats that exist in practice DO need
something extra. A video frame implicitly lasts until the next frame
overwrites it, but no such implicit duration information exists in all
subtitle formats. You need to explicitly specify both the start time and
duration (or stop time) of the subtitle. A "natural" representation for
such a format requires having more than just a start time at the
container level.

You could make a subtitle format which behaves like video and has a new
packet at each point where anything changes (such as a subtitle
disappearing). But unlike video all the existing subtitle formats are
not like that. FFmpeg could try to convert each format to such a variant
for internal representation, but converting back would be nontrivial.

The version you propose in the above URL, moving the timing information
inside the codec packets, is not really analogous to how video handles
it as it uses explicit time values instead of the point where the packet
occurs. You wouldn't remove demuxer-level pts fields and use codec-level
timing information because of a container that doesn't support
container-level timestamps. Timing values really belong at the demuxer
level. The way Aurelien tried to do such a change in MPlayer after the
discussion in that URL clearly went wrong: the timing information inside
the codec-specific data became authoritative over the information in the
demuxer packet. I suppose the same would happen in FFmpeg if you
currently tried to mux SSA into any container, but I'm not sure whether
that's considered to be supported.

I think the best choice for FFmpeg is to use an internal storage format
that keeps all the timing information in demuxer packet fields like
display_duration when possible. Not all containers can represent such
timing information directly at the container level, so they have to use
hacks like moving it inside the codec packets or a less hacky but more
complicated system like adding an explicit end packet for each subtitle
(note that SSA would probably have problems with this, IIRC you need to
know the duration immediately for some effects). So you couldn't mux
such a format unchanged into all containers. However it's the format
easiest to convert from, and it's not yet known what kind of workaround
(if any) would be the standard for each container. It's also a format
that keeps sane semantics at the muxing level; moving timing information
inside codec packets with some codec-specific coding will cause problems
if you want to do even simple timing changes during remuxing.