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
