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

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sun Aug 19, 2018 1:05 am

I totally understand about the low-level functionality, to be honest, I am not sure really how one would handle this through a driver. Reason being, there are tons of options for things like noise reduction, or turning off AGC, or setting the no-signal image, that are really not a one size fits all. And trying to code all that in, seems like it would be complicated.

For most things, I can change them on the fly with I2C messages, but others I cannot. If I have to maintain my own copy of the driver, I am fine with that. I mainly mention this here in case someone else comes across this thread and run into the same problem where an option they want does not work.

Nevertheless, I've ket my code run for 24+ hours and it works fantastic. Hopefully you can use this in the other ADV chips you were working with as well!

Also, simple de-interlacing works pretty well. I've not had time to explore additional shader de-interlacing yet, but I will, and I will report back here.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5538
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 20, 2018 8:58 am

grimepoch wrote:
Sun Aug 19, 2018 1:05 am
I totally understand about the low-level functionality, to be honest, I am not sure really how one would handle this through a driver. Reason being, there are tons of options for things like noise reduction, or turning off AGC, or setting the no-signal image, that are really not a one size fits all. And trying to code all that in, seems like it would be complicated.
V4L2 does have custom controls for some drivers. Look in include/uapi/linux/v4l2-controls.h and there is actually a reserved block of controls for ADV7180 (V4L2_CID_USER_ADV7180_BASE for 16 controls). It's currently only used for controlling fast switching.
If you look at tc358743.c then that adds two custom controls for relaying whether audio is present, and the samping rate if it is.

ADV7180 is being maintained upstream, so if you make useful changes to it then it'd be worth pushing patches to the linux-media list for merging. For purely upstream files we prefer to only backport patches, rather than applying custom patches to the Pi kernel.
grimepoch wrote:For most things, I can change them on the fly with I2C messages, but others I cannot. If I have to maintain my own copy of the driver, I am fine with that. I mainly mention this here in case someone else comes across this thread and run into the same problem where an option they want does not work.
Be very careful if you're pushing I2C commands to a device that has a loaded kernel driver. The kernel driver is not expecting other things to touch the device so may be making assumptions about state (eg if there is page switching in the registers).
grimepoch wrote:Nevertheless, I've ket my code run for 24+ hours and it works fantastic. Hopefully you can use this in the other ADV chips you were working with as well!
I was generally seeing the code as being stable. I haven't got an ADV7481 board as yet (it supposedly in the pipeline), but I'm expecting the same technique to work. Did you manage to confirm if the fields were being correctly flagged? For PAL and NTSC preferably.
grimepoch wrote:Also, simple de-interlacing works pretty well. I've not had time to explore additional shader de-interlacing yet, but I will, and I will report back here.
Simple deinterlacing using what algorithm? I'm just curious.
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 20, 2018 11:01 pm

6by9 wrote:
Mon Aug 20, 2018 8:58 am
V4L2 does have custom controls for some drivers. Look in include/uapi/linux/v4l2-controls.h and there is actually a reserved block of controls for ADV7180 (V4L2_CID_USER_ADV7180_BASE for 16 controls). It's currently only used for controlling fast switching.
If you look at tc358743.c then that adds two custom controls for relaying whether audio is present, and the samping rate if it is.
I'll have a look at that, thanks. I need to wrap my head around the different setting setups. Things like no signal image, noise filter, etc make sense to change as parameters.

