[FFmpeg-devel] [PATCH V1 0/2] Use avctx->framerate first for frame rate setting

[mypopy at gmail.com]

On Tue, May 7, 2019 at 9:54 AM mypopy at gmail.com <mypopy at gmail.com> wrote:
>
> On Sun, May 5, 2019 at 11:23 AM mypopy at gmail.com <mypopy at gmail.com> wrote:
> >
> > On Sun, May 5, 2019 at 9:31 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > >
> > > Am So., 5. Mai 2019 um 03:23 Uhr schrieb mypopy at gmail.com <mypopy at gmail.com>:
> > > >
> > > > On Sun, Apr 28, 2019 at 7:02 PM mypopy at gmail.com <mypopy at gmail.com> wrote:
> > > > >
> > > > > On Sun, Apr 28, 2019 at 5:30 PM Gyan <ffmpeg at gyani.pro> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 28-04-2019 07:19 AM, mypopy at gmail.com wrote:
> > > > > > > On Sat, Apr 27, 2019 at 8:22 PM Gyan <ffmpeg at gyani.pro> wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >> On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote:
> > > > > > >>> 2019-04-27 13:17 GMT+02:00, Jun Zhao <mypopydev at 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 ？