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