The other options, like setting up an entire chain of commands, I need to think about and study the setup. I still think it makes it complicated in the sense that for different desired setups, different command sets need to be set in a certain order, if not, the chip doesn't work properly. In those cases, for those scenarios, I need to be specific. I'll see what I come up with and if it looks shareable I'd love to help enhance the driver.
6by9 wrote:
Mon Aug 20, 2018 8:58 am
Be very careful if you're pushing I2C commands to a device that has a loaded kernel driver. The kernel driver is not expecting other things to touch the device so may be making assumptions about state (eg if there is page switching in the registers).
Good to know, so far I've not had any problems with changing things, but, clearly this is not the best way. I think studying the driver will help me see what is going on and see what I want to do there. I am doing quite a bit of testing to make sure I don't break things for my application.
6by9 wrote:
Mon Aug 20, 2018 8:58 am
I was generally seeing the code as being stable. I haven't got an ADV7481 board as yet (it supposedly in the pipeline), but I'm expecting the same technique to work. Did you manage to confirm if the fields were being correctly flagged? For PAL and NTSC preferably.
I am seeing the frames flagged as top and bottom. I've not merged in the new changes yet to test the new frame code yet. That's on the list (I am doing a hardware revision for a different portion of the circuit, not related to the coding, so that has kept me busy). I also only tested NTSC so I need to get back in and work on PAL as well. I'll report back after I test.

6by9 wrote:
Mon Aug 20, 2018 8:58 am
Simple deinterlacing using what algorithm? I'm just curious.
Surprisingly enough, just interleaving the frames. It's a lot smoother than you'd think probably because the fast half field frame rate. But I found some algorithms that others have written to do temporal based and I want to study between those. I have someone that is going too help me with those tests so we can capture the output and see what it looks like in both cases in a way we can see the effects easier.

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

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 23, 2018 6:58 am

Updated the unicam driver with your changes, something with the sequence for some reason isn't coming out right.

This is a print function where I have 16 buffers, and I and just dequeuing them. I is the buffer index, F is the frame type (top,bottom), S is the sequence # returned. This was for NTSC.

Code: Select all

I: 0, F: 3, S: 0, BYTES: 353280
I: 1, F: 3, S: 1, BYTES: 353280
I: 2, F: 3, S: 2, BYTES: 353280
I: 3, F: 2, S: 0, BYTES: 353280
I: 4, F: 3, S: 3, BYTES: 353280
I: 5, F: 2, S: 0, BYTES: 353280
I: 6, F: 3, S: 4, BYTES: 353280
I: 7, F: 2, S: 0, BYTES: 353280
I: 8, F: 3, S: 5, BYTES: 353280
I: 9, F: 3, S: 6, BYTES: 353280
I: 10, F: 2, S: 0, BYTES: 353280
I: 11, F: 3, S: 7, BYTES: 353280
I: 12, F: 2, S: 0, BYTES: 353280
I: 13, F: 3, S: 8, BYTES: 353280
I: 14, F: 2, S: 0, BYTES: 353280
I: 15, F: 3, S: 9, BYTES: 353280
And it just continues to ping pong back and forth between 0 and the next highest number.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5538
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 23, 2018 9:25 am

grimepoch wrote:
Thu Aug 23, 2018 6:58 am
Updated the unicam driver with your changes, something with the sequence for some reason isn't coming out right.

This is a print function where I have 16 buffers, and I and just dequeuing them. I is the buffer index, F is the frame type (top,bottom), S is the sequence # returned. This was for NTSC.
Because I'm a numpty. In unicam_process_buffer_complete

Code: Select all

		if (frame_num == 2)
			dev->cur_frm->vb.sequence = dev->sequence++;
needs to be

Code: Select all

		if (frame_num == 2)
			dev->sequence++;
		dev->cur_frm->vb.sequence = dev->sequence;
As you've seen, it's only setting dev->cur_frm->vb.sequence (the output sequence number) if frame_num==2, otherwise it'll be returning 0.
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 23, 2018 12:33 pm

Haha, okay, I'll try that.

First question, is there a faster way to put these changes in? When I update the unicam source code, I run the following steps:

Code: Select all

