Idea for quickly grabbing a thumbnail from an MPEG

[dbloom]

This is all basically theoretical, and I'm not sure if it would work. I'd search to see if it's been brought up before but I'm not sure of they keywords to use.

The DCTs in MPEG (if my memory is correct) are accompanied with a value that determines the average of each 8x8 block. These could probably be read really fast from an MPEG-2 to generate a quick lower-resolution thumbnail of any frame. It could be especially nice for seeking or showing low resolution frames until an I frame is reached during playback.

Would this be practical (or possible)?

[Mug Funky]

this would probably only work effectively on I-frames. remember on inter frames, the DCT is performed on the difference between the current frame and the motion-compensated last (or next) frames. this means the DC component would be almost completely mid-grey if it were just read out of the stream.

btw, i've never written an encoder before, just read a lot about them. i could easily be wrong :)

[mpucoder]

This technique has been used by many image editors for jpeg, so there's no reason it would not work with an mpeg I frame.

[dbloom]

Originally posted by mpucoder
This technique has been used by many image editors for jpeg, so there's no reason it would not work with an mpeg I frame.

Could error concealment vectors be used for other frames? Or should we just decode the whole thing the normal way at that point?

[jfcarbel]

I would be very interested in seeing the code for this. I have been trying to figure out a way to do this as well.

I assume this is how DVDShrink does the preview during the VOB parsing.

[Enots_]

I doubt very much that shrink uses such a technique - most modern mpeg2@ml decoders can do well in excess of 100 FPS on a modern computer. Also Shrink has a particular interest in taking a peek at how many AC components is in the video (to estimate how it'll compress)- at least for analysis. For playback you're fast enough anyway. Obviously you'd probably need a downsample routine and a color conversion step as well - but you should be able to do that and still be far in excess of 30 FPS which is required for viewing. Skipping frames would be surperior (either only skipping what you display or skip non-reference frames entirely). Also you definately need to do the syntax decoding regardless because macroblocks are not aligned or "findable" in an MPEG stream without actually parsing all macroblocks prior to it in the slice.

It could make some sense as a simple downsampling routine for HD tv for ultra fast previewing. As the DCT becomes very simple when you only have a DC component. Taking it even further you could probably expand to P & B doing motion compensation on DC (in worst case you'd have to read only 4 pixels/DC values and average them up when doing MC). But it's a far out fucked up implementation which simply doesn't make sense for anything but ultra-highdef.