Problem downloading Disneydags from SVT Play

[andersm1019]

svtplay-dl versions:

3.1-5-gcb3612b

Operating system and Python version:

Raspbian GNU/Linux 10 (buster) Python 3.7.3

What is the issue:

Problems downloading "Disneydags" from SVT Play. Video is OK, but audio is truncated. Only a few minutes of sound at the beginning are downloaded. Subtitles are not downloaded. "WARNING: Can't download subtitle file". svtplay-dl -S --verbose https://www.svtplay.se/video/30315858/disneydags/disneydags-sasong-1-avsnitt-1

log.txt

[spaam]

interesting 🤔

[SYSophie]

@andersm1019 seems to be a publishing issue to me. DASH isn't available at all and the soundtracks spits out various error-code such as miss-matching sample rate etc... I have tried to fetch a variety of the soundtracks and they have all given different error codes.

Some of them gives me 3sec another one gives me 3minutes, some won't even start and try and download.

I would suggest contacting SVT so that they can troubleshoot this :)

[SweDennis]

All confirmed on my end, still works in streaming the episode, no loss of sound then ... oh well. :-D

[andersm1019]

Could this be a deliberate attempt to throw downloaders off-track, possibly because of some Disney requirements? "Doctor McStuffins", which was published today, and is also from Disney, has the same odd behavior. https://www.svtplay.se/doktor-mcstuffins

[SYSophie]

Could this be a deliberate attempt to throw downloaders off-track, possibly because of some Disney requirements? "Doctor McStuffins", which was published today, and is also from Disney, has the same odd behavior. https://www.svtplay.se/doktor-mcstuffins

This also lacks DASH, which will lead to playback issues for users and SVT have to strive for compatibility.

[spaam]

looking at the web browser. its using the different HLS than the script chooses 🤔

[SweDennis]

As you said before ... "Interesting ..." Another somewhat interesting observation is that youtube-dl fails in downloading this, in exactly the same way, sounds stops for that download as well, at the same time stamp ... Usually, if one fails the other works, or different behaviour somewhere, but not so this time.

/Dennis

[pythonuser3856]

I noticed a similar error some time ago, see closed issue #1307 A couple of days later there was no error anymore, download was successful with full sound, and I closed the issue assuming that it was caused by a temporary error by SVT.

[spaam]

they are using fragmented mp4 (fmp4) i hls. i guess something is wrong somewhere when the script download the files.

[spaam]

pretty weird. using other hls playlists , it always stop at that 3min 28s . even with ffmpeg

[CBennerstedt]

I observed something. I made a copy of the two .ts files before they were automatically merged and it seems the audio.ts file does have the correct audio all the way. However the video ts file contains truncated audio (it gets cut off around 3 minutes 28s in), which I guess is what the resulting .mp4 ends up using.

[spaam]

interesting observation. 🤔 if that is the case, with some ffmpeg arguments should be possible to fix it

[hacker112]

So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files.

Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?

[spaam]

i guess map would be a thing to fix it to tell ffmpeg which audio and video track to use for the end file.

[spaam]

like something ffmpeg -i video.ts -i audio.ts -map 0:1 -map 1:1 -c copy -bsf:a aac_adtstoasc output.mp4 if the first track in video.ts is the video and the first track in audio.ts is the audio. if the tracks is different , just run ffmpeg -i file.ts to see which one is correct :)

[UWTD]

So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files.

Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?

Sorry but i do not think this is a solution You will get: Invalid data found when processing input

[andersm1019]

So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files. Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?

Sorry but i do not think this is a solution You will get: Invalid data found when processing input

MKVToolNix will happily mux the video and audio into an MKV-container. Once you've done that, you can use ffmpeg to remux it into an MP4-container if that's what you prefer.

Also, I've made some instructions for how to manually download the subtitles for now: https://www.dubbningshemsidan.se/forum/index.php?topic=3212.750

[SYSophie]

So a workaround right now would be to temporarily rename the ffmpeg-binary (since it seems like there is no option to make svtplay-dl skip the merge (or remux)) then run the command so that it keeps the .ts-files. Then figure out what ffmpeg-command is needed merge the files correctly. @spaam: Any idea of what arguments could help?

Sorry but i do not think this is a solution You will get: Invalid data found when processing input

MKVToolNix will happily mux the video and audio into an MKV-container. Once you've done that, you can use ffmpeg to remux it into an MP4-container if that's what you prefer.

