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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
