-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test Streams Needed! #3065
Comments
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.
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 |
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.
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.
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.
Wishlist -- Hopefully utilizing features like:
|
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"). |
From @gkatsev in video-dev slack
|
HLS fMP4 Audio-Only with emsg id3v2.4 Timed Metadata Reference StreamsThere has been much question on how this is to be implemented. These streams have been produced with StreamS HLSdirect(tm) Live Encoder. AAC-LC AAC-HEv1 xHE-AAC FLAC - Lossless This can be viewed in action here: /greg. |
AV1+Opus streamHere'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 :-) |
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: Note there is also this related issue and workaround #4527 |
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. |
👁️ |
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
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.
The text was updated successfully, but these errors were encountered: