http://qs321.pair.com?node_id=920304


in reply to 2d animation

Are you looking to do this on the web or desktop?

Either way, streaming a movie of a real-time line trace would be a hugely cpu-intensive way of approaching the problem. Video-encoding is a very cpu-intensive process, usually done off-line, not on-the-fly.

The most (band-width) economic method would be to transmit (just) the numeric values and have the graph drawn locally. Basically, each update would consist of bit-blitting the right-most, width-N pixels left N pixels and then drawing the new N-pixel position on the right.

Updating 60 times per second may be a little too fast across an unreliable html connection, but you can easily reduce that (to 30/sec) by doing two new values at a time, or (15/sec) doing 4 at a time etc.

For the web this can easily be done using javascript or the new HTML5 canvas control. You could also use a web browser, or one of the graphical toolkits (eg Tk) on the desktop.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: 2d animation
by wanna_code_perl (Friar) on Aug 15, 2011 at 22:40 UTC
    I meant streaming to the encoder (e.g., ffmpeg) in the Unix pipelining sense, not streaming to the end user. Offline encoding is indeed what I want, "exported as any reasonable movie format". Sorry if that wasn't clear.
[reply]

      Hm. OKay, but still at somepoint, someone is going to watch these movies right?

      Drawing, compressing, shipping and displaying 60 frames a second of video in order to display 60 individual numeric values per second is a laborious, time & space consuming way of allowing them to see it. Especially if there are going to be many such videos.

      It would be far more cost effective to construct a simple application that reads the raw timestamp/value pairs from a file and draws the scrolling line trace on the users screen on demand. Then you give the user(s) the application once and send them the raw data files -- which will compress readily -- as they become available.

      My estimate is that 10 minutes of raw data -- say 2 x 64-bit float values per reading -- 16 * 60 * 60 * 10 = 1/2 Mb uncompressed and reasonably, less than half that zipped.

      The same information captured as 640x480 video will run to ~60MB. Even if you radically compress it with a lossy codec, you'll be very lucky to get much below 30-35MB. And the results would be hideously blurry, blocky and inaccurate. Effectively useless for anything other than "Ooh. Look at that!".

      I also seriously doubt that you'll be able to render the movies in real-time, which means you'll first have to record the data, and then play it back -- via some application that renders the scroll line trace -- so you can record that as the movie.

      So, you'll need a line tracer anyway to create the movies. Once you have that, why not just give a copy to the user(s) and let them see the actual trace rather than wait for you to produce and ship some huge, blotchy movie of it?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        The moving graph is composited on top of raw multi-camera footage, along with some other control information. This is in fact why I wanted to export the graph in a video format.

        Hard to believe, yes, but sometimes the OP actually knows what they want. :-)

[reply]
      There is a FFmpeg module on CPAN that wraps the C libraries. Have you investigated it?
[reply]
        There is a FFmpeg module on CPAN that wraps the C libraries. Have you investigated it?

        Thanks! It looks like it might actually offer some efficiency and simplicity benefits (depending on the underlying implementation, which I haven't looked into). I'm planning on benchmarking and comparing the output of both. (I.e., FFmpeg module and CLI, and probably Mencoder as well.)

[reply]

In Section Seekers of Perl Wisdom