[Live-devel] TS file with high VBR

[Christophe Lemoine]

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'.