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