libdv-dev

Re: [libdv-dev] Howto change DV file to MPEG2 and vice versa ???

[LE Q. K. <quo...@fp...>]

Thanks very much about change from DV to MPEG2.
But how about the vice versa from MPEG2 to DV ????
I find an app "encodedv" in libdv but don't know how to use. What's its
input ???

Thanks very much again for your answer

----- Original Message -----
From: Dan Dennedy <da...@de...>
To: LE QUOC KHOI <quo...@fp...>
Cc: libdv-dev <lib...@li...>
Sent: Thursday, March 07, 2002 2:29 PM
Subject: Re: [libdv-dev] Howto change DV file to MPEG2 and vice versa ???


> You need to make a type 2 DV AVI file, and then use mjpegtools:
> http://mjpeg.sf.net/
>
>
> On Thu, 2002-03-07 at 02:17, LE QUOC KHOI wrote:
> > Thank you very much for your feedbacks
> >
> >
> > _______________________________________________
> > libdv-dev mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libdv-dev
>
>
>

Re: [libdv-dev] Howto change DV file to MPEG2 and vice versa ???

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

You need to make a type 2 DV AVI file, and then use mjpegtools:
http://mjpeg.sf.net/


On Thu, 2002-03-07 at 02:17, LE QUOC KHOI wrote:
> Thank you very much for your feedbacks
> 
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] Howto change DV file to MPEG2 and vice versa ???

[LE Q. K. <quo...@fp...>]

Thank you very much for your feedbacks

Re: [libdv-dev] DV plugin

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

I am sorry I have not been more involved with the libquicktime project.
I could test the current code myself and maybe see where your problem
is. Unfortunately, I have been busy working on some Kino stuff lately in
order to get out a new release. I'll try to get around it.

Regarding the color shifting... I assume this is with RGB input. Before
working on the recent libdv patch, I made diffs of both your and Heroine
Virtual's changes to libdv to analyze. I will view yours again and
attempt to see what change you made and test it. You should not need to
write your own program to test this case; you can use the supplied
encodedv utility. Remember, my libdv patch reuses much more code than
yours and Heroine's changes. Therefore, any changes should affect
encodedv as well.

P.s. Heroine Virtual will still have a bone to pick with color gamut
clamping and his need to preserve superblack. Maybe we can eventually
address this with a configure option.


On Wed, 2002-03-06 at 14:18, Arthur Peters wrote:
> On Thu, 2002-02-28 at 20:04, Dan Dennedy wrote:
> > Well, yes, the whole reason for my patch was to provide a public 
> > function as encodedv statically links using non-distributed headers. 
> > However, there is a lot of code reuse; I did not really innovate here. 
> > It is interesting tho that encodedv does not crash. Also, I have not 
> > experienced any crashing with recode.c. Have you played with recode?
> > 
> 
> Sorry it took so long, but I finally beat on it some more. I found that
> I can't get recode to crash either. It seems to me that the problem is
> probably in the way libquicktime is calling libdv (although it may that
> libdv should be handling it better). I have found that almost any frame
> contence crashes it, so it's almost sure to be in my code. I'm going to
> write a little ppmtodv program to do some more testing. I'll try to
> figure out what situation causes the crash. 
> 
> BTW, I've noticed that the chromenance values seems to be offset in the
> image. That is the U and V values are shifted right with respect to the
> Y values. I managed to get ride of this in my hacked version for
> quicktime4linux, but I just mess with it until it worked. I don't know
> what I did. I'll send you example images of this after I right my little
> program (ppmtodv).
> 
> -Arthur
>  
> -- 
> 
> 	"Last night I had the strangest dream
> 	 I'd ever dreamed before
> 	 I dreamed the world had all agreed
> 	 To put an end to war"
> 			- Ed McCurdy
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

Re: [libdv-dev] DV plugin

[Arthur P. <am...@si...>]

On Thu, 2002-02-28 at 20:04, Dan Dennedy wrote:
> Well, yes, the whole reason for my patch was to provide a public 
> function as encodedv statically links using non-distributed headers. 
> However, there is a lot of code reuse; I did not really innovate here. 
> It is interesting tho that encodedv does not crash. Also, I have not 
> experienced any crashing with recode.c. Have you played with recode?
> 

Sorry it took so long, but I finally beat on it some more. I found that
I can't get recode to crash either. It seems to me that the problem is
probably in the way libquicktime is calling libdv (although it may that
libdv should be handling it better). I have found that almost any frame
contence crashes it, so it's almost sure to be in my code. I'm going to
write a little ppmtodv program to do some more testing. I'll try to
figure out what situation causes the crash. 

BTW, I've noticed that the chromenance values seems to be offset in the
image. That is the U and V values are shifted right with respect to the
Y values. I managed to get ride of this in my hacked version for
quicktime4linux, but I just mess with it until it worked. I don't know
what I did. I'll send you example images of this after I right my little
program (ppmtodv).

-Arthur
 
-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

Re: [libdv-dev] Utilities using libdv, encoding jaggies

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

AJ Milne wrote:

>Hi. Scanned the archives, don't seem to see anyone else with this particular problem.
>
>RGB, pack it back in using the ppm encoder (one that takes 24 bit RGB). I cut into the codec in two places it doesn't normally advertise in the headers to make this work -- once in the ppm encoder (I call dv_enc_rgb_to_ycb directly, to compose a single frame in the ppm input encoder), then once in the encode normally called by the encoder loop, passing in the set up ppm encoder. Diff file at http://www.well.com/~ajmilne/patches/ajm.libdv!
>.25022002.patch, if this is of any interest.
>
Did you see the new public encoder interface that I committed to CVS 
that takes care of this already?

>
>Utilities do their thing, but the trouble is, the encoding is quite consistently rough -- a lot worse resolution than the sources -- kinda cubist/blocky, a little like an off-centre satellite feed. Anyone out there have any idea why, and whether there's anything I can do about it?
>
I have some blockiness around diagonal lines with much contrast.

>
>I've tried various settings -- within and without the static qno tables, 1 to 3 passes, various builds of the codec, and best I get still looks like this. Is this normal? Is the DV AVI format just basically really  lossy, or is this the lib?
>
Well, it's lossy allright, but it's considered extremely good for the 
compression levels that it provides especially for consumer and prosumer 
usage. It would be naive to say that are encoding is very high quality 
at this point because it is a fairly new implementation, and not many 
applications are exploiting it yet. I implemented the new interface to 
make it easier for apps to integrate, in particular Kino.

>
>Also -- are these tools of any interest to the project?
>
Perhaps. Would you care to help Kino? We want to do as much as possible 
in YUV space for things like fades, dissolves, and wipes. Obviously, 
multiple, sequenced image importing is a big feature to add. I am 
planning to use sodipodi SVG code for rendering titles. Finally, I have 
been exploring in my mind a way to integrate Kino with GIMP by 
programming a GIMP plugin and communicating to it from within Kino 
through the scriptfu TCP port and temp files. Also, a standalone GIMP 
plugin that works with DV files and decodes and encodes numbered XCFs 
would be cool so it would work with the existing set of GIMP video plugins.

>
>Thanks all.
>
>_______________________________________________
>libdv-dev mailing list
>lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libdv-dev
>

[libdv-dev] Re: Utilities using libdv, encoding jaggies

[AJ M. <aj...@we...>]

Re previous -- disregard re encoding problem -- moved to using Arthur Peters' YUV422 encoder in the libdv compiled into libquicktime, and it has very nicely solved the problem. Thanks all.

On Sun, 3 Mar 2002 21:36:21 -0500
AJ Milne <aj...@we...> wrote:

> Hi. Scanned the archives, don't seem to see anyone else with this particular problem.
> 
> I've been building some simple utilities that use Kino's AVI code and the codec -- one that overlays fades (any colour, to or from, any place on the track), another that takes an RGBA PNG and lays it down as a static title (does nice semi-transparent titles, if you set the PNG up right), another that grabs frames, another that displays header and frame info to the console, all working from DV AVIs. Goal is to take DV tapes, cut 'em up, do a sequence I can run back onto the tape with Kino. To do this, tools extract RGB from each frame, edit the RGB, pack it back in using the ppm encoder (one that takes 24 bit RGB). I cut into the codec in two places it doesn't normally advertise in the headers to make this work -- once in the ppm encoder (I call dv_enc_rgb_to_ycb directly, to compose a single frame in the ppm input encoder), then once in the encode normally called by the encoder loop, passing in the set up ppm encoder. Diff file at http://www.well.com/~ajmilne/patches/ajm.lib!
dv.25022002.patch, if this is of any interest.
> 
> Utilities do their thing, but the trouble is, the encoding is quite consistently rough -- a lot worse resolution than the sources -- kinda cubist/blocky, a little like an off-centre satellite feed. Anyone out there have any idea why, and whether there's anything I can do about it?
> 
> I've tried various settings -- within and without the static qno tables, 1 to 3 passes, various builds of the codec, and best I get still looks like this. Is this normal? Is the DV AVI format just basically really  lossy, or is this the lib?
> 
> Also -- are these tools of any interest to the project?
> 
> Thanks all.

[libdv-dev] Utilities using libdv, encoding jaggies

[AJ M. <aj...@we...>]

Hi. Scanned the archives, don't seem to see anyone else with this particular problem.

I've been building some simple utilities that use Kino's AVI code and the codec -- one that overlays fades (any colour, to or from, any place on the track), another that takes an RGBA PNG and lays it down as a static title (does nice semi-transparent titles, if you set the PNG up right), another that grabs frames, another that displays header and frame info to the console, all working from DV AVIs. Goal is to take DV tapes, cut 'em up, do a sequence I can run back onto the tape with Kino. To do this, tools extract RGB from each frame, edit the RGB, pack it back in using the ppm encoder (one that takes 24 bit RGB). I cut into the codec in two places it doesn't normally advertise in the headers to make this work -- once in the ppm encoder (I call dv_enc_rgb_to_ycb directly, to compose a single frame in the ppm input encoder), then once in the encode normally called by the encoder loop, passing in the set up ppm encoder. Diff file at http://www.well.com/~ajmilne/patches/ajm.libdv!
.25022002.patch, if this is of any interest.

Utilities do their thing, but the trouble is, the encoding is quite consistently rough -- a lot worse resolution than the sources -- kinda cubist/blocky, a little like an off-centre satellite feed. Anyone out there have any idea why, and whether there's anything I can do about it?

I've tried various settings -- within and without the static qno tables, 1 to 3 passes, various builds of the codec, and best I get still looks like this. Is this normal? Is the DV AVI format just basically really  lossy, or is this the lib?

Also -- are these tools of any interest to the project?

Thanks all.

Re: [libdv-dev] Re: DV plugin

[Peter S. <ud...@rz...>]

Hi Dan, Arthur,

On 1 Mar 2002, Dan Dennedy wrote:

> 	dv_vlc_block_t vlc_block[5*6];
> [...]
> 	for (m = 0; m < 5; m++) {
> 		dv_vlc_block_t *v_bl = vlc_block;
> 		for (b = 0; b < 6; b++) {
> 			v_bl->bit_offset = (8* (80 * m))+dv_parse_bit_start[b];
> 			v_bl->bit_budget = (b < 4) ? 100 : 68;
> 			v_bl++;
> 		}
> 	}

This is really funny. You can delete this whole loop since bit_offset and
bit_budget are only needed for vlc_encoding not for quantization... (and
are therefor initialized once again in the vlc_encoding loop). You would
have noticed this bug definitely, since he had otherwise assigned an
arbitrary bit_offset or bit_budget in vlc_block[m*6+b] for m > 0.
=> core dump on every picture.

> I am now looking for something I do differently in my code than yours
> since the problem does not appear with encodedv.

I suspect that we got way too large amplitudes for some reasons.
Could you send me a small demo application and test picture which
reproduces this problem?

Greetings,
Peter

---
Peter Schlaile  ***  eMail ud...@rz...

So Linus, what are we doing tonight?
          The same thing we do every night Tux. Try to take over the world!

Re: [libdv-dev] Re: DV plugin

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

Peter, check out the bug report below. I am analysing the code, but I
honestly do not understand the inner workings--yet. 

I have basically duplicated the process_videosegment for my needs, and I
see no differences in my version. This bit of code in both versions is
suspicious:

	dv_vlc_block_t vlc_block[5*6];
[...]
	for (m = 0; m < 5; m++) {
		dv_vlc_block_t *v_bl = vlc_block;
		for (b = 0; b < 6; b++) {
			v_bl->bit_offset = (8* (80 * m))+dv_parse_bit_start[b];
			v_bl->bit_budget = (b < 4) ? 100 : 68;
			v_bl++;
		}
	}

It looks like v_bl is not incremented over the full range during
initialisation. Unfortunatley, the vlc_blocks are not the data used in
the vlc_num_bits routines, and this appears to be unrelated. On the
other hand, I do not fully understand the quantization. Any thoughts?

I am now looking for something I do differently in my code than yours
since the problem does not appear with encodedv.

+-DRD-+

On Thu, 2002-02-28 at 01:19, Arthur Peters wrote:
> On Wed, 2002-02-27 at 21:33, Dan Dennedy wrote:
> > > I think there might be a bug in the encoder in libdv that is causing a
> > > segfault under some situations. It seems like it might even be based on
> > > image content. I think it might be that large areas of perfect black
> > > (RGB 0,0,0) cause problems. Any ideas from people familiar with libdv?
> > > 
> > Do you know if it's only an issue with RGB input or also with YUV? Also,
> > I don't suppose you also tried to disable MMX to further isolate the
> > problem area? This is the sort of testing I'll try first unless you have
> > isolated it.
> 
> I have attached a file with four stack traces. no-MMX YUV input, no-MMX
> RGB input, MMX YUV input and MMX RGB input. All compinations cause a
> segfault. There isn't a difference between RGB and YUV, but I included
> both for completness. Please tell me if you need more info. I'll be glad
> to give it.
> 
> Just found a weird thing, if I use the encodedv program it works fine. I
> think I saw that encodedv uses a different function to encode the frames
> then the external interface.
> 
> 
> -Arthur
> 

> .........oooooooooooo No-MMX ooooooooooo.........
> ------========= YUV input ===========--------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 3196)]
> vlc_num_bits_block (coeffs=0xbfff9520) at encode.c:442
> 442		return vlc_num_bits_lookup[(amp + 255) | (run << 9)];
> (gdb) bt
> #0  vlc_num_bits_block (coeffs=0xbfff9520) at encode.c:442
> #1  0x40347624 in quant_3_passes (videoseg=0xbfffe410, vblocks=0xbfffa4e0, static_qno=0) at encode.c:1085
> #2  0x403489df in dv_encode_videosegment (dv_enc=0xbffff7a0, videoseg=0xbfffe410, vsbuffer=0x405c5238 "") at encode.c:1490
> #3  0x40348d30 in dv_encode_full_frame (in=0x805e100, out=0x405c5008 "", color_space=e_dv_color_yuv, isPAL=0, is16x9=0, 
>     vlc_encode_passes=3, static_qno=0, force_dct_=-1) at encode.c:1655
> #4  0x40019c7d in encode () from /usr/local/lib/libquicktime/lqt_dv.so
> #5  0x405e85a8 in ?? ()
> #6  0x83248108 in ?? ()
> Cannot access memory at address 0x81018001
> 
> ------========= RGB input ===========--------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 3224)]
> vlc_num_bits_block (coeffs=0xbfff9520) at encode.c:442
> 442		return vlc_num_bits_lookup[(amp + 255) | (run << 9)];
> (gdb) bt
> #0  vlc_num_bits_block (coeffs=0xbfff9520) at encode.c:442
> #1  0x40347624 in quant_3_passes (videoseg=0xbfffe410, vblocks=0xbfffa4e0, static_qno=0) at encode.c:1085
> #2  0x403489df in dv_encode_videosegment (dv_enc=0xbffff7a0, videoseg=0xbfffe410, vsbuffer=0x405c5238 "") at encode.c:1490
> #3  0x40348d30 in dv_encode_full_frame (in=0x805e168, out=0x405c5008 "", color_space=e_dv_color_rgb, isPAL=0, is16x9=0, 
>     vlc_encode_passes=3, static_qno=0, force_dct_=-1) at encode.c:1655
> #4  0x40019c7d in encode () from /usr/local/lib/libquicktime/lqt_dv.so
> #5  0x405e8878 in ?? ()
> #6  0x050c0100 in ?? ()
> Cannot access memory at address 0x2010002
> 
> .........oooooooooooo MMX ooooooooooo.........
> ------========= YUV input ===========--------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 13749)]
> 0x4034e145 in vlc_num_bits_block_amp_zero () from /usr/local/lib/libdv.so.1
> (gdb) bt
> #0  0x4034e145 in vlc_num_bits_block_amp_zero () from /usr/local/lib/libdv.so.1
> #1  0xbfff9458 in ?? ()
> Cannot access memory at address 0x7200
> 
> ------========= RGB input ===========--------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 13687)]
> 0x4034e145 in vlc_num_bits_block_amp_zero () from /usr/local/lib/libdv.so.1
> (gdb) bt
> #0  0x4034e145 in vlc_num_bits_block_amp_zero () from /usr/local/lib/libdv.so.1
> #1  0xbfff9458 in ?? ()
> Cannot access memory at address 0x7200

Re: [libdv-dev] Re: DV plugin

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

Arthur Peters wrote:

>I have attached a file with four stack traces. no-MMX YUV input, no-MMX
>RGB input, MMX YUV input and MMX RGB input. All compinations cause a
>segfault. There isn't a difference between RGB and YUV, but I included
>both for completness. Please tell me if you need more info. I'll be glad
>to give it.
>
Ok, at least it is crashing in the same place so I will look into it.

>
>Just found a weird thing, if I use the encodedv program it works fine. I
>think I saw that encodedv uses a different function to encode the frames
>then the external interface.
>
>Even if I bypass the qt DV plugin completely it still crashes. I think
>you may be able to get somewhere by comparing the function encode (used
>by encodedv) and dv_encode_full_frame.
>
Well, yes, the whole reason for my patch was to provide a public 
function as encodedv statically links using non-distributed headers. 
However, there is a lot of code reuse; I did not really innovate here. 
It is interesting tho that encodedv does not crash. Also, I have not 
experienced any crashing with recode.c. Have you played with recode?

>
>BTW, I thought of another thing. dv_decoder_t objects are allocated
>using dv_decoder_new() but there is no dv_decoder_delete() and
>dv_decoder_t contains pointer so every time you dv_decoder_new() an
>object and then free() it you leak a bit of memory. This is not a
>problem in players where you just have one decoder for the life-time of
>the program, but in libquicktime it is possible that a person would open
>and close file quite a lot and each time a DV file was closed a bit of
>memory would be leaked. This is not a major problem but I thought I
>ought to mention it.
>
Yes, it is known but not really documented anywhere that you need to 
free(decoder->video) and free(decoder->audio). That's all.

[libdv-dev] Re: DV plugin

[Arthur P. <am...@si...>]

On Wed, 2002-02-27 at 21:33, Dan Dennedy wrote:
> > I think there might be a bug in the encoder in libdv that is causing a
> > segfault under some situations. It seems like it might even be based on
> > image content. I think it might be that large areas of perfect black
> > (RGB 0,0,0) cause problems. Any ideas from people familiar with libdv?
> > 
> Do you know if it's only an issue with RGB input or also with YUV? Also,
> I don't suppose you also tried to disable MMX to further isolate the
> problem area? This is the sort of testing I'll try first unless you have
> isolated it.

I have attached a file with four stack traces. no-MMX YUV input, no-MMX
RGB input, MMX YUV input and MMX RGB input. All compinations cause a
segfault. There isn't a difference between RGB and YUV, but I included
both for completness. Please tell me if you need more info. I'll be glad
to give it.

Just found a weird thing, if I use the encodedv program it works fine. I
think I saw that encodedv uses a different function to encode the frames
then the external interface.

Even if I bypass the qt DV plugin completely it still crashes. I think
you may be able to get somewhere by comparing the function encode (used
by encodedv) and dv_encode_full_frame.

BTW, I thought of another thing. dv_decoder_t objects are allocated
using dv_decoder_new() but there is no dv_decoder_delete() and
dv_decoder_t contains pointer so every time you dv_decoder_new() an
object and then free() it you leak a bit of memory. This is not a
problem in players where you just have one decoder for the life-time of
the program, but in libquicktime it is possible that a person would open
and close file quite a lot and each time a DV file was closed a bit of
memory would be leaked. This is not a major problem but I thought I
ought to mention it.

-Arthur
 
-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

[libdv-dev] Re: [Libquicktime-devel] DV plugin

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

On Wed, 2002-02-27 at 00:27, Arthur Peters wrote:
> 
> I think there might be a bug in the encoder in libdv that is causing a
> segfault under some situations. It seems like it might even be based on
> image content. I think it might be that large areas of perfect black
> (RGB 0,0,0) cause problems. Any ideas from people familiar with libdv?
> 
Do you know if it's only an issue with RGB input or also with YUV? Also,
I don't suppose you also tried to disable MMX to further isolate the
problem area? This is the sort of testing I'll try first unless you have
isolated it.

Re: [libdv-dev] DV plugin

[H. <mh...@in...>]

On Tue 26.02. 23:27, Arthur Peters wrote:

> I think there might be a bug in the encoder in libdv that is causing a
> segfault under some situations. It seems like it might even be based on
> image content. I think it might be that large areas of perfect black
> (RGB 0,0,0) cause problems. Any ideas from people familiar with libdv?

Hmm, strange. The single frame I've placed at 

http://www.mark13.de/other/segfault.dv

which segfaults the _decoder_ has large black areas also.

Mark

P.S.
I've modified the code preventing it from crashing which performs 
some checks during transformation to the RGB space but the problem
seems to be somewhere else.

-- 
mh...@in...
dipl.-inf.                        Innominate Security Technologies AG
software engineer                                   networking people
tel: +49.30.6392-3305                      http://www.innominate.com/

[libdv-dev] DV plugin

[Arthur P. <am...@si...>]

I just commited the updated dv plugin. 

Log message:
Converted DV plugin to external libdv.
Decoding works and seems stable. Encoding works some of the time.
Removed old internal libdv directory.

I think there might be a bug in the encoder in libdv that is causing a
segfault under some situations. It seems like it might even be based on
image content. I think it might be that large areas of perfect black
(RGB 0,0,0) cause problems. Any ideas from people familiar with libdv?

There is a bug in my code that is causing the output to be heavily puple
tinted if it must be converted to a new color space before encoding. If
the input is YUV422 or RGB888 and the right size the output looks fine.
Any hint on this would be good. 

I'm going to working on these problems.

BTW, someone talked about not knowing the format of BC_YUV422. It is
YUY2. That is a two pixel macropixel is: YUYV.

-Arthur

-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

[libdv-dev] Re: Please look at this libdv patch

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

On Fri, 2002-02-22 at 12:59, Peter Schlaile wrote:
> attached is a working version of recode.c. You simply forgot to copy
> the line
> 
> 	memset(target, 0, 144000);
> 
FYI all,
In the committed version, dv_encode_full_frame() clears the target
buffer for you.

Re: [libdv-dev] Thread safety of libdv

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

On Sun, 2002-02-24 at 03:51, Dan Dennedy wrote:
> deeper in the code that is not. Well, I know of at least one global var
> affecting DCT encoding that I need to address.

Ok, I just committed that fix. The new public encoder does not use the
global force_dct. 

Are static vars in function scope thread-safe?
Looking through the code, nothing is jumping out at me except that
perhaps dv_init() is being called repeatedly by each thread. dv_init()
contains a static flag var to skip if already done. So far I only see
the numerous lookup tables initialized in dv_init() are global. 

Re: [libdv-dev] Thread safety of libdv

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

As far as I know it is not thread-safe. Charlie Yates noticed it during
Kino 0.5 development and added thread locks. I took care to make sure my
additions to the encoder is thread-safe, but there might be things
deeper in the code that is not. Well, I know of at least one global var
affecting DCT encoding that I need to address.

I would like to take care of this before the next 1.0 release.

On Sun, 2002-02-24 at 02:14, Arthur Peters wrote:
> Hi, I'm updating the libquicktime DV plugin inpreperation for the new
> encoding interface and I need to know if libdv is thread safe. The old
> dv code used a lock around all libdv access. Is this still nessisary?
> 
> -Arthur
> 
> -- 
> 
> 	"Last night I had the strangest dream
> 	 I'd ever dreamed before
> 	 I dreamed the world had all agreed
> 	 To put an end to war"
> 			- Ed McCurdy
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] commited encoder interface to CVS

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

From the ChangeLog:

2002-23-02  Dan Dennedy <da...@de...>
	* Added public (shared object) interface to encoder: see dv.h

	* Added dv1394.h header to support apps needing to use
	  dv1394 IOCTL interface

	* Added recode.c test utility

	* Changed configure.in to configure.ac to invoke proper
	  version of autoconf on Debian

	* Applied patch from Peter Schlaile to repair encode during
	  build on non x86 architectures

2002-07-02  Peter Schlaile <ud...@rz...-karlsruhe.
	* New dvconnect version featuring 
	  - multi-threading and buffer control
	  - new video1394 interface support
	  - underrun picture support
	
	* Updated insert_audio to plugin interface
	
	* Added dvavi, a small utility to convert DV-AVIs to RAW-DV
	
	* Added wide-screen option to encoder
	
	* Made the encoder detect PAL/NTSC on /dev/video input
	
	* Various bugfixes

[libdv-dev] Thread safety of libdv

[Arthur P. <am...@si...>]

Hi, I'm updating the libquicktime DV plugin inpreperation for the new
encoding interface and I need to know if libdv is thread safe. The old
dv code used a lock around all libdv access. Is this still nessisary?

-Arthur

-- 

	"Last night I had the strangest dream
	 I'd ever dreamed before
	 I dreamed the world had all agreed
	 To put an end to war"
			- Ed McCurdy

Re: [libdv-dev] Re: Please look at this libdv patch

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

On Fri, 2002-02-22 at 14:18, Peter Schlaile wrote:
> Hi Dan,
> 
> ... and while you are at it. Could you commit the attached patch, which
> enables encoding with ARCH_X86=0 again?

Done. I will commit all of this soon after adding some docs and
changelog entries.

[libdv-dev] Re: Please look at this libdv patch

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

On Fri, 2002-02-22 at 12:59, Peter Schlaile wrote:
> Hi Dan,
> 
> attached is a working version of recode.c. You simply forgot to copy
> the line
> 
> 	memset(target, 0, 144000);
> 
> into dv_encode_full_frame(). This is very important since put_bits works
> by or-ing the vlc_bits into the dv-frame... It was one of these not so
> obvious performance optimizations, I know...

Awesome, I knew I could count on you! We greatly appreciate the ground
you have broken with dv encoding and DV transmission over 1394. I
suppose you could say that my work on this patch and on dv1394 is a
tribute to your work.

> 
> P.S.: Interesting little test program. Should try this several times and
>       watch how picture quality decreases...
> 

That was my thought. I read a review of Sonic Foundry Vegas Video 3
where they compared Sonic's DV codec to MS' lousy one. In it they
recompressed frames up to 50X.

[libdv-dev] Re: Please look at this libdv patch

[Peter S. <ud...@rz...>]

Hi Dan,

... and while you are at it. Could you commit the attached patch, which
enables encoding with ARCH_X86=0 again?

Greetings,
Peter

---
Peter Schlaile  ***  eMail ud...@rz...

So Linus, what are we doing tonight?
          The same thing we do every night Tux. Try to take over the world!

[libdv-dev] Re: Please look at this libdv patch

[Peter S. <ud...@rz...>]

Hi Dan,

attached is a working version of recode.c. You simply forgot to copy
the line

	memset(target, 0, 144000);

into dv_encode_full_frame(). This is very important since put_bits works
by or-ing the vlc_bits into the dv-frame... It was one of these not so
obvious performance optimizations, I know...

On 22 Feb 2002, Dan Dennedy wrote:

> The Problem... audio is working fine for me, but the video output is
> noisy. I included my recode.c program I have been using for testing.
> You'll have to adapt for PAL. It takes a raw dv file on input, decodes,
> and then re-encodes dv and audio to stdout. You can toggle the defines
> to make it generate ppms or read ppms. This helps verify the decoder is
> working okay, and provides a test mode that isolates the encoder from
> the decoder. In pure recode operation, the decoder interfers with the
> encoder. dv_parse_header() on each frame before decoding affects the
> output.

See memset() above...

> Throwing a dv_init() between the decode and encode operations
> affects it too. I am currently at a loss.

Not that surprising. The second call to dv_init() simply skips
initialisation...

Greetings,
Peter

P.S.: Interesting little test program. Should try this several times and
      watch how picture quality decreases...

---
Peter Schlaile  ***  eMail ud...@rz...

So Linus, what are we doing tonight?
          The same thing we do every night Tux. Try to take over the world!

[libdv-dev] configure.ac

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

I recommend we rename configure.in as configure.ac. This is in
accordance with autoconf 2.5. Also, Debian does a special dual
autoconf2.13 and 2.5 install. It invokes 2.13 on configure.in and 2.5 on
configure.ac. 

Also, I had to get automake 1.5 to get all the necessary macros as 1.4
(p2?) did not contain them. Should we modify bootstrap accordingly?

I am prepared to apply these changes with my forthcoming commit if
that's okay.

+-DRD-+