Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
ffmpeg - "Fixing malformed AAC bitstream" eventually corrupts the audio or deletes it #15802
Comments
|
Try to upgrade ffmpeg 3.2 to the newer 3.4.2. To disable fixing the aac stream use: --fixup warn |
|
I will try both of these and test again. Thank you for the quick reply! I was hesitant to turn this into a bug report, but I do have one question. I know it may not be a widespread issue, but would it be prudent to include this parameter as a default option instead of fixing it up by default? EDIT: I guess I should have taken more action on my part by upgrading ffmpeg before submitting this. Sorry about that. Again, I'll test and see if either of these suggestions help me. |
|
Updating ffmpeg to 3.4.2 still makes it detect the AAC stream as malformed and will eventually delete it. The option Either way, this has solved my problem. Thank you for the information. This program is probably the best one I've ever found, so thank you for your hard work and for keeping it up-to-date! |
|
A) The deletion of the video/audio streams at the end of processing has absolutely nothing to do with FFmpeg. It's youtube-dl that cleans up the streams after having FFmpeg mux them together. The deletion message even tells you that if you want to keep the original streams around, you have to use the -k parameter. B) The AAC fixup is not autodetected by probing anything. It's required whenever certain types of remuxing occur, because the AAC bitstream has to be manipulated in order to correctly mux into MP4 and related containers. Right from the FFmpeg documentation: Note the requirement when copying from MPEG-TS. HLS streams use MPEG-TS as their payload container (not sure if DASH does as well, but it wouldn't surprise me). There is no way to escape that, and even if youtube-dl wasn't passing -bsf:a aac_adtstoasc by default, FFmpeg would still automatically insert it whenever the output format is MP4 or related. The problem (whatever it is here; why are you re-running the process four times?) is more that youtube-dl does all of these steps - applying the bitstream filter to the AAC stream, embedding subtitles, embedding metadata) in extra consecutive passes instead of in one pass at the very end when all the data has been collected. Doing it the way youtube-dl currently does adds needless extra time to the entire process, because it remuxes the output file two or three times in a row. And if audio somehow is going missing during this process, it's likely because of all these extra remuxing steps, not anything FFmpeg is doing. |
|
Let me start out by explaining why I re-run the process multiple times. When downloading videos from Crunchyroll, I input a playlist. Instead of finding every single video URL and putting it into a text file for processing, I just put in the name of the anime that I want to download, and youtube-dl does the rest. I start the download at work, and it gets through about 1/4 of them before I either have to leave or pack up my laptop to go somewhere else, hence why I just re-run my batch file full of parameters whilst I do other things and it processes files multiple times. I may not know much about video and audio formats, but I can tell you that Crunchyroll does not use DASH and it does not have to mux the video and audio streams as separate files together, as it is served as one file, but you should know this already by looking at my logs posted above. Also, after testing by making FFmpeg remux the file about 20 times using youtube-dl (very unnecessary, I know, it's just for testing) and telling youtube-dl to not fix up the AAC bitstream using Regardless, my issue was fixed by using |
|
Use |
|
Ah, so that's what that option is for... I guess I should have experimented with it. Does this require any other params to store the ID's, or does this option store the ID's inside the file without any further params? |
|
No, only a filename for an archive file. Archive file stores everything needed. |
|
Very good to know. Thank you very much for this information! Sorry that it had to be in a bug report, and my first one at that. |
Make sure you are using the latest version: run
youtube-dl --versionand ensure your version is 2018.03.03. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.Before submitting an issue make sure you have:
What is the purpose of your issue?
Description of your issue, suggested solution and other information
If one tries to download a file, whether it be from YouTube, Crunchyroll, or otherwise, successive downloads will delete the audio after some time. I believe it is from ffmpeg trying to fix a "corrupt" AAC audio stream when it's actually just fine, as you can see from the logs above. The 3rd run will remove the audio (or corrupt it, not sure which) of the downloaded video, upon which you can see in the 4th run that it no longer exists or sees that it's there.
Does youtube-dl run ffprobe to see if the downloaded files are fine? If so, maybe a simple solution would be to add an option to disable verification of downloaded streams. I'm not sure on how most of this works, but that's my two cents.