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: Brandie M. <b_m...@tv...> - 2004-10-11 15:40:32
|
<html><ejlwhntdtjovio> Thi<ewdzranxbatladf>s week on<tuujotvdmhttumg>ly: F.<ekfeczzdgrhhslb>R<eoxvmkgbwfbz>E<xakgboedbtdma>E GE<gjorcayzcnbkp>N.ER<swtzdhicgcjbia>lC VlA<tzabgcudevnqvl>G.RA<p> Cover the ship<ektxqftdmdnqc>pin<pmlsyomcfjl>g, and we'll send you<br>our product at N<ercwvzqdcigzix>0 C0<eyzakzxdsen>S<zbzqhnwcjgnzm>T to pr<eusyqmpdwcskvcw>ove its effe<txmsirkbwrmlbvr>ctiven<ectaropctvobt>es<eijorkodvfbryhb>s.<p><br> <a href="http://bkgmnkbufpjg.ggg-apple.com/free/?gagabob"><fuzrlmccypltq>W0<etwztyxvbai>N'T LA<shkzpyvcnxcl>ST..<qesxtxyruindcb>.HUR<eppsmclcwmttz>R<elrhvigibqbk>Y</a> <p><erywryikgyhatb><br><evdhuxcdfsscv><br><eimgkdtyujssb><br><hjzolgizsjvtn><br><br><gwzuhevhykg><br><br><dyriwmhbbvri><br> <a href="http://yoxdapdmjg.ggg-apple.com/rm.html"><guqrsdvdiah>Sto<fissfohbuqi>p pr<gmpllgxdipwcxvd>omo<zhqabkddmtychn>s.</a><oayvwzvtofarhqx> </html> |
|
From: SourceForge.net <no...@so...> - 2004-10-07 21:00:03
|
Bugs item #1042555, was opened at 2004-10-07 22:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1042555&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marek Szyprowski (march123) Assigned to: Nobody/Anonymous (nobody) Summary: Endianess problem in audio encoding Initial Comment: I found a nasty bug related to audio encoding, when used on big-endian (PowerPC) machine. dv_decode_full_audio() function fill audio buffer in cpu native byte order, however dv_encode_full_audio() requires audio buffer to be in little-endian byte-order. This is the real problem, because such construction as: dv_decode_full_audio() do something with audio dv_encode_full_audio() is often used in tools for processing DV files (like Kino for example). In my opinion both functions should work on buffers in same byte-order. Regards, Marek Szyprowski <ma...@st...> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1042555&group_id=4393 |
|
From: Roman S. <rv...@su...> - 2004-09-13 21:10:55
|
On Mon, Sep 13, 2004 at 03:57:35PM -0500, Ben...@ni... wrote: > My intent is to port this to Pharlap (a real-time OS with most of the > win32 API functions) for decoding live DV camera streams. I got it to > compile in MSVC with a few hacks, but I'm decoding at 6 seconds/frame on a > P3 Celeron. Aha! Than, please, try ffmpeg's DV codec. That's exactly the situation where it definitely has an edge against libdv. What's more important, however, is that being a current DV maintainer in ffmpeg I can surely help you with porting. > I tried compiling with MinGW, but I'm having linker issues (with the x86 > functions) when I run configure with the --disable-gtk option (with > --disable-gtk & --disable-asm everything links fine). Another drawback to > MinGW is that a couple of functions (AddAtom, FindAtom, GetAtomName) are > being automatically linked into my DLL and Pharlap does not support these > functions. MinGW seems like an awesome environment, but I'm not very > familiar with the *nix way of doing things, so small roadblocks throw me > off pretty easily. I know that some folks on ffmpeg's mailing list tried to compile ffmpeg with MSVC++ and failed, however, since all you need is just DV codec it will be a much simpler task. But first, let's see how much speed up will an unoptimized (and thus non ASM dependent) ffmpeg give you. Thanks, Roman. |
|
From: <Ben...@ni...> - 2004-09-13 20:57:46
|
Roman Shaposhnick <rv...@su...> Sent by: lib...@li... 09/13/2004 03:27 PM To Ben...@ni... cc lib...@li... Subject Re: [libdv-dev] Compiling libdv with mmx optimizations on win32 On Mon, Sep 13, 2004 at 03:19:03PM -0500, Ben...@ni... wrote: > Has anyone attempted to move the AT&T syntax assembly to Intel style > assembly with any success? Or more importantly, has anyone compiled libdv > with MSVC (or any other win32 compiler besides Cygwin) with the MMX and > assembly code optimizations? And why would you be needing this ? Do you have any particular port in mind? Will MinGW be good enough ? Thanks, Roman. My intent is to port this to Pharlap (a real-time OS with most of the win32 API functions) for decoding live DV camera streams. I got it to compile in MSVC with a few hacks, but I'm decoding at 6 seconds/frame on a P3 Celeron. I looked at the assembly, but I get pretty lost. I was hoping the x86 optimized code would help bump that up to 10-15 frames/second. I tried compiling with MinGW, but I'm having linker issues (with the x86 functions) when I run configure with the --disable-gtk option (with --disable-gtk & --disable-asm everything links fine). Another drawback to MinGW is that a couple of functions (AddAtom, FindAtom, GetAtomName) are being automatically linked into my DLL and Pharlap does not support these functions. MinGW seems like an awesome environment, but I'm not very familiar with the *nix way of doing things, so small roadblocks throw me off pretty easily. Hopefully this will shed more light on the subject...Thanks, Ben |
|
From: Roman S. <rv...@su...> - 2004-09-13 20:27:50
|
On Mon, Sep 13, 2004 at 03:19:03PM -0500, Ben...@ni... wrote: > Has anyone attempted to move the AT&T syntax assembly to Intel style > assembly with any success? Or more importantly, has anyone compiled libdv > with MSVC (or any other win32 compiler besides Cygwin) with the MMX and > assembly code optimizations? And why would you be needing this ? Do you have any particular port in mind? Will MinGW be good enough ? Thanks, Roman. |
|
From: <Ben...@ni...> - 2004-09-13 20:19:18
|
Has anyone attempted to move the AT&T syntax assembly to Intel style assembly with any success? Or more importantly, has anyone compiled libdv with MSVC (or any other win32 compiler besides Cygwin) with the MMX and assembly code optimizations? Thanks for any insight, Ben |
|
From: Dan D. <da...@de...> - 2004-08-31 21:23:54
|
On Tue, 2004-08-31 at 14:30, Rivulet wrote: > Dear developers, > I would like to add dv25 on a TI DM642 evaluation board and I have the > following questions please: > > 1- can I use the libdv source code to build an image for the DM642 TI > board, if yes how? yes, as long as you obey the license. IOW, if you distribute a binary version, then also distribute the source or be prepared to supply it on demand. I can not tell you how to build an image for that TI board, and I doubt anyone else here can or will either. Besides, that is your job, no? ;-) > 2- I can capture video using TI's drivers, how can I integrate the > buffers with libdv for input/output? Are these DV encoded buffers that you want to decode or some uncompresed that you want to encode? > 3- was libdv tested with a real-time video feed? Define realtime video feed. It is tested with playing live DV feeds from a FireWire DV device, and it works, but it can only decode in "realtime" if the CPU is fast enough. By "realtime" I mean that it is fast enough to decode and display in X all frames at the source video's framerate (no dropping frames or "backlog"). |
|
From: Andrea a. J. <fro...@ya...> - 2004-08-24 02:55:05
|
Thanks four your reply, Roman. > -- have you tried ffmpeg's DV ? It's known to have > better quality than libdv. Both in terms of PSNR and in terms of green > shift of the reiteration. Thanks for the tip, I shall check it out! Jamie. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
|
From: Roman S. <rv...@su...> - 2004-08-23 18:13:45
|
On Mon, Aug 23, 2004 at 06:39:35AM -0700, Andrea and Jamie wrote: > Hello, > > I would like to bounce an idea off of this list... > > What would libdv developers think of adding the ability to encode a dv frame using the following > inputs: First of all, as far as I know there's no active development of libdv anymore. Just a very helpful maintenance. By the way, if this is a wrong perception -- I'd be happy to listen to anyone who begs to disagree :-) Anyhow... > - The original dv frame from the input file > - the altered frame buffer, in RGB or YUV or whatever > - and, a change list that details what regions of the frame were modified. EG, a list of > rectangles. > > This could provide two big benefits: > - greatly reduced computation in some situations > - The potential for applying some effects with absolutely no loss whatsoever to most of the video > frame. Unfortunately it ain't so simple, as they say. Here's why: minimal coding unit in DV video is something called video segment, which is a collection of 5 MacroBlocks (8x8 blocks of pixels) taken from very distinct places in the frame. For example video segment #1 could have its 5 MacroBlocks arranged like this: +--------------------------- |X | X | | | X | | X | X Given the fact that most of the overlays will be three or four times larger that 8x8 and they will be most likely off kilter given the video segment pattern we will have to reencode quite a few 8x8 blocks. Which brings us to the next question -- quality. Now, the perceived quality of an image parts of which has been reencoded and others stayed the same is usually worse than "uniformally" degraded image. At least this has been my experience. Speaking of quality -- have you tried ffmpeg's DV ? It's known to have better quality than libdv. Both in terms of PSNR and in terms of green shift of the reiteration. Thanks, Roman. |
|
From: Andrea a. J. <fro...@ya...> - 2004-08-23 13:39:42
|
Hello, I would like to bounce an idea off of this list... What would libdv developers think of adding the ability to encode a dv frame using the following inputs: - The original dv frame from the input file - the altered frame buffer, in RGB or YUV or whatever - and, a change list that details what regions of the frame were modified. EG, a list of rectangles. This could provide two big benefits: - greatly reduced computation in some situations - The potential for applying some effects with absolutely no loss whatsoever to most of the video frame. If, for example, you were overlaying a small logo into the corner of your video, then only the affected blocks would need to be re-encoded. Unaffected blocks can simply be copied. I can see two big problems, at the moment: - The layout of the DV blocks means reduced 'probability' of having unaffected blocks. - Affected blocks may need more bit allocation than the blocks they are replacing, and would therefore have to 'borrow' some from other blocks. Perhaps this is too difficult to do, or maybe it would not be as useful as I think, but there it is , for what it's worth! Jamie Strachan _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush |
|
From: Roman S. <rv...@Su...> - 2004-08-17 01:56:10
|
On Mon, Aug 16, 2004 at 06:48:35PM -0700, Andrea and Jamie wrote: > >> Just wondering if anyone might suggest how to detect the field order of a frame or file. > >> (I suggested adding a function to the API to return this information under 'features'). > > > > There's one and only one field order possible for DV -- bottom field first. > > Or are you talking about smth. else ? > > I have been using MainConcept's MainActor, and one of the export options is to specify > progressive, LFF, or UFF, when exporting to NTSC DV Type 1, and so I assumed that DV supported > upper first. No. DV does not support upper first. That doesn't mean that you can't generate such a file, but you'll have a pretty hard time convincing hardware and other software to play it properly. As for the progressive, it has always been a mystery to me. I think that different hardware encoders flag progressive frames differently. But then again, I don't have an access to the IEC DV standard to verify that. Thanks, Roman. |
|
From: Andrea a. J. <fro...@ya...> - 2004-08-17 01:51:05
|
>> Just wondering if anyone might suggest how to detect the field order of a frame or file. >> (I suggested adding a function to the API to return this information under 'features'). > > There's one and only one field order possible for DV -- bottom field first. > Or are you talking about smth. else ? I have been using MainConcept's MainActor, and one of the export options is to specify progressive, LFF, or UFF, when exporting to NTSC DV Type 1, and so I assumed that DV supported upper first. Thanks for the reply! Jamie. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Roman S. <rv...@su...> - 2004-08-17 00:22:12
|
On Mon, Aug 16, 2004 at 09:38:28AM -0700, Andrea and Jamie wrote: > Hi, > > Just wondering if anyone might suggest how to detect the field order of a frame or file. > (I suggested adding a function to the API to return this information under 'features'). There's one and only one field order possible for DV -- bottom field first. Or are you talking about smth. else ? Thanks, Roman. |
|
From: Andrea a. J. <fro...@ya...> - 2004-08-16 16:38:35
|
Hi, Just wondering if anyone might suggest how to detect the field order of a frame or file. (I suggested adding a function to the API to return this information under 'features'). I want to display the fields, one at a time, and if they're not shown in the correct order, it can look pretty horrible! Thanks, Jamie Strachan. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
|
From: Steven M. S. <sm...@2B...> - 2004-08-07 18:58:52
|
On Fri, 6 Aug 2004, Dan Dennedy wrote: > On Fri, 2004-08-06 at 12:22, Steven M. Schultz wrote: > > > Thing to do is find a way from the commandline to forcibly tell > > MPlayer what a file is (i.e. bypass the file probing/autodetect logic). > > I was going to suggest that. mplayer has so many options, surely one > allows explicit format. Also, I think players should give MIME types It took some detailed reading of the MPlayer manpage and a bit of grep'ing around in the MPlayer source code but I found the magic option. mplayer -demuxer 22 Sequence1.dv Once you know the demuxer number that's compiled in you can specify it numerically. RAW DV is 22 so "-demuxer 22" did the trick. Cheers, Steven Schultz |
|
From: Dan D. <da...@de...> - 2004-08-06 22:28:48
|
On Fri, 2004-08-06 at 12:22, Steven M. Schultz wrote: > Thing to do is find a way from the commandline to forcibly tell > MPlayer what a file is (i.e. bypass the file probing/autodetect logic). I was going to suggest that. mplayer has so many options, surely one allows explicit format. Also, I think players should give MIME types priority over probing and other magic. Sometimes, like in a raw pipe, there simply is no mime type, and it requires explicit help. |
|
From: Roman S. <rv...@Su...> - 2004-08-06 20:37:48
|
On Fri, Aug 06, 2004 at 09:22:39AM -0700, Steven M. Schultz wrote: > > On Fri, 6 Aug 2004 Rom...@Su... wrote: > > > Why use libdv for that ? ffmpeg's DV support is your friend, really. > > Even in MPlayer :-) </self promoting> > > You'd have to ask the MPlayer folks about that ;) As a matter of fact, I see ffmpeg's DV codec mentioned earlier in codec.conf from the MPlayer-1.0pre5 than libdv codec. What version of MPlayer are you using? > > Yes there are. However, they are few and far between. And I suspect they > > Or sanity checking on the fields in the header perhaps? Yes, that could be possible, in theory -- but will require some hacks which I judge to be more than 15-minutes ones. :-) > > can be present in all sorts of "other" formats as well. So your best option > > would be to move DV codec to the end of MPlayer's codec description list. > > The problem there is that the MPEG-PS check sees the raw DV file > (created by Final Cut) as a "encrypted VOB file" before the DV check > is made: [ skiped... ] > But if I move the DV check before the MPEG-PS check then MPEG-1 > files are accepted by libdv's header parsing. > > Thing to do is find a way from the commandline to forcibly tell > MPlayer what a file is (i.e. bypass the file probing/autodetect logic). Aha. I see your problem now. Well, I've just asked about native MPlayer demuxer for DV -- may be Arpi will accept that. Thanks, Roman. |
|
From: Steven M. S. <sm...@2B...> - 2004-08-06 16:25:00
|
On Fri, 6 Aug 2004 Rom...@Su... wrote:
> Why use libdv for that ? ffmpeg's DV support is your friend, really.
> Even in MPlayer :-) </self promoting>
You'd have to ask the MPlayer folks about that ;)
> Yes there are. However, they are few and far between. And I suspect they
Or sanity checking on the fields in the header perhaps?
> can be present in all sorts of "other" formats as well. So your best option
> would be to move DV codec to the end of MPlayer's codec description list.
The problem there is that the MPEG-PS check sees the raw DV file
(created by Final Cut) as a "encrypted VOB file" before the DV check
is made:
system stream synced at 0x21BC6A (0)!
{ERROR5,c=217}
{ERROR5,c=213}
Encrypted VOB file! Read DOCS/HTML/en/dvd.html.
{PTS_err:1}
==> Found audio stream: 23
{ERROR5,c=223}
Encrypted VOB file! Read DOCS/HTML/en/dvd.html.
==> Found audio stream: 20
Encrypted VOB file! Read DOCS/HTML/en/dvd.html.
==> Found audio stream: 4
{ERROR5,c=233}
{PTS_err:1}
Encrypted VOB file! Read DOCS/HTML/en/dvd.html.
But if I move the DV check before the MPEG-PS check then MPEG-1
files are accepted by libdv's header parsing.
Thing to do is find a way from the commandline to forcibly tell
MPlayer what a file is (i.e. bypass the file probing/autodetect logic).
Cheers,
Steven Schultz
|
|
From: <Rom...@Su...> - 2004-08-06 06:20:14
|
>Hi - > > Are there any additional "sanity checks" that can be made in > dv_parse_header() to make sure the file is really a DV stream? > > The reason I ask is that I'm having trouble getting MPlayer to > recognize some raw DV files. Why use libdv for that ? ffmpeg's DV support is your friend, really. Even in MPlayer :-) </self promoting> > My assumption was that if dv_parse_header > was able to parse a header then it must be a raw dv file - that works > as long as the file is a DV file. > > MPlayer's heuristics are to march thru each demuxer's probe/header > routine until one returns success. This worked until I tried to play > a MPEG-ES file and dv_parse_header() claimed to be able to parse it! > > Are there more "must be 0", "must be 1" types of fields, etc that > dv_parse_header() could check? Yes there are. However, they are few and far between. And I suspect they can be present in all sorts of "other" formats as well. So your best option would be to move DV codec to the end of MPlayer's codec description list. Thanks, Roman. |
|
From: Steven M. S. <sm...@2B...> - 2004-08-06 04:34:53
|
Hi - Are there any additional "sanity checks" that can be made in dv_parse_header() to make sure the file is really a DV stream? The reason I ask is that I'm having trouble getting MPlayer to recognize some raw DV files. My assumption was that if dv_parse_header was able to parse a header then it must be a raw dv file - that works as long as the file is a DV file. MPlayer's heuristics are to march thru each demuxer's probe/header routine until one returns success. This worked until I tried to play a MPEG-ES file and dv_parse_header() claimed to be able to parse it! Are there more "must be 0", "must be 1" types of fields, etc that dv_parse_header() could check? Cheers, Steven Schultz |
|
From: William R S. <wi...@so...> - 2004-07-26 20:30:01
|
I've configured libdv (from CVS this morning, and 0.103) and installed it. I used the following command line to 'configure': ./configure --with-pal-yuv=YV12 --prefix=/usr/local/stow/libdv-cvs I'm decoding a 720x576 25fps PAL DV stream. I can supply sample footage if required. The planar YUV output didn't seem to be working correctly for me -- the U plane always comes up empty, so I wrote a short app to test this. The content of the compressed_frame buffer (which holds the raw DV frame) is, I believe, correct -- YUY2 decoding works fine. The app is very simple: It allocated a 720x576 buffer for each plane and then dumps the buffers to disk so I can see what libdv wrote into them. Each buffer is initialised so all bytes are 0x80. The U, V buffers are four times the size they should be; this is because I was concerned that libdv might be writing the U, V plans at an offset from the pointer passed in (this turned out not to be the case). // setup, etc. uint8_t *outframe_ptrs[3]; int outframe_pitches[3]; char *y_buffer = (char*)malloc(720*576); char *u_buffer = (char*)malloc(720*576); char *v_buffer = (char*)malloc(720*576); memset(y_buffer, 128, 720*576); memset(u_buffer, 128, 720*576); memset(v_buffer, 128, 720*576); outframe_ptrs[0] = (uint8_t*)y_buffer; outframe_ptrs[1] = (uint8_t*)u_buffer; outframe_ptrs[2] = (uint8_t*)v_buffer; outframe_pitches[0] = 720; outframe_pitches[1] = 360; outframe_pitches[2] = 360; dv_decode_full_frame(dv_handle, (uint8_t*)compressed_frame, e_dv_color_yuv, outframe_ptrs, outframe_pitches); char rubbish[64]; int fd; sprintf(rubbish, "frame%04d_y.raw", frame_number); fd = open(rubbish, O_WRONLY | O_CREAT, 0664); write(fd, y_buffer, 720*576); close(fd); free(y_buffer); sprintf(rubbish, "frame%04d_u.raw", frame_number); fd = open(rubbish, O_WRONLY | O_CREAT, 0664); write(fd, u_buffer, 720*576); close(fd); free(u_buffer); sprintf(rubbish, "frame%04d_v.raw", frame_number); fd = open(rubbish, O_WRONLY | O_CREAT, 0664); write(fd, v_buffer, 720*576); close(fd); free(v_buffer); I then converted each plane from raw to PNG format: rawtopgm -bpp 1 720 576 frame0990_y.raw | pnmtopng > frame0990_y.png Same for U, V. Of course the U and V planes should be only 360 pixels wide, but I didn't correct for this. Silly me. These are the 990th frames from the video: http://sowerbutts.com/tmp/frame0990_y.png (198KB) http://sowerbutts.com/tmp/frame0990_u.png (1.8KB) http://sowerbutts.com/tmp/frame0990_v.png (34KB) Y looks as I would expect. V looks correct, too (I should've halved the width of the PNG -- doh!) but U looks screwey. It's mostly blank, but there is a little data in the very first row. Any ideas, libdv gurus? I'm stuck. Thanks, Will _________________________________________________________________________ William R Sowerbutts wi...@so... "Carpe post meridiem" http://sowerbutts.com main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));} |
|
From: Richard B. <ba...@th...> - 2004-07-23 22:45:54
|
I've fixed this problem on my system, and others have arisen, all pertaining to the changes for 64-bit assembly. I've included the new errors below. I'm going to continue working on it, but if anyone else knows better what to do, please stop me ;). On Fri, 2004-07-23 at 18:25, Richard Baverstock wrote: > A few things: >=20 > 1) MMX is not tested for support, since ARCH_X86 does not get defined > (dv.c has tests to see if ARCH_X86 is defined to include mmx.h and > mmx_ok();) >=20 > 2) When trying to compile, after putting "#define ARCH_X86 1" into > config.h, the following compile error results: >=20 > baver@moses libdv $ make > make all-am > make[1]: Entering directory `/home/baver/Programming/libdv/libdv' > if /bin/sh ../libtool --silent --mode=3Dcompile gcc -DHAVE_CONFIG_H -I. > -I. -I.. -g -O2 -Wall -g -MT dv.lo -MD -MP -MF ".deps/dv.Tpo" -c -o > dv.lo dv.c; \ > then mv -f ".deps/dv.Tpo" ".deps/dv.Plo"; else rm -f ".deps/dv.Tpo"; > exit 1; fi > /tmp/ccvXpLxd.s: Assembler messages: > /tmp/ccvXpLxd.s:131: Error: suffix or operands invalid for `push' > /tmp/ccvXpLxd.s:132: Error: suffix or operands invalid for `push' > /tmp/ccvXpLxd.s:133: Error: suffix or operands invalid for `push' > /tmp/ccvXpLxd.s:135: Error: suffix or operands invalid for `pop' > /tmp/ccvXpLxd.s:141: Error: suffix or operands invalid for `pop' > /tmp/ccvXpLxd.s:246: Error: suffix or operands invalid for `pop' > /tmp/ccvXpLxd.s:247: Error: suffix or operands invalid for `pop' > /tmp/ccvXpLxd.s:248: Error: suffix or operands invalid for `pop' > make[1]: *** [dv.lo] Error 1 > make[1]: Leaving directory `/home/baver/Programming/libdv/libdv' > make: *** [all] Error 2 >=20 >=20 > Any ideas anyone? --=20 Richard Baverstock John 11:25-26 |
|
From: Richard B. <ba...@th...> - 2004-07-23 22:25:45
|
A few things: 1) MMX is not tested for support, since ARCH_X86 does not get defined (dv.c has tests to see if ARCH_X86 is defined to include mmx.h and mmx_ok();) 2) When trying to compile, after putting "#define ARCH_X86 1" into config.h, the following compile error results: baver@moses libdv $ make make all-am make[1]: Entering directory `/home/baver/Programming/libdv/libdv' if /bin/sh ../libtool --silent --mode=3Dcompile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -g -MT dv.lo -MD -MP -MF ".deps/dv.Tpo" -c -o dv.lo dv.c; \ then mv -f ".deps/dv.Tpo" ".deps/dv.Plo"; else rm -f ".deps/dv.Tpo"; exit 1; fi /tmp/ccvXpLxd.s: Assembler messages: /tmp/ccvXpLxd.s:131: Error: suffix or operands invalid for `push' /tmp/ccvXpLxd.s:132: Error: suffix or operands invalid for `push' /tmp/ccvXpLxd.s:133: Error: suffix or operands invalid for `push' /tmp/ccvXpLxd.s:135: Error: suffix or operands invalid for `pop' /tmp/ccvXpLxd.s:141: Error: suffix or operands invalid for `pop' /tmp/ccvXpLxd.s:246: Error: suffix or operands invalid for `pop' /tmp/ccvXpLxd.s:247: Error: suffix or operands invalid for `pop' /tmp/ccvXpLxd.s:248: Error: suffix or operands invalid for `pop' make[1]: *** [dv.lo] Error 1 make[1]: Leaving directory `/home/baver/Programming/libdv/libdv' make: *** [all] Error 2 Any ideas anyone? --=20 Richard Baverstock John 11:25-26 |
|
From: Charles 'B. K. <kr...@ga...> - 2004-07-15 14:41:42
|
Ok, I've re-added AM_MAINTAINER_MODE in cvs. -- Buck On Thu, 2004-07-15 at 06:36, Daniel Kobras wrote: > Moi! > > On Wed, Jul 14, 2004 at 09:31:00AM -0700, Charles 'Buck' Krasic wrote: > > As part of the release, I've made some minior build changes, and > > additions to CVS relating to the build. > > I'm all but happy with disabling AM_MAINTAINER_MODE in configure.ac, > especially as you also added auto-generated files to CVS. Now the order > of checkout determines which auto-generated files are considered more > recent than others. This means several of the autotools might be run > more or less at random during the build sequence. This is prone to > errors, especially when the user's system contains different versions of > the autotools than those used to generate the files in CVS. Please > consider re-adding AM_MAINTAINER_MODE. > > Regards, > > Daniel. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > libdv-dev mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdv-dev |
|
From: Daniel K. <ko...@de...> - 2004-07-15 13:36:33
|
Moi! On Wed, Jul 14, 2004 at 09:31:00AM -0700, Charles 'Buck' Krasic wrote: > As part of the release, I've made some minior build changes, and > additions to CVS relating to the build. I'm all but happy with disabling AM_MAINTAINER_MODE in configure.ac, especially as you also added auto-generated files to CVS. Now the order of checkout determines which auto-generated files are considered more recent than others. This means several of the autotools might be run more or less at random during the build sequence. This is prone to errors, especially when the user's system contains different versions of the autotools than those used to generate the files in CVS. Please consider re-adding AM_MAINTAINER_MODE. Regards, Daniel. |
16 messages has been excluded from this view by a project administrator.
