asquared / openreplay Goto Github PK

Hi Andrew,

curious for your project i started to compile on a fresh ubuntu 10.4 install, and got stuck on a build problem?

[code]
root@ubuntu:/var/openreplay/core# make -f Makefile

g++ -Wno-multichar -Wall -Wextra -I ../../include -fno-rtti -g -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS pkg-config libavcodec libavformat libswscale libavutil --cflags sdl-config --cflags -o sdl_gui sdl_gui.cpp ffwrapper.cpp mmap_buffer.cpp -lm -ldl -lpthread pkg-config libavcodec libavformat libswscale libavutil --libs -lavutil sdl-config --libs -lSDL_image -lSDL_ttf
g++ -o mjpeg_ingest mjpeg_ingest.cpp mmap_buffer.cpp -Wno-multichar -Wall -Wextra -I ../../include -fno-rtti -g -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -lm -ldl -lpthread
g++ -o bmdplayoutd bmdplayoutd.cpp ffwrapper.cpp mmap_buffer.cpp -Wno-multichar -Wall -Wextra -I ../../include -fno-rtti -g -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -lm -ldl -lpthread pkg-config libavcodec libavformat libswscale libavutil --cflags pkg-config libavcodec libavformat libswscale libavutil --libs -lavutil
bmdplayoutd.cpp:199: warning: unused parameter �speed
[/code]

u got an idea?

This means a 1-line modification.

Floating point values can cause rounding errors, possibly resulting in jerky playback. A rational value should probably be used instead.

See #6. Preroll should be accounted for when a mark is saved, not when it is used. This will make things like a "no-preroll" mark command easier to implement.

Also easy enough to make happen.

This will entail a few things...

• capturing HD video from DeckLink and other cards
• processing streams to obtain a preview feed
• allowing sdl_gui to control playout over distributed machines
• control of external video switchers to select the output stream from said distributed machines

RPI TV HD Sports... coming soon!

These are everywhere, and tend to limit openreplay's usefulness in non-NTSC locales. They will also be a problem when openreplay is to be used in HD productions.

The "ffoutput" program will constantly read data from ffmpeg even before it is needed. This can result in large memory buffers being allocated. Potential fixes include using separate ffmpeg processes for video and audio decoding, or blocking the ffmpeg process when buffers exceed a preset size. Separate processes are likely to work best, in light of the fact that ffmpeg audio decoding can be blocked if nothing reads from the video pipe, and vice versa. (Thanks go to lpelay for initially reporting this.)

For support of things like on-the-fly addition of keyboard macros. For example, RPI TV might like to map the h and j keys to some scripts for marking and rolling super-motion clips (h: mark right now into a special mark register, no preroll. j: select the super-motion camera, cue the "special" mark, and roll replay).

Possible implementation: use Ruby/FFI to call the sdl_gui main routine and enable Ruby access to internal commands. Set up some Ruby-based callback functions for events (for now, a keypress hook is probably sufficient). Build a Ruby framework for hooking keystrokes and implementing new commands.

This would improve A/V sync in ffoutput. If the API decides to work this week, this is worth implementing.

For some applications (i.e. RPI TV Hyper-Motion(tm)), it would be nice to store a separate mark. (For example, with hyper-motion, there will be a "main" mark of the initial event, followed by a second mark of the super-slow-motion replay rolling from the camera.)

Things that will be necessary:

1. ability to store marks into auxiliary mark registers
2. ability to execute a cut to a secondary mark

Proposed keyboard inputs:

• <numeric>m: mark into the register with the given number (with preroll)
• <numeric>n: mark into the register with the given number (without any preroll)
• <numeric>,: cut using the selected mark

Also, mark handling is currently a bit stupid - preroll is applied to the mark when it's used, not when it's marked. This is really not good, confusing, and will make implementation of some features difficult.

Hmmm, maybe I should use that bogus "RPI TV Birds-Eye View" DSK for the over-goal shots at hockey? On a more serious note - it should be possible to automatically enable a DSK when a certain camera is selected for playout.

On a related note, DSKs should be loaded from command-line args, not hard-wired defaults. This should be easy to do with getopt.

i.e. playoutd d1 d2 d3 d4 --dsk 0,instantreplay.png --dsk 1,reverseangle.png --dsk 2,hypermotion.png --auto-dsk 0,0,1,2

where the --auto-dsk option will automatically enable the "instant replay" DSK for cameras 1 and 2, the "reverse angle" DSK for camera 3, and the "hyper-motion" DSK for camera 4. Perhaps DSKs should just be loaded in order i.e. --dsk instantreplay.png,reverseangle.png,hypermotion.png. In any case, most of this should be simple to implement.

http://www.mir.com/DMG/interl.html

"Odd dominant" should really be called "lower field first"; "even dominant," "upper field first". This may require a lot of code to be changed.

One, two, it wants more... gigabytes that is. </really bad pun>

Leak is somewhere in the text rendering code, in picture.cpp. Leaked memory was allocated in pango or freetype, (even though all objects are nominally released?) Bug probably in openreplay and not one of the external dependencies. More analysis is needed.

When we film hockey, Reilly at RPI TV says that there should be less preroll on the second and subsequent replay angles rolled. I agree.

Another command should be added: "MARK IN". This will set the current mark position to the current playout position, or maybe set another, different mark. Thereafter, a "CUT/REWIND" command should cut to this new mark instead of the original one. Thinking about using the "I" key for this purpose.