I wanted to try out the Video Editing in Blender, but when I go to drag in a MP4 file or a MKV file either from file manager or just from opening within Blender itself, Blender won’t let me add it and gives me an error saying “File could not be loaded.” when trying to import it to the timeline.
I am using Blender 3.1.0 | c77597cd0e15 on Manjaro Linux. 5.15.28-1-MANJARO
This is going to yet turn into a dead-end discussion with no answers, which means future people who look up this issue are just going to run into this post in the future with no answers.
You’re not wrong. I’m getting the same ‘could not be loaded’ error.
I’ve narrowed the issue down to Blender not supporting AV1-encoded .mp4 files but I don’t know if that’s the real issue. H264-encoded files work but AV1-encoded files don’t. I tested it on Blender 4.5 and Blender 5.0. I’m on Windows 11.
Blender uses ffmpeg.
You may not be able to use codecs not supported by ffmpeg.
If other codecs are supported (testing is required), you will need to have them installed on your system to use them.
Well, the AV1 codec is supported by FFmpeg and is even an option for exporting in Blender.
I also checked whether I have the codec installed on Windows 11, and I do.
I don’t see how this is even a problem given that Blender natively supports the codec.
Yeaaah, coincidentally I also encoded a test render from Blender with AV1 and that works as well.
To be specific, I’m trying to import a video with the AV1 codec encoded by Nvidia Shadowplay. I’ll have to look at how Shadowplay encodes its videos, I think.
I never had to look into this but Nvidia Shadowplay uses a NVENC hardware encoder. Perhaps this specific encoder does something that Blender doesn’t like/support? I really have no clue.
It’s worth noting that Shadowplay files encoded in the H264 codec works just fine in Blender.
Encoding errors seem to have been experienced in other software as well.
While this issue isn’t common, it’s still a risk.
It could be a hardware issue, or it could be due to a codec with poor compatibility.
This is why we recommend outputting image sequences.
Since we don’t know the exact cause, it’s difficult to say whether this is a simple error.
If it occurs repeatedly and under specific conditions, it could be considered a bug.
However, if it occurs randomly, it could be an encoding error.
Add…
When testing with a simple scene, there were no issues with the output.
However, I observed a significant difference between AV1 and H.264.
The test was conducted on EEVEE.
AV1 often had low GPU usage and high CPU usage.
H.264 had high GPU usage and consistent CPU usage.
In this test, AV1 exhibited what is commonly referred to as lag.
You can see pauses at certain intervals.
This could be due to my hardware, but the difference is clear.
While I agree that image sequences are superior for compositing workflows, it doesn’t really matter in this case because the source footage is captured in video format. Having to convert our video footage to an image sequence just so it can be imported into Blender is tedious.
Furthermore, the topic is not concerned with which codecs to use for Blender export. We’re simply wondering why Blender is being selective with the .mp4 files it can import and add to the sequencer timeline – seemingly not based on codec, but encoding.
In my case, none of my footage captured with AV1 encoding through Nvidia Shadowplay is accepted by Blender while older H264-encoded footage is accepted without issue.
P.S. I submitted a ticket with Nvidia Support to see what they have to say.
Only the most recent GPU generations (Nvidia/AMD and Intel) have AV1 decoding built into the GPU chip and as such, unless you are running one of those very latest GPU’s with supporting drivers, AV1 decoding will have to be done on the CPU. Which is likely to put a fairly big load on the CPU.
On the other hand, GPU’s have been able to hardware decode and in many cases, encode, H.264 for some time. H.265 has also been covered for a while now, it’s just that AV1 is ‘pretty new’, so way less supported at the moment.
Can you chill a little bit please? You’re getting a ton of time and effort from unpaid volunteers trying to help you, the least you can do in return is be appreciative
The ability to produce a format correctly according to some specification has nothing to do to be able to read this format from a maybe not so correctly produceing “combatant”.
Also: there was initially no information from what exactly this was captured. So when Shadowcapture (SC) did produced “acceptable H264”, assuming this was also done with SC because the reply only states:
then this may simply be a more standard conform encoding in SC or a more forgivable implementation of th decoding on the FFmpeg side ? IDK…
So maybe a more in-depth analysis is needed. In fact FFmpeg can give some more information via the ffprobe command.
I don’t mean to come off as rude but it’s frustrating when people don’t read the entire topic and then proceed to help with a problem that’s not even posted in here. The fact that someone else refers to Nvidia Shadowplay as “Shadowcapture” just proves my point.
I appreciate your reminder, and next time I’ll let out my frustration with constructive criticism instead of a childish outburst.