Second thing I noticed is that flushing is broken for v4l2m2m encoders.
> avcodec_send_frame(enc_ctx, NULL);
should return AVERROR_EOF instead of continuing with an empty AVPacket with
size=0.
Hope we can get this fixed.
Roland
___
ffmpeg-devel
After some investigation I came to the conclusion, that av_frame_get_buffer
does not allocate the buffers correctly.
1. frame->pix_fmt=AV_PIX_FMT_NV12 frame->width=64 frame->height=64
2. so we need a buffer with 2 planes of same size. First plane holds Y and
second plane holds U and V
I compiled ffmpeg with debug flags:
> ./configure --prefix="/opt/ffmpeg" \
>--pkg-config-flags="--static" --disable-programs --disable-doc \
>--enable-gpl --enable-static --enable-pic --enable-v4l2_m2m \
>--disable-optimizations --disable-mmx --disable-stripping
> Run:
> $ gdb -ex r --args ./encode_video out h264_v4l2m2m
>
> At the core dump, type "bt" and press return. Post that backtrace. Or
> analyze it, if you know what you are doing.
Hi Moritz,
thanks for the quick reply. I tried to debug the problem already, but the
problem lies within
On Thu, Dec 20, 2018 at 18:24:07 +0100, Roland Singer wrote:
> hope somebody can help solving a segmentation fault caused by using the
> h264_v4l2m2m encoder on an Samsung Exynos5422.
[...]
> > # ./encode_video out h264_v4l2m2m
Run:
$ gdb -ex r --args ./encode_video out h264_v4l2m2m
At the core
Hi,
hope somebody can help solving a segmentation fault caused by using the
h264_v4l2m2m encoder on an Samsung Exynos5422.
I tested the encoder using the unmodified examples (git master):
- encode_video.c
- transcoding.c
> # ./encode_video out h264_v4l2m2m
> [h264_v4l2m2m @ 0x49e150] driver