libdv-dev

Re: [libdv-dev] Possible bug encoding interlaced material?

[<no...@xs...>]

...

>   That said, I would be really interested in working on libdv++ or libdv2
>   making it easier for me to maintain both codecs at the same time.
>   Most likely this will mean leaving API 100% intact but changing
>   some of the implementation details quite a lot. If there's an interest
>   in me doing this -- please let me know.

Yes Roman, I would be interested in a next-gen libdv. I like the libdv API
better than the ffmpeg API, it is more to the point (probably because it
does not have to be as generic like the ffmpeg API).

Good luck,
Erwin

Driessens & Verstappen
www.xs4all.nl/~notnot

Re: [libdv-dev] Possible bug encoding interlaced material?

[Roman S. <rv...@Su...>]

On Thu, Apr 07, 2005 at 04:18:12PM +0930, Jonathan Woithe wrote:
> > On Wed, Apr 06, 2005 at 01:40:47PM +0930, Jonathan Woithe wrote:
> > > Essentially I tested ffmpeg's encoder both with a CGI frame and a "real
> > > world" frame.  The upshot was that with the real world frame ffmpeg's encoder
> > > appears to do a good job, while with the CGI input it's better than libdv but
> > > there are still issues.  Note though that these issues might be associated
> > > with the limits of DV's quality - I don't know and can't test this.
> > 
> >   In general, I agree with the way you did your experiments but:
> > 
> >     1. You shouldn't be doing deinterlancing. There are very few
> >        tools for that to handle PAL chroma issues correctly.
> 
> Um, the only deinterlacing I did was after the (interlaced) DV frame had
> been extracted to a PNG file.  This (as mentioned on the web page) used
> ffmeg's decoder via mplayer.  The resulting extracted PNG frame was still
> interlaced, so any PAL chroma issues should have been taken care of by the
> DV decoder used.  

  Nope. PNG uses RGB color space, while PAL DV operates in YUV420, thus
  you need a conversion. And the conversion of PAL chroma is a picky
  thing.

> If anything in those frames is caused by chroma issues
> then it would indicate a problem in the DV decoder. 

  Unfortunately, you can't really tell whether you've got artifacts from
  the colorpsace conversion or from the decoder. That's the reason I recommend
  using YUV4MPEG.