Also, I've made some instructions for how to manually download the subtitles for now: https://www.dubbningshemsidan.se/forum/index.php?topic=3212.750

Yes, but the audio tracks are still malformed....Which might be the reason why DASH-streams isn't available.

[pythonuser3856]

For what it's worth; The issue is at hand with the movie "Valyrie"/"Valkyria" when you choose to retrieve a version with 2-channel sound. If you instead choose to get a version "h264-51" the sound is complete and correct. I know it's not so much of a help with the items in this thread since these do not have the 5.1 option, sorry.

[spaam]

🤔 this is so weird. when i use ffmpeg to download its the same issue. when i use vlc it works.

[andersm1019]

Well, we can complain all we want that there's something wrong with SVT's streams. Still, it seems that there are no problems playing these programs in web browsers or apps, and that's really all that SVT can be expected to support. The errors may very well be intentional to discourage downloading attempts. Remember, this is Disney, and they may have their own agenda.

Since the first episode of Disneydags is about to be taken down by SVT, it was critical to find a workaround. I can live with that, but it would of course be more convenient if svtplay-dl could download the episodes without any special tricks.

As for the subtitles, there IS a problem that SVT has confirmed, but they have yet to fix it.

[SYSophie]

Well, we can complain all we want that there's something wrong with SVT's streams. Still, it seems that there are no problems playing these programs in web browsers or apps, and that's really all that SVT can be expected to support. The errors may very well be intentional to discourage downloading attempts. Remember, this is Disney, and they may have their own agenda.

Since the first episode of Disneydags is about to be taken down by SVT, it was critical to find a workaround. I can live with that, but it would of course be more convenient if svtplay-dl could download the episodes without any special tricks.

As for the subtitles, there IS a problem that SVT has confirmed, but they have yet to fix it.

The thing is that they don't play fine, on all devices,systems or browsers. Since there are no DASH-streams available.

I have been in contact with SVT thru email about the lack of DASH streams and they have acknowledged the issue but they are unable of providing. a timeline of when it will be fixed.

also as I have pointed out before there are issues with the audio tracks which ffmpeg correctly raises and therefor fails. This is a consistent issue that is repeated with all episodes. So there might and probably is an issue with SVT's new compressions model that they use for animated content.

[andersm1019]

The thing is that they don't play fine, on all devices,systems or browsers. Since there are no DASH-streams available.

I believe you. Which devices, systems and browsers have problems?

I have successfully played the Disneydags and the Doc McStuffins shows in several browsers like Firefox, Chrome and Edge, and in the apps on iPhone, iPad and Apple TV. Also, using the unofficial SVT Play add-on for Kodi on Raspberry Pi.

Everything works fine, except the subtitles, which only seem to work at random.

I have been in contact with SVT thru email about the lack of DASH streams and they have acknowledged the issue but they are unable of providing. a timeline of when it will be fixed.

Thank you! I too would contact SVT if I could find a system where the shows can't be played. I've been in contact with them regarding the subtitle issue. They have even claimed that problem to be solved, but then realized that it wasn't the case.

also as I have pointed out before there are issues with the audio tracks which ffmpeg correctly raises and therefor fails. This is a consistent issue that is repeated with all episodes. So there might and probably is an issue with SVT's new compressions model that they use for animated content.

Are there other animated shows that are affected in the same way? I thought it was only the two Disney shows because of special requirements by Disney to protect their content.

[SYSophie]

The thing is that they don't play fine, on all devices,systems or browsers. Since there are no DASH-streams available.

I believe you. Which devices, systems and browsers have problems?

The browsers I have had playback issues with are Android on various devices both thru their own app and thru i.e Chrome.

I have also had issues with playback thru Safari.

The issue is not only that DASH is non-existing, not all HLS-manifest doesn't seem to work properly either as spaam also has pointed out earlier. One manifest is for example loaded but then re-directed to another that works. On some episodes I think there are examples also where only one or two HLS-manifests actually returns working streams.

Have also noticed that these videos are more geo-striated and they have block VPN IP:s, which they don't do on other content.

I have successfully played the Disneydags and the Doc McStuffins shows in several browsers like Firefox, Chrome and Edge, and in the apps on iPhone, iPad and Apple TV. Also, using the unofficial SVT Play add-on for Kodi on Raspberry Pi.

Everything works fine, except the subtitles, which only seem to work at random.

I have been in contact with SVT thru email about the lack of DASH streams and they have acknowledged the issue but they are unable of providing. a timeline of when it will be fixed.

