Closed Murmur closed 1 year ago
It seems --cmaf=cmfc
writes 3.84s segments with drm or without any, files have a correct total sum of SIDX.duration=3,84s
. Still happening mdat.dur=24*512
may not match to the duration field in SIDX fragment but I am probably missing some small detail(?).
Timing may relate to negctts handling? cmf2: trun.version=1, negctts(negative composite offset allowed) cmfc: trun.version=0, no negctts being used.
MP4Box -dash 184320 -frag 46080 -dash-scale 48000 -mem-frags -rap -profile dashavc264:live \
-profile-ext urn:hbbtv:dash:profile:isoff-live:2012 -min-buffer 2000 \
-bs-switching no -sample-groups-traf -single-traf --tfdt64 --tfdt_traf --noroll=yes --btrt=no \
--truns_first=yes --cmaf=cmfc -subsegs-per-sidx 0 \
-segment-name "$RepresentationID$/$Number$$Init=i$" \
-out manifest.mpd:dual \
"temp/temp-v1.mp4#trackID=1:id=v1:period=p0:asID=1:role=main:dur=24:#HLSPL=manifest_v1.m3u8" \
"temp/temp-a1.mp4#trackID=1:id=a1:period=p0:asID=21:role=main:dur=24:#HLSPL=manifest_a1.m3u8:#HLSGroup=audio"
What is the real reason to choose cmfc or cmf2 profiles?
Can I control trun.version=1 using a cmdline --negctts=yes
flag or similar, could run without cmaf profiles to see how things go with various use cases?
I think have found a partial fix, need to specify :negctts
flag in a crypt cmd. Dashing can use cmf2, cmfc
profiles and include SIDX box in a segment file. Total duration of sidx and sidx.earliestPresentationTime looks good in 1..n.m4s segment files.
Still sidx.duration
fragment does not match to mdat.duration
fragment.
MP4Box -crypt drm-cenc.xml temp/temp-v1.mp4 -out temp/temp-v1-cenc.mp4:negctts
MP4Box -dash 184320 -frag 46080 -dash-scale 48000 -mem-frags -rap -profile dashavc264:live \
-profile-ext urn:hbbtv:dash:profile:isoff-live:2012 -min-buffer 2000 \
-bs-switching no -sample-groups-traf -single-traf --tfdt64 --tfdt_traf --btrt=no \
--truns_first=yes --cmaf=cmf2 -subsegs-per-sidx 0 \
-segment-name "$RepresentationID$/$Number$$Init=i$" \
-out manifest.mpd \
"temp/temp-v1-cenc.mp4#trackID=1:id=v1:period=p0:asID=1:role=main" \
"temp/temp-a1-cenc.mp4#trackID=1:id=a1:period=p0:asID=21:role=main"
**NEW cenc segments, :negctts flag was used in a crypt command (ok)**
- 1.m4s and 2.m4s sidx total duration is correct
- still sidx.duration fragment does not match to mdat.duration fragment !!!
cenc/v1/1.m4s SIDX.earliestPresTime=0, timescale=12800, trun.version=1
SIDX.dur= 12800, 12288, 12288, 11776, total=49152 (3,84s) !!!
mdat.dur=24*512=12288, 24*512=12288, 24*512=12288, 24*512=12288, total=49152 (3,84s) !!!
cenc/v1/2.m4s SIDX.earliestPresTime=49152(3,84s) !!!
SIDX.dur= 12800, 12288, 12288, 11776, total=49152 (3,84s)
mdat.dur=24*512=12288, 24*512=12288, 24*512=12288, 24*512=12288, total=49152 (3,84s)
**OLD cenc segments, no :negctts flag in a crypt command (incorrect)**
- 1.m4s SIDX.dur is wrong, wrong value goes to 2.m4s sidx.earlisetPresentationTime field.
cenc/v1/1.m4s SIDX.earliestPresTime=0, timescale=12800, , trun.version=1
SIDX.dur= 11776, 12288, 12288, 11776, total=48128 (3,76s) !!!
mdat.dur=24*512=12288, 24*512=12288, 24*512=12288, 24*512=12288, total=49152 (3,84s) !!!
cenc/v1/2.m4s SIDX.earliestPresTime=48128(3,76s) !!!
SIDX.dur= 12800, 12288, 12288, 11776, total=49152 (3,84s)
mdat.dur=24*512=12288, 24*512=12288, 24*512=12288, 24*512=12288, total=49152 (3,84s)
We indeed had a bug when moving from ctts v0 to v1, source delay was not ignored when computing sidx, now fixed thanks for the report.
Regarding fragment durations, this is the expected behaviour: mdat.duration is the sum of durations of all samples in the fragment, but sidx.duration is NOT, it is the diff between the min cts in the next sidx entry (or in next segment) and the min cts in the fragment. Depending on the gop structure, this can change the fragment duration.
Thanks, all looking good. I was not aware of sidx.dur|mdat.dur does not follow the same calculation. Using fps=25, segdur=3.84s, gop=1.92s, frags=2 | aac 48Khz
writes two video fragments(dur=24576, scale=12800, both sidx rap=1) and sidx.dur=mdat.dur
match in a segment file.
(latest mp4box from git) Dash segments don't have an equal duration in
SIDX.duration
andmdat.duration(samples*dur)
fields. Should SIDX and mdat fragment chunk durations match?Things go even more wrong after encryption, first
cenc/v1/1.m4s
file isSIDX.dur=3.76s, mdat=3.84s !!!
values.Encoding target is 3,84s segments (input aac 48Khz/h264 25fps, gop 96 frames), this should give 100% align video+audio segment durations.
4x fragments, no drm and drm
1x fragment, no drm, drm
intermediary temp-xx.mp4 input files https://refapp.hbbtv.org/videos/dashtest/test1/temp/temp-v1.mp4 https://refapp.hbbtv.org/videos/dashtest/test1/temp/temp-a1.mp4 https://refapp.hbbtv.org/videos/dashtest/test3/temp/temp-v1.mp4 https://refapp.hbbtv.org/videos/dashtest/test3/temp/temp-a1.mp4
Dash command lines
drm-cenc.xml
ps: #2377 ticket is loosely related to a timing, SIDX.earliestPresentationTime value was fixed.