Test Streams Needed!

[itsjamie]

Is your feature request related to a problem? Please describe.
One of the aspects that have plagued feature development on hls.js has been the accessibility to streams that have the relevant aspect included in the stream.

It would be great if people were able to generate new or find test assets (with an appropriate license!) that included aspects that the project could add to the CI stack. They don't need to be accessible online, because we can likely find a place to put them for long term project usage.

Currently needed streams

• Modern packaged content (hlsv7+):
  • MPEG-TS - shaka packager / bento4 output
  • CMAF - shaka packager / bento4 output
• Features
  • VOD stream (cmaf) with known inserted EMSGs (Inband Timed Metadata for FMP4 (ID3 within Emsgv1) #2360)
  • VOD stream (cmaf/mpegts) with AES-128 encrypted out of band captions (Closed Captions (WebVTT) aren't displayed in IE11 in some Windows 10 OS when stream is encrypted (AES-128), cueChange event isn't fired in IE11  #3051)
  • Stream with HDCP test content to ensure we get out of the way for external usage.
  • In stream CEA708's marked with INSTREAM-ID in playlist to indicated the Service channel.

You tell us! Come in and ask in Slack if a certain stream type is needed, or submit a PR! Much appreciated ❤️

Describe the solution you'd like
A PR submitted with a test stream added to the unit tests, and what features that stream has in it.

If you can't donate the bandwidth for long-term CI usage, or it isn't your bandwidth to donate, include the stream as a ZIP in the PR, or get in contact on the video-dev Slack in the #hlsjs chat.

Please, only provide streams that you legally are allowed to!

Describe alternatives you've considered
Requiring a test-stream to go along with a feature-request. But this raises the bar for people who request features, it's definitely something that would be nice to receive, but I don't think it's something that should be required. It can be a lot of work to get content available with the correct features and be able to be shared without rights issues.

[tchakabam]

Great topic. I full agree.

We should be much stronger in having much better test-content database with better sorted categories and cases. I think it looks messy and dodgy what we have - to honestly say it - for being the most popular player out there. Not wanting to blame anyone or anything here for it - but I think it is important to point out there is a big deficiency here.

We are usually creating/packaging content for prod or testing in live or VOD with FFmpeg or GStreamer solely. I have never use the "commercial" packagers that you mention, except via integrated into various online SaaS APIs, because it was DRM packaging.

Modern packaged content

Do you need Bento or Shaka-Package to produce the streams you want, or is that an option among others?

What would be (if any) the difference or lacking features to ouput created with FFmpeg (or even GStreamer)?

Can you be more specific in what exactly you want to have for characteristics in the MPEG-TS packaging? What do you mean with hlsv7+ in that context?

[itsjamie]

We should be much stronger in having much better test-content database with better sorted categories and cases. I think it looks messy and dodgy what we have - to honestly say it - for being the most popular player out there. Not wanting to blame anyone or anything here for it - but I think it is important to point out there is a big deficiency here.

Agreed, the sorting and what features each stream is intended to test could definitely be better sorted so we have a clear idea of what is being tested. I will say, the nice part that we do currently do is make sure that issues reported don't regress with adding ticketed streams to the CI setup. I wouldn't want us to lose that with whatever new structure got proposed.

I have never use the "commercial" packagers that you mention, except via integrated into various online SaaS APIs, because it was DRM packaging. Do you need Bento or Shaka-Package to produce the streams you want, or is that an option among others?

The fact that their integrated into the various online SaaS APIs is why I feel like we should have at least a few assets we know are produced using these packagers / encoders / libraries. The vast majority of users who integrate with the various SaaS providers are going to receive something produced with at least one of the four software solutions (ffmpeg, gstreamer, bento4, shaka) in the mix somewhere in the chain 99 times out of a 100.

What would be (if any) the difference or lacking features to ouput created with FFmpeg (or even GStreamer)?

Given the small differences they have in the media they generate it would be good to just ensure we get a modern file from their latest branches to ensure compatability. Example I'm personally aware of is the keyframe metadata in the MP4 metadata that each report is quite different, and on older Chrome versions that bit hard on the migration to using the AVC keyframe data rather than the container metadata. I'm not aware of any current issues that happen, but this is why I felt it was useful.

What do you mean with hlsv7+ in that context?

Wishlist -- Hopefully utilizing features like:

• byte-range playback from a single file
• CEA708s (or 608's in 708) with a EXT-X-MEDIA with a INSTREAM-ID of SERVICE<n>
• HDCP test content that indicates the HDCP level via HLS
• externalized PAT/PMT packets via EXT-X-MAP of MPEG-TS content.
  • not even sure which encoders would support this out of the box, but the extra packets are unnecessary for an MPEG-TS encoded piece of content only destined to be served via HLS and it'd be nice to have tested support for https://tools.ietf.org/html/rfc8216#section-3.2

[robwalch]

The dash.js demo page does a really nice job of organizing samples with the "Stream" select box, it's sub categories and the "provider" credit in the title (ex: "VOD > [Wowza] Static Timeline").

https://github.com/Dash-Industry-Forum/dash.js/blob/development/samples/dash-if-reference-player/app/sources.json

[robwalch]

From @gkatsev in video-dev slack

for streams, we should resurrect https://github.com/video-dev/streams and make it an Actual Thing ™️ that we can share across projects. We have our own list of streams in VHS https://github.com/videojs/http-streaming/blob/main/scripts/sources.json

[gogonowski]

HLS fMP4 Audio-Only with emsg id3v2.4 Timed Metadata Reference Streams

There has been much question on how this is to be implemented.
This is how you do it.

These streams have been produced with StreamS HLSdirect(tm) Live Encoder.

AAC-LC
https://la2.indexcom.com/player/pad/fmp4/hls/128k/program.m3u8

AAC-HEv1
https://la2.indexcom.com/player/pad/fmp4/hls/64k/program.m3u8

xHE-AAC
https://la2.indexcom.com/player/pad/fmp4/hls/40k/program.m3u8

FLAC - Lossless
https://la2.indexcom.com/player/pad/fmp4/hls/FLAC/program.m3u8

This can be viewed in action here:
https://la2.indexcom.com/player/eval
https://la2.indexcom.com/player/pad/fmp4

/greg.
StreamS

[sesse]

AV1+Opus stream

Here's a test of AV1 and Opus together, but in fMP4 (I believe this is standardized and used by e.g. YouTube, although my stream does not have separate audio and video components):

https://storage.sesse.net/av1test/test.m3u8

It's a 720p25 (decimated from 720p60 originally because reasons), with a simple tone for audio that changes a bit halfway through or so. It plays fine in hls.js in at least Chrome 103, assuming that you set "defaultAudioCodec": "opus" (otherwise, autodetection fails and Chrome becomes sad). It also plays fine in VLC and mpv, but somehow, not in Chrome for Android's native HLS handling. I don't know what Safari would make of it, although it would be interesting to find out with the rumored possible AV1 support in the latest betas :-)

[robwalch]

Not a Contribution

Here's a test of AV1 and Opus together

Thank you @sesse,

This might work in hls.js with a variant playlist that includes the CODECS attribute so that the SourceBuffer is initialized with the correct audio codec. Currently HLS.js recognizes AV1 in the media segment and assigns that to the SourceBuffer. For audio, mp4a.40.5 is used as the default which results in an error when appending this content.

Another issue is that the assets do not include CORS headers so testing this sample in a browser requires disabling web security. I only tried it in a session of chrome started using the command:
open -na Google\ Chrome --args --user-data-dir=/tmp/temporary-chrome-profile-dir --disable-web-security

Note there is also this related issue and workaround #4527

[sesse]

I tested a variant playlist at some point, but couldn't get it to work. I might have messed up something, though.

FWIW, I got to test Safari on iOS beta, and it still doesn't play AV1, unfortunately.