Re: Can't get kino or dvgrab to work

On Tue, Oct 20, 2009 at 11:28 AM, Stefan Richter
<[email protected]> wrote:
> On 20 Oct, Dan Dennedy wrote:
>> On Tue, Oct 20, 2009 at 12:30 AM, Stefan Richter
>> <[email protected]> wrote:
>>> Danny Piccirillo wrote:
>>>> I've been trying to capture video from my DV camera but Kino freezes every
>>>> time i try (using Ubuntu Karmic by the way), and dvgrab won't grab more than
>>>> the first few seconds. dvgrab has at least made some progress and captured a
>>>> little bit, but for some reason it stops early.
>>>
>>> dvgrab stops early for me too (when I tried it the last time), but I can
>>> successfully work around that by means of the -noavc option.
>>
>> Let's focus on dvgrab for now. My suspicion is that dvgrab believes it
>> is at the end of the tape, and -noavc suppresses the ability to detect
>> that. I have not reproduced the problem yet. It could be
>> device-dependent behavior.
>
> Uh, I left an important fact out of my "report":  Lately I used this
> camcorder without a tape inserted, in webcam mode.  (I never ever record
> anything, I got this camcorder for nothing else than driver testing.)

Yes, that is important

> So here is what happens:  Without noavc option, dvgrab exits with a
> message like
>
>        Found AV/C device with GUID 0x008088030960484b
>        Waiting for DV...
>        Capture Started
>        "dvgrab-010.dv":     0.14 MiB 1 frames timecode 00:00:00.00 date 2009.10.20 18:54:45
>        Capture Stopped

I believe I have a limitation in detecting the exact state. IOW, I
believe I may not be able to determine the difference between this and
the end-of-tape. I will have to review this use case to be sure.  For
now, for this use case, -noavc is required.

> if I have no tape inserted.  With tape in it, dvgrab captures the
> webcam-mode video stream.  Also, with tape inserted and camcorder in
> play mode, dvgrab starts the tape and records.
>
> Kino is a little bit different:  Always shows the live preview, but

Kino is no longer being developed or even actively maintained.

>>> Dan had a suggestion for me what I should check in the dvgrab source to
>>> narrow down my problem, but I didn't spend the time to do that yet.
>>
>> There is a big test in the middle of captureThreadRun() in dvgrab.cc
>> around a call to writeFrame(). It would be interesting test for
>> someone who is affected by this bug to comment the if lines and call
>> writeFrame unconditionally to see if it resolves.
>
> Hmm.  I left the three blocks with "buffer underrun...", "damaged
> frame...", and "frame dropped..." intact because these messages were
> never printed, and changed the else block thus:

correct, and you changed what I was hinting at, but this is not the
part of the code that is doing end-of-tape detection.

-- 
+-DRD-+

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference