Re: Audio portion of dash downloads slow
> On 14 Mar 2022, at 03:02, Nick Payne wrote: > > No, here's an example of the quite different speeds for the audio and video > portions of a dash download - the 158Mb of audio took 31 This has always been the case, though it is more visible now with 1080p since DASH is its default format, unlike 720p and others. There is no reason to expect that audio and video would download at the same speed. Video may be throttled as well, and there can be cases where the video stream is slower than the audio. Those media streams are intended for real-time playback, and even the low-ish speeds you get are adequate for that purpose. Audio is only a few percent of the total payload, so it only needs a few percent of the total throughput to keep up with the video. In your example, the audio actually downloaded at 5x real-time, which was about twice that of the video. Anyway, that has nothing to do with GiP. > A second, and quite unrelated problem is that the estimated file sizes for > fhd 1080p downloads are always too high by a factor or three or Read the release notes ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audio portion of dash downloads slow
Hi, Jeremy wrote: > > INFO: Downloaded: 158.00 MB (02:42:25) [2538] in 00:31:30 @ 0.67 Mb/s units(1) is handy for that kind of thing. $ units -1v '158 MiB / (31 min + 30 s)' Mibit/s 158 MiB / (31 min + 30 s) = 0.66878307 Mibit/s -- Cheers, Ralph. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audio portion of dash downloads slow
On 2022-03-14 03:02, Nick Payne wrote: No, here's an example of the quite different speeds for the audio and video portions of a dash download - the 158Mb of audio took 31 minutes to download... It was 158 MB of audio data which is at least 8 times larger (more than 8* if it includes transfer protocol data as well as the audio data). Maybe you know that & are just being sloppy with your notation, but if you use the wrong forms you'll likely get confused since the stats listed carefully make use of both. Look at this line: INFO: Downloaded: 158.00 MB (02:42:25) [2538] in 00:31:30 @ 0.67 Mb/s (dashfhd1/cf) [audio] which has the total quantity and also the Mbps download speed. That is download speed in Bps (Bytes per sec) was 158 * 1024 * 1024 / ((31 * 60) + 30) = 87658 Bytes / sec which is at least (87658 * 8) = 701264 bps (bits/sec) which is 701264 / (1024 * 1024) = 0.6687 Mbps (ie the 0.67 Mb/s shown). -- Jeremy Nicoll - my opinions are my own ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audio portion of dash downloads slow
On 14/03/2022 09:30, VeniVidiVideo wrote: On Mar 13, 2022, at 5:45 PM, Nick Payne wrote: When I download a program with GiP using dash rather than hls, the initial separate download of the audio always comes down at only somewhere between 5% and 10% of the speed that I get when the video portion of the download is happening. Do other users see the same? This is with the latest v3.29 GiP. Did the audio actually download in much less time than the video, overall? So you're mainly concerned about the reported download speeds? If so, it's possible that the audio, being much smaller than the video, is having its download speed calculated from many fewer samples, so it is less accurate. Its measurement would also be drastically more affected by any startup and/or shutdown overhead that is included in the download time. No guarantees, but as long as the audio is actually downloading in substantially less time than the video the problem may simply be in how these speeds are being calculated. No, here's an example of the quite different speeds for the audio and video portions of a dash download - the 158Mb of audio took 31 minutes to download, and the 3536Mb of video took 1hr 2min, which means that the video portion downloaded at just over 14 times the speed of the audio download. If the audio had downloaded at the same speed as the video, the entire download would have completed in about 2/3 of the time it actually took. I see the same audio/video download speed difference for every dash download. A second, and quite unrelated problem is that the estimated file sizes for fhd 1080p downloads are always too high by a factor or three or four - unlike 720p downloads, where the estimate is usually accurate within 20% or so. Again, see the example below, where GiP's estimate for the video size was 10339Mb, but the actual size for the successfully completed download was 3536Mb. I think every fhd download I've done has had the same wildly inaccurate estimated size. = INFO: Downloading tv: 'Snooker: Welsh Open: 2022 - 14. The Final - Part 2 (m00158vr) [original]' INFO: Trying 'dashfhd1' mode: attempt 1 / 3 INFO: ffmpeg version string = 4.3.3-0+rpt2+deb11u1 INFO: ffmpeg version number = 4.3 INFO: File name prefix = Snooker_Welsh_Open-s15e14-The_Final_-_Part_2 INFO: Begin downloading at: 0.00 MB (00:00:00) [1] INFO: Downloaded: 158.00 MB (02:42:25) [2538] in 00:31:30 @ 0.67 Mb/s (dashfhd1/cf) [audio] INFO: Begin downloading at: 0.00 MB (00:00:00) [1] 3.3% 341.30 MB / ~10339.76 MB (00:09:01 / 02:42:25) [ 141 / 2538] @ 9.4 Mb/s ETA: 02:22:13 (dashfhd1/cf) [video] [...] INFO: Downloaded: 3536.83 MB (02:42:25) [2538] in 01:02:04 @ 7.60 Mb/s (dashfhd1/cf) [video] INFO: Converting to MPEG-TS [...] = Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audio portion of dash downloads slow
On Mar 13, 2022, at 5:45 PM, Nick Payne wrote: > When I download a program with GiP using dash rather than hls, the initial > separate download of the audio always comes down at only somewhere between 5% > and 10% of the speed that I get when the video portion of the download is > happening. Do other users see the same? This is with the latest v3.29 GiP. Did the audio actually download in much less time than the video, overall? So you're mainly concerned about the reported download speeds? If so, it's possible that the audio, being much smaller than the video, is having its download speed calculated from many fewer samples, so it is less accurate. Its measurement would also be drastically more affected by any startup and/or shutdown overhead that is included in the download time. No guarantees, but as long as the audio is actually downloading in substantially less time than the video the problem may simply be in how these speeds are being calculated. - larryy ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
