#9048 closed defect (needs_more_info)
FFmpeg crashing
Reported by: | joblow | Owned by: | |
---|---|---|---|
Priority: | important | Component: | ffmpeg |
Version: | unspecified | Keywords: | Crash |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
FFmpeg crashes a lot.
- Generally I convert videos from youtube. Every once in a while I get a crash, maybe 1 out of 100. The crash occurs consistently on the same file but sometimes changing the quality settings will get it to convert.
- I have some realmedia files that crash all the time. I can't get them to convert. I have a few hundreds and about half convert and the other half will not even with different quality settings. Sometimes changing the quality will convert but most of the time it will not.
This seems to be a problem with FFmpeg. 1. It shouldn't crash. 2. It probably should be able to handle the videos. I can play them just fine.
Stream mapping:
Stream #0:1 -> #0:0 (rv20 (native) -> hevc (libx265))
Stream #0:0 -> #0:1 (sipr (native) -> aac (native))
Press [q] to stop, ? for help
x265 [info]: HEVC encoder version 3.4+2-73ca1d7be377
x265 [info]: build info [Windows][GCC 10.2.1][64 bit] 8bit+10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-2 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(4 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-29.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
These are the commands passed to ffmpeg
-threads 4 -f mp4 -movflags +faststart -c:v libx265 -framerate 30 -crf 30 -c:a aac -b:a 64k -af aresample=resampler=soxr -ar 44100
changing crf to different values may allow the file to convert rather than crash ffmpeg.
I am attaching a video that produces the crash using those settings.
Attachments (1)
Change History (8)
by , 4 years ago
Attachment: | ffmpeg crash.txt added |
---|
follow-up: 2 comment:1 by , 4 years ago
Resolution: | → needs_more_info |
---|---|
Status: | new → closed |
Invalid report, missing full log and version of ffmpeg.
comment:2 by , 4 years ago
Resolution: | needs_more_info |
---|---|
Status: | closed → reopened |
Replying to richardpl:
Invalid report, missing full log and version of ffmpeg.
Um, it does it with all versions. I gave the damn links to videos, why the hell can't you just try to convert it with the command line to generate your own damn report... fucking lazy bastards! I take the time out to upload all this shit and you want to close it because you don't have a useless report.
You are a lazy fucktard and don't give as hit about actually making ffmpeg. Your just looking for any reason to not actually do any work.
FFMPEG IS CRASHING YOU STUPID FUCK! Do you even know what that means? Or are you some dumbass CS major that is trying to get browning points so you can put "FFMPEG developer" on your resume to pretend you actually have a clue?
comment:3 by , 4 years ago
The file is invalid it warns:
[rv20 @ 000001ebd3b409c0] reserved bit set time=00:01:21.50 bitrate= 77.2kbits/s dup=478 drop=320 speed=17.9x [rv20 @ 000001ebd3b409c0] HEADER ERROR Error while decoding stream #0:1: Invalid data found when processing input [rv20 @ 000001ebd3b409c0] concealing 19 DC, 19 AC, 19 MV errors in B frame More than 1000 frames duplicated 2048kB time=00:02:47.85 bitrate= 100.0kbits/s dup=959 drop=685 speed=17.5x [rv20 @ 000001ebd3b409c0] reserved bit set time=00:05:54.10 bitrate= 118.4kbits/s dup=1994 drop=1424 speed=16.4x [rv20 @ 000001ebd3b409c0] HEADER ERROR Error while decoding stream #0:1: Invalid data found when processing input [rv20 @ 000001ebd3b409c0] concealing 7 DC, 7 AC, 7 MV errors in B frame Error while decoding stream #0:1: Invalid data found when processing inputkbit
also this file is H.263, which is so damn old.
comment:4 by , 4 years ago
Resolution: | → needs_more_info |
---|---|
Status: | reopened → closed |
Very professional entry from some "corporate" user. You provided zero interest to give actual proof that bug happens inside ffmpeg code. It could be anywhere but not in FFmpeg code.
Also I downloaded your files and they have some issues but otherwise decode just fine with ffmpeg.
Please refrain from personal attacks.
follow-ups: 6 7 comment:5 by , 4 years ago
Hmmm,
I can't get them to convert.
I can also successfully convert all of the two your realmedia to hevc. Interesting is the second file, Based on G.722.1, Real Player 6
G.722.1, holy s*! Well, it should be supported though perfectly.
Try to use https://github.com/BtbN/FFmpeg-Builds/releases/download/autobuild-2020-12-31-12-37/ffmpeg-N-100501-g477dd2df60-win64-gpl-shared-vulkan.zip and it will work (you should have used those anyway to report this bug).
comment:6 by , 4 years ago
Replying to Balling:
Hmmm,
I can't get them to convert.
I can also successfully convert all of the two your realmedia to hevc. Interesting is the second file, Based on G.722.1, Real Player 6
All the files were downloaded several years ago, hence why I am trying to convert them. Not all of them crash and I can always seem to convert them depending on which settings I used so you might have just got lucky.
G.722.1, holy s*! Well, it should be supported though perfectly.
Try to use https://github.com/BtbN/FFmpeg-Builds/releases/download/autobuild-2020-12-31-12-37/ffmpeg-N-100501-g477dd2df60-win64-gpl-shared-vulkan.zip and it will work (you should have used those anyway to report this bug).
The point is that ffmpeg crashes, to claim it is not crashing when it is clearly crashing is asinine. When windows pops up and says ffmpeg crashed and I ran it from the command line what else could it be? Sure it might be the build. I have tried several different builds over the years and all have this problem. It is also not just these files, I have always had issues.
There is definitely a bug in ffmpeg. IT SHOULD NOT CRASH regardless. I will try your link though, the file is 350MB while the vulkan latest build I used from the ffmpeg site gave 95MB which I was upgrading from a 80MB version(do not remember the versions nor will I go look them up as it is pointless).
While it could be a compatibility issue with my system(video card or whatever) FFMPEG SHOULD NOT CRASH. A crash is clearly a bug ALWAYS.
If you can't produce the crash then, well, can't do much. I hope you used the command line I used though else it is kinda pointless.
I will try your build and if it doesn't fix it then I will reopen this and ask you that you try to convert the files again with the correct command line and different crf's. Again, sometimes it works. I usually can eventually get a batch of files converted after trying several crf's. My settings is usually from 30-35. I start off with 30, about half the files usually convert, then I go to 31 and a quarter to a half convert and I work my way up. Sometimes I have to go below 30. FFMPEG crashes every time! It does report issues with the media but then why would it convert it eventually when changing crf?
comment:7 by , 4 years ago
Replying to Balling:
Hmmm,
I can't get them to convert.
I can also successfully convert all of the two your realmedia to hevc. Interesting is the second file, Based on G.722.1, Real Player 6
G.722.1, holy s*! Well, it should be supported though perfectly.
Try to use https://github.com/BtbN/FFmpeg-Builds/releases/download/autobuild-2020-12-31-12-37/ffmpeg-N-100501-g477dd2df60-win64-gpl-shared-vulkan.zip and it will work (you should have used those anyway to report this bug).
so I upgraded, this was essentially the build I used several days ago:
specifically I used
ffmpeg-N-100493-gc720286ee3-win64-gpl-vulkan.zip
[Of course I've been having this problem for years]
It seems that the link you gave is better though. Not sure if it is recent updates, or if it is because the files I'm recoding just happen to work or what. I am still getting crashes, but it's about 2-5% now rather than 20-50%.
[Update] Must have been those specific files because after that batch finished the new one is crashing a lot.
[Update] So, it seems to crash a less. I don't know if it's just coincidence but out of about 100 files it's crashed 10-20%. Again, regardless it shouldn't crash.
Includes links because of the 2.5MB limit.