KDENLIVE cannot make proxy from DJI Mini5 -files

Help
1

I’ve got a new drone - a DJI Mini5 Pro.
It produces either MP4-videofiles or D-LOGM-videofiles.

When I copy the files to my PC and import them into KDENLIVE, it cannot create proxys of them. This is the same wether it’s a MP4-video, or a D-LOGM-video = no proxy.

KDENLIVE states this errormessage:
[mov @ 0x62602b685240] Could not find tag for codec h264 in stream #1, codec not currently supported in container
[out#0/mov @ 0x62602b655740] Could not write header (incorrect codec parameters ?): Invalid argument
Error while filtering: Nothing was written into the output file 0 (because at least one of its streams received no packets).
frame= 0 fps=0.0 q=0.0 Lsize= 0kB time=-00:00:00.00 bitrate=N/A speed= 0x

What’s wrong?
Is there anything I can do to help out this issue?

Best regards
Carsten

2

yea i have the same problem i use handbrake and than its of some reason working

3

I found this link which seems to explain what is happening. Since this is drone footage, I wonder if stream #1 contains non-video data (gyro info, GPS, etc.); if so, Kdenlive would choke as it doesn’t know what to do with it. That would also explain why when marix passed his footage into Handbrake, his issues were solved, as the video stream got rearranged or something.

Assuming you have ffmpeg installed, could you run ffmpeg -i (filename)in the terminal with your video and paste the output?This is very useful for seeing what is in each stream.

4

It won’t be that this data exists in the file as such, I have lots of footage containing data streams like that, in some cases several of them in addition to the A/V streams, and there’s been no problems with any of it.

But there may indeed be some assumption about layout being violated somewhere. The usual layout I tend to see is video in stream 0, audio in stream 1, then data in some number of streams following that.

If the drone has no audio, then it would make sense that the telemetry begins in stream 1. It’s not immediately obvious what chokes on that or why, but I think you’re on the right track.

Is it only proxy creation that is the problem? Can you import and edit the files just fine?

It would probably be helpful if someone with one of the affected devices could create a minimal example file for testing (just a couple of seconds of footage in a small file that reproduces the problem) - and attach that to a bug report.

You can link back to the bug report here for general discussion and reference for others who might also see this here.

5

Hi everyone
Sorry for being away so long.
I will try to answer your requests:

  • It works fine to make/render videos with the files from the drone. It seems only to be a problem with KDENLIVE making proxyfiles.
  • I don’t have Handbrake - Didn’t even know it existed. Is that now a must-have to solve this issue?
  • I’ve run ffmeg -i on one of the drone-videos, and got this result:
ffmpeg version 6.1.1-3ubuntu5+esm7 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13 (Ubuntu 13.3.0-6ubuntu2~24.04)
  configuration: --prefix=/usr --extra-version=3ubuntu5+esm7 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --disable-omx --enable-gnutls --enable-libaom --enable-libass --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libharfbuzz --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-openal --enable-opencl --enable-opengl --disable-sndio --enable-libvpl --disable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-ladspa --enable-libbluray --enable-libjack --enable-libpulse --enable-librabbitmq --enable-librist --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libx264 --enable-libzmq --enable-libzvbi --enable-lv2 --enable-sdl2 --enable-libplacebo --enable-librav1e --enable-pocketsphinx --enable-librsvg --enable-libjxl --enable-shared
  libavutil      58. 29.100 / 58. 29.100
  libavcodec     60. 31.102 / 60. 31.102
  libavformat    60. 16.100 / 60. 16.100
  libavdevice    60.  3.100 / 60.  3.100
  libavfilter     9. 12.100 /  9. 12.100
  libswscale      7.  5.100 /  7.  5.100
  libswresample   4. 12.100 /  4. 12.100
  libpostproc    57.  3.100 / 57.  3.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x58dc13ff0e40] stream 0, timescale not set
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'DJI_20260306164147_0018_D.MP4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    creation_time   : 2026-03-06T15:41:47.000000Z
    encoder         : DJI Mini5Pro
  Duration: 00:00:30.41, start: 0.000000, bitrate: 95358 kb/s
  Stream #0:0[0x1](und): Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(tv, bt709), 3840x2160, 89957 kb/s, 59.94 fps, 59.94 tbr, 60k tbn (default)
    Metadata:
      creation_time   : 2026-03-06T15:41:47.000000Z
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Data: none (djmd / 0x646D6A64), 149 kb/s
    Metadata:
      creation_time   : 2026-03-06T15:41:47.000000Z
      handler_name    : CAM meta
  Stream #0:2[0x0]: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 960x540 [SAR 1:1 DAR 16:9], 90k tbr, 90k tbn (attached pic)
At least one output file must be specified

Can you make any conclusions of that?

6

Thanks - yeah this seems like a real bug, so please do file a report for it (see the instruction at the link I posted above). We don’t actually track bugs in this forum, but it was the right place to bring it up and get initial confirmation. If you can create a small test file (just a few seconds of sharable footage) to attach there too that would be a great help.

I don’t have Handbrake - Didn’t even know it existed. Is that now a must-have to solve this issue?

Until it’s actually fixed, you can probably remove the offending stream with ffmpeg, something like this. In your case copying only the stream 0 video.

Though it looks like that file might also contain a low res preview in stream 2 - so it might also be possible to extract that stream (in the same manner with ffmpeg) to use as an external proxy file instead of needing Kdenlive to generate one.

We don’t currently support proxies in the same container as the original, so you’d need to split those into a separate file - but if they are of good enough quality to use as editing proxies, that might be a useful feature request to consider too.

7

This bug has already been resolved and the fix will be available in the next release due next month. In the meantime you can test the fix using this appimage.