[FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[Michael Niedermayer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161101/c3017931/attachment.sig>