Youtube video downloads but will not play correctly.

[linxman]

Checklist

• [x ] I'm reporting a broken site support
• [x ] I've verified that I'm running youtube-dl version 2019.11.28
• [x ] I've checked that all provided URLs are alive and playable in a browser
• [x ] I've checked that all URLs and arguments with special characters are properly quoted or escaped
• [x ] I've searched the bugtracker for similar issues including closed ones

Verbose log

$ time ~/bin/youtube-dl-191128 -v https://www.youtube.com/watch?v=LHA9Ikd9fEw
[debug] System config: ['--prefer-free-formats']
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://www.youtube.com/watch?v=LHA9Ikd9fEw']
[debug] Encodings: locale ISO-8859-1, fs iso8859-1, out ISO-8859-1, pref ISO-8859-1
[debug] youtube-dl version 2019.11.28
[debug] Python version 3.7.5 (CPython) - Linux-5.3.15-300.fc31.x86_64-x86_64-with-fedora-31-Thirty_One
[debug] exe versions: ffmpeg 4.2.1, ffprobe 4.2.1
[debug] Proxy map: {}
[youtube] LHA9Ikd9fEw: Downloading webpage
[youtube] LHA9Ikd9fEw: Downloading video info webpage
[youtube] LHA9Ikd9fEw: Downloading m3u8 information
[youtube] LHA9Ikd9fEw: Downloading MPD manifest
[debug] Default format spec: bestvideo+bestaudio/best
[debug] Invoking downloader on 'https://manifest.googlevideo.com/api/manifest/dash/expire/1576768947/ei/U0H7XfqiIuKij-8Pl7278AE/ip/173.162.21.73/id/LHA9Ikd9fEw.1/source/yt_live_broadcast/requiressl/yes/as/fmp4_audio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_hd_clear/force_finished/1/fexp/23842630/itag/0/playlist_type/DVR/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Cas%2Cforce_finished%2Citag%2Cplaylist_type/sig/ALgxI2wwRQIhAIqSjqJvvTGFsH-nuu5fSnVngmP2ZnF9nPWj4xWhxRW0AiBXAHa6k_tnS_Sw4eiJncKtDd2vtCGJJlSJPaCgFMsLTQ%3D%3D'
[dashsegments] Total fragments: 2881
[download] Destination: House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.f136.mp4
[download] 100% of 1.93GiB in 19:57
[debug] Invoking downloader on 'https://manifest.googlevideo.com/api/manifest/dash/expire/1576768947/ei/U0H7XfqiIuKij-8Pl7278AE/ip/173.162.21.73/id/LHA9Ikd9fEw.1/source/yt_live_broadcast/requiressl/yes/as/fmp4_audio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_hd_clear/force_finished/1/fexp/23842630/itag/0/playlist_type/DVR/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Cas%2Cforce_finished%2Citag%2Cplaylist_type/sig/ALgxI2wwRQIhAIqSjqJvvTGFsH-nuu5fSnVngmP2ZnF9nPWj4xWhxRW0AiBXAHa6k_tnS_Sw4eiJncKtDd2vtCGJJlSJPaCgFMsLTQ%3D%3D'
[dashsegments] Total fragments: 2881
[download] Destination: House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.f140.m4a
[download] 100% of 222.96MiB in 14:11
[ffmpeg] Merging formats into "House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.mp4"
[debug] ffmpeg command line: ffmpeg -y -loglevel repeat+info -i 'file:House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.f136.mp4' -i 'file:House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.f140.m4a' -c copy -map 0:v:0 -map 1:a:0 'file:House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.temp.mp4'
Deleting original file House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.f136.mp4 (pass -k to keep)
Deleting original file House committee debates Trump impeachment vote guidelines-LHA9Ikd9fEw.f140.m4a (pass -k to keep)

real 36m24.331s
user 3m1.329s
sys 2m4.790s

Description

Youtube-dl appears to download the video file without any apparent problem, but the file seems to be smaller than it should be. Playing the resulting file in VLC gives the first few seconds of the video with sound before the screen turns gray with no audio and continues with a lot of tearing. Smplayer fairs a little better in that the video presents an image with audio, but the image speeds up and slows down without bothering to sync up with the audio before mplayer aborts.

[Jeeaaasus]

I have the same issue. Seems to only be happening with previously live streamed videos and specifically when downloading separate video and audio formats.

The confusing thing is that not all vods have this issue and it seems like the issue goes away after some time, sometimes hours and sometimes days ...

[fireattack]

This issue is specific to DASH videos (see also: #23793) and is still present today.

youtube-dl (or ffmpeg) can merge it fine, but the timecode is all messed up.

I figured a workaround just in case someone is interested:

1. remux the video into MKV using whatever tools you like
2. Use mkvextract to extract the raw video and audio tracks. In this process the (wrong) timecode will be discarded.

You can actually just extract audio.aac and video.h264 (make sure to not use any container, otherwise ffmpeg will still keep the timestamps) directly from the mp4 file using ffmpeg too:

ffmpeg -i yourvideo.mp4 -c copy -map 0:v video.h264 -map 0:a audio.aac

but I found it's very slow. So I prefer to extract using mkvextract if the file is large.

3. Merge them back to whatever format you like using either ffmpeg or mkvtoolnix.

Edit: clarify

[lss4]

This issue is specific to DASH videos (see also: #23793) and is still present today.

youtube-dl (or ffmpeg) can merge it fine, but the timecode is all messed up.

I figured a workaround just in case someone is interested:

1. remux the video into MKV using whatever tools you like
2. Use mkvextract to extract the raw video and audio tracks. In this process the (wrong) timecode will be discarded.

Note: theoretically you would just extract audio.aac and video.h264 (make sure to not use any container, otherwise ffmpeg will still keep the timestamps) from the mp4 file using ffmpeg, but I found it's very slow.

1. Merge them back to whatever format you like using either ffmpeg or mkvtoolnix.

Yes, can confirm this works. I've been dealing with similar issues for quite a while. You're a lifesaver!

Should note that, if youtube-dl is downloading files using incompatible format combinations (in most cases, mp4 video and webm audio), which would be converted to mkv in such cases, the resulted mkv file will have correct timestamps and can be played properly, so I think the conversion process correctly stripped the invalid timestamp (which was the duration of an individual fragment, usually 10-20s).

Maybe one should always force the output file to mkv to see if that makes a difference.