What is an malformed AAC bitstream?

J

Jeddy

Member
I've been trying to use Q Download to download a program which I've done in the past.
This time the program has downloaded but the box crashed while trying to fix an malformed AAC bitstream.
I'm now in a vicious circle of crash, , power off/on, restarting the queued download, downloading video page, json, DPD manifest, m3u8 information, a message the file has already been downloaded, fixing malformed AAC bitstream and crash again!

I can see a program.mp4 of 5.99Gb and a program.temp.mp4 of varying size (it grows before crashing and getting deleted recreated etc.).
Downloading the program.mp4 to my PC it seems to play which makes me wonder what the malformed AAC bitstream is about?

Any thoughts on how to fix etc. please?
Thanks
Jeddy
 
Delete or Hold the problem causing entry in the queue database using the option on the Queue display to prevent it retrying again.
(if it currently running it will run until it crashes but shouldn't restart)
 
Thanks, any idea if there is a problem with program.mp4 which actually needs to be corrected or is it good anyway? What is it trying to fix?
 
Youtube-dl always ends up with a "malformed AAC bitstream", and proceeds to patch it up with FFMPEG. The box will crash if processing uses up too much memory, and 6GB is a pretty big file to process.

swapper helps by setting up swap space on disk.
 
Thanks, I thought it may be size related hence why I mentioned it.

Are there any implications of not fixing the malformed AAC bitstream, deleting the program.temp.mp4 file and just using the program.mp4 file?

If I do need to fix it (to use the mp4), what would be a good size to change the swapfile size to and can I leave it at that long term without other adverse implications?

It's been so long since I've played around with any of this I can no longer recall how to do things like change swapfile sizes, run commands etc., although I suspect that information shouldn't be too hard to find.
 
If you can play the file, including audio, then there is nothing that needs fixing, if you cant then it needs to be fixed!
I think in most cases there is nothing that needs to be fixed
 
For playing locally and then deleting, you can probably skip the "fixing" (--fixup warn, or just use the program.mp4 as-is). Here is the ffmpeg doc for the fixup.

A 256MB swap file solved this for me, but with MP4 files of ~1.7GB (Vigil S2 E5, eg), on a re-built HD-Fox T2 where I'd forgotten to re-enable the swap. See also https://hummy.tv/forum/threads/swapper-virtual-memory.8844/post-171196.

yt-dl could try to roll all ffmpeg operations together (then, if you used ffmpeg as downloader for a single A-V stream, only one ffmpeg command would be run, and no .temp.mp4 files would be seen), but that would mean implementing a much better model of the complex ffmpeg command-line syntax, so will probably never happen.
 
Last edited:
Thanks! I found the file editor and changed 128 to 256 and a different program (around 4.8Gb) which had also been failing the same way has now worked.
The first failing program did appear to play at the start and end so it sounds like I can just use it anyway.
Now onto the remaining programs in the queue. ;)
 
What about adding --fixup never to the config options, and keeping fingers crossed it's not needed?
 
I'm quite cautious and would rather be alerted to a possible problem when I have chance to fix it (re-download the program) rather than when I want to watch it only to find out it doesn't play. Knowing I can just check the program and ignore if needed should suffice for now thanks.
 
Jeddy said:
I'm quite cautious and would rather be alerted to a possible problem when I have chance to fix it (re-download the program) rather than when I want to watch it only to find out it doesn't play. Knowing I can just check the program and ignore if needed should suffice for now thanks.
Click to expand...
But you'll always be alerted. The "malformed bitstream" always occurs, in my experience, so if you are resigned to checking whether the download is playable without the fix then the warning is irrelevant.

Besides, the warning will only be visible in the log file, so you'll still have to go looking for it.

IMO, the best bet is to ensure you have enough swap space and just let it process.
 
Interesting, I'm having trouble getting my head around this though. This is my thinking (which may or may not be valid).

Currently we 'always' get the malformed bitstream message. Currently the fixup checks it and seems to fix it regardless of whether it needed fixing. Either that or crashes trying to do something which may or may not be needed. In this case I notice the crash and can check if the fix is needed and potentially try downloading again if it is and I can't stop the crash.

However if I apply the fixup never then I just get the initially downloaded .mp4 which will usually be valid, but also may not be and I may not find out until the download is no longer available to redo, unless I check every download.

Hoping that makes sense, if I've understood things?
 
I think that's about it. As with most things in life, if the ideal is unobtainable (as usual), it's a question of deciding which is least-worst according to your own personal criteria. With a big enough swap file, it shouldn't crash, so is it better just to run stream fix regardless knowing that the result is bullet-proof? Something else you might try is to prevent the stream fix deleting the original file, then you get the best of both worlds.

I mean, from my own personal perspective, I have to question the wisdom of downloading 6GB files with the Humax in the first place, at least any more than just occasionally.
 
It seems that during the crash loop the original .mp4 never gets deleted so at least I didn't have to keep downloading that, it detected it was already downloaded and just proceeded to attempt to fix it again. If I do abandon a fix then I'm left with both files so after checking the original would just delete the smaller invalid .mp4

As for the wisdom of downloading 6Gb, well yes, I can't really argue with that, but when there is a 3hr 20min program on iplayer you want to have... ;) Obviously films of that length are unusual, well used to be very ususual, but films do seem to be getting longer these days. Mind, having said which I struggle to understand modern films anyway, there is usually so much going on and so many plots and stories I loose track - but that's another matter.
Thanks again!
 
Another way forward could be to use --hls-prefer-ffmpeg --hls-use-mpegts --external-downloader-args "-mpegts_m2ts_mode true". How would this help?
1. The fixup is only applied when the native downloader is used and --fixup ... does not disable it, or, regardless of --fixup ..., if the ffmpeg downloader sees that it is writing AAC audio from HLS to a .mp4 container.
2. In this build of yt-dl the native HLS downloader has to invoke wget for each fragment, so downloading with one invocation of ffmpeg should be more efficient: hence --hls-prefer-ffmpeg.
3. Specifying --hls-use-mpegts forces the ffmpeg output to be a .ts container, which does not need or get any AAC fixup.
4. Specifying --external-downloader-args "-mpegts_m2ts_mode true" forces the .ts container to conform to MPEG2TS, the native format for off-air "recordings". You might then be able to integrate your qtube downloads with "recorded" videos, by creating the necessary sidecar files.

You should also ensure that the format selection will pick HLS rather than DASH or other types of download, by adding [protocol^=m3u8] to the format selection.
 
I don't think a "malformed AAC bitstream" has actually been detected it is blindly applying a fix in case one does exist
 
You must log in or register to reply here.
Back
Top