[question]video-audio bitrate correlation

[kuznetcoff777]

Hello! Here is the issue:
3 video bitrates that has their own audio bitrates (for example 4000---256; 2000---128; 1000---64)
Player takes video and audio separately, so i got that moment:
I watch 1000 video bitrate (so buffer keeps about 12-20 seconds) and audio takes 256kbit fragments. So by logic of player it assumes this audio bitrate as the top, so player downloads audio fragments for 60 seconds ahead).
So i suppose it is not good. Is there any way to correlate video-audio bitrates, for my example, that when plays 4000 video then it have to take only 256 audio and so on (2000---128; 1000---64)?

[dsparacio]

There is no way to do that in the current code base. They are , as you pointed out, completly independent. Easiest way to solve this is for Dash.js to re-allow Muxed content.

[kuznetcoff777]

@AkamaiDASH Sorry, i did not get about "to re-allow Muxed content". Google search for "dash.js muxed content" gives nothing reasonable.

[dsparacio]

No problem, let me explain. We use to allow single fragment audio/video (muxed content) in dash.js but @ v1.4 we stopped since it was out of compliance with the MPEG DASH guidelines. We have talked about lifting this restriction with a settable API flag to work in non-compliance mode.

[kuznetcoff777]

@AkamaiDASH
I got your idea but what exact flag is responsible for this?

So i have another proposal.
As i described above sometimes i see that audio fragments get downloaded faster then video fragments, so thats why i see that situation:
video-fragment-1(downloaded)
audio-fragment-1(downloaded)
video-fragment-2(still downloading)
audio-fragment-2(downloaded)
audio-fragment-3(downloaded)
audio-fragment-4(downloaded)
audio-fragment-5(downloaded)
audio-fragment-6(downloaded)

So while player attempting to download video-fragment-2, other audio fragments already downloaded - so while audio was downloading - bandwith was taking for them - instead of let this bandiwth be used for downloading video fragment more faster. So in this situation player stalls, becuase video frag still not downloaded.

I suppose it would be better to implement logic for video-audio downloading: for audio frags will not be downloaded more then one video ahead, for example:
video-fragment-1(downloaded)
audio-fragment-1(downloaded)
video-fragment-2(still downloading but faster)
audio-fragment-2(downloaded)
audio-fragment-3(downloaded)

[kuznetcoff777]

@AkamaiDASH, please, comment, and maybe reopen an issue for "Feature Enhancment"

[dsparacio]

Others have mentioned the unevenness.

Only an issue with incredibly slow connection but still an issue nonetheless. I agree we should balance it a bit more. We use to have an incredibly complex way for this and I think there is a very easy way to solve. We just need to manage the buffer targets individually for audio and video. Possibly divide current video bitrate by current audio bitrate * seg duration to set an audio target. I will mark this a enhancement and try to get into next release.

[dsparacio]

@kuznetcoff777 and @KarishmaBagga I have implemented a very simple yet very effective solution for this and will commit it soon. Basically I always set the audio buffer target to the video's buffer length allowing video to grow larger first and have XHR priority. few lines of code was all that was needed. I will share soon.

[dsparacio]

Ok i have added code to balance audio and give video priority. Not much testing yet but I think it will be good. I will test next week but you can find code here
https://github.com/AkamaiDASH/dash.js/tree/BugFixes