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

[Stefano Sabatini]

On date Tuesday 2016-11-01 02:45:00 -0300, James Almer encoded:
> 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.
> 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.
> 
> At least three developers have stated being against the implementation
> of such an arbitrary custom format, and as much as you want to cover your
> ears, declare it's all "duplicate arguments" in order to downplay and
> discard their opinions, and decree that no matter how many people are
> against something from a design PoV the only thing that matters are
> technical arguments limited to the realm of how to implement the solution
> for the very specific scenario you're presenting, if more people are
> against it than in favor then it should not go in, or a vote should be
> called.
> 

> And why not just keep it in a separate repo for that matter? Why does it
> need to be committed to the main repo?

It depends. If implemented as a libavformat component, it's impossible
to publish it in a separate repository. If implemented as a standalone
tool that would be possible, but still would require to duplicate the
FFmpeg infrastructure (mostly the configure/build system).

For my first use case (injecting data streams) it would be much easier
to write a custom tool. I was asked to integrate this into FFmpeg to
avoid the conversion step (custom format => standard format), and
while doing this I was suggested to use the more general ffprobe
format, which although not a real format was something which was
already used internally by the project.

Talking about conversion tools (say it ffprobe-dump and
ffprobe-undump), I wonder how they would work. I expect something as:

ffprobe-dump IN > OUT.ffprobe

(this could also be a modified version of ffprobe, probably with some
custom options).

Now you need to import the file (possibly after you edit it). The
problem here is that you need to convert it to another internally
supported format, using libavformat. That's when it becomes
inconvenient, because you basically need to use the library to convert
the format (see the arguments by Nicolas and Michael).

> You talk about maintenance, yet keeping it in a separate repository would
> mean as much maintenance for you as it would in the main repository.

I see the validity of the arguments for not integrating this into
FFmpeg, yet (sorry for repeating), there are also valid arguments in
favor of the integration, that's why I proposed a vote since I think
that technical arguments cannot resolve the decision alone, since it
also involves design and policy (which depend on how each every
developer conceives the project, which is somehow subjective).
-- 
FFmpeg = Foolish & Faithless Mortal Proud Ermetic Gigant