cmd/mp4ff-info: invalid moof size reported

[3052]

using this file (97 KB):

http://0x0.st/HgmH.m4f

I get this:

> mp4ff-info -l trun:1 segment0.m4f
[moof] size=4641
  [mfhd] size=16 version=0 flags=000000
   - sequenceNumber: 1
  [traf] size=4617
    [tfhd] size=20 version=0 flags=020008
     - trackID: 1
     - defaultBaseIsMoof: true
     - defaultSampleDuration: 1024
    [tfdt] size=20 version=1 flags=000000
     - baseMediaDecodeTime: 0
    [trun] size=2252 version=0 flags=000301
     - sampleCount: 279
     - DataOffset: 6881

with another tool:

https://github.com/abema/go-mp4/tree/master/cmd/mp4tool

I get this:

> mp4tool dump -full trun segment0.m4f
[moof] Size=6873
  [mfhd] Size=16 Version=0 Flags=0x000000 SequenceNumber=1
  [traf] Size=6849
    [tfhd] Size=20 Version=0 Flags=0x020008 TrackID=1 DefaultSampleDuration=1024
    [tfdt] Size=20 Version=1 Flags=0x000000 BaseMediaDecodeTimeV1=0
    [trun] Size=2252 Version=0 Flags=0x000301 SampleCount=279 DataOffset=6881

what made me notice is that typically trun.DataOffset will be moof.Size + 8.

[tobbee]

Yes, mp4ff has some problem in parsing the senc-box and reports its size as too small. It should be 2248, but is reported as 16. This size then propagates up to higher level, since the sizes come from mp4ff's internal representation of the boxes.

The parsing of the senc box is in general more complex than others, since some values depend on other boxes. There is therefore a two-pass parsing of it. In any case, this looks like a bug, so I'll see how it can be fixed.

[tobbee]

I found a bug for this particular case of senc box encoding in the second phase of parsing it. The size issue should be fixed in PR #309.

This looks like a file that tries to be compatible both with common encryption as used in DASH and with PIFF-encryption as used in SmoothStreaming (there is a PIFF "senc"-box embedded in the uuid-box coming after the senc box). I have some work ongoing on adding PIFF decryption support. I hadn't thought before that there was a case like this, where one can either decrypt using common-encryption information or PIFF information.

For my curiosity, what tool was used to generate it?

[3052]

For my curiosity, what tool was used to generate it?

it comes from https://www.amcplus.com. I can provide an MPD if its helpful, but I think the media URLs have an
expiration. also here is the init if it helps:

https://github.com/Eyevinn/mp4ff/files/13778007/init.zip

I did notice it says Bento4 Sound Handler in the hdlr box

[tobbee]

I've fixed this now, but here is some more background.

mp4ff-info is not a simple parser, but it creates an internal representation of the the mp4 file so that one can manipulate all internal boxes or add boxes. The size of the boxes are not stored, but instead always calculated from the the content of the box and child boxes. In this case, the media segment itself does not have a value for "perSampleIVSize", but is dependent on the init segment to get that. If you concatenate the init segment with the media segment (or run mp4ff-decrypt with the init segment), the library gets the information about the perSampleIVSize from the init segment so that it can build a proper representation of all the data in the senc box.

To fix this in the general case, I am now deferring the perSampleIVSize from the information I've got in the media segment if no value is provided from the outside. I included the "moof" part of your asset in a test.

[3052]

confirmed fixed - thanks