Quasar DV Codec

For me, the easiest way for me to see the problem is to reduce image
size to 50% (to isolate one of the fields). Then, above the yellow spot
in the center of the image, I do see very noticable red lines in the
libdv picture but not in the Panasonic.

Very interesting.

On Sat, 2003-11-01 at 13:19, Nicola Fankhauser wrote:
> Hello all
> 
> I am trying to transcode interlaced PAL DV footage. Most scenes have a
> lot of movement and thus interlaced lines are visible most of the time.
> 
> However, when decoding DV files, libdv messes up the order of lines in
> the frame - instead of one line from field #1, then one line from field
> #2 there are two lines of field #1, then two lines of field #2.
> 
> Additionally, the problem seems to be most visible where red areas from
> field #1 (resp. #2) and green areas from field #2 (resp. #1) mix because
> of movement.
> 
> I need to say that I am no video expert and this analysis may be
> completely wrong - still, the issue exists... :)
> 
> I put the same frame in two versions on a webserver to show the issue:
> 
> * one decoded with libdv 0.99 (CVS gives the same), showing artifacts: 
> http://q.nts.ch/~fankhaun/frame_libdv.jpg
> 
> * one decoded with Panasonic DV codec on Win32, showing no artifacts: 
> http://q.nts.ch/~fankhaun/frame_panasonic.jpg
> 
> I hope somebody can shed some light on this issue...
> 
> thanks & regards
> nicola
> 
> PS: Did I mention that libdv is a useful and great piece of software?
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> libdv-dev mailing list
> libdv-dev@...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

On Saturday 01 November 2003 21:50, Dan Dennedy wrote:
> For me, the easiest way for me to see the problem is to reduce image
> size to 50% (to isolate one of the fields). Then, above the yellow spot
> in the center of the image, I do see very noticable red lines in the
> libdv picture but not in the Panasonic.
> 
> Very interesting.

Yes, but keep in mind that PAL DV color encoding is 420. By that, every
second line has NO color information. Libdv does NOT interpolate missing
colorinformation.
A hardware displayer (Camcorder or DVD player) may display only one
field for still pictures recorded in interlaced format, so interlaced
effects may not be visible.

So I don't know if I shall name this an error or just less sophisticated

> 
> On Sat, 2003-11-01 at 13:19, Nicola Fankhauser wrote:

[..]

> > Additionally, the problem seems to be most visible where red areas from
> > field #1 (resp. #2) and green areas from field #2 (resp. #1) mix because
> > of movement.
> > 
> > I need to say that I am no video expert and this analysis may be
> > completely wrong - still, the issue exists... :)

-- 
--------

Stefan Lucke

On Sun, 2003-11-02 at 02:02, Stefan Lucke wrote:
> On Saturday 01 November 2003 21:50, Dan Dennedy wrote:
> > For me, the easiest way for me to see the problem is to reduce image
> > size to 50% (to isolate one of the fields). Then, above the yellow spot
> > in the center of the image, I do see very noticable red lines in the
> > libdv picture but not in the Panasonic.
> > 
> > Very interesting.
> 
> Yes, but keep in mind that PAL DV color encoding is 420. By that, every
> second line has NO color information. Libdv does NOT interpolate missing
> colorinformation.

Correct, but in this case, I do not see a lack of color information,
seems more like wrong information--information from the wrong scanline.

> A hardware displayer (Camcorder or DVD player) may display only one
> field for still pictures recorded in interlaced format, so interlaced
> effects may not be visible.

I do not understand the relevance of this comment. The Panasonic sample
is from a software DV codec. By reducing 50% through halving the number
of lines (no interpolation), interlace effects should not be visible,
but in the libdv picture they are.

> So I don't know if I shall name this an error or just less sophisticated
> 
> > 
> > On Sat, 2003-11-01 at 13:19, Nicola Fankhauser wrote:
> 
> [..]
> 
> > > Additionally, the problem seems to be most visible where red areas from
> > > field #1 (resp. #2) and green areas from field #2 (resp. #1) mix because
> > > of movement.
> > > 
> > > I need to say that I am no video expert and this analysis may be
> > > completely wrong - still, the issue exists... :)

hi stefan

On Sun, 2003-11-02 at 08:02, Stefan Lucke wrote:
> Yes, but keep in mind that PAL DV color encoding is 420. By that, every
> second line has NO color information. Libdv does NOT interpolate missing
> colorinformation.

Then how comes that non-interlaced areas seem not to suffer from this
problem?

There must be already some interpolation be done in libdv, because you
can't transform a 4:2:0 encoded frame to RGB space without color
interpolation - you would see that every other line misses either the Cr
or Cb value.

It just seems that libdv doesn't do it right for 4:2:0 encoded frames -
I don't know how libdv performs on NTSC DV material, which supposedly is
4:1:1 encoded.

> A hardware displayer (Camcorder or DVD player) may display only one
> field for still pictures recorded in interlaced format, so interlaced
> effects may not be visible.

What do have hardware still pictures you mention to do with this issue?
The Panasonic picture I put on the net comes from the Panasonic
_software_ codec for win23.

regards
nicola

On Sunday 02 November 2003 15:58, Nicola Fankhauser wrote:
> hi stefan
> 
> On Sun, 2003-11-02 at 08:02, Stefan Lucke wrote:
> > Yes, but keep in mind that PAL DV color encoding is 420. By that, every
> > second line has NO color information. Libdv does NOT interpolate missing
> > colorinformation.
> 
> Then how comes that non-interlaced areas seem not to suffer from this
> problem?
> 
> There must be already some interpolation be done in libdv, because you
> can't transform a 4:2:0 encoded frame to RGB space without color
> interpolation - you would see that every other line misses either the Cr
> or Cb value.

Color values are just repeated (used for two lines). There is more than one
PAL DV format (consumer DV: 420, DVCam or DVpro: 411). So what type is the
camera ? 
I've never seen a sample which is recored in those professional DV formats.
Perhaps yours is such 411 PAL DV. Could you upload this single frame in
plain dv format (*.dv) ?

-- 
--------

Stefan Lucke

On Sun, 2003-11-02 at 15:40, Dan Dennedy wrote:
> Correct, but in this case, I do not see a lack of color information,
> seems more like wrong information--information from the wrong scanline.

Right, I hacked libdv a bit so that it gave me first chroma only
pictures - they are all georgeous and perfect.

Then I squeezed out one Cr and one Cb picture - they have very strange
2px wide bands, as if the order of the chroma channels' lines was
interleaved (example for Cr, but the same applies for Cb):
line #1: dark red
line #2: dark red
line #3: bright red
line #4: bright red

whereas the L channel was (like already said) like it should be, when
looking at interlaced frames:
line #1: dark
line #2: bright
line #3: dark
line #4: bright

so, the accompanying pictures:
http://q.nts.ch/~fankhaun/still_luma.jpg
http://q.nts.ch/~fankhaun/still_red.jpg
http://q.nts.ch/~fankhaun/still_blue.jpg

regards
nicola

On Sun, 2003-11-02 at 15:16, Stefan Lucke wrote:
> > On Sun, 2003-11-02 at 08:02, Stefan Lucke wrote:
> > > Yes, but keep in mind that PAL DV color encoding is 420. By that, every
> > > second line has NO color information. Libdv does NOT interpolate missing
> > > colorinformation.
> 
> Color values are just repeated (used for two lines).

Then, perhaps the DV chroma subsampling is field-based and libdv is
treating it frame-based.

Dan Dennedy wrote:
> Then, perhaps the DV chroma subsampling is field-based and libdv is
> treating it frame-based.
Actually, I'm embarrassed to say we've known about this for a long time, 
but never quite got around to mailing the list about it.  A student 
(Karl Sharman) at the University here found it and fixed it.  I believe 
the error was indeed due to libdv applying the chroma across two lines 
from separate fields.  You can find a sample PAL DV file and several 
pictures highlighting the problem at:
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/

The important one is 
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/libdv-0.9_codec-cropped-zoomed.png 
where it is clear that the orange of the ball is being incorrectly used 
on the white of the background.  Compare with 
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/fixedlibdv-0.9_codec-cropped-zoomed.png 
which is our fixed version.  There's also some pictures from Sony and 
Pinnacle codecs for comparison.

If you wish to use it, his change description is at 
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/kjschanges_v0.9.txt 
but I believe they do things in a different fashion to the original.  It 
also changes several other parts of libdv that may be worth examining 
(I've not looked at it in detail, or I'd probably have actually managed 
to mail the list about it..).

I can also make a diff of our current source tree if that would be 
helpful (it has some bits to make a Win32 port easier and some Python 
interfacing).

Mike Grant.

On Mon, 2003-11-03 at 17:58, Mike Grant wrote:
> Dan Dennedy wrote:
> > Then, perhaps the DV chroma subsampling is field-based and libdv is
> > treating it frame-based.
> Actually, I'm embarrassed to say we've known about this for a long time, 
> but never quite got around to mailing the list about it.  A student 

I am very glad to see that I'm not the first one experiencing this
problem. I know, giving back to the community gets forgotten once
problems are solved. but then again, it's almost precisely one year
since you discovered the issue...

> I can also make a diff of our current source tree if that would be 
> helpful (it has some bits to make a Win32 port easier and some Python 
> interfacing).

If it ends up as a codec I can use on my box - then it's alright with
me. :)

regards
nicola

Nicola Fankhauser wrote:
> On Mon, 2003-11-03 at 17:58, Mike Grant wrote:
>>I can also make a diff of our current source tree if that would be 
>>helpful (it has some bits to make a Win32 port easier and some Python 
>>interfacing).
> If it ends up as a codec I can use on my box - then it's alright with
> me. :)
Most of the win32 port changes are about removing glib references, which 
I think has been done already (we still use 0.9).  There are a few 
interesting things (partly to do with FPU precision being different for 
some calculations on Windows and Linux).

The python changes mainly just give output in a different form more 
suitable for interfacing to the Python Imaging Library.

Using the jpeg DCT might be worth considering though (it's in Karl's 
changes file linked in the previous mail) - I think it came out faster.

I'll wait for Dan to say if he's interested in a diff before I do it (I 
probably should update to the latest libdv before doing that).

Anyway, getting a bit off topic now ;)

Regards,

Mike Grant.

On Mon, 2003-11-03 at 11:58, Mike Grant wrote:
> Dan Dennedy wrote:
> > Then, perhaps the DV chroma subsampling is field-based and libdv is
> > treating it frame-based.
> Actually, I'm embarrassed to say we've known about this for a long time, 
> but never quite got around to mailing the list about it.  A student 

Well, now, I am just glad you happened to still be on the list and read
about the the problem to be able to comment!

> If you wish to use it, his change description is at 
> http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/kjschanges_v0.9.txt
> but I believe they do things in a different fashion to the original.  It 

Yes, it is quite different, but I think Stefan or I will be able to
figure out a solution.

> I can also make a diff of our current source tree if that would be 
> helpful (it has some bits to make a Win32 port easier and some Python 
> interfacing).

I would appreciate it esp. if you can pinpoint a date or release version
your cvs was based upon.

Thanks, Mike

On Tuesday 04 November 2003 05:01, Dan Dennedy wrote:
> On Mon, 2003-11-03 at 11:58, Mike Grant wrote:
> > Dan Dennedy wrote:
> > > Then, perhaps the DV chroma subsampling is field-based and libdv is
> > > treating it frame-based.
> > Actually, I'm embarrassed to say we've known about this for a long time, 
> > but never quite got around to mailing the list about it.  A student 
> 
> Well, now, I am just glad you happened to still be on the list and read
> about the the problem to be able to comment!
> 
> > If you wish to use it, his change description is at 
> > http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/kjschanges_v0.9.txt
> > but I believe they do things in a different fashion to the original.  It 
> 
> Yes, it is quite different, but I think Stefan or I will be able to
> figure out a solution.

Color change should be done first.

From looking at the different samples provided by Mike, I would say
the pinnacle codec has the same problem as libdv.

I changed the YUY2 C implementation first.

The changes are commited in a separate branch which includes
my other changes as well. Branch name is "dv_stefan_lucke" .

So the renderer format is runtime selectable including PAL YV12.
For testing different render functions thats easier.
Render functions a selectable via playdv option --renderer=xxxx .
The fixed version is available via --renderer=YUY2_palfix .
Available names are:
	YUY2, YUY2_palfix, YUY2_mmx, YUY2_mmx_hh, YV12, YV12_mmx, RGB24

For frame by frame execution I added option --step.

Since this version breaks other applications, I strongly recomment
NOT to INSTALL.

For testing you'll need to

cvs -d :pserver:anonymous@... co -r dv_stefan_lucke libdv
cvs -d :ext:DEVELOPER_NAME@... co -r dv_stefan_lucke libdv

or

The future of this branch should be discussed later.

> 
> > I can also make a diff of our current source tree if that would be 
> > helpful (it has some bits to make a Win32 port easier and some Python 
> > interfacing).
> 
> I would appreciate it esp. if you can pinpoint a date or release version
> your cvs was based upon.
> 
> Thanks, Mike
> 
> 
> 

-- 
--------

Stefan Lucke

On Wed, 2003-11-05 at 15:45, Stefan Lucke wrote:

> Color change should be done first.
[...]
> I changed the YUY2 C implementation first.

Please explain more... you are saying that the fix Mike Grant points to
is not ideal because the error lies at the YCbCr source as opposed to
the RGB conversion?

On Wednesday 05 November 2003 22:39, Dan Dennedy wrote:
> On Wed, 2003-11-05 at 15:45, Stefan Lucke wrote:
> 
> > Color change should be done first.
> [...]
> > I changed the YUY2 C implementation first.
> 
> Please explain more... you are saying that the fix Mike Grant points to
> is not ideal because the error lies at the YCbCr source as opposed to
> the RGB conversion?

The error is present in ALL our render functions. As you suspected
chroma information is field based if SONY codecs output is the correct one.
The code Mike presented processes chroma info in such a way.

To my opinion this is more reasonable. Frame based chroma means, the second
half frame has no chroma information at all ;-) .

So each color render function for PAL has to be modified.

We have to look at the encoding part too (later).

It would be interesting to read a comment form one with
IEC 61834 PAL specs.



-- 
--------

Stefan Lucke

On Wed, Nov 05, 2003 at 11:32:06PM +0100, Stefan Lucke wrote:
> On Wednesday 05 November 2003 22:39, Dan Dennedy wrote:
> > On Wed, 2003-11-05 at 15:45, Stefan Lucke wrote:
> > 
> > > Color change should be done first.
> > [...]
> > > I changed the YUY2 C implementation first.
> > 
> > Please explain more... you are saying that the fix Mike Grant points to
> > is not ideal because the error lies at the YCbCr source as opposed to
> > the RGB conversion?
> 
> The error is present in ALL our render functions. As you suspected
> chroma information is field based if SONY codecs output is the correct one.
> The code Mike presented processes chroma info in such a way.
> 
> To my opinion this is more reasonable. Frame based chroma means, the second
> half frame has no chroma information at all ;-) .
> 
> So each color render function for PAL has to be modified.
> 
> We have to look at the encoding part too (later).
> 
> It would be interesting to read a comment form one with
> IEC 61834 PAL specs.

  Here's what Adam Wilt says about this stuff:
  http://www.adamwilt.com/pix-sampling.html:

  "Co-sited 4:2:0 sampling is used in 625/50 ("PAL") DV and DVCAM formats. Cr and
   Cb samples are on alternate lines in each field (a frame view would show two lines of
   YCr,Y pairs, then two lines of YCb,Y pairs). Note that this is different from the 4:2:0
   chroma sample positioning in JPEG, MPEG, and H.261 formats!"


  It seems to make a lot of sense to me, and I guess that lidbv currently suffers 
  from doing it in a JPEG-like fashion, right ?

Thanks,
Roman.

P.S. ffmpeg's DV seems to be suffering from the same as well -- will be fixing it
pretty soon.

Stefan Lucke wrote:
> It would be interesting to read a comment form one with
> IEC 61834 PAL specs.
I have access to some of those, but they don't seem to be very specific 
about PAL DV (which is 4:2:0 afaik).  As far as the ones I have go, the 
best they describe is 4:2:2 as in the SMPTE specs.

The other interesting question would be how progressive scan (non 
interlaced) DV is handled in terms of the chroma split.  I don't think 
there's any way to tell from the DV file, so I presume it's the same as 
interlaced, despite the fields no longer being separated temporally?  If 
needed, I can produce some test PAL DV in interlaced and progressive scan.

Mike Grant.

On Thu, Nov 06, 2003 at 08:29:48PM +0000, Mike Grant wrote:
> Stefan Lucke wrote:
> >It would be interesting to read a comment form one with
> >IEC 61834 PAL specs.
> I have access to some of those, but they don't seem to be very specific 
> about PAL DV (which is 4:2:0 afaik).  As far as the ones I have go, the 
> best they describe is 4:2:2 as in the SMPTE specs.
> 
> The other interesting question would be how progressive scan (non 
> interlaced) DV is handled in terms of the chroma split.  I don't think 
> there's any way to tell from the DV file, so I presume it's the same as 
> interlaced, despite the fields no longer being separated temporally?  If 
> needed, I can produce some test PAL DV in interlaced and progressive scan.

  That'll be great -- please do.

Thanks,
Roman.

On Thursday 06 November 2003 21:29, Mike Grant wrote:
> Stefan Lucke wrote:
> > It would be interesting to read a comment form one with
> > IEC 61834 PAL specs.
> I have access to some of those, but they don't seem to be very specific 
> about PAL DV (which is 4:2:0 afaik).  As far as the ones I have go, the 
> best they describe is 4:2:2 as in the SMPTE specs.
> 
> The other interesting question would be how progressive scan (non 
> interlaced) DV is handled in terms of the chroma split.  I don't think 
> there's any way to tell from the DV file, so I presume it's the same as 
> interlaced, despite the fields no longer being separated temporally?  If 
> needed, I can produce some test PAL DV in interlaced and progressive scan.

