Video artefacts on full hd recording on rpi2

[Krutskikh Ivan]

Hi,

I'm experiencing something like http://stackoverflow.com/questions/33255390/gstreamer-artifacts-at-160x120

With pipeline

v4l2src do-timestamp=true name=source  ! omxh264enc target-bitrate=20000000 control-rate=variable-skip-frames inline-header=true periodicty-idr=300 interval-intraframes=300 ! video/x-h264,profile=high  !  mpegpsmux  name=mux ! multisocketsink timeout=2000000000 sync-method=1  name=sink

If i have a 1920X1080 resolution, I get a green noise line at the bottom of my video (1080/16 = 67,5). Unfortunatly, full hd is a must In my project...

How can I fix this issue?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ashish Kumar Mishra]

Does RPI-2 support WUXGA resolution (1920 * 1080) ?
http://www.raspberry-projects.com/pi/pi-hardware/raspberry-pi-2-model-b/rpi2-model-b-hardware-general-specifications

Which development board / processor are you using ?

[Krutskikh Ivan]

Just to clarify:

I've added ! videoscale ! video/x-raw,width=1920,height=1088 and the issue was fixed. But I don't think that is a good practice...

2016-04-05 12:05 GMT+03:00 Krutskikh Ivan <[hidden email]>:

Hi,

I'm experiencing something like http://stackoverflow.com/questions/33255390/gstreamer-artifacts-at-160x120

With pipeline

v4l2src do-timestamp=true name=source  ! omxh264enc target-bitrate=20000000 control-rate=variable-skip-frames inline-header=true periodicty-idr=300 interval-intraframes=300 ! video/x-h264,profile=high  !  mpegpsmux  name=mux ! multisocketsink timeout=2000000000 sync-method=1  name=sink

If i have a 1920X1080 resolution, I get a green noise line at the bottom of my video (1080/16 = 67,5). Unfortunatly, full hd is a must In my project...

How can I fix this issue?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[RAJensen]

Hello Ashish

Yes.
You can view specs here for the different models of Raspberry Pi

Best regards Robin.

Den 05-04-2016 kl. 11:00 skrev Ashish Kumar Mishra:

Does RPI-2 support WUXGA resolution (1920 * 1080) ?
http://www.raspberry-projects.com/pi/pi-hardware/raspberry-pi-2-model-b/rpi2-model-b-hardware-general-specifications

Which development board / processor are you using ?





--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Video-artefacts-on-full-hd-recording-on-rpi2-tp4676755p4676756.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ashish Kumar Mishra]

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.

[Krutskikh Ivan]

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 <[hidden email]>:

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ian Davidson]

Almost certainly, it is to do with the number of bits in a byte.

If that is the case, it is not something which you are going to want to
tweak.

Ian

On 05/04/2016 15:24, Krutskikh Ivan 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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Peter Maersk-Moller-2]

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 <[hidden email]> 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 <[hidden email]>:

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[schousda]

Hello,

these days i ran into the same issue.
Did you find a fix for this or still using the resolution of 1920x1088?

Thanks.

[pneves]

Are you by chance using a C920 camera?

[schousda]

No, im using the Raspberry Pi camera modul (5MP version).
After i changed my setting to 1920x1088 it seems to work.
The bad thing is, that i get black bars left and right of the video on youtube now, because of the non-standard resolution.