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

[Nicolas George]

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.

> "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.

> 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:

* What benefits do you see for the separate tool approach?

* Can you negate any of these drawbacks?

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161031/6d3f8775/attachment.sig>