NV12 issue in 1.14.1

[Nicolas Dufresne]

Le mercredi 25 juillet 2018 à 07:24 -0500, tobatrance a écrit :
> Hi there,
> 
> I'm right now shifting my application from 1.8.3 to 1.14.1 as I shift Ubuntu
> as well from 16.04 to 18.04. I got some issues with the NV12 format. Back in
> 1.8.3 almost all my videos came in I420, meanwhile they're by default
> encoded in NV12. 

I420 and NV12 is the same format, just a different layout, so it's not
possible to encode in one or the other.

> 
> I'm in general using this simple pipeline:
> 
> filesrc ! decodebin ! appsink
> 
> I grab the frames from my appsink and push them on to OpenGL for some
> postprocessing before displaying them. There are *some* videos which cause
> trouble, the majority runs fine, like bunny e.g., but some don't work the
> way they're supposed to which have been working with I420. Said that I can
> exclude my shader being wrong. Please note the attached video. This is one
> of these working before in I420 but not in NV12. 
> 
> countdown.mp4
> <http://gstreamer-devel.966125.n4.nabble.com/file/t377636/countdown.mp4>  

This video is profile main, so it's you are not using openh264, maybe
you are using vaapi then, which indeed gives me NV12 by default.

Though, there does not seem to be any issues with the GstVideoMeta when
using glimagesink here:

gst-launch-1.0 souphttpsrc location=http://gstreamer-devel.966125.n4.nabble.com/file/t377636/countdown.mp4 ! queue2 ! qtdemux ! h264parse ! vaapih264dec ! video/x-raw ! glimagesink

This is 1.14.1, you should do the same test to validate.

> 
> To me it seems that the strides given by the GstVideoInfo.stride property do
> not fit the corresponding GstVideoFrame.data property. For the countdown
> video, when using the stride 765 in 1.14.1/NV12 for the Y plane it works
> properly. In 1.8.3/I420, GST gives 720, which is the same as the actual
> width and it works 	. In 1.14.1/NV12 it also gives 720 but as I
> mentioned it's not displayed correctly. When changing the value to 765 it
> works. I'm using the stride in /glPixelStorei(GL_UNPACK_ROW_LENGTH,
> stride);/ when updating the texture with the current sample's buffer.
> 
> I got a different issue with the UV plane: The strides there don't work as
> well like with the Y plane. But additionally it seems that the plane has an
> offset in respect to the Y plane. When swichting off displaying the Y plane
> in the shader and just showing the UV plane it seems the UV plane is shifted
> to the top. In other words: It seems like the first couple of rows are
> missing in the UV plane. The bottom is filled with visual noise. 
> 
> Appreciate any help. If you need more information let me know.

Without any code it would be hard to point to your bugs. This is a bug
in your code of course. 

> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180725/859f9ef8/attachment.sig>