On 19/02/2024 12:08, Tomas Härdin wrote:
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.
Same.
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?
Beside the fact we don't know the version, I have files from other
muxers having the same issue.
In practice:
- For the example file, no need to check identification, as said
previously essence container label provides I2 tip, so I could propagate
I2 tip to the jp2k decoder
- But if we limit to that, some other files in the wild won't be
recognized because essence container label stipulates (legally)
unspecified and (out of spec but it is real) have the same issue with
frame layout.
If I understood correctly the other comments an AVPacket should be a MXF
element so the MXF parser should not split the packet.
I am preparing a v2 patch which does not include the extra probe,
relying on current jp2k parser for catching the 2nd field, so in my
opinion there is not value added to try to catch I2 including buggy
muxers in MXF.
Jérôme
_______________________________________________
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".
