Le decadi 20 messidor, an CCXXV, Reimar Döffinger a écrit : > I don't think that's a correct description then. > First, the format is made to change and be extended, so what is > true now might not stay true. > But also the images can have arbitrary dimensions, in particular > they can be "3D" images with the third dimension being time, > thus being a video. > This may not be well enough specified for the demuxer to be > able to produce a proper "video stream" at this point, > but implementing it in the img2 framework to me seems to > have a significant risk of turning out a dead-end.
Ok. To me, it looks identical to GIF: it is primarily an image format but with non-essential animation features, it was first implemented as part of img2 and only when somebody did actually implement the animation features was it implemented as an actual demuxer. I think it was the right approach. Anyway, whatever solution is chosen to fix it, the big chunk of logic duplication between the demuxer and the decoder as they are is IMO unacceptable in new and non-essential code. Even more so in the scope of an internship project, where the primary goal is not to produce code as fast as possible but to teach good coding practices. Therefore I urge again to post a dump of a typical three-images FITS file and comment it to see which part belong in which data structure. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
