Talk:Recorder

The most important with recorder - avoid frame drops (maybe something can be doen with network buffering) and control them using timestamps. And the recorder better provide managable files (under 2GB), but with zero drops between them.

See also previous talks about timestamps and recorder.

1. We must try to make ogg-mjpeg file and test is it compatible with existent applications.
2. It is better to use own optimized rtp receiver
3. It must be small standalone application without GUI. Use only stdin/stdout and files for output.
4. It should have simple control interface with text format as mplayer in slave mode. One command on line. Command are:
   1. pause
   2. quit
5. Command line arguments:
   1. multicast ip-adress
   2. multicast port
   3. [maximum number of frames]
   4. frames, time or length limits for file
   5. output to stdout
   6. template for file names (see GenReS for compatibility)

At prealpha version can be skipped control interface, cutting and templates for filenames.

---

On ftp://xeon.elphel.com/landy uploaded binary precompiled and source archive ElphelOgm.tgz - filter for receive RTP stream and dump it to OGM file. For example,

./ElphelOgm -a <address> -p <port> -f <fps> > file.ogm

it is dumping stream into file.ogm . More options ./ElphelOgm -h. It is first version(alpha) and has problem with streamers alexlp, khlut - but working with landy's streamer. May be different structure MJPEG stream(I don't know)? Utility are multithreaded and have two thread:

 first, for read RTP stream and put packets to list
 second, for get data from list and put it into OGG container.

Priority both of them thread can be set. By default using SCHED_OTHER dispatch, both thread have same priority. You can select SCHED_FIFO or SCHED_RR real-time dispatch and separate priority for threads(different for receiver and dumper), but utility must be started by root or you can set stiky-bit for it(for nonprivileged users).

Next, size of output file limited by file system on host. If we can writing files more 2Gb, we will be have limits inside container. It is limited by granulepos and packetno(internal variables in OGG container for logical stream). But we can write next stream(logical stream in OGG container, RTP stream are same) with same serialno. Before zeroed packetno and granulepos we must writing OGG headers and continue dumping RTP stream. It is worked! I tested.

If file system can't make files with size more 2Gb we can genereate file with same name and add number to it(for example, dump_video_001.ogm, dump_video_002.ogm and etc). This files shell be overlayed - frames in last 5 sec(for example) in first file and 5 sec from start in second file will be same. It is OK?

Andrey Latin --194.84.94.130 11:21, 8 December 2005 (CST)