> In practice the
> evidence suggests that the artifacts illustrated are not the result of
> chroma mis-handling on decode - see my next point below.  In any case, the
> deinterlacing I did was only done once the encoded frame had been extracted
> verbatim to a PNG file by mplayer - only then did I load the frame into gimp
> for deinterlacing, and this was really only to make the artifacts clearer to
> the human eye when displayed on computer monitors.

  I understand your reasons, but as I've explained earlier, the correct
  sequence of steps to get a truly telling result would be:
     
     1. Extract to YUV4MPEG (make sure it's labeled as PAL).
     2. Use the deinterlacer from the mjpeg tools.

> >     2. The only format that doesn't screw up PAL chroma right away
> >        is YUV4MPEG. So you should be using it instead of PNG to
> >        store the output of the DV decoders. 
> 
> I don't think the chroma is getting adversely screwed by what I'm doing. 

  It is. Believe me.

> It is true that the mjpegtools (which use YUV4MPEG) generally handle the PAL
> chroma correctly.  Therefore I am reasonably confident that when my encoded
> DV goes to MPEG2 (for use on a DVD player) via mpeg2enc that the chroma will
> be handled correctly.

  That is a correct assumption.

> With this supposed correct handling of chroma, the
> DVD player shows exactly the field shadow artifacts which are illustrated in
> the PNG files I mentioned.

  Hm. That is interesting. Could you show us the full command line you use
  to go from DV to MPEG2 using ffmpeg and mjpegtools ?

> The other thing to note is that these artifacts are not present in the raw
> footage.

  Interesting. Could you post a sample of that raw footage somewhere for
  me to play with ?

> >     3. You might find it useful to try commercial DV codecs by the
> >        virtue of MPlayer .dll handling.
> 
> Are there any around which are freely available?  Hmm, Canopus appear to have
> a freely downloadable playback only DV codec; I'll see if I can get any
> joy out of that.

  I think Sony and Mainconcept have "free" ones.

Thanks,
Roman.

Re: [libdv-dev] Possible bug encoding interlaced material?

[Jonathan W. <jw...@ph...>]

> On Wed, Apr 06, 2005 at 01:40:47PM +0930, Jonathan Woithe wrote:
> > Essentially I tested ffmpeg's encoder both with a CGI frame and a "real
> > world" frame.  The upshot was that with the real world frame ffmpeg's encoder
> > appears to do a good job, while with the CGI input it's better than libdv but
> > there are still issues.  Note though that these issues might be associated
> > with the limits of DV's quality - I don't know and can't test this.
> 
>   In general, I agree with the way you did your experiments but:
> 
>     1. You shouldn't be doing deinterlancing. There are very few
>        tools for that to handle PAL chroma issues correctly.

Um, the only deinterlacing I did was after the (interlaced) DV frame had
been extracted to a PNG file.  This (as mentioned on the web page) used
ffmeg's decoder via mplayer.  The resulting extracted PNG frame was still
interlaced, so any PAL chroma issues should have been taken care of by the
DV decoder used.  If anything in those frames is caused by chroma issues
then it would indicate a problem in the DV decoder.  In practice the
evidence suggests that the artifacts illustrated are not the result of
chroma mis-handling on decode - see my next point below.  In any case, the
deinterlacing I did was only done once the encoded frame had been extracted
verbatim to a PNG file by mplayer - only then did I load the frame into gimp
for deinterlacing, and this was really only to make the artifacts clearer to
the human eye when displayed on computer monitors.

>     2. The only format that doesn't screw up PAL chroma right away
>        is YUV4MPEG. So you should be using it instead of PNG to
>        store the output of the DV decoders. 

I don't think the chroma is getting adversely screwed by what I'm doing. It
is true that the mjpegtools (which use YUV4MPEG) generally handle the PAL
chroma correctly.  Therefore I am reasonably confident that when my encoded
DV goes to MPEG2 (for use on a DVD player) via mpeg2enc that the chroma will
be handled correctly.  With this supposed correct handling of chroma, the
DVD player shows exactly the field shadow artifacts which are illustrated in
the PNG files I mentioned.

It is possible I'm missing something here though.

The other thing to note is that these artifacts are not present in the raw
footage when that goes to MPEG2 via mpeg2enc having not passed through
libdv's encoder - an observation which is consistent with images I extract
from the raw DV files using the same processes.  This would tend to clear
the analysis side of my method of suspicion I would have thought.

>     3. You might find it usefull to try commercial DV codecs by the
>        virtue of MPlayer .dll handling.

Are there any around which are freely available?  Hmm, Canopus appear to have
a freely downloadable playback only DV codec; I'll see if I can get any
joy out of that.

Regards
  jonathan
-- 
* Jonathan Woithe    jw...@ph...                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *

Re: [libdv-dev] Possible bug encoding interlaced material?

[Roman S. <rv...@su...>]

On Wed, Apr 06, 2005 at 01:40:47PM +0930, Jonathan Woithe wrote:
> Essentially I tested ffmpeg's encoder both with a CGI frame and a "real
> world" frame.  The upshot was that with the real world frame ffmpeg's encoder
> appears to do a good job, while with the CGI input it's better than libdv but
> there are still issues.  Note though that these issues might be associated
> with the limits of DV's quality - I don't know and can't test this.

  In general, I agree with the way you did your experiments but:

    1. You shouldn't be doing deinterlancing. There are very few
       tools for that to handle PAL chroma issues correctly.

    2. The only format that doesn't screw up PAL chroma right away
       is YUV4MPEG. So you should be using it instead of PNG to
       store the output of the DV decoders. 

    3. You might find it usefull to try commercial DV codecs by the
       virtue of MPlayer .dll handling.

Thanks,
Roman.

Re: [libdv-dev] Possible bug encoding interlaced material?

[Jonathan W. <jw...@ph...>]

> > > To my opinion there are to issues:
> > > 1. block artefacts in luma space. If noticed them too, even after first
> > >    recoding of the same frame with libdv.
> > > 2. shadows of the other field. This may be related to color handling of
> > >    other decoders too. As you encode with fps=25 I think you are
> > >    operating in PAL mode. You converted dv to png with mplayer who
> > >    uses ffmpeg to my knowledge as default decoder.
> > >    DV-PAL has different needs when 4:2:0 is decoded as color subsampling
> > >    is field based and not frame based.
:
> to (1): Yes, I tried to fix that, but I _failed_.  So it is still on the TODO list.
> to (2): There was a big thread on this list. It started on 2003-11-01,
>           subject: "libdv produces strange interlaced frames".
>           Mails from Roman's and me (2003-11-06/07) show the handling
>           of field based chroma information. This is implemented in libdv's
>           decoder for YUV2 output (not encoding part).

Right, so I take it from this that especially as a result of (2), libdv's
*encoder* really isn't up to the task yet if minimal artifacting is desired?

Is anyone working on this and/or is there a plan to address these issues
(particularly 2)?

Regards
  jonathan
-- 
* Jonathan Woithe    jw...@ph...                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *

Re: [libdv-dev] Possible bug encoding interlaced material?

[Stefan L. <st...@lu...>]

On Mittwoch, 6. April 2005 06:10, Jonathan Woithe wrote:
> Hi Stefan

> > To my opinion there are to issues:
> > 1. block artefacts in luma space. If noticed them too, even after first
> >    recoding of the same frame with libdv.
> > 2. shadows of the other field. This may be related to color handling of
> >    other decoders too. As you encode with fps=25 I think you are
> >    operating in PAL mode. You converted dv to png with mplayer who
> >    uses ffmpeg to my knowledge as default decoder.
> >    DV-PAL has different needs when 4:2:0 is decoded as color subsampling
> >    is field based and not frame based.
> 
> Yes, I am in PAL land (Australia to be precise).  I can also confirm that
> the default decoder in mplayer is ffmpeg.
> 
> I did some further tests overnight which might be interesting.  These
> involved using ffmpeg's encoder to see what it did.  The updated results
> are at the bottom of
> 
>   http://www.atrad.com.au/~jwoithe/mpeg/pantest/
> 
> Essentially I tested ffmpeg's encoder both with a CGI frame and a "real
> world" frame.  The upshot was that with the real world frame ffmpeg's encoder
> appears to do a good job, while with the CGI input it's better than libdv but
> there are still issues.  Note though that these issues might be associated
> with the limits of DV's quality - I don't know and can't test this.
> 
> Getting back to your comment about there being possibly two issues, I'm not
> sure I understand what you're suggesting.  In (1) are you saying that libdv
> is having trouble keeping luma information block-free and that this has been
> noticed at other times?  My understanding of (2) is that perhaps libdv's PAL
> encoder (and maybe its decoder as well) is not as well tested as the NTSC
> side of things and that it might still have gremlins lurking in it, and that
> these problems might affect ffmpeg's decoder as well?

to (1): Yes, I tried to fix that, but I _failed_.  So it is still on the TODO list.
to (2): There was a big thread on this list. It started on 2003-11-01,
          subject: "libdv produces strange interlaced frames".
          Mails from Roman's and me (2003-11-06/07) show the handling
          of field based chroma information. This is implemented in libdv's
          decoder for YUV2 output (not encoding part).

-- 
Stefan Lucke

Re: [libdv-dev] Possible bug encoding interlaced material?

[Jonathan W. <jw...@ph...>]

Hi Stefan

> > Over the past few months I've been trying to track down the source of
> > flickering during horizontal movement in DVDs I've been making.  The
> > details of all the tests I've done and the results are available for
> > viewing at
> > 
> >   http://www.atrad.com.au/~jwoithe/mpeg/
> > 
> > Initially I thought the problem was with mpeg2enc (from mjpegtools). 
> > However, of particular interest are the last round of tests at
> > 
> >   http://www.atrad.com.au/~jwoithe/mpeg/pantest/
> > 
> > These tests seem to suggest that the root cause of the problem actually lies
> > in libdv's encoder.  It appears that when presented interlaced input, libdv
> > doesn't do the right thing, and perhaps even assumes the input is
> > non-interlaced: each field of the encoded frame contains blocky shadows of
> > the contents of the frame's other field.
> 
> To my opinion there are to issues:
> 1. block artefacts in luma space. If noticed them too, even after first
>    recoding of the same frame with libdv.
> 2. shadows of the other field. This may be related to color handling of
>    other decoders too. As you encode with fps=25 I think you are
>    operating in PAL mode. You converted dv to png with mplayer who
>    uses ffmpeg to my knowledge as default decoder.
>    DV-PAL has different needs when 4:2:0 is decoded as color subsampling
>    is field based and not frame based.

Yes, I am in PAL land (Australia to be precise).  I can also confirm that
the default decoder in mplayer is ffmpeg.

I did some further tests overnight which might be interesting.  These
involved using ffmpeg's encoder to see what it did.  The updated results
are at the bottom of

  http://www.atrad.com.au/~jwoithe/mpeg/pantest/

Essentially I tested ffmpeg's encoder both with a CGI frame and a "real
world" frame.  The upshot was that with the real world frame ffmpeg's encoder
appears to do a good job, while with the CGI input it's better than libdv but
there are still issues.  Note though that these issues might be associated
with the limits of DV's quality - I don't know and can't test this.

Getting back to your comment about there being possibly two issues, I'm not
sure I understand what you're suggesting.  In (1) are you saying that libdv
is having trouble keeping luma information block-free and that this has been
noticed at other times?  My understanding of (2) is that perhaps libdv's PAL
encoder (and maybe its decoder as well) is not as well tested as the NTSC
side of things and that it might still have gremlins lurking in it, and that
these problems might affect ffmpeg's decoder as well?

Regards
  jonathan

Re: This is libdv devel list. (WAS: Re: [libdv-dev] Possible bug encoding interlaced material?)

[Stefan L. <st...@lu...>]

Reply handling error. Should go to the list.

On Montag, 4. April 2005 07:59, Roman Shaposhnick wrote:
> On Mon, Apr 04, 2005 at 07:41:08AM +0200, Stefan Lucke wrote:
> > On Montag, 4. April 2005 03:02, Roman Shaposhnick wrote:
> > > <F2On Mon, Apr 04, 2005 at 10:14:44AM +0930, Jonathan Woithe wrote:
> > > > Anyway, what do others think? =9AIs this an issue? =9AIs there a =
way to get
> > > > around it so interlaced material is encoded correctly to DV by li=
bdv?
> > > =9A=20
> > > =9A Oh, yeah! Use ffmpeg :-)
> >=20
> > Roman, this list should cover libdv development related things.
> > To me it is rather annoying as your default answer to questions like:
> > Q: I've a problem using libdv with ..
> > A: Use ffmpeg ..
> =9A=20
> =9A Well, I understand your feelings and attachment to the libdv,
> =9A and I can really see that "Oh yeah!" style can be considered
> =9A inappropriate by some. At the same time, all I can really
> =9A offer to mitigate your concerns is to start making these suggestion=
s
> =9A in private without Cc'ing to the mailing list.

Yes, my mail was rather emotional triggered. I didn't want to offend you.
If thats the case I'm really sorry for that.


--=20
Stefan Lucke

Re: [libdv-dev] Possible bug encoding interlaced material?

[Stefan L. <st...@lu...>]

On Montag, 4. April 2005 02:44, Jonathan Woithe wrote:
> Hi all
> 
> Over the past few months I've been trying to track down the source of
> flickering during horizontal movement in DVDs I've been making.  The
> details of all the tests I've done and the results are available for
> viewing at
> 
>   http://www.atrad.com.au/~jwoithe/mpeg/
> 
> Initially I thought the problem was with mpeg2enc (from mjpegtools). 
> However, of particular interest are the last round of tests at
> 
>   http://www.atrad.com.au/~jwoithe/mpeg/pantest/
> 
> These tests seem to suggest that the root cause of the problem actually lies
> in libdv's encoder.  It appears that when presented interlaced input, libdv
> doesn't do the right thing, and perhaps even assumes the input is
> non-interlaced: each field of the encoded frame contains blocky shadows of
> the contents of the frame's other field.

To my opinion there are to issues:
1. block artefacts in luma space. If noticed them too, even after first
   recoding of the same frame with libdv.
2. shadows of the other field. This may be related to color handling of
   other decoders too. As you encode with fps=25 I think you are
   operating in PAL mode. You converted dv to png with mplayer who
   uses ffmpeg to my knowledge as default decoder.
   DV-PAL has different needs when 4:2:0 is decoded as color subsampling
   is field based and not frame based.

> 
> A very brief glance at the libdv (and the included encodedv) source didn't
> turn up any obvious way to specify whether the input was interlaced or not.
> I don't know if this is an issue, but it's not at all obvious to me how
> libdv can know whether the frames being presented to it are interlaced 
> or not.
> 
> Anyway, what do others think?  Is this an issue?  Is there a way to get
> around it so interlaced material is encoded correctly to DV by libdv?  While
> having encodedv work correctly would be good, a general libdv solution is
> the most important consideration from my point of view since it would mean
> that the output from programs which use libdv (such as cinelerra) would be
> correct.
> 
> Best regards
>   jonathan
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev
> 
> 

-- 
Stefan Lucke

Re: [libdv-dev] DVCPRO50 support?

[Roman S. <rv...@su...>]

Hi, Steven!

Long time no see :-)

On Sun, Apr 03, 2005 at 11:03:04PM -0700, Steven M. Schultz wrote:
> Hi -
> 
> 	Has anyone looked into supporting DVCPRO50 - the 50Mb/s (4:2:2) DV
> 	variant?  
> 
> 	I know ffmpeg doesn't do it either :) 

  I can implement it for you there :-) (it's not too difficult at all)
  For libdv it shouldn't be too difficult either, however I'd rather
  see somebody replying to my libdv++ offer, first.  

Thanks,
Roman.

[libdv-dev] DVCPRO50 support?

[Steven M. S. <sm...@2B...>]

Hi -

	Has anyone looked into supporting DVCPRO50 - the 50Mb/s (4:2:2) DV
	variant?  

	I know ffmpeg doesn't do it either :) 

	Cheers,
	Steven Schultz

Re: This is libdv devel list. (WAS: Re: [libdv-dev] Possible bug encoding interlaced material?)

[Roman S. <rv...@su...>]

On Mon, Apr 04, 2005 at 07:41:08AM +0200, Stefan Lucke wrote:
> On Montag, 4. April 2005 03:02, Roman Shaposhnick wrote:
> > <F2On Mon, Apr 04, 2005 at 10:14:44AM +0930, Jonathan Woithe wrote:
> > > Anyway, what do others think?  Is this an issue?  Is there a way to get
> > > around it so interlaced material is encoded correctly to DV by libdv?
> >   
> >   Oh, yeah! Use ffmpeg :-)
> 
> Roman, this list should cover libdv development related things.
> To me it is rather annoying as your default answer to questions like:
> Q: I've a problem using libdv with ..
> A: Use ffmpeg ..
  
  Well, I understand your feelings and attachment to the libdv,
  and I can really see that "Oh yeah!" style can be considered
  inappropriate by some. At the same time, all I can really
  offer to mitigate your concerns is to start making these suggestions
  in private without Cc'ing to the mailing list.

  Please, try to understand me as well -- at this point ffmepg's DV codec
  proved itself to be quite stable and in a number of tests it was
  demonstrated that it offers more quality for the encoding.
  I really don't want people to be stuck with libdv if they have a choice
  and if ffmpeg suits them. They might even benefit from switching
  by gaining access to the whole variety of *other* codecs ffmpeg provides.
  
  However, in the FSF/Linux world DV == libdv. 

  Of course, ffmpeg's DV *FORMAT* handler is inferior compared to libdv's.
  Functionality wise that is. But than again, for some folks (like myself)
  quality of the encoder is much more important.
 
  Hope that explains why I'm making these suggestions all the time.

