Incorrect duration on mpd file

[rcottingham]

We have noticed from our Observation Framework validation that some content has the incorrect duration in the mpd file e.g: in this content:

• The reported duration from the mpd file is mediaPresentationDuration="PT0H0M29.996S"

• However, the actual duration of the presentation is 29.997S (analysed using MediaArea.net/MediaInfo)

We noticed on this one, but others may have the same issue.

Please ensure that for all content the actual duration and the mediaPresentationDuration value in the mpd file match.

[jpiesing]

@nicholas-fr Is this something that could be added to your script in addition to checking that the correct mezzanine was used?

[yanj-github]

I have concated all the fragment in the content folder and added up total duration gives it total 29.997S but in mpd file it shows mediaPresentationDuration="PT0H0M29.996S".

[rbouqueau]

For the record:

(60060*14+59059)/30000 = 29.99663333333333333333

So we're talking about millisecond truncation/rounding accuracy here.

I've found no reference in the MPEG DASH standard.

Could you give more context about how this is an issue?

[yanj-github]

Thanks @rbouqueau this is clear to me now. I can see that the duration is rounded down 3 decimal points in mpd. This is causing issue on observation framework reporting last frame is incorrect for fractional frame rates content.

Observation Framework takes the duration from mpd, which is reported in the test runner configuration file, to calculate what is the expected last frame. At the moment, the calculation on OF for expected last frame number is 1 less than the actual presented frame from the content. And this is cause by "PT0H0M29.996S" is being rounded down. To resolve the issue we can either update content mpd or observation framework. 

My question is whether or not there is a reference somewhere it states duration should be rounded down or up? @rbouqueau stated that nothing on MPEG DASH standard and we are also haven't spotted any reference as well. If there is no common standard for how duration should be rounded then this issue might come back if we just fix current content or algorithm on OF. As others might generate contents which are round differently. Does anyone else aware of any reference to this please? Or want to add requirement to the dpctf spec?

Alternatively, we can allow bigger tolerance for last frames on OF if this is preferable. 

For the future solution, OF can calculate last frame based on sum of SegmentTimeline instead of from mediaPresentationDuration. We have raised issue here https://github.com/cta-wave/dpctf-tests/issues/98 for audio observation to get SegmentTimeline, and if we have same information for video which is passed on dpctf test configuration file then we can update OF to use SegmentTimeline to get correct duration. I assume SegmentTimeline not be a rounded number here but it might cause same issue if SegmentTimeline is again possibily rounded? Any comments please?

[nicholas-fr]

For some of the test vectors the delta is ~equal to or longer than the duration of 1 frame, which I would not expect. Particularly strange is t2 25fps:

[rbouqueau]

@nicholas-fr I am not sure to follow you. Where does the "Total sample duration" column value come from? Again if I take the duration from the segment timeline in the MPD for t1@29.97 I get (60060*14+59059)/30000 = 29.99663333333333333333, not 30.029999.

And the value for t2 at 25 fps (the second entry) (mediaPresentationDuration="PT0H0M30.000S") seem right. Where does 30.23999 come from?

[nicholas-fr]

@rbouqueau Sorry if it wasn't clear. The total sample duration is the sum of all track fragment header box sample durations: total sample duration = track_fragment_header_sample_duration * track_run_box_sample_count / media_header_box_time_scale

Following the initial comment from Richard, I was looking for deltas between the duration signalled in MPD vs the duration of the actual media content.

The fact that the duration of the content aligns perfectly with the MPD duration for most, but not all test vectors seems strange. Especially for t2 25fps.

Perhaps there a logical explanation for this?

[rbouqueau]

You are still not giving enough details about your computation. Here is what I did for t2@25fps:

Download the DASH session: gpac -i https://dash.akamaized.net/WAVE/vectors/cfhd_sets/12.5_25_50/t2/2022-10-17/stream.mpd dashin:forward=file -o $File$:dynext

Get the box structure: for i in `ls 1/*` ; do MP4Box -diso $i ; done

