XviD Dshow flipped video (fix)

[sh0dan]

ok - created a new thread instead of extending the Selam thread even further.

Here's the deal:

By default RGB24/32 is flipped when heigt is positive. This is correctly reflected in HRESULT CXvidDecoder::ChangeColorspace(GUID subtype, GUID formattype, void *, where the following code can be found:rgb_flip = (vih->bmiHeader.biHeight < 0 ? 0 : XVID_CSP_VFLIP);
So if height is less than 0, the image is not flipped - when height is positive it is flipped. The variable name above suggests that it is only applied to RGB, which is also true if you look at the rest of the code in "ChangeColorspace", and this is fully correct.

However if you look at the code in HRESULT CXvidDecoder::Transform(IMediaSample *pIn, IMediaSample *pOut): if (PPSettings.bFlipVideo) {
if (rgb_flip)
m_frame.output.csp &= ~XVID_CSP_VFLIP;
else
m_frame.output.csp |= XVID_CSP_VFLIP;
}
else {
if (rgb_flip)
m_frame.output.csp |= XVID_CSP_VFLIP;
else
m_frame.output.csp &= ~XVID_CSP_VFLIP;
}
You can observe that even if the "Flip Video" switch is disabled the "rgb_flip" value is inserted into the csp - No matter the colorspace!

IMO the code should read:
if (PPSettings.bFlipVideo) {
m_frame.output.csp ~= XVID_CSP_VFLIP;
}

If the "Flip Video" is active, reverse Vflip no matter the colorspace - otherwise leave it untouched.

I don't have access to a compiler here to test it.

Furthermore IMO the prefered output order should be:

YUY2 (Not the fastest, but the most compatible hardware-wise).
YV12 (I have experienced better hardware support than IYUV)
IYUV
RGB32
RGB24

[Koepi]

Thanks sh0dan,

that sounds reasonable. I hope the fix will be in CVS soon.

Regards
Koepi

[sysKin]

Thank you sh0dan :)
I just have one question. the code:
if (PPSettings.bFlipVideo) {
m_frame.output.csp ~= XVID_CSP_VFLIP;
}
Doesn't seem right either.

How about:
/* add the flag if dshow says so */
if (rgb_flip) m_frame.output.csp |= XVID_CSP_VFLIP;

/* reverse the flag if user says so*/
if (PPSettings.bFlipVide) m_frame.output.csp ^= XVID_CSP_VFLIP;

..but of course I have to take a look at the code first.

Radek

[sh0dan]

Originally posted by sysKin
How about:
/* add the flag if dshow says so */
if (rgb_flip) m_frame.output.csp |= XVID_CSP_VFLIP;

/* reverse the flag if user says so*/
if (PPSettings.bFlipVide) m_frame.output.csp ^= XVID_CSP_VFLIP;

..but of course I have to take a look at the code first.

Radek

Sorry - you are right - I meant XOR. Anyway - the rgb_flip is already added to the colorspace in RGB-mode in ChangeColorspace in RGB mode only, for example:
else if (subtype == MEDIASUBTYPE_RGB32)
{
DPRINTF("RGB32");
m_frame.output.csp = rgb_flip | XVID_CSP_BGRA;
}

The cleanest would probably be to only set it once, and flip it later if the user has requested so. That was my intent, at least. ;)

[snowcrash]

Well, I don't know if this is the same problem but let me tell you what I'm experiencing since installing XViD beta3. When I play XViD videos in WMP9, about 80% through the video the image will flip upside-down. Now if I play the video again the whole thing is upside down. I have to close and reopen WMP9 to get it back to normal, but then it flips again 80% of way through. This doesn't happen with Zoomplayer.

[sysKin]

Originally posted by sh0dan
Anyway - the rgb_flip is already added to the colorspace in RGB-mode in ChangeColorspace in RGB mode only, for example:OOOkay - this is why I said I had to look at the code. I'll fix it tommorow :) Thanks.
Originally posted by snowcrash
When I play XViD videos in WMP9, about 80% through the video the image will flip upside-down.So it does not neccessarly crash on WMP9? Good to know. Indeed, it might be related to the problem and in fact might even be related to the crash people are reporting at http://forum.doom9.org/showthread.php?s=&threadid=67042.
We'll see.

