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.r...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
