Video artefacts on full hd recording on rpi2

[Peter Maersk-Moller]

Hi Ivan.

There may be an error in GStreamers OMX video encoder.

The documentation for the OpenMax Video Encoder for the Raspi specify the
following:

nSliceHeight must be the same as nFrameHeight rounded up to the nearest
multiple of 16. nStride must be a multiple of 32.

However in source code for gstomxvideoenc.c I see this:

  port_def.format.video.nFrameWidth = info->width;
  if (port_def.nBufferAlignment)
    port_def.format.video.nStride =
        (info->width + port_def.nBufferAlignment - 1) &
        (~(port_def.nBufferAlignment - 1));
  else
    port_def.format.video.nStride = GST_ROUND_UP_4 (info->width);       /*
safe (?) default */

  port_def.format.video.nFrameHeight = info->height;
  port_def.format.video.nSliceHeight = info->height;

So in the case of 1920x1080, the code ought to have set the nSliceHeight to
1088 and not 1080. That should be pretty easy to add the code. *However
this have some serious implications that may not be that easy to fix.*
Quite likely setting the nFrameheight to 1080 and nSliceHeight to 1088
means that the buffers sent to the encoder MUST have an image the size of
1980x1080 in the buffer with room for  the size 1980*1088. I don't know if
a module can ask upstream to put an image into a buffer that is large than
the geometry of the image.

Also note the image MUST have a stride that is a multipla of 32. Stride is
number of bytes between first byte in a row until the first byte in next
row. That is not a problem with 1980, but I don't see any code checking
this here. Maybe somewhere else.

There may be a bug here. Please consider filing a bug report and please
drop a link to the bug report her on the list or send it to me.

Best regards
Peter Maersk-Moller


On Tue, Apr 5, 2016 at 4:24 PM, Krutskikh Ivan <stein.hak at gmail.com> wrote:

> Thanks for sharing you experience. I am working with encoder (omxh264enc)
> and it seams to work only with fixed block size (16X16 pixels) So both
> width and height must be divided by 16. I was wondering if It's a fixed
> constant or can be tweaked.
>
> 2016-04-05 15:36 GMT+03:00 Ashish Kumar Mishra <
> ashish.kmishra at dexceldesigns.com>:
>
>> Hi ,
>>
>> w.r.t Green artifacts and based on my limited experience :-
>> 1) We have observed similar problem when the decoder was not able to
>> properly handle the signals .
>> Now here the decoder might not be in a position to handle the given
>> resolution or the configuration (timing of decoder ) is not proper.
>>
>> 2) w.r.t link , below is the info from the wiki page
>> "....... Note also that allowing the highest resolutions does not imply
>> that
>> the GPU can decode video formats at those; in fact, the Pis are known to
>> not
>> work reliably for H.265 (at those high resolution, at least), commonly
>> used
>> for very high resolutions (most formats, commonly used, up to full HD, do
>> work)..."
>>
>> 3) Since i have never worked with RPI board , not sure of the behavior at
>> WUXGA resolution.
>>
>> Probably some senior group member might have faced similar problem and can
>> provide some pointers for this thread.
>>
>>
>>
>> --
>> View this message in context:
>> http://gstreamer-devel.966125.n4.nabble.com/Video-artefacts-on-full-hd-recording-on-rpi2-tp4676755p4676764.html
>> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160405/ad7e453d/attachment.html>