Radek

[snowcrash]

Originally posted by snowcrash
Well, I don't know if this is the same problem but let me tell you what I'm experiencing since installing XViD beta3. When I play XViD videos in WMP9, about 80% through the video the image will flip upside-down. Now if I play the video again the whole thing is upside down. I have to close and reopen WMP9 to get it back to normal, but then it flips again 80% of way through. This doesn't happen with Zoomplayer.

Just wanted to add a couple thing that might help you sorting this stuff out. First, I'm only having problems with upside-down video in WMP9, not WMP6.4 or Zoomplayer. In WMP9, clips that were encoded with a previous version of XViD display the behavior I described above. Clips that were encoded with XViD beta 3 flip upside down a few frames into the video. Definately a WMP9 issue, though.

[sysKin]

Originally posted by sh0dan
By default RGB24/32 is flipped when heigt is positive.Could you please share your knowladge and tell me if *only* RGB colorspaces are subject to flipping? Should negative height also flip YUV colorspaces (from what you said, no). Should the gui switch have any effect on YUV colorspaces? (I guess it's up to us, so yes why not, but maybe you'll say something smarter than that).

Thanks in advance,
Radek

[sh0dan]

RGB is the ONLY format that can be flipped! I have not experienced flipped YUV material (in any form).

RGB24/32 is by default flipped with first byte being equal to lower-left pixel. However some codecs deliver negative height to indicate top-first order. In YUY2/YV12 (and various forms thereof) the first byte is ALWAYS top-left - I have never experienced it in any other form.

IMO it should also flip in YUV-colorspaces - otherwise it would just be strange that it didn't have any effect. (Also if there is an error later in the chain it could correct for this).

[JJ2335]

Hi, I have my own findings to share about beta3 encodes. Using divx or ffdshow decoders the video isn't flipped but video playback is jerky at a lower FPS under media player classic. Using the Xvid beta3 Decoder video plays at standard ~23FPS but video is flipped. From this, it seems flipped video occurs under xvid codec while stuttering video occucs under other decoders. I encoded a movie 2pass in Gordian Knot. Please, anyone who can clear up this issue or can contribute make a post. Thanks.

[JJ2335]

okay so flipped video is a XvID decoder bug? and at the moment xvids unique implementation of packed bitstream isn't compatible with other decoders resulting in stuttering. I'll try unchecking packed bitstream and share my results.

[sysKin]

The packed bitstream implementation is not unique, but rather extends DivX5's method. The extension comes from the fact that XviD supports more than one b-frame. If only one b-frame is used, packing method is identical to divx5's.

[sysKin]

I was about to commit the fix but then Koepi asked a disturbing question:
16:14:51 : (@Koepi): did you test it, does dshow work correctly?

Afterthoughts resulting from this interesting concept (testing I mean) resulted in a discovery that I shouldn't XOR a flag every frame, or funny things happen.

I'll think of something later today :D

Radek

[Leak]

Originally posted by sysKin
Afterthoughts resulting from this interesting concept (testing I mean) resulted in a discovery that I shouldn't XOR a flag every frame, or funny things happen.

Heh - so that's how you invent new bugs... :D

np: Lawrence - Lost Friday (The Absence Of Blight)

[sysKin]

OK commited. There was noone to ask silly questions this time.

I also made XviD understand Matroska's aspect ratio. You can now use xvid to decode anamorphic mkv files.

As sh0dan suggested, the first colorspace will be YUV2 now, it's much safer on any hardware I've seen.

Have fun,
Radek

[zulu]

Originally posted by sysKin
I also made XviD understand Matroska's aspect ratio. You can now use xvid to decode anamorphic mkv files.
Radek [/B]
wow, great! thanks :)

[Assault]

