| Printable Version of Topic
Click here to view this topic in its original format |
| Unofficial VirtualDub Support Forums > Testing / Bug Reports > Basic Windows Bitmap Format Avis |
| Posted by: MadMaz Feb 13 2003, 11:05 PM |
| I have these avi's that virtualdub can't seem to handle correctly. When I open them, they look very strange. The video is split up into 15 horizontal bands. Each band is horizontally offset from the one above it. So, each frame basically looks like its been skewed diagonally. These videos play fine in MediaPlayer. You can find an example frame of the video at http://www.eecs.umich.edu/~mazina/example.bmp AVIinfo reports that the video uses "Basic Windows Bitmap Format" and that it does not require a codec. The audio coded is mp3. I've tried everything I can think of to convert it with no luck: - Opened the files up forcing vdub to use various codecs - Various other programs: TmpgEnc, TmpgEnc with direct show filter prioritized, graphedit, winmpg video convert, quicktime pro, Pinnacle Studio Again, these videos look fine in Media Player. btw, the colors within each band are very distorted. Does anyone have any idea how I can edit these files? http://www.eecs.umich.edu/~mazina/example.bmp |
| Posted by: phaeron Feb 14 2003, 03:20 AM |
| Can you post or send me a 1 frame sample showing the problem? VirtualDub should be able to cut the video in direct mode even if it can't decode it properly. |
| Posted by: fccHandler Feb 14 2003, 04:23 AM |
| Please post a link if possible. I'd like to see it also. |
| Posted by: MadMaz Feb 14 2003, 07:04 AM |
| The above URL was a single frame exported from the movie. Here's a short clip without sound. It's about 400k: http://www.eecs.umich.edu/~mazina/example.avi btw, VirtualDub is able to cut the movies fine in direct mode, but I'm trying to find a way to reencode these as the seek times are very slow on my older computers. |
| Posted by: jcsston Feb 14 2003, 07:31 AM | ||
I downloaded that clip and it is compressed with DivX. The fccHandler is blank but the biCompression is 'DIVX'.  It plays fine for me with VirtualDub and WMP. |
| Posted by: phaeron Feb 14 2003, 09:15 AM |
| fccHandler in AVI headers is defined as the ID of the codec that created the stream, not the format of the stream itself. No Microsoft AVI reader appears to pay attention to it, and I believe NULL is a legitimate value. For Motion JPEG streams, it is frequently some mutant of 'mjpg', as people tend to have more than one MJPEG codec installed under slightly varying fccs. I fixed VirtualDub some time ago to allow fccHandler=0. And yes, the file is most certainly DivX compressed, not Windows DIB. As for the decoding issue, I have just verified that it is a bug in the RGB24 output path of the DivX 5.0.3 decore. (Possibly earlier versions too, but I don't know.) It affects both the DirectShow and the VFW decoders, but it doesn't normally show up in Windows Media Player because either RGB555, RGB32, or YUY2 is usually used instead. If you use GraphEdit to stick the Intel Indeo R3.2 compressor after the DivX Decoder, so that RGB24 output is forced, you see the same color stripes. Microsoft AVIEdit shows the same problem as VirtualDub with the VFW codec, and in VirtualDub, the problem goes away if you force 16-bit decoding in Video | Color Depth. So I'm very sure this is not on my end. Please file a bug report with DivXNetworks so that they know about this. Make sure to specify RGB24 output, the 326x242 frame size, and your CPU in case it's a specific CPU optimization path. |
| Posted by: MadMaz Feb 14 2003, 11:36 AM |
| Wow, you guys are impressive (and fast). Switching to 16-bit allows me to recompress the file properly. I was thrown off a bit as the video in the output preview pane still appears corrupt even after changing the settings. But when it actually generates the new video, the output is fine. Though I don't really grok the underlying color representation issues, I'll use this thread to file the bug report with DivXNetworks. I'm assuming that this bug also exists with xvid and vp31, as forcing vdub to use them also causes similar problems. Thanks for the help! |
| Posted by: MadMaz Feb 14 2003, 02:46 PM |
| I went back to convert some old files that I had in this format, and I found some avi's for which this technique did not fully work. Switching to 16-bit did get rid of the banding and color problems, but, with these new files, a variant of the skewing issue remains. The only difference is that each individual line is skewed by a small amount, while previously each of the bands was skewed by a large amount. To be clear, switching to 16-bit did get rid of banding, color AND skewing problems in some of the original files, but not in these new ones. Any ideas on this? I've posted a snippet from one of these new problem files: http://www.eecs.umich.edu/~mazina/ex2.avi |
| Posted by: fccHandler Feb 14 2003, 03:01 PM |
| As far as I can see, whoever made these videos goofed. The DivX encoders require the width to be a multiple of 4. The first video "example.avi" has a width of 326, and the second "ex2.avi" has a width of 315! So of course the codec craps out, because someone's been feeding it bad widths. |
| Posted by: MadMaz Feb 14 2003, 05:50 PM |
| Yeah, I know. But when I recompressed the first set of files, setting color to 16bit and resizing to a multiple of 4, it resulted in a pefectly good video. With these new ones, only part of the problem is corrected. And, again, even with the funky width, the oiriginals of these new videos look fine in wmv. btw, I don't know if this matters, but I got all of these videos from Spanish usenet groups (es.binarios). Though I've admittedly heard that there are hardliners in Spain who would do anything to stop people in the US from recompressing their videos, I don't put much credence in that theory. I just thought I'd mention it in case it's a PAL-related issue. |
| Posted by: fccHandler Feb 14 2003, 08:26 PM |
| If the videos play OK in MediaPlayer, why do you want to convert them? |
| Posted by: MadMaz Feb 14 2003, 08:31 PM |
| On some of them, the color and contrast are off. And they all take too long to seek on slow machines. |
| Posted by: phaeron Feb 15 2003, 03:32 AM | ||
Older DivX codecs did not enforce this limitation on encoding. If the current revision of the codec cannot properly decode 24-bit RGB for a particular frame size, it should refuse to do so instead of passing the query call and then decoding corrupted video. Of course, doing this requires knowing beforehand that your code won't work in this fashion, which isn't always the case.... |
| Posted by: MadMaz Feb 15 2003, 03:34 AM |
| I don't mean to be bothersome, but I had another question. The files that did convert "successfully" look much grainier than the originals. Examining them closely, it looks like the images are being dithered in the conversion. So, am I correct in thinking that that the original file is, in fact, in 24-bit color, but using the 16-bit setting to get around the rgb24 bug is causing this loss of quality? If so, is there any way around this? For that matter, why is the divx decoder choosing a different rgb output path than it would with a typical file (assuming the dithering means that the color depth is 24-bit like a typical file.) Thanks for all the help |
| Posted by: MadMaz Feb 15 2003, 03:56 AM |
| Ack, simulataneous posts. I think your post answered my question then. Lemme see if I got this right. You're saying it's all caused by the illegal size. And there's no way around it since since we can't force the codec to use one of those other 24-bit color paths that do work, i.e. the ones that wmv chooses. But we can force it to use a 16-bit path that's more forgiving of size, but it must dither and we lose quality. And even that path is not forgiving enough to handle the width of 315. Am I correctly paraphrasing what you guys are saying? I assume there's no way to crop out some of the image to a legal size without recompressing, right? |
| Posted by: fccHandler Feb 16 2003, 05:54 AM | ||||
Right. But you may be able to grab the version you see in MediaPlayer by using GraphEdit, or this Avisynth script:
|