On Fri, Mar 17, 2017 at 01:59:40PM +0100, Hendrik Leppkes wrote: > On Fri, Mar 17, 2017 at 12:32 AM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote: > >> Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a écrit : > >> > Applications which depend on the current default would need > >> > >> ... to implement a correct structure to carry the data from their > >> demuxer to the lavc decoders. > > > > Is this possible for every application using every framework ? > > > > If you are using a multimedia framework, then putting non-media data > into the media buffers is even worse then doing it internally in > avformat->avcodec only. > There could be all sorts of other components in play in such a > framework which have no idea what this sidedata is, and as someone > actually working with such a framework daily (DirectShow), it can and > has broken playback when non-avcodec decoders were used and such data > was in the packets. > > So in short, the "merge" solution has never solved anything for me > using a media framework, luckily it was only used very sparingly > (until recently when every packet out of the mpegts demuxer suddenly > had pointless sidedata and broke all the things). > If you use a multimedia framework that does in no way allow you to > attach side data to the packets, then the person working with the > framework should decide what to do about that, because only they know > how their framework may work - merging it into the data has potential > for way more breakage.
i agree i think the open question is if removing the possibility for user apps to call the merge / split functions is a good idea or not. Removing them makes it obviously impossible for a user app to use them Leaving them gives a user application the choice to use or not use them [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
