--- On Tue, 2/11/10, Tomas Härdin <[email protected]> wrote:
> From: Tomas Härdin <[email protected]> > Subject: Re: [libav-user] mpeg-ts PCR marks not correct > To: "Libav* user questions and discussions" <[email protected]> > Date: Tuesday, 2 November, 2010, 11:39 > On Tue, 2010-11-02 at 11:47 +0100, > Ján Kolár wrote: > > 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 > > Interesting.. However, settings mux_rate that high is > probably not > desirable since the overhead of that stream is basically > 1-8/33 = 76%. > > What you're after regarding smoothing bitrate is the VBV > buffer, whose > size can be set by -bufsize (aka rc_buffer_size). AFAICT it > should be > around max_delay*bit_rate/1000000 (bit_rate times max_delay > in seconds). > If you set it too high the burstiness of the encoder will > cause that > "dts < pcr" error (if I understand correctly). > > My use case was encoding H.264 at 3 Mbps and muxing it CBR > at 3.5 Mbps. > For that -bufsize 2000000 was sufficient, compared to > max_delay = 0.7 > (ffmpeg's default) * 300000 = 2100000. With audio squeezed > in there the > CBR overhead was acceptable (5-10%). > > I would suggest also trying larger values for max_delay. As > you can tell > from the above, I'm one order of magnitude above you. Try > ffmpeg's > default - 700000 in microseconds (actually, in > AV_TIME_BASE). > > In short, try something like the following and let me know > how that > works: > > bit_rate = 8000000 > mux_rate = 9000000 > rc_buffer_size = 5000000 > max_delay = 700000 > > /Tomas > Any news on when your modifications will be added to the tree, as i am having problems due the PCR being out of spec on current MPEG-TS streams. joolz _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
