grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 5:07 pm

luiscgalo wrote:
Thu Aug 09, 2018 5:04 pm
Hi grimepoch,
To complement 6by9 info about how to merge the individual top and bottom fields into a single frame, you can take a look to the "video_field_cb" function within the "rawcam.c" file of my prototype code available on the following post:
viewtopic.php?f=43&t=218928#p1345272

In that case, since it is just a prototype, I'm merging two individual fields (1920*540) forming a FullHD video frame (1920*1080).

I hope that it helps you a little bit solving the problem related with the deinterlacing using image_fx ;)
Excellent! I will take a look at that and see if I can merge into my copy of YAVTA where I am playing with the MMAL stuff. I'll report back!

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 5:31 pm

Looks like your code is doing raw_cam->image_fx->ISP->....

Do you see any reason I can't go V4L2->ISP->image_fx->...

I need to go through your code more and understand how the hand-off occurs. Is this appending the images on the ARM side? Then calling your convert function which is pushing them through image_fx.

I guess the question there is, does the image need to retain YUYV into image_fx, or if it can work with RGBA if I do that conversion first in ISP.

luiscgalo
Posts: 29
Joined: Fri Jun 22, 2018 9:09 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 6:13 pm

grimepoch wrote:
Thu Aug 09, 2018 5:31 pm
Looks like your code is doing raw_cam->image_fx->ISP->....
Well, my code is not working exactly like that.
I have the following data processing chain:
rawcam (capturing BGR24 bottom/top fields) -> interlaced frame merge (BGR24) -> ISP (converts BGR24 to I420) -> image_fx (deinterlacer, however in my case it's struggling with FullHD 1080p50 video :? ) -> H264 Video Encode block (for saving an H264 video file)

Regarding the top/bottom field merge, I'm basically doing something similar to the following diagram within "video_field_cb" function:
interlace_diagram_interlace.jpg
interlace_diagram_interlace.jpg (65.42 KiB) Viewed 574 times
grimepoch wrote:
Thu Aug 09, 2018 5:31 pm
Do you see any reason I can't go V4L2->ISP->image_fx->...
Well, I'm not an expert such as 6by9, but I don't see any problem there...
grimepoch wrote:
Thu Aug 09, 2018 5:31 pm
I guess the question there is, does the image need to retain YUYV into image_fx, or if it can work with RGBA if I do that conversion first in ISP.
In my code, image_fx is handling I420 format at input and ouput.
I'm not sure if it will work with RGBA...
We've to wait for an answer from someone with more experience such as 6by9 ;)
Last edited by luiscgalo on Thu Aug 09, 2018 9:04 pm, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 7:12 pm

image_fx ONLY takes I420.

It should make little difference whether you interleave the RGB/YUYV and then convert that to I420 (with the earlier proviso that you need to treat it as 1440x240/288), or convert to two I420 images and interleave those (remembering that you have 3 independent planes to worry about).

luiscgalo - please note this as I only realised that we need to do special handling for the conversion to I420 today.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 7:30 pm

ahh, okay. So if I understand this correctly, I am getting I420 out of V4L2. I'd need to:

V4L2->MergeFrames->image_fx->isp->...

(In this case, I'd be using isp to output to RGBA)

What I'm curious about is what kind of hit we get with the MergeFrames portion of it? Given that has to go to ARM, then we have to memcpy into a buffer. In my case, right now, to get into a GL texture, that is requiring another buffer copy. I feel like the ISP code is going to get hit with the same limitation at the moment I am getting with V4L2 -> GL texture.

Naturally, my use case here is a bit different.

The two big questions I have in my mind is, the work image_fx is doing as a de-interlacing algorithm to deal with temporal issues, I am not doing that right now in my GLSL code. I need to determine what I would need to add. And then question is, from an efficiency standpoint, which is better. (seems like image_fx would be better to free up some GPU resources I am using for other GLSL things).

Second question, still on getting that texture filled more efficiently. Going to do some research on the egl_image information, maybe try to put something in there. That using the DMA transfer would see useful in either case of me implementing this.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 8:21 pm

grimepoch wrote:
Thu Aug 09, 2018 7:30 pm
ahh, okay. So if I understand this correctly, I am getting I420 out of V4L2. I'd need to:

V4L2->MergeFrames->image_fx->isp->...

(In this case, I'd be using isp to output to RGBA)
No, you're getting UYVY (YUV4:2:2) from V4L2.

V4L2 -> Merge fields -> isp (i420) -> image_fx -> isp (rgba)
or
V4L2 -> isp (i420) -> Merge fields -> image_fx -> isp (rgba)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 8:23 pm

Ahhh! That makes sense. Thanks.

I would think that merge would be expensive in terms of processing since I have to do that on the ARM side.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 09, 2018 9:46 pm

Getting closer, some good info in here as an example framework. Specifically slide 15 and 16.

https://elinux.org/images/5/53/Zero-cop ... eaming.pdf

What is not clear is given we are using multiple buffers out of V4L2, do I need to export each one using:

Code: Select all

ioctl(video_fd, VIDIOC_EXPBUF, &expbuf);
And then, do I create an EGLImageKHR for each buffer. Map them with eglCreateImageKHR. Then after I queue up all the buffers, do I then do the same loop of:

SELECT
DEQUEUE
BIND TEXTURE
glEGLImageTargetTexture2DOES
UNBIND TEXTURE
QUEUE

Repeat.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Fri Aug 10, 2018 10:52 pm

Stuck on one portion of the code that fails to work:

Code: Select all

      EGLint attrib_list[] = {
        EGL_WIDTH, 736,
        EGL_HEIGHT, 240,
         EGL_LINUX_DRM_FOURCC_EXT, fourcc_code('U','Y','V','Y'), 
         EGL_DMA_BUF_PLANE0_FD_EXT, expbuf.fd, 
         EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0, 
         EGL_DMA_BUF_PLANE0_PITCH_EXT, 1472, 
         EGL_NONE,
      };
      //GDisplay
      egl_image[n_buffers] = eglCreateImageKHR(
         eglGetCurrentDisplay(),
         EGL_NO_CONTEXT,
         EGL_LINUX_DMA_BUF_EXT,
         NULL,
         attrib_list);

always returns EGL_BAD_PARAMETER. I've tried different fourcc codes, but no change (and that should actually generate the error EGL_BAD_MATCH. I've also verified that expbuf.fd has at least a valid int in it.

Sadly I see no way to get info on WHAT parameter is bad, the documentation just says:

Code: Select all

Add to the list of error conditions for eglCreateImageKHR:

      "* If <target> is EGL_LINUX_DMA_BUF_EXT and <buffer> is not NULL, the
         error EGL_BAD_PARAMETER is generated.

       * If <target> is EGL_LINUX_DMA_BUF_EXT, and the list of attributes is
         incomplete, EGL_BAD_PARAMETER is generated.

       * If <target> is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT
         attribute is set to a format not supported by the EGL, EGL_BAD_MATCH
         is generated.

       * If <target> is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT
         attribute indicates a single-plane format, EGL_BAD_ATTRIBUTE is
         generated if any of the EGL_DMA_BUF_PLANE1_* or EGL_DMA_BUF_PLANE2_*
         attributes are specified.

       * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for
         EGL_YUV_COLOR_SPACE_HINT_EXT is not EGL_ITU_REC601_EXT,
         EGL_ITU_REC709_EXT or EGL_ITU_REC2020_EXT, EGL_BAD_ATTRIBUTE is
         generated.

       * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for
         EGL_SAMPLE_RANGE_HINT_EXT is not EGL_YUV_FULL_RANGE_EXT or
         EGL_YUV_NARROW_RANGE_EXT, EGL_BAD_ATTRIBUTE is generated.

       * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for
         EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT or
         EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT is not
         EGL_YUV_CHROMA_SITING_0_EXT or EGL_YUV_CHROMA_SITING_0_5_EXT,
         EGL_BAD_ATTRIBUTE is generated.

       * If <target> is EGL_LINUX_DMA_BUF_EXT and one or more of the values
         specified for a plane's pitch or offset isn't supported by EGL,
         EGL_BAD_ACCESS is generated.
Still trying to determine what it could be. As a side note for my other path I am experimenting with, I see that "raspivid" apparently can map out of MMAL to a texture, so I will look at that once I get this working.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sat Aug 11, 2018 9:55 am

I thought I'd already said that the GLES (firmware) stack does not support dmabufs at all, but perhaps that was on another thread.
The GL (kernel) stack does support it.

MMAL's mapping of things into textures was always a touch magic, and required a VPU convert of the images from YUV to RGB T-format. I wouldn't rely on it for anything.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sat Aug 11, 2018 4:59 pm

Ahh, okay, I didn't realize that it didn't work with GLES, I must have missed that bit. Given the huge amount of threads I've read at this point, it's possible I even saw you say it elsewhere! Haha.

Pertaining to the MMAL into texture, what I've done before is taken non RGBA data and basically told the texture mechanism is was RGBA and then converted the data within the shader from YUYV to RGBA as it was being used. Would this not work in this case?

I've been looking through the RaspiStill code and was going to try and convert that to what I was doing. Are you saying its just not going to be worth it?

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sun Aug 12, 2018 12:57 am

Okay, well I am not sure exactly why, but transferring from a memory mapped buffer into a texture is now working. I *think* what I had wrong is the specifications on buffer size into the update texture. The performance is pretty fantastic.

I've also successfully did a simple deinterlace for now (interleaved) from 2 textures. I've found some algorithms for dealing with temporal filtering if you will, I will explore those later.

Doing the UYVY decoding I need to think about and study how it's aligned in memory. I have some issues regarding how the mapped in memory is being decoded into coordinates on the screen. (In that, I think I am dealing with mismatched coordinate translations since the buffers are 738 wide, I am not sure how the frame is aligned within that. Right now my window is defined as 640x480. I think that is part of the problem.

The only path I did not test is MMAL->ISP(YUV->RGB)->? But given you don't think that path is workable, I'm going to ignore it for now since I have something that is working.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 13, 2018 7:46 am

Do you know if PBO's are supported by extension with GLES2.0 on the Pi?

Another recommended example is mapping a PBO into user space, then writing into there and letting the texture grab that asynchronously. Uses DMA transfer as well. Then using a few PBO so you have a pool as well.

I see the "GL_PIXEL_UNPACK_BUFFER" show up in GL/glext.h when I do a search through /usr/include.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 13, 2018 9:10 am

The buffers have a stride that is a multiple of 32 pixels wide. 720 is not a multiple of 32, therefore it is rounded up to 736.
That restriction has been relaxed a bit on the ISP component in the latest firmwares. The hardware requires a multiple of 32 bytes (not pixels), so with UYVY you can come back down to a stride of 1440 (720*2). The same is not true if using I420 as that is one byte per pixel within the plane, therefore it does have to be rounded up to 736.

The image always starts at pixel 0 on the line, it's just that there is extra padding on the right hand edge. (MMAL does have crop.x and crop.y fields, but they are not actually implemented).
image_fx will always require the I420 frame to be a multiple of 32 pixels.

GL is not my thing, therefore I know very little about what is going on where.
Doing a VCHI transfer to a buffer of an incorrect size will fail, so that may well have been your problem.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 13, 2018 3:25 pm

I was wondering where that padding came from, thank you, that makes it much clearer now. I've asked the GL questions in the appropriate forum location.

The one thing I am dealing with now is that once I implemented this code into my larger framework, there the code cannot always process every frame, since with GL, if I am doing a lot of stuff, the frame rate can drop. That's fine, but of course, what is happening is that sometimes I get different fields getting combined and so I get some weird visual artifacts when those events happen.

Before you said:
The peripheral is double buffered. The blanking periods can be very short, therefore if you haven't given it a new buffer before the end of frame it will just overwrite the old one again and not release it back to the client.
The only other option is to fully stop the peripheral after every frame, and there you would be relying on interrupt latencies being very low.
I've been thinking about the ways to solve this issue.

1) Create a pool of buffers that get filled in a thread that run a select/dequeue/queue loop. Give this thread a higher priority. (I have CPU to spare). Keep track of newest frame available, transfer into texture either using current mechanism (blocking texture update) or use PBOs if available.

2) I tried using STREAM OFF and STREAM ON, but for some reason I was getting a black frame. No indication of why, I am still exploring this one. This also means that it adds in some wasted time waiting for a frame always, and stalls the GL pipeline, which leads me to the next issue:

Given these are different fields coming out, if I am being too slow reading them, if it constantly replaces the last buffer with TOP then BOTTOM over and over, this probably leads to situations where I have mismatched frames.

So when I call STREAMOFF, do I need to DEQUEUE all the buffers and then REQUEUE them up?

When I use select, that's basically waiting to make sure there is a buffer to dequeue. If I want to get the latest buffers, do I just run DEQUEUE till it fails? Then scrap the returned structures to find the last full pair of TOP/BOTTOM? Then release the ones I am not using and continue with the 2 I am using? If this is possible, then I could use the current direct transfer into GL but not get the stuttering I am seeing.

I'm unclear on how to properly drop frames in a way to always allow the peripheral to have something to write into so I at least get the proper combination of frames and use newer frames, not older ones, when I have to drop.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 13, 2018 3:42 pm

Working out how many buffers to drop is not an easy one to solve. Count how many buffers are with GL and if it is higher than a threshold then it means GL is running behind and you need to return some.
Alternatively have a peekable queue feeding GL. When GL wants some frames, check the length and pull out and discard N-2, leaving 2 fields to process (or do you always want a TOP and BOTTOM field in a particular order?)

As for how to handle dropped frames, looking at the v4l2_buffer structure flags is the right thing to do - that's why I went to the effort of detecting the frame number so I could give the correct field signalling.
Amend the queue described above to not immediately return the old buffers unless it has a newer pair of fields to process.

STREAMOFF/ON stops and restarts the ADV chip, the CSI2 receiver, and just about everything else. You don't want to be doing that unless you really want to stop.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 13, 2018 3:49 pm

That sounds reasonable. I'll try that and see what I get.

When you mentioned turning the peripheral on and off before, was that with STREAMON/STREAMOFF? I just want to make sure I understand what I quoted from you, or if that was a different mechanism. (Like a pause or something in the stream).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 13, 2018 4:11 pm

grimepoch wrote:
Mon Aug 13, 2018 3:49 pm
That sounds reasonable. I'll try that and see what I get.

When you mentioned turning the peripheral on and off before, was that with STREAMON/STREAMOFF? I just want to make sure I understand what I quoted from you, or if that was a different mechanism. (Like a pause or something in the stream).
The only other option is to fully stop the peripheral after every frame, and there you would be relying on interrupt latencies being very low.
I'm referring to design options when writing the kernel driver for the peripheral, not userspace options.
The second bit is the crux - interrupt latencies are not very low. They're low, but not low or predictable enough.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 13, 2018 11:27 pm

One thing I notice is that the sequence value always increases, on both TOP and BOTTOM frames. Is that expected? The documentation says:
Set by the driver, counting the frames (not fields!) in sequence.
Is TOP and BOTTOM considered different frames?

I also don't get back the timecode flag, which the documentation indicates that the value stored in timecode are not valid.

So it appears the approach is working where I am keeping track of the returned buffers and then returning the ones I am not using.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 14, 2018 8:48 am

grimepoch wrote:
Mon Aug 13, 2018 11:27 pm
One thing I notice is that the sequence value always increases, on both TOP and BOTTOM frames. Is that expected? The documentation says:
Set by the driver, counting the frames (not fields!) in sequence.
Is TOP and BOTTOM considered different frames?
Nope, that would be a bug in the interlaced support.
The difficult bit is that I don't have documentation stating which field is the end of the frame as it comes out of the ADV, same as I don't know which line number is TOP vs BOTTOM. I can hazard a guess again, but I don't have the test equipment to verify.

It seems a little academic anyway. As long as you take two consecutive fields with correct signalling it doesn't matter which happened first temporally. The deinterlace component is doubling the frame rate / duplicating the field rate by taking a stream of fields

Code: Select all

12345678
TBTBTBTB
and deinterlacing 1&2, then 2&3, then 3&4, then 4&5, etc to give 7 output frames from the 8 fields at the field rate. The matching only matters if you are dropping back from 50fields/s to 25frames/s.
grimepoch wrote:I also don't get back the timecode flag, which the documentation indicates that the value stored in timecode are not valid.
We don't support timecodes - it's mainly used in film production, not broadcast. You may find hardware with a timecode decoder built in, but the ADV doesn't.

We have timestamps in the timestamp field of the buffers, and V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC should be set to give you the base. Definition
For capture streams this is time when the first data byte was captured, as returned by the clock_gettime() function for the relevant clock id
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 14, 2018 11:10 am

Branch rpi-4.14.y-unicam-interlaced updated to only increment the sequence number on the second field (CSI frame number = 2).
Not tested, and needs to be confirmed that it is incremented on the correct field.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Aug 15, 2018 4:09 am

Quick question, are we using the adv7180.c that is doing all our register assignments? I ask because I think I am having a problem with the settings and want to see how things are being set.

The 7282 has a robust autodetect system, yet I am having some trouble with certain inputs. I know that the chip can be pretty finicky on settings order.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Aug 15, 2018 6:49 am

Yes, adv7180.c
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Aug 15, 2018 8:07 am

Excellent, thanks.

For reference, what I am trying to deal with is I want the output to be ITU-R BT.656-4, not 3 that it is defaulting. 3 is creating a blank set of lines at the beginning. I also want to set to NTSC with pedestal. I've tested with MANY different sources and this seems to be the correct settings.

One other thing I wanted to ask, I saw in a message from ADV engineers that its possible for their hardware to send more lines than it should in events like loosing and gaining sync. Does the driver handle that? To protect from overwriting the internal buffers past the end? I've never seen it have a problem, but I figured I'd ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5663
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 16, 2018 10:33 am

grimepoch wrote:
Wed Aug 15, 2018 8:07 am
For reference, what I am trying to deal with is I want the output to be ITU-R BT.656-4, not 3 that it is defaulting. 3 is creating a blank set of lines at the beginning. I also want to set to NTSC with pedestal. I've tested with MANY different sources and this seems to be the correct settings.
Sorry, that's getting too low down into the video signals for me to care too much. (And why can't the ITU put a change history into the spec when bumping up the revision?)
Any changes to the driver really need to be made upstream through the linux-media mailing list. We try to avoid changing the mainline drivers as it causes headaches when updating to new kernel releases.
grimepoch wrote:One other thing I wanted to ask, I saw in a message from ADV engineers that its possible for their hardware to send more lines than it should in events like loosing and gaining sync. Does the driver handle that? To protect from overwriting the internal buffers past the end? I've never seen it have a problem, but I figured I'd ask.
The Unicam driver will start writing to the frame when it gets a frame start short packet, and stop writing when it gets a frame end short packet or has written the defined number of bytes. https://github.com/raspberrypi/linux/bl ... cam.c#L589
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Camera board”

Who is online

Users browsing this forum: SmartySmart702 and 9 guests