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.)
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