Progressive scan is detectable via data. But in pond.dv it is in a different location
than SMPTE314 tells us (interlace flag). With my camera Sony PAL I can record
progressive only at 12.5Hz ;-(.

So a two frames progressive scan samples from an other cam would be interesting.
And please let us know the exact model name.

> 
> Mike Grant.
> 
> 

-- 
--------

Stefan Lucke

On Thursday 06 November 2003 20:56, Roman Shaposhnick wrote:
> On Wed, Nov 05, 2003 at 11:32:06PM +0100, Stefan Lucke wrote:
[..]
> > 
> > It would be interesting to read a comment form one with
> > IEC 61834 PAL specs.
> 
>   Here's what Adam Wilt says about this stuff:
>   http://www.adamwilt.com/pix-sampling.html:
> 
>   "Co-sited 4:2:0 sampling is used in 625/50 ("PAL") DV and DVCAM formats. Cr and
>    Cb samples are on alternate lines in each field (a frame view would show two lines of
>    YCr,Y pairs, then two lines of YCb,Y pairs). Note that this is different from the 4:2:0
>    chroma sample positioning in JPEG, MPEG, and H.261 formats!"

Thats the part I do not understand.

So libdv's original view was like: 
take line x of Cr and Cb and generate line x and x+1 of the frame.

now the other way is:
take line x of Cr and Cb and generate line x and x+2 of the frame.

I added for branch dv_stefan_lucke additional render functions
RGB24_palfix, YUY2_mmx_palfix and YUY2_mmx_hh_palfix .

Those with "hh" in their name produce HalfHeight output (only one field).

-- 
--------

Stefan Lucke

On Thu, Nov 06, 2003 at 10:18:18PM +0100, Stefan Lucke wrote:
> On Thursday 06 November 2003 20:56, Roman Shaposhnick wrote:
> > On Wed, Nov 05, 2003 at 11:32:06PM +0100, Stefan Lucke wrote:
> [..]
> > > 
> > > It would be interesting to read a comment form one with
> > > IEC 61834 PAL specs.
> > 
> >   Here's what Adam Wilt says about this stuff:
> >   http://www.adamwilt.com/pix-sampling.html:
> > 
> >   "Co-sited 4:2:0 sampling is used in 625/50 ("PAL") DV and DVCAM formats. Cr and
> >    Cb samples are on alternate lines in each field (a frame view would show two lines of
> >    YCr,Y pairs, then two lines of YCb,Y pairs). Note that this is different from the 4:2:0
> >    chroma sample positioning in JPEG, MPEG, and H.261 formats!"
> 
> Thats the part I do not understand.

  It's a bit confusing to me as well. Here's a letter I've sent to
  ffmpeg-devel regarding this issue, but haven't got any response yet.
  Can you comment on it if there's anything wrong with what I stated,
  please ? [ I probably should've crospot it, in the first place... oh well!]

To: ffmpeg-devel@...
From: Roman Shaposhnick <Roman.Shaposhnick@...>
Subject: [Ffmpeg-devel] DV 4:2:0 is not YUV420 ?

A week or so ago our friendly neighbors from libdv discovered
that libdv mishandles chroma information when sampling is 4:2:0.
The problem boiled down to the fact that in DV chroma is 
filed-based as opposed to frame-based one. Here's how Adam
Wilt describes it: http://www.adamwilt.com/pix-sampling.html

"Co-sited 4:2:0 sampling is used in 625/50 ("PAL") DV and DVCAM formats. Cr and
 Cb samples are on alternate lines in each field (a frame view would show two lines of
 YCr,Y pairs, then two lines of YCb,Y pairs). Note that this is different from the 4:2:0
 chroma sample positioning in JPEG, MPEG, and H.261 formats!"

Now, obviously ffmpeg's DV codec does things on a frame-based level
as opposed to a field based one, thus when codec processes Y and Cr/b 
blocks it does this:

    freshly                                     composite sampling plane
 uncompressed Cr  data                     for one frame (2 interlaced fields)

  r00 r01 r02 r03 r04 r05 r06 r07            (y00, r00) y01 (y02, r01) y03 .....
  r10 r11 r12 r13 r14 r15 r16 r17            (y10, b00) y11 (y12, b01) y13 .....
  ............                      --->     (y20, r10) y21 (y22, r11) y23 .....
                                        ^    (y30, b10) y31 (y32, b11) y33 .....
                                       /
                                      /
    freshly                          /
 uncompressed Cb  data              / 
   
   b00 b01 b02 b03 b04 b05 b06 b07
   b10 b11 b12 b13 b14 b15 b16 b17


  Where the correct one for DV should look like this:
                                               
                                              (y00, r00) y01 (y02, r01) y03 .....
                                              (y10, r10) y11 (y12, r11) y13 .....
                                              (y20, b00) y21 (y22, b01) y23 .....
                                              (y30, b10) y31 (y32, b11) y33 .....

Of course this doesn't seem to be a YUV420 sampling pattern ffmpeg is used
to deal with.

Thus my questions:

   1. Does all of what I said above make any sense ?
   2. If it does, is DV the only one to use this sort of twisted yuv420 sampling ?
   3. What would be the best way to fix it in ffmpeg, I'd imagine introducing
      something like YUV402 (pun intended ;-)).

Thanks,
Roman.

P.S. Here's the original e-mail for your reference:

From: Mike Grant <mgg@...>
To: libdv-dev@...
Subject: Re: [libdv-dev] libdv produces strange interlaced frames

Dan Dennedy wrote:
> Then, perhaps the DV chroma subsampling is field-based and libdv is
> treating it frame-based.
Actually, I'm embarrassed to say we've known about this for a long time, 
but never quite got around to mailing the list about it.  A student 
(Karl Sharman) at the University here found it and fixed it.  I believe 
the error was indeed due to libdv applying the chroma across two lines 
from separate fields.  You can find a sample PAL DV file and several 
pictures highlighting the problem at:
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/

The important one is 
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/libdv-0.9_codec-cropped-zoomed.png 
where it is clear that the orange of the ball is being incorrectly used 
on the white of the background.  Compare with 
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/fixedlibdv-0.9_codec-cropped-zoomed.png 
which is our fixed version.  There's also some pictures from Sony and 
Pinnacle codecs for comparison.

If you wish to use it, his change description is at 
http://www.ecs.soton.ac.uk/~mgg/libdv/libdv_decode_errors/kjschanges_v0.9.txt 
but I believe they do things in a different fashion to the original.  It 
also changes several other parts of libdv that may be worth examining 
(I've not looked at it in detail, or I'd probably have actually managed 
to mail the list about it..).

I can also make a diff of our current source tree if that would be 
helpful (it has some bits to make a Win32 port easier and some Python 
interfacing).

Mike Grant.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Ffmpeg-devel mailing list
Ffmpeg-devel@...
https://lists.sourceforge.net/lists/listinfo/ffmpeg-devel

On Thursday 06 November 2003 23:31, Roman Shaposhnick wrote:

Is it normal that your mailer is using encoding Cyrillic encoding (koi8-r) ?

> On Thu, Nov 06, 2003 at 10:18:18PM +0100, Stefan Lucke wrote:
> > On Thursday 06 November 2003 20:56, Roman Shaposhnick wrote:
[..]
> > >   "Co-sited 4:2:0 sampling is used in 625/50 ("PAL") DV and DVCAM formats. Cr and
> > >    Cb samples are on alternate lines in each field (a frame view would show two lines of
> > >    YCr,Y pairs, then two lines of YCb,Y pairs). Note that this is different from the 4:2:0
> > >    chroma sample positioning in JPEG, MPEG, and H.261 formats!"
> > 
> > Thats the part I do not understand.
> 
>   It's a bit confusing to me as well. Here's a letter I've sent to
>   ffmpeg-devel regarding this issue, but haven't got any response yet.
>   Can you comment on it if there's anything wrong with what I stated,
>   please ? [ I probably should've crospot it, in the first place... oh well!]

[..]

> Now, obviously ffmpeg's DV codec does things on a frame-based level
> as opposed to a field based one, thus when codec processes Y and Cr/b 
> blocks it does this:
> 
>     freshly                                     composite sampling plane
>  uncompressed Cr  data                     for one frame (2 interlaced fields)
> 
>   r00 r01 r02 r03 r04 r05 r06 r07            (y00, r00) y01 (y02, r01) y03 .....
>   r10 r11 r12 r13 r14 r15 r16 r17            (y10, b00) y11 (y12, b01) y13 .....
>   ............                      --->     (y20, r10) y21 (y22, r11) y23 .....
>                                         ^    (y30, b10) y31 (y32, b11) y33 .....
>                                        /
>                                       /
>     freshly                          /
>  uncompressed Cb  data              / 
>    
>    b00 b01 b02 b03 b04 b05 b06 b07
>    b10 b11 b12 b13 b14 b15 b16 b17
> 
> 
>   Where the correct one for DV should look like this:
>                                                
>                                               (y00, r00) y01 (y02, r01) y03 .....
>                                               (y10, r10) y11 (y12, r11) y13 .....
>                                               (y20, b00) y21 (y22, b01) y23 .....
>                                               (y30, b10) y31 (y32, b11) y33 .....
> 

Pattern I use now is (line numbers are frame based):

(y00 r00 b00) y01 r00 b00 (y02 r01 b01) y03 r01 b01 ... line0 field0
(y10 r10 b10) y11 r10 b10 (y12 r11 b11) y13 r11 b11 ... line1 field1
(y20 r00 b00) y21 r00 b00 (y22 r01 b01) y22 r01 b01 ... line2 field0
(y30 r10 b10) y31 r10 b10 (y32 r11 b11) y33 r11 b11 ... line3 field1

> Of course this doesn't seem to be a YUV420 sampling pattern ffmpeg is used
> to deal with.

From reading Adam Wilts text, I a came to a similar conlusion and thats is confusing.
With this order we can decode/transform nothing. To generate RGB values one MUST
have Y Cr and Cb!

> 
> Thus my questions:
> 
>    1. Does all of what I said above make any sense ?

No see above (RGB ..)

>    2. If it does, is DV the only one to use this sort of twisted yuv420 sampling ?
>    3. What would be the best way to fix it in ffmpeg, I'd imagine introducing
>       something like YUV402 (pun intended ;-)).

--------

Stefan Lucke

On Wednesday 05 November 2003 21:45, Stefan Lucke wrote:
> The changes are commited in a separate branch which includes
> my other changes as well. Branch name is "dv_stefan_lucke" .
> 

[..]
 
> Since this version breaks other applications, I strongly recomment
> NOT to INSTALL.

Should mean don't do make install. configure, make is ok.

--------

Stefan Lucke

On Friday 07 November 2003 06:26, Stefan Lucke wrote:
> On Thursday 06 November 2003 23:31, Roman Shaposhnick wrote:
[..]
> >   Where the correct one for DV should look like this:
> >                                                
> >                                               (y00, r00) y01 (y02, r01) y03 .....
> >                                               (y10, r10) y11 (y12, r11) y13 .....
> >                                               (y20, b00) y21 (y22, b01) y23 .....
> >                                               (y30, b10) y31 (y32, b11) y33 .....
> > 
> 
> Pattern I use now is (line numbers are frame based):
> 
> (y00 r00 b00) y01 r00 b00 (y02 r01 b01) y03 r01 b01 ... line0 field0
> (y10 r10 b10) y11 r10 b10 (y12 r11 b11) y13 r11 b11 ... line1 field1
> (y20 r00 b00) y21 r00 b00 (y22 r01 b01) y22 r01 b01 ... line2 field0
> (y30 r10 b10) y31 r10 b10 (y32 r11 b11) y33 r11 b11 ... line3 field1
> 
> > Of course this doesn't seem to be a YUV420 sampling pattern ffmpeg is used
> > to deal with.
> 
> From reading Adam Wilts text, I a came to a similar conlusion and thats is confusing.
> With this order we can decode/transform nothing. To generate RGB values one MUST
> have Y Cr and Cb!

I wise man let us had a look at IEC .. . Figure 25, the one of interest, explains it.
(One picture says more than thousend words)

By this figure I think i understand what Adam Wilt wnats to explain with Co-located
and so on. I you separate Cr and Cb information into separate arrays you'll get
my figure, and if you Roman, extend your figure by the missing color component by the
next one (nearest distence) you'll get the same:

(y00, r00 xx) with xx = b00 and so on
(y10, r10 yy) with yy = b10 ..

> 
> > 
> > Thus my questions:
> > 
> >    1. Does all of what I said above make any sense ?
> 
> No see above (RGB ..)

Now it makes sense to my opinion, and those render functions used by _palfix extension
are the correct one (tm).

--------

Stefan Lucke

hello

On Wed, 2003-11-05 at 21:45, Stefan Lucke wrote:
> The fixed version is available via --renderer=YUY2_palfix .
> Available names are:
> 	YUY2, YUY2_palfix, YUY2_mmx, YUY2_mmx_hh, YV12, YV12_mmx, RGB24
> 
> For frame by frame execution I added option --step.
> 
> Since this version breaks other applications, I strongly recomment
> NOT to INSTALL.

kino does not like it, I found out. :)

> For testing you'll need to

I did get it to work (altough playdv seems to not like options anymore,
so I had to change the defaults, which fortunately was quite easy) - and
the frames seem to be decoded properly now! congratulations, guys!

What made this branch incompatible with other applications? I hope a
merge with the current development branch (or maybe an unstable branch)
is doable without big hassle, so I will be able to profit from these
improvements as soon as possible!

> The future of this branch should be discussed later.

hm, what about ... now? :)

thanks to all who helped & regards
nicola

Zitat von Nicola Fankhauser <nicola.fankhauser@...>:

