video encoding for teh suck

[zwol]

When fine details of motion in video from your experiment will be gone over frame by frame by undergraduate slave labor research assistants, clever temporal encoding like H.264 (which introduces all sorts of motion artifacts, invisible at normal speed) are no longer a good idea. Conveniently enough, QuickTime container format allows you to just encode each frame as a separate JPEG. But then the file is much bigger, and you can't fit as much video on your DVD as it says on the label.

Just how much you can fit depends strongly on where you put the JPEG quality slider. Ideally I'd like to put it way high up, because DCT artifacts can be just as bad; but empirically speaking, I have to put it down around "medium" to get 60mins of video on one DVD with associated reference material.

Also, it takes nearly as long to encode the video as it does to get the video off the tape and onto the hard drive, i.e. about as long as it would take to play the thing back in realtime. And only at the end of that do you discover whether the file will fit on the DVD; and if you got it wrong, you get to do it all over again.

Comments

an apple a day may cause hypertension in some individuals

[(Anonymous)]

And, of course, there's no earthly reason one couldn't stream the video off of the tape and directly into the JPEG encoder (with some disk-backed buffer to hide latency, blah blah), and the JPEG encoder could perfectly well watch the bitrate it was achieving and tune it on the fly to get the maximum quality that fits on one DVD.

And then after you've carefully done the idiot dance of clicking it through its whole elaborate sequence, it throws away the frame numbers. Apparently copying integers from the input file to the output file is so difficult, that it requires an extra $1000 of software.

I _so_ hope that as DV gets more mainstream, there'll be enough interest for FOSS folks to just solve this stuff. Given how many hours this stuff wastes, it'd be _so easy_ to justify just _fixing_ it, if there was any way to do so...

Non-bitterly-yrs,
-- Nathaniel

Re: an apple a day may cause hypertension in some individuals

[(Anonymous)]

...actually, I wonder if gstreamer could do all that these days? It seems to have all the pieces, except for proper quicktime container format support...

-- N

Re: an apple a day may cause hypertension in some individuals

[zwol.livejournal.com]

... and maybe we could even stream the video straight from the camera to the computer and avoid all this mucking around with tape? (I'm not sure I really want that. I like knowing that even if that computer in the lab craters, and even if I never see the DVDs I pass out to the coders again, the data will still be on the tapes. On the other hand, not having to deal with magnetic tape would be a happy. Also it was two-thirds of my expense budget on this experiment.)

Um, what do you mean "it throws away the frame numbers", and exactly how screwed does that mean I am?

gstreamer is clever and stuff, but I don't really trust it in the same room as even slightly proprietary data formats (libxine seems to be the clear winner here), and I have no clue how to manipulate it. And yeah, the temptation to Just Fix It is there, but we both know that that way lie years of work and not even a dissertation at the end of them. :/

Re: an apple a day may cause hypertension in some individuals

[(Anonymous)]

Hrm. I have nothing but open-mouthed respect for the modern linux scheduler's real-time capabilities, but I'd still trust the camera's real-time capabilities more, especially given how squirrely disks are. (Dropped frames are nobody's friend.) The tapes are also less-compressed than the jpeg versions, so theoretically somewhat higher quality...

"Throws away the frame numbers" -- DV streams have timecode in, each frame is marked by a unique sequential number saying where it is. It would be nice if, upon doing a capture starting at 5 seconds into such a stream, you ended up with a file whose timecode stated that frame 1 = second 5. (The file formats involved all support this, and Final Cut /Pro/ does it automatically.) Then when browsing the video files, the time shown on the screen would line up with the times on the tape, so you could easily go back and find exactly the same frame back in the source media. I'm not sure how often you need to match up the full-capture to the original tape, since they're similar in quality. Where it'd really be handy is when you've cut little clips out, it'd be nice if you could systematically figure out where exactly they were cut out of the original larger stream.

Also, we are converting a bunch of discrete items from digital to digital. WTF can we not match them up again afterwards?

It looks like gstreamer does have a plugin to give it acces to ffmpeg, and I dunno what libxine has that ffmpeg doesn't. I bet it could be convinced to spit out quicktime (though probably without proper timecode, alas). And gstreamer has python bindings...

Re: an apple a day may cause hypertension in some individuals

[zwol.livejournal.com]

Hrm. I have nothing but open-mouthed respect for the modern linux scheduler's real-time capabilities, but I'd still trust the camera's real-time capabilities more, especially given how squirrely disks are.

Oog, yes, you're right. Also, you remind me of the complaint that I totally left out of the original: there is no good reason why reading the data off the tape (which is, as you say, discrete and digital and timecoded) should have to go at realtime playback speed. It should be able to stuff data down the cable as fast as the cable can take it. (Disclaimer: for all I know it is already saturating the cable. It's for damn sure not saturating the disk interface, though.

The tapes are also less-compressed than the jpeg versions, so theoretically somewhat higher quality...

DCT artifacts are bloody obvious in the DVD version of a lot of my data, and weren't there in the little 'play back direct from tape' window, so yeah.

It looks like gstreamer does have a plugin to give it acces to ffmpeg, and I dunno what libxine has that ffmpeg doesn't.

Not-crashing, in my experience. :P ... okay, mainly what I use either of these things for, on my actual Linux box, is playing commercial DVD movies, which is totally not the same problem, but still.