> If you know the source of some problems related to libdv it would
> be more polite to post a fix .

  I know a number of problems with libdv at this moment, however I really
  have no interest in fixing them. That wouldn't be a problem though,
  it there would be someone willing to act on this information.
  However, at this point my understanding is that libdv doesn't really
  have anybody interested in its further development. Correct me if I'm wrong,
  by you and Dan you strike me more like reluctant maintainers. 

  That said, I would be really interested in working on libdv++ or libdv2
  making it easier for me to maintain both codecs at the same time.
  Most likely this will mean leaving API 100% intact but changing
  some of the implementation details quite a lot. If there's an interest
  in me doing this -- please let me know. 

Thanks,
Roman.

This is libdv devel list. (WAS: Re: [libdv-dev] Possible bug encoding interlaced material?)

[Stefan L. <st...@lu...>]

On Montag, 4. April 2005 03:02, Roman Shaposhnick wrote:
> <F2On Mon, Apr 04, 2005 at 10:14:44AM +0930, Jonathan Woithe wrote:
> > These tests seem to suggest that the root cause of the problem actually lies
> > in libdv's encoder.  It appears that when presented interlaced input, libdv
> > doesn't do the right thing, and perhaps even assumes the input is
> > non-interlaced: each field of the encoded frame contains blocky shadows of
> > the contents of the frame's other field.
> 
>   To make things a little bit clearer could you, please, run your
>   experiments using ffmpeg instead of libdv. Both for encoding and
>   decoding.
> 
> > Anyway, what do others think?  Is this an issue?  Is there a way to get
> > around it so interlaced material is encoded correctly to DV by libdv?
>   
>   Oh, yeah! Use ffmpeg :-)

Roman, this list should cover libdv development related things.
To me it is rather annoying as your default answer to questions like:
Q: I've a problem using libdv with ..
A: Use ffmpeg ..

If you know the source of some problems related to libdv it would
be more polite to post a fix .

-- 
Stefan Lucke

Re: [libdv-dev] Possible bug encoding interlaced material?

[Jonathan W. <jw...@ph...>]

Hi Roman

> On Mon, Apr 04, 2005 at 10:14:44AM +0930, Jonathan Woithe wrote:
> > These tests seem to suggest that the root cause of the problem actually lies
> > in libdv's encoder.  It appears that when presented interlaced input, libdv
> > doesn't do the right thing, and perhaps even assumes the input is
> > non-interlaced: each field of the encoded frame contains blocky shadows of
> > the contents of the frame's other field.
> 
>   To make things a little bit clearer could you, please, run your
>   experiments using ffmpeg instead of libdv. Both for encoding and
>   decoding.

I actually tried this but things went pear-shaped fairly rapidly.  This was
a CVS snapshot of ffmpeg from 3 March 2005.  Initially I couldn't work out
how to convince ffmeg to accept a series of stills as input; eventually I
resorted to mencoder to write a MJPEG movie (just for the purposes of these
tests, since it's lossy and therefore undesireable at this stage of the
pipeline) which ffmpeg then accepted.  When I then used ffmpeg to output a
raw DV file encoded using libavcodec's DV codec, the resulting frames were
garbled almost beyond recognition (the mjpeg movie was fine when played in
mplayer).  At this point I gave up since the whole ffmpeg route seemed too
fragile and I didn't have time to pursue it further - I don't know for
example if the trouble was the mjpeg file produced by mencoder or the ffmpeg
codec itself).

I should note at this point that libdv's decoding appears to be fine.
Although not explicitly tested by me, viewing interleaved frames from raw
(from camera) DV data do does not seem to show the artifacts I see when the
libdv encoder has been used.  I will test this though, for completeness.

> > Anyway, what do others think?  Is this an issue?  Is there a way to get
> > around it so interlaced material is encoded correctly to DV by libdv?
>   
>   Oh, yeah! Use ffmpeg :-)

Unfortunately I need DV codec functionality in other programs such as
cinelerra (among others) and it is not entirely trivial to do this at this
point in time.

> > While having encodedv work correctly would be good, a general libdv
> > solution is the most important consideration from my point of view since
> > it would mean that the output from programs which use libdv (such as
> > cinelerra) would be
> 
>   Last I've heard cinelerra had a way of using ffmpeg's DV codec instead
>   of libdv. 

The unofficial CVS folks are working on it, but my reading of their mailing
list suggests it's not really production ready at this point, and besides,
at the present moment I need something which "just works".  A fix to libdv
would probably be easier than a wholescale move to ffmpeg's codec.

Regards
  jonathan

Re: [libdv-dev] Possible bug encoding interlaced material?

[Roman S. <rv...@su...>]

<F2On Mon, Apr 04, 2005 at 10:14:44AM +0930, Jonathan Woithe wrote:
> These tests seem to suggest that the root cause of the problem actually lies
> in libdv's encoder.  It appears that when presented interlaced input, libdv
> doesn't do the right thing, and perhaps even assumes the input is
> non-interlaced: each field of the encoded frame contains blocky shadows of
> the contents of the frame's other field.

  To make things a little bit clearer could you, please, run your
  experiments using ffmpeg instead of libdv. Both for encoding and
  decoding.

> Anyway, what do others think?  Is this an issue?  Is there a way to get
> around it so interlaced material is encoded correctly to DV by libdv?
  
  Oh, yeah! Use ffmpeg :-)

> While
> having encodedv work correctly would be good, a general libdv solution is
> the most important consideration from my point of view since it would mean
> that the output from programs which use libdv (such as cinelerra) would be

  Last I've heard cinelerra had a way of using ffmpeg's DV codec instead
  of libdv. 

Thanks,
Roman.

[libdv-dev] Possible bug encoding interlaced material?

[Jonathan W. <jw...@ph...>]

Hi all

Over the past few months I've been trying to track down the source of
flickering during horizontal movement in DVDs I've been making.  The
details of all the tests I've done and the results are available for
viewing at

  http://www.atrad.com.au/~jwoithe/mpeg/

Initially I thought the problem was with mpeg2enc (from mjpegtools). 
However, of particular interest are the last round of tests at

  http://www.atrad.com.au/~jwoithe/mpeg/pantest/

These tests seem to suggest that the root cause of the problem actually lies
in libdv's encoder.  It appears that when presented interlaced input, libdv
doesn't do the right thing, and perhaps even assumes the input is
non-interlaced: each field of the encoded frame contains blocky shadows of
the contents of the frame's other field.

A very brief glance at the libdv (and the included encodedv) source didn't
turn up any obvious way to specify whether the input was interlaced or not.
I don't know if this is an issue, but it's not at all obvious to me how
libdv can know whether the frames being presented to it are interlaced 
or not.

Anyway, what do others think?  Is this an issue?  Is there a way to get
around it so interlaced material is encoded correctly to DV by libdv?  While
having encodedv work correctly would be good, a general libdv solution is
the most important consideration from my point of view since it would mean
that the output from programs which use libdv (such as cinelerra) would be
correct.

Best regards
  jonathan

[libdv-dev] AV/C hangs under kernel 2.6

[Marko <mar...@hu...>]

Dan,

On Thu, Mar 10, 2005 at 08:46:39AM -0500, Dan Dennedy wrote:
> Right now, module removal of ieee1394 modules under kernel 2.6 is known
> to be problematic. None of the kernel messages shown are alarming
> except, of course, the Oops on card eject. None of the messages relate
> to AV/C deadlocking Kino. Can you test if transport control in dvcont or
> gscanbus works OK?

gscanbus became unkillable and entered a busy loop (presumably in the kernel)
either as the result of changing my camera from record mode (via power-off)
to play mode, or attempting to click the mouse on the camera icon.  During
this test, the following was displayed on stdout or stderr:

Error while reading from IEEE1394: : Resource temporarily unavailable
0/0x0000fffff000040c: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
0/0x0000fffff0000410: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
0/0x0000fffff0000414: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
Error while reading from IEEE1394: : Resource temporarily unavailable
Could not read topologyMap
Error while reading from IEEE1394: : Resource temporarily unavailable
Error while reading from IEEE1394: : Resource temporarily unavailable
Could not read topologyMap
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Invalid argument
Could not read topologyMap
Error while reading from IEEE1394: : Resource temporarily unavailable
0/0x0000fffff000040c: read failed

After rebooting, "dvcont verbose play" displayed

node 0 type = 2

and hanged (but didn't consume any noticeable amount of processing power)
until I turned off the camera (it was in play mode).  After that point,
it printed:

node 0 AVC video recorder? no
node 0 AVC disk recorder? no
node 0 AVC tuner? no
node 0 AVC video camera? no
node 0 AVC video monitor? no
Could not find any AV/C devices on the 1394 bus.

Before the dvcont test, the relevant dmesg output was as follows:

ohci1394: $Rev: 1223 $ Ben Collins <bco...@de...>
PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
ACPI: PCI interrupt 0000:03:00.0[A] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:03:00.0 to 64
ohci1394: fw-host0: Unexpected PCI resource length of 1000!
uhci_hcd 0000:00:1d.1: suspend_hc
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[11]  MMIO=[10800000-108007ff]  Max Packet=[2048]
uhci_hcd 0000:00:1d.2: suspend_hc
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00004c020000002d]

After turning on the camera, the following was logged:

ieee1394: Error parsing configrom for node 0-00:1023
ieee1394: Error parsing configrom for node 0-01:1023
ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
ieee1394: Node added: ID:BUS[0-00:1023]  GUID[0080880000f134e6]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
ieee1394: raw1394: /dev/raw1394 device initialized
atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.

Nothing further was printed when dvcont was hanging.  After I turned off the
camera, the following was printed:

isa0060/serio0 reports too many keys pressed.
ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[0080880000f134e6]
atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.

Do you need the lspci output, or is there anything else I could do to help
debug this, such as adding some debugging output to the 2.6.11.1 kernel?

This Intel Centrino based system has an Intel 82855PM chipset, Texas
Instruments PCI4520 Cardbus controller and NEC Corporation IEEE 1394 Host
Controller (rev 01).  AV/C has worked fine under 2.4 kernels using the
same hardware.

	Marko

Re: [libdv-dev] Spam...

[Charles \Buck\ K. <kr...@cs...>]

The list was configured to allow posts by non-members.   I didn't notice 
the spam problem, because (like many others I suppose), I run spam 
filters that grouped it with all the other spam.

I've changed the list policy to only allow postings from members from 
now on.

-- Buck

Dan Dennedy wrote:

>Yes, the spam is true. I am a SF project admin, but not the creator of
>the mailing lists and therefore do not have the separate mailman admin
>password. I have forwarded the issue to Buck, and hopefully he will
>respond soon. If not, there is a function to reset the password, and
>then I can take care of it.
>
>On Sat, 2005-03-12 at 16:28 -1000, Warren Togami wrote:
>  
>
>>You aren't seeing messages like the attached?  The mail headers indicate 
>>they went through the libdv-dev list.
>>
>>Warren Togami
>>wt...@re...
>>
>>Christopher Alexander Stein wrote:
>> > Hi Warren, I haven't been having a spam problem with the
>> > libdv-dev list and I don't even spam filter. have you tried
>> > procmail filtering spam or using ask?
>> >
>> > Lex
>> >
>> > On Sat, 12 Mar 2005, Warren Togami wrote:
>> >
>> >
>> >>Please deal with the spam, or it will be difficult for me to remain
>> >>subscribed.  Is the list allowing non-subscribed member posting?
>> >>
>> >>Warren Togami
>> >>wt...@re...
>> >>
>>email message attachment ([libdv-dev] Re: (QXS/18]-Pharrmmacy)
>>On Sat, 2005-03-12 at 16:28 -1000, Warren Togami wrote:
>>    
>>
>>> 
>>>Hello, Just Vissit Our Phaarmaccy-By-Mail SHOP and save up to 80%.
>>> 
>>>Va
>>>
>>>um Vi
>>>
>>>ra Ci
>>>
>>>is Am
>>>
>>>en,
>>> And man
>>>
>>>li
>>>ag
>>>al
>>>bi
>>>y other!
>>> 
>>>P.S. You will be pleasantly surprised with our prrices ;)
>>> 
>>>Have a good day!
>>>      
>>>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>libdv-dev mailing list
>lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libdv-dev
>  
>

Re: [libdv-dev] Spam...

[Dan D. <da...@de...>]

Yes, the spam is true. I am a SF project admin, but not the creator of
the mailing lists and therefore do not have the separate mailman admin
password. I have forwarded the issue to Buck, and hopefully he will
respond soon. If not, there is a function to reset the password, and
then I can take care of it.

On Sat, 2005-03-12 at 16:28 -1000, Warren Togami wrote:
> You aren't seeing messages like the attached?  The mail headers indicate 
> they went through the libdv-dev list.
> 
> Warren Togami
> wt...@re...
> 
> Christopher Alexander Stein wrote:
>  > Hi Warren, I haven't been having a spam problem with the
>  > libdv-dev list and I don't even spam filter. have you tried
>  > procmail filtering spam or using ask?
>  >
>  > Lex
>  >
>  > On Sat, 12 Mar 2005, Warren Togami wrote:
>  >
>  >
>  >>Please deal with the spam, or it will be difficult for me to remain
>  >>subscribed.  Is the list allowing non-subscribed member posting?
>  >>
>  >>Warren Togami
>  >>wt...@re...
>  >>
> email message attachment ([libdv-dev] Re: (QXS/18]-Pharrmmacy)
> On Sat, 2005-03-12 at 16:28 -1000, Warren Togami wrote:
> >  
> > Hello, Just Vissit Our Phaarmaccy-By-Mail SHOP and save up to 80%.
> >  
> > Va
> > 
> > um Vi
> > 
> > ra Ci
> > 
> > is Am
> > 
> > en,
> >  And man
> > 
> > li
> > ag
> > al
> > bi
> > y other!
> >  
> > P.S. You will be pleasantly surprised with our prrices ;)
> >  
> > Have a good day!

