sön 2024-02-25 klockan 05:14 +0100 skrev Jerome Martinez: > On 24/02/2024 13:26, Tomas Härdin wrote: > > 3a) if the codec is inherently interlaced, call the decoder once > > 3b) if the codec is not inherently interlaced, call the decoder > > twice, > > with appropriate stride, and keep track of the number of bytes > > decoded > > so far so we know what offset to start the second decode from > > > The place I see for that is in decode_simple_internal(). > But it is a very hot place I don't like to modify, and it seems to me > some extra code for 99.9999% (or even more 9s) of files which don't > need > such feature,
See below > with more risk to forget this specific feature during a > future dev e.g. not obvious to change also in ff_thread_decode_frame > when touching this part. This is why we adds tests. > I also needed to add a dedicated AVStream field for saying that the > decoder is able to manage this functionality (and is needed there). > > What is the added value to call the decoder twice from decode.c > rather > than recursive call (or a master function in the decoder calling the > current function twice, if preferred) inside the decoder only? We get support for all codecs that can do SEPARATE_FIELDS in MXF, rather than a half measure that only supports j2k, that we'd have to fix later anyway. > > The codecs for which 3b) applies include at least: > > > > * jpeg2000 > > Our use case. > > > * ffv1 > > FFV1 has its own flags internally for interlaced content (interleaved > method only) and I expect no work for separated fields. the MXF/FFV1 > spec does not plan separated fields for FFV1, and there is no byte in > the essence label for that. Ah, I missed that > > * rawvideo > > * tiff > > I didn't find specifications for the essence label UL corresponding ULs aren't for specifying interlacing type (though I wouldn't be surprised if there's a mapping that misuse them for that) > and > I have no file for that, as far as I understand it is highly > theoretical I've had clients asking about VBI data in MXF, which sometimes are stored as raw samples. It is not outside the realm of possibility that someone using MXF for archival purposes would use raw video which, due to the nature of capture equipment, would be stored as SEPARATE_FIELDS. I'm not aware of a mapping document for this however, but I am aware of people doing precisely this kind of stuff. > but if it appears would be only a matter of mapping the MXF signaling > to > the new AVStream field and supporting the feature in the decoders > (even > if we implement the idea of calling the decoder twice, the decoder > needs > to be expanded for this feature). So in other words putting it into every decoder for which there exists an MXF mapping for SEPARATE_FIELDS, rather than doing it properly? /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
