On Wed, Sep 07, 2016 at 10:07:26PM -0300, James Almer wrote: > 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? There might be another way. If this is moved to lavf/utils, the code will have access to AVStream->internal->avctx, which is (still) legit. AFAICT, this will require a function such as avformat_remux_copy_timebase(). But is this what we really want? Also, we need to clarify the use of copy_tb. Currently, according to the doc, 0=demuxer, 1=decoder, -1=auto but 2 is not documented (maybe it's time to move the cli options to an AVOption system to have constants). > I know adding private-but-not-really fields suck, but so does being stuck > here because AVI is a crappy format. > This is not only for avi, see eed7e08 cf9500a ba96a2a > 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? And re-do the probe somehow to fill its parameters? > 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. Yes, and this is really hindering any progress with the merge (ETA: ~300 commits, twice as worse as a few weeks ago). > 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? AFAIK, yes -- Clément B. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel