[Live-devel] TS file with high VBR

[Christophe Lemoine]

Sorry.... my mistake: the commercial muxer is adding null packets to 
create a CBR transport stream...... it manages to keep the file not too 
big by maybe having a better H264 compression.

Christophe

On 01/11/2011 10:22 AM, Christophe Lemoine wrote:
> Hi Ross,
>
> Thanks a lot for your answer: that would be great to have better 
> support for high VBR TS file.
> I get your point regarding streaming of live encoder. Maybe the code 
> could be different depending on the stream source.
>
> While testing different muxers, I'm getting confused by some 
> results..... I use tsreport to get the Transport Stream bit rate.
>       - ffmpeg gives files with very high VBR. Basically, it justs add 
> the PCR based on the video frame DTS when VBR is requested. Here is an 
> example report.
>  .. PCR     17010342 Mean byterate 5114089 byterate 5113793
>  .. PCR     19440250 Mean byterate 5114313 byterate 5115882
>  .. PCR     21870158 Mean byterate 4739385 byterate 1740110
>  .. PCR     24300066 Mean byterate 4265636 byterate    2088
>  .. PCR     26730960 Mean byterate 3878453 byterate    8352
>
>       - TSMuxer gives similar results.
>
>       - Some (commercial muxers), while still generating VBR TS file 
> (no null packets to make it CBR), have a CBR when looking at the PCR 
> time and number of packets between PCRs (time between packets remains 
> constant). I still trying to understand the details, but my guess is 
> that the number of packets between 2 I frames should not vary by a 
> lot. Then, it might be possible to play with the delay between the PCR 
> and the frames DTS to make the stream looks like CBR. The player 
> buffer will then have to cope with it. But, obviously, the algorithm 
> in the muxer must be quite complex to determine the proper PCRs, 
> without getting the difference between PCR  and DTS drifting...
> Example report (same source video file as with ffmpeg, result ts file 
> size very similar)
>  .. PCR      5013968 Mean byterate 1313100 byterate 1313100
>  .. PCR      6015175 Mean byterate 1313099 byterate 1313099
>  .. PCR      7016381 Mean byterate 1313100 byterate 1313100
>  .. PCR      8017587 Mean byterate 1313100 byterate 1313100
>  .. PCR      9018794 Mean byterate 1313099 byterate 1313099
>  .. PCR     10020000 Mean byterate 1313100 byterate 1313100
>  .. PCR     11021206 Mean byterate 1313100 byterate 1313100
>  .. PCR     12022413 Mean byterate 1313099 byterate 1313099
>
>
> BR
> Christophe
>
> On 01/10/2011 04:44 PM, Ross Finlayson wrote:
>>> Maybe I'm wrong, but, by reading the code of the media server, it 
>>> looks likes it relies on an average BR to determine when to send the 
>>> packets (based on past packets).
>>
>> Yes.  (This is done in "MPEG2TransportStreamFramer".)
>>
>>
>>>  The PCR is used to compute this average, but not to determine when 
>>> to actually send the packets. (I might be totally wrong here as I 
>>> must admit that the code is quite complex and I probably have missed 
>>> something.....).
>>> Now, if I'm not totally wrong, would there be a way to either:
>>>        - Rely on PCR to determine when to send packets (something 
>>> like: get the next PCR, determine BR from first packet till this PCR 
>>> packet, send packets in a way where the packet containing the PCR is 
>>> sent on time).
>>
>> The "MPEG2TransportStreamFramer" code is intended to work when 
>> streaming arbitrary Transport Stream data - including Transport 
>> Stream data that might come 'live' from an encoder.  It therefore has 
>> no knowledge of 'the next PCR' (because it doesn't look ahead in 
>> time).  However...
>>
>>
>>>        - Or: use the index file to store current frame BR (so use 
>>> the actual BR of a frame instead of an average based on past frames)
>>
>> Yes, for Transport Stream files for which we have pre-computed an 
>> index file, we do - in principle - have enough 'future' information 
>> (using PCR values) from which we could compute a more accurate 
>> 'duration' for each outgoing Transport Stream packet.  In the past I 
>> had considered modifying "MPEG2TransportStreamFramer" to use this 
>> information, but didn't (because such a solution would work only for 
>> Transport Stream files for which we have index files, whereas the 
>> existing code works for any Transport Stream data).
>>
>> However, because - as you noted - excessively VBR streams are more 
>> likely to be a problem with H.264 Transport Streams, I think I'll 
>> take another look at this, to see if we can use the index file - when 
>> present - to generate more accurate Transport Stream 'durations'.
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel