Request

[Lunarwalker60]

Does anybody have any ideas about capturing live-streams from SVT? My goal is to fix my Windows timed recorder app which has stopped working since SVT changed live-streaming to DASH/MPD.

/S

[pythonuser3856]

Please see #1398 My work-around is manual handling; capturing video still works using the switch --live and I capture audio using Audacity from playing the web live-stream in a web browser. It can be rather time consuming to get video and audio in sync afterwards.

[Lunarwalker60]

I don't know if it's relevant for this forum but the following works for me now:

 

ffmpeg -y -i "https://svt1-c.akamaized.net/se/svt1/5eff9010-33e6-4944-b906-1e885e20d659/dash-v4/v4.m3u8" -i "https://svt1-c.akamaized.net/se/svt1/5eff9010-33e6-4944-b906-1e885e20d659/dash-a0/a0.m3u8" -c:v copy -c:a copy "SVT1-Direkt.mkv"

 

ffmpeg -y -i "https://svt-live-c.secure.footprint.net/se/svt2/28fbcc56-60a4-4024-8840-a63ed223c56d/dash-v4/v4.m3u8" -i "https://svt-live- c.secure.footprint.net/se/svt2/28fbcc56-60a4-4024-8840-a63ed223c56d/dash-a0/a0.m3u8" -c:v copy -c:a copy "SVT2-Direkt.mkv"

 

Video sizes/qualities are from v0 to v4

 

You will probably have to update the .m3u8-addresses now and again between captures.

 

/S

 

Sent: Monday, June 13, 2022 at 6:32 AM From: "pythonuser3856" @.> To: "spaam/svtplay-dl" @.> Cc: "Lunarwalker60" @.>, "Author" @.> Subject: Re: [spaam/svtplay-dl] Request (Issue #1481)

 

Please see #1398 My work-around is manual handling; capturing video still works using the switch --live and I capture audio using Audacity from playing the web live-stream in a web browser. It can be rather time consuming to get video and audio in sync afterwards.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[pythonuser3856]

Thank's for the tip ! I've used your information to create an automated script solution for time based recordings (replicating VCR-recorder). This is, however, just a temporary fix; there are pieces of information missing so it's not as good as an an intrinsic feature of svtplay-dl could be.

[pythonuser3856]

I have used "svtplay-dl --get-url" to get a valid m3u8-reference and have previously got the very links "https://svt1-c.akamaized.net/se/svt1/..:" and "https://svt-live-c.secure.footprint.net/se/svt2/..." that you refer to here above.

However, when I now use "svtplay-dl --get-url" I instead get the links "https://svt-secure-c.akamaized.net/secure/svt1/..." respectively "https://svt-secure-c.akamaized.net/secure/svt2/..."

Using either of the links that I now get from svtplay-dl does not work with ffmpeg. The good thing is that your original links still works with ffmpeg !

[spaam]

man im getting a bit tired of this the whole scraping video stuff. maybe its time to shut it down? 🤔 fix one issue get another issue. i dont want to start processing all the data to see if they are valid then download it again to get files people like.

you can try to revert this commit https://github.com/spaam/svtplay-dl/commit/94eb8543f79bc992fd3b5aee2a0bb4403d85ed04 . its related to https://github.com/spaam/svtplay-dl/issues/1510 it had bad files in it.

[pythonuser3856]

I added the comment since it's necessary to be aware of at using FFmpeg to capture live SVT channels (as a workaround while waiting for svtplay-dl to provide live support). If it should boil down to a choice; in my view it's more important to have support for live capturing compared to #1510 "deal with incorrect information about available audio variants" since that can be detected and handled. Sorry if I stirred things up.

[pythonuser3856]

Reverting the commit 94eb854 does not make any difference when I try.

Based on that I'll stick with my current solution, a script-based substitution of the first part of the m3u8-link with what @Lunarwalker60 refers to, and then feed it as one of the parameters to FFmpeg. That works for now.