Thank you very much sysKin. The XviD decoder is my favourite mpeg4 decoder now. :) (The only feature I would like to see in the future is the ability to read the AR flags in the mpeg4 bitstream.) ;)

Assault

[sh0dan]

@sysKin: Is the "Force Colorspace selection is in reversed order" from the "Selam"-thread also fixed?

(When RGB24 is selected YV12 is forced and vice versa - when RGB32 is selected YUY2 is forced)

[sysKin]

Originally posted by sh0dan
@sysKin: Is the "Force Colorspace selection is in reversed order" from the "Selam"-thread also fixed?I *think* so. The original list was sorted (dunno why), it might have caused the problem. I'm not sure - but I checked debug output and it appeared to force colorspaces well.

Radek

[sh0dan]

Since there is still problems with flipped video:

Noticed the code:
m_frame.output.csp &= ~XVID_CSP_VFLIP;
m_frame.output.csp |= rgb_flip^(PPSettings.bFlipVideo ? XVID_CSP_VFLIP : 0);

Doesn't this mean that YUV still gets flipped, or am I mistaking?

I got a compiler now, but I cannot get it to compile the DirectShow filter.

It could be fixed by setting rgb_flip to 0, if the CS is YUV. Could be implemented like this:
if (subtype == CLSID_MEDIASUBTYPE_IYUV)
{
DPRINTF("IYUV");
m_frame.output.csp = XVID_CSP_I420;
m_frame.output.stride[0] = (m_frame.output.stride[0] * 2) / 3; /* planar format fix */
rgb_flip = 0;
}
[...]

And repeating for every YUV colorspace.

You might also have a look at Planar YUV stride (http://list.xvid.org/pipermail/xvid-devel/2004-January/003968.html).

[celtic_druid]

No problems compiling it here, with or without your changes.

http://celticdruid.no-ip.com/xvid.rar

Don't think it works though. That was CXvidDecoder.cpp that I was supposed to change?

[chros]

So, does this flipped video problem exist in the RC1 still ?
Or the MPC and VobSub makes this ?

Strange, until beta3 there were no such bug ...

[sh0dan]

YV12 and YUY2 are no longer flipped on my system using the patched .ax file above! Reverting to RC1 recreates the problem.

@sysKin: I notinate this for inclusion! :cool:

(Edit: I wrote below, when it was above - however if you consider the way you write, it might even make sense)

[sysKin]

Thank you sh0dan. If only my coding style didn't mean "make all the bugs you ever can" lol...

Sh0dan, could you also check if all colorspaces are mapped OK? I don't trust anything I've written.
Originally posted by chros
Strange, until beta3 there were no such bug ...This isn't strange at all - I didn't touch the code before :P

Proundly Inventing New XviD Bugs,
Radek

[JJ2335]

Flip video occurs with XviD 1.0 RC1-B3 + Dvobsub 2.23. As stated the flipped video is limited to dvobsub usage regardless of container in question (avi, ogm, mkv). Versions prior to XviD 1.0 clearly had no flip issues. Bottom line check your filters; MPC can state filters loaded also look for the green arrow task tray icon.

I have graciously forwarded gabest, developer of vobsub of this issue but he has yet to reply. Many changes have been made in XviD 1.0. Is it possible a fix or workaround be made by the developers instead?


Keep up the great work!

[Milkman Dan]

Yeah, I can confirm that I don't get flipped video with RC1 unless there is a dvobsub supported stream in the container (mkv in my case). If I don't have subs, dvobsub doesn't load, and I don't get flipped video.

[sh0dan]

Originally posted by JJ2335
I have graciously forwarded gabest, developer of vobsub of this issue but he has yet to reply.

No need to direct Gabest here. The bug is in Xvid, but it is triggered by DVobSub.

What do you mean by "Is it possible a fix or workaround be made by the developers instead?". Syskin is an XviD developer.

[sysKin]

I commited new code (again ;p)

Anyone would like to test?
http://homepages.ihug.com.au/~syskin/xvid.ax.zip

I'll now work a bit more to add new bugs related to:
- DX50 and mp4v (or MP4V or both?) 4cc support, disabled by default but selectable
- find out why players with auto-repeat are unable to loop xvid videos

Wish me luck~
Radek


What is the mp4v fourcc used to play mp4 files? mp4v or MP4V ?

[chros]

Originally posted by sysKin
I commited new code (again ;p)

Anyone would like to test?
http://homepages.ihug.com.au/~syskin/xvid.ax.zip


Sorry, for the Rookie question:
Where should I put this xvid.ax file in WinXP ?

And Yes, if DVobSub is loaded, then the video is always (!!!) flipped !!!

[sysKin]

Originally posted by chros
Sorry, for the Rookie question:
Where should I put this xvid.ax file in WinXP ?You can register it wherever you want by the command

regsvr32.exe xvid.ax

or you can replace RC1's xvid.ax in WINNT\system32\

:)

