objarni's picture

Feedback idea

I have this idea that feedback is one of the psychologically most important aspects of software development.

So I thought, what will increase the feedback most when developing an OpenTK application..? Screenshots are traditionally a really good "carrot" for inspiration and progress. If there was a simple way to create a screenshot and put it up at the opentk blog, it would increase the feedback rate for me.

Continuing that thought line, I know that Progress.Start(path) opens up the file browser of the operating system.
Also, Progress.Start(url) opens the browser at the specified URL (or a new Tab if you're in Firefox). The URL to add a blog post at opentk.com is http://www.opentk.com/node/add/blog, at least if the browser caches the login to opentk, which it does here. And, the GLControl has a "screenshot" method called GetBitmap.

Could I mix all these ingredients into something productive..?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Nope, video encoding is more fun :)

Sorry for hijacking your thread, but I am giving up for now (maybe someone wants to take the lead?)

A commandline like this could be a good starting point:

ffmpeg -r 4 -i udp:// video.avi

The encoder starts listening for data on - "all" that remains is find out a format you can stream to ffmpeg ("-f tif" doesn't seem to work :)), capture the frame data and stream it to the socket.

Should work. In theory.

objarni's picture

Hehe nice try at least, maybe someone can fill in on that.

I'll just have to wait and try it out myself tonight.. :(

triton's picture

I've been using Fraps to record videos, I don't know if it can be controlled by a script. Then I use VirtualDub with ffdshow codecs to convert the video to something more manageable.

But your solution using a listener and sending the frame data also seems interesting.

the Fiddler's picture

I use Fraps too, but it's windows-only shareware. An alternative would be nice.

Now, capturing the frame and audio data is relatively easy. Encoding is also easy. The difficult part is finding out how to stream the data to the encoder. Unfortunately, ffmpeg's documentation isn't very enlightening here.

Why streaming?

  • faster than writing to disk, reading then writing to disk again
  • it's cross-platform
  • maybe you have a second computer and a gigabit LAN lying around - why not use it? :)
objarni's picture

Can the encoder encode things in realtime? It sounds like an awfully complicated process (more complicated than, say, LZH-compression).

If not - how is "piped" encoding possible? Specifically, where does the stream of information reside if not on disc? Memory would fill up quite fast I guess?

the Fiddler's picture

It depends on the format, the profile, the quality settings and the CPU speed. Things like divx/xvid or the SD profiles of h264 can be encoded faster than realtime nowadays.

If the CPU can't keep up, it will either have to reduce quality until it catches up or start dropping frames.