[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