Dash-Industry-Forum / DASH-IF-Conformance

This repository provides the source code for MPEG-DASH/DASH-IF Conformance Software/Validator. It has been extended according to further standards, such as CMAF, DVB-DASH, HbbTV, and CTA WAVE.
https://conformance.dashif.org/
Other
66 stars 27 forks source link

HbbTV profile gives an error "trun run box shall allow negative composition offset (v1 expected but v0 found, on audio segments)" #688

Open Murmur opened 10 months ago

Murmur commented 10 months ago

See gpac issue, a new parameter to force trun.version=1 on audio segments: https://github.com/gpac/gpac/issues/2586 they should not complain, trun v1(trun.version=1) is only mandatory for video tracks in cmf2 brand.

FFMPEG is writing video=v1, audio=v1 segments, MP4BOX is writing video=v1, audio=v0 segments. Validator does not complain on ffmpeg segments but do complain on mp4box segments.

HbbTV specs too strict about "forcing" V1 on video+audio segments? Specs wording is not clear enough? Validator gives a false error?

MP4BOX test content video=v1,audio=v0 https://refapp.hbbtv.org/videos/00_llama_h264_v8/manifest_1080p_24s.mpd

HbbTV ts_103285v010301p.pdf spec Following are constraints on the Player with respect to ISO BMFF format(=mp4 file): Players shall support the usage of the track fragment run box ('trun') with negative composition offsets (trun.version=1 format). Negative composition offsets were added to ISO/IEC 14496-12 in Amendment 3, which is included in ISO/IEC 14496-12 in the Segment can be determined by adding composition offsets stored in the Track Run Box (trun). Negative composition offsets in a V1 trun box should be used to adjust the presentation time of the first presented sample (V1=version 1 format).

Validator error: [x]segment [x]hbbtv segment validation: ## ### HbbTV check violated: Section E.3.1.1. "The track run box (trun) shall allow negative composition offsets in order to maintain audio visual presentation synchronization", but unsigned offsets found.

rbouqueau commented 10 months ago

There is a "should" in HbbTV. So the code should be modified accordingly: error for video, warning otherwise.

See also unresolved #446.

RufaelDev commented 10 months ago

Hey all, I think the negative composition time is only needed in video tracks in certain cases (when negative composition times are needed), so this is a player requirement not a content requirement. If you have a simple GOP in decode order I P P P for example you dont need trun v1 even for video. I raised this issue also in MPEG for CMAF 9.2.5 as that clause assumes that negative composition time is required, but this is not always the case such as in simple group structures. So supporting trun v1 in my opinion is a player requirement not a content requirement. Of course when you need negative composition you can use it but CMAF also adds the option of using edit list. I see the HbbTV text implies that trun v1 shall be used but the text does not literally state it. Content provider may default to v1 trun but I dont think it is a requirement.

So my point is if you read the text carefully you will see that it is a player requirement not a content requirement, as your content may not require negative composition time offsets

so even for video i dont think using trun v0 should raise an error.

Murmur commented 9 months ago

trun v1 negative composition time | CMAF also adds the option of using edit list.

@RufaelDev Slight offtopic but how do trun.ver1=allow negative composite time(no edit list tables) VS use edit list tables for negative time(+trun.ver0) decision should be evaluated, pro+/con- issues, player implications and compatibility etc?