jc-kynesim / rpi-ffmpeg

FFmpeg work for RPI
Other
111 stars 27 forks source link

v4l2_buffer_swframe_to_buf: Plane total 6220800 > buffer size 5529600 #28

Open jacaru opened 2 years ago

jacaru commented 2 years ago

@jc-kynesim Trying this with a ffmpeg build included with raspbian os on raspberry pi 4 B:

ffmpeg -hwaccel drm -codec:v hevc -i jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv -codec:v h264_v4l2m2m -pix_fmt yuv420p t.mp4

error:

v4l2_buffer_swframe_to_buf: Plane total 6220800 > buffer size 5529600

Sample: https://jell.yfish.us/media/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv

Full debug log: https://gist.github.com/jacaru/e57df5b22bd21d660f36b7051dda7997

ggregory8 commented 1 year ago

Did you get a resolution on this one? I am getting a similar error of Plane total xx > buffer size xx (although my values are different) when trying to record video 3840x2160 cropped down to 2160x820.

jc-kynesim commented 1 year ago

I'll have a look. Can you give me a complete command line and sample clip please. My first thought is "is that meant to work?" given that I don't think that the Pi H264 encoder is rated above HD. I'll double check but I suspect that the bug may be that the encoder should have rejected the stream at init rather than waiting to fail later.

ggregory8 commented 1 year ago

Ok is there a resolution limit on the h264_ encoder? I can't find any documentation on this. I.e is there somewhere you can increase the buffer size? Full command line below and I don't have a sample clip as the video source is USB UVC camera: ffmpeg -y -hide_banner -f v4l2 -pix_fmt yuv420p -video_size 3840x2160 -i /dev/video0 -r 7.5 -c:v h264_v4l2m2m -pix_fmt yuv420p -filter:v "crop=2160:2160:820:0" -an vid_high_res.mp4 And output is below.

[video4linux2,v4l2 @ 0x2b93340] Dequeued v4l2 buffer contains corrupted data (0 bytes).
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 0.000000, bitrate: 1990656 kb/s
  Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, 3840x2160, 1990656 kb/s, 15 fps, 15 tbr, 1000k tbn
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_v4l2m2m))
Press [q] to stop, [?] for help
[video4linux2,v4l2 @ 0x2b93340] Dequeued v4l2 buffer contains corrupted data (0 bytes).
    Last message repeated 30 times
[h264_v4l2m2m @ 0x2b96490]  <<< v4l2_encode_init: fmt=0/-1
[h264_v4l2m2m @ 0x2b96490] Using device /dev/video11
[h264_v4l2m2m @ 0x2b96490] driver 'bcm2835-codec' on card 'bcm2835-codec-encode' in mplane mode
[h264_v4l2m2m @ 0x2b96490] requesting formats: output=YU12 capture=H264
Output #0, mp4, to 'vid_high_res.mp4':
  Metadata:
    encoder         : Lavf59.27.100
  Stream #0:0: Video: h264 (avc1 / 0x31637661), yuv420p(tv, progressive), 2160x2160, q=2-31, 200 kb/s, 7.50 fps, 15360 tbn
    Metadata:
      encoder         : Lavc59.37.100 h264_v4l2m2m
v4l2_buffer_swframe_to_buf: Plane total 7050240 > buffer size 6266880
[h264_v4l2m2m @ 0x2b96490] Enqueue frame failed: Operation not permitted
Error submitting video frame to the encoder
Conversion failed!
jc-kynesim commented 1 year ago

A quick search yielded the info that the encoder is specced to L4.1 which gives a limit of 8192 16x16 macroblocks. I think your crop option there is asking for 2160x2160 @ 820,0 which isn't what you said you meant. 2160x2160 is definitely outside the limit - though I agree that 2160x820 should be inside. I'll look at what is actually happening, fix anything that can be fixed and try to improve early rejection with clearer error messages if this can't be done due to encoder limitations.

ggregory8 commented 1 year ago

Ok thanks for the info. Do you mind sharing where you go the specs on the h264_v4l2m2m encoder. As mentioned I can't seem to find this.

jc-kynesim commented 1 year ago

OK - I now have more info. You are limited to 1920 in both width and height by the V4L2 kernel driver. The h/w has limitations that prevent > 2048 but there are other issues that mean that you can't have 2048 so we are stuck with a slightly lower limit. This is an old block (probably the same block that was in Pi1) and whilst it might be clocked a little faster than when first sold it hasn't changed otherwise.

I've fixed ffmpeg so it now checks the dimensions at init and gives a less misleading error message - the fix will be in the next release.

For my initial comments I searched in the raspberry pi forums and that it probably the best place to get questions like "what is the spec on the encoder" answered.