Jerky video at TV4 play, fix possible

[suncore]

Using svtplay-dl master: When downloading a video from TV4 play, the video is jerky/choppy. Instead of using ffmpeg to merge audio and video .ts, I used mkvmerge: mkvmerge -o foo.mkv input.ts input.audio.ts and the video is now smooth. Also, it is a lot faster to merge. Maybe it is possible to have mkv as alternative?

[Sopor]

Yes, this was really nice. The video is very smooth. That should really be an option in svtplay-dl so it is possible to use mkvmerge on sites that have this issue.

MKVToolNix is available for Windows, Linux and macOS, so it should work on all three OS's :)

[SYSophie]

@suncore mkv is a nice format that makes it possible to maintain the original format and has support for a range of different formats.

However, if you ever would convert the mkv to any other format it would result in an unsynchronized video.

This is because TV4 produces HLS-streams with malformed PTS-timestamps. A better solution is to download thru the DASH protocol since this protocol isn't having the same issue. End result thru dash is a mp4 without any issues.

I don't see this as a long term or in anyway as a good solution since it will keep the underlaying issues.

[suncore]

Thanks for the detailed explanation :-)

I wonder if the malformed time stamps are also in the air broadcast. I have discovered that if I watch TV4 on kodi (via tvheadend) with DXVA2 acceleration, kodi either displays garbage at scene breaks (with Intel driver) or crashes (with Nvidia drivers). I had to turn off DXVA2 acceleration to make it work.

Do you know in what way the time stamps are malformed? Are they out of spec or is it just some weird TV4 home grown dialect?

[SYSophie]

There are some other issues already about this, #1046 or https://github.com/stefansundin/privatkopiera/issues/10.

The timestamps that are malformed are from the audio track and don't match up with the video track. When FFmpeg tries to put these two tracks together it fails to match the timestamps. And these bad timestamps are only produced with their HLS-streams and I have neve been able to re-produce this with any of their dash-streams. Why they produce these bad streams is something that i leave to Bonnier to troubleshoot but I can only assume that they have some machines that are not preforming that well.

This has been a known issue for two years almost. If you want a good solution then I suggest that you move over to using DASH. Because when talking with Bonniers (useless customer service) about this issue numerous times doesn't help, so you shouldn't be prepared to see any change soon.

What they usually do is that after a show has been aired is that they make the episode available thru a live manifest that will be available for 24-74h or somewhere around there. After this they will cut it to length if it's a live show and then re-upload new manifests. If it's pre-recorded they will just make these available from the beginning. That's about how their publishing workflow works based on my own observations.

Unfortunately doesn't svtplay-dl support DASH from TV4 but on the other hand does youtube-dl this.

DASH will give you a good end result, in the other linked issues they discuss some ways to kind off solve it but to break it down. To repair timestamps is just too time consuming and isn't worth the extra job since there is a working alternative that produces flawless output from the beginning which is DASH.

[suncore]

Thanks!

[SweDennis]

Hi, I've been downloading from tv4play both before and after this issue was reported, and can't say that I've seen this. Have I just been lucky? Do you have a troublesome example link together with whatever parameters are being passed to svtplay-dl for me to test?

Regards, /Dennis

[suncore]

I just downloaded an episode of Robinson without any extra arguments to svtplay-dl except for the URL. It was evident the video was choppy.

[SweDennis]

I will test this. I have for sure had choppy video at times, but in those instances it's been when I've downloaded something too big for my laptop to handle, it can't do 1080p without being choppy for instance, it's an old and slow thing. Just out of habit I do -q 1500 -Q 300 on that one, and never had any issues. On my main system, with no such issues, I've never seen it happen.

[SweDennis]

Have downloaded the latest robinson episode now, will watch it and report back. I just gave the command svtplay-dl https://www.tv4play.se/program/robinson/12527167, and it downloaded a high bitrate version, hls 5863. Apart from this, I just make sure to have the latest version of svtplay-dl and ffmpeg. More to follow. :)

[SweDennis]

The above download is not in the slightest choppy for me, it really isn't, so don't know what else to say. It seems very difficult to fault svtplay-dl for it, even if it is choppy.

Just for reference, I'm using:

dennis@Lenovo:~$ svtplay-dl --version svtplay-dl 2.4+35.g81cb18f dennis@Lenovo:~$

dennis@Lenovo:~$ ffmpeg --version ffmpeg version N-52628-g79e3c4dd74-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2020 the FFmpeg developers

Regards, /Dennis

