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

[James Almer]

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?
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?