Live stream letterboxed top and bottom on Hisense TV

stuartflanagan commented 4 years ago

What version of Hls.js are you using?

0.13.0

What browser and OS are you using?

Hisense TV V0000.01.00A.J0727

Test stream:

Checklist

[x] The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
[ ] The issue occurs in the stable client on https://hls-js.netlify.com/demo and not just on my page
[ ] The issue occurs in the latest client on https://hls-js-latest.netlify.com/demo and not just on my page
[x] The stream has correct Access-Control-Allow-Origin headers (CORS)
[x] There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

Please provide clear steps to reproduce your problem
If the bug is intermittent, give a rough frequency

Expected behavior

Video should fill full viewport

Actual behavior

Live video starts and displays fullscreen for a few seconds. After this bars appear at the top and the bottom of the screen. This does not happen when using just the video element without HLS.JS. It also does not happen with vod content only our Live manifests.

Console output

Do not have access to developer console on the TV

This may be an issue with our manifests but would like to know if this is something that has been experienced by you please.

stuartflanagan commented 4 years ago

Sorry this is a hard one to apply the full checklist to as it is only happening with a Live HLS manifest on Hisense model TVs using Chromium. Let me know if I can supply any extra information. If it helps the letterboxing comes and goes but is there for the most part.

robwalch commented 4 years ago

Please provide a sample of the manifest and screenshots, or pictures; Whatever you can provide to confirm that the aspect ratio for all renditions in the same.

Can you preform any kind of debugging on the Hisense TV? I do not have access to one of these devices so I can't really help much. The first thing to confirm is the video element size and properties. This could be something the browser is doing, or your stream and have nothing to do with hls.js.

stuartflanagan commented 4 years ago

Hi @robwalch thanks for getting back to me.

Our manifests are protected but it would be great to see if you can see anything in them that may be an issue.

The stream plays back without letterboxing when not using HLS.JS on the TV only when using HLS.JS do we get this issue. We are using HLS.JS as a way to support in band HLS captions.

I will get you a TS segment and manifest

stuartflanagan commented 4 years ago

@robwalch here is a segment manifest and a TS file from that segment.

Archive.zip

stuartflanagan commented 4 years ago

Also please note this is not an Android TV issue it is an HTML5 video issue. Platform is SmartTV

robwalch commented 4 years ago

Also please note this is not an Android TV issue it is an HTML5 video issue. Platform is SmartTV

@stuartflanagan I labeled the issue Android TV because my understanding is that Hisense's SmartTV platform is based on Android. I don't have access to one of these TVs but maybe we can identify similar issues on other Android based device browsers.

There is no "SmartTV" platform or single operating system and we don't call these "HTML5" video issues either. Hls.js is an MSE video player (HTML5 video usually refers to setting the src if a video tag) . What we try to capture in bug tickets is OS, Browser and the versions of each. The android tv label means you have an issue on a TV that runs Android OS.

stuartflanagan commented 4 years ago

Hi @robwalch Most of the Hisense TVs in circulation are running the SmartTV version not Android. The Manifests are being set on the Source element of the Video Tag. EME is present as we have successful playback on these TVs just this letterboxing issue. We have HLS.JS playing on Samsung and LG as well to allow inband captions for live streams.

robwalch commented 4 years ago

The Manifests are being set on the Source element of the Video Tag

Can you provide an example?

It sounds like you should not be using hls.js in that case. Just like if you were playing HLS streams in Safari using video.src = m3u8 or <video><source src=m3u8> you would not use hls.js, but interface directly with the video element to control playback.

OrenMe commented 4 years ago

Hisense runs an sos called Vidda, which is html5 based and their latest release includes a fairly up to date chromium browser engine. I’m not aware that they support HLS natively so things might got “lost in translation”. The browser does support MSE and EME. This applies to later versions of vidda and the ones I stumbled upon are newer then the ones the OP talks about.

Could it be that not all renditions of the manifest are at same aspect ratio and hlsjs jumps to one of those? Also, I’m not sure if mentioned, this issue doesn’t occur on chrome desktop? Try the demo and go manual one by one on each rendition and see if you also see the issue.

stuartflanagan commented 4 years ago

Thanks @OrenMe and @robwalch, The TVs do support HLS natively but not in-band subtitle decoding and display. Hence why we are using HLS.JS for playing Live streams only.

I did provide a sample Manifest segment and TS file.

I think I asked this in an earlier comment but is there a way to just use HLS.JS to just do the captions part? And not do the video?

Thanks for your help.

robwalch commented 4 years ago

is there a way to just use HLS.JS to just do the captions part? And not do the video?

Hls.js is cannot just do captions. The subtitle stream/track controllers are open-source and you could try adapting them to your solution but you are on your own there.

I've never seen a browser (html5) implementation of HLS that only supported video and couldn't handle captions however, so you might want to test your app in Safari and make sure you can get captions working there. Examining video.textTracks would reveal if the browser is parsing HLS subtitle tracks or 608/708 captions into a textTrack which can be shown on the device.

stuartflanagan commented 4 years ago

Hi @robwalch thanks for this. Yes it is a bit of an obscure issue. Unfortunately some of the TVs only support older versions of HLS specification and it is not uncommon for HLS.JS to be used to fill the gap when captions are required for a TV video element that does not have support for in band captions. Our only issue is with one TV manufacturer that is letterboxing the video. These TVs do handle EME so we will switch them to MPEGDASH DRM soon. I have attached a photo of the actual issue.

PHOTO-2020-03-30-10-25-59 copy

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] commented 4 years ago

This issue has been automatically closed because it has not had recent activity. If this issue is still valid, please ping a maintainer and ask them to label it accordingly.

video-dev / hls.js