Folks:
I believe I have my first contribution to make!
Multipart .nuv files contain records whose timestamps reflect the time
since the capture started, not necessarily zero if this is a later file
of a multipart capture. I've attached a patch which allegedly fixes
this. It works for me, though I've only had occasion to use it once or
twice.
Maybe some guru with CVS commit permissions would review it and
contribute it?
It's for version 1.1.x
See attachment.
Thanks in advance
Steve Hosgood.
--- import_nuv.c.old 2006-12-12 16:30:56.000000000 +0000
+++ import_nuv.c 2007-01-23 14:05:41.000000000 +0000
@@ -231,6 +231,7 @@
{
PrivateData *pd;
double timestamp;
+ static offset = -1;
uint8_t *audiobuf = NULL;
int audiolen = 0;
@@ -379,11 +380,19 @@
/* Check the timecode on the video frame and read or clone as needed. */
timestamp = (double)pd->framehdr.timecode / 1000;
+
+ if (offset == -1)
+ /* first time only, remember first timestamp seen */
+ /* multipart .nuv files start at non-zero timestamps */
+ /* earlier timestamps are in previous parts of the multipart set */
+ /* S.Hosgood, Dec 2006 */
+ offset = timestamp;
+
if (verbose & TC_DEBUG) {
tc_log_msg(MOD_NAME,"<<< frame=%d[%.3f] timestamp=%.3f >>>",
pd->framenum, pd->framenum/pd->fps, timestamp);
}
- if (timestamp < (pd->framenum+0.5)/pd->fps) {
+ if (timestamp - offset < (pd->framenum+0.5)/pd->fps) {
if (pd->framehdr.comptype != 'L') { // 'L'ast frame: keep saved data
if (pd->framehdr.packetlength > 0) {
if (read(pd->fd, pd->saved_vframe, pd->framehdr.packetlength)
