Yes, this is utterly unique to me as well, and I've used Octanes for compressed video for years now, flawlessly (except for software issues, like 6.5.14m having broken libraries or something, necessitating going to 6.5.15). In fact, I prefer the Octane to the O2 for video.
Hm. Okay, here's what I think I typed (I was using nedit for cli notes and then middle mouse buttoning the command in place, but freezes apparently happened before syncing the filesystem or something since on restart, my notes file would be completely empty):
Code:
dmconvert -f qt -p audio -p video,comp=qt_mjpega in.mv out.mov
I am recompressing the file, and did get it to work fine on one of my files, without any issue.
The in.mv file was a straight-up capture using dmrecord with 95% compression quality settings and audio, captured from 8mm analog tape via video switch with TBC with absolutely no dropped frames with high quality video (14m bitrate).
I'll be able to mess with it more when I get back to the office. Push comes to shove, I can pull the board and put it back into
Pachyrhinosaurus (now that I've fixed dmedia's little red wagon), but I was curious to see how the board behaved in the new machine.
I do get one curious result:
Quote:
dmconvert -f qt -p audio -p video,comp=qt_mjpega,engine=impact in.mv out.mov
generates a complaint, something to the affect of the compression hardware only works on video in resolution multiples of 16. I'm fairly certain I was only capturing 640x480, but I'll have to check the captured files when I get back...