[FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

Michael Niedermayer michael at niedermayer.cc
Fri Mar 3 01:02:18 EET 2017


On Thu, Mar 02, 2017 at 03:35:08PM +0100, Tobias Rapp wrote:
> On 02.03.2017 03:27, Michael Niedermayer wrote:
> >On Mon, Feb 27, 2017 at 09:50:31AM +0100, Tobias Rapp wrote:
> >>On 26.02.2017 16:09, Michael Niedermayer wrote:
> >>>On Mon, Feb 20, 2017 at 04:05:00PM +0100, Tobias Rapp wrote:
> >>>>On 20.02.2017 15:09, Mark Thompson wrote:
> >>>>>On 06/02/17 12:33, Tobias Rapp wrote:
> >>>>>>Sets framerate field in output codec context if explicitly specified on
> >>>>>>the command-line.
> >>>>>>
> >>>>>>Signed-off-by: Tobias Rapp <t.rapp at noa-archive.com>
> >>>>>>---
> >>>>>>ffmpeg_opt.c | 2 ++
> >>>>>>1 file changed, 2 insertions(+)
> >>>>>>
> >>>>>>diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> >>>>>>index 6a47d32..3b532da 100644
> >>>>>>--- a/ffmpeg_opt.c
> >>>>>>+++ b/ffmpeg_opt.c
> >>>>>>@@ -1535,6 +1535,8 @@ static OutputStream *new_video_stream(OptionsContext *o, AVFormatContext *oc, in
> >>>>>>       av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n", frame_rate);
> >>>>>>       exit_program(1);
> >>>>>>   }
> >>>>>>+    if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
> >>>>>>+        video_enc->framerate = ost->frame_rate;
> >>>>>>   if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
> >>>>>>       av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce invalid output files\n");
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>Is there a reason not to always set this, rather than only when it is specified explicitly on the command line as you have?
> >>>>>
> >>>>>(Like <https://git.libav.org/?p=libav.git;a=commit;h=d10102d23c9467d4eb84f58e0cd12be284b982f6>, though that is after the current merge point and I don't know if it interacts with anything else.)
> >>>>
> >>>>I just tried to be extra cautious. Merging Libav commit
> >>>>d10102d23c9467d4eb84f58e0cd12be284b982f6 would provide a more
> >>>>general solution and might be preferred.
> >>>
> >>>that one would change fate results, are the changed results better or
> >>>worse ?
> >>
> >>I rebased unto current master and run fate with the attached change
> >>to ffmpeg.c applied but couldn't find any changed reference files.
> >>
> >
> >>Which fate tests had some changes and which platform did you check?
> >
> >there was a commit in origin/master that broke the tests, i realized
> >that after sending the mail but was too busy to reply immedeaty and
> >then forgot
> 
> No problem. So I consider my original patch 1/3 as dropped.
> 

> What is the best way to continue, assuming that the other two
> patches in the series are OK?

> 
> Shall I merge the single Libav commit d10102d2 followed by the other
> two patches? Or shall I wait until the general Libav merge-queue up
> to d10102d2 has been processed (~210 commits)? Or just wait for the
> merges affecting ffmpeg.c (~4 commits)?

waiting is generally bad for paralellism
if you need a patch, cherry pick it
    

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170303/568c5603/attachment.sig>


More information about the ffmpeg-devel mailing list