Motion Dive 3 compression

[Nienzus081]

Now I know that this subject is a consistent one on these boards but I am still not satisfied with the look of my projected output in MD3. Meaning that i spend a great amount of time composing rich :30 clips only to have the impact lessened by lossy compression.

SO: what kinds of compression are you using for MD3? I create most of what I do in Final Cut and have tried exporting with mostly cinepack and Sorenson. I have even tried using Cleaner but the clips, when blown full screen in MD3 look horrible. Since I have a lot of graphics in my clips COMPRESSION SUCKS! When I finally get a good quality of compression, the files are too big and are therefore to slow on the triggering. Has anyone solved this dilema???

Thanks in advance,
N081

[walrus]

I compress my movs in sor3, millions of colors,
90kB 320*240 12.5fr and it looks quite ok,
the sorensen compression doubles quite well.

ANyone has got an idea what's the compression of
the original MD files. They run really fast,
but ok the quality isn't great.

[Nienzus081]

Wal,

At those perameters do your clips trigger fast?

[innathort]

i have been using cinepak millions of colors, 320/240 @30fps
and they seem to run fine as long as they are reasonably small.

but i'm still confused with this subject, as it seems most people are because i have had a 650mb movie playing in one channel and mixing in smaller movies on the other channel and its fine but then if i have two movies that are about 15mb running they choke sometimes.

i would really love to get an answer to this MD problem, as i'm sure many others would it seems.

Nienzus: you say how bad they look full screen, i read somewhere, might have been on the audivisualizers site (actually is -

"Or, you can use the recommended method (by the MD3 authors, and what I'm doing), by using an external scan converter to zoom in on your final mix window, and then use the fullscreen output from your scan converter to feed your video mixer or projector."

[spark]

- the never ending topic -

if you are using a live mix application you need as processor efficient a codec as possible with no temporal compression, ie every frame is a keyframe. ie, your computer can go straight to the frame it needs and is spending the minimum of time decompressing it once its got there.

on a mac this is quicktime, photo-jpeg and final cut pro3 ships with a G4 enhanced version called something like photo-jpegRT.

providing your vjsoft streams the clip in, filesize is utterly irrelevant with modern disks and bus speeds.

cleaner or virtual-dub is your best friend here: it will take your DV masters, allow you to process the picture for optimal display on screen, and encode it consistently. quality needn't suffer, once you've accepted the lo-res, processing multiple video streams at 320x240 is quite enough for most machines.

you use a scan converter to get faster framerates, as it takes over the task of pixel doubling the final output to 640x480 from the computer. only using a good quality scanny, which scales the image with smoothing (like bipolar in photoshop) will it make a difference on the image quality.

hope this helps.

toby

ps. is there not an authoratitive thread or article on this yet (i don't believe it)? does one need to be written?

[innathort]

so spark, are you saying to use the photo-jpeg and put in a key frame for every frame?

"is there not an authoratitive thread or article on this yet (i don't believe it)? does one need to be written?"

hmm i think so mate... questions reguarding md3 seem to pop up quite a bit.
i guess we are all still waiting/hoping for the manual to be translated and all our problems will be solved ;)

thanx

[spark]

this isn't really a MD3 issue, its generic to any vj soft that mixes multiple video streams together. the vdmx documentation goes through it well... hint hint!

photo-jpeg is by definition every frame a keyframe, you shouldn't need to specify it, but if you do then yes. keyframes are an encoding thing, where you can say make every 25th frame a keyframe (ie full picture) and then only record the changes till the next... which is good for compression but useless for live vj use. set quality to around 80% and you won't see a drop in quality from the masters.

for the article, wait till after the AVIT event when hopefully we'll document the showcases and i'll try and remember to get this issue in there...

remember the mantra is: PHOTO-JPEG, 80%, 320x240

[mondo]

from my understanding, best output at speed for .mov in md3 is

cinepack
320 X 240
million colors
50-100% quality
Data rate 300-600KB/s
Keyframe 5
Frame 24 fps


works wikkid for me...no complaints

:-a

>>if it moves, sample it<<

;)

[spark]

no: i'll tell you why. you can get better quality and better framerates using photo-jpeg over cinepak.

cinepak - you get compression artifacts which lose you quality. photojpeg 80% there is no loss in quality.

every frame a key frame - to get the best framerates and responsive scratching, every frame has to be described in full. otherwise it needs to load the keyframe before it and compute all the changes through the frames leading up to it, ie get to the image thats the frame before your keyframe, you've processed 4 frames to get 1. think about this and playing backwards, video scratching etc.

[Nienzus081]

Spark:

At that resolution do your clips lag at all? My whole quest is to find a compression that looks great and equally triggers fast, all at a size that MD3 can handle. I'll do some tests with PhotoJpeg. Up till now I have been taking my 720/480 clips out of Final Cut and put them through Cleaner using Cinepak 320/480. As mentioned before, they trigger fast but could look at lot better.

[innathort]

i'm glad we're all talking about this.

nienzus, i ran a test using phot-jpeg at 30fps and i found it lagged a lot compared to cinepak, sure enough the quality of the cinepak was lower, but i need a quick trigger and no lag.

i have yet to put any key frames into my samples - what exactly does this do to improve the flow?

also, i'm looking at the info on a motion dive clip now and it says:

"garbled" of course 320x240, millions
30.03 fps
317.5k bytes/sec data rate

so now where are we? :confused:

[spark]

interesting.

lag is mostly to do with the app you're using - its seems that programmers basically have to make a trade off between a low latency (lag) architecture and a realtime effects architecture. codecs do play a part, but its really just down to how processor efficient they are, and to my knowledge cinepak and photojpeg are as efficient as you can get.

the keyframe thing i've already explained - the ultra summary is that if you want to do anything that isn't playing the clip forward at its set framerate, then every frame should be a keyframe. photo-jpeg is automatically like this, cinepak isn't. that might explain the difference, as your cinepaks will play forward well but do anything else badly, the photojpegs will play consistently nomatter how you scrub it, but p'raps at a slightly lower framerate. so to get sensible results we need to test scratch response as well.

basically, any testing you're doing is all good, as people use these things differently and things move on so what was right a year ago may not be now. at the end of the day, i'm sticking to G4 enhanced photo-jpeg, 80%. if i was on a PC, i'd probably use the visuals codec designed by the midivid people (forgot about that in the earlier post).

- this debate will never end, but its time for me to check out for this episode -

toby

ps. why use md3 when there's vdmx! www.vidvox.net wahaaa haaa haa wa haaa haa. my apologies.

toby

[murph]

the midivid folks ran into these issues and created a couple codecs to work them out. The first is their mjpeg codec, which is similar to what's described above. Their second is what they call a "performance" codec, and I really don't know what the difference is, but we've had better luck with this codec under resolume and haven't noticed any image deterioration - available at midivid.com I believe.

[Nienzus081]

Finally did more tests and I have to agree with Spark in that Photo-Jpeg is the way to go on the mac. I compared everything within the Final Cut export selection and PJ kept good quality at a reasonable file size. Gonna try that for a while....