Trouble capturing Composite on DM6467T EVM

Helmut,

Looks like COMPOSITE input is not active. Setting input fails in that case. May be you need to test wether COMPOSITE source is active by connecting it to a TV once.

Regards,

Nag

Hi,

I would suggest to try out sample application first to make sure set up is correct. You can try out saUserPtrLoopback.c or saMmapPtrLoopback.c sample application. These applications detects input and sets the same input on display and capture.

Thanks,

Brijesh Jadav

Nag & Brijesh Jadav,

Thanks very much for your advice.

Unfortunately, I believe neither will help directly.  Please consider the below and advise me further.  I would greatly appreciate your doing this.

Nag, my composite source is already going through a Y-cable and being displayed on a TV monitor, so I'm certain that the source is active.

Brijesh Jadav, on the side, please educate me.  Is your given name Brijesh or Jadav?  In some cultures, the second name is the given name.  Regardless, how should I address you?  For now, I'll just copy your signature!  Anyway, I tried the dmai_loopback and discovered that it wants to set up the display in the same format as the capture.  I believe this is the same as you suggest here.  Unfortunately, the DM6467T EVM does not have a composite output, only a composite input.  Note that I do not have an ADV7343 daughter card. Note also that when my own custom board soon finishes assembly, it will have strictly composite I/O.  But debugging on that would be to debug software and hardware at the same time, which would be foolish and much more complicated!

Everyone, perhaps I can nevertheless leverage your advice.

1) Do you not see inconsistency in the error text "Invalid argument"?  Sure, the question is subjective.  I would hope "Invalid" meant the argument could never be correct, regardless of the physical environment.  But then the code author may have been a little lose with their language, which is often the case.  Nag implies that it only means the argument didn't lead to success.

2) Is there possibly a straightforward path to adjust Brijesh Jadav's advice.  For example, is there an existing loopback/conversion program that can input composite then output component?  Otherwise, I could try simply encoding the composite to a disk file.  If it merely ran without error, I would be getting further than today.  I would not necessarily have to later decode that file and then convert it's format (if not already a part of the decode) for composite output.

3) Please note this additional info.  When analyzing the source code in the guts of the failing ioctl() call, I find myself looking at vpif_capture.c.  I believe this is where the ioctl() from dmai's capture.c gets actually executed.  Anyway, in that code there was a lot of referencing to a "sub device".  This makes me wonder about the two TVP5147's and if I'm getting the wrong one selected, or if I'm failing to specify which I want.  Of course, I'm using Capture_Input_COMPOSITE, and there is an Capture_Input_SVIDEO that I'm not using.  So this ought to be where such selection is occurring.

4) I'd rather not add the complexity of purchasing and testing out the ADV7343 daughter card.

I think path #2 may be the most promising.  Any more advice specifically in this area?

Thanks again,

Helmut

Hi,

Can you try below code snippet in your environment and see if it works?

fd = open("/dev/video0", O_RDWR);

if(fd <= 0) {
                perror("Open\n");
                exit(0);
}

input_idx = 0;
ret = ioctl(fd, VIDIOC_S_INPUT, &input_idx);
if(ret < 0) {
                perror("VIDIOC_S_INPUT");
                close(fd);
                exit(0);
}

You can call me Brijesh

Thanks,

Brijesh

Brijesh,

Very interesting.  I embedded your snippet in MY application code, immediately before my call to Capture_create().  I added a close(fd) at the end of the snippet, so that if it succeeded and flowed on through to my Capture_create(), the resource(s) should be freed up.

Guess what.  With the snippet's open/ioctl, it caused my Capture_create() to work!  The code progressed to an existing check for 720P, that it failed, because I have not yet upgraded the program yet by omitting that check as well as analyzing the remaining software to see what needs to be upgraded for NOT being 720P.

Oops.  That was only the FIRST time I ran.  

1) That first time was after powering on the EVM, logging in, and running my script that leads to this code.  

2) When I ran a second time, the ioctl failed.  I assumed it may have been due to a resource not being free (although this should have caused the open to fail), because of my later 720P check that might be exiting the program non-gracefully.  

