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.
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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
