AW: Displaying camera not working

[Iñigo Huguet]

I have to say that I have had to add sync=false to the videosink because 
if not lot of frames were reported to being dropped because of the 
source "being late" with the timestamps. May this be related to this 
problem of the frames that retain old content?


El 27/04/18 a las 13:56, Iñigo Huguet escribió:
> It is the version included with Buildroot: 1.12.3.
>
> With XV driver you mean an X11 driver, right? My device use 
> xf86-video-fbturbo, which is based on xf86-video-fbdev, adding some 
> optimizations and hardware accelerations for Allwinner SoC. It is 
> supposed to have XV support.
>
> I'm pretty sure that this SoC uses (or admit) NV12 format in its 
> framebuffer because demo program writes to the framebuffer in NV12 
> format. (as I said, framebuffer is used to display graphics, even with 
> X11). That makes me think that the fbturbo driver should accept NV12 
> buffers as input for XV, but I don't know how to test it.
>
>
> El 27/04/18 a las 13:38, Nicolas Dufresne escribió:
>> Le vendredi 27 avril 2018 à 11:17 +0200, Iñigo Huguet a écrit :
>>> gst-launch-1.0 filesrc location=raw_video.bin ! videoparse width=720
>>> height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert !
>>> autovideosink
>>> This way, I can see the image OK, not only lot of lines of random
>>> colors. So I concluded that the problem in my device must be in
>>> videoconvert or in xvimagesink, not in the cameras driver.
>>> My device is using an Allwinner A20 SoC. This SoC uses the
>>> framebuffer to output graphics, even using X11. So I installed
>>> fbdevsink plugin and tried this command:
>>>
>>> gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-
>>> raw,format=NV12,width=720,height=576 ! videoconvert ! fbdevsink
>>> sync=false
>>>
>>> I can see the image OK. I still don't know if the problem is in
>>> videoconvert, in xvimagesink, or in both. However, I can't use
>>> fbdevsink because it interferes with X11, trying both of them to
>>> "take control" of the framebuffer. Any hint about what can I try to
>>> find out what's failing and how to solve it?
>> It's more likely a bug in XV driver. Make sure you use the very latest
>> upstream code there.
>>
>>> Also, I have another problem. Only one of every 7 buffers seems to be
>>> updated with a new frame, the other 6 remains with the first fame
>>> they captured at the beginning, so I have a video of the same
>>> sequence of 6 frames repeating all time the same and one single frame
>>> that seems to be correct between each 6 frames sequence.
>> Looks familiar, but something that would have been fixed a long time
>> ago. Which GStreamer version are you running ?
>>
>> Nicolas
>>
>