3) Therefore, I shutdown and restarted linux to try for a third time.  My thinking was that this would clear up resource usage.  It didn't help.  The ioctl fails again.

4) So, I shutdown and powered off for 10 seconds.  This should certainly reset the TVP5147, CPLD, and everything else.  Yippie!  The ioctl worked again!

Therefore, I can be sure of two things:

A) My existing code (Capture_create with particular parameters) can successfully open the capture device by first tentatively open/ioctl/close beforehand (your snippet plus close).  Therefore, something is missing from my existing code.  Note that this code works for component before changing all parallel things to values needed for composite. So either I have failed in my "parallel changes", or else to get composite working requires more than component requires.

B) The fact that I can't run twice without a cold restart means that I'm either leaving things messed up, or the extra stuff should only be done once per cold start.  Since I am error-ing out on that 720P check, it's most likely the case that I'm leaving things messed up.

I will continue testing by seeking a clean exit to my program, as opposed to the current exit due to 720P...

Yep, removing 720P check allowed code to continue.  I get video (albeit not format converted to my 720P display and therefore all crossed up)!!!  Also, I can stop program with IR remote, then run things again and they work the same.  This means the (B) fact of can't run twice was due to ungraceful exit.   (Note I'll work on format conversion later.  Note I'll rely on your Composite/YUV422SP advice elsewhere in doing so.  I can handle that, now that I have composite capturing occurring at all.  Note also I've gotten to the point of knowing that the ungraceful exit is inherited from encodedecode, by testing from fresh with my source turned off and forcing a common error.  This means that example could use some improvement.  Perhaps I'll remember and be able to feed back suggestions there.  )

This now leaves the (A) fact that the snippet fixes the problem.  Why?  I'll analyze a little further to see if my "parallel changes" are incorrect (insufficient)... (11:28am since 5am.  Early lunch then back on to this.)

BTW, I enjoy learning about and great respect other cultures or cultural origins/backgrounds.  Thanks for the info.

-Helmut

PARTIALLY RESOLVED!

I put everything back the way it was in the beginning, aside from my getting rid of the 720P format check inherited by my application.  After a COLD START, my application runs with composite video in and mish-mashed component video out.  This is a "success", prior to actually coding format conversion.

It turns out that the cold start was the problem all along.  The application exited non-gracefully due to the 720P format check, and this messed things up.  Several WARM STARTS ("shutdown -r 0" on the arm terminal monitor) did NOT clean this up yesterday.  I kept power on all day yesterday.  With power off overnight, I discovered the glee of the cold start.  With that discovered, and with the non-graceful exit avoided by omission of the 720P format check, I can now run over and over again after having my first cold start.

This tells me there is an INITIALIZATION BUG somewhere, probably in the linux driver for the TVP5147.  There should be no difference in a cold and warm start, but there is.  This means the [driver] is failing to [re-] initialize something [in the TVP5147] on a warm start, leaving it to the cold start to do this.  (This bug, aka failure to initialize, could be in dmai somewhere, but I would think that all the TVP5147-specific stuff ought to be in it's driver, and I would think the cold start can only impact actual hardware registers, thus my focus on the TVP5147 or perhaps the CPLD or even less likely the CPU(s).)

So, let's (Brijesh or someone else viewing this thread) please inform those responsible for this driver.  I'm too far behind schedule due to this (and other $#!*) to try to fix the driver myself, aside from my lack of prior experience on this specific code.  I can offer bug-reproduction guidance, of course.  But really all I've done is (1) recompile kernel for using TVP514x, change progeny of encodedecode to use Capture_Input_COMPOSITE as videoInput.  I believe that suffices as the only changes necessary to reproduce the problem.  Sure, encodedecode will crash later due to format checks, and you'll have to warm or cold restart, but at least you should be able to reproduce the difference in cold and warm restarts.

Thanks very much,

Helmut

Hi,

I agree, it looks like there is some issue in open source TVP driver.

Thanks,

Brijesh