Corrupted video files resulting from attempting to download a livestream using youtube-dl

[infinity]

I would like to preface I was directed here from an initial bug report I made in the youtube-dl repository, as I was using their software which resulted in this bug. I suggest taking a look at it for more detail: ​https://github.com/ytdl-org/youtube-dl/issues/24457

Summary of the bug: When using youtube-dl to download a livestream from the streaming platform VLive, upon signaling the interrupt command during the download (CTRL+C), the output file would be corrupted and could not be played.

How to reproduce:

1. Find a livestream on VLive's website, ​https://www.vlive.tv/home/new
2. Retrieve the livestream link, ie. ​https://www.vlive.tv/video/181733 (as of the time of this post, the following link is to a live broadcast, and not a VOD)
3. Issue either one of the following commands with youtube-dl

   youtube-dl --no-part -f best "https://www.vlive.tv/video/181733"
   youtube-dl --no-part --hls-prefer-native -f best "https://www.vlive.tv/video/181733"
   youtube-dl --no-part --hls-prefer-ffmpeg -f best "https://www.vlive.tv/video/181733"
   

---

The command that DID NOT output an uncorrupted video was:
youtube-dl --no-part --hls-use-mpegts -f best "https://www.vlive.tv/video/181733"

---

Please do keep in mind that this only applies to livestreams from what I have experienced thus far issuing one of the three commands indicated above. I have attached a file of youtube-dl's verbose logging, ending when I signaled the interruption.

The following below is a result of ffprobe with the corrupted file. All downloaded files that are corrupted, results in the same error of moov atom not found:

{{{<redacted-path>\extracted>ffprobe "[V LIVE] 무지무지 3 ☁️✨ 2020-03-24 09_06-181733.mp4"
ffprobe version 4.2.2 Copyright (c) 2007-2019 the FFmpeg developers

built with gcc 9.2.1 (GCC) 20200122
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100

[mov,mp4,m4a,3gp,3g2,mj2 @ 0000029199bbcec0] moov atom not found
[V LIVE] 무지무지 3 ☁️✨ 2020-03-24 09_06-181733.mp4: Invalid data found when processing input

<redacted-path>\extracted>}}}

---

Once more, if you do find the time, I suggest taking a brief look at the GitHub issue as linked above in the preface of this report. Please do take a look at the attached logs as I believe the verbose logging also displays logs from ffmpeg, though I can't be sure.

Both ffmpeg and youtube-dl are the latest (master) versions.

[infinity]

youtube-dl verbose log

[infinity]

My apologies, I didn't properly format the output of ffprobe:

{{{<redacted-path>\extracted>ffprobe "[V LIVE] 무지무지 3 ☁️✨ 2020-03-24 09_06-181733.mp4"
ffprobe version 4.2.2 Copyright (c) 2007-2019 the FFmpeg developers
built with gcc 9.2.1 (GCC) 20200122
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000029199bbcec0] moov atom not found
[V LIVE] 무지무지 3 ☁️✨ 2020-03-24 09_06-181733.mp4: Invalid data found when processing input
<redacted-path>\extracted>}}}

[Gyan]

As per the ffmpeg log, ffmpeg was killed abruptly, which prevented ffmpeg from flushing out the moov box to the output file. When ffmpeg directly receives a single SIGINT, it will print at the end Exiting normally, received signal 2.. I suspect the SIGINT is received by yt-dl which does not relay it to ffmpeg but kills it, in which case, ffmpeg won't wait for the output trailer to be written. But this is a guess.

[Carl Eugen Hoyos]

Does not look like an issue that can be fixed in FFmpeg.