> hello
> 
> On Wed, 2003-11-05 at 21:45, Stefan Lucke wrote:
> > The fixed version is available via --renderer=YUY2_palfix .
> > Available names are:
> > 	YUY2, YUY2_palfix, YUY2_mmx, YUY2_mmx_hh, YV12, YV12_mmx, RGB24
> > 
> > For frame by frame execution I added option --step.
> > 
> > Since this version breaks other applications, I strongly recomment
> > NOT to INSTALL.
> 
> kino does not like it, I found out. :)
> 
> > For testing you'll need to
> 
> I did get it to work (altough playdv seems to not like options anymore,
> so I had to change the defaults, which fortunately was quite easy)

Could you explain which option do not work and which changes you had to
do to get it work ?

> - and
> the frames seem to be decoded properly now! congratulations, guys!
> 
> What made this branch incompatible with other applications? 

The incompatibility is that the render function is now runtime selectable.
So other applications have to set this separate.

> I hope a
> merge with the current development branch (or maybe an unstable branch)
> is doable without big hassle, so I will be able to profit from these
> improvements as soon as possible!
> 
> > The future of this branch should be discussed later.
> 
> hm, what about ... now? :)

There is not an explicit development branch. So "head" is
stable including fixes.

The color change will have some influence for encoding too ;-) .

I extension to my last mail from this morning,
I come to the conclusion that YV12 support has to dropped complete,
since I think NO one expects field base chroma information for this
format !!


Stefan Lucke

hello

On Fri, 2003-11-07 at 10:28, Stefan Lucke wrote:
> Could you explain which option do not work and which changes you had to
> do to get it work ?

none work for me.

nikee@...$ ./playdv --usage
dv_add_renderer: now at 1/8 (32 bytes) name = RGB24
dv_add_renderer: now at 2/8 (32 bytes) name = RGB24_palfix
dv_add_renderer: now at 3/8 (32 bytes) name = BGR32
dv_add_renderer: now at 4/8 (32 bytes) name = YUY2
dv_add_renderer: now at 5/8 (32 bytes) name = YUY2_palfix
dv_add_renderer: now at 6/8 (32 bytes) name = YUY2_mmx
dv_add_renderer: now at 7/8 (32 bytes) name = YUY2_mmx_palfix
dv_add_renderer: now at 8/8 (32 bytes) name = YUY2_mmx_hh
dv_add_renderer: now at 9/16 (64 bytes) name = YUY2_mmx_hh_palfix
dv_add_renderer: now at 10/16 (64 bytes) name = YV12
dv_add_renderer: now at 11/16 (64 bytes) name = YV12_mmx
open:: No such file or directory

nikee@...$ ./playdv --dump-frames=dump%05.ppm
~/bouncing_ball.dv
dv_add_renderer: now at 1/8 (32 bytes) name = RGB24
dv_add_renderer: now at 2/8 (32 bytes) name = RGB24_palfix
dv_add_renderer: now at 3/8 (32 bytes) name = BGR32
dv_add_renderer: now at 4/8 (32 bytes) name = YUY2
dv_add_renderer: now at 5/8 (32 bytes) name = YUY2_palfix
dv_add_renderer: now at 6/8 (32 bytes) name = YUY2_mmx
dv_add_renderer: now at 7/8 (32 bytes) name = YUY2_mmx_palfix
dv_add_renderer: now at 8/8 (32 bytes) name = YUY2_mmx_hh
dv_add_renderer: now at 9/16 (64 bytes) name = YUY2_mmx_hh_palfix
dv_add_renderer: now at 10/16 (64 bytes) name = YV12
dv_add_renderer: now at 11/16 (64 bytes) name = YV12_mmx
open:: No such file or directory

this is not a fix for the problem, it rather circumvents it:

cvs server: Diffing .
Index: playdv.c
===================================================================
RCS file: /cvsroot/libdv/libdv/playdv/playdv.c,v
retrieving revision 1.11.2.1
diff -u -r1.11.2.1 playdv.c
--- playdv.c    5 Nov 2003 20:41:32 -0000       1.11.2.1
+++ playdv.c    7 Nov 2003 09:42:33 -0000
@@ -115,8 +115,8 @@
   if(!(result->oss = dv_oss_new())) goto no_oss;
   if(!(result->decoder = dv_decoder_new(TRUE, 1, 1))) goto no_decoder;
   result->arg_loop_count = 1;
-  result->arg_renderer_name = "YUY2";
-  result->arg_single_step = 0;
+  result->arg_renderer_name = "YUY2_palfix";
+  result->arg_single_step = 1;
  
 #if HAVE_LIBPOPT
   result->option_table[DV_PLAYER_OPT_VERSION] = (struct poptOption) {



> The incompatibility is that the render function is now runtime selectable.
> So other applications have to set this separate.

Can I set the renderer at compliation time (as a temporary fix), so kino
does not segault anymore?

> The color change will have some influence for encoding too ;-) .

sure, but an unstable branch can IMHO contain unfinished and partly
buggy code... :)

regards
nicola

Zitat von Nicola Fankhauser <nicola.fankhauser@...>:

> hello
> 
> On Fri, 2003-11-07 at 10:28, Stefan Lucke wrote:
> > Could you explain which option do not work and which changes you had to
> > do to get it work ?
> 
> none work for me.

[..]
> dv_add_renderer: now at 11/16 (64 bytes) name = YV12_mmx
> open:: No such file or directory

Do you have an libpopt installed ? option handling is done via this lib.
Check for HAVE_LIBPOPT.

[..]

> 
> Can I set the renderer at compliation time (as a temporary fix), so kino
> does not segault anymore?

Didn't check kino. But I think I'll port these changes from branch to head.

regards
Stefan

I still have troubles with playdv, though. What did you do to make
it work ? All I have is a greyscale image in a left half of the 
window. 

Thanks,
Roman.

P.S. I use bouncing_ball.dv

On Fri, Nov 07, 2003 at 10:50:43AM +0100, Nicola Fankhauser wrote:
> hello
> 
> On Fri, 2003-11-07 at 10:28, Stefan Lucke wrote:
> > Could you explain which option do not work and which changes you had to
> > do to get it work ?
> 
> none work for me.
> 
> nikee@...$ ./playdv --usage
> dv_add_renderer: now at 1/8 (32 bytes) name = RGB24
> dv_add_renderer: now at 2/8 (32 bytes) name = RGB24_palfix
> dv_add_renderer: now at 3/8 (32 bytes) name = BGR32
> dv_add_renderer: now at 4/8 (32 bytes) name = YUY2
> dv_add_renderer: now at 5/8 (32 bytes) name = YUY2_palfix
> dv_add_renderer: now at 6/8 (32 bytes) name = YUY2_mmx
> dv_add_renderer: now at 7/8 (32 bytes) name = YUY2_mmx_palfix
> dv_add_renderer: now at 8/8 (32 bytes) name = YUY2_mmx_hh
> dv_add_renderer: now at 9/16 (64 bytes) name = YUY2_mmx_hh_palfix
> dv_add_renderer: now at 10/16 (64 bytes) name = YV12
> dv_add_renderer: now at 11/16 (64 bytes) name = YV12_mmx
> open:: No such file or directory
> 
> nikee@...$ ./playdv --dump-frames=dump%05.ppm
> ~/bouncing_ball.dv
> dv_add_renderer: now at 1/8 (32 bytes) name = RGB24
> dv_add_renderer: now at 2/8 (32 bytes) name = RGB24_palfix
> dv_add_renderer: now at 3/8 (32 bytes) name = BGR32
> dv_add_renderer: now at 4/8 (32 bytes) name = YUY2
> dv_add_renderer: now at 5/8 (32 bytes) name = YUY2_palfix
> dv_add_renderer: now at 6/8 (32 bytes) name = YUY2_mmx
> dv_add_renderer: now at 7/8 (32 bytes) name = YUY2_mmx_palfix
> dv_add_renderer: now at 8/8 (32 bytes) name = YUY2_mmx_hh
> dv_add_renderer: now at 9/16 (64 bytes) name = YUY2_mmx_hh_palfix
> dv_add_renderer: now at 10/16 (64 bytes) name = YV12
> dv_add_renderer: now at 11/16 (64 bytes) name = YV12_mmx
> open:: No such file or directory
> 
> this is not a fix for the problem, it rather circumvents it:
> 
> cvs server: Diffing .
> Index: playdv.c
> ===================================================================
> RCS file: /cvsroot/libdv/libdv/playdv/playdv.c,v
> retrieving revision 1.11.2.1
> diff -u -r1.11.2.1 playdv.c
> --- playdv.c    5 Nov 2003 20:41:32 -0000       1.11.2.1
> +++ playdv.c    7 Nov 2003 09:42:33 -0000
> @@ -115,8 +115,8 @@
>    if(!(result->oss = dv_oss_new())) goto no_oss;
>    if(!(result->decoder = dv_decoder_new(TRUE, 1, 1))) goto no_decoder;
>    result->arg_loop_count = 1;
> -  result->arg_renderer_name = "YUY2";
> -  result->arg_single_step = 0;
> +  result->arg_renderer_name = "YUY2_palfix";
> +  result->arg_single_step = 1;
>   
>  #if HAVE_LIBPOPT
>    result->option_table[DV_PLAYER_OPT_VERSION] = (struct poptOption) {
> 
> 
> 
> > The incompatibility is that the render function is now runtime selectable.
> > So other applications have to set this separate.
> 
> Can I set the renderer at compliation time (as a temporary fix), so kino
> does not segault anymore?
> 
> > The color change will have some influence for encoding too ;-) .
> 
> sure, but an unstable branch can IMHO contain unfinished and partly
> buggy code... :)
> 
> regards
> nicola
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> libdv-dev mailing list
> libdv-dev@...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

On Thu, Nov 06, 2003 at 09:58:24PM +0100, Stefan Lucke wrote:
> So a two frames progressive scan samples from an other cam would be
> interesting.

I have a JVC GR-DVL9600 (PAL model).  Would you also like to have a four-frame
sample of its 100 Hz mode (1/4 vertical resolution)?  Could someone who can
upload the samples to a libdv related web page contact me?  I don't want to
flood your mailboxes with large attachments.

	Marko

On Sunday 09 November 2003 20:55, Marko M=E4kel=E4 wrote:
> On Thu, Nov 06, 2003 at 09:58:24PM +0100, Stefan Lucke wrote:
> > So a two frames progressive scan samples from an other cam would be
> > interesting.
>=20
> I have a JVC GR-DVL9600 (PAL model).  Would you also like to have a fou=
r-frame
> sample of its 100 Hz mode (1/4 vertical resolution)?  Could someone who=
 can
> upload the samples to a libdv related web page contact me?  I don't wan=
t to
> flood your mailboxes with large attachments.

I never tried to upload something to libdv's page. So I don't know if I'm=
 allowed
to do that.

It's good to keep that of list. So either private mail of publish a link =
for
download. The format you mentioned seems to be interesting. Does it decod=
e currently ?
Somewhere I've read something about such a format, kino's forum ? Ah no t=
his list,
this year, june 4th.
Would be really nice to get such a sample.

--=20
--------

Stefan Lucke

On Sun, Nov 09, 2003 at 11:36:30PM +0100, Stefan Lucke wrote:
> On Sunday 09 November 2003 20:55, Marko M"akel"a wrote:
> > On Thu, Nov 06, 2003 at 09:58:24PM +0100, Stefan Lucke wrote:
> > > So a two frames progressive scan samples from an other cam would be
> > > interesting.
> > 
> > I have a JVC GR-DVL9600 (PAL model).  Would you also like to have a four-frame
> > sample of its 100 Hz mode (1/4 vertical resolution)?  Could someone who can
> > upload the samples to a libdv related web page contact me?  I don't want to
> > flood your mailboxes with large attachments.
> 
> I never tried to upload something to libdv's page. So I don't know if I'm allowed
> to do that.
> 
> It's good to keep that of list. So either private mail of publish a link for
> download. The format you mentioned seems to be interesting. Does it decode currently ?
> Somewhere I've read something about such a format, kino's forum ? Ah no this list,
> this year, june 4th.
> Would be really nice to get such a sample.

  Indeed! I'd appreciate getting them as well.

Thanks,
Roman.

On Sat, 2003-11-08 at 00:26, Roman Shaposhnick wrote:
> I still have troubles with playdv, though. What did you do to make
> it work ? All I have is a greyscale image in a left half of the 
> window. 

you can specify which mode to use for display - GTK is one of them and
it could help. If setting options does not work (because of missing
libopt I heard, like in my case) you could have a look at playdv.c and
change the defaults to other values and then recompile.

regards
nicola

On Fri, 2003-11-07 at 11:03, Stefan Lucke wrote:
> > Can I set the renderer at compliation time (as a temporary fix), so kino
> > does not segault anymore?
> 
> Didn't check kino. But I think I'll port these changes from branch to head.

Could you send a notification to this list when you have ported the
changes to HEAD?

thanks & regards
nicola

Hi all,

Those who are interested can now grab the samples I made with my JVC GR-DVL9600
from a temporary location, http://www.tcs.hut.fi/~msmakela/gr-dvl9600.zip

The zip archive contains three files, extracted with dd from a capture taken
with dvconnect, and verified with playdv and kino:
gr-dvl9600-100.dv   "high speed" mode, 2 frames per field, 100 Hz frame rate
gr-dvl9600-50.dv    interlaced mode, 50 Hz frame rate
gr-dvl9600-25.dv    progressive mode

For some reason, the white cupboard doors in the background look rather dark
gray.  Also, the red LEDs look a bit purple.

The movement is from right to left (e.g., the camera is moving from left to
right) in the two first files.  In gr-dvl9600-25.dv, the movement is in the
opposite direction.

Could someone please upload these files to a better location and announce that
location on the list?  If space is not an issue, I can provide longer samples
as well.

	Marko

On Fri, 2003-11-07 at 04:28, Stefan Lucke wrote:
> The incompatibility is that the render function is now runtime selectable.
> So other applications have to set this separate.

Can you make it so the default is the current build-time default
(yuv422) and a new function sets it explicitly?


> I come to the conclusion that YV12 support has to dropped complete,
> since I think NO one expects field base chroma information for this
> format !!

Some apps like transcode seem to prefer YV12. Is there a more standard
representation of chroma fields that we should do some processing for?

On Tuesday 11 November 2003 10:23, Marko M=E4kel=E4 wrote:
> Hi all,
>=20
> Those who are interested can now grab the samples I made with my JVC GR=
-DVL9600
> from a temporary location, http://www.tcs.hut.fi/~msmakela/gr-dvl9600.z=
ip
>=20
> The zip archive contains three files, extracted with dd from a capture =
taken
> with dvconnect, and verified with playdv and kino:
> gr-dvl9600-100.dv   "high speed" mode, 2 frames per field, 100 Hz frame=
 rate
> gr-dvl9600-50.dv    interlaced mode, 50 Hz frame rate
> gr-dvl9600-25.dv    progressive mode

Good samples. The 100Hz samples show clear our previous wrong color decod=
ing,
especially if you use the half high renderer. That should be renamed to f=
0
(field0) renderer :-) .

But I think xx-50.dv is the progressive one, since it doesen't show inter=
lace
effects. the xx-25.dv one shows interlace effects.

For the xx-50.dv there is in VCS pack VAUX-0x61, byte 3, bit 4 NOT set.
SMPTE314: thats an reserved bit ;-).
This is common to pond.dv, and my own sample Sony TRV-900E.
Three different camcorder flag progressive scan this way.

But I've no idea how to detect that special mode of xx-100.dv :-( .


--=20
--------

Stefan Lucke

On Tuesday 11 November 2003 19:02, Dan Dennedy wrote:
> On Fri, 2003-11-07 at 04:28, Stefan Lucke wrote:
> > The incompatibility is that the render function is now runtime selectable.
> > So other applications have to set this separate.
> 
> Can you make it so the default is the current build-time default
> (yuv422) and a new function sets it explicitly?

The call to select_renderer should be somewhere in dv_init after
renderer initialisation. Sould add some query functions too
so that an application could offer some choices to users.

> > I come to the conclusion that YV12 support has to dropped complete,
> > since I think NO one expects field base chroma information for this
> > format !!
> 
> Some apps like transcode seem to prefer YV12. Is there a more standard
> representation of chroma fields that we should do some processing for? 

Yes that will cause some trouble. Main intent of mine was, to get rid
of compile time selection of YU12. But as we know now, chroma has to be
processed field based.

Some graphic card do support such modes (G400 on CRTC2 output), but I don't
know if any driver offers such modes for applications.

-- 
--------

Stefan Lucke

On Tue, Nov 11, 2003 at 10:38:32PM +0100, Stefan Lucke wrote:
> But I think xx-50.dv is the progressive one, since it doesen't show interlace
> effects. the xx-25.dv one shows interlace effects.

You're right.  I verified this by watching the DV in the camera and in Kino
and by checking the timestamps.

> But I've no idea how to detect that special mode of xx-100.dv :-( .

It could use some out-of-band signalling.  If I remember correctly, some
time ago, I tried to play back a captured 100 Hz clip to the camera, and
it didn't recognize the mode.

BTW, I forgot that the camera has a 16:9 option.  Would you like to have
such clips as well?

	Marko

On Tuesday 11 November 2003 23:04, Stefan Lucke wrote:
> On Tuesday 11 November 2003 19:02, Dan Dennedy wrote:
> > On Fri, 2003-11-07 at 04:28, Stefan Lucke wrote:
> > > The incompatibility is that the render function is now runtime selectable.
> > > So other applications have to set this separate.
> > 
> > Can you make it so the default is the current build-time default
> > (yuv422) and a new function sets it explicitly?
> 
> The call to select_renderer should be somewhere in dv_init after
> renderer initialisation. Sould add some query functions too
> so that an application could offer some choices to users.

Changed initialisation in branch. Main view of kino works with branch.
There is a new function to query the names.


Stefan Lucke

hi stefan

I tried out the branch with the fixed pal-renderer (cvs update done at
14:00 MEZ) and unfortunately, I still get a segmentation fault with kino
0.6.4:

---
(gdb) run
(... load a dv file with kino ...)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3501)]
0x405f89cb in dv_decode_full_frame (dv=0x88db1d0, buffer=0x4132e008
"\037\a", color_space=e_dv_color_rgb, pixels=0xbfffecd0,
pitches=0xbfffecc0) at dv.c:392
392       dv -> current_renderer -> dv_render_func [render_type] (mb,
pixels, pitches,

(gdb) bt
#0  0x405f89cb in dv_decode_full_frame (dv=0x88db368, 
    buffer=0x4132e008 "\037\a", color_space=e_dv_color_rgb,
pixels=0xbfffecd0, 
    pitches=0xbfffecc0) at dv.c:392
#1  0x080b6860 in Frame::ExtractRGB(void*) ()
#2  0x080b6879 in Frame::ExtractPreviewRGB(void*) ()
#3  0x080bb8d7 in FrameDisplayer::Put(Frame&, _GtkWidget*, int) ()
#4  0x080c3043 in PageEditor::showFrame(int, int) ()
#5  0x080c2f2a in PageEditor::movedToFrame(int) ()
#6  0x080c0301 in KinoCommon::moveToFrame(int) ()
#7  0x080c0279 in KinoCommon::moveToFrame() ()
#8  0x080bdac9 in KinoCommon::loadFile() ()
#9  0x080db885 in openFile ()
#10 0x401c23f3 in gtk_marshal_NONE__NONE () from
/usr/lib/libgtk-1.2.so.0
#11 0x401f1a9e in gtk_signal_remove_emission_hook ()
   from /usr/lib/libgtk-1.2.so.0
#12 0x401f0f1c in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0
#13 0x401eeea8 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#14 0x40161e00 in gtk_button_clicked () from /usr/lib/libgtk-1.2.so.0
#15 0x4016336f in gtk_button_get_relief () from /usr/lib/libgtk-1.2.so.0
#16 0x401c23f3 in gtk_marshal_NONE__NONE () from
/usr/lib/libgtk-1.2.so.0
#17 0x401f0cce in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0
#18 0x401eeea8 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#19 0x40161d44 in gtk_button_released () from /usr/lib/libgtk-1.2.so.0

(gdb) frame 0
#0  0x405f89cb in dv_decode_full_frame (dv=0x88db368, 
    buffer=0x4132e008 "\037\a", color_space=e_dv_color_rgb,
pixels=0xbfffecd0, 
    pitches=0xbfffecc0) at dv.c:392
392       dv -> current_renderer -> dv_render_func [render_type] (mb,
pixels, pitches,
---

hope this helps somehow.

regards
nicola

On Saturday 15 November 2003 14:31, Nicola Fankhauser wrote:
> hi stefan
> 
> I tried out the branch with the fixed pal-renderer (cvs update done at
> 14:00 MEZ) and unfortunately, I still get a segmentation fault with kino
> 0.6.4:

Please try again .

Stefan Lucke

On Sat, 2003-11-15 at 15:38, Stefan Lucke wrote:
> Please try again .

did it and got the same result - segfault at dv.c line 392. 

just to assure myself that it's not kino or something, I re-installed
the old libdv2 debian package - and it worked (albeit with the decoder
error we hunted down together).

it's the branch 'dv_stefan_lucke', isn't it? not that in the end I was
on the wrong branch or so... :)

On Saturday 15 November 2003 16:58, Nicola Fankhauser wrote:
> On Sat, 2003-11-15 at 15:38, Stefan Lucke wrote:
> > Please try again .
> 
> did it and got the same result - segfault at dv.c line 392. 

Did you do a cvs update ?
Changelog should start with:

2003-11-15  Stefan Lucke <stefan@...> BRANCH: dv_stefan_lucke
  * compatibility for old renderer selection (kino)'
  * removed compile time dependent dv_use_mmx

> 
> just to assure myself that it's not kino or something, I re-installed
> the old libdv2 debian package - and it worked (albeit with the decoder
> error we hunted down together).
> 
> it's the branch 'dv_stefan_lucke', isn't it? not that in the end I was
> on the wrong branch or so... :)

It should. Now I get the small RGB frames (at scene change) on kinos left side too.

Stefan Lucke

On Sat, 2003-11-15 at 17:06, Stefan Lucke wrote:
> 2003-11-15  Stefan Lucke <stefan@...> BRANCH: dv_stefan_lucke
>   * compatibility for old renderer selection (kino)'
>   * removed compile time dependent dv_use_mmx

now I know what to blame: CVS anonymous access is from backup servers,
and they have a 24h+ delay compared to the developer repository.

maybe you could send me a tarball?

> It should. Now I get the small RGB frames (at scene change) on kinos left side too.

sounds good. what about transcode? because that's what I'll use
ultimately to transcode my infamous surgery film... :)

thanks & regards
nicola

hello stefan

On Sat, 2003-11-15 at 18:01, Stefan Lucke wrote:
> Let me have some feedback.

it works perfectly. great job! thank you!

regards
nicola

hi stefan

On Sat, 2003-11-15 at 18:01, Stefan Lucke wrote:
> Let me have some feedback. And don't use YV12 output format.

besides having a lot of output when decoding frames, transcode
apparently does not like the new version - when using xml import (SMIL
file created with kino consisting of multiple pointers to DV files), it
merely encodes the first scene and aborts then, whereas the old libdv2
0.99 behaves correctly and encodes all scenes of the SMIL file.

there is no error message or crash as far as I've seen.

regards
nicola

Are you encoding back to dv?
If so, I located a bug in a recent change to the encoder vlc lookup
tables I am trying to sort out besides simply reverting. This bug has
made its way into Stefan's branch as well as HEAD.


On Mon, 2003-11-17 at 08:33, Nicola Fankhauser wrote:
> hi stefan
> 
> On Sat, 2003-11-15 at 18:01, Stefan Lucke wrote:
> > Let me have some feedback. And don't use YV12 output format.
> 
> besides having a lot of output when decoding frames, transcode
> apparently does not like the new version - when using xml import (SMIL
> file created with kino consisting of multiple pointers to DV files), it
> merely encodes the first scene and aborts then, whereas the old libdv2
> 0.99 behaves correctly and encodes all scenes of the SMIL file.
> 
> there is no error message or crash as far as I've seen.
> 
> regards
> nicola
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> libdv-dev mailing list
> libdv-dev@...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