KERNEL=kernel7
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2709_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j3 zImage modules dtbs
sudo make modules_install
sudo cp arch/arm/boot/dts/*.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo cp arch/arm/boot/zImage /boot/$KERNEL.img
Then I reboot. Are all those steps necessary every time?

Second question, I'm still digging into this, but I seem to be getting mismatched Top and Bottom fields some time, even though the sequencing from the driver counts correctly. When I run YAVTA I always get TONS of messages about dropped frames. I didn't think anything of it when I when I was looking at the I2P or just the TOP or BOTTOM frame because it ends up being acceptable.

However, when combining the fields, I can see clearly that sometimes the fields match for awhile, then sometimes they don't, and of course this makes a juddering/strobe effect. It's not just normal field differences, it's clearly temporally MUCH longer than 1/60s

I've monitored my code, and I am not dropping buffers, most of the time I get 2 buffers per dequeue cycle I run. I also make sure I pull a 3 and 2 frame next to each other being returned. I've tried both orders as well (2 followed by 3, or 3 followed by 2 field). I basically have a ring reference buffer where I track the returned buffers (I have 16) and match them up as they come in.

Given that it works properly and improperly, over time, leads me to believe the unicam buffer is not grabbing all frames. Are we actually pulling through the frame # as reported by the CSI-2 received data packets? Or are we just creating new frame numbers in the driver? Unless the YAVTA output is meaningless in this context, or I misunderstand it.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5538
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 23, 2018 1:37 pm

grimepoch wrote:
Thu Aug 23, 2018 12:33 pm
Haha, okay, I'll try that.

First question, is there a faster way to put these changes in? When I update the unicam source code, I run the following steps:

Code: Select all

KERNEL=kernel7
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2709_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j3 zImage modules dtbs
sudo make modules_install
sudo cp arch/arm/boot/dts/*.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo cp arch/arm/boot/zImage /boot/$KERNEL.img
Then I reboot. Are all those steps necessary every time?
bcm2709_defconfig is only necessary if you change the configuration options, so you can skip that.

zImage is building the core kernel (anything that is built in).
modules is building all the modules. bcm2835-unicam is a module
dtbs is building all the device tree and overlay files.
Omit any of those that you haven't changed (so "modules" is probably what you want).

Are you cross-compiling or compiling on the Pi? I'm a little confused as you have CROSS_COMPILE variables in there, but "sudo make modules_install" will fail badly if you really are cross-compiling.

If you've only changed modules then you don't need any of copying stuff to /boot, just the modules_install line should do all that you need.
grimepoch wrote:Second question, I'm still digging into this, but I seem to be getting mismatched Top and Bottom fields some time, even though the sequencing from the driver counts correctly. When I run YAVTA I always get TONS of messages about dropped frames. I didn't think anything of it when I when I was looking at the I2P or just the TOP or BOTTOM frame because it ends up being acceptable.
yavta only compares the timestamp delta that it gets against the frame rate that it had reported to it. PAL is reporting 25fps, NTSC 29.970fps.
I hadn't considered the alternate interlace condition, so it will be comparing field timestamps against the frame rate. That actually counts in your favour as fields are delivered at 50 or 59.94fps, so I wouldn't expect to see any frame drops reported at all.
There's a printf in video_do_capture that is commented out - "print("%u (%u) [%c] %s %u %u B ....". Enable that. What timestamps do you get? When I run "./yavta --capture=1000 -f UYVY -T -m /dev/video0 --field interlaced" or "--field none" I get a solid 50fps reported.
It sounds like you're taking a long time over delivering frames back to V4L2 if you get dropped frames reported. What differences do you have from my version of yavta?
grimepoch wrote:However, when combining the fields, I can see clearly that sometimes the fields match for awhile, then sometimes they don't, and of course this makes a juddering/strobe effect. It's not just normal field differences, it's clearly temporally MUCH longer than 1/60s

I've monitored my code, and I am not dropping buffers, most of the time I get 2 buffers per dequeue cycle I run. I also make sure I pull a 3 and 2 frame next to each other being returned. I've tried both orders as well (2 followed by 3, or 3 followed by 2 field). I basically have a ring reference buffer where I track the returned buffers (I have 16) and match them up as they come in.
If you're getting two buffers dequeued at the same time then you are spending far too long between calling DQBUF. I would expect to block on DQBUF waiting for a buffer to be returned.
grimepoch wrote:Given that it works properly and improperly, over time, leads me to believe the unicam buffer is not grabbing all frames. Are we actually pulling through the frame # as reported by the CSI-2 received data packets? Or are we just creating new frame numbers in the driver? Unless the YAVTA output is meaningless in this context, or I misunderstand it.
If Unicam doesn't have a new buffer to store data into it doesn't deliver the buffer to your app, and it will write the next frame into it. At the end of that frame it will try to swap buffers and if there is still no new buffer it will overwrite it again. Repeat until there is a buffer available.

The ADV doesn't produce incrementing frame numbers. It sends a value of either 1 or 2 depending on which field it is.
The bcm2835-unicam driver is producing the sequence number based on the number of frames it delivers out (no accounting for dropped frames/fields). This was based on an existing driver so I just copied the behaviour.
Trying to derive a sensible behaviour (particularly with FIELD_ALTERNATE) is not easy - what do you do with the sequence number should you get just one field dropped.
For debug, add a log line to the driver in unicam_isr

Code: Select all

	if (ista & UNICAM_FEI) {
		/*
		 * Ensure we have swapped buffers already as we can't
		 * stop the peripheral. Overwrite the frame we've just
		 * captured instead.
		 */
		if (unicam->cur_frm && unicam->cur_frm != unicam->next_frm)
			unicam_process_buffer_complete(unicam, frame_number);
		else
			unicam_err(unicam, "No buffer swap - frame dropped\n"); //!!!! ADD ME
	}
