- 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.)
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
