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 ?
Usually not; I just don't like declaring variables as "protected:"
unless I
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
- 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 w
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: th
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
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
Hi,
I'm still trying to properly encode a TS file containing H264 video (HD)
in order to be able to stream it.
The file has a quite high VBR as B and P frames are very often much much
smaller than I frames (quite expected with H264). I then get lots of
jittering, especially when the image is
