Re: saa7146: please test the vb2 conversion!

[Hans Verkuil <hverkuil-cisco@xs4all.nl>]

On 10/04/2023 00:36, Stefan Herdler wrote:
> On 07/04/23 09:04, Hans Verkuil wrote:
>> On 07/04/2023 00:43, Stefan Herdler wrote:
> [...]
>>>
>>> VBI output is used to switch the aspect-ratio via WSS.
>>> this should be supported by any av7110 card.
>>>
>>> The software is run a daemon or plugin, so the userspace-facing change
>>> shouldn't matter.
>>>
>>> I'll test this as soon as possible.
>>>
>>>
>>>
>>>
>>> I've done only basic testing so far, but unfortunately it already failed.
>>>
>>> The test:
>>> Switch to a channel[*] and view the decoded video with tvtime.
>>>
>>> The resulting picture is corrupted.
>>> Almost green with some pink traces at the outlines.
>>>
>>> It reminds me to YCbCr component-yideo on a RGB-input.
>>> Maybe the input-format of saa7146 not set correctly?
>>>
>>> The OSD is equally affected, but the card seems to run stable.
>>
>> That's weird. When you are in this state, can you run
>> 'v4l2-ctl -V -d /dev/videoX' for the video device that tvtime
>> is using? I'll try to test it with tvtime as well next week.
>> I have done my tests using qvidcap and qv4l2, and that looked fine.
> 
> I've done some more testing and the result is somehow confusing to me.
> 
> At first I tried qv4l and it shows correct videos with any driver.
> And with any pixel format setting I tried.
> 
> 
> After boot /dev/video0 (there is only this device) starts always with
> this settings:
> Format Video Capture:
>         Width/Height      : 384/288
>         Pixel Format      : 'BGR3' (24-bit BGR 8-8-8)
>         Field             : Interlaced
>         Bytes per Line    : 1152
>         Size Image        : 331776
>         Colorspace        : SMPTE 170M
>         Transfer Function : Default (maps to Rec. 709)
>         YCbCr/HSV Encoding: Default (maps to ITU-R 601)
>         Quantization      : Default (maps to Full Range)
>         Flags             :
> 
> 
> On the working "old" driver tvtime switches to the following settings:
> Format Video Capture:
>         Width/Height      : 720/576
>         Pixel Format      : 'UYVY' (UYVY 4:2:2)
>         Field             : Interlaced
>         Bytes per Line    : 1440
>         Size Image        : 829440
>         Colorspace        : SMPTE 170M
>         Transfer Function : Default (maps to Rec. 709)
>         YCbCr/HSV Encoding: Default (maps to ITU-R 601)
>         Quantization      : Default (maps to Limited Range)
>         Flags             :
> It seems tvtime needs this 'UYVY' pixel format to work.
> 
> 
> On the "new" driver, with patches [1], tvtime switches to:
> Format Video Capture:
>         Width/Height      : 720/576
>         Pixel Format      : 'BGR3' (24-bit BGR 8-8-8)
>         Field             : Interlaced
>         Bytes per Line    : 2160
>         Size Image        : 1244160
>         Colorspace        : SMPTE 170M
>         Transfer Function : Default (maps to Rec. 709)
>         YCbCr/HSV Encoding: Default (maps to ITU-R 601)
>         Quantization      : Default (maps to Full Range)
>         Flags             :
> And now it is getting weird:
> I can switch to the correct 'UYVY' settings using qv4l.
> But tvtime always switches back to 'BGR3'.

The cause is "[PATCH 10/17] media: common: saa7146: fall back to V4L2_PIX_FMT_BGR24".

Can you drop that patch and test again?

It's really a tvtime bug since drivers are allowed to either reject an unsupported
pixelformat (the old behavior) or replace it with a supported pixelformat (the
new behavior). And tvtime only supports the old behavior.

> 
> Using qv4l while tvtime is running doesn't work and sometimes
> causes freezing of both programs (on all drivers).

Are you just starting qv4l2 when tvtime is running? Or trying to stream?
Do you see messages in the kernel log?

I couldn't reproduce this. Since tvtime is streaming, qv4l2 shouldn't be able to
do anything since all attempts to change something should result in EBUSY.

Regards,

	Hans

> 
> 
> I have also build a new driver just without the patches [2].
> It shows the "old" correct behavior.
> So I think, the cause of the change must be somewhere in the
> patches.
> 
> 
> 
> Btw.:
> I also tried to open the video device with the usual
> media-players, but I had no luck so far (with any driver).
> 
> 
> Regards
> 
> Stefan
> 
> 
> [1] git checkout -B saa7146-clean 837736a79a76c9becddf0caf905b27c144a64030
> [2] git checkout -B saa7146-clean 2653fad0d8a9625667e9a78133ea9e1245b7c40c
> 
>>
>> Regards,
>>
>> 	Hans
>>
> [...]