that should log every time the driver fails to swap buffers.
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

Fri Aug 24, 2018 7:36 am

6by9 wrote:
Thu Aug 23, 2018 1:37 pm
Are you cross-compiling or compiling on the Pi? I'm a little confused as you have CROSS_COMPILE variables in there, but "sudo make modules_install" will fail badly if you really are cross-compiling.
I had just copied this from other code, that I saw online, specifically from here:

https://www.raspberrypi.org/forums/view ... 3&start=25

Where you had put this code out for someone else, haha, so that was your CROSS_COMPILE flag in there. That said, I am running on the Pi so I removed it. However, that triggered rebuilding everything, so my testing will be in awhile when it finishes! Haha.
6by9 wrote:
Thu Aug 23, 2018 1:37 pm
There's a printf in video_do_capture that is commented out - "print("%u (%u) [%c] %s %u %u B ....". Enable that. What timestamps do you get? When I run "./yavta --capture=1000 -f UYVY -T -m /dev/video0 --field interlaced" or "--field none" I get a solid 50fps reported.
It sounds like you're taking a long time over delivering frames back to V4L2 if you get dropped frames reported. What differences do you have from my version of yavta?
I just downloaded your version and ran it, I didn't change anything at that time. That was of course when the I2P code was active, so I disabled the print out while I was exploring the code. Once my machine is back, I'll also report back on this.
grimepoch wrote:However, when combining the fields, I can see clearly that sometimes the fields match for awhile, then sometimes they don't, and of course this makes a juddering/strobe effect. It's not just normal field differences, it's clearly temporally MUCH longer than 1/60s
6by9 wrote:
Thu Aug 23, 2018 1:37 pm
If you're getting two buffers dequeued at the same time then you are spending far too long between calling DQBUF. I would expect to block on DQBUF waiting for a buffer to be returned.
Well given I am in a OpenGL loop, my frame rate is lower as it processes in progressive. That said, I am fine with getting 2 fields per cycle, since I am using them together. (I was going to just update one or the other, but given I was seeing frames not coming in occasionally, I changed to looking for 2 that matched, or what I thought was matching.

Given I have 16 buffers, and at most it is returning 2 to me at a time, that means I have 14 buffers that it has to work with almost always. I cannot imagine I am getting any contention of non available buffering. I even did a run with 32 JUST to make sure, but it behaved the same as the 16.

I experimented with REALLY slowing down the GL loop by putting a sleep in there to see what would happen with my code. What I do is scan all the buffers that get returned in my ring and take the newest 2 fields the match (sequential) and then return all the rest. This is the best I can do to dump frames and get something okay reasonable.

Hopefully by tomorrow I will have some more details for you from these runs! :)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5538
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

