mån 2024-02-19 klockan 00:14 +0100 skrev Tomas Härdin:
> tor 2024-02-15 klockan 16:02 +0100 skrev Jerome Martinez:
> > On 05/02/2024 01:19, Tomas Härdin wrote:
> > > [...]
> > > Which entry in the table would the provided file correspond to?
> > > To
> > > me
> > > it seems none of them fit. There's two fields, meaning two j2k
> > > codestreams, in each corresponding essence element KLV packet (I
> > > think,
> > > unless CP packets get reassembled somewhere else). Entry I2 seems
> > > closest but it specifies FULL_FRAME. I1 is otherwise tempting,
> > > but
> > > there SampleRate should equal the field rate whereas the file has
> > > SampleRate = 30000/1001.
> >
> > Other examples I have (not shareable) with 2 jp2k pictures per KLV
> > have
> > identification from an old version of AmberFin iCR, I have no file
> > with
> > the I2 correctly signaled, with my first example it isI2 (2 fields
> > per
> > KLV) with I1 Header Metadata Property Values **but** with I2
> > essence
> > container label which has a content byte (byte 15 of the UL) of
> > 0x04
> > = I2.
> > The AmberFin iCR files have the generic essence container label
> > with
> > content byte of 0x01 = FU (Unspecified) so for my main use case we
> > could
> > activate the search of the 2nd jp2k only if I2 is explicitly
> > signaled
> > by
> > the essence container label but it would prevent to catch the 2nd
> > field
> > when this signaling is unspecified and buggy Frame layout + sample
> > rate
> > + edit rate.
>
> I'm not super stoked about implementing support for broken muxers.
> Instead these companies should fix their code. But either way we at
> the
> very least need a reliable way to detect these kinds of files if we
> are
> to do this. There was no Software + Version information in the sample
> provided, which is otherwise a reliable method to deal with shitty
> muxers.
Correction: there is Identification metadata, but it's at the end of
the header metadata so I missed it.
Identifications
Identification = {fb8e5be0-1fc5-11e9-8263-7062b8a31e5c}
Identification -> Strong Reference to Identification
Identification
InstanceUID = {fb8e5be0-1fc5-11e9-8263-7062b8a31e5c}
ThisGenerationUID = {fb8e5be0-1fc5-11e9-8264-7062b8a31e5c}
CompanyName = OpenCube
ProductName = MXFTk Advanced
ProductUID = {3a4fe380-0d01-11e4-869f-3cd92b5c1dfc}
VersionString = 2.7.0.20190123
ProductVersion = Major="2", Minor="7", Patch="0", Build="0",
Release="VersionReleased"
ToolkitVersion = Major="2", Minor="7", Patch="0", Build="0",
Release="VersionReleased"
Platform = Microsoft Windows 7 Professional Service Pack 1
(Build 7601)
ModificationDate = 2019-01-24 11:51:37.884
LastModifiedDate = 2019-01-24 11:51:37.884
GenerationUID = {fb8e5be0-1fc5-11e9-8264-7062b8a31e5c}
This at least (maybe) allows us to detect these broken files. But does
MXFTk *always* write interlaced files like this?
/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".
