Menu
▾
▴
libdv-dev
This list is closed, nobody may subscribe to it.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(36) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(3) |
Oct
(2) |
Nov
(59) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(43) |
Feb
(11) |
Mar
(10) |
Apr
(39) |
May
(22) |
Jun
(25) |
Jul
(10) |
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
(22) |
Dec
(2) |
| 2002 |
Jan
(4) |
Feb
(20) |
Mar
(50) |
Apr
(13) |
May
(39) |
Jun
(36) |
Jul
(14) |
Aug
(16) |
Sep
(3) |
Oct
(23) |
Nov
(34) |
Dec
(16) |
| 2003 |
Jan
(37) |
Feb
(37) |
Mar
(2) |
Apr
(14) |
May
(10) |
Jun
(23) |
Jul
(33) |
Aug
(16) |
Sep
(27) |
Oct
(17) |
Nov
(76) |
Dec
(10) |
| 2004 |
Jan
(89) |
Feb
(13) |
Mar
(13) |
Apr
(14) |
May
(43) |
Jun
(27) |
Jul
(34) |
Aug
(14) |
Sep
(4) |
Oct
(15) |
Nov
(14) |
Dec
(33) |
| 2005 |
Jan
(9) |
Feb
(4) |
Mar
(12) |
Apr
(19) |
May
|
Jun
(4) |
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2006 |
Jan
(3) |
Feb
(4) |
Mar
(7) |
Apr
(11) |
May
(3) |
Jun
(7) |
Jul
|
Aug
(8) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(7) |
Nov
(7) |
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(8) |
Jul
(3) |
Aug
|
Sep
(6) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Dan D. <dde...@co...> - 2001-06-11 06:55:20
|
I just uploaded to SourceForge, a new Kino 0.43.
Release Notes
-----------------------------------------------
IMPORTANT: use the new libavc1394 v0.2.2.
Bug fixes, see ChangeLog.
There is a new option in the Display Options tab of the Preferences dialog:
Enable preview during capture. If this is off, then the capture window
stops displaying the video during the actual process of capture (when
you click start grabbing). This is good for slower machines to prevent
dropped or corrupt video frames.
ChangeLog
-----------------------------------------------
Changes in version 0.43, June 10, 2001:
Changes by Dan Dennedy:
- expose cip_d for NTSC users in the prefs dialog as the timing
threshold
- include video1394.h in distribution
- endian fix in riff.cc ?? (needs testing)
- better AV/C handling of changing nodes
- new Preferences option to disable preview during capture
Changes by Arne Schirmacher:
- fixes to IEEE1394Reader::AviHandler to be compatible with new
versions of ohci1394
- bug fix for PAL DV export
- prettier code
|
|
From: Alastair M. <ala...@ww...> - 2001-06-02 17:46:29
|
The 50_60 flag makes a *big* difference exporting to a Sony TRV103 NTSC camcorder, thank you Yamazaki and Dan. Changing the CIP timing to 1, 16 (ie 30.0 frames/sec) cleans out some block noise with that camcorder too. My camcorder now seems rock-solid on export with the 50_60 flag set correctly and the framerate at 30.0. Framerate at 29.97 gives an image but with periodic bursts of block noise, so this is certainly something that needs to be user settable for different equipment. It'd be nice to build up a database of which settings work best with which hardware. (And perhaps have the software default the settings based on the hardware IDs from polling the device.) The above successful testing was based on modifying dvconnect (in libdv) with the changes suggested for Kino -- I haven't tested the latter yet because of the required kernel module change. Thanks guys. -- Alastair |
|
From: Arne S. <ar...@sc...> - 2001-06-02 06:55:57
|
Can you explain exactly when the incorrect sound appears? At playback of an AVI under Linux or Windows, using what program? Or after playing back a tape on the camcorder that has been recorded with DV export? I don't fully understand your description; in particular why you have this problem also in raw mode, where no audio code is involved. The difference between AVI type 1 and type 2 is that both Kino and dvgrab attempt to decode the audio data and put it into separate blocks in the AVI file. This is for some Windows programs that expect both a video and an audio track in the AVI file. As there are many possible audio formats (12 bit, 16 bit, 2 channels, 4 channels and other features), it looks as if I did not got all combinations right. Arne -----Original Message----- From: Alastair Mayer Sent: Wednesday, May 30, 2001 11:00 PM To: Dan Dennedy Cc: lib...@li...; Kin...@li...; Kirk I Reiten Subject: [libdv-dev] Re: [Kino-dev] DV output - data points More (audio) data points -- see below Dan Dennedy wrote: > > Thanks for the feedback. I am commiting to CVS a new version of Kino > tomorrow night that will expose the various timing constants for DV export > in the Preferences dialog (the preferences will also save between sessions). > This will let you experiment to get a good output. Also, I have noticed on > my AMD 333 development machine, that the updating of the progress bar > interferes with export, so I will either provide a toggle in preferences or > see if a simple textual "current frame #/total frames" feedback is less > intrusive. Cool. Although for my work-related app I may not use Kino -- see below -- but I'll be using it for home video editing. > Alastair, it is normal for your device to take a few seconds to "synch" up > before displaying the video. Therefore, I have on the Kino task list to > revise DV export to display the first frame for a few seconds before > continuing. Sounds reasonable -- testing the DV-bridge with longer clips it does seem to pretty consistently take about 5 seconds before the analog stream appears, but if I cat multiple clips together (eg cat *.dv|dvconnect -s) there's only a brief blank between clips. And I have more data points from playing with dvgrab, Kino, and dvconnect, all with the Dazzle Hollywood DV bridge in NTSC. The video stream looks okay on longer clips, but I'm getting weird audio effects in some cases (on export). Specifically, capturing in Kino AVI 2 mode and playing back, or capturing with dvgrab or Kino in raw mode and exporting with dvconnect, I get garbled audio -- some sort of periodic noise or chirp mixed with the audio. I don't get this if I capture/export with Kino AVI 1, or capture raw DV with dvconnect and export with dvconnect -s. Clean audio in both those cases. (The machine I'm currently working on doesn't have an audio card so I can't test what it sounds like played back on the PC.) Since there's a way to get clean audio in AVI (mode 1) or raw DV (with dvconnect) that's a low priority for me, just thought I'd mention it. I'm probably going to end up with some hybrid of the Kino playlist and dvconnect's export of DV files, since that's what I need for the project I'm currently being paid to work on. (Dynamic creation of videotapes from a library of clips. Currently we're using expen$ive analog cards on NT.) -- Alastair _______________________________________________ libdv-dev mailing list lib...@li... http://lists.sourceforge.net/lists/listinfo/libdv-dev |
|
From: Alastair M. <am...@pe...> - 2001-05-31 16:44:58
|
Following up to my post yesterday about export to a camcorder vs to
a DV-bridge, I've found that a lot of the timing/sync problems seem
to be due to disk performance -- although there's never a complaint
about dropped frames.
The DV-bridge (Dazzle's Hollywood) still works better than my Sony
TRV103 camcorder, but I found a major difference between the two
PCs I was testing on. Curiously, the one with the better CPU and
more memory does *worse* -- a file that exported perfectly to the
DV-bridge on the "slower" (CPU) machine gave repeated interruptions and
lost data on the "faster" (CPU) one.
I ran 'hdparm -t' and 'hdparm -T' to find the disk timing, and that
seems to be the critical difference. The numbers:
Export works Export fails/scrambled
Buffer-cache read 43.4 MB/sec 20.0 MB/sec
Buffered disk read 8.3 MB/sec 6.6 MB/sec
The timing on both is bad enough that exporting to the camcorder is
pointless, but I do get a few more frames (although scrambled) on
the machine with faster disk. (In both cases the file is larger
than available RAM).
Neither Kino nor dvconnect complain about transfer problems.
I do have a faster machine I can try after I move the 1394 card
(102 MB/sec cache reads, 15.4 MB/sec disk reads), which I can also
put a SCSI drive on, but I won't have time to try that before I
go out of town for a week. I'm hoping the camcorder works there.
Bottom line: camcorder is still more sensitive to timing than is
the DV bridge, but disk (and bus) performance has a *major* effect on
whether either is usable.
Hope this helps somebody,
-- Alastair
|
|
From: Alastair M. <am...@pe...> - 2001-05-30 21:59:17
|
More (audio) data points -- see below Dan Dennedy wrote: > > Thanks for the feedback. I am commiting to CVS a new version of Kino > tomorrow night that will expose the various timing constants for DV export > in the Preferences dialog (the preferences will also save between sessions). > This will let you experiment to get a good output. Also, I have noticed on > my AMD 333 development machine, that the updating of the progress bar > interferes with export, so I will either provide a toggle in preferences or > see if a simple textual "current frame #/total frames" feedback is less > intrusive. Cool. Although for my work-related app I may not use Kino -- see below -- but I'll be using it for home video editing. > Alastair, it is normal for your device to take a few seconds to "synch" up > before displaying the video. Therefore, I have on the Kino task list to > revise DV export to display the first frame for a few seconds before > continuing. Sounds reasonable -- testing the DV-bridge with longer clips it does seem to pretty consistently take about 5 seconds before the analog stream appears, but if I cat multiple clips together (eg cat *.dv|dvconnect -s) there's only a brief blank between clips. And I have more data points from playing with dvgrab, Kino, and dvconnect, all with the Dazzle Hollywood DV bridge in NTSC. The video stream looks okay on longer clips, but I'm getting weird audio effects in some cases (on export). Specifically, capturing in Kino AVI 2 mode and playing back, or capturing with dvgrab or Kino in raw mode and exporting with dvconnect, I get garbled audio -- some sort of periodic noise or chirp mixed with the audio. I don't get this if I capture/export with Kino AVI 1, or capture raw DV with dvconnect and export with dvconnect -s. Clean audio in both those cases. (The machine I'm currently working on doesn't have an audio card so I can't test what it sounds like played back on the PC.) Since there's a way to get clean audio in AVI (mode 1) or raw DV (with dvconnect) that's a low priority for me, just thought I'd mention it. I'm probably going to end up with some hybrid of the Kino playlist and dvconnect's export of DV files, since that's what I need for the project I'm currently being paid to work on. (Dynamic creation of videotapes from a library of clips. Currently we're using expen$ive analog cards on NT.) -- Alastair |
|
From: Dan D. <dde...@co...> - 2001-05-30 20:38:44
|
Thanks for the feedback. I am commiting to CVS a new version of Kino tomorrow night that will expose the various timing constants for DV export in the Preferences dialog (the preferences will also save between sessions). This will let you experiment to get a good output. Also, I have noticed on my AMD 333 development machine, that the updating of the progress bar interferes with export, so I will either provide a toggle in preferences or see if a simple textual "current frame #/total frames" feedback is less intrusive. Alastair, it is normal for your device to take a few seconds to "synch" up before displaying the video. Therefore, I have on the Kino task list to revise DV export to display the first frame for a few seconds before continuing. Kirk, in regards to your last email, the new Kino will also include a new video1394.c that lets me expose the SYT offset in the driver through preferences, and that is another thing you need to experiment with now that you are close. From: "Alastair Mayer" > I've been experimenting with exporting DV over the past couple of days, > and have a couple of data points for anyone struggling with this. > > The short form: works with Dazzle DV-Bridge, not with Sony TRV-103. > > The longer form: my software setup: Mandrake 8.0, 2.4.3 kernel with > Mandrake-included ieee1394 modules, and libdv, libraw, dvgrab, and > kino built from the latest downloadable tgz/rpm files (not CVS). > (dvgrab-0.99, kino-0.4b, libdv-0.8, libraw1394-0.8.2, although come > to think of it, the raw1394 module came with Mandrake, so I'm using > whatever version that is, just using the 0.8.2 header files for > building the other stuff) > > It appears to work OK using a Dazzle Hollywood DV-Bridge (hardware > DV-to-analog), it appears to NOT work properly to my Sony TRV103 > camcorder. NTSC in both cases. Using Kino to export the movie. > > So far I've only tested short clips. Watching the Hollywood output > on a TV monitor it remains dark for a few seconds then the video > comes on, I don't know if that's buffering, or sync'ing, or both. > Watching my camcorder, the viewer flickers indicating that something > is happening, and reviewing the tape shows mostly blue screen with > the occasional video frame or two (sometimes garbled). > > I suspect the camcorder is more sensitive to timing and possibly > to various flags being set properly in the DV stream. I know the > camcorder *can* record DV input because I've tested it with output > from a (Windows) setup using the Matrox RT-2000 and Adobe Premiere. > > A couple of additional notes on hardware: I tested the camcorder > and Hollywood box on different systems: the camcorder on my home > system with a D-Link 1394 card, the Hollywood box at work with an > Adaptec card. (AMD K6-233 at home, Pentium-166MMX at work, both > with 64MB, both with fresh Mandrake installs plus the 1394/DV software). > At some point I'll either take the Hollywood box home or bring my > camera in to work and retest, so that those will be the only variables. > > Right now my priority is being able to export DV via the Hollywood > box (or similar) for recording on VHS. (Via a playlist, no GUI). > I'll be testing with PAL (the DV-Bridge supports both) in a few days > when our PAL gear arrives. > > -- Alastair > > (OBTW - building Kino requires libdb1.a which doesn't appear to be part > of a Mandrake install (at least not as I installed it). I just > copied the lib from a SuSE install on another machine here.) > > _______________________________________________ > Kino-dev mailing list > Kin...@li... > http://lists.sourceforge.net/lists/listinfo/kino-dev > |
|
From: Alastair M. <am...@pe...> - 2001-05-29 17:59:04
|
I've been experimenting with exporting DV over the past couple of days, and have a couple of data points for anyone struggling with this. The short form: works with Dazzle DV-Bridge, not with Sony TRV-103. The longer form: my software setup: Mandrake 8.0, 2.4.3 kernel with Mandrake-included ieee1394 modules, and libdv, libraw, dvgrab, and kino built from the latest downloadable tgz/rpm files (not CVS). (dvgrab-0.99, kino-0.4b, libdv-0.8, libraw1394-0.8.2, although come to think of it, the raw1394 module came with Mandrake, so I'm using whatever version that is, just using the 0.8.2 header files for building the other stuff) It appears to work OK using a Dazzle Hollywood DV-Bridge (hardware DV-to-analog), it appears to NOT work properly to my Sony TRV103 camcorder. NTSC in both cases. Using Kino to export the movie. So far I've only tested short clips. Watching the Hollywood output on a TV monitor it remains dark for a few seconds then the video comes on, I don't know if that's buffering, or sync'ing, or both. Watching my camcorder, the viewer flickers indicating that something is happening, and reviewing the tape shows mostly blue screen with the occasional video frame or two (sometimes garbled). I suspect the camcorder is more sensitive to timing and possibly to various flags being set properly in the DV stream. I know the camcorder *can* record DV input because I've tested it with output from a (Windows) setup using the Matrox RT-2000 and Adobe Premiere. A couple of additional notes on hardware: I tested the camcorder and Hollywood box on different systems: the camcorder on my home system with a D-Link 1394 card, the Hollywood box at work with an Adaptec card. (AMD K6-233 at home, Pentium-166MMX at work, both with 64MB, both with fresh Mandrake installs plus the 1394/DV software). At some point I'll either take the Hollywood box home or bring my camera in to work and retest, so that those will be the only variables. Right now my priority is being able to export DV via the Hollywood box (or similar) for recording on VHS. (Via a playlist, no GUI). I'll be testing with PAL (the DV-Bridge supports both) in a few days when our PAL gear arrives. -- Alastair (OBTW - building Kino requires libdb1.a which doesn't appear to be part of a Mandrake install (at least not as I installed it). I just copied the lib from a SuSE install on another machine here.) |
|
From: David B. <dav...@id...> - 2001-05-29 10:00:13
|
Hi all, I'm trying to use the dvgrab's function ExtractAudio(). Has anybody already used it ? Could you explain me how to use it ? Does anybody know something about : * the number of channels * the rate (samples per sec) * the bits per sample ? Thanks for your help. David |
|
From: Dan D. <dde...@co...> - 2001-05-22 21:30:49
|
(I dropped linux1394-devel from the recipients since it is really off-topic.) Also, check out http://deinterlace.sourceforge.net/ This is Windows code, but you re-use the core functions, which are apparantly high quality. From: "Arne Schirmacher" > The mjpeg project has a decent de-interlacer. I wrote a brief article on > this software on my website ( > http://www.schirmacher.de/arne/dvgrab/index_e.html ), but I did not mention > the de-interlacing functions. > > My understanding of the interlacing in DV is that every frame in DV is > actually two interleaved video frames where every other row has been > omitted. So a non-interlaced frame could be made by taking every other row > and duplicating it in two consecutive rows (to retain the w/h ratio) into > the destination buffer. The "two interleaved video frames" are called fields. Interlacing captures inter-field motion, which is why deinterlacing is not so simple. > I would like to have such a function in the libdv code. I could easily > duplicate it in the Kino code, but if interlacing is a feature of DV, then > libdv should have code to de-interlace it. I do not agree that libdv should do it. It is not really a feature of DV; it is a feature of the analog video signals that DV compresses. Also, other analog video capture sources (LML-33) have interlacing too. There are many deinterlacers out there. Broadcast and GIMP have one. Gstreamer should have one if it does not. Deinterlacing and scaling are things I have been thinking about in Kino as well. I recently asked libdv-dev about built-in scaling, to which the answer is not so simple. However, I do not advocate implementing these into Kino. This is just another example of how Kino has a monolithic architecture and should be ported to gstreamer. > I am not an mpeg expert at all, but I think that the mpeg code would > compress de-interlaced frames better than interlaced ones, because the > latter have more rough looking features which do not compress that good. > But this is just a guess. Yes, and you do not need to be an expert to notice it! The inter-field motion creates a "blinds effect" that compresses something horrible. > Also, when saving a single frame the de-interlaced image would look much > better. Maybe the two half frames can even be processed and overlaid with > some existing image processing library. > > Arne > -----Original Message----- > From: David Bonneville > Sent: Monday, May 21, 2001 2:35 PM > To: lib...@li...; lin...@li... > Subject: horrible frames > > Hi all, > > I have some problems when I use Frame::ExtractRGB() (dvgrab's code). I got > some interlaced frames as you can see at > http://www.idiap.ch/~bonnevil/images > > Do you have/know this problem ? > > I am also trying to use Frame::ExtractYUV() but it seems that I've not > find > the correct format yet. If somebody know it or has ever used it before, > please tell me what to do. > > Thanks > > David > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-devel > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux1394-devel > |
|
From: David B. <dav...@id...> - 2001-05-22 14:11:30
|
RG9lcyBhbnlib2R5IGtub3cgdGhpcyBmdW5jdGlvbiB3aGljaCBpcyBpbiBlZGl0bGlzdC5j IChtanBlZ3Rvb2xzKSA6DQppbnQgZWxfZ2V0X2F1ZGlvX2RhdGEoY2hhciAqYWJ1ZmYsIGxv bmcgbmZyYW1lLCBFZGl0TGlzdCAqZWwsIGludA0KbXV0ZSkNCg0KSSB3b3VsZCBsaWtlIHRv IGtub3cgdGhlIGZvcm1hdCBvZiBhYnVmZiwgdGhhdCBtZWFucyB3aGF0IGlzIGluIGl0IGFu ZA0KaG93ID8gKGZvcm1hdCBvZiBhdWRpbyBkYXRhLi4uKQ0KDQpEYXZpZA0KDQpBcm5lIFNj aGlybWFjaGVyIHdyaXRlczoNCiA+IFRoZSBtanBlZyBwcm9qZWN0IGhhcyBhIGRlY2VudCBk ZS1pbnRlcmxhY2VyLiBJIHdyb3RlIGEgYnJpZWYgYXJ0aWNsZSBvbiANCiA+IHRoaXMgc29m dHdhcmUgb24gbXkgd2Vic2l0ZSAoIA0KID4gaHR0cDovL3d3dy5zY2hpcm1hY2hlci5kZS9h cm5lL2R2Z3JhYi9pbmRleF9lLmh0bWwgKSwgYnV0IEkgZGlkIG5vdCBtZW50aW9uIA0KID4g dGhlIGRlLWludGVybGFjaW5nIGZ1bmN0aW9ucy4NCiA+IA0KID4gTXkgdW5kZXJzdGFuZGlu ZyBvZiB0aGUgaW50ZXJsYWNpbmcgaW4gRFYgaXMgdGhhdCBldmVyeSBmcmFtZSBpbiBEViBp cyANCiA+IGFjdHVhbGx5IHR3byBpbnRlcmxlYXZlZCB2aWRlbyBmcmFtZXMgd2hlcmUgZXZl cnkgb3RoZXIgcm93IGhhcyBiZWVuIA0KID4gb21pdHRlZC4gU28gYSBub24taW50ZXJsYWNl ZCBmcmFtZSBjb3VsZCBiZSBtYWRlIGJ5IHRha2luZyBldmVyeSBvdGhlciByb3cgDQogPiBh bmQgZHVwbGljYXRpbmcgaXQgaW4gdHdvIGNvbnNlY3V0aXZlIHJvd3MgKHRvIHJldGFpbiB0 aGUgdy9oIHJhdGlvKSBpbnRvIA0KID4gdGhlIGRlc3RpbmF0aW9uIGJ1ZmZlci4NCiA+IA0K ID4gSSB3b3VsZCBsaWtlIHRvIGhhdmUgc3VjaCBhIGZ1bmN0aW9uIGluIHRoZSBsaWJkdiBj b2RlLiBJIGNvdWxkIGVhc2lseSANCiA+IGR1cGxpY2F0ZSBpdCBpbiB0aGUgS2lubyBjb2Rl LCBidXQgaWYgaW50ZXJsYWNpbmcgaXMgYSBmZWF0dXJlIG9mIERWLCB0aGVuIA0KID4gbGli ZHYgc2hvdWxkIGhhdmUgY29kZSB0byBkZS1pbnRlcmxhY2UgaXQuDQogPiANCiA+IEkgYW0g bm90IGFuIG1wZWcgZXhwZXJ0IGF0IGFsbCwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgbXBlZyBj b2RlIHdvdWxkIA0KID4gY29tcHJlc3MgZGUtaW50ZXJsYWNlZCBmcmFtZXMgYmV0dGVyIHRo YW4gaW50ZXJsYWNlZCBvbmVzLCBiZWNhdXNlIHRoZSANCiA+IGxhdHRlciBoYXZlIG1vcmUg cm91Z2ggbG9va2luZyBmZWF0dXJlcyB3aGljaCBkbyBub3QgY29tcHJlc3MgdGhhdCBnb29k LiANCiA+IEJ1dCB0aGlzIGlzIGp1c3QgYSBndWVzcy4NCiA+IA0KID4gQWxzbywgd2hlbiBz YXZpbmcgYSBzaW5nbGUgZnJhbWUgdGhlIGRlLWludGVybGFjZWQgaW1hZ2Ugd291bGQgbG9v ayBtdWNoIA0KID4gYmV0dGVyLiBNYXliZSB0aGUgdHdvIGhhbGYgZnJhbWVzIGNhbiBldmVu IGJlIHByb2Nlc3NlZCBhbmQgb3ZlcmxhaWQgd2l0aCANCiA+IHNvbWUgZXhpc3RpbmcgaW1h Z2UgcHJvY2Vzc2luZyBsaWJyYXJ5Lg0KID4gDQogPiBBcm5lDQogPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KID4gRnJvbToJRGF2aWQgQm9ubmV2aWxsZQ0KID4gU2VudDoJTW9u ZGF5LCBNYXkgMjEsIDIwMDEgMjozNSBQTQ0KID4gVG86CWxpYmR2LWRldkBsaXN0cy5zb3Vy Y2Vmb3JnZS5uZXQ7IGxpbnV4MTM5NC1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCiA+ IFN1YmplY3Q6CWhvcnJpYmxlIGZyYW1lcw0KID4gDQogPiBIaSBhbGwsDQogPiANCiA+IEkg aGF2ZSBzb21lIHByb2JsZW1zIHdoZW4gSSB1c2UgRnJhbWU6OkV4dHJhY3RSR0IoKSAoZHZn cmFiJ3MgY29kZSkuIEkgZ290DQogPiBzb21lIGludGVybGFjZWQgZnJhbWVzIGFzIHlvdSBj YW4gc2VlIGF0IA0KID4gaHR0cDovL3d3dy5pZGlhcC5jaC9+Ym9ubmV2aWwvaW1hZ2VzDQog PiANCiA+IERvIHlvdSBoYXZlL2tub3cgdGhpcyBwcm9ibGVtID8NCiA+IA0KID4gSSBhbSAg YWxzbyB0cnlpbmcgdG8gdXNlIEZyYW1lOjpFeHRyYWN0WVVWKCkgYnV0IGl0IHNlZW1zIHRo YXQgSSd2ZSBub3QgDQogPiBmaW5kDQogPiB0aGUgY29ycmVjdCBmb3JtYXQgeWV0LiBJZiBz b21lYm9keSBrbm93IGl0IG9yIGhhcyBldmVyIHVzZWQgaXQgYmVmb3JlLA0KID4gcGxlYXNl IHRlbGwgbWUgd2hhdCB0byBkby4NCiA+IA0KID4gVGhhbmtzDQogPiANCiA+IERhdmlkDQog PiANCiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogPiBtYWlsaW5nIGxpc3QgbGludXgxMzk0LWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5l dA0KID4gaHR0cDovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9saW51 eDEzOTQtZGV2ZWwAAA0KID4gDQogPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KID4gbWFpbGluZyBsaXN0IGxpbnV4MTM5NC1kZXZlbEBsaXN0 cy5zb3VyY2Vmb3JnZS5uZXQNCiA+IGh0dHA6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlz dHMvbGlzdGluZm8vbGludXgxMzk0LWRldmVs |
|
From: Daniel K. <ko...@ta...> - 2001-05-22 07:57:55
|
On Mon, May 21, 2001 at 09:59:38PM +0100, Arne Schirmacher wrote: > My understanding of the interlacing in DV is that every frame in DV is > actually two interleaved video frames where every other row has been > omitted. So a non-interlaced frame could be made by taking every other row > and duplicating it in two consecutive rows (to retain the w/h ratio) into > the destination buffer. DV doesn't care about interlacing. That's your camera's business. Some models allow you to switch off interlacing, i.e. they send only a single field at full resolution. Has a drawback when capturing motion of course, as you're sort of decreasing your sample rate. Nothing libdv should care about, though, I think. Regards, Daniel. |
|
From: Arne S. <ar...@sc...> - 2001-05-21 20:08:12
|
The mjpeg project has a decent de-interlacer. I wrote a brief article on this software on my website ( http://www.schirmacher.de/arne/dvgrab/index_e.html ), but I did not mention the de-interlacing functions. My understanding of the interlacing in DV is that every frame in DV is actually two interleaved video frames where every other row has been omitted. So a non-interlaced frame could be made by taking every other row and duplicating it in two consecutive rows (to retain the w/h ratio) into the destination buffer. I would like to have such a function in the libdv code. I could easily duplicate it in the Kino code, but if interlacing is a feature of DV, then libdv should have code to de-interlace it. I am not an mpeg expert at all, but I think that the mpeg code would compress de-interlaced frames better than interlaced ones, because the latter have more rough looking features which do not compress that good. But this is just a guess. Also, when saving a single frame the de-interlaced image would look much better. Maybe the two half frames can even be processed and overlaid with some existing image processing library. Arne -----Original Message----- From: David Bonneville Sent: Monday, May 21, 2001 2:35 PM To: lib...@li...; lin...@li... Subject: horrible frames Hi all, I have some problems when I use Frame::ExtractRGB() (dvgrab's code). I got some interlaced frames as you can see at http://www.idiap.ch/~bonnevil/images Do you have/know this problem ? I am also trying to use Frame::ExtractYUV() but it seems that I've not find the correct format yet. If somebody know it or has ever used it before, please tell me what to do. Thanks David _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/lists/listinfo/linux1394-devel |
|
From: David B. <dav...@id...> - 2001-05-21 13:35:04
|
Hi all, I have some problems when I use Frame::ExtractRGB() (dvgrab's code). I got some interlaced frames as you can see at http://www.idiap.ch/~bonnevil/images Do you have/know this problem ? I am also trying to use Frame::ExtractYUV() but it seems that I've not find the correct format yet. If somebody know it or has ever used it before, please tell me what to do. Thanks David |
|
From: Charles 'B. K. <kr...@ac...> - 2001-05-20 15:56:01
|
Libdv doesn't have a built-in scaler. It would be relatively easy to downscale to a thumbnail by doing DC-only decode (downsample by factor 8 in each direction). Otherwise, it would be a fair amount of work to get much performance benefit from an integrated scaler. One problem is that parsing takes up so much of the current time, and that does not change when you down sample. As a simple rule, every pixel in a block depends on every DCT coefficient. Since parsing currently accounts for about 50% of libdv time, the total reduction from scaling is limited to 50% of the reduction achieved, which will be exclusively in the backend. So if you can speed up the backend by 50%, your total speedup will be 25%. If anybody wants to do that, I'd suggest writing specialized versions of DCT, weight, and quant that work on 1/2 and 1/4 of the pixels. -- Buck ps Alternatively, there is a really interesting article in the most recent issue of IEEE Transactions on Circuits and Systems for Video Technology on doing scaling in the DCT domain. I don't know if their techniques would let you get speedups over non-scaled decode, but it looks very cool for arbitrary scaling in sofware, relative to other software techniques. "Dan Dennedy" <dde...@co...> writes: > Is there a way to tell the decoder to do some down-scaling while decoding? I > am interested in offering a smaller video window size in Kino to improve the > performance of dv decoding. Currently, in our preferences, I added a setting > for the quality index, and that helps. I would prefer that the decoder does > the scaling so it has less work to do. A downstream scaler would defeat the > purpose! > Thanks, > +-DRD-+ |
|
From: Dan D. <dde...@co...> - 2001-05-20 03:32:54
|
Is there a way to tell the decoder to do some down-scaling while decoding? I am interested in offering a smaller video window size in Kino to improve the performance of dv decoding. Currently, in our preferences, I added a setting for the quality index, and that helps. I would prefer that the decoder does the scaling so it has less work to do. A downstream scaler would defeat the purpose! Thanks, +-DRD-+ |
|
From: <no...@so...> - 2001-05-09 08:07:13
|
Patches item #422574, was updated on 2001-05-09 01:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=422574&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Kobras (nold) Assigned to: Nobody/Anonymous (nobody) Summary: Fix enc_input.c with non-asm. Initial Comment: Current enc_input.c will only build when ARCH_X86 is set. The attached patch adds a missing include for rint(), and defines a few helper variables in the !ARCH_X86 parts. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=422574&group_id=4393 |
|
From: <no...@so...> - 2001-05-08 19:14:24
|
Patches item #422421, was updated on 2001-05-08 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=422421&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artur Zaprzala (zybi) Assigned to: Nobody/Anonymous (nobody) Summary: Some cleaning in include directives mess Initial Comment: The attached patch corrects include directives in libdv subdirectory and changes the ones like this: #include <libdv/dv_types.h> #include <dv_types.h> to this: #include "dv_types.h" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=422421&group_id=4393 |
|
From: <no...@so...> - 2001-05-08 18:55:35
|
Patches item #422417, was updated on 2001-05-08 11:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=422417&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artur Zaprzala (zybi) Assigned to: Nobody/Anonymous (nobody) Summary: Workaround for gcc error on RedHat 7.1 Initial Comment: After installing RedHat 7.1 and recompiling libdv suddenly my dv videos started to be a little jerky. What I discovered was that array dv_weight_inverse_248_matrix was incorrectly initialized in libdv/weighting.c. Finally it turned out to be gcc bug - invalid assembly code was produced that referenced uninitialized variable. Changing optimization switch from -O2 to -O1 corrects this problem. The other solution is to modify a little expression "1.0 / (W[x] * W[2*z] / 2);" where the problem arises. Here is the patch attached. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=422417&group_id=4393 |
|
From: <no...@so...> - 2001-05-06 15:11:26
|
Patches item #421837, was updated on 2001-05-06 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=421837&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Schlaile (schlaile) Assigned to: Nobody/Anonymous (nobody) Summary: dvconnect / --no-mmap / bugfixes Initial Comment: * Added dvconnect. A small utility to grab and send dv data over firewire * Added --no-mmap option to playdv in order to handle pipes correctly * Various bugfixes ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=421837&group_id=4393 |
|
From: Christoph S. <ch...@ne...> - 2001-05-05 22:24:34
|
Hello all,
first of all my apologies to everybody who gets this e-mail more than once
since I posted it to three mailing-lists. But that takes me exactly to the
point that I want to address: would it be a good idea to initiate a project on
sourceforge that tries to bring people working in different projects together
to discuss a common video-editing or video-production toolset for linux?
I subscribed to these different mailing-lists since I was interested in the
following (maybe I am not the only one here)
1. capture video from analog sources or a digital camcorder
2. nonlinear editing of the material
3. add titles, effects, manipulate/dub sound
4. compress the video to MPEG, manipulate MPEG
5. create (S)VCDs for easy watching of the result on a standalone player
And luckily there were tools to do almost all of these steps. The problem is
that they are distributed over a lot of places:
1. MJPEG project, libdv, dvgrab, kino, bcast2000
2. MJPEG project, kino, bcast2000
3. GIMP, bcast2000
4. MJPEG project, SAMPEG, mpgtx
5. vcdimager
Some of the recent developments or plans that are very interesting for the
above purposes that I have seen include:
* the source from several of the above projects has been used to build
gstreamer plugins (DV, MPEG,...)
* there has been some discussion on the MJPEG mailing list to move to a
gstreamer based framework
* the MJPEG tools now also allow to encode DV data directly as MPEG
* for vcdimager a XML frontend is underway that would allow to create
(S)VCDs with menus, etc.
I get the impression that it would be beneficial to have a central discussion
forum for video-editing that covers the whole way from MJPEG, DV capture to
(S)VCD production with open-source tools and to combine some efforts in
developing the missing links and tools. Probably everything based on the
gstreamer framework.
Christoph
------------------------------------------------------------------------------
Christoph Scheurer e-mail: ch...@fe...
Department of Chemistry WWW: http://markov.chem.rochester.edu/chris
University of Rochester
P.O. Box RC 270216 phone: +1-716-275-8289
Rochester, NY 14627-0216 +1-716-242-0989 (private)
USA Fax: +1-716-473-6889
------------------------------------------------------------------------------
GnuPG public key: http://markov.chem.rochester.edu/chris/key.html
|
|
From: Erik W. <om...@te...> - 2001-05-05 22:06:07
|
On Sat, 5 May 2001, Arne Schirmacher wrote: > The MJPEG/Linux square <http://sourceforge.net/projects/mjpeg> has a tool > that can convert DV AVIs into mpeg files. This is very interesting. Now we > can convert DV data easily to mpeg format. FYI, the author of this package frequents #gstreamer, and is converting the mjpeg tools to gstreamer as soon as he gets the the next release out. The other mjpeg author (author of mpeg2enc) is also twitching to move to gstreamer as soon as his next release is out. He's also looking at libcodec (codecs.org) as a base library for his next codec project, which will be working with sampeg4 (sorry, don't have a link). With Buck's help, GStreamer has a preliminary DV decoder plugin, and I also wrote a dv1394 source, so we can play DV right from the camera on fast enough machines. There are sufficient problems with the raw1394 subsystem to cause problems though, such as no user-space DMA. Erik Walthinsen <om...@te...> - System Administrator __ / \ GStreamer - The only way to stream! | | M E G A ***** http://gstreamer.net/ ***** _\ /_ |
|
From: Arne S. <ar...@sc...> - 2001-05-05 19:26:54
|
The MJPEG/Linux square <http://sourceforge.net/projects/mjpeg> has a tool that can convert DV AVIs into mpeg files. This is very interesting. Now we can convert DV data easily to mpeg format. I have put up a small article with instructions etc. on my website: http://www.schirmacher.de/arne/dvgrab/ . Arne |
|
From: Stefan L. <Ste...@sn...> - 2001-05-02 21:49:55
|
On Son, 29 Apr 2001, Nobody/Anonymous wrote: > Bugs item #419875, was updated on 2001-04-28 16:41 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=104393&aid=419875&group_id=4393 Hopefully you are subscriber to this list. > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Nobody/Anonymous (nobody) > Assigned to: Nobody/Anonymous (nobody) > Summary: YUV still overloading the lookup tables > > Initial Comment: > In YUY2.c the Ytmp and cbcr_frame values still overload > the lookup tables and produce artifacts when > decompressing car break lights and fluorescent signs at > night. The artifacts are very difficult to see unless > you watch the video in fullscreen. So I think it's best to provide a short 1 frame dv file for download, so that we can view your false decoded frame too. > Also the lookup > tables seem to clamp between 16 and 240. Y values should be clamped to 16 and 235, Cr,Cb values should be clamped to 16 .. 240 (see SMPTE-314 page 22). Y clamp table (line 73) should be set to: else if(i > (235-128)) value = 235; instead of: else if(i > (235-128)) value = 240; > Camcorders > store information in these super black and super white > regions which videographers often need for color > correction and rounding. Could you provide more information about that color correction. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=104393&aid=419875&group_id=4393 > > _______________________________________________ > libdv-dev mailing list > lib...@li... > http://lists.sourceforge.net/lists/listinfo/libdv-dev -- mfg Stefan Lucke (Ste...@sn...) |
|
From: Stefan L. <Ste...@sn...> - 2001-05-02 21:49:54
|
Solved problems are perhaps of public interest ? Stefan Lucke ---------- Forwarded Message ---------- Subject: Re: libdv segfault Date: Wed, 2 May 2001 09:07:43 -0400 From: Christoph Scheurer <ch...@ne...> Hi Stefan, On Wed, May 02, 2001 at 01:03:26PM +0100, Ste...@sn... wrote: > could you please change 'extern void' forward declaration of > quant_248_inverse_XYZ to a 'static void' forward declaration, and > corresponding procedure headers from 'void' to 'static void' > (near end of file quant.c). I just checked everything again and I found the mistake ... pretty dumb. The program I had the problems with also depends on the quicktime4linux library and I had to use a modified version of it to be able to link with libdv since quicktime4linux incorporates an old version of libdv. When I reconfigured the new CVS checkout, configure picked up the unmodified version of quicktime and that caused the problems. Anyway, I think your extern -> static change still makes sense and everything works well with it. Thanks, Christoph ------------------------------------------------------------------------------ Christoph Scheurer e-mail: ch...@fe... Department of Chemistry WWW: http://markov.chem.rochester.edu/chris University of Rochester P.O. Box RC 270216 phone: +1-716-275-8289 Rochester, NY 14627-0216 +1-716-242-0989 (private) USA Fax: +1-716-473-6889 ------------------------------------------------------------------------------ GnuPG public key: http://markov.chem.rochester.edu/chris/key.html ------------------------------------------------------- -- mfg Stefan Lucke (Ste...@sn...) |
|
From: Christoph S. <ch...@ne...> - 2001-05-01 14:58:04
|
Hello,
I extended lav2yuv from the MJPEG project on sourceforge to read DV files. It
worked nicely so far, but now I ran into a problem with libdv and I don't
know where it really comes from. I am using libdv-0.8 and I built the modified
lav2yuv with this version before and didn't have any problems.
I built lav2yuv again from a clean CVS checkout which went without problems
but when I try to use lav2yuv with DV input I receive a Segmentation fault. I
ran it through the debugger and got a surprising result: the segmentation
fault is from within libdv which never occured before. The debugger says the
problem is in:
dv_quant_init () at quant.c:153
/usr/local/src/libdv-0.8/libdv/quant.c:153:3119:beg:0x8058ea4
and the offending line in the source is:
quant_248_inverse = quant_248_inverse_std;
Does anybody know what could cause the problem? I am running Debian woody with
gcc 2.95.3 and nasm version 0.98.
Any help is appreciated,
Christoph
------------------------------------------------------------------------------
Christoph Scheurer e-mail: ch...@fe...
Department of Chemistry WWW: http://markov.chem.rochester.edu/chris
University of Rochester
P.O. Box RC 270216 phone: +1-716-275-8289
Rochester, NY 14627-0216 +1-716-242-0989 (private)
USA Fax: +1-716-473-6889
------------------------------------------------------------------------------
GnuPG public key: http://markov.chem.rochester.edu/chris/key.html
----- End forwarded message -----
------------------------------------------------------------------------------
Christoph Scheurer e-mail: ch...@fe...
Department of Chemistry WWW: http://markov.chem.rochester.edu/chris
University of Rochester
P.O. Box RC 270216 phone: +1-716-275-8289
Rochester, NY 14627-0216 +1-716-242-0989 (private)
USA Fax: +1-716-473-6889
------------------------------------------------------------------------------
GnuPG public key: http://markov.chem.rochester.edu/chris/key.html
|
16 messages has been excluded from this view by a project administrator.
