VLC DASH rate adaptation

[rwy36]

Hello all,

I'm a new forum member, and I've been doing some VLC DASH testing using a recent VLC 2.1.0-git nightly build. The MPDs and the related video assets are from http://www-itec.uni-klu.ac.at/ftp/datasets/mmsys12/ which offers a wide range of videos, video segment lengths and video encoding rates. "Big Buck Bunny" (or BBB) and "Elephants Dream" (or ED) were the two specific video assets used in testing. Both 1 second and 6 second segment sizes were tested. Windows was used as the OS platform for the VLC client side.

The good news is that VLC successfully opens the video stream (which is being served locally from an Apache WWW server with a custom MPD to reflect the BaseURL change). The audio side isn't present for some reason, but that's not our main concern at this point. What's more puzzling is the adaptive rate behavior. Initially a 200Kb video encoding rate is used, then an up-shift to a 500Kb encoding rate is seen within the first second of the stream, but even though much more additional bandwidth is available, VLC DASH doesn't seem to either detect or take advantage of that available network resource and use the higher BW video asset representation (we expected additional 'rate upshifts' to the higher encoding rates to fill the available BW). We can transfer FTP files at a much higher rate from the same content source, so we're confident more network BW is available to VLC in our test environment.

I'm digging into the source to better understand how the DASH adaptive rate shifting works, but I thought it might be worthwhile to share these observations with the broader team. Has anyone else experienced this VLC DASH behavior? Is it possibly a setup or configuration problem within VLC?

Thanks everyone,

Bill

[Jean-Baptiste Kempf]

Dash code is in development, so it might be a bug. You probably will have to find it...