Fri Aug 24, 2018 8:25 am

grimepoch wrote:
Fri Aug 24, 2018 7:36 am
6by9 wrote:
Thu Aug 23, 2018 1:37 pm
Are you cross-compiling or compiling on the Pi? I'm a little confused as you have CROSS_COMPILE variables in there, but "sudo make modules_install" will fail badly if you really are cross-compiling.
I had just copied this from other code, that I saw online, specifically from here:

https://www.raspberrypi.org/forums/view ... 3&start=25

Where you had put this code out for someone else, haha, so that was your CROSS_COMPILE flag in there. That said, I am running on the Pi so I removed it. However, that triggered rebuilding everything, so my testing will be in awhile when it finishes! Haha.
Official docs for building the kernel - https://www.raspberrypi.org/documentati ... uilding.md
There are slightly different steps for local building vs cross-compiling.

Cross compiling is generally so much faster that I would recommend it if you're doing any significant level of kernel development. We tend to use Ubuntu running in VirtualBox on Windows PCs. If you mount your Pi root directory over NFS from the VM it makes updates even faster as you only have to do a local copy of the modules within the VM.
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 25, 2018 3:26 am

Okay, got a chance to run everything.

1) After some initial dropped frames as the system begins to run, no frames are dropped from the driver. I monitored the output of the unicam driver with dmesg as I left the system running.

2) yavta shows a consistent frame rate when using that printf to monitor. What I saw before must have been the I2P output regarding dropped frames.

So, this leaves me to believe that the artifacts I am seeing are GLSL related. I have seen cases related to texture manipulation to where GLSL will switch between what appears to be double buffered output while I can only imagine something is not ready in the pipe-line. I'll dig deeper now that we know that the driver appears to be working properly.

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

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sat Aug 25, 2018 5:39 am

So my code was just resending the same buffer each pass if it didn't change into the gl texture, which seemed to cause a bit of an artifact, not really sure why. Now, I detect if I already sent that buffer to the texture, do not resend. So that solved the juddering.

Now I am just left with interlaced artifacts. Unless I employ some temporally based smart detection, I am not sure how I would solve this else wise. Given there is NO way smart detection would work well on the Pi, I'm left with trying to implement something like a BOB and/or weave algorithm which is at least better than what I am getting now (at the cost of a few more texture look ups per pixel, which are of course expensive).

I'm sure this is delving into an area that you might not care about, my posts about it here will be for others who come across this and I'll share what I find in terms of shaders.

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

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sat Aug 25, 2018 6:36 am

Alright, much better. I found this de-interlacer which basically just blends the adjacent even/odd field and writes into both. Basically it is a Y blur, but, you are retaining both fields information in the blur, which the I2P processor does not do, it interpolates a new line between.