[Sopor]

It is horribly to watch. If you don't convert the ts file to mp4 (or not merge video with audio) it is playing smoothly, but when it get converted to mp4 (merging video/audio) it will not play smoothly anymore.

ffmpeg.exe --version ffmpeg version 4.2.2

svtplay-dl 2.4-34-g800d406

@SweDennis You can download my video and watch that if you want?

[Sopor]

Even if you download the hds-5534 with youtube-dl it will be choppy.

youtube-dl -f hds-5534+bestaudio https://www.tv4play.se/program/robinson/12527167

File size: 919 776 425 bytes

Try download the DASH with youtube-dl and it is not choppy 👍

youtube-dl -f dash-video=5406008+bestaudio https://www.tv4play.se/program/robinson/12527167

File size: 919 522 706 bytes

[SweDennis]

I really don't want anything. If I can help in an way then I will. I'm just slightly interested in why I don't experience the issue. I just issued the command youtube-dl -f hds-5534+bestaudio https://www.tv4play.se/program/robinson/12527167. Will report back.

[SweDennis]

This command line from above youtube-dl -f hds-5534+bestaudio https://www.tv4play.se/program/robinson/12527167, did not produce a choppy video for me, it works just fine, it really does.

/Dennis

[Sopor]

@SweDennis How much do you watch? In the beginning of the episode there are some tree they sweeps over. That is horribly to look at.

File size in bytes?

[Sopor]

I did change ffmpeg to git-2020-05-04-5767a2e but it didn't helped. The file size was different though 919 275 306 bytes

[suncore]

Maybe you are using different players? I have tested with kodi in windows and vlc in linux, both were choppy. Maybe some other player can hide the choppiness, or maybe a difference in graphics card.

[Sopor]

@SweDennis download this file and play it locally ...

Then we will see why you are not experiencing it or we will see if it is ffmpeg or you hardware that for some reason hide it as @suncore wrote.

We all have different levels what is choppy or not, so maybe you don't see it as an issue?

[SweDennis]

Watching the episode again now, having downloaded it locally from Sopor's link.

[SweDennis]

dennis@Lenovo:~/test$ youtube-dl -f hds-5534+bestaudio https://www.tv4play.se/program/robinson/12527167 [TV4] 12527167: Downloading video info JSON [TV4] 12527167: Downloading JSON metadata [TV4] 12527167: Downloading m3u8 information [TV4] 12527167: Downloading MPD manifest WARNING: [TV4] Unknown MIME type application/mp4 in DASH manifest [TV4] 12527167: Downloading f4m manifest [TV4] 12527167: Downloading ISM manifest WARNING: Requested formats are incompatible for merge and will be merged into mkv. [f4m] Downloading f4m manifest [f4m] Total fragments: 333 [download] Destination: Robinson del 40-12527167.fhds-5534.flv [download] 100% of 877.75MiB in 07:54 [hlsnative] Downloading m3u8 manifest [hlsnative] Total fragments: 333 [download] Destination: Robinson del 40-12527167.fhls-133.mp4 [download] 100% of 20.71MiB in 00:49 [ffmpeg] Merging formats into "Robinson del 40-12527167.mkv" Deleting original file Robinson del 40-12527167.fhds-5534.flv (pass -k to keep) Deleting original file Robinson del 40-12527167.fhls-133.mp4 (pass -k to keep) dennis@Lenovo:~/test$

total 897736 -rw-rw-r-- 1 dennis dennis 919275306 May 8 18:35 'Robinson del 40-12527167.mkv' dennis@Lenovo:~/test$ md5sum Robinson\ del\ 40-12527167.mkv 383f75af0563811082b19f60640f28a8 Robinson del 40-12527167.mkv dennis@Lenovo:~/test$

Find above what I download, it works, and am watching it now from Sopors link, so far so good, for me.

[SweDennis]

@sopor As to your comment on where we draw the line, then yes, it very well could be, but I don't know how say it other than that it looks absolutely fine to me. My computer doesn't stutter in the video, it doesn't stutter in audio, it just plays the thing.

[Sopor]

@SweDennis Ignore the bad quality (it is recorded with my phone on the screen), but this is how it looks like when it is choppy

[Sopor]

Robinson del 40-12527167.mkv

Do you convert it to mkv @SweDennis? I get an mp4 file.

[SweDennis]

Not at all, I just run the command as shown. I don't do anything extra.

[SweDennis]

