DivX Color Problem on Standalone

[D-Train]

Greetings!

I've been lurking these forums for months now and have found a great source of knowledge. I only hope I can contribute a fraction of what I've learned here. On to my question... :)

I recently bought a new standalone that supports DivX. It's been great so far. I now have a file that doesn't play right. GSpot reports it as DivX 5.0, 25 fps, 544x416, so I guess it's PAL. Most everything else I've played is NTSC. This file plays fine on my computer but when I play it on my standalone the color is off. Everyone's faces are blue. What causes this and what can I do to play this file right? Also, is there a way to slowdown the speed to 23.976 without re-encoding the video? I'd probably have to re-encode the audio but that's not a problem. Any suggestions on how to get this file playable without reducing the quality is much appreciated.

[manono]

Hi, and welcome to the forum-

It's easy enough to slow it to 23.976 without reencoding. Extract the audio and convert it to 23.976 in BeSweet (as you said, reencoding the audio is necessary). It even has a Preset for the job. Then open the video in VDubMod. If the audio is still in the .avi, click No when that annoying question comes up. Set Video for Direct Stream Copy. Then go Video->Frame Rate->Change to 23.976 frames per second. Add the reencoded audio in Streams->Streams List->Add. If the original audio is still in there, Disable it first. Then back to File->Save As, give it another name, and wait a minute or 2.

I don't really know why the color channels are being reversed. My guess is that it's in RGB, and the player has trouble with it. But that's just a guess. Sounds like a player defect to me. Maybe report it to the manufacturer and hope for a firmware upgrade. Reencoding to YUY2 or YV12 should fix that, if my guess is correct.

[stephanV]

uhm... like most codecs DivX uses yv12 as internal colorspace... you cannot re-encode it to yuy2 or yv12...

perhaps the player just doesnt know how to cope with the frame rate...

[manono]

What I was thinking was that whoever encoded it may have used Full Processing in VDubMod, perhaps to use internal VDub filters, perhaps because he didn't know what he was doing. Or maybe he frameserved using a VFAPI, or encoded in TMPG. Won't that create a video in RGB? And won't reencoding make it possible to convert back to YV12?

As for not being able to cope with the 25fps; mine (Sigma Designs chipset) plays just about every possible framerate. But after slowing it to 23.976fps, maybe D-Train will tell us if that works to fix the problem.

[stephanV]

Originally posted by manono
What I was thinking was that whoever encoded it may have used Full Processing in VDubMod, perhaps to use internal VDub filters, perhaps because he didn't know what he was doing. Or maybe he frameserved using a VFAPI, or encoded in TMPG. Won't that create a video in RGB? And won't reencoding make it possible to convert back to YV12?

Nope that wont create a video in RGB... that would make VirtualDub kinda useless. All MPEG is yv12 internally, if the codec gets a none yv12 input it will convert it to yv12 itself. in case it doesnt recognise the input colorspace it will spit out an error.

if DivX could use compression in RGB24 that would require a twice as high bitrate as yv12 to get similar quality (with regard to blocking and ringing). anyway, it doesnt do this.

of course there is also the possibility that the video wasnt created within the DivX profiles...

[manono]

Hey stephanV-

I had to go back and research this in the YV12 FAQ (http://forum.doom9.org/showthread.php?s=&threadid=37276) and it turns out that you're absolutely right (which you knew already:)). No matter what you feed it, YV12 always gets outputted (is that a word?). Even TMPG which I was sure output RGB, does require RGB24 for input, but converts it to YV12 when compressed. Thanks for the heads-up. Of course, none of this helps D-Train, but it helped me.

[D-Train]

Thanks for the help. I tried using the process described by manono to slow down the video and the problem still persists. I tried using another video that was at 25 fps and that one plays fine. According to the metadata of the problem video, the AVS was created using Nandub build 1853. My player is a JVC XV-NP10S btw (http://www.divx.com/hardware/detail.php?p=22).

Anything else I can try?

[Soulhunter]

@ manono

Something about VDub's processing modes and colorspace conversations... (http://forum.doom9.org/showthread.php?s=&threadid=74549) ;)


Bye

[manono]

I think that the metadata saying that it's NanDub just means that NanDub was used for the muxing. I do the same myself, and it says NanDub also, even though the .avis are XviD (in the upper right Video section of GSpot).

I don't know if any funny business is going on with the FourCCs, but you might experiment with that. There's a FourCC changer that comes with the XviD Codec. It's called Nic's Mini AviC FourCC Changer and is AviC.exe in your XviD Codec folder. I have no idea if that'll do anything to help, and GSpot crashes after I do it, although the video plays fine after being changed from XviD to DivX. Other than that, and other than reencoding, I'm out of ideas (and some weren't so good to begin with). Maybe someone else can help.

[stephanV]

@D-train: the best thing you can do is try to take perhaps a short piece of your video, re-encode that within the DivX certified profiles (no QPEL, no GMC, only 1 cons. b-frames) and see if that works. If it is muxing problems you are encountering you would probably still see them. If you don't, you probably know what to do.

My other suggestion would be remuxing the whole thing with AVImux GUI, turning of all openDML options in the settings, but that would seem a more unlikely one too me. (are people still using nandub for muxing BTW???)

[D-Train]

Thanks for all the replies everyone. I wanted to follow up and not leave this thread hanging. I bought a new standalone because of other problems I had with the first player. The new standalone had the same probs so they either use the same chip or there's something with the encode. I'm not sure which. Either way this has become low priority for me and I found that re-encoding was acceptable and the new encodes play fine.

[bond]

qpel can also cause some distortions, if there is a dct mismatch (but i think divx 5.0 didnt offer qpel anyways)