Re: [libdv-dev] Spam...

[Warren T. <wt...@re...>]

You aren't seeing messages like the attached?  The mail headers indicate 
they went through the libdv-dev list.

Warren Togami
wt...@re...

Christopher Alexander Stein wrote:
 > Hi Warren, I haven't been having a spam problem with the
 > libdv-dev list and I don't even spam filter. have you tried
 > procmail filtering spam or using ask?
 >
 > Lex
 >
 > On Sat, 12 Mar 2005, Warren Togami wrote:
 >
 >
 >>Please deal with the spam, or it will be difficult for me to remain
 >>subscribed.  Is the list allowing non-subscribed member posting?
 >>
 >>Warren Togami
 >>wt...@re...
 >>

[libdv-dev] Spam...

[Warren T. <wt...@re...>]

Please deal with the spam, or it will be difficult for me to remain 
subscribed.  Is the list allowing non-subscribed member posting?

Warren Togami
wt...@re...

[libdv-dev] Re: (QXS/18]-Pharrmmacy

[Maja L. <Bre...@jt...>]

Hello, 

Baynes, the master, of the homestead, grave of countenance and
for her words revealed the fact that of all that he had said the
He bowed to them, and turned to depart again, but mademoiselle
precaution against those released prisoners was to order them int
To Levasseur's relief, Captain Blood not only agreed, but pronoun
would have dared to take so much upon themselves?
my men.
boom of cannon.  Not until four o'clock, when the sun was rising 
men, and his judgment of Levasseur filled him with misgivings whi
The Colonel's eyes bulged in his head.  What the devil do you me

Have a good day.

Re: [libdv-dev] Image Processing using Firewire

[Dan D. <da...@de...>]

First, it is not a good idea to decode inside the libraw1394 receive
handler. You want to return this memory to the DMA engine of the OHCI
controller as soon as possible. Secondly, the only way I have ever used
libdv is by supplying it all of the DV for a frame at one time. For
NTSC, 250 DV blocks are supplied per frame and 300 for PAL with each
block being 480 bytes. If you look at the value of the length parameter
in the receive handler you should see that it is 496 when it is not 16.
So, you can not just copy 120000 or 144000 bytes out the data pointer.
Also make sure the first packet in the dv buffer is the first block of
the frame. See dvconnect or playdv source code for how to detect the
beginning of frame.

On Thu, 2005-03-10 at 13:38 -0800, Juan Cantonez wrote:
> Hi,
> 
> I have a Sony VX2000 DV camera which supports firewire
> connection. What I would like to do is capture frames
> continuously from the firewire and save those frames
> to my hard disk for image processing. After some
> research, I found that to capture the raw DV data
> libraw1394 library in linux has to be used and to
> decode the data libdv should be used. I wrote a small
> code for this purpose, however I am getting weird,
> random colored images. I also looked at the examples
> that come from libdv source files; however no luck at
> all. Can somebody please look at my code and tell me
> what I am doing wrong? I got stuck on this and I can't
> start my research area. Thanks a lot for your
> responses in advance. Here is my code: 
> 
> #define BUFFER 1000
> #define PACKET_MAX 4096
> 
> #include <iostream>
> #include
> "/home/elgitaro/libraw1394-1.1.0/src/raw1394.h"
> #include <libdv/dv.h>
> using namespace std;
> u_int64_t listen_channels;
> raw1394handle_t handle;
> int num_of_cards;
> struct raw1394_portinfo pinf[ 16 ];
> quadlet_t buffer;
> dv_decoder_t *mydecoder;
> raw1394_iso_dma_recv_mode mode;	
> int pitches[3];
> unsigned char *pixels[1];
> char filename[1024];
> void saveasppm(unsigned char**,dv_decoder_t);
> unsigned char dv_buffer[144000];
> unsigned char video_buffer[720 * 576 * 3];
> int *isPAL = FALSE;
> 
> 
> static enum raw1394_iso_disposition 
> iso_handler(raw1394handle_t handle, unsigned char
> *data, 
>         unsigned int length, unsigned char channel,
>         unsigned char tag, unsigned char sy, unsigned
> int cycle, 
>         unsigned int dropped)
> {
> 	if ( length > 16 )
> 	{
> 		memcpy(dv_buffer,data,120000);
> 		unsigned char * p = ( unsigned char* ) & data[ 3 ];
>         if (p[ 3 ] & 0x80) { //Check if the signal is
> PAL
> 				cout << "Pal" << endl;
> 				mydecoder->clamp_luma = FALSE;
> 				mydecoder->clamp_chroma = FALSE;
> 				dv_reconfigure(FALSE, FALSE);
>                 memcpy(dv_buffer + 120000, data,
> 144000 - 120000);
> 		}
> 		if((dv_parse_header(mydecoder, dv_buffer)) < 0){
>       	cout << "dv_parse_header failed" << endl;
> 		return RAW1394_ISO_OK;	
>     }
> 		else
> 			cout << "Parse Header successful" << endl; 
> 	
> 	pitches[0] = 720 * 3; //mydecoder->width * 3;
> 	//dv_parse_packs (mydecoder, dv_buffer);
>     dv_decode_full_frame(mydecoder,
> 			 dv_buffer,
> 			 e_dv_color_rgb, /* RGB */
> 			 pixels,
> 			 pitches);
> 	FILE *fp;
> 	sprintf(filename, "outbuf.ppm");
>     fp = fopen(filename, "wb");
>     if(fp != NULL)
> 		{
>       fprintf(fp, "P6\n%d
> %d\n255\n",mydecoder->width,mydecoder->height);
>       fwrite(pixels[0], 1,
> 3*mydecoder->width*mydecoder->height, fp);
>       fclose(fp);	
> 		}
> 	 }	
> 	return RAW1394_ISO_OK;
> }
> 
> int main()
> {
> 	pixels[0] = video_buffer;
> 	handle = raw1394_new_handle();
> 	if (handle==0)
> 		cout << "No handle has been created" << endl;
> 	else
> 		cout << "Handle is: " << handle << endl;
> 	//num_of_cards = raw1394_get_port_info( handle, pinf,
> 16 );
> 	//cout << "Number of ports: " << num_of_cards <<
> endl;
> 	//cout << "Port info: " << pinf[0].name << " . " <<
> pinf[0].nodes << endl;
> 		if (raw1394_set_port(handle, 0) < 0) 
> 			{
> 				cout << "Couldn't set port";
> 				exit(1);
> 		}
> 	mode = RAW1394_DMA_DEFAULT;
> 		
> 	raw1394_iso_multichannel_recv_init(handle,
> iso_handler,
>                         BUFFER, 2048, -1);
> 		listen_channels = ~0ULL;
> 		raw1394_iso_recv_set_channel_mask(handle,
> listen_channels);
> 		
> 	
> 	 
> 	/* create dv decoder */
> 	cout << "creating the dv decoder" << endl; 
>   	mydecoder = dv_decoder_new(FALSE, FALSE, FALSE);
> 	if(mydecoder == NULL)
>     	cout << "dv_decoder_new failed" << endl;
> 	mydecoder->video->arg_monochrome = 0; /* color frames
> */
>   	mydecoder->quality = 
>     mydecoder->video->quality = DV_QUALITY_BEST; /*
> color and fine scale */
> 
> 
> 
> 	
> 	if(raw1394_iso_recv_start(handle, -1, -1, 0)==0)
> 		cout << "iso_recv_start success" << endl;
>     //while (raw1394_loop_iterate(handle) == 0);
> 	//for (int i=0; i<5; i++)
> 	raw1394_loop_iterate(handle);
> 	
> 	
> 	dv_decoder_free(mydecoder);
> 	raw1394_iso_shutdown(handle);
> 	exit(1);		
> }
> 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/ 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] Image Processing using Firewire