This is the algorithm I basically used (converted for my texture setup, written by VADE. I also believe this is the same as the ofxDeinterlacer available in open frameworks. Works FANTASTIC.

Code: Select all

VADE DE-INTERLACER


// define our rectangular texture samplers 
uniform sampler2DRect tex0; 

// define our varying texture coordinates 
varying vec2 texcoord0; 
varying vec2 texdim0; 

void main (void) 
{ 
// we have to average like so: 
// scanline 0 and 1 are (0 + 1) / 2. 
// scanline 2 and 3 are (2 + 3) / 2. 

// we need to not do 
// scanline 0 and 1 are (0 + 1) / 2. 
// scanline 1 and 2 are (1 + 2) / 2. 

float isodd = mod(texcoord0.y, 2.0); // returns 0 or 1. 

vec4 result; 

if(bool(isodd)) 
{ 
vec4 evenfield = texture2DRect(tex0, vec2(texcoord0.x, texcoord0.y + 1.0)); 
vec4 oddfield = texture2DRect(tex0, texcoord0); 

result = mix(evenfield, oddfield, 0.5); 
} 

else 
{ 
vec4 evenfield = texture2DRect(tex0, texcoord0); 
vec4 oddfield = texture2DRect(tex0, vec2(texcoord0.x, texcoord0.y - 1.0)); 

result = mix(evenfield, oddfield, 0.5); 
} 

gl_FragColor = result; 

// moo : short cow ! 
} 

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

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sun Aug 26, 2018 10:23 pm

Digging into this a little deeper, I am seeing the order of top/bottom field isn't staying consistent with the frame number when hooking up a source to the ADV7182.

In that, I know my code is grabbing the fields relative to the TOP/BOTTOM tag and always placing them in the exact same textures, which I interpret specifically.

With a DVD player, I attach/unattach/re-attach to the CVBS input and I notice that sometimes the field orders are reversed. They stay reversed as well, so whatever mechanism is deciding the order of the fields, it stays consistent.

I'll take a look at the driver and see if I can understand how you are deciding which field is which.

I think we need to use the line start/end packet info, not the frame start/end. If the line start packet is even or odd indicates which field is being sent in the frame.

I've verified in the captures I referenced earlier, for each frame, all the line start codes are even or odd depending on which field they represent. So even if we just captured the first or last line code data while processing a frame, we could use that to know which field we received.

I'm in the unicam code, but I have no reference for using cap1 as you mentioned before to know how even to install that extraction of data from a line start code. I imagine once we get cap1 doing the check, this is the area of the code we could use:

Code: Select all

	if (sta & UNICAM_PI0) {
		u32 cap0 = reg_read(cfg, UNICAM_CAP0);

		if (get_field(cap0, UNICAM_CPHV))
			frame_number = get_field(cap0, UNICAM_CWC_MASK);

		reg_write(cfg, UNICAM_CAP0, 0x80000000);

		ista |= UNICAM_FEI;
	}
We could still use frame_number variable if you wanted from that new derived field information, just to simplify the changes.

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

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sun Aug 26, 2018 11:51 pm

I should also add that the documentation makes you believe that the the frame # should work, as there are settings as to which gets output depending on even/odd fields.

I'm just not sure how to determine why they are getting reversed. To me that would imply the ADV7182 is doing it because it stays consistently wrong, which means the internal processing of the ADV7182 has to be sending them in the reverse order. Like their counter logic is getting offset by 1 and they don't resync it.

Which leads to the question, what if the line count is also from the same logic and is reversed.

The reason I don't think it is my code is I am looking for a consecutive 2 and 3 (thats the numbers for the FRAME ODD/EVEN flags). So those are getting reversed somehow.

I tried asking a question over at EngineeringZone but it looks like it's read only till the middle of next week.

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

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 28, 2018 4:59 am

I'm getting one more problem as well and for the life of me, cannot figure out what could cause it.

I used a DVD player with a progressive source movie stuffed into a 480i frame, so that I know both even/odd fields match temporary in content. In fact, I hooked up the DVD directly to a video capture device and went frame by frame verifying I NEVER had mouse teeth in the image.

I took that same segment of video and passed through the ADV7282.

While capturing frames to display, I verified that the sequence # always matched, and I always had 2 consecutive fields. In fact, the buffers were also always 1 apart as well.

To make sure I wasn't getting some weirdness from something else, I copied the data out of the 2 buffers and merged into 1 single texture, that I sent to a GLSL shader. So I know there isn't some issue with one texture working and not another. I used memcpy to transfer into my own buffer, then GLSL reads immediately into texture when I tell it to (it doesn't wait).

I then captured the output of this using the same mechanism (Black Magic Capture). What I found is it appears I get frames that have the top of the old frame, and then bottom of a new frame. Yet when I capture and verify EVERY SINGLE set of frames from buffers I sent, there is never a situation where I had frames from different sequences (comparing the info from the buffer struct).

Right now I am running in non-blocking mode, so if there isn't a new frame, I just leave the code and wait a bit to come back.

So I tried, call select once to know something is there, then go through a bunch of dequeue till it fails with no frame available, then use each returned buffer (I get 2 fields to 1 field per cycle, which is fine since my GL loop is running at progressive speeds).

I also ran one select PER dequeue, same result.

I read somewhere that some V4L2 driver implementations are designed to repeat a frame if something new is not available, but it is supposed to have identical settings in the buffer structure. Could this be happening and not working properly?

I'm also not certain if both problems I am seeing (mixing up even/odd consistently for duration of capture) and this aren't related somehow.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5538
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 28, 2018 10:45 am

I'm only working with the information provided by the ADV on the data stream. I do have that caveat in the code that Murphy's law says I will have it the wrong way up, but it will always be consistent with the data from the CSI2 source.
We really need confirmation from AD here as nothing is documented about this in the datasheet.

Plumbing in line counts is going to be moderately painful. I'd want 100% guarantees from AD that it will work before thinking about investing the time. It's a custom thing for this one device, and none of it is standardised.
grimepoch wrote:
Tue Aug 28, 2018 4:59 am
I read somewhere that some V4L2 driver implementations are designed to repeat a frame if something new is not available, but it is supposed to have identical settings in the buffer structure. Could this be happening and not working properly?
Nope, definitely not. That is not a requirement of the API that I've ever heard of. The normal behaviour is to block waiting for a new buffer, or you poll/select on the fd waiting to be told that a buffer is available before calling DQBUF if you don't want to block.
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

Tue Aug 28, 2018 12:01 pm

I think what you've said makes sense, especially the fact it feels like we are not getting consistent frame numbers with regards to field order.

The forums are supposed to be open today, so I'll get that question out there and see what possibly could be going on. Maybe there is something with the CSI-2 settings in the ADV7282 that need to be looked at (I will confirm the CSI-2 register settings happening in the driver).

Pertaining to the dropped or repeated frame, I had been referencing this text in the V4L2 documentation on the buffer struct:
In V4L2_FIELD_ALTERNATE mode the top and bottom field have the same sequence number. The count starts at zero and includes dropped or repeated frames. A dropped frame was received by an input device but could not be stored due to lack of free buffer space. A repeated frame was displayed again by an output device because the application did not pass new data in time.
However, given I do not see any out of sequence. The only thing I could imagine is the ADV chip itself skipping a frame, which seems unlikely. The stream seems pretty consistent.

In any case, let's see what they say.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5538
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 28, 2018 12:19 pm

grimepoch wrote:
Tue Aug 28, 2018 12:01 pm
In V4L2_FIELD_ALTERNATE mode the top and bottom field have the same sequence number. The count starts at zero and includes dropped or repeated frames. A dropped frame was received by an input device but could not be stored due to lack of free buffer space. A repeated frame was displayed again by an output device because the application did not pass new data in time.
If it is the application not passing data in time then this is for a V4L2 OUTPUT device, not capture. We're a capture device. V4L2 output devices are very rare these days as most people use DRM or similar.
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 29, 2018 5:36 am

Thanks for being the voice of reason on the code, haha, so after MANY hours tonight, we found a progressive scan video recorder, so we KNEW that the output was exactly progressive stuffed in interlace. Works perfect.

Went back to the video we were using, I think the 24fps to NTSC transfer causes certain frames to have blur, others not, and we confirmed this.

So that answers that question, the frames are correct, the order is correct.

For the random starting of even/odd, surprisingly enough, I *think* it might have been me accidentally setting the planes fields to something when we did not have planes. I set those back to zero, and it looks like the initial detection is correct.

Still testing, but looks good.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5538
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 29, 2018 6:29 am

3:2 pulldown to convert from 24fps to NTSC does cause odd effects, so that would be a very sensible explanation. I was slightly wondering what your progressive source was, but hadn't thought of that bit.
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: No registered users and 11 guests