On Sat, 2008-02-16 at 15:24 -0600, Carl Karsten wrote: > > THe biggest problem is that I don't master the v4l2 specs as I should :( > > If the producer whant to enhance the support, the best thing by far is > > to patch import_v4l2.c; a patch against import_v4l.c will be appreciated > > as well, even if it is less useful. Lastly, some hints to improve our > > code bt ourselves will be appreciated as well. > > hmm, looks like none of the people working on my VGA capture project is a > v4l2 > (or v4l) expert :) this is the first time i have ever thought of it. I > will > try to recruit someone. If you know anyone who is also into Python, they may > be > most willing to help (given the material will be Python presentations.) > If you could find some v4l2 spec links or something to direct them to, that > would be good.
The main problem is the I/O model expected by transcode and provided by device. We adopt streaming/mmap I/O model (see source for details): http://v4l2spec.bytesex.org/spec/x5406.htm This model is very often supported by capture cards, but AFAIK rarely supported by USB/webcam stuff. The error messages provided by you seems to confirm that your specific devices doesn't provide it. I've taken a look to sample application, ad looks like it uses some proprietary ioctls. While it is feasible (and desiderable!) to add fallbacks to our import module to try at least one other I/O model froma a v4l device (this will work with some USB webcams hopefully), like that: http://v4l2spec.bytesex.org/spec/c5357.htm#RW I don't want to mess with proprietary extensions, so them must stay out. It is also feasible to craft a new transcode module specifically tailored for such device, but since this is extremely specific, I'll save this option as very last resort. > > No, we lack this. That's one of the biggest source of trobules. A proper > > solution should of course introduce some kind of master time source. > sounds easy enough... :) Yes, that way is pretty easy and this is the first solution I want to merge. The only concern if this solution is flexible enough and capable to handle the bunch of corner cases that transcode e should/must address :) > > timeindex=0 > > timeindex+= frame_time > > frame_time... where should that come from? fixed fps: 1s / fps (PAL example: 1s/25fps -> 40 ms) variable fps: longer discussion :) > I can see passing i, fps, timeindex to the import module, and it can use what > is > best to calculate frame_time. Yes, demuxer/decoders should tag all the frames they are producing with the timestamp, maybe provided by hardware (v4l), maybe extracted from the source material (mpeg?) maybe computed from scratch (avi), maybe read from /dev/magic (:)) Then we should have a synchronization modules that asynchronously receives the frames and delivers a synchronized pair of A/V frames when asked. This pair should be obtained by buffering the frames and by doing the necessary adjustement: - nothing, just buffer, if A/V streams are already synchronized - cloning/dropping frame if some desync happens, and/or - adjusting frame rate if needed (maybe this will lead to troubles?) - adding null A/V frames if one stream ends early or starts later > I considered fpx*i (the frame index) in the controller loop, but that won't > work > for variable fps. AFAIK (but I lack material to test: I live in happy PAL-all-fixed-fps country :), I'll see what mplayer samples archive has to offer) a variable-fps source it is not much more that a source made of segments each one at fixed fps. So the above approach could still work with some extra-machinery to handle fps-change points. > which btw, I found out a bit about: > > (11:28:20 AM) CarlFK: is there a codec that supports a variable fps? > (11:36:01 AM) Rathann: CarlFK: do codecs have a notion of fps? > (11:37:22 AM) CarlFK: Rathann I'm not exactly sure what the term is. file > format? > (11:37:36 AM) Rathann: we say container > (11:38:00 AM) CarlFK: ok, I can see container > (11:38:21 AM) Rathann: CarlFK: certainly nut, mkv and asf. I don't know about > mov. maybe also mpegs (in NTSC lands). > >>>> Why is there both ptr->video_len and video_size ? > >>> See comments in src/framebuffer.h (pasted here) > >> Can you add these two lines to the source? > > Which ones? The quoted above? > yes. just something that reference why there are 2. most everything else > seemed self explanatory. OK, that is already documented in the file that defines the involved structures. Bests, -- Francesco Romani // Ikitt [ Out of memory. ~ We wish to hold the whole sky, ~ But we never will. ]
