v4l2src does not support progressive interlacing
Tim Harvey
tharvey at gateworks.com
Sat Jan 26 00:56:49 UTC 2019
On Tue, Jan 22, 2019 at 4:28 PM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
>
>
>
> Le lun. 21 janv. 2019 19 h 47, Tim Harvey <tharvey at gateworks.com> a écrit :
>>
>> On Mon, Oct 29, 2018 at 11:58 AM Tim Harvey <tharvey at gateworks.com> wrote:
>> >
>> > On Mon, Oct 29, 2018 at 11:56 AM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
>> > >
>> > >
>> > >
>> > > Le lun. 29 oct. 2018 18 h 32, Tim Harvey <tharvey at gateworks.com> a écrit :
>> > >>
>> > >> On Sun, Oct 28, 2018 at 3:44 PM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
>> > >> >
>> > >> >
>> > >> >
>> > >> > Le dim. 28 oct. 2018 20 h 43, Antoine Villeret <antoine.villeret at gmail.com> a écrit :
>> > >> >>
>> > >> >> hi Nicolas,
>> > >> >>
>> > >> >> as far as i understand v4l2-compliance output (https://gist.github.com/avilleret/0eb894d58612d91aba7ab81f9d823dbf)
>> > >> >> bttv driver does support TRY_FMT
>> > >> >> but I might be wrong
>> > >> >>
>> > >> >> on the other side, I made further test with your path, and it seems to work.
>> > >> >> 'it seems' because strangely a test pipeline abord with the output you've already look at.
>> > >> >> But my program (based on OpenFrameworks) does work with your patch while it didn't with gstreamer 1.14 from Ubuntu 18.04 repo.
>> > >> >> I don't know actually what trigs the error you see and why the test pipeline abord before displaying anything,
>> > >> >> maybe I miss some extensions/plugins.
>> > >> >
>> > >> >
>> > >> > Ok, so it seems like the patch does something. I'll reread with the assumption TRY_FMT isn't supported, I might better understand. I always believed that without that, it would always fail.
>> > >> >
>> > >> >>
>> > >> >> Thanks for your time, and I might make further test tomorrow if you need.
>> > >> >>
>> > >>
>> > >> Nicolas,
>> > >>
>> > >> Did you receive the log I sent you regarding my experience with this
>> > >> issue? I can send again if needed.
>> > >>
>> > >> Regards,
>> > >
>> > >
>> > > I haven't I believe. Maybe the ML have eaten it, was it big ?
>> >
>> > I sent it off-list... it probably went to your spam :)
>> >
>> > I've attached it (135K) here.
>> >
>> > Tim
>>
>> Nicolas,
>>
>> Sorry to resurrect a fairly dated thread but this issue still exists
>> using gstreamer master.
>>
>> root at imx6q-gw5404:~/gst/master# v4l2-ctl -d7 --get-fmt-video
>> Format Video Capture:
>> Width/Height : 720/480
>> Pixel Format : 'UYVY' (UYVY 4:2:2)
>> Field : Sequential Bottom-Top
>> Bytes per Line : 1440
>> Size Image : 691200
>> Colorspace : SMPTE 170M
>> Transfer Function : Rec. 709
>> YCbCr/HSV Encoding: ITU-R 601
>> Quantization : Limited Range
>> Flags :
>> root at imx6q-gw5404:~/gst/master# gst-launch-1.0 v4l2src
>> device=/dev/video7 ! video/x-raw,format=UYVY ! jpegenc ! rtpjpegpay !
>> udpsink host=172.24.20.19 port=5000
>> Setting pipeline to PAUSED ...
>> Pipeline is live and does not need PREROLL ...
>> Setting pipeline to PLAYING ...
>> New clock: GstSystemClock
>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device
>> '/dev/video7' does not support progressive interlacing
>> Additional debug info:
>> gstv4l2object.c(3821): gst_v4l2_object_set_format_full ():
>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>> Device wants interleaved interlacing
>> Execution ended after 0:00:00.003732076
>>
>> I've put the GST_DEBUG log here:
>> https://gist.github.com/tharvey/fb3ef7ded7cb686739aeac1ba947a8ca
>>
>> I've got a gstreamer devel environment handy now for testing if you
>> have some ideas.
>
>
> It shouldn't be too hard to implement. First the new layout should be added to the interlaced-mode enum on libgstvideo (-base). I believe there is something there already that match, but needs to be detailed in the documentation.
>
> Second thing is to solve how userspace is supposed to locate the start of the second field. Is it half the buffer allocation size or the display height * stride ? As it is, it's unlikely anyone thought about that, it's probably whatever the HW is doing. The thing is of it does not match, how do we signal that in GST ? The existing unimplemented doc is suggesting having two VideoMeta, could be an option (similar to stereoscopic streams).
>
Nicolas,
Let me make sure I'm configuring things and explaining the issue properly.
What I have is an adv7180 subdev with NTSC camera which outputs
alternating 720x240 fields connected to an IMX6 CSI which has the
ability to interweave the fields into a 720x480 frame. So I start by
setting up the media-ctl pipeline:
# detect std
media-ctl -e "adv7180 2-0020" # /dev/v4l-subdev14
v4l2-ctl --device /dev/v4l-subdev14 --get-detected-standard
Video Standard = 0x0000b000
NTSC-M/M-JP/M-KR
# reset all links
media-ctl -r
# Setup links
media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]'
media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]'
media-ctl -l '"ipu2_csi1":2 -> "ipu2_csi1 capture":0[1]'
# configure pads
media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480]"
media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x480]"
media-ctl --get-v4l2 "'ipu2_csi1':2"
[fmt:AYUV8_1X32/720x480 at 1/30 field:seq-bt
colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range]
# capture device
media-ctl -e 'ipu2_csi1 capture'
/dev/video7
v4l2-ctl --device /dev/video7 --get-fmt-video
Format Video Capture:
Width/Height : 720/480
Pixel Format : 'UYVY' (UYVY 4:2:2)
Field : Sequential Bottom-Top
Bytes per Line : 1440
Size Image : 691200
Colorspace : SMPTE 170M
Transfer Function : Rec. 709
YCbCr/HSV Encoding: ITU-R 601
Quantization : Limited Range
Flags : premultiplied-alpha
^^^ we are still sequential-bt here because we haven't asked the IMX
to do any conversions
v4l2-ctl --device /dev/video7 --stream-mmap --stream-to=x.raw
--stream-count=1 # 691200 bytes (720x480x2)
^^^ this captures 1 'frame' which is 2 sequential fields b-t for NTSC,
t-b for PAL
convert -size 720x240 -depth 16 uyvy:x.raw /var/www/html/files/frame.png
^^^ converts just first field; b for NTSC, t for PAL
convert -size 720x480 -depth 16 uyvy:x.raw /var/www/html/files/frame.png
^^^ converts both fields but they are sequential still (b-t for NTSC,
t-b for PAL) so the resulting image shows both sequential fields
gst-launch-1.0 v4l2src device=/dev/video7 !
video/x-raw,width=720,height=480,format=UYVY ! jpegenc ! rtpjpegpay !
udpsink host=$SERVER port=5000
^^^ gstreamer-1.8.3/1.10.5/1.12.5 work - and I notice they
automatically change /dev/video7 to field=interlaced-bt
^^^ gstreamer-1.14.3 fails with 'Device '/dev/video7' does not support
progressive interlacing'. It does not automatically change /dev/video7
to field=interlaced-bt so if we do that manually:
v4l2-ctl --device /dev/video7 --set-fmt-video=field=interlaced_bt
v4l2-ctl --device /dev/video7 --get-fmt-video
Format Video Capture:
Width/Height : 720/480
Pixel Format : 'UYVY' (UYVY 4:2:2)
Field : Interlaced Bottom-Top
Bytes per Line : 1440
Size Image : 691200
Colorspace : SMPTE 170M
Transfer Function : Rec. 709
YCbCr/HSV Encoding: ITU-R 601
Quantization : Limited Range
Flags :
gst-launch-1.0 v4l2src device=/dev/video7 !
video/x-raw,width=720,height=480,format=UYVY ! jpegenc ! rtpjpegpay !
udpsink host=$SERVER port=5000
# ^^^ still fails with gstreamer-1.14.3/master
So again it used to work and got broken with 1.14. It seems that
gstreamer is trying to set the field to V4L2_FIELD_NONE.
Regards,
Tim
More information about the gstreamer-devel
mailing list