[Juan C. <elg...@ya...>]

Hi,

I have a Sony VX2000 DV camera which supports firewire
connection. What I would like to do is capture frames
continuously from the firewire and save those frames
to my hard disk for image processing. After some
research, I found that to capture the raw DV data
libraw1394 library in linux has to be used and to
decode the data libdv should be used. I wrote a small
code for this purpose, however I am getting weird,
random colored images. I also looked at the examples
that come from libdv source files; however no luck at
all. Can somebody please look at my code and tell me
what I am doing wrong? I got stuck on this and I can't
start my research area. Thanks a lot for your
responses in advance. Here is my code: 

#define BUFFER 1000
#define PACKET_MAX 4096

#include <iostream>
#include
"/home/elgitaro/libraw1394-1.1.0/src/raw1394.h"
#include <libdv/dv.h>
using namespace std;
u_int64_t listen_channels;
raw1394handle_t handle;
int num_of_cards;
struct raw1394_portinfo pinf[ 16 ];
quadlet_t buffer;
dv_decoder_t *mydecoder;
raw1394_iso_dma_recv_mode mode;	
int pitches[3];
unsigned char *pixels[1];
char filename[1024];
void saveasppm(unsigned char**,dv_decoder_t);
unsigned char dv_buffer[144000];
unsigned char video_buffer[720 * 576 * 3];
int *isPAL = FALSE;


static enum raw1394_iso_disposition 
iso_handler(raw1394handle_t handle, unsigned char
*data, 
        unsigned int length, unsigned char channel,
        unsigned char tag, unsigned char sy, unsigned
int cycle, 
        unsigned int dropped)
{
	if ( length > 16 )
	{
		memcpy(dv_buffer,data,120000);
		unsigned char * p = ( unsigned char* ) & data[ 3 ];
        if (p[ 3 ] & 0x80) { //Check if the signal is
PAL
				cout << "Pal" << endl;
				mydecoder->clamp_luma = FALSE;
				mydecoder->clamp_chroma = FALSE;
				dv_reconfigure(FALSE, FALSE);
                memcpy(dv_buffer + 120000, data,
144000 - 120000);
		}
		if((dv_parse_header(mydecoder, dv_buffer)) < 0){
      	cout << "dv_parse_header failed" << endl;
		return RAW1394_ISO_OK;	
    }
		else
			cout << "Parse Header successful" << endl; 
	
	pitches[0] = 720 * 3; //mydecoder->width * 3;
	//dv_parse_packs (mydecoder, dv_buffer);
    dv_decode_full_frame(mydecoder,
			 dv_buffer,
			 e_dv_color_rgb, /* RGB */
			 pixels,
			 pitches);
	FILE *fp;
	sprintf(filename, "outbuf.ppm");
    fp = fopen(filename, "wb");
    if(fp != NULL)
		{
      fprintf(fp, "P6\n%d
%d\n255\n",mydecoder->width,mydecoder->height);
      fwrite(pixels[0], 1,
3*mydecoder->width*mydecoder->height, fp);
      fclose(fp);	
		}
	 }	
	return RAW1394_ISO_OK;
}

int main()
{
	pixels[0] = video_buffer;
	handle = raw1394_new_handle();
	if (handle==0)
		cout << "No handle has been created" << endl;
	else
		cout << "Handle is: " << handle << endl;
	//num_of_cards = raw1394_get_port_info( handle, pinf,
16 );
	//cout << "Number of ports: " << num_of_cards <<
endl;
	//cout << "Port info: " << pinf[0].name << " . " <<
pinf[0].nodes << endl;
		if (raw1394_set_port(handle, 0) < 0) 
			{
				cout << "Couldn't set port";
				exit(1);
		}
	mode = RAW1394_DMA_DEFAULT;
		
	raw1394_iso_multichannel_recv_init(handle,
iso_handler,
                        BUFFER, 2048, -1);
		listen_channels = ~0ULL;
		raw1394_iso_recv_set_channel_mask(handle,
listen_channels);
		
	
	 
	/* create dv decoder */
	cout << "creating the dv decoder" << endl; 
  	mydecoder = dv_decoder_new(FALSE, FALSE, FALSE);
	if(mydecoder == NULL)
    	cout << "dv_decoder_new failed" << endl;
	mydecoder->video->arg_monochrome = 0; /* color frames
*/
  	mydecoder->quality = 
    mydecoder->video->quality = DV_QUALITY_BEST; /*
color and fine scale */



	
	if(raw1394_iso_recv_start(handle, -1, -1, 0)==0)
		cout << "iso_recv_start success" << endl;
    //while (raw1394_loop_iterate(handle) == 0);
	//for (int i=0; i<5; i++)
	raw1394_loop_iterate(handle);
	
	
	dv_decoder_free(mydecoder);
	raw1394_iso_shutdown(handle);
	exit(1);		
}



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: [libdv-dev] Continuous "audio block/sample failure" with JVC DV camera

[Dan D. <da...@de...>]

Right now, module removal of ieee1394 modules under kernel 2.6 is known
to be problematic. None of the kernel messages shown are alarming
except, of course, the Oops on card eject. None of the messages relate
to AV/C deadlocking Kino. Can you test if transport control in dvcont or
gscanbus works OK?

On Thu, 2005-03-10 at 00:45 +0200, Marko M=E4kel=E4 wrote:
> On Thu, Dec 02, 2004 at 12:07:47PM +0200, Marko M=E4kel=E4 wrote:
> > On Thu, Dec 02, 2004 at 01:04:51AM -0500, Nathan Kidd wrote:
> > > Marko M=E4kel=E4 wrote:
> > > >I have a JVC GR-DVL9600 (PAL), and audio has worked for me, except=
 for some
