Thread: Streaming live video.
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-devel
|
From: Daniel K. <dan...@st...> - 2000-06-02 22:49:53
|
Hi!
As stated in my previous message, I can display live video streams
on-screen using linux1394 and libdv. I'm not too happy about the
implementation though. What's bothering me most is the internal buffering
of iso data in the subsystem. I'd like to drop intermittent frames if my
processing is too slow. However with a naive approach I get the whole
backlog of frames in the buffer (and a klogd screaming badly about
dropping packets). My current workaround is to start/stop iso rcv for
every frame (which makes me yearn for the patch below to be applied
soon...). An alternative approach would be to spawn a seperate thread that
calls raw1394_loop_iterate in a tight loop, and telling the iso handler
just to drop packets when processing is too slow. Both suck. mmapping
/dev/ohci1394 is the proper way to go for OHCI, I think but that's not
really a generic solution. Has anyone thought about this already? Maybe a
'drop' option to start_iso_rcv() (which questionable semantics)?
Daniel.
Index: ohci1394.c
===================================================================
RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v
retrieving revision 1.31
diff -u -r1.31 ohci1394.c
--- ohci1394.c 2000/05/19 16:13:54 1.31
+++ ohci1394.c 2000/06/02 22:42:16
@@ -1420,7 +1420,7 @@
#endif
if (!test_and_set_bit(arg, &ohci->IR_channel_usage)) {
- PRINT(KERN_INFO, ohci->id,
+ DBGMSG(KERN_INFO, ohci->id,
"listening enabled on channel %d", arg);
if (arg > 31) {
@@ -1446,7 +1446,7 @@
spin_lock_irqsave(&ohci->IR_channel_lock, flags);
if (test_and_clear_bit(arg, &ohci->IR_channel_usage)) {
- PRINT(KERN_INFO, ohci->id,
+ DBGMSG(KERN_INFO, ohci->id,
"listening disabled on iso channel %d",
arg);
if (arg > 31) {
--
GNU/Linux Audio Mechanics - http://www.glame.de
GPG Key ID 89BF7E2B - http://www.keyserver.net
|
|
From: <br...@pr...> - 2000-06-05 01:10:02
|
On Jun 3, 0:47, Daniel Kobras wrote: > > As stated in my previous message, I can display live video streams > on-screen using linux1394 and libdv. I'm not too happy about the > implementation though. What's bothering me most is the internal buffering > of iso data in the subsystem. I'd like to drop intermittent frames if my > processing is too slow. It might be useful to look at the model used by the SGI digital media libraries for real-time streamed data (this applies to analog video I/O e.g. on the O2, not sure what they do in their 1394 library for iso transfers). They use a circular buffer with a fixed size (i.e. frames) and incoming data just keeps being written around the circle. The kernel/library gives you an event (select'able via a file descriptor) when each new frame arrives, you then use the mmapped frame data as you wish. It's up to you to use the data quickly enough to avoid overflow - if it looks like you're running behind, you can opt to skip some frames in the buffer. I believe you tell the library when you start and finish using the data from a frame, which allows the detection of overflows as well as preventing an 'in use' frame from being overwritten. It works well with their UST/MSC system, which assigns a 64-bit nanosecond accuracy timestamp (relative to machine reset time) and a 'media count' (i.e. frame count) to each incoming media unit (i.e. frame) around the circular buffer, so you can accurately match up similarly-labelled incoming audio, detect dropped frames, etc. Outgoing data can also be accurately synced to absolute time and/or other media types. In the case of 1394/DV, you would also want to associate DV timecode and 'time of day' timestamps to incoming frames. I'd be interested to hear if there is any movement in these directions in the Linux 1394 or Video4Linux camps... I hope this is not too far off topic, and might give some inspiration to Linux 1394 developers. Regards, Brian. -- -- ----------------------------------- Brian Murray Proximity Pty Ltd http://www.proximity.com.au/~brian/ ----------------------------------- |
|
From: Sebastien R. <Seb...@sy...> - 2000-06-08 23:23:54
|
>>>>> "Brian" == Brian Murray <br...@pr...> writes: Brian> On Jun 3, 0:47, Daniel Kobras wrote: >> As stated in my previous message, I can display live video streams >> on-screen using linux1394 and libdv. I'm not too happy about the >> implementation though. What's bothering me most is the internal buffering >> of iso data in the subsystem. I'd like to drop intermittent frames if my >> processing is too slow. Brian> It might be useful to look at the model used by the SGI digital media Brian> libraries for real-time streamed data (this applies to analog video I/O Brian> e.g. on the O2, not sure what they do in their 1394 library for iso Brian> transfers). Brian> They use a circular buffer with a fixed size (i.e. frames) and incoming Brian> data just keeps being written around the circle. The kernel/library Brian> gives you an event (select'able via a file descriptor) when each new Brian> frame arrives, you then use the mmapped frame data as you wish. It's up Brian> to you to use the data quickly enough to avoid overflow - if it looks Brian> like you're running behind, you can opt to skip some frames in the Brian> buffer. I believe you tell the library when you start and finish using Brian> the data from a frame, which allows the detection of overflows as well Brian> as preventing an 'in use' frame from being overwritten. The current ohci dma mmap system is very similar. You have a ring buffer and frame completion are signaled to user space. However when a frame buffer is full, is is removed from the ring. It is inserted back in by the user app when it has finished processing it. The dma prog discard incoming video data if the ring buffer is empty. Detecting dropped frame could easily been done by the user app using time stamping of some sort. Brian> It works well with their UST/MSC system, which assigns a 64-bit Brian> nanosecond accuracy timestamp (relative to machine reset time) and a Brian> 'media count' (i.e. frame count) to each incoming media unit Brian> (i.e. frame) around the circular buffer, so you can accurately match up Brian> similarly-labelled incoming audio, detect dropped frames, etc. Outgoing Brian> data can also be accurately synced to absolute time and/or other media Brian> types. In the case of 1394/DV, you would also want to associate DV Brian> timecode and 'time of day' timestamps to incoming frames. I am not familiar with the DV format, but isn't there already some kind of timestamp encoded in the DV frame already ? -- Sebastien Rougeaux RSISE, The Australian National University |
|
From: <br...@pr...> - 2000-06-09 11:36:56
|
On Jun 9, 9:19, Sebastien Rougeaux wrote: > > Brian> It works well with their UST/MSC system, which assigns a 64-bit > Brian> nanosecond accuracy timestamp (relative to machine reset time) and a > Brian> 'media count' (i.e. frame count) to each incoming media unit > Brian> (i.e. frame) around the circular buffer, so you can accurately match up > Brian> similarly-labelled incoming audio, detect dropped frames, etc. Outgoing > Brian> data can also be accurately synced to absolute time and/or other media > Brian> types. In the case of 1394/DV, you would also want to associate DV > Brian> timecode and 'time of day' timestamps to incoming frames. > > I am not familiar with the DV format, but isn't there already some kind of > timestamp encoded in the DV frame already ? I'm not familiar either, but I understand it has an hh:mm:ss:ff timecode or equivalent, as well as an (optional?) time-of-day timestamp so camcorders no longer need to burn it into the video image. The UST/MSC stuff is especially meaningful when capturing from analog sources which don't have their own inherent timestamp. The SGI effectively assigns a timestamp to the video stream as soon as the signal crosses the RCA jack, so there is an absolute time basis with which to relate other incoming/outgoing video, audio, midi events, serial port characters, keypresses etc. (e.g. you can specify that each serial character is to be transmitted at a specific UST time). I only bring it up because at some stage Linux may want a systemic view of media timestamping, and I thought I'd throw it into the melting pot now ... Cheers Brian. -- -- ----------------------------------- Brian Murray Proximity Pty Ltd http://www.proximity.com.au/~brian/ ----------------------------------- |
Thanks for helping keep SourceForge clean.
X