[FFmpeg-devel] mpegts_write_header(), the buffering and thus reordering of audio samples.

[Will Korbe]

On Mon, Oct 31, 2011 at 7:41 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Oct 31, 2011 at 06:24:07PM -0700, Will Korbe wrote:
>> Hello,
>>
>> I hopefully have a minor question about the
>> libavformat/mpegtssec.c:mpegts_write_header() implementation. My hours
>> of online searching and specification reading for the answer has been
>> unsuccessful.
>>
>> I see there is an efficiency built in to bundle multiple audio samples
>> into one PES packet and was wondering if someone could point out a
>> paragraph from the MPEG2 specification which indicates the reordering
>> of TS Packets this causes is okay? I have a video with many 41 byte
>> audio samples at the start, and this seems to push the first audio
>> samples 5 seconds into the output. At this point, the PTS and DTS for
>> the audio samples are beyond the last PCR value by 5 seconds. The
>> video plays fine in QuickTime, the audio and video are precisely in
>> sync, so I assume QuickTime has logic to buffer the video frames until
>> seeming the first audio sample to account for this, but I wonder if
>> most MPEG2TS players handle this the same way. If this is spelled out
>> in the specification, I would sure feel more comfortable with it.
>>
>> Any information would be useful.
>
> I dont remember a tight limit on the PCR-DTS distance in the spec but
> then i dont remember the spec very well ...
> but having this large is bad because this means a long startup delay.
> So 5 seconds is IMHO not appropriate by default.
> Of course that delay would only affect actual broadcast and not playing
> from a local file with a modern player.
> the user parameter max_delay should be able to limit this, if not
> a bugreport & patch are welcome
>
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>

Hi Michael,

Thank you for your response. From what I can tell, max_delay does not
limit the amount of audio sample buffering, rather, it is a macro,
DEFAULT_PES_PAYLOAD_SIZE (2930 bytes). In my test case,
AVFormatContext::max_delay is set to 50000 (50 ms). My sample video is
actually a movie trailer with close to 5 seconds of silence before the
audio sample byte sizes become substantial, after that point, the
audio samples are large enough that the PTS/DTS values become just 500
ms behind the last PCR. Given this, it seems when there are
multi-second periods of silence, the PTS/DTS of an audio sample has
the potential to become multi-seconds behind the last PCR in the TS
Packet Stream. As you mentioned, this may be acceptable with regards
to the specification and/or current playback implementations, however,
to attempt to handle more cases, perhaps the buffering of audio
samples should be limited by max_delay as you suggest, that would seem
to make it more inline with the mpeg2 timing model, but I'm not and
expert in this area. I plan to investigate further to see if a BUG
report is warranted.

Thank you,
Will