Now, new build to test:
http://homepages.ihug.com.au/~syskin/xvid.ax2.zip

which allows DX50, DIVX and mp4v fourcc - but you have to open xvid video to open configuration and tick them, so I don't really like it yet, work in progress :)

[guilc]

All right, it works fine, the flip video bug with directvobsub is corrected, it decodes fine DivX (4CC : DX50 and DIVX)

Thanks :)

[sysKin]

Nice to hear that guilc :)

http://homepages.ihug.com.au/~syskin/xvid.ax3.zip - another version, fixes the problem with players entering infinite loop when the video has ended.

:)

[Assault]

Great work sysKin!

I just tested latest version and I it's really nice that divx5 movies can be decoded by the xvid decoder now. :)

EDIT: Do you intend to add another 4CC? Otherwise you could place the three 4CCs in a row for a more symmetrical look than at the moment. ;)

Assault

[iago]

The latest version works fine here too, with both XviD and DivX5 content without any problems. Great! :)

regards,
iago

[mf]

Originally posted by Assault
EDIT: Do you intend to add another 4CC? Otherwise you could place the three 4CCs in a row for a more symmetrical look than at the moment. ;)
MP4V? :)

[sysKin]

Originally posted by mf
MP4V? :) Yes right, can someone explain me if MP4V is needed, or mp4v is enough? I made a text search accross mplayer.exe and it doesn't have MP4V anywhere.
I'm looking for *the* 4CC used to play .mp4 files.

Also, are there any other mpeg-4 4CCs? 3vix's? ND's ? Or maybe mp43 (or, again, is it MP43??) is mpeg-4 too?

[Selur]

3ivx is using 3iv2

[bond]

Originally posted by sysKin
Yes right, can someone explain me if MP4V is needed, or mp4v is enough? I made a text search accross mplayer.exe and it doesn't have MP4V anywhere.i also dont know a codec that uses "MP4V"

I'm looking for *the* 4CC used to play .mp4 files. shitowax meant that connecting to mp4 files (via the 3ivx splitter) should perfectly work if you support the small size "mp4v"
but i tested it and it doesnt want to connect to 3ivx, so maybe there is a bug somewhere :(

(Shitowax) if the checkbox is checked (in the 3ivx splitter), there is nothing more than to support the mp4v fourcc ...
(Shitowax) the question is who refuses the connection ... because, the initial mediatype is outputted by the 3ivx splitter and should be accepted by the xvid decoder ... if he can't connect, it might be his fault
(Shitowax) i tested it and the 3ivx splitter is ok with all the mediatypes, so it's in his code
Also, are there any other mpeg-4 4CCs? 3vix's? ND's ? Or maybe mp43 (or, again, is it MP43??) is mpeg-4 too?3ivx uses 3iv2
nd isnt usable in avi (if it is in mp4 it also works with mp4v)
mp43 is the 4cc of the ms mpeg-4 codec, which isnt mpeg-4 compliant
ffvfw uses fvfw (dunno what ffmpeg uses)
divx5 uses both divx and dx50 4ccs

[mf]

Okay, I meant mp4v. ;)

[sysKin]

