On Thu, Sep 07, 2017 at 04:17:24PM -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(). i do see differences in other mkv output, i assume these are also from field_order one example ./ffmpeg -copyts -ss 11 -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 moon.mkv [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
