[FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Clément Bœsch]

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 <michael at 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 <michael at 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.