<div dir="ltr"><div><div><div><div><div><div><div>Hi Ivan.<br><br></div>There may be an error in GStreamers OMX video encoder.<br><br></div>The documentation for the OpenMax Video Encoder for the Raspi specify the following:<br><br><div style="margin-left:40px"><tt>nSliceHeight</tt> must be the same as <tt>nFrameHeight</tt> rounded up
to the nearest multiple of 16. <tt>nStride</tt> must be a multiple of
32.</div><br></div>However in source code for gstomxvideoenc.c I see this:<br><br><div style="margin-left:40px"><span style="font-family:monospace,monospace"> port_def.format.video.nFrameWidth = info->width;<br> if (port_def.nBufferAlignment)<br> port_def.format.video.nStride =<br> (info->width + port_def.nBufferAlignment - 1) &<br> (~(port_def.nBufferAlignment - 1));<br> else<br> port_def.format.video.nStride = GST_ROUND_UP_4 (info->width); /* safe (?) default */<br><br> port_def.format.video.nFrameHeight = info->height;<br> port_def.format.video.nSliceHeight = info->height;<br></span><br></div>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. <b>However this have some serious implications that may not be that easy to fix.</b> 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.<br><br></div>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.<br><br></div>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.<br><br></div>Best regards<br></div>Peter Maersk-Moller<br><div><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 4:24 PM, Krutskikh Ivan <span dir="ltr"><<a href="mailto:stein.hak@gmail.com" target="_blank">stein.hak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. <br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-04-05 15:36 GMT+03:00 Ashish Kumar Mishra <span dir="ltr"><<a href="mailto:ashish.kmishra@dexceldesigns.com" target="_blank">ashish.kmishra@dexceldesigns.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi ,<br>
<br>
w.r.t Green artifacts and based on my limited experience :-<br>
1) We have observed similar problem when the decoder was not able to<br>
properly handle the signals .<br>
Now here the decoder might not be in a position to handle the given<br>
resolution or the configuration (timing of decoder ) is not proper.<br>
<br>
2) w.r.t link , below is the info from the wiki page<br>
"....... Note also that allowing the highest resolutions does not imply that<br>
the GPU can decode video formats at those; in fact, the Pis are known to not<br>
work reliably for H.265 (at those high resolution, at least), commonly used<br>
for very high resolutions (most formats, commonly used, up to full HD, do<br>
work)..."<br>
<br>
3) Since i have never worked with RPI board , not sure of the behavior at<br>
WUXGA resolution.<br>
<br>
Probably some senior group member might have faced similar problem and can<br>
provide some pointers for this thread.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/Video-artefacts-on-full-hd-recording-on-rpi2-tp4676755p4676764.html" rel="noreferrer" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Video-artefacts-on-full-hd-recording-on-rpi2-tp4676755p4676764.html</a><br>
<div><div>Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>