[Live-devel] TS file with high VBR

[Christophe Lemoine]

Hi Ross,

Thanks for spending time on this issue. I understand that this is a 
major change and it have to be considered carefully.....
I could not find a good tuning that works with very high VBR TS 
files..... So I end up using CBR files for now. Not only this creates 
very big files (generating a CBR file is not easy and I have to keep a 
very high margin to make sure that all frames fits), but it also 
increases the network usage....

I was thinking of writing a new media subsession and a new framer that 
would read the file ahead (it would work only for file streaming), but I 
found it quite hard to just extend existing classes 
(MPEG2TransportStreamFramer, MPEG2TransportFileServerMediaSubsession and 
DynamicRTSPServer) as many methods are private instead of protected: is 
this intentional ?

BR
Christophe

On 01/29/2011 02:43 AM, Ross Finlayson wrote:
>>>        - 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'.
>
> As promised, I looked into whether it would be feasible to do this 
> (use the index file to compute more accurate 'durations' for each 
> outgoing RTP packet, when streaming an indexed Transport Stream file. 
> (When streaming from a non-indexed file, or a live stream, the 
> existing code would continue to be used.)  I came up with a solution 
> that would work, but decided not to check it in, because I'm not 
> convinced that it would be a good idea, for several reasons:
>     1/ My solution changes the format of the index file (to add a new 
> 'duration per transport packet' field).  Old index files would no 
> longer work, which means that everyone would have to reindex all of 
> their Transport Stream files.  (Also, index files would become about 
> 36% bigger.)
>     2/ While streaming a Transport Stream file, the server would also 
> need to read the whole of its corresponding index file, leading to an 
> almost 10% overhead in file system reads.
>     3/ Although we would now know more accurate 'durations' for each 
> outgoing packet, we would still need to adjust these using some 'fudge 
> factors' (tuning parameters), because otherwise we'd often end up 
> seeing 'buffer underflow' at the receivers (due to network jitter, for 
> example).  (So the new scheme would not eliminate the 'fudge factors' 
> present in the current scheme.)
>     4/ For highly VBR files, this new solution - by computing more 
> accurate 'durations' for each outgoing packet - would end up 
> generating an output network packet stream that's more bursty than the 
> current scheme (which works by computing a weighted average 
> duration).  This would potentially lead to more network congestion 
> (and possibly more packet loss).
>
> Therefore, my current thinking is that it's probably best to retain 
> the existing scheme, even though its tuning parameters ('fudge 
> factors') sometimes need to be tweaked in special circumstances.  (I 
> could potentially still be convinced otherwise, though.  But right now 
> I don't plan to change the existing "MPEG2TransportStreamFramer" 
> implementation.)