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


in reply to Re^2: 2d animation
in thread 2d animation

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.

Replies are listed 'Best First'.
Re^4: 2d animation
by wanna_code_perl (Friar) on Aug 16, 2011 at 00:41 UTC

    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. :-)

      The moving graph is composited on top of raw multi-camera footage, along with some other control information.

      That compositing could also be done at the client for a considerable saving.

      But it is your own and your clients cpu, bandwidth and time, therefore money, that you are spending. Not mine. Good luck.


      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.

        Do me a favor. Download six different ~8 hour h.264 38.8Mbps 29.97fps 1080p clips on your fastest laptop (yes, I'll wait). Fire up six instances of your fastest video player and tile them across your monitor. Mash play on all six at once. What's your frame rate user experience like?

        Now repeat the test with a single 6-7Mbps clip. (Pick one with a visible timecode if you're worried that lossy compression would render a graph illegible.)

        How did that work for you? :-)