> > > >occasional glitches, probably due to errors on the tape.  I've bee=
n using
> > > >libdv with the 2.4 kernel since 2.4.21 or so.
> > >=20
> > > My motherboard only is supported by 2.6, so I unfortunately can't t=
ry=20
> > > 2.4.  But it's good to know it's not a universal JVC thing.  Maybe =
it's=20
> > > just my model. That would figure. :)
> >=20
> > Well, the GR-DVL9600 is pretty old, apparently from early 2000.  It e=
ven
> > features a JLIP connector (RS-232) for importing still pictures.  It =
was
> > a display model that I bought around March 2003.
> >=20
> > When I last tried the 2.6 kernel in Debian GNU/Linux unstable, I got =
some
> > trouble with the loading of modules.  Maybe the support has been impr=
oved
> > by now.  I could give it a try within the next week.  My IEEE-1394 in=
terface
> > is a cheap PCI card based on VIA 6306, if I remember correctly.
>=20
> I'm sorry for the delay, but I didn't get around to this immediately, a=
nd
> I also had to do some surgery to the camera after it dropped about 1 me=
ter
> to the ground.  Only the case was damaged, but I had to disassemble the=
 whole
> camera in order to fix the strap holder that broke off.  While doing th=
at,
> I of course had to break the locking mechanism of one tiny 51-pin conne=
ctor
> inside the camera.
>=20
> I just tested Kino with kernel 2.6.11.1 on a OHCI1394 compliant PCMCIA
> Firewire adapter that has worked with kernel 2.4.x.  When I plug it in,
> I get this:
>=20
> ohci1394: $Rev: 1223 $ Ben Collins <bco...@de...>
> PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
> ACPI: PCI interrupt 0000:03:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> ohci1394: fw-host0: Unexpected PCI resource length of 1000!
> ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=3D[11]  MMIO=3D[10800000-1=
08007ff]  Max Packet=3D[2048]
> uhci_hcd 0000:00:1d.0: suspend_hc
> uhci_hcd 0000:00:1d.1: suspend_hc
> uhci_hcd 0000:00:1d.2: suspend_hc
> ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00004c020000002d]
>=20
> Capture in Kino apparently works, but pressing the AV/C button (which w=
orked
> with kernel 2.4.x) hangs the whole Kino process and makes it unkillable=
 until
> I turn the camera off.
>=20
> "cardctl eject" makes the kernel try dereferencing a NULL pointer.  Tha=
t
> was also the case for 2.6.10, but I didn't even try Kino there.  Here a=
re
> the rest of the dmesg entries related to firewire.  I guess that the fi=
rst
> few entries are related to turning the camera on and trying the AV/C co=
ntrols
> in Kino.
>=20
> ieee1394: Error parsing configrom for node 0-00:1023
> ieee1394: Error parsing configrom for node 0-01:1023
> ieee1394: The root node is not cycle master capable; selecting a new ro=
ot node and resetting...
> ieee1394: Node added: ID:BUS[0-00:1023]  GUID[0080880000f134e6]
> ieee1394: Node changed: 0-00:1023 -> 0-01:1023
> ieee1394: raw1394: /dev/raw1394 device initialized
> ohci1394: fw-host0: AT dma reset ctx=3D0, aborting transmission
> ieee1394: Node changed: 0-01:1023 -> 0-00:1023
> ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[0080880000f134e6]
> ieee1394: Node removed: ID:BUS[0-00:1023]  GUID[00004c020000002d]
> ieee1394: Node removed: ID:BUS[0-00:1023]  GUID[0080880000f134e6]
> Unable to handle kernel NULL pointer dereference at virtual address 000=
00000
>  printing eip:
> d0a03bdb
> *pde =3D 00000000
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: raw1394 dv1394 joydev evdev ohci1394 ieee1394 ehci_h=
cd uhci_hcd rtc parport_pc parport
> CPU:    0
> EIP:    0060:[<d0a03bdb>]    Not tainted VLI
> EFLAGS: 00010296   (2.6.11.1)
> EIP is at dv1394_remove_host+0x1b/0xe0 [dv1394]
> eax: d092b688   ebx: 00000000   ecx: 00000000   edx: d0a03bc0
> esi: 00000000   edi: d0a0459d   ebp: cf231e84   esp: ce9c7e6c
> ds: 007b   es: 007b   ss: 0068
> Process cardctl (pid: 3459, threadinfo=3Dce9c7000 task=3Dcb9ee550)
> Stack: cf6698d4 d0a06040 cf230000 cf230000 cf231e84 d0915331 00000000 c=
f231e84
>        d0914df0 00000000 d0a06040 d0a06040 cf230000 d092b6bc cf231e84 d=
0915d7b
>        cf230000 c1377044 d08de4c8 d0914c98 c1377000 d08da3a3 c0316aca c=
f231d2c
> Call Trace:
>  [<d0915331>] __unregister_host+0xd1/0xe0 [ieee1394]
>  [<d0914df0>] hl_get_hostinfo+0x70/0x90 [ieee1394]
>  [<d0915d7b>] highlevel_remove_host+0x3b/0x70 [ieee1394]
>  [<d0914c98>] hpsb_remove_host+0x38/0x60 [ieee1394]
>  [<d08da3a3>] ohci1394_pci_remove+0x53/0x210 [ohci1394]
>  [<c01b6548>] pci_device_remove+0x28/0x30
>  [<c021a7a4>] device_release_driver+0x74/0x80
>  [<c021a9e4>] bus_remove_device+0x54/0x90
>  [<c02198ca>] device_del+0x5a/0xa0
>  [<c0219918>] device_unregister+0x8/0x10
>  [<c01b42f7>] pci_destroy_dev+0x17/0x90
>  [<c01b4478>] pci_remove_behind_bridge+0x28/0x40
>  [<c0251428>] shutdown_socket+0x58/0xa0
>  [<c01228af>] msleep+0x2f/0x40
>  [<c02515bb>] socket_shutdown+0x1b/0x30
>  [<c0251a98>] socket_remove+0x8/0x70
>  [<c0253652>] pcmcia_eject_card+0x62/0x70
>  [<c0257a64>] ds_ioctl+0x224/0x590
>  [<c01638ca>] do_ioctl+0x6a/0x90
>  [<c0163afe>] vfs_ioctl+0x5e/0x1d0
>  [<c0163cad>] sys_ioctl+0x3d/0x70
>  [<c010306f>] syscall_call+0x7/0xb
> Code: 3c 92 73 ef 8b 5c 24 38 83 c4 3c c3 8d 74 26 00 55 57 bf 9d 45 a0=
 d0 56 53 83 ec 04 8b 98 28 1d 00 00 8b 80 20 1d 00 00 8b 70 04 <ac> ae 7=
5 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 0f 85 7e
>=20
> Please let me know if you would like to have further tests.  If I remem=
ber
> correctly, I got that "cardctl eject" failure with 2.6.10 even without
> plugging in the camera.
>=20
> Best regards,
>=20
> 	Marko
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev