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

[Michael Niedermayer]

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.

done locally


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

currently the 2 fields are filled in by avformat_find_stream_info()
parsing and or decoding headers and packets and these can require many
packets. The 2 fields really arent special, avformat_find_stream_info()
fills in alot of little bits and pieces from informative over occasional
useful to critical things.
What avformat_find_stream_info() does could be moved into applications
But that would duplicate the code in many user applications and make
it impossible to centrally fix bugs or add features. It could be moved
under a different API too of course. This would raise the question of
"Why" we again reimplement the API. Theres also a general lack of
discussions about design changes and API deprecations on ffmpeg-devel,
which may be part of the problem

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160908/7c094e37/attachment.sig>