v4l2src does not support progressive interlacing
Locked
12
12
Re: v4l2src does not support progressive interlacing
 
|
On Mon, Oct 29, 2018 at 11:58 AM Tim Harvey <[hidden email]> wrote:
> > On Mon, Oct 29, 2018 at 11:56 AM Nicolas Dufresne <[hidden email]> wrote: > > > > > > > > Le lun. 29 oct. 2018 18 h 32, Tim Harvey <[hidden email]> a écrit : > >> > >> On Sun, Oct 28, 2018 at 3:44 PM Nicolas Dufresne <[hidden email]> wrote: > >> > > >> > > >> > > >> > Le dim. 28 oct. 2018 20 h 43, Antoine Villeret <[hidden email]> 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@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@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. Regards, Tim Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src does not support progressive interlacing
|
|
Le lun. 21 janv. 2019 19 h 47, Tim Harvey <[hidden email]> a écrit : On Mon, Oct 29, 2018 at 11:58 AM Tim Harvey <[hidden email]> wrote: 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).
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src does not support progressive interlacing
|
|
On Tue, Jan 22, 2019 at 4:28 PM Nicolas Dufresne <[hidden email]> wrote:
> > > > Le lun. 21 janv. 2019 19 h 47, Tim Harvey <[hidden email]> a écrit : >> >> On Mon, Oct 29, 2018 at 11:58 AM Tim Harvey <[hidden email]> wrote: >> > >> > On Mon, Oct 29, 2018 at 11:56 AM Nicolas Dufresne <[hidden email]> wrote: >> > > >> > > >> > > >> > > Le lun. 29 oct. 2018 18 h 32, Tim Harvey <[hidden email]> a écrit : >> > >> >> > >> On Sun, Oct 28, 2018 at 3:44 PM Nicolas Dufresne <[hidden email]> wrote: >> > >> > >> > >> > >> > >> > >> > >> > Le dim. 28 oct. 2018 20 h 43, Antoine Villeret <[hidden email]> 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@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@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@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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src does not support progressive interlacing
|
|
Le vendredi 25 janvier 2019 à 16:56 -0800, Tim Harvey a écrit :
> 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. Yes, it used to ignore what the driver was producing and let random images comes out. In some cases (notably ALTERNATE) not validating the value returned by the driver would lead to GStreamer crash. I made the decision that things should be signalled correctly in GStreamer, so if there is a random / unsupported field layout, we will rather return an error then let these image come out. I am totally aware that SEQ_TB, SEQ_BT and ALTERNATE interlace layout aren't supported in GStreamer. Someone is working on ALTERNATE as we are speaking, someone else need to work on SEQ_TB/BT. Now, you are using an IMX.6, which has VDIC and PRP IPs. Just construct your media pipeline using these nodes and the HW will deinterlace the images for you. I'm not sure why you must grab these images in SEQ_TB/BT in the first place. If this is just for testing your HW, you can use v4l2-ctl. In GStreamer I made an effort to produce correct images that are properly signal, so they are usable outside a simple "test" environment. If you need more detail on how to setup your IMX.6 media controller, please refer to https://linuxtv.org/downloads/v4l-dvb-apis/v4l-drivers/imx.html and the linux-media mailing list. Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src does not support progressive interlacing
|
|
On Sat, Jan 26, 2019 at 7:18 AM Nicolas Dufresne <[hidden email]> wrote:
> > Le vendredi 25 janvier 2019 à 16:56 -0800, Tim Harvey a écrit : > > 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. > > Yes, it used to ignore what the driver was producing and let random > images comes out. In some cases (notably ALTERNATE) not validating the > value returned by the driver would lead to GStreamer crash. I made the > decision that things should be signalled correctly in GStreamer, so if > there is a random / unsupported field layout, we will rather return an > error then let these image come out. I am totally aware that SEQ_TB, > SEQ_BT and ALTERNATE interlace layout aren't supported in GStreamer. > Someone is working on ALTERNATE as we are speaking, someone else need > to work on SEQ_TB/BT. Ok, I understand. Is there a discussion or patches posted for ALTERNATE? It seems that SEQ_TB/BT would likely be a minor change to that? > > Now, you are using an IMX.6, which has VDIC and PRP IPs. Just construct > your media pipeline using these nodes and the HW will deinterlace the > images for you. I'm not sure why you must grab these images in > SEQ_TB/BT in the first place. If this is just for testing your HW, you > can use v4l2-ctl. In GStreamer I made an effort to produce correct > images that are properly signal, so they are usable outside a simple > "test" environment. > > If you need more detail on how to setup your IMX.6 media controller, > please refer to > https://linuxtv.org/downloads/v4l-dvb-apis/v4l-drivers/imx.html and the > linux-media mailing list. > Right - that 'does' work for something like the adv7180 but doesn't work for anything with a width or height > 1024 such as the tda1997x HDMI decoder I'm also working with. I'm trying to write documentation for our boards that have these two sensors so I'm trying to cover all combinations and figure out what works, what doesn't, and provide recommendations. For anything >1024 that is alternate/seq-bt/seq-tb it may be the best solution is to use the CSI to downscale by 2 first. Regards, Tim _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |