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

[James Almer]

On 10/31/2016 3:30 PM, Nicolas George wrote:
> Le decadi 10 brumaire, an CCXXV, James Almer a écrit :
>> It's an scenario that could happen, like it or not. I'd rather not open the
>> doors for it.
> 
> "Opening doors" sounds like a different wording for the slippery slope
> fallacy.

Would you prefer "setting a precedent", then?

> 
>> "why this format and not this other" is coincidentally the argument that
>> will be used after this thing gets committed to justify adding others.
> 
> And the answer in this case is very easy: if the format is more useful
> than harmful, it goes in.

No. You insist this is about technical merits, and i already mentioned this
is not about that.

> 
>> If something is to create these files, it should be ffprobe itself and
>> not some unrelated muxer that's going to duplicate a lot of code.
> 
> I agree, that would be best.
> 
>> It might, hence why i suggested this being implemented as a standalone tool
>> and not that you should drop the whole thing.
> 
> Ok, thanks.
> 
>> You presented an scenario and use case to dump media streams into a text
>> file to easily alter them, analyze them and reconstruct them. You then
>> declared said dumps to be an actual format so they could qualify for an
>> avformat module that could digest them.
>>
>> There are no technical drawbacks for this demuxer.
> 
> Again, thanks. Therefore, let us discuss the rest:
> 
>> 						     This is a concept and
>> design issue. It's a very specific need so far a single person or two
>> that's being forced into the libraries because it's the easiest way to
>> implement it.
>>
>> This should be written as a standalone tool that uses lavf API to rebuild
>> the custom xml-like dump with the hex formatted packets as created by
>> ffprobe. Basically, write ffmpeg's own, more powerful and versatile
>> version of oggz-dump that uses lavf instead of libogg, meaning the dumps
>> can be created and rebuilt from and into any lavf supported format.
> 
> Ok. But compared with the demuxer approach, I see several drawbacks
> (some of which I have already posted):
> 
> - More code, therefore more maintenance burden.
> 
> - When used for debugging (this is the main purpose of this feature),
>   more code path, and therefore more room to trigger unrelated bugs that
>   will waste time.
> 
> - Subject to the limitations of the intermediate format.
> 
>   This one is especially important: imagine I am trying to investigate a
>   bug that happens with files with inconsistent timestamps. I can edit
>   the dump to make the timestamps inconsistent. And then... I try to
>   rebuild a file based on the dump, and lavf (used by the undump tool)
>   forbids me to mux inconsistent timestamps. Game over.
> 
>   The whole point of this demuxer is to be able to build slightly broken
>   input, because they are the cases that need debugging the most.
>   Unfortunately, if you convert to an actual format, some of the
>   brokenness will be fixed on the fly or flat out impossible.
> 
> - More steps for the person who is doing the debugging. Considering some
>   debugging sessions will require hundreds of rounds, the difference
>   will add up. Not just the generation step, but also the half hour lost
>   because the developer forgot to convert after a change in the text
>   file.
> 
> Now, your move:

This is not a competition, Nicolas, and this is not a technical merits
discussion. Nobody doubts a lavf module would be much more versatile and
powerful than a standalone tool.

> 
> * 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?
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.

> 
> Regards,
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>