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 not changing a lot (P and B
frames are very small). When muxing in CBR, I get much smoother
streaming, but, obviously, the file becomes huge and the network usage
higher (in CBR I might also be loosing some packets as I sometime have
decoding errors in the client).
The muxing itself should be ok (PCR is based on frame DTS - a fixed
delay. This is the way ffmpeg mux for VBR. So, I think that if packets
are sent on time, the player should get them before it must decode it).
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). 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).
- 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)
Thanks for your help
Christophe
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
