• Not Answered

OMAP3530-ISP dropping fields from TVP5150.

We are working on a custom multimedia platform based on the OMAP3530 EVM Rev. G from Mistral.  It is very similar to the EVM and use a modified kernel based upon it.

One hardware difference is that we are using a TVP5150 video decoder chip rather than the TVP5146 on the EVM.  We had to modify the 5146 driver as well as the ISP driver to support it.  The ISP driver had to be modified to ignore the lack of HS_VS interrupts and use VD0 interrupts for processing instead.  For some weeks now, we've had the drivers working and capturing video through the V4L2 interface, and encoding H.264 and MP4 using the DSP.  

Unfortunately, we've now noticed that we're not getting an interrupt on every field in the video stream.  This is resulting in corrupted frames and jerky, jittery video.  This is a major problem as we require 29.97 fps, high-quality video, and still-frame captures for our product.  Has anyone else come across this problem?  Are there any suggestions as to what might be causing this problem, and how we might go about fixing it?

19 Replies

  • In reply to Dennis E:

     

    ah!  ok.  You increased the timeout from the 10 msec default. 

    I found that after I get the VD0 interrupt, it takes around 14.9 msec before the CCDC busy flag clears.  At 60hz, this is basically a whole field time!  During that 15 msec, the code is probably spinning in the busy loop waiting for busy flag to clear.  Maybe this is what causes high CPU utilization on the ARM side?

    Very shortly after the busy bit clears (like 1.8 msec later), I get the next VD0 interrupt.  I'm still trying to figure it out, but it's almost like I'm getting VD0 interrupt at the beginning of the field instead of the end of the field.  Not sure if this could cause you dropped frames?

    Chris

     

     

     

  • In reply to Dennis E:

    Hi Dennis,

    Let me break your question,

     

    >>>My supervisor's putting pressure on me to get the field dropping problem resolved this week.  Do you have any other recommendations for me?

    [Vaibhav] We have to change our ISR routine not to use HS/VS interrupts and only use VD0 & VD1 interrupts, whole buffer processing logic will now dependent on VD0 and VD1 interrupts.

     

    >>> I've found that the saMmapLoopback example application takes about 10-15% of CPU for 30fps capture and display, so that seems to provide a baseline for performance on

    >>> our hardware.  This number seems awfully high when compared to the benchmarking data you provided, but we could live with it.

    [Vaibhav] The bench-marking data which I have shared is captured with different application (saUserPtrLoopback.c), saMmapLoopback.c file does memcpy operation from Capture buffer to Display buffer and that's where you are seeing high CPU consumption. You use USERPTR mode of operation to avoid memcpy operation and use the same buffer between both Capture and Display.

    Please refer to saUserPtrLoopback.c file for reference.

    >>>I've found, additionally, when I enable the composite video out instead of DVI, the calculated framerate drops to 25fps and a large number of fields are missed.

    [Vaibhav] This is not frame drop, your Composite out (rather TV out) standard must be PAL which leads to 25FPS. This is expected behavior. Please keep both standard (incoming & outgoing streams) same, either NTSC or PAL.

     

    >>>Could there be something with our hardware or software setup at a very low level, like DDR timings, or cache mis-calibration, or something else systematic that

    >>>would cause the CPU to use so many cycles doing something fairly simple?

    [Vaibhav] I think I have answered all your question above which are more-or-less expected behavior so I don't expect it to be any Cache/DDR related issues. Rather I would say currently we do not have any data pointers which will lead to this conclusion.

     

    Thanks,

    Vaibhav


  • In reply to Vaibhav Hiremath:

    Vaibhav Hiremath

    [Vaibhav] We have to change our ISR routine not to use HS/VS interrupts and only use VD0 & VD1 interrupts, whole buffer processing logic will now dependent on VD0 and VD1 interrupts.

    I've done the same since the beginning.  What do you use VD1 for? I only use VD0.

    Vaibhav Hiremath
    [Vaibhav] The bench-marking data which I have shared is captured with different application (saUserPtrLoopback.c), saMmapLoopback.c file does memcpy operation from Capture buffer to Display buffer and that's where you are seeing high CPU consumption. You use USERPTR mode of operation to avoid memcpy operation and use the same buffer between both Capture and Display.

    That makes sense.

    Vaibhav Hiremath
    >>>I've found, additionally, when I enable the composite video out instead of DVI, the calculated framerate drops to 25fps and a large number of fields are missed.

    [Vaibhav] This is not frame drop, your Composite out (rather TV out) standard must be PAL which leads to 25FPS. This is expected behavior. Please keep both standard (incoming & outgoing streams) same, either NTSC or PAL.

    This actually is frame/field drop.  I have my ISR print a message when the number of the field received (0 or 1) is not the one that's expected, and I get a number of them, perhaps 5 per second, corresponding to a 5 fps reduction in framerate.  That is why I brought up this behavior in the first place, it manifests itself in the ISR in the same way as the original problem I need to fix.  What would cause my TV-out to be set to PAL? It's not PAL by default is it?  I haven't looked at that as a possibility.

    Thanks

    Dennis

  • In reply to chrisw957:

    Chris,

    I also noticed such behavior, that the CCDC busy flag stays set for a very long time, and that it's almost as if the VD0 interrupt occurs at the beginning of the frame instead of the end.  I wondered if it may be that the VD0 interrupt occurs at the end of the frame, but by the time the ISR occurs & the software begins processing it, that it may already be receiving the next frame.  There seems to be no way to determine the latency of this interrupt, however high latency would seem to be a very good candidate for the cause of the problems we're seeing.

    Dennis

  • In reply to Dennis E:

    Dennis,

    I tested a new daughter card which has the 5150 including VS and HS signals...  During normal operation, it doesn't get any "ccdc idle" timeouts.  I say during normal operation because I think I may have some hardware issues causing glitches in the incoming data which causes timeouts and errors in the video.  I haven't checked to see if there are any dropped fields.

    Which level shifter did you end up using?  Did you put terminating resistors between the level shifter and the overo?  If so, what value?  Right now we're using a 74AVC164245 with 100 ohm resistors inline on the overo side, and 33 ohm on the side going towards the tvp5150.  Originally we tried 33 ohm on both sides without good results, and I saw the pixhawk board used 100 ohm, so we're using that now.

    -chris

     

  • For anyone who might be interested in seeing the video that results from our problem, I've attached an H.264 encoded MP4 file which demonstrates the problem.

  • In reply to Vaibhav Hiremath:

    Hi Vaibhav,

     

    Could you explain this problem with ISP-CCDC and bt656 a bit further?

    I We've built a board using the tvp5151 and omap3530.


    I'm using AM35x-OMAP35x-PSP-SDK-03.00.00.05, and have ported the tvp514x-int.c for the 5151, and I'm seeing a very similar issue.

    I expected  to follow the EVM closely, but that does not seem to be the case. It appears that the EVM is using SYNC format from the tvp5146.  As the 3530 Torpedo does not connect CAM_FLD, I don't believe that I can do this.  If that's correct, and the OMAP cannot accept bt656, I've got a problem...

    Did you work out the issue with generating the HS/VS interrupts for BT656 streams?

     

    Thanks,

    Joel.

     

  • In reply to Joel Greene:

    Hi Joel,

    Let me summarize my previous findings (which has been conformed from Hardware expert) here once again,

    First of all,

    OMAP3 does support BT656 interface and it does decode incoming SAV and EAV bit fields without any issues, which has been validated with all PSP releases. On EVM, all sync signals like HS, VS and FLD has been interfaced to OMAP3 CCDC, so all along until now we were configuring TVP5146 to generate these signals along with BT656 streams and the ISP ISR routine is also implemented considering these 4 interrupts (HS, VS, VD0 and VD1).

    Now the issue/finding here is, if you don't connect HS and VS signals to OMAP3 CCDC, the input formatter won't be able to generate HS & VS interrupts. It has been conformed from Hardware team that input formatter is going to generate interrupts only on external HS/VS signals. I have already raised the issue to update this important information in the TRM which has been accepted and likely to get updated in next version of TRM.

    Now what that means is, the ISP ISR has to be changed to only deal with VD0 and VD1 interrupts.

     

    I hope above information clarifies all your doubts, please let me know if you have any issues.

    Thanks,

    Vaibhav

     

  • hello,we are working on beagleboard-xm platform,we are using TVP5151,why do you have to modify the 5146 rahter than 5150? Only do the isp support 5146? we also want to capture video through the V4L2 interface, and encoding H.264 using the DSP.  how can you do it ? can you give me you source ? thank you very much !