[FFmpeg-trac] #1916(avformat:open): mxf format pcm_s24le decoding is broken.
FFmpeg
trac at avcodec.org
Fri Jan 4 17:05:44 CET 2013
#1916: mxf format pcm_s24le decoding is broken.
-------------------------------------+-------------------------------------
Reporter: dem0n | Owner:
Type: defect | Status: open
Priority: important | Component: avformat
Version: git-master | Resolution:
Keywords: mxf | Blocked By:
regression | Reproduced by developer: 1
Blocking: |
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Tjoppen):
The sample file is broken. Assuming you didn't mess with the file with dd
(or similar) then Amberfin needs to fix their muxer. Here's an analysis:
The essence is contained in one huge, 994593600 byte (@ $2DDD) KLV. The
file is only 9437489 bytes. This is a problem.
The reason this file worked before is because av_get_packet() refuses to
read past EOF. This is evident from the line "Truncating packet of size
994593600 to 9425725". This also means that almost the entire file was
read into RAM, which is what bf2290a8 was meant to fix. Another problem is
that reading the entire rest of the file also includes what looks like
!FooterPartition data at the end of the file.
The reason for this is that the demuxer assumes OP1a == frame-wrapped. It
*might* be legal to use clip-wrapping instead. Indeed, the
!EssenceContainer UL in the file (06 0E 2B 34 04 01 01 01 0D 01 03 01 02
06 02 00) corresponds to "MXF-GC Clip-wrapped Broadcast Wave audio data
(SMPTE 382M)" (per RP224v10). If I force the demuxer to treat the file as
OPAtom (always clip-wrapped) then it works a little better. Sadly, because
MXF is MXF, it is not easy to detect the wrapping kind used in general. I
have a tool that figures out what a UL means based on the RP224v10 Excel
sheet (yay perl), so it's conceivable to parse the wrapping kind
information out of the .xls. First I need to know the file wasn't messed
with though.
Speaking of !FooterPartition, it's not located where the header claims it
is:
{{{
ClosedCompleteHeader
MajorVersion = 1
MinorVersion = 2
KAGSize = 1
ThisPartition = 0
PreviousPartition = 0
FooterPartition = 994605365
^^^^^^^^^-- way past EOF
HeaderByteCount = 11489
IndexByteCount = 128
IndexSID = 129
BodyOffset = 0
BodySID = 1
OperationalPattern = MXF OP1a SingleItem SinglePackage
EssenceContainers
EssenceContainer = MXF-GC AES-BWF Audio
}}}
By the way:
{{{
Identification
InstanceUID = {c380b4ee-5b6e-11e1-a3ce-00265533fdc2}
ThisGenerationUID = {c480b4ee-5b6e-11e1-a3ce-00265533fdc2}
CompanyName = AmberFin Limited.
ProductName = iCR
ProductVersion = Major="7", Minor="2", Patch="0", Build="44848",
Release="VersionReleased"
VersionString = 7.2.0.44848
ProductUID = {84ae5ffc-4710-11dd-a6fe-0010c629ec73}
ModificationDate = 2012-03-15 5:01:35.080
ToolkitVersion = Major="1", Minor="3", Patch="0", Build="5",
Release="VersionReleased"
Platform = MXF Desktop
}}}
So: assuming you didn't mess with the file then you need to tell Amberfin
to fix their MXF muxer(s).
In the meantime, using mxfsplit is a possible workaround if you don't mind
the FooterPartition crap near the end:
{{{
$ mxfsplit pcm_s24le_to_pcm_s16le.mxf && ffmpeg -f s24le -ar 48000 -ac 1
-i _0001-G16010201.Stream foo.wav
}}}
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1916#comment:2>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list