Try using --fixup never. If it solves your issue, the problem is probably the same as #618 (comment). It is pervasive enough that I have considered changing the default downloader back (or setting --fixup never as default). But in the end, the proper solution is to have this issue be addressed by ffmpeg and not us.

'--fixup never' results in an almost complete download.
ffprobe for the downloaded file with the above:
[aac @ 0x55eccb85c080] Estimating duration from bitrate, this may be inaccurate
Input #0, aac, from 'Guilt - Episode 1 [3058097753].mp4':
Duration: 00:51:52.70, bitrate: 160 kb/s

ffprobe when using '--downloader ffmpeg':
Duration: 00:51:58.46, start: 0.000000, bitrate: 158 kb/s
without the 'estimating duration' warning

The timestamps in the file provided by server needs to be corrected (hence the wrong duration without fixup). ffmpeg does it correctly when using it as a downloader. But when asked to do it on an already downloaded file, it totally breaks the file at the point where the timestamp correction is needed. This issue does not exist in ffmpeg 3.0.1, only in later versions. So it is a regression afaik.

I do not know enough about the internal workings of ffmpeg to know what caused this to break or whether there is any workarounds. But it could be possibly related to ytdl-org/youtube-dl#28042 (see #871 (comment)) but the patch for that issue doesn't fix this. So I am not sure

Actually, 'fixup never' leaves a .mp4 container with the 00:51:52.70 duration as previously shown.
If I extract the audio in that .mp4 download, the resulting is Duration: 00:04:12.29.
With '--downloader=ffmpeg' it is Duration: 00:51:58.46

Let me try downloading it. I'll get back to you

You are correct that video players are unable to play the audio after the 4min mark. However, performing fixup with ffmpeg3.0.1 gave me the corrected file with a full 52:09 duration. So this is the exact same issue as #618

Have you tried comparing the outputs of ffprobe -show_packets -show_frames -show_format -show_data between FFmpeg downloader and native downloader pre- and post-fixup?

I suspect the whole brokenness might as well be a bug in the native downloader. (Compare #637.)

Good news is that native hls downloader worked when using latest static build of ffmpeg I downloaded from https://johnvansickle.com/ffmpeg/
ffmpeg N-58863-g715f63232f-static, ffprobe N-58863-g715f63232f-static

As 'latest' is the only ffmpeg supported by the ffmpeg community I vote for closing this issue.

It is used as a final step - look at the last three lines of the verbose log

Yeah, I already deleted my comment because I realized that.

Great, I can confirm that the latest builds do in fact fix this. My ffmpeg build was just a few weeks old, so it is probably a recent fix.

I'm not interested enough to go though the ffmpeg commits and figure out which one fixed it, but if anyone knows, let me know (just out of curiosity)

@fstirlitz You could argue that it is the native downloader's fault - in the sense that the native downloader doesn't have the capability to fix the timestamps. But we know this is a potential issue when downloading hls streams. This is why we pass it to ffmpeg for fixup

The root cause of this issue is: https://trac.ffmpeg.org/ticket/9433
A patch has been submitted to ffmpeg devs: https://patchwork.ffmpeg.org/project/ffmpeg/patch/[email protected]
and this patch has been added to our custom ffmpeg builds: https://github.com/yt-dlp/FFmpeg-Builds

250a938 also implements a workaround for the issue which should work even without the above mentioned patch

Just wanted to point out that 250a938 doesn't fix it for all sites (still get issues with Funimation) but using the custom ffmpeg builds does.

this is NOT fixed, I just encountered this problem while downloading a long stream from youtube

@Zerogoki00 If you're talking about a livestream, it would be an unrelated issue since the native HLS downloader is not used for livestreams. Either way, you should open a new issue with a verbose log