On Mon, 2003-11-17 at 15:35, Dan Dennedy wrote:
> Are you encoding back to dv?

no, I'm not. I was encoding to mpeg2 (and ffmpeg/mpeg4 as a test, but
that did not matter in the end).

but I appreciate your interest. :)

regards
nicola

On Monday 17 November 2003 19:06, Nicola Fankhauser wrote:
> On Mon, 2003-11-17 at 15:35, Dan Dennedy wrote:
> > Are you encoding back to dv?
> 
> no, I'm not.

So it's not your change Dan.

Nicola did you compiled transcode new after you installed libdv_branch ?
And do you get those repeating messages of selecting renderer by name ?

I had a look at their code. They set one field in decoder structure
and access others. I don't know which offsets the compiler generates for them.
If my offset counting is right, it would unintentionally activate
chroma clamping :-) .
I'm talking of transcode 0.6.11 .

OT: We should supply more query functions and hide internal structures for apps.


Stefan Lucke

On Mon, 2003-11-17 at 21:55, Stefan Lucke wrote:
> Nicola did you compiled transcode new after you installed libdv_branch ?

no, I thought that replacing the shared library would do it - at the
moment, I'd like to have a simple solution for transcoding my video
footage, compilation orgies are something for weekends... :)

seriously, I'll have a look at re-compiling transcode with the new libdv
when I'll have some spare hours.

> And do you get those repeating messages of selecting renderer by name ?

yes, that must be it.

regards
nicola

On Mon, 2003-11-17 at 15:55, Stefan Lucke wrote:

> OT: We should supply more query functions and hide internal structures
> for apps.

Perhaps this would help us to make the architecture dependencies in
dv_types.h private or even permit us to not distribute it all?

On Tuesday 18 November 2003 16:25, Dan Dennedy wrote:
> On Mon, 2003-11-17 at 15:55, Stefan Lucke wrote:
> 
> > OT: We should supply more query functions and hide internal structures
> > for apps.
> 
> Perhaps this would help us to make the architecture dependencies in
> dv_types.h private or even permit us to not distribute it all?

I definitly vote for not distribute internal structures.
Other votes ?

Just added some of those query functions to branch.

Next release should include them.
Should that be named 0.100 ?


Stefan Lucke

On Wed, 2003-11-19 at 06:47, Stefan Lucke wrote:
> On Tuesday 18 November 2003 16:25, Dan Dennedy wrote:
> > On Mon, 2003-11-17 at 15:55, Stefan Lucke wrote:
> > 
> > > OT: We should supply more query functions and hide internal structures
> > > for apps.
> > 
> > Perhaps this would help us to make the architecture dependencies in
> > dv_types.h private or even permit us to not distribute it all?
> 
> I definitly vote for not distribute internal structures.
> Other votes ?
> 
> Just added some of those query functions to branch.
> 
> Next release should include them.
> Should that be named 0.100 ?

We were headed towards a 1.0 release, but we need to delay that at least
by a couple of releases. So, yes 0.100 is fine. I would like to release
asap, and require the new release for Kino 0.7.0, which I will update
for interface changes.

Can you give us a status update on your branch and plans? Where can you
use help?

On Friday 21 November 2003 14:37, Dan Dennedy wrote:
> On Wed, 2003-11-19 at 06:47, Stefan Lucke wrote:
> > On Tuesday 18 November 2003 16:25, Dan Dennedy wrote:
> > > On Mon, 2003-11-17 at 15:55, Stefan Lucke wrote:
> > > 
> > > > OT: We should supply more query functions and hide internal structures
> > > > for apps.
> > > 
> > > Perhaps this would help us to make the architecture dependencies in
> > > dv_types.h private or even permit us to not distribute it all?
> > 
> > I definitly vote for not distribute internal structures.
> > Other votes ?
> > 
> > Just added some of those query functions to branch.
> > 
> > Next release should include them.
> > Should that be named 0.100 ?
> 
> We were headed towards a 1.0 release, but we need to delay that at least
> by a couple of releases. So, yes 0.100 is fine. I would like to release
> asap, and require the new release for Kino 0.7.0, which I will update
> for interface changes.

Some of the changes I did in branch, are now in head too (PAL color
decoding, additional query functions).

> 
> Can you give us a status update on your branch and plans? Where can you
> use help?

Branch should be used for some tests including design checks/tests.
Help is needed for checking PAL encoding part (field based chroma).

If you plan to release kino 0.7 soon, those other changes like select
render should stay in branch.

So
	libdv-0.100	extended query capabilities to avoid direct structure access
	libdv-0.101	drop dv_types.h from distribution
	libdv-0.102	select renderer ?? better documentation
	libdv-1.0	with some fixes (whoever finds bugs).


Stefan Lucke

On Sun, 2003-11-23 at 12:22, Stefan Lucke wrote:
> On Friday 21 November 2003 14:37, Dan Dennedy wrote:
> > On Wed, 2003-11-19 at 06:47, Stefan Lucke wrote:
> > > On Tuesday 18 November 2003 16:25, Dan Dennedy wrote:
> > > > On Mon, 2003-11-17 at 15:55, Stefan Lucke wrote:
> > > > 
> > > > > OT: We should supply more query functions and hide internal structures
> > > > > for apps.
> > > > 
> > > > Perhaps this would help us to make the architecture dependencies in
> > > > dv_types.h private or even permit us to not distribute it all?
> > > 
> > > I definitly vote for not distribute internal structures.
> > > Other votes ?
> > > 
> > > Just added some of those query functions to branch.
> > > 
> > > Next release should include them.
> > > Should that be named 0.100 ?
> > 
> > We were headed towards a 1.0 release, but we need to delay that at least
> > by a couple of releases. So, yes 0.100 is fine. I would like to release
> > asap, and require the new release for Kino 0.7.0, which I will update
> > for interface changes.
> 
> Some of the changes I did in branch, are now in head too (PAL color
> decoding, additional query functions).

OK, good. This tells me you will selectively move changes from your
branch to head rather than attempting some complete merge. 

> > 
> > Can you give us a status update on your branch and plans? Where can you
> > use help?
> 
> Branch should be used for some tests including design checks/tests.
> Help is needed for checking PAL encoding part (field based chroma).
> 
> If you plan to release kino 0.7 soon, those other changes like select
> render should stay in branch.
> 
> So
> 	libdv-0.100	extended query capabilities to avoid direct structure access

OK, I would be happy without this being complete. I feel we need to make
a new release very soon that contains bugfixes since the last release
and esp. the PAL chroma fix. 

> 	libdv-0.101	drop dv_types.h from distribution

I would be content to make this version contain the full query
capabilities because Charles and I have decided not to make Kino 0.7.0
require a new libdv release as we do not want to compound too many
changes at the same time.

After the kino 0.7.0 release, I will start changing Kino, dvgrab, and
smilutils to use new query functions, and kino 0.7.1 will likely require
this libdv version.

> 	libdv-0.102	select renderer ?? better documentation
> 	libdv-1.0	with some fixes (whoever finds bugs).

sounds good.

> Stefan Lucke

On Sunday 23 November 2003 20:25, Dan Dennedy wrote:
> On Sun, 2003-11-23 at 12:22, Stefan Lucke wrote:
> > On Friday 21 November 2003 14:37, Dan Dennedy wrote:
> > > Can you give us a status update on your branch and plans? Where can you
> > > use help?
> > 
> > Branch should be used for some tests including design checks/tests.
> > Help is needed for checking PAL encoding part (field based chroma).
> > 
> > If you plan to release kino 0.7 soon, those other changes like select
> > render should stay in branch.
> > 
> > So
> > 	libdv-0.100	extended query capabilities to avoid direct structure access

Next release should definitly include a fix for PAL encoder.
Did a short test with recode, but resulted frame looks very poor.
I'll try some steps with encoder as long as I can stay within C part.


Stefan Lucke