Thank you! I too would contact SVT if I could find a system where the shows can't be played. I've been in contact with them regarding the subtitle issue. They have even claimed that problem to be solved, but then realized that it wasn't the case.

The latest message I received they stated that they don't have any prognosis of when it will be solved but they mentioned that this is because the problem is substantial.

also as I have pointed out before there are issues with the audio tracks which ffmpeg correctly raises and therefor fails. This is a consistent issue that is repeated with all episodes. So there might and probably is an issue with SVT's new compressions model that they use for animated content.

Are there other animated shows that are affected in the same way? I thought it was only the two Disney shows because of special requirements by Disney to protect their content.

I don't really rip that much animated content in general so can't answer that but I would be surprised if this is the only content that is affected by it.

SVT has started using a new compression model for animated content (heavier) (Link - Source of statement (can also be observed in their manifests in comparison with "Normal Content").

Sure they use some basic encryption for it but not DRM. I mean they have apply the same encryption to their live streams of channels before and other content too, that part is nothing new really I would say.

[pythonuser3856]

I have the same issue with the feature film"Birdman" that was released at SVTplay today. Only HLS is available and sound cuts off after approx 3min 26sec.

[pythonuser3856]

This afternoon the sound is suddenly ok with "Birdman". One thing that's changed is that SVT suddenly made 5.1-sound an available option and selecting that provided me with full-length sound.

[pythonuser3856]

The issue of truncated audio seems to be spreading.

I found that it's at hand with most (all?) items under the link https://www.svtplay.se/faret-shaun At testing I'm using svtplay-dl v4.0. With this I'm using python 3.8.10, MS Windows 8.1, and ffmpeg 4.4.

If I try a "quality" different from the default highest one, I do at many times end up with an .mp4-file of diminished size (1 kB), i.e. with no playable content.

[spaam]

🤔 what quality and what video? i dont want to try to find what video when its 10+ videos with 10+ different quality options for each video.

[pythonuser3856]

Fair enough.

I get the symptoms using svtplay-dl with one switch only; the switch "--subtitle" to attempt to retrieve subtitles Some example links where audio is cut off: https://www.svtplay.se/video/9783602/faret-shaun/faret-shaun-sasong-5-avsnitt-16 https://www.svtplay.se/video/9862155/faret-shaun/faret-shaun-sasong-5-avsnitt-18 https://www.svtplay.se/video/29172470/faret-shaun/faret-shaun-sasong-6-far-a-gas https://www.svtplay.se/video/9888258/faret-shaun/faret-shaun-sasong-5-avsnitt-19 https://www.svtplay.se/video/9809841/faret-shaun/faret-shaun-sasong-5-avsnitt-17 https://www.svtplay.se/video/9942403/faret-shaun/faret-shaun-sasong-5-avsnitt-20

Additional info: Neither of the above is retrieved with subtitles However, with the two example links below (using the same setting with svtplay-dl) I succeeded to get full audio: https://www.svtplay.se/video/29155250/faret-shaun/faret-shaun-sasong-6-frakt-forhinder https://www.svtplay.se/video/29139718/faret-shaun/faret-shaun-sasong-6-lada-uthyres and, I also got subtitles with these two.

[spaam]

this is so random. i dont know wtf is wrong. when i use ffmpeg to download it , it works. but it would be nice to know why it works in ffmpeg. it would also be nice to know how to detect this thing. i dont wanna make this script as a frontend to ffmpeg more than it is know.

[pythonuser3856]

Is ffmpeg able to get subtitles with the ones that I point out as troublesome ? ( I'm just looking for patterns in behavior, here if there is more than just the impact on audio )

[spaam]

i guess it could.

i have something that fixed the issue without having to use ffmpeg. but that broke live download a bit, i have an idea how to fix it.

[pythonuser3856]

As already mentioned it seems to be spreading.

svtplay-dl snapshot 20210630_104506 MS WIndows 8.1 Python 3.8.10 ffmpeg 4.4

https://www.svtplay.se/video/31549610/en-amerikansk-varulv-i-london

I can watch and get proper audio beyond 3m 28s when viewing using FireFox Downloading works fine but the resulting .mp4-file has truncated audio at using VLC to watch it:

py c:\svtplaydll\svtplay-dl_sshot_20210630_104506py__main__.py --subtitle -o "Långfilm - En amerikansk varulv i London" https://www.svtplay.se/video/31549610/en-amerikansk-varulv-i-london INFO: Outfile: Långfilm - En amerikansk varulv i London.ts INFO: Selected to download hls, bitrate: 3376 format: h264 [1457/1457][========================================] ETA: 0:00:00 [1457/1457][========================================] ETA: 0:00:00 INFO: Merge audio and video into Långfilm - En amerikansk varulv i London.mp4 INFO: Merging done, removing old files.

Another observation for the same material Using a different quality (from default) resulted in an .mp4-file with a size of 1 kB Two different qualities/codecs tried:

py c:\svtplaydll\svtplay-dl_sshot_20210630_104506py__main__.py --subtitle --format-preferred hevc --quality 3290 https://www.svtplay.se/video/31549610/en-amerikansk-varulv-i-london INFO: Outfile: en.amerikansk.varulv.i.london-2a3b39c-svtplay.ts INFO: Selected to download hls, bitrate: 3290 format: hevc [1458/1458][========================================] ETA: 0:00:00 [1458/1458][========================================] ETA: 0:00:00 INFO: Merge audio and video into en.amerikansk.varulv.i.london-2a3b39c-svtplay.mp4 INFO: Merging done, removing old files.

py c:\svtplaydll\svtplay-dl_sshot_20210630_104506py__main__.py --subtitle --quality 3284 https://www.svtplay.se/video/31549610/en-amerikansk-varulv-i-london INFO: Outfile: en.amerikansk.varulv.i.london-2a3b39c-svtplay.ts INFO: Selected to download hls, bitrate: 3284 format: h264 [1458/1458][========================================] ETA: 0:00:00 [1458/1458][========================================] ETA: 0:00:00 INFO: Merge audio and video into en.amerikansk.varulv.i.london-2a3b39c-svtplay.mp4 INFO: Merging done, removing old files.

I tried a workaround by using "svtplay-dl --get-url" and then feed the result to FFmpeg for download. The result, however, was that FFmpeg left me with an .mp4-file with a video stream but no audio stream ( maybe I didn't use FFmpeg as needed ? ) A workaround which is a bit tedious but does the trick is to use Audacity to capture sound while playing the movie via Firefox, and then use FFmpeg to stich it together. That's where I ended up.

[pythonuser3856]

Early feedback to latest snapshot 2021-07-23 12:47:36 MS Windows 8.1 Pyhton 3.8.10 FFmpeg 4.4 Using the link https://www.svtplay.se/video/51280/faret-shaun/faret-shaun-sasong-1-avsnitt-22

The svtplay-dl operation during fetch looks normal but the result is an .MP4-file of size 1 kB I've tried the qualities 1587, 1292, 1188 and 990

[pythonuser3856]

A hint: I've used Audacity to successfully read and import the audio.ts file from a Disneydags episode. To accomplish the task Audacity uses an FFmpeg library file "avformat-55.dll" to read and interpret the audio file content.

My point: Since svtplay-dl already uses FFmpeg for postprocessing, perhaps it's a matter of using a suitable set of parameters to FFmpeg ?

Details: MS Windows 8.1 python 3.8.10 svtplay-dl v4.9 FFmpeg 4.4
Audacity v3.0.4 (using the lib avformat-55.dll from FFmpeg v2.2.2)

I downloaded the episode of Disneydags with svtplay-dl v4.9 using options --no-merge and --no-postprocess. The link was https://www.svtplay.se/video/33201450/disneydags/disneydags-sasong-1-avsnitt-17 I used Audacity -> File -> Import -> Audio Audacity immediately started to import the file; I did not have to specify any audio format for Audacity to start.

[SYSophie]

A hint: I've used Audacity to successfully read and import the audio.ts file from a Disneydags episode. To accomplish the task Audacity uses an FFmpeg library file "avformat-55.dll" to read and interpret the audio file content.

My point: Since svtplay-dl already uses FFmpeg for postprocessing, perhaps it's a matter of using a suitable set of parameters to FFmpeg ?

Details: MS Windows 8.1 python 3.8.10 svtplay-dl v4.9 FFmpeg 4.4 Audacity v3.0.4 (using the lib avformat-55.dll from FFmpeg v2.2.2)

I downloaded the episode of Disneydags with svtplay-dl v4.9 using options --no-merge and --no-postprocess. The link was https://www.svtplay.se/video/33201450/disneydags/disneydags-sasong-1-avsnitt-17 I used Audacity -> File -> Import -> Audio Audacity immediately started to import the file; I did not have to specify any audio format for Audacity to start.

I have tried a number of different parameters for FFmpeg and have been unsuccessful with fixing the malformed audio tracks.

I don't know if this is a potential result of that Disney has delivered the file in this state or if it's a result of the new heavier compression that SVT has started using for animated content.

Either way, the audio tracks are seen as malformed by FFmpeg, this causes the issues.

[pythonuser3856]

Still, with use of libavformat by Audacity I get a successful import of the Disney audio from the .audio.ts-file. When reading documentation of avformat at https://ffmpeg.org/doxygen/trunk/group__libavf.html there is a claim "... Most importantly an AVFormatContext contains: the input or output format. It is either autodetected or set by user for input... " Could a use of libavformat in FFmpeg be a way forward ? Perhaps not. It could of course be a use by Audacity of a feature in libavformat which current version of FFmpeg does not support. An indication of that comes from FFplay and a run-time trace:

ffplay disneydags.s01e17.avsnitt.17-f3e22d2-svtplay.audio.ts ffplay version n4.4-78-g031c0cb0b4 Copyright (c) 2003-2021 the FFmpeg developers

built with gcc 10-win32 (GCC) 20210408 configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-conf ig=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw 32 --enable-gpl --enable-version3 --disable-debug --disable-w32threads --enable- pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --en able-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbi s --enable-opencl --enable-libvmaf --enable-vulkan --enable-amf --enable-libaom --enable-avisynth --enable-libdav1d --enable-libdavs2 --disable-libfdk-aac --ena ble-ffnvcodec --enable-cuda-llvm --enable-libglslang --enable-libgme --enable-li bass --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2 --enable-libmfx --enable-libopenco re-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librav1e --ena ble-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-libs rt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --enable-libvidstab --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-l ibzimg --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pth read --extra-ldexeflags= --extra-libs=-lgomp libavutil 56. 70.100 / 56. 70.100 libavcodec 58.134.100 / 58.134.100 libavformat 58. 76.100 / 58. 76.100 libavdevice 58. 13.100 / 58. 13.100 libavfilter 7.110.100 / 7.110.100 libswscale 5. 9.100 / 5. 9.100 libswresample 3. 9.100 / 3. 9.100 libpostproc 55. 9.100 / 55. 9.100 [aac @ 0000004f9845a180] Estimating duration from bitrate, this may be inaccurat e Input #0, aac, from 'disneydags.s01e17.avsnitt.17-f3e22d2-svtplay.audio.ts': Duration: 00:58:33.99, bitrate: 198 kb/s Stream #0:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 198 kb/s [aac @ 0000004f98526240] More than one AAC RDB per ADTS frame is not implemented . Update your FFmpeg version to the newest one from Git. If the problem still oc curs, it means that your file has a feature which has not been implemented. [aac @ 0000004f98526240] channel element 1.11 is not allocated [aac @ 0000004f98526240] Number of bands (37) exceeds limit (33). [aac @ 0000004f98526240] channel element 2.15 is not allocated0/0 [aac @ 0000004f98526240] channel element 3.1 is not allocated=0/0 [aac @ 0000004f98526240] channel element 3.1 is not allocated=0/0 [aac @ 0000004f98526240] channel element 3.1 is not allocated=0/0 [aac @ 0000004f98526240] channel element 3.8 is not allocated=0/0 [aac @ 0000004f98526240] Multiple frames in a packet. 0B f=0/0 [aac @ 0000004f98526240] Sample rate index in program config element does not ma tch the sample rate index configured by the container. [aac @ 0000004f98526240] Inconsistent channel configuration. [aac @ 0000004f98526240] get_buffer() failed [aac @ 0000004f98526240] Number of bands (56) exceeds limit (44). [aac @ 0000004f98526240] Error decoding AAC frame header.0B f=0/0 [aac @ 0000004f98526240] Input buffer exhausted before END element found 252.38 M-A: 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0

< ffplay manually aborted >

[bjornstromberg]

this issue is related to ffmpeg it would seem.. both instances uses the same svtplay-dl 4.25

on ubuntu 20.04 with an old ffmpeg 4.2.7 this issue occurs. ffmpeg version 4.2.7-0ubuntu0.1

when firing up a docker container with archlinux ffmpeg 6.0 ffmpeg version n6.0

the downloaded files play fine on kodi with an older ffmpeg.

so the critical step is the download part with a newer ffmpeg