Andrew Church wrote:
> I've done a partial rewrite of import_nuv in CVS HEAD that checks the
>timestamps and clones frames as needed to keep sync; could you try it out
>and let me know if it works?
>
> --Andrew Church
> [EMAIL PROTECTED]
> http://achurch.org/
>
>
>
Andrew:
Various problems:
In file included from import_nuv.c:183:
../../libtc/tc_lzo.h:13:23: lzo/lzo1x.h: No such file or directory
../../libtc/tc_lzo.h:14:25: lzo/lzoutil.h: No such file or directory
import_nuv.c: In function `rtjpeg_vid_get_frame':
import_nuv.c:351: error: `lzo_uint' undeclared (first use in this function)
import_nuv.c:351: error: (Each undeclared identifier is reported only once
import_nuv.c:351: error: for each function it appears in.)
import_nuv.c:351: error: syntax error before "len"
import_nuv.c:359: warning: implicit declaration of function
`lzo1x_decompress'
import_nuv.c:360: error: `len' undeclared (first use in this function)
import_nuv.c:360: error: `LZO_E_OK' undeclared (first use in this function)
make[3]: *** [import_nuv.lo] Error 1
This was trivial: I added a couple of "#ifdef HAVE_LZO" lines around the
offending code.
However, I then ran into a real problem:
w32dll.c: In function `modify_ldt':
w32dll.c:1043: warning: implicit declaration of function `__syscall_return'
w32dll.c:1043: error: syntax error before "int"
w32dll.c: In function `w32dll_init_fs':
w32dll.c:1055: error: storage size of `ldt' isn't known
w32dll.c:1055: warning: unused variable `ldt'
make[3]: *** [w32dll.lo] Error 1
I couldn't get around this. I'm compiling on Fedora Core 2, and I guess
my 'glibc' doesn't have certain magic support macros.
--------------------------
So, what I did next was to copy your new (but hand-fixed) import_nuv.c
into the 1.0.2 stable-release sources which *do* compile for me. I had
to comment out the tc_log_{warn,error,msg} calls, and had to rename
"ac_memcpy" to "tc_memcpy". But it compiled. The results were kinda strange:
Please download ftp://tallyho.bc.nu/pub/steve/nuvsyncproblem2.mpg
Basically, the audio sync seems to be holding, but much of the time you
can't see that because the picture freezes. Looks like your "repeat the
previous frame" code is working just a bit too enthusiastically and
doesn't let go once it spots a problem!
Also, the U and V components seem to be swapped.
Steve.
PS: Ironic that I chose a crazy Japanese game show to illustrate the
point isn't it.....