Originally posted by bond
shitowax meant that connecting to mp4 files (via the 3ivx splitter) should perfectly work if you support the small size "mp4v"
but i tested it and it doesnt want to connect to 3ivx, so maybe there is a bug somewhere :(What do you mean "maybe" and what do you mean "somewhere" LOL. Of course there is a bug, and of course it's in the code I've written. There should be no doubts about it *even* if stuff works :p :p :p

Quick fix at http://homepages.ihug.com.au/~syskin/xvid.ax4.zip

Please try again, this is the first time I'm messing with this. Don't forget to re-register the filter (if you just copy, system will not know it supports mp4v).

Have fun,
Radek

[bond]

works great now! :)

it would be also great if the xvid decoder could also support resizing anamorphic mp4 files by default, like it does with matroska
but i will stop my bugging now :D

[sysKin]

Originally posted by bond
works great now! :)

it would be also great if the xvid decoder could also support resizing anamorphic mp4 files by default, like it does with matroska
but i will stop my bugging now :D It only works with matroska because matroska splitter supplies decoder with AR information. If mp4 spliter would do that, decoder would pass it to overlay mixer as well.

Good to hear it works ^_^

[bond]

Originally posted by sysKin
It only works with matroska because matroska splitter supplies decoder with AR information. If mp4 spliter would do that, decoder would pass it to overlay mixer as well.hm i guess the 3ivx splitter also does that (cause if used with the 3ivx decoder automatic resizing works and according to shitowax the 3ivx decoder doesnt do any resizing)
i guess the 3ivx splitter passes it another way than the matroska splitter

Good to hear it works ^_^ great work! :)

[shitowax]

No idea how Matroska does, but the 3ivx splitter put the DecoderSpecificDescriptor ( aka VOSH or VO/VOS/VOL for MPEG-4 video) of the mp4 file at the end of the VIDEOINFOHEADER structure. If you want the AR info, they are here. Btw, it does exactly the same thing with audio, but coreAAC already use that.
Another trick, the latest 3ivx VfW codec put exactly the same information in AVI. That's why, AR now works in avi as well ...

Sure that helps ;)

[sysKin]

Originally posted by shitowax
No idea how Matroska does, but the 3ivx splitter put the DecoderSpecificDescriptor ( aka VOSH or VO/VOS/VOL for MPEG-4 video) of the mp4 file at the end of the VIDEOINFOHEADER structure. If you want the AR info, they are here. Btw, it does exactly the same thing with audio, but coreAAC already use that.
Another trick, the latest 3ivx VfW codec put exactly the same information in AVI. That's why, AR now works in avi as well ...

Sure that helps ;) Ah thanks for the info shitowax. Not easy to implement with current XviD structure which doesn't really have any easly accessable VOL-reading functions. Possibly I could create a decoder, read VOL header and close decoder? We'll see.

Let me tell you what XviD does support at the moment:
- aspect ratio in VIDEOINFOHEADER2 structure. It's got dwPictAspectRatioX and dwPictAspectRatioY fields in it, this is how matroska provides AR information to decoder. XviD just copies this info to output pin (which also uses VIDEOINFOHEADER2).
- biXPelsPerMeter and biYPelsPerMeter in VIDEOINFOHEADER structure. This works with AVI well, and gets translated to VIDEOINFOHEADER2's AR in output pin.
Just note that my interpretation is as follows: Pixels-per-meter is inverted PAR, so the actual PAR is (1/XPelsPerMeter):(1/YPelsPerMeter) which, as a ratio, is the same as YPelsPerMeter:XPelsPerMeter.

Would be nice if your splitter supported one of them ;) especially concidering that it wouldn't break anything.

After 1.0 is out, I'll see what I can do about supporting your way. Seems more difficult to implement :(

Regards,
Radek

[shitowax]

Originally posted by sysKin
Let me tell you what XviD does support at the moment:
- aspect ratio in VIDEOINFOHEADER2 structure. It's got dwPictAspectRatioX and dwPictAspectRatioY fields in it, this is how matroska provides AR information to decoder. XviD just copies this info to output pin (which also uses VIDEOINFOHEADER2).[/B]

