| Message ID | 0cc7464a-53cf-84f7-26b9-9ecd38b03d00@noa-archive.com |
|---|---|
| State | Accepted |
| Commit | 8db301deadfcf113fb274881e65afcbe3e1bd645 |
| Headers | show |
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@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 [...]
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@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)? Another option would be to just apply the other two patches as they are passing FATE without this one (framerate is guessed from stream timebase then). Regards, Tobias
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@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 [...]
diff --git a/ffmpeg.c b/ffmpeg.c index 06570c0..333a806 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -3202,6 +3202,8 @@ static int init_output_stream_encode(OutputStream *ost) enc_ctx->bits_per_raw_sample = FFMIN(dec_ctx->bits_per_raw_sample, av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth); + enc_ctx->framerate = ost->frame_rate; + ost->st->avg_frame_rate = ost->frame_rate; if (!dec_ctx ||