[FFmpeg-devel] TS muxer issues -- some progress

[Alexandre Ferrieux]

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) ?

-Alex