That's the easy way for you, but our splitter knows nothing about the video info except what is written in the video track description (basically, dimensions and that's all). The splitter outputs what it knows and it doesn't know anything about PAR or SBR for audio ... I don't like the matroska's way cause you can store in theory different PAR in the video bitstream and in the file format ...

- biXPelsPerMeter and biYPelsPerMeter in VIDEOINFOHEADER structure. This works with AVI well, and gets translated to VIDEOINFOHEADER2's AR in output pin.
Just note that my interpretation is as follows: Pixels-per-meter is inverted PAR, so the actual PAR is (1/XPelsPerMeter):(1/YPelsPerMeter) which, as a ratio, is the same as YPelsPerMeter:XPelsPerMeter.

hum ... nice trick ... I dunno if that respect the "official" PelsPerMeter, but it seems funcky :)
But once again, that would need adding VOL parsing in our splitter ...

Would be nice if your splitter supported one of them ;) especially concidering that it wouldn't break anything.
After 1.0 is out, I'll see what I can do about supporting your way. Seems more difficult to implement :(

I dunno if it's more difficult, but it's more powerfull and systematic (works for audio, video and would be the same for system)and respect the MPEG way : the system layer gives the media decoders what they need to work : the decoderSpecificDescriptor... As far as I've hacked it, ND seems to work exactly the same way ;)

[sysKin]

Thank you for explainations shitowax. Indeed, if demuxer knows something about video stream (like with mp4) it should pass the whole header (VOL header in this case) to decoder. Simple and efficient, with many uses.

If demuxer doesn't know that, like with AVI or MKV, it's the other way around - container has to store its own aspect ratio info. You're right, this might mean that this AR is different than written in video stream itself.

I wonder if matroska splitter could attach whole first frame to the end of VIDEOINFOHEADER2 (it uses the -2). This could solve many problems...

Anyway, you just added another point to my TODO list for after-1.0 development. Oh well.... ;)

Radek

[Stux]

Originally posted by bond

3ivx uses 3iv2
nd isnt usable in avi (if it is in mp4 it also works with mp4v)
mp43 is the 4cc of the ms mpeg-4 codec, which isnt mpeg-4 compliant
ffvfw uses fvfw (dunno what ffmpeg uses)
divx5 uses both divx and dx50 4ccs

I think you should be precise,

3ivx uses '3IV2'
MP4 uses 'mp4v'
ms-mpeg4v3 uses 'MP43'
divx5 uses both 'DIVX' and 'DX50'

fourccs are case sensitive, and getting the cases wrong is what causes all these problems in the first place.

[DavidW]

sysKin,

I'm a complete idiot about this stuff and I appologze in advance. But anyway.

I registered the last xvid.ax file you posted here and the video flip occuring in Windows Media Player 9 near the end of the movie is almost fixed.

This problem was first posted in this thread by snowcrash who said it happedned near 80% through on his movies. On mine it's even closer to the end. About 45 seconds away from the end of a 3 hour movie.

Anyway. I say it almost fixed it because my video still flips. Around 45 seconds away from the end of the movie the video becomes choppy and slow for a second or two then flips, then (thanks to your added code) flips back to it's original position.

If you play through the same movie again there is no flip. but if you open a new movie the same flip and reflip occur near the end of the movie.

This is a very minor annoyance becuase I encode most of my movies with the credits included, so it's just credits gettign flipped. But I aspire to one day use the XviD codec to encode family movies that don't have credits. Then Grandma is suddenly gonna be flipped at the end of the movie. :)

Of course I'm sure by then all of this will be worked out and long since gone, but I thought since you fixed flipping problems with the other program maybe you'd be interested in knowing that you almost fixed the WMP9 player also. (Or maybe you already knew that)

Like I said before, I'm an idiot on this encoding and decoding stuff. If not for Gordian Knot I wouldn't be posting here today. But let me know if there is anything I can do to help you resolve this problem. I love XviD and look forward to the day when I can reliably encode (and decode) everything with it.

Thanks for the fix,
David