Gerd Knorr wrote:
> 
> >  The core uses deep buffering to give some latitude to the synch
> >  routines, and absorb any transient latencies.  Until v4l gets
> >  timestamping, the only way to buffer deeply with v4l would be to have a
> >  tight loop CSYNCing frames as soon as possible, and timestamping them,
> >  then copying them into a userspace buffer - which is a hideous waste of
> >  processing power.
> 
> Having a thread which does nothing but CSYNC + gettimeofday() certainly
> helps to get more exact timestamps (one of the reasons why I've moved
> xawtv's compression code to another thread recently).  But you don't
> need to copy the buffer.  The v4l2 API allows up to 32 buffers (and so

I wasn't aware that the v4l2 API put any limits on this?

> does bttv when loaded with gbuffers=32), that should be enouth ...

Yes, but this won't cope with transient latencies.  If the capture
thread doesn't get run for a couple of hundred milliseconds, you can
develop quite a skew in the timestamp - that is why I though of using
"shallow" kernel buffers, and a deep userspace buffer.  But all of this
is pointless (and there just is not 1 completely functional solution). 
The current bttv 0.7.x implementation is timestamping the buffer - why
don't we just add enhanced CSYNC capabilities to get this timestamp back
to the user?

Something like:

struct video_timedbuffer {
        int index;
        unsigned long long timestamp;
// possibly sequence numbers/buffer size/ other usefull information
        int reserved[8]; // for everything we forgot the first time round...
}

And an ioctl VIDIOCSYNC_TIMED which takes a struct video_timedbuffer as
an argument, and will sync the buffer with index "index", and then fill
in the rest of the information.

Or, maybe piggyback it on VIDIOCSYNC, using a negative index to trigger
the extra capabilities (which is nice, as drivers that do not support it
will simply return -EINVAL at this point, and we can fall back to the
traditional interface.

-justin



_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list

Reply via email to