Dňa 28. 10. 2010 11:30, Ján Kolár wrote / napísal(a):
Dňa 28. 10. 2010 11:12, Tomas Härdin wrote / napísal(a):
On Thu, 2010-10-28 at 10:52 +0200, Ján Kolár wrote:
Dňa 26. 10. 2010 16:32, Tomas Härdin wrote / napísal(a):
On Tue, 2010-10-26 at 16:20 +0200, Ján Kolár wrote:
When generating mpeg-ts stream using ffmpeg, I have observed, that
PCR
marks are spaced too far apart one from another. Typical PCR
period is
about 60 - 70 ms which is a way too much. Another problem is that
this
value considerable varies at some moments. Especially on dynamic
scenes
I have seen extraordinarily big PCR periods ranging to several
hundreds
of milliseconds. Because of this I have disordered timing in output
module which sends created stream to network QAM modulator
(http://www.dektec.com/Products/IP/DTE-3114/). My output buffer can
accomodate max. 250 ms block of data. I have suspicion that this is a
ffmpeg bug, but not sure. Has this happened to someone?
Jan
I posted a couple of patches related to PCR generation a few weeks
ago.
They have not been OK'd to commit yet though. Do try them out since
feedback on them would be good.
The following thread deals with PCR jitter and accuracy improvement:
https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-September/097856.html
The latest version of that patch is at:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-October/098479.html
This thread deals with forcing PCR to be written more often, at the
cost
of some overhead. It is probably closer to what you want:
https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-October/098484.html
/Tomas
I applied both of your patches. Its awesome that PCR period is now
fixed
to 20 ms. PCR accuracy is not critical in my case so maybe this part of
first patch was not essential. But PCR drift could be problem regarding
long-term stability. I tested my program whole night, all was OK when I
arrived to work this morning. From my point of view both patches are
functioning.
That sounds awesome. So far I've been waiting for word from other people
with broadcast equipment to which I've sent some sample files. This
sounds very promising.
Only problem I encountered is warning message dts< pcr.
The effect of this was non-smoothness of video sequence. But that
can be
avoided by setting AVFormatContext::max_delay to about 50000 (50000
microseconds = 50 milliseconds).
Jan
Yes, I had a similar problem with my system until I noticed ffmpeg.c
sets max_delay to 0.7 by default. Its default value is zero, which is
too low.
/Tomas
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Regarding big PCR periods mentioned in my first email. After analyzing
log messages I concluded that real PCR periods were not so big - most
probably they moved in region from 50 to 100 ms. Apparent big PCR
periods like 200 - 300 ms were brought by long coding time of dynamic
scenes. When coding restrictions are set too tight (max_bit_rate,
min_bit_rate, rc_buffer_size) coding time of one frame can be > 100 ms
for PAL resolution. This is because ffmpeg is trying to code the same
scene multiple times to keep bit rate accurately.
Jan
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
My program successfully passed through firewalk when streaming live
hockey match. But as i said in my previous message its a bit of alchemy
to correctly set all of the encoding parameters like max_bit_rate,
min_bit_rate, rc_buffer_size and max_delay. This is not concern when
saving to file for offline viewing. I used folowing values of them:
bit_rate = 8,000,000 (8 mbps)
mux_rate = 33,000,000 (33 mbps). Another option would be to set this
value to 1 which means VBR (variable bit rate mode) but some decoders
like our dektec can correctly work only with CBR stream. When setting
CBR mode mux_rate should be at least twice bit_rate to smooth bit_rate
rc_buffer_coeff = 0.3
max_rate_coeff = 2.0
min_rate_coeff = 0.05
max_delay = 50000
Jan
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
