On 9/7/2016 6:14 AM, Michael Niedermayer wrote: >> libavformat/utils.c | 4 +++- >> > tests/ref/fate/copy-trac4914 | 4 ++-- >> > tests/ref/fate/copy-trac4914-avi | 4 ++-- >> > 3 files changed, 7 insertions(+), 5 deletions(-) >> > 2dc146e807cbdbdbca653a22d827920e8c05b3c8 >> > 0001-avformat-Export-ticks_per_frame-in-st-codec.patch >> > From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001 >> > From: Michael Niedermayer <mich...@niedermayer.cc> >> > Date: Tue, 6 Sep 2016 18:10:41 +0200 >> > Subject: [PATCH] avformat: Export ticks_per_frame in st->codec >> > >> > Suggested-by: Hendrik Leppkes >> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > applied > > with this we have restored the functionality to prior bug/regression > so it should serve better as a reference.
Should be backported to the 3.1 branch. Regarding this whole time_base/ticks_per_frame issue, couldn't we maybe add both fields (merged or as is) to codecpar as Clément suggested, but as internal/hack/nonpublic instead at least until we find a proper way to solve the stream copy case? I know adding private-but-not-really fields suck, but so does being stuck here because AVI is a crappy format. Alternatively, since until now ffmpeg.c's stream copy has been using the initialized AVCodecContext from AVStream, can't we alloc, initialize and use a separate one, much like it's done for actual transcoding? Would that be enough for the decoder to set the two fields? I'm throwing shit at the wall to see what sticks, because i barely know half of what this whole problem entails. But i do know that the more we bikeshed the less chances it will be resolved in a timely and adequate manner. For that matter, libav clearly didn't have this issue. Does that means avconv is creating broken files in these specific cases with stream copy? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel