YouTube livestream FFmpeg MP4 Mux bug

[BlakeCochrane]

Checklist

• [x ] I'm reporting a broken site support issue
• [x ] I've verified that I'm running youtube-dl version 2020.06.06
• [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 bug reports including closed ones
• [x ] I've read bugs section in FAQ

Verbose log

youtube-dl https://www.youtube.com/watch?v=8DT--3PxtBg -v
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['https://www.youtube.com/watch?v=8DT--3PxtBg', '-v']

[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2020.06.06
[debug] Python version 3.4.4 (CPython) - Windows-7-6.1.7601-SP1
[debug] exe versions: ffmpeg git-2020-06-04-7f81785, ffprobe git-2020-06-04-7f81
785
[debug] Proxy map: {}
[youtube] 8DT--3PxtBg: Downloading webpage
[youtube] 8DT--3PxtBg: Downloading m3u8 information
[youtube] 8DT--3PxtBg: Downloading MPD manifest
[debug] Default format spec: bestvideo+bestaudio/best
[debug] Invoking downloader on 'https://manifest.googlevideo.com/api/manifest/da
sh/expire/1591448521/ei/aT_bXpvWCYGbkwaqqbSgBw/ip/2407%3A7000%3A8535%3A1700%3A%3
A1d66/id/8DT--3PxtBg.1/source/yt_live_broadcast/requiressl/yes/hfr/all/as/fmp4_a
udio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_
hd_clear/force_finished/1/vprv/1/keepalive/yes/beids/23874722/itag/0/playlist_ty
pe/DVR/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Chfr%2Cas%2Cforce_fi
nished%2Cvprv%2Citag%2Cplaylist_type/sig/AOq0QJ8wRgIhAI94tECV6N0o2VN6a2bARmwurbr
KohQwdTHWqqH1rSMdAiEAw37kN-Y2LleDJvmJ8XDOpxi1Bzj0BytggP0Z23ZUGnE%3D'
[dashsegments] Total fragments: 815
[download] Destination: Online prenosy-8DT--3PxtBg.f299.mp4
[download] 100% of 214.09MiB in 01:53
[debug] Invoking downloader on 'https://manifest.googlevideo.com/api/manifest/da
sh/expire/1591448521/ei/aT_bXpvWCYGbkwaqqbSgBw/ip/2407%3A7000%3A8535%3A1700%3A%3
A1d66/id/8DT--3PxtBg.1/source/yt_live_broadcast/requiressl/yes/hfr/all/as/fmp4_a
udio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_
hd_clear/force_finished/1/vprv/1/keepalive/yes/beids/23874722/itag/0/playlist_ty
pe/DVR/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Chfr%2Cas%2Cforce_fi
nished%2Cvprv%2Citag%2Cplaylist_type/sig/AOq0QJ8wRgIhAI94tECV6N0o2VN6a2bARmwurbr
KohQwdTHWqqH1rSMdAiEAw37kN-Y2LleDJvmJ8XDOpxi1Bzj0BytggP0Z23ZUGnE%3D'
[dashsegments] Total fragments: 815
[download] Destination: Online prenosy-8DT--3PxtBg.f140.m4a
[download] 100% of 63.22MiB in 01:26
[ffmpeg] Merging formats into "Online prenosy-8DT--3PxtBg.mp4"
[debug] ffmpeg command line: ffmpeg -y -loglevel "repeat+info" -i "file:Saturday
 stream. Drill sgt screams at female  recruit and gets court martialed-pTLTZ9k3j
Jw.f299.mp4" -i "file:Online prenosy-8DT--3PxtBg.f140.m4a" -c copy -map "0:v:0" -map "1:a:0" "fi
le:Online prenosy-8DT--3PxtBg.temp.mp4"
Deleting original file Online prenosy-8DT--3PxtBg.f299.mp4 (pass -k to keep)
Deleting original file Online prenosy-8DT--3PxtBg.f140.m4a (pass -k to keep)

Description

In the last few days if you download a youtube livestream just after it has finished but before the VP9 transcode is available and allow youtube-dl to utilise FFmpeg to mux the individual AVC/AAC files into a MP4 container, you only end up with only the first 8 seconds of the stream. The muxed file is the correct file size of the AVC+AAC+muxing overhead. If I run the remuxed file through mkvmerge I get a error stating that the CTTS atom is missing. Attempting to repair the file was unsuccessful. If I use the -k option I can mux the AVC and AAC files with mkvmerge then mux the AVC and AAC streams into a MP4 container with the same version of FFmpeg that youtube-dl is using, the result is a perfectly working file. So there appears to be some incompatibility with youtube-dl and FFmpeg. After the VP9 transcode is available the FFmpeg muxing issue appears to be resolved as I was not able to reproduce the issue after that.