Announcement

Collapse
No announcement yet.

Dropped frames... again !!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dropped frames... again !!

    Hi, I know that this dropped frames stuff has been talked from the time of the Romans but here I go again : I'm using VirtualDub (1.4.7) with a G450 eTV to capture some Hi8 tapes. First, I captured 1 min using YUY2 with the Huffyuv codec (predict gradient setting) @ 29.97fps and a 352x240 resolution. Te result was one 180MB AVI file with 1 dropped frame. The CPU usage during the capture was around 14%.

    Believing that this test was conclusive I started to capture the entire tape. 40 minutes later I noticed that the dropped frames counter was changing very fast (must have been 20+ lost frames per second) so I stop the capture.

    The output file was a single 5.5GB AVI file. I opened it with WMP 6.4 and FF to the end. I couldn't notice anything wrong with the picture so it appears that the dropped frames was a bug in the VirtualDub interface or something like that.

    My system :
    MSI 6330 MoBo with integrated AC97 sound
    Athlon 1400 MHz
    768MB SDRAM
    Matrox 40GB 7200 rpm HD drive for capture (empty) NTFS
    Win2K Pro with SP2

    What bugs me is that for a while VirtualDub doesn't drop any frames and at a given point it begins to drop almost all of them, at least that's what the counter tells.

    Any ideas of what's happening here ?

    Thanks in advance !!

    Christian.

  • #2
    If I remember corectly (help me here doc..) There is the different versions of the AVI header that eneables the Avi file to be either 1,2 or 4 GB.

    anyting above that produces that kind of results...
    If there's artificial intelligence, there's bound to be some artificial stupidity.

    Jeremy Clarkson "806 brake horsepower..and that on that limp wrist faerie liquid the Americans call petrol, if you run it on the more explosive jungle juice we have in Europe you'd be getting 850 brake horsepower..."

    Comment


    • #3
      This limit is exactly 2^31 microseconds. It's a bug in the Maxtrox drivers. Read more about it here:



      Does anyone know if Matrox has produced a new
      driver which fixes this bug?

      Comment

      Working...
      X