This is your downloaded file: -rw-rw-r-- 1 dennis dennis 919776425 May 8 18:32 'Robinson del 40-12527167-flv.mp4'

dennis@Lenovo:~/Downloads$ md5sum Robinson\ del\ 40-12527167-flv.mp4 fe9e38e0a399d43b4f1fa8ae7a9d86d5 Robinson del 40-12527167-flv.mp4 dennis@Lenovo:~/Downloads$

Do you have an exakt timestamp I should look at?

/Dennis

[Sopor]

Did you looked at the video above that i recorded with my phone?

00:42, but you can see it in the whole video more or less.

[SweDennis]

The video above is only 17 seconds for me, so don't even get to 00:42 ...

dennis@Lenovo:~/Downloads$ ffprobe 20200508_165445.mp4 ffprobe version N-52628-g79e3c4dd74-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2007-2020 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg libavutil 56. 43.100 / 56. 43.100 libavcodec 58. 82.100 / 58. 82.100 libavformat 58. 42.102 / 58. 42.102 libavdevice 58. 9.103 / 58. 9.103 libavfilter 7. 80.100 / 7. 80.100 libswscale 5. 6.101 / 5. 6.101 libswresample 3. 6.100 / 3. 6.100 libpostproc 55. 6.100 / 55. 6.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20200508_165445.mp4': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: isommp42 creation_time : 2020-05-08T14:55:03.000000Z location : +00.0000+000.0000/ location-eng : +00.0000+000.0000/ com.android.version: 8.0.0 com.android.capture.fps: 30.000000 Duration: 00:00:17.33, start: 0.000000, bitrate: 14365 kb/s Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 14105 kb/s, SAR 1:1 DAR 16:9, 30 fps, 120 tbr, 90k tbn, 180k tbc (default) Metadata: creation_time : 2020-05-08T14:55:03.000000Z handler_name : VideoHandle Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 256 kb/s (default) Metadata: creation_time : 2020-05-08T14:55:03.000000Z handler_name : SoundHandle dennis@Lenovo:~/Downloads$

[Sopor]

00:42 was in the original Robinson episode, but as i wrote you can see it in the whole Robinson episode more or less.

Can't you see how choppy the video is that i recorded from my screen?

[Sopor]

@SweDennis I tried to run the command you used when it was converted to an mkv file and it doesn't matter. Both the mkv and the mp4 are choppy, so there wasn't any difference between them. I was forced to test it. It seems that youtube-dl didn't liked mp4 when hds-5534 was specified, but if i understand this correct the bestvideo should be hds-5534 flv 1920x1080 5534k (best) but it seems to download hls-5863 mp4 1920x1080 5863k , avc1.640028, 25.0fps, video only instead.

youtube-dl have so many options and switches that you almost need to be an expert to use it. That is why i prefer svtplay-dl and i believe i'm not the only one :)

[Sopor]

It seems that viafree also now have this issue :(

[spaam]

url to the video? what ffmpeg version are you using?

[EmilSodergren]

Any progress on this? I am using: Svtplay-dl version 3.8 Ffmpeg version N-102605-g4c705a2775 ( built from source a couple of days ago) and I am experiencing this stuttering from tv4play. It may be better on the lower qualities but that might just be due to worse resolution.

[SYSophie]

@EmilSodergren ask Bonnier Broadcasting / Telia, since they are the ones that seemingly is producing faulty Audiotracks...

DASH works great though

[EmilSodergren]

Well :) I do not think they are very interested in helping me out... However I tried to download "--only-video" and noticed the same lag. Are you sure it is the audio track that is the culprit here? DASH is probably better but not something they provide I'm afraid.

After aborting a download half way through a '--only-video'-run and playing the .ts file that svtplay-dl wasn't given the chance to remux the lag seemed to be gone. I also did the same with the audio and got two partial files and muxed them my self. ffmpeg -i video.ts -i audio.ts -map 0:v -map 1:a -c copy -shortest output.mkv This lead to the same choppy result as with plain stvplay-dl, however adding -fflags +igndts like so: ffmpeg -fflags +igndts -i video.ts -i audio.ts -map 0:v -map 1:a -c copy -shortest output.mkv did the trick.

Using the existing PTS as reference and ignoring the DTS seems to be the way to go... Could this be something that is valid for all HLS streams?

[SYSophie]

Well :) I do not think they are very interested in helping me out... However I tried to download "--only-video" and noticed the same lag. Are you sure it is the audio track that is the culprit here? DASH is probably better but not something they provide I'm afraid.

After aborting a download half way through a '--only-video'-run and playing the .ts file that svtplay-dl wasn't given the chance to remux the lag seemed to be gone. I also did the same with the audio and got two partial files and muxed them my self. ffmpeg -i video.ts -i audio.ts -map 0:v -map 1:a -c copy -shortest output.mkv This lead to the same choppy result as with plain stvplay-dl, however adding -fflags +igndts like so: ffmpeg -fflags +igndts -i video.ts -i audio.ts -map 0:v -map 1:a -c copy -shortest output.mkv did the trick.

Using the existing PTS as reference and ignoring the DTS seems to be the way to go... Could this be something that is valid for all HLS streams?

They don't provide DASH? That's something new for me because last time I looked they do.

The faulty timestamps messes up for FFmpeg when merging.

If you output mkv you won't have the same issues in general.

[EmilSodergren]

I ran svtplay-dl --list-quality <url> and no DASH streams showed up. It works without lag if i output to mp4 as well, if i provide the -fflags +igndts.

[granbom]

We kind of discussed this here #1049 and here #1046 before. The issue as I understand it is most likely that TV4 have a source of mp4 and using HLS. these issues are common then. After a few days they normally fix the initial file, but not always. The broken file can be fixed with +igndts in ffmpeg.

[EmilSodergren]

Does this mean that you must download and start watching the thing to determine if it is needed, or can you add a +igndts "just in case" on all HLS strems?

[granbom]

@EmilSodergren my thought about it 2019 was:

1. Do a test muxing without +igndts for like 5 seconds (like ffmpeg -i input.ts -i input.audio.ts -c copy -ss 00:01:00 -t 00:00:05 -f null -)
2. Read the ffmpeg stderr and look for Invalid timestamps messages
3. If so, add -fflags +igndts to the muxing parameters, othervise mux without them.

as I understand in 2019, always using +igndts is not recommended (according to ffmpeg then) can't remember where I found it. maybe it's ok to always use it for tv4.

[EmilSodergren]

I think that sounds reasonable. The first solution seems to be the correct one, however always applying for tv4-HLS streams might be easier to implement. Since it is not possible to not remux the streams I think it needs to be done internally in svtplay-dl.

[granbom]

Yes, also I think it would be a good idea @spaam if we could add a setting to not remux at all regardless.

[granbom]

Another point might be to always use -fflags +igndts when video.ts and audio.ts are the sources, together with HLS. Maybe it's only TV4, but why limit it by provider. Regardless, a --no-mux or similar parameter to svtplay-dl I think could be a good addition.

[spaam]

what player ( and version of it ) do you guys use to watch these videos when you see its jerky? i used ffmpeg ( 4.2.4-1ubuntu0.1 ) in ubuntu 20.04 and tried a news clip. it works fine with both in VLC (3.0.14) and "Films & TV" in windows 10.

sure i could add that argument :)

[SweDennis]

Has always worked fine for me as well, using Celluloid 0.20, included with latest Linux Mint, based on Ubuntu 20.04, also using proprietary Nvidia Graphics Acceleration when available.

[EmilSodergren]

FFmpeg version N-102605-g4c705a2775 and VLC 3.0.12 on ubuntu 21.04 for me. I tested with some "Hela kändis sverige bakar", 1.6GB on max resolution. It stutters just a tiny bit, but very frequently. Multiple times a second, making you nauseous when watching it :). May just be the program though, the solution might be to watch something else :)

Another point might be to always use -fflags +igndts when video.ts and audio.ts are the sources, together with HLS. Maybe it's only TV4, but why limit it by provider.

I really root for this solution though. .ts + HLS should default to setting the flags mentioned.

[spaam]

@EmilSodergren there are 12 episodes of that show. which one have the issue? i dont want to download all episodes and check :)

[EmilSodergren]

What, who would not want to fill their hard drive with "celebrities" making pie??? I just assume all of them, but I apparently chose part 4.

[Sopor]

You get this jerky video if you download Efterlyst after they broadcast it LIVE, but the next day when they have removed the commercials the jerky video is gone.

[SYSophie]

I ran svtplay-dl --list-quality <url> and no DASH streams showed up. It works without lag if i output to mp4 as well, if i provide the -fflags +igndts.

svtplay-dl doesn't support DASH for tv4, that doesn't mean that DASH doesn't exist.

If you wanna try and fetch DASH I would suggest that you try using YouTube-dl instead, which has support for it.

[spaam]

latest snapshot have support for dash . i will release it tomorrow :)