[00:09] *** djrscally has quit IRC (Ping timeout: 480 seconds)
[01:09] *** camus1 has joined #linux-media
[01:11] *** camus has quit IRC (Ping timeout: 480 seconds)
[01:45] *** eelstrebor has quit IRC (Quit: Ex-Chat)
[01:47] *** jarthur has quit IRC (Ping timeout: 480 seconds)
[01:47] *** jarthur has joined #linux-media
[02:20] *** xiaer1921 has quit IRC (Remote host closed the connection)
[02:20] *** xiaer1921 has joined #linux-media
[02:34] *** camus has joined #linux-media
[02:35] *** camus1 has quit IRC (Remote host closed the connection)
[03:14] *** camus1 has joined #linux-media
[03:19] *** camus has quit IRC (Ping timeout: 480 seconds)
[04:13] *** NiksDev has joined #linux-media
[05:22] *** eelstrebor has joined #linux-media
[05:43] *** eelstrebor has quit IRC (Quit: Ex-Chat)
[06:28] *** jm_h has joined #linux-media
[07:00] *** jm_h has quit IRC (Remote host closed the connection)
[07:00] *** jarthur has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[07:01] *** jm_h has joined #linux-media
[07:28] *** lucaceresoli has joined #linux-media
[07:44] *** gouchi has joined #linux-media
[07:44] *** gouchi has quit IRC ()
[08:00] *** djrscally has joined #linux-media
[09:30] *** xiaer1922 has joined #linux-media
[09:30] *** xiaer1921 has quit IRC (Remote host closed the connection)
[09:30] *** xiaer1922 is now known as xiaer1921
[09:46] *** camus has joined #linux-media
[09:51] *** camus1 has quit IRC (Ping timeout: 480 seconds)
[09:56] *** ao2 has joined #linux-media
[10:21] *** camus1 has joined #linux-media
[10:25] *** camus has quit IRC (Ping timeout: 480 seconds)
[10:58] *** syoung has quit IRC (Read error: Connection reset by peer)
[11:03] *** syoung has joined #linux-media
[12:01] *** kilobyte_ch has joined #linux-media
[12:06] <kilobyte_ch> Hello, I'm trying to get an ADV7282 Analog Video to CSI2 Decoder running. This device is configurable to output Progressive or Interlaced video. The Progressive mode seems to be quite unusuable as it features vertical jitter most of the time and also the quality isn't perfect as it just uses line doubling. Thus I like to get it running in the Interlaced mode and do deinterlacing on the
[12:06] <kilobyte_ch> Linux System. I use a Raspberry Pi 4 as Linux System/CSI2 Receiver. To get CSI2 Interlace support I use this WIP Kernel Branch: https://github.com/6by9/linux/commits/rpi-5.10.y-unicam-interlaced. With this Branch I get a V4L device which can provide ALTERNATE Interlaced video.
[12:07] <kilobyte_ch> I tried to use this Alternate Interlaced device in VLC and GStreamer but wasn't able to use it. VLC doesn't want to even play it and the best I got from GStreamer was that it outputed half of the resolution without doing proper deinterlacing.
[12:07] <kilobyte_ch> So my question is, is there another tool which can work with a V4L device which provides Alternate Interlaced video? Or is Alternate Interlaced video still a WIP thing and shouldn't be used?
[12:11] <pinchartl> kilobyte_ch: gstreamer has a deinterlacing element, I would expect that to work
[12:13] <kilobyte_ch> pinchartl: Yes, they are also working/worked on V4L2_FIELD_ALTERNATE which is basically what I need. But I never got it working. It looks also still pretty WIP. But I'm not sure as I don't have a known good V4L2_FIELD_ALTERNATE source or something else to compare. I guess with V4L2_FIELD_INTERLACED it would work but my Hardware can't provide in this Field Format.
[12:17] <pinchartl> I haven't worked with interlaced video myself I'm afraid
[12:18] <pinchartl> (I wish interlacing would just die)
[12:26] <kilobyte_ch> No problem, I would also like to wish that this Part would just output Progressive video and I wouldn't need to deal with all that stuff :D
[12:27] <kilobyte_ch> If someone here has experience with the ADV7282 and the I2P Block that would also help a lot as I wasn't able to get it properly working without Jitter and so on (not sure if that is a Limitation of its I2P or if that is my fault)
[12:33] <ezequielg> kilobyte_ch: if you can cope with some interlacing artifacts (many videos can) then just grab your alternate buffers and memcpy them into interlaced buffers.
[12:33] <ezequielg> you can then use gstreamer deinterlace, which will work as-is.
[12:33] <ezequielg> i know from very recent experience that this works out of the box.
[12:34] <ezequielg> the deinterlace gstreamer element takes a lot of cpu.
[12:34] <ezequielg> in my case, i've decided to not use that, it's too much cpu just for some artifacts.
[12:35] <kilobyte_ch> ezequielg: with copying them into interlaced buffers you mean to do that in the kernel driver right?
[12:35] <ezequielg> no
[12:35] <ezequielg> or yes. it's the same.
[12:36] <kilobyte_ch> May I ask what Hardware you did use which provides Alternate Interlaced video?
[12:36] <ezequielg> my hw provides interlaced video, it's tw686x
[12:36] <ezequielg> going from alternate to interlaced is trivial, iirc.
[12:37] <ezequielg> alternate is separate fields in separate buffers (right?). interlaced is just combining  two buffers in one. 
[12:38] <kilobyte_ch> Yes, if I understand correctly alternate is to get two buffers, one filled with even lines and the other filled with odd lines. The buffers have /2 height of the image.
[12:38] <ezequielg> right.
[12:38] <kilobyte_ch> And interlaced is basically the same just that the buffer is the normal size and the lines in between are black or something
[12:38] <ezequielg> nono
[12:38] <kilobyte_ch> hmm?
[12:38] <ezequielg> interlaced is combining the two fields.
[12:39] <ezequielg> why do you say black in between? in between what? 
[12:39] <ezequielg> Hridya Valsaraju
[12:39] <ezequielg> ouch bad copy paste
[12:39] <ezequielg> https://www.kernel.org/doc/html/v4.9/media/uapi/v4l/field-order.html
[12:39] <kilobyte_ch> ah ok, then that was just misunderstanding from me (never used interlaced video before)
[12:40] <ezequielg> Images contain both fields, interleaved line by line. The temporal order of the fields (whether the top or bottom field is first transmitted) depends on ...
[12:40] <ezequielg> so you memcpy line by line from two alternate buffers to get one interlaced buffer
[12:40] <kilobyte_ch> I guess you used an i.MX SoC or something with your Techwell decoder right?
[12:41] <ezequielg> and the video has artifacts: https://en.wikipedia.org/wiki/Interlaced_video#Interlacing_problems
[12:41] <ezequielg> those artifacts are removed by a filter such as gstreamer deinterlace
[12:41] <ezequielg> the SoC or the capture hardware has no relevance :)
[12:42] <ezequielg> but fwiw, the techwell card is a pci card on x86 boxes.
[12:42] <ezequielg> (again this is not relevant)
[12:42] <kilobyte_ch> It has kind of relevance as my capture hardware (raspberry pi 4) officially just supports progressive video and the alternate interlaced is just available with the patched kernel I linked above
[12:43] <ezequielg> yeah, but i am talking about generic stuff :)
[12:43] <ezequielg> of course, each case has its own issues and amusements.
[12:43] <ezequielg> fwiw, an interlaced buffer and a progressive buffer cannot be distinguished.
[12:44] <ezequielg> unless you say "this is progressive"
[12:44] <ezequielg> which is why there is a flag.
[12:44] <ezequielg> to the userspace, it's just a Width x Height x Pixel format buffer
[12:44] <kilobyte_ch> But alternate interlacing is special in that case as the buffer is just half the height
[12:45] <ezequielg> yes.
[12:45] <kilobyte_ch> Thats also the part which GStreamer doesn't work properly in my case
[12:45] <ezequielg> you must be doing it wrong :)
[12:45] <ezequielg> interlaced buffer and a progressive buffer are both Width x Height x Pixel format buffer.
[12:45] <ezequielg> alternate buffer is half the height.
[12:45] <kilobyte_ch> I can get it running when specifying half the height (which is wrong according to GST docs + GST irc) and when specifying the full resolution with deinterlacing plugin the pipeline won't start to run with some negotiate error.
[12:46] <ezequielg> yes.
[12:46] <ezequielg> makes sense.
[12:46] <ezequielg> if you read the ab
[12:46] <ezequielg> the above, you'll see i'm explaining how to solve it.
[12:47] <ezequielg> may require kernel changes, gstreamer ad-hoc elements, gstreamer appsink, or whatever way you want to do it.
[12:47] *** xiaer1922 has joined #linux-media
[12:48] <kilobyte_ch> I can't fully follow now, I guess with kernel changes you mean modifying the current Alternate Interlace Kernel Driver to non Alternate Interlace with buffering to create a full interlace frame with memcpy or something
[12:49] <kilobyte_ch> and with appsink you mean to do the same but in userspace with the data which is provided from GST in the appsink
[12:51] <ezequielg> yup.
[12:51] <ezequielg> both correct :)
[12:51] <ezequielg> two alternate solutions... pun intended hehe
[12:51] <kilobyte_ch> :D
[12:52] <kilobyte_ch> Just for completness as you already tried stuff with alternate and GST, this error doesn't ring a bell for you? https://pastebin.com/mfKrfq20
[12:52] <kilobyte_ch> especially line 9
[12:52] *** xiaer1921 has quit IRC (Ping timeout: 480 seconds)
[12:52] *** xiaer1922 is now known as xiaer1921
[12:52] <kilobyte_ch> (when specifying half the height the GST pipeline runs with the same v4l device)
[12:53] <ezequielg> right...
[12:53] <ezequielg> so follow me in this line of reason
[12:53] <ezequielg> v4l2src will produce buffers that are 720x288
[12:54] <ezequielg> but you are telling the pipeline it's 720x576
[12:54] <ezequielg> you are somehow expecting gstreamer will know that.
[12:54] <ezequielg> and will somehow make 720x576 buffers out of two 720x288 buffers .... with videoconvert?
[12:54] <ezequielg> but videoconvert is afaik, just to do pixel format conversions and the like.
[12:55] <ezequielg> for me, since i'm a kenrel dev, the simplest solution is to make interlaced buffers 720x576 in the driver.
[12:56] <ezequielg> dunno how the memcpy will affect your arm cpu.
[12:56] <ezequielg> if you had a dma engine you could configure that to do this.
[12:58] <kilobyte_ch> Fully agree with your explanation that the buffer is half the height. But the caps in gstreamer totally confuse me. They even added something regarding that in the docs but it still confuses me https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/2452f0bbcf3f1420b75ef39c8933f6438b7959d2 
[12:59] <kilobyte_ch> For my understanding the field dimension is what GST gets from the V4L device (->720x288) and the frame dimension is from the GST buffer which is "normal progressive" (-> 720x576)
[13:28] *** bingbu has joined #linux-media
[13:50] *** bingbu has quit IRC (Remote host closed the connection)
[15:46] *** Bugies has joined #linux-media
[17:40] *** gouchi has joined #linux-media
[18:12] *** eelstrebor has joined #linux-media
[18:57] *** camus has joined #linux-media
[18:59] *** camus1 has quit IRC (Read error: Connection reset by peer)
[19:19] *** camus1 has joined #linux-media
[19:20] *** camus has quit IRC (Read error: Connection reset by peer)
[20:23] *** darkapex1 has joined #linux-media
[20:29] *** darkapex has quit IRC (Ping timeout: 480 seconds)
[20:56] *** lucaceresoli has quit IRC (Quit: Leaving)
[21:43] *** gouchi has quit IRC (Remote host closed the connection)
[21:49] *** swegener has quit IRC (Remote host closed the connection)
[21:50] *** swegener has joined #linux-media
[21:59] *** jm_h has quit IRC (Remote host closed the connection)
[22:20] *** NiksDev has quit IRC (Ping timeout: 480 seconds)
[22:49] *** ao2 has quit IRC (Remote host closed the connection)
[23:52] *** djrscally has quit IRC (Ping timeout: 480 seconds)