Skip to content
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

Encoding / decoding live metadata for a long continuous stream #6736

Open
twilson90 opened this issue Oct 3, 2024 · 1 comment
Open

Encoding / decoding live metadata for a long continuous stream #6736

twilson90 opened this issue Oct 3, 2024 · 1 comment
Labels

Comments

@twilson90
Copy link

What do you want to do with Hls.js?

The problem can be divided in 2, the first does not involve hls.js but I will ask it here anyway if that's ok.

Using ffmpeg I am sequencing many different media files consisting of various aspect ratios together and outputting a long running hls stream, which is served and presented using hls.js.

I would like to encode into the stream dynamic metadata that changes from time to time. Specifically I want to encode the original media's aspect ratio so it can be read by the client and the video can be presented on the front-end video player with less black bars (e.g. if a 4/3 video is encoded on a 16/9 stream but presented in a 4/3 container, you get black bars all around the image, a simple scale can effectively remove the top/bottom black bars if we know exactly what the original image's aspect ratio is).

Considering the segments are short (2 seconds) I suppose I could just append a single aspect ratio value to each segment whenever the segment is requested, but ideally I'd like to embed it in every frame and apply the crop for the end user with frame precision.

Assuming the above is possible, how would I use hls.js to read the metadata from the HLS stream?

The client views the video stream via a web browser. I could establish an additional websocket or http connection to my media server that will provide this metadata, which is a lot simpler but a little less efficient and would incur a delay.

What have you tried so far?

Nothing yet, just doing some preliminary research.

@twilson90 twilson90 added Needs Triage If there is a suspected stream issue, apply this label to triage if it is something we should fix. Question labels Oct 3, 2024
@robwalch
Copy link
Collaborator

robwalch commented Oct 5, 2024

Do you need to do any of that when you have HTMLVideoElement.videoHeight and videoWidth?

https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement/videoHeight
https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement/videoWidth

Video width and height are present in video init segments without additional metadata. HLS.js exposes this for M2TS segments on BUFFER_CODECS ({ video: { metadata: { width, height } } }). This track data applies to all subsequent video segments. HLS.js does not parse this information from mp4 init segments (although it could in a future update). You don't need this data from HLS.js since you can get the videoHeight and videoWidth on the HTMLVideoElement "resize" event independently.

@robwalch robwalch removed the Needs Triage If there is a suspected stream issue, apply this label to triage if it is something we should fix. label Oct 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants