Buildbot scte35 id3 markers

[rbouqueau]

• M2TS demux:

  • [DONE] Handle metadata in PES and Sections as it was done for TEMI in the AdaptationField.
  • [DONE] ID3/meta handling shall be more generic for proper inspection.
  • [DONE] Convey as a property.
  • [DONE] Make sure there is no duplication between the PID (when section or PES) and properties. It may be problematic when remuxing.
  • [TODO Make configurable which TS metadata track goes into which CMAF track #2831] Make configurable which TS metadata track goes into which CMAF track, for instance, based on the TS PID.
  • [TODO Question about unregistered packet properties #2830] id3 PES streams may not have any PTS. However Filters replace properties (instead of merging them) when submitting several with the same name. This leads to id3 losses.

• rfadts:

  • [TODO rfadts: props from the first packet are not forwarded #2829] Props from the first packet are not forwarded.

• Inspect:

  • [DONE] generic dump of all SCTE-35 commands.
  • [DONE] detail for splice_time/time_signal and splice_insert (which are the only two commands in my samples).
  • [DONE] test dump from timed metadata track: https://dashif-documents.azurewebsites.net/Ingest/master/DASH-IF-Ingest.html#interface-1-timed-metadata (to be tested with self-generated 23001-18 samples).
  • [DONE] how do will still display SCTE-35 after converting the M2TS PID to some pck property?

• M2TS mux:

  • [DONE] Re-add SCTE PID from property.
  • [DONE] How to avoid having two PMTs? Current implement defines a fake pck to convey SCTE-35 presence, but still too late since configure_pid still happened (and first PMT without SCTE-35 was generated) => put a static property when dmx PMT.
  • [WONTDO] Ensure duplicated properties are only processed once. We should put an id to the prop e.g. using it as a namespace or #ServiceId. The simplest heuristic may be to attach the property to only one media type.

• isom_mux:

  • [DONE] the current implementation starts a fragment when an 'emsg' box is inserted because it shall be right before the 'moof' box. Add option to wait for the next fragment. (PS: done differently).
  • [DONE] 23001-18 event message track.
  • Maybe not relevant?
    • [WONTDO] CTA DASH-HLS interop: "CMAF Fragment boundaries SHALL be created at all splice points".
    • [WONTDO] several messages in the same 'emsg' box (i.e. same message_data[] array) shall be separated with '0x0A'.
  • [DONE] when the duration is unknown the event_duration should be set to 0XFFFFFFFF.
  • [DONE] check brands, cf in dasher.

• Dasher:

  • [TODO SCTE-35 manifest support #2828] SCTE-35: add <InbandEventStream schemeIdUri="urn:scte:scte35:2013:bin"></InbandEventStream> => DASH-IF recommends xml+bin.
  • [TODO SCTE-35 manifest support #2828] Add HLS #EXT-X-CUE-IN and #EXT-X-CUE-OUT.
  • [DONE] investigate brands (ok) and URNs (xml+bin).
  • [DONE] 23001-18 (done except write the essential/supplemental properties since I found none in our test cases).

• Metadata injection new module (likely jsf):

  • [WONTDO as part of this PR] Insert SCTE-35.
  • [WONTDO as part of this PR] Insert KLVs (which translates into emsg boxes). Specify each track.

• flist:

  • [WONTDO as part of this PR] try to generate markers with flist.

• dec_scte35:

  • [DONE] initial sparse implementation
  • [DONE] add support for empty samples
  • [DONE] forward duration + pto
  • [DONE] rewrite segmented emib boxes (maintain an internal timeline)
  • [DONE] emeb boxes should be merged, at least when dashing
  • [TODO] merge emib (with correct duration one instead of 85cb9b2): waiting for UTs to be merged (Buildbot embedded unittests #2755)

[aureliendavid]

uint8_t currently doesn't build on windows

maybe we should add an #include <stdint.h> in the windows part of setup.h?

or maybe we should just use the u8 type instead?

[rbouqueau]

I will use u8, thanks! FYI this is just a draft PR ATM. I'm not even sure we will not cherry-pick the commits on here.

[jadarve]

Does it make sense to write pck->data_len before pck->data so that other filters that parse this data know how many bytes to read? For instance here

[rbouqueau]

We know the size of the property. That being said what would happen if several properties are pushed simultaneously? The spec says that "several messages in the same 'emsg' box (i.e. same message_data[] array) shall be separated with '0x0A'." Is it a realistic use-case?

[jadarve]

We know the size of the property. That being said what would happen if several properties are pushed simultaneously?

The 271 size of the Nielsen ID3 tag is indeed known. However, if we want to push other ID3 tags of unknown size, then writing the data_len is needed to create the emsg box correctly.

The spec says that "several messages in the same 'emsg' box (i.e. same message_data[] array) shall be separated with '0x0A'." Is it a realistic use-case?

I haven't seen this edge case in the tests I have run so far. It can be omitted for now, I think.