search

shaka-project / shaka-player

JavaScript player library / DASH & HLS client / MSE-EME player
Apache License 2.0
7.07k stars 1.33k forks source link

not to download captions if button unpressed #1058

Closed kuznetcoff777 closed 6 years ago

kuznetcoff777 commented 6 years ago

Have you read the FAQ and checked for duplicate issues:yes

What version of Shaka Player are you using:latest

Can you reproduce the issue with our latest release version:on demo

Can you reproduce the issue with the latest code from master: on demo

Are you using the demo app or your own custom app: demo

If custom app, can you reproduce the issue using our demo app:

What browser and OS are you using: win7x64+chrome

What are the manifest and license server URIs:https://shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-demo-assets/sintel-mp4-wvtt/dash.mpd;lang=ru (you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)

What did you do?opened stream and unpressed CC button

What did you expect to happen? player does not download captions

What actually happened? player downloads captions anyway

vaage commented 6 years ago

@kuznetcoff777 We always stream subtitles so that when someone enables them, they are immediately present. If we did not do this, they would have to wait for the subtitles to be available. Since subtitles consume so little bandwidth we feel that this minor cost in bandwidth usage is a minor price to pay for user experience.

kuznetcoff777 commented 6 years ago

"Since subtitles consume so little bandwidth we feel that this minor cost in bandwidth usage is a minor price to pay for user experience." - yes, from user side it is not so bad situation. But from streamer side... I want to mention that in DASH there is a good decision was made to divide init.mp4 and mp4. Init file in our case is about 1KB, not so big, but in long-term perspective it is economy of traffic. In our case caption file minimum size is 32KB. So, for example, if we have 100000 of users that dont need captions and they watch stream for 1 hour (10sec fragments) - we get excess traffic ((32/1024)100000 60 *60/10) = 1125000MB = 1,125TB - too huge Moreover we get excess req/s for edge servers.

" If we did not do this, they would have to wait for the subtitles to be available." - i suppose it is not so worse situation if user will wait a little for new subs. Or it will be good if if cc button pressed then caption must be downloaded immediately and showed to user.

Otherwise I propose to make configurable parameter - by default player fetches captions as you described, and if it is off, then player start to fetch captions only after CC button is pressed.

kuznetcoff777 commented 6 years ago

I suppose it is readonable, isnt it?

vaage commented 6 years ago

@joeyparrish Is not in the office right now. It is his call. Once he is back in the office I will talk to him about it.

karlovich commented 6 years ago

Hi gents,

The same situation in our application, but our fragment is 2 sec and subs chunk size is about 32kb (TTML base64 images). Ability to download subs by user selection could save much CDN traffic and improve network performance and playback quality as a result.

@vaage @joeyparrish, any updates on this?

joeyparrish commented 6 years ago

I must be unfamiliar with this situation. Please forgive my ignorance.

@karlovich, you have 2s segments, and each 2s of subs is 32kB? That would be about 128 kbit/sec, which is as much bandwidth as some audio streams. I did not anticipate this. Your TTML contains base64-encoded images instead of actual text?

@kuznetcoff777, you have a minimum caption file size of 32kB? Why is this a minimum? Where does this limitation come from?

I am not sure how much work it will be to change this. A configurable parameter would not make it any easier to implement, so I'm not sure if that would make sense for us to add one.

We don't want anyone to waste 11 MB per person per hour on unused subs, so I will schedule this enhancement for the current milestone. Thank you for being patient with us while we try to understand the problem better.

kuznetcoff777 commented 6 years ago

"you have a minimum caption file size of 32kB? Why is this a minimum? Where does this limitation come from?" It is not a limitation, i just watched directory where fragments are situated and found mimimum size of our 10-sec caption fragments.

"We don't want anyone to waste 11 MB per person per hour on unused subs, so I will schedule this enhancement for the current milestone. Thank you for being patient with us while we try to understand the problem better." - it will be perfect, thanks!

karlovich commented 6 years ago

@joeyparrish

Your TTML contains base64-encoded images instead of actual text?

Yes

you have 2s segments, and each 2s of subs is 32kB?

Depends on content inside. 32kB is max size but many chunks have two images inside.

That would be about 128 kbit/sec, which is as much bandwidth as some audio streams.

Seems yes, one more audio stream in background.

Please see possible variations: 30.4 кВ (two images inside) TTML-base64-m4s-Two-Images-Inside.txt 16.2 кВ (one image inside) TTML-base64-m4s-One-Image-Inside.txt 0.68 kB (empty) TTML-base-64-m4s-Empty.txt

joeyparrish commented 6 years ago

We are going to try to tackle this as part of v2.3. Depending on how complex it turns out to be, it may have to be deferred until v2.4.

joeyparrish commented 6 years ago

This will appear in v2.3, and is available in the nightly build now: https://nightly-dot-shaka-player-demo.appspot.com/demo/

kuznetcoff777 commented 6 years ago

@joeyparrish Opened stream https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-demo-assets/sintel-mp4-wvtt/dash.mpd;lang=ru

But when button is unpressed it still fetches subtitles, screenshot is attached wtt

kuznetcoff777 commented 6 years ago

@joeyparrish @michellezhuogg Guys, reopen ticket, problem is not solved!!!

joeyparrish commented 6 years ago

We have been looking into the issue, but forgot to reopen the ticket. We should have it fixed soon. Thanks!

joeyparrish commented 6 years ago

This should be fixed in the nightly build now: https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-demo-assets/sintel-mp4-wvtt/dash.mpd;lang=ru

All fixes for this will appear in the v2.3 release.

itaykinnrot commented 6 years ago

Our use case is that the captions are always hidden since we want to render them ourself (styling that will work cross browser...) and this "fix" just stop us from doing that. can we change it to not disabled?

TheModMaker commented 6 years ago

@itaykinnrot See #1332. We'll be adding a configuration for this. Also note that you could write your own TextDisplayer to use our text pipeline and then still use player.setTextTrackVisibility.

joeyparrish commented 6 years ago

I think the intended way for you to render them yourself is to use the TextDisplayer plugin interface. See also the default implementation, SimpleTextDisplayer, which delegates to the browser's native rendering.

I'm not sure of the details of what you are doing, but you may also be interested in bug #1332. In that isue, we realized that in order to support native controls, we need a new option to stream without regard for the display state. This may also help you.