[FFmpeg-devel] TS muxer issues -- some progress
Thu Feb 19 14:41:41 CET 2009
M?ns Rullg?rd wrote:
>> tell me if the following description is correct for streaming TS to a
>> set-top-box over IP:
>> 1- assume some VBR source that ffmpeg can decode
>> 2- internal ffmpeg data structures hold PTS values
>> 3- these PTS values give target timings for playing at normal speed
>> 4- with -re, they keep this property even if the input is a flat file
>> on a fast, local hard drive.
>> 5a- the TS muxer could base its PCR on those internal PTSs
>> 5b- or, it could base its PCR on the local gettimeofday()
>> 5c- but today is bases it on written byte counts instead (!), *and* on
>> IP there is no byte-stuffing like would normally occur on a CBR link
>> like satellite.
>> 6- As a consequence, the receiving STB sees a PCR that is way too slow
>> and reports underflows.
>> TIA for any comments,
> Assuming a VBV-compliant elementary stream, the tricky part is
> determining the ideal transmission time of a given packet. The main
> constraint is, of course, that a frame must be transmitted in full
> before the PCR reaches the DTS of the frame. Additionally, a bit may
> not be transmitted before there is space for it in the receiver
> buffer. Within these constraints, there is still room for variations,
> and therein lies the difficulty.
Do you, or not, validate that 5c is currently the case in mpegtsenc.c ?
What about 5b : simply creating PCRs (and PTS/DTS) out of the real time
(since we are already consuming input at real speed with -re) ?
More information about the ffmpeg-devel