Toresbe and I are going to try to write some sort of basic live DV switching/mixing software, in case Flumotion isn't able to do this job in time. Toresbe has created a project on Alioth for this. There's no guarantee we can have this working in time either, but we do have last year's software as a fallback position. We need to establish requirements and priorities for the mixer software before we get going. I think there should be a short meeting for this on IRC. This will not be a full team meeting; it's only for discussing this software. My proposed time is Thursday 20:00 UTC, but I realise this is short notice so am open to alternatives. The requirements I can think of are: 1 Essential 1.1. The mixer must receive at least 2 real-time DV streams over an Ethernet network. 1.2. A separate program must capture a DV stream from a camera over Firewire and send it using the appropriate protocol. (Initially the protocol is raw DV over TCP/IP and we use dvgrab and netcat.) 1.3. A separate program must read a DV stream from a file and send it using the appropriate protocol in real-time. (This will be needed during testing for simulation of a second camera.) 1.4. The mixer must allow the operator to select between video streams. 1.5. The mixer must display the selected video stream to the operator at full resolution and full frame rate, no more than about 250 ms after capture time. (Is this reasonable? We could stretch the latency requirement if the operator hears similarly delayed audio.) 1.6. The mixer must display thumbnails of all received video streams to the operator at 10 fps, synchronised with the selected stream. These may be grayscale rather than colour. 1.7. The mixer must save audio from selected audio stream and video from selected video stream to a file in common format (probably raw DV). The selection of the audio stream can be static as we expect it to be mixed separately and fed to a single camera. (Encoding and streaming should be done in a separate program using the file.) 1.8. The selection of the video stream must be visible in the displayed and saved stream within about 100 ms after the frame displayed when the operator changes selection. 1.9. The saved audio stream must be identical to the received audio stream. 1.10. The saved video stream must be synchronised with the received video stream, to within 1 frame time. The received video frames may be dropped or doubled only where it is necessary to maintain synchronisation. 1.11. The mixer must be controllable using only the keyboard. (We don't know whether there will be space for a mouse, and pressing a key is faster than using a mouse to press an on-screen button.) (What are the likely hardware specifications? We need to know these to tell whether we're really meeting the latency and frame rate requirements.) 2 Desirable 2.1. The mixer should receive DV streams over UDP/IP. (I believe TCP's slow recovery from dropped packets will not be acceptable.) This would imply we also need a new program to bridge between Firewire and Ethernet. 2.2. The mixer should handle arbitrary numbers of streams within processor limitations. 2.3. The mixer should allow picture-in-picture mixing - one video stream full size and another scaled by a fixed amount and overlaid on one corner. 3 Wishlist 3.1. The mixer could allow fading between two video streams. 3.2. The mixer could allow fading to a solid colour. 3.3. The mixer could allow (sub)titles to be overlaid on the video stream. Maybe I should put these on a wiki and we can then revise them during the meeting? Ben. -- Ben Hutchings friends: People who know you well, but like you anyway.
Attachment:
signature.asc
Description: This is a digitally signed message part