On Tue, May 7, 2019 at 9:54 AM myp...@gmail.com <myp...@gmail.com> wrote: > > On Sun, May 5, 2019 at 11:23 AM myp...@gmail.com <myp...@gmail.com> wrote: > > > > On Sun, May 5, 2019 at 9:31 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > > > > > Am So., 5. Mai 2019 um 03:23 Uhr schrieb myp...@gmail.com > > > <myp...@gmail.com>: > > > > > > > > On Sun, Apr 28, 2019 at 7:02 PM myp...@gmail.com <myp...@gmail.com> > > > > wrote: > > > > > > > > > > On Sun, Apr 28, 2019 at 5:30 PM Gyan <ffm...@gyani.pro> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 28-04-2019 07:19 AM, myp...@gmail.com wrote: > > > > > > > On Sat, Apr 27, 2019 at 8:22 PM Gyan <ffm...@gyani.pro> wrote: > > > > > > >> > > > > > > >> > > > > > > >> On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote: > > > > > > >>> 2019-04-27 13:17 GMT+02:00, Jun Zhao <mypopy...@gmail.com>: > > > > > > >>>> perfer avctx->framerate first than use avctx->time_base when > > > > > > >>>> setting the frame rate to encoder. 1/time_base is not the > > > > > > >>>> average frame rate if the frame rate is not constant. > > > > > > >>> But why would the average framerate be a good choice to set > > > > > > >>> the encoder timebase? > > > > > > >>> > > > > > > >> Also, note that x264/5 RC looks at the framerate. > > > > > > >> See > > > > > > >> https://code.videolan.org/videolan/x264/commit/c583687fab832ba7eaf8626048f05ad1f861a855 > > > > > > >> > > > > > > >> I can generate a difference with x264 by setting -enc_time_base > > > > > > >> to > > > > > > >> different values (with vsync vfr). > > > > > > >> Maybe check that this change does not lead to a significant > > > > > > >> change in > > > > > > >> output. Although I think this would be still an improvement for > > > > > > >> those > > > > > > >> cases where r_frame_rate >> avg_frame_rate > > > > > > >> > > > > > > >> Gyan > > > > > > > Yes, framerate and time_base is not close correlation in vfr case, > > > > > > > e,g, I can setting the framerate = 60fps, but time_base = 1/1000 > > > > > > > s, > > > > > > > then setting pts like: > > > > > > > > > > > > > > time_base = 1/1000 s = 1 millisecond > > > > > > > framerate = 60 fps per second > > > > > > > PTS 0----16----33----50----66----83----100 ... > > > > > > > > > > > > > > PTS delta 16 17 17 16 17 17 ... > > > > > > > > > > > > > > we will get 16ms * 20 frames + 17 ms * 40 frames = 1000ms > > > > > > > > > > > > I'm aware of the relationship between TB and PTS. My point is > > > > > > x264's RC > > > > > > adjusts its quantizer based on fps. You're changing that value so > > > > > > the > > > > > > output bitrate will change for the same input with the same encoder > > > > > > config if (avg_frame_rate) != (ticks * 1/TB). > > > > > > > > > > > > Gyan > > > > > in fact，this is the purpose of this patch, we used FFmpeg API to > > > > > setting the time_base/pts/framerate like above to tuning the PTS. > > > > > > > > Any other comments? > > > > > > Please explain why this patch is a good idea / what gets fixed. > > > > > In this patch, we can setting time_base/framerate without tight > > coupling from encoding API level, it's need for VFR case like above > > sample > > More comments for this patchset > > 1. This patchset used to when use FFmpeg codec API to setting > the avctx->time_base/framerate with PTS like following example: > > setting the framerate = 60fps, but time_base = 1/1000s = 1 millisecond, > and PTS like: > > PTS 0----16----33----50----66----83----100 ... > PTS delta 16 17 17 16 17 17 ... > > get 16ms * 20 frames + 17 ms * 40 frames = 1000ms in one second. > > 2. For ffmpeg command tools, it's will support "enc_time_base" and "r" > options both for encoder > > In fact, time_base/framerate is not tightly coupled like current > libx264 wrapper. > Ping ？ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