Get the SampleCount and check for consistency:

rbouqueau@rose:/tmp/wave$ grep SampleCount 1/*.xml | wc -l
378
rbouqueau@rose:/tmp/wave$ grep SampleCount=\"1\" 1/*.xml | wc -l
6
rbouqueau@rose:/tmp/wave$ grep SampleCount=\"2\" 1/*.xml | wc -l
372

The timescale is 12800 and the sample duration is 512.

Do the math: ( 372 * 2 + 6 * 1 ) * 512 / 12800 = 30

@nicholas-fr Where does your 30.23999 value come from?

PS: I've just tried to follow your computation, not taking into account the dts/cts offsets.

[nicholas-fr]

Thanks @rbouqueau, it was due to a calculation error (as you might expect).

I was incorrectly assuming the same sample count for all chunks in a fragment. I'm now using the correct number of samples per chunk. E.g. for t2 25fps where the last chunk per fragment has 1 sample instead of 2. With this corrected calculation, I find the same duration (after rounding as discussed further above) for the MPD mediaPresentationDuration and the total sample duration.

total_sample_duration = 0
for chunk in fragment:
  total_sample_duration  += chunk_sample_duration * chunk_sample_count /  media_header_box_time_scale

Where: chunk_sample_duration = track_fragment_header_sample_duration chunk_sample_count = track_run_box_sample_count

This can be closed, sorry for the confusion, but at least it helped me fix a bug in the validation script.

[rbouqueau]

I think we can close.

[jpiesing]

I think we can close.

Does Eurofins agree?

[yanj-github]

Thanks @nicholas-fr for checking the duration match.

I guess a tiny delta betweeen the mediaPresentationDuration from mpd compared with total sample duration still there and this is caused by the mediaPresentationDuration is being rounded down. Current OF uses mediaPresentationDuration to calculate expected frame which won't be accurate as mediaPresentationDuration is rounded number.

• mediaPresentationDuration="PT0H0M29.996S"
• (60060*14+59059)/30000 = 29.99663333333333333333

We have following 4 options:

1. Change content and round mediaPresentationDuration instead round down
2. Change OF to round up as current mediaPresentationDuration is being rounded down
3. Add 1 frame tolerance at last frame
4. OF change to calculate expected ending frame based on total sample duration (SegmentTimeline, timescale)

Both option 1,2 is not prefact as it fix issue with specific content but will occure on otheres if other content generated differently.

Option 3 will work for all, if everyone happy about the wider tolerance.

Option 4 is preferable from our prospective. We need this for audio content where fragments durations are likey will be vary. We are planning to add this with audio observation which means current version of OF will report fault on the last frame and swiching point of test with frational rate content.

[nicholas-fr]

Sorry if I'm missing something, but why not simply change the tolerance for the rounding error (e.g. ignore differences <0.001s)?

Otherwise, option 4 seems acceptable, especially if such a change is needed anyway. Although it doesn't seem acceptable to have an incorrect error reported for all fractional rate tests in the meantime.

[yanj-github]

Just to clarify:

The problem is not on the duration check it is on the calculation of last frame number. Will be 1 frame less or more. This is what we do on OF. QRn.mezzanine_frame_num == rounddown(cmaf_track_duration * mezzanine_frame_rate)

Where using either rounddown roundup, round all cause issues if the mediaPresentationDuration is rounded differently.

[rbouqueau]

Why not add the half duration of a frame prior to rounding down?

[yanj-github]

Thanks @rbouqueau I think it will be a quick fix which can be applied quickly until we have option 4.

[yanj-github]

I am going to make changes to OF so that: QRn.mezzanine_frame_num == rounddown((cmaf_track_duration + half_frame_duration) * mezzanine_frame_rate)

If no objection and nother else to add on then we are happy to close this ticket.

[rcottingham]

Interim change implemented as per Yan's last comment.

The OF will be updated in a future release to calculate the expected last frame from the total sample duration (SegmentTimeline, timescale).

Issue closed.