#71 (K)Ubuntu Feisty: Capture hangs after just a few frames

closed
None
5
2007-04-08
2007-03-21
No

For some reason, xvidcap hangs after capturing just a few frames on Kubuntu Feisty, whereas it worked under Edgy. I've not noticed any problems with any of the other software I've recompiled under Feisty, so I'm doubting it's a simple compiler issue.

I've tested this with the current SVN/ffmpeg-8195, as well as the 1.1.5rc1 version.

When capturing, the counter will stop and the interface will become unresponsive somewhere between 1 and 20 frames into the video.

Any idea on the best way I can begin troubleshooting this?

Thanks,

Discussion

  • Karl H. Beckers

    Karl H. Beckers - 2007-03-21
    • assigned_to: nobody --> charly4711
     
  • Karl H. Beckers

    Karl H. Beckers - 2007-03-21

    Logged In: YES
    user_id=782084
    Originator: NO

    can you give me the exact command line, so I can try to reproduce this?

     
  • Jesse Litton

    Jesse Litton - 2007-03-21

    Logged In: YES
    user_id=210111
    Originator: YES

    It happens when I simply run "xvidcap" and hit the record button (all default preferences; no .xvidcaprc).

    You gave me a good test though: I found that if I start xvidcap from the command line with no GUI, it records normally. So, the problem appears to be specific to the GUI.

    I've imported the project into KDevelop, with the intention of doing a debug build to see if I could determine exactly where it was hanging. Do you know an easier way to do this? Unfortunately, the majority of my programming experience is on Windows... so I'm not familiar with all the debugging tools available in Linux.

    -J

     
  • Karl H. Beckers

    Karl H. Beckers - 2007-03-21

    Logged In: YES
    user_id=782084
    Originator: NO

    xvidcap is not normally stripped of debugging symbols, so no need to do a special debug build.
    What you could do is run xvidcap through gdb (though I suppose KDevelop does that internally).
    You'd do smth. like:
    gdb ~/xvidcap/bin/xvidcap
    break xtoffmpeg.c:12345
    run --auto --file test.avi

    The line with the break sets a breakpoint at line 12345 of the file xtoffmpeg.c. Of course, you need to have a suspicion. Locking would indicate smth. around threading (locking and releasing mutexes).
    For more on gdb, I always refer to:
    http://www.cs.princeton.edu/~benjasik/gdb/gdbtut.html
    http://www.delorie.com/gnu/docs/gdb/gdb_toc.html

    Btw. have you tried to disable audio?

     
  • Jesse Litton

    Jesse Litton - 2007-03-22

    Logged In: YES
    user_id=210111
    Originator: YES

    I have tried capturing from the GUI with audio disabled, but it does not appear to make any difference. I've also tried playing with a few of the other settings (shared memory, etc...) but I do not see any visible difference.

    KDevelop's having some issues creating a debug build... so I'll have to wait until this weekend when I can find more time to look into debugging.

     
  • Jesse Litton

    Jesse Litton - 2007-04-08
    • status: open --> closed
     
  • Jesse Litton

    Jesse Litton - 2007-04-08

    Logged In: YES
    user_id=210111
    Originator: YES

    I'm not sure if it was changes in ffmpeg, or the changes you made to xvidcap, or one of the hundreds of recent feisty patches, but I just now sat down to debug this and am extremely happy to find that the bug has disappeared after updating everything.

    Thanks for all your time. And thanks for the link - I will definitely have to check that out for the next time I run into a locked program.

    Keep up the good work,

    -J

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks