On Fri, May 26, 2017 at 05:08:51PM -0300, James Almer wrote: > There's no need to wait for the first packet of every stream now that > every bitstream filter behaves as intended. > > Signed-off-by: James Almer <jamr...@gmail.com> > --- > What should we do with the AVFMT_FLAG_AUTO_BSF flag? Do we deprecate > it and force the automatic insertion of muxer-required bitstream > filters now that the generic muxing code will always behave the same, > or keep it to give the user a choice to apply said bitstream filters? > I ask because some filters, like vp9_superframe, are necessary to > avoid creating broken files, so it's not wise to allow the user to > disable it. > It would also go in line with AVCodec.bsfs, which is essentially a > non-optional (for reasons made obvious in fa1749dd34) autobsf at the > codec level instead of container level. > > The change to fate-rgb24-mkv is a regression that can be prevented by > committing https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211311.html > or a similar solution, maybe using avformat_init_output(), to make sure > ffmpeg.c sets AVCodecParameters->field_order for the output stream before > calling avformat_write_header(). > > libavformat/internal.h | 6 ----- > libavformat/mux.c | 53 > +++++++++--------------------------------- > libavformat/options_table.h | 2 +- > libavformat/tests/fifo_muxer.c | 52 ----------------------------------------- > tests/ref/fate/fifo-muxer-tst | 1 - > tests/ref/fate/rgb24-mkv | 4 ++-- > 6 files changed, 14 insertions(+), 104 deletions(-)
seems not to apply cleanly, so i cannot test it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
