[FFmpeg-devel] [PATCH] Add FITS Demuxer

[Reimar Döffinger]

On 19.07.2017, at 12:03, Nicolas George <george at nsup.org> wrote:

> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a écrit :
> 
>> I think the image2 demuxer shouldn't handle this type of junk/useless data
>> filtering and would rather see a separate demuxer like the current patch
>> which deals with crap.
> 
> I am somewhat confused by your statement, because in my mind, this is
> exactly the purpose and task of the image2(pipe) demuxers.
> 
> The image2pipe demuxer reads the input stream, calls a parser to find in
> it the size of the images and returns them as individual packets. Note
> that the parsers are not part of the image2(pipe) demuxers, they are
> separate entities of their own, each specific to one image format.
> 
> I do not know what the image2pipe demuxer would be good for, if not for
> that. Or did I miss something?

I am a bit unclear on the details, but my memory:
Well, they work better (only?) if the images are completely independent.
I am not sure this is entirely the case here, for example the first image would have a different header it looks like from the muxer patch.
There is also the question: how would the encoding work?
Because if encoding will be using a muxer, having things symmetric by having a demuxer is an advantage.

> Good design and maintenance require a single implementation.

I don't think we have the right frameworks for that. Other cases like the MPEG video format parsers and decoders also duplicate that kind of code.
There might be some ways though, I am mostly thinking of an iterative function that is called with a pointer to each 80 byte header buffer and updates a state structure with the info it extracts from there. Would still get messy if the decoder needs quite different data than the demuxer.
I have not yet checked how similar these functions actually are.

> I think the best and simplest way of achieving that is to have both the
> parser and the decoder call the same function. And I think the simplest
> way of implementing it is to make a parser and rely on image2pipe.

Parsers work best when parsing requires very limited context.
My impression is that there is no fixed maximum header size, which can easily make things really painful in a parser.

Also considering the complexity: I suspect that the header parsing can be simplified a good bit, and maybe some common helper functions extracted.
I wouldn't insist on avoiding code duplication when trying to share it might actually result in more complicated code. But it probably needs some thinking to figure out what makes sense.