On Tue, Nov 01, 2016 at 02:45:00AM -0300, James Almer wrote: > On 10/31/2016 3:30 PM, Nicolas George wrote: > > Le decadi 10 brumaire, an CCXXV, James Almer a écrit : [...] > > > > * What benefits do you see for the separate tool approach? > > > > * Can you negate any of these drawbacks? > > I'll repeat what i said. This is not a technical discussion. This is a > design issue. For your very specific debugging needs and scenario, you > devised a way to dump media streams into a text file and declared said > dumps a multimedia "format" so they may qualify for a demuxer.
not being nicolas, and not having desiged this and I admit fully not understanding the design issue. Most generically Something that takes a linear stream of bytes (possibly finite possibly not) (possibly seekable, possibly not) and spits out ordered byte sequences (packets) organized by streams, maybe with timestamps metadata, chapters, ... Is something I would call a demuxer Or rather thats how i would define a demuxer. something taking a linear text stream (ffprobe formating) that spits out ordered byte sequences (packets) organized by streams, maybe with timestamps metadata, chapters, ... Is by that definition also a demuxer. While for example a video capture device would NOT be a demuxer, it doesnt have a linear byte stream as input, it in fact doesnt have an input from the point of view of the software. I do understand the issue people had with demuxers being used as video capture API but i dont understand it here for a ascii/utf8 instead of a standarized with spec binary input. > Libavformat is not a dumping ground for code molded by a single person's > specific needs, and it is not a library meant to hold your or anyone's > debug tools. playing devils advocate, why not? If a group of developers needs some code to debug and maintain a part of FFmpeg it does seem logic to me to dump that in the codebase if it doesnt affect anyone else except psycological. we can play this thought experiment even more evil. Consider a fork one where developers dump the code they need to maintain and debug in the code base (strictly limited to what does not affect others technically) and one fork where people cannot do this Who of the 2 is more "fit" for survival in a evolutionary / darwinian sense ? A project where people can just debug and maintain their code or a project where its more cumbersome in some way (seperate repo, seperate tool that only works in a subset of cases, ...)? I dont want to be offensive but to me one side of this argument is completely absurd maybe iam an idiot and just dont see it, but i really dont understand why we would want to make it harder for ourselfs to maintain and debug things. Now after writing this, theres somethig i realize Is the issue people have with the text/ffprobe demuxer that it is not a standarized format ? Would writing a formal specification resolve this whole disagreement ? I mean a real actual quality spec from which one could write both a muxer and demuxer that can interoperate [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
