Hi Marek, I have been using gstreamer 1.11.2 with the following patches applied to gst-plugins-good (to add the encoder element): https://gist.github.com/mihailescu2m/f52a8f4df67a3d796247337ff67211a9 Also gst-plugins-good was compiled --without-libv4l2 This is a pipeline I used to test encoding (mfc-dec on /dev/video10 and mfc-enc on /dev/video11): gst-launch-1.0 filesrc location=~/sintel_trailer-720p.mp4 ! qtdemux ! h264parse ! v4l2video10dec ! v4l2video11h264enc extra-controls="encode,h264_level=10,h264_profile=4,frame_level_rate_control_enable=1,video_bitrate=4097152" ! h264parse ! matroskamux ! filesink location=~/sintel-encoded.mkv I believe this uses all the default MFC encoder options, except: H264 profile, set to High H264 level, set to 3.2 max bitrate set to ~4M (default is unlimited, which results in ~100MB/min files). Cheers, Marian > On 22 Mar. 2017, at 8:10 pm, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > Hi Marian, > > On 2017-03-22 10:33, Marian Mihailescu wrote: >> Hi, >> >> I was testing with the linux-next kernel + the v2 patches >> HW: odroid xu4 >> decoding (working): tested with gstreamer >> encoding: tested with gstreamer && mfc-patched ffmpeg >> before patches: encoding worked >> after patches: encoding didn’t work. >> >> I moved on from linux-next in the meantime and I cannot give you logs, BUT I’ve seen Hardkernel applied these patches (and all the linux-next MFC patches) on top of their 4.9 tree, and the result is very similar to mine on linux-next: https://github.com/hardkernel/linux/issues/284 >> >> Mar 21 13:04:54 odroid kernel: [ 37.165153] s5p_mfc_alloc_priv_buf:78: Allocating private buffer of size 23243744 failed >> Mar 21 13:04:54 odroid kernel: [ 37.171865] s5p_mfc_alloc_codec_buffers_v6:244: Failed to allocate Bank1 memory >> Mar 21 13:04:54 odroid kernel: [ 37.179143] vidioc_reqbufs:1174: Failed to allocate encoding buffers >> >> >> A user reported even adding s5p_mfc.mem=64M did not make the encoder work. >> Any thoughts? > > Thanks for the report. Could you provide a bit more information about the encoder configuration (selected format, frame size, etc). 23MiB for the temporary buffer seems to be a bit large value, but I would like to reproduce it here and check what can be done to avoid allocating it from the preallocated buffer. > > > > >> Thanks, >> M. >> >> (resent in plain text format) >> >>> On 17 Mar. 2017, at 10:36 pm, Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: >>> >>> Hi Marian, >>> >>> On 15.03.2017 12:36, Marian Mihailescu wrote: >>>> Hi, >>>> >>>> After testing these patches, encoding using MFC fails when requesting >>>> buffers for capture (it works for output) with ENOMEM (it complains it >>>> cannot allocate memory on bank1). >>>> Did anyone else test encoding? >>> I have tested encoding and it works on my test target. Could you provide >>> more details of your setup: >>> - which kernel and patches, >>> - which hw, >>> - which test app. >>> >>> Regards >>> Andrzej >>> >>> >>>> Thanks, >>>> Marian >>>> >>>> Either I've been missing something or nothing has been going on. (K. E. Gordon) >>>> >> >> > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland
