not to download captions if button unpressed

[kuznetcoff777]

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]

@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]

"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]

I suppose it is readonable, isnt it?

[vaage]

@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]

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]

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]

"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]

@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