XviD-1.1.-127-13102004...

[Taurus]

Originally posted by SeeMoreDigital
Has anybody here checked how well the old Windows Media Player 6.4.09.1125 (mplayer2.exe) or Media Player 5.1 (mplay32.exe) cope with XviD.ax?

Mediaplayer 6.4.09.1125 can't open the file. Error 80040216
Mediaplayer Classic 6.4.8.2 opens the file in 4:3 mode,
after one mouseclick in the screen (left or right)16.9 Widescreen Anamorphic resolution is shown. Very strange but funny:D .
Mediaplayer 9 opens the file in 16.9 Widescreen Anamorphic resolution,
but refuses to open via right click in explorer.
BS Player messed up too. In window mode 16.9, full screen mode 4:3.

Edit: Mediaplayer 6.4.09.1125 opens the file if in options menu avi support is enabled.

[SeeMoreDigital]

Well just to make things more consistant...

Here is a link to my PAL 4:3 720x576 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/PAL_4.3_720x576_-_Test_Card.zip).

So together with the already up-linked PAL 16:9 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/PAL_16.9_720x576_-_Test_Card.zip). That's good old PAL sorted.


And for all you NTSC guys... here are your encodes: -

NTSC 4:3 720x480 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/NTSC_4.3_720x480_-_Test_Card.zip).

NTSC 16:9 720x480 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/NTSC_16.9_720x480_-_Test_Card.zip).



Cheers

EDIT: PAL "Test Cards" updated, NTSC "Test Cards" added.

[Taurus]

Originally posted by SeeMoreDigital
Well just to make things more consistant...

Your testfile is shown in correct 4:3 aspect ratio in all mentioned
players (see above)

16:9 testfile is displayed only @4:3 in mediaplayer classic when overlay mixer is used.
In VMR9+7, while opening the file, most of the time it is drawn at 4:3 first. Maximizing the window, clicking into it, or switching to fullscreen mode restores the 16:9 setting.

[jaapaa]

This is not related to the discussion above, but this is related to XviD-1.1.-127-13102004 so I post it here..

After installing XviD-1.1.-127-13102004, I've got several occasions where the encoding job and virtualdubmod have just plain died and disappeared in the middle of the encode. No error message, no message box, zilch, nada, nothing..
Never had it with XViD 1.02. Of course I'd provide you with more info, if I'd know where to get it and or what you want to know...

XP, 1 gig, no SP2, vdubmod 1.5.10.1, amd 3200+

[Koepi]

That's usually an issue with bad memory. Or too hot CPU/memory.

You should open your computer and clean the fans, maybe there is too much dust collected and the cooling doesn't suffice anymore.

XviD stresses your CPU and memory more than usual programs like burn-in-tests and memory checkers (at least the ICL compiled builds).

Regards
Koepi

[loni_blues]

Hi,
Thanks kurt: Zoomplayer with vmr9 displays the PAR correctly!

Another issue: From what I've read I believe vbv compliancy is only useful for compatibility in standalones. Is this right?

Regards

[Sharro]

Originally posted by loni_blues
... From what I've read I believe vbv compliancy is only useful for compatibility in standalones. Is this right?

Regards

From what I've read YES you're right :)

The sudden bitrate spikes make many standalones choke....

From my experience with standalones (I encode always above 1.200Kbps averages) the Mediatek 1389EE copes much better with these than 1389DE did and I do hope this is something that will not be an issue in the future if we want to dream of HDTV resolutions Xvid playback on standalones....

All the best,

Sharro

[Sharktooth]

@Koepi: any news on the bughunting side?

[Koepi]

Nope. I've not too much time and can't imagine where this comes from. I'll ask sysKin if he remembers.

Regards
Koepi

[Sharktooth]

I meant... in the decoder.

[Koepi]

I know.

[loni_blues]

Oh, oh, this thing about resizing never ends. It is working fine in MPC and Zoomplayer (with VMR9) but it stops working if subtitles are auto-loaded with DirectVobSub. The right PAR is displayed as long as no vobsub subtitles are displayed.
Is anybody having the same problem? What can be happening with PAR displaying/detection?
Thanks in advance.

[Sharktooth]

It seems AR is working if Xvid is the last filter before the renderer.

[loni_blues]

Thanks!
Sorry for my ignorance, but is there any way to put the decoder after DirectVobSub, so that it's last before the renderer?

[LigH]

:confused: The decoder filter after an overlay filter?

On which surface shall an overlay filter (like DVobSub) render its content, before a decoder creates the video surface?

[Ark]

I've never seen this feature working.

I tried it on 2 PC's at work and on my home PC without luck...

I can change Pixel AR or Picture AR but it does absolutely (apparently) nothing. I tried MPC and WMP with all renderer, tried to maximize/minimize the player or pause/click on it (someone has reported that such things "activate" the correct AR), change the decoder AR (16:9, 2.35:1) but nothing happens.

My home machine was formatted not too long ago, I simply installed Windows XP, MB/VGA drivers, DirectX 9.0b, Xvid, MPC. That should be enough to play correctly!

Maybe I forgot something...

(I've an Athlon XP-M 3600+, 512 mb RAM, MB Abit NF7-S rev 2)

[Koepi]

Dumb question:

did you change the PAR/DAR in encoder and switched over to playback or did you encode with that setting and the resulting bitstream doesn't change the AR?

Regards
Koepi

[Sharktooth]

Originally posted by Ark
I've never seen this feature working.

I tried it on 2 PC's at work and on my home PC without luck...

I can change Pixel AR or Picture AR but it does absolutely (apparently) nothing. I tried MPC and WMP with all renderer, tried to maximize/minimize the player or pause/click on it (someone has reported that such things "activate" the correct AR), change the decoder AR (16:9, 2.35:1) but nothing happens.

My home machine was formatted not too long ago, I simply installed Windows XP, MB/VGA drivers, DirectX 9.0b, Xvid, MPC. That should be enough to play correctly!

Maybe I forgot something...

(I've an Athlon XP-M 3600+, 512 mb RAM, MB Abit NF7-S rev 2)
Make sure to have VMR9 enabled (AR seems to work only with VMR, at least for me...), use DirectX 9.0c (maybe it helps) and make sure you have no filters between Xvid decoder and Video renderer (use graphedit to check).

[Ark]

Originally posted by Koepi
Dumb question:

did you change the PAR/DAR in encoder and switched over to playback or did you encode with that setting and the resulting bitstream doesn't change the AR?

Regards
Koepi

I did a few short encodes with all possible PAR/DAR combinations and played them all with all decoder DAR settings. From the results it seems that the AR flag is ignored by player/decoder in every case i tried. (I don't think XviD doesn't write it though)

@Sharktooth

Yes, WMR9 is enabled (i tried all renderer from overlay to WMR9 renderless). I've still to check with Graphedit, thanks for the suggestion :)

[Ark]

I've a Matrox video converter filter (coming from a RTX100) after XviD, causing this issue. (see attachment)

Erasing this filter cause the video to play correctly (finally!!) if I play the graph from Graphedit, but it's only temporary.

I've to find a way to erase this filter for normal playback on Dshow players...

(Bella Shark, ottimo consiglio!! :))

(Thank Shark, good suggestion!! :))

EDIT: hey i've attached a .gif file, but it doesn't show... :confused:

[Sharktooth]

@Ark: the attachment should be approved by a mod then it will show up :)
comunque ... grazie :)

[Ark]

Thanks, i didn't know that

[SeeMoreDigital]

...or upload your images via ImageShack (http://www.imageshack.us/). It's free to use!


Cheers

[Leak]

Originally posted by Ark
I've a Matrox video converter filter (coming from a RTX100) after XviD, causing this issue. (see attachment)

Erasing this filter cause the video to play correctly (finally!!) if I play the graph from Graphedit, but it's only temporary.

Add this filter to MPC's block list: "Options/Filters/Overrides/Add Filter", browse for it and set it to "Block" - if you need the file name, the "Insert Filters" dialog in graphedit will show it if you expand that filter's node, then just make MPC block that file.

That should probably fix it; if you don't need the filter at all you could also just unregister the filter with regsvr32 or G-Spot...

np: März - The Pop Song (Wir Sind Hier)

[Bill_st]

I've been doing some testing with this build and I have a question about vbv support. I'm trying to make my encodes work with a cheap standalone that doesn't allow bitrate spikes above 3 Mbit before giving problems, I don't know if it is a chipset limitation (it is a ESS Vibrato II) or loader speed limit, but going above 3 Mbit/s leads to audio skipping and stutters.

With Divx, unchecking the Divx profiles and setting the max bitrate at 3 Mbit was enough to make it work (it changed the CL to -vbv 3000000,3145728,2359296) , and now with this Xvid build with vbv support and using the AS@L4 profile it still skips audio during complex scenes, though less than before. I don't know how to view avi bitrates, but checking with Virtualdub I measured 2.32 MB of video during a complex scene that was 123 frames long, so I guess the average bitrate in that interval was around 3.77 Mbit/s (it is a PAL video, 25 fps). Wouldn't this be impossible with vbv on and AS@L4 profile? One thing is true though, it was more than twice as much with the 1.0.2 build, so it is doing its job, even if I don't know why it isn't respecting the 3 Mbit limit. Perhaps this number (max bitrate) could be selectable in newer builds?

[celtic_druid]

Think VBV is probably just hard coded to the DivX Home Theatre settings. There were some older custom builds around with selectable VBV if I recall correctly.

[Bill_st]

Hmm, that would make a lot of sense, since I measured a bitrate very close to the max bitrate allowed by the Divx Home Theater Profile. If that is the case, I would please ask for this number to be selectable in future releases, thx :D

[Ark]

Originally posted by Leak
Add this filter to MPC's block list: "Options/Filters/Overrides/Add Filter", browse for it and set it to "Block" - if you need the file name, the "Insert Filters" dialog in graphedit will show it if you expand that filter's node, then just make MPC block that file.

That should probably fix it; if you don't need the filter at all you could also just unregister the filter with regsvr32 or G-Spot...

np: März - The Pop Song (Wir Sind Hier)

Strange, today i checked the yesterday videoclip in Graphedit, and the Matrox filter wasn't there! But the autoAR yet doesn't work...

There is a "Subtitle Mixer" filter between XviD decoder and video renderer, and if i erase it AR works.

So i tried your method and set to Block this filter in MPC.. but nothing changes, it still doesn't work, and i don't know how to do now, i can see correctly played movies only in Graphedit...

[Sharktooth]

The xvid decoder needs a fix coz most filters does not support AR signaling.
A possible workaround is to "pass" the AR corrected resolution instead of the full resolution or building a special resize DS filter that will be always placed before the video renderer.

[pogo stick]

Originally posted by celtic_druid
Think VBV is probably just hard coded to the DivX Home Theatre settings.
Is it? Koepi, can confirm it?
I thought it supposed work with levels of ASP and SP. :confused:

[Koepi]

VBV works with hardcoded values currently, no matter what you enter as profile. I / we should adopt that of course. Don't forget this is a test build. We were wondering if VBV compliancy works as expected at all - which it seems to do. So now it's time to extend that.

Regards
Koepi

[Sharktooth]

Good news.
There will be also an option to make custom profiles (or maybe a simple override where you can manually set max bitrate...)?

[PiXuS]

I am doing a ~24h encode with 1.1. My settings are:

mode: single pass
qm: 6of9
qpel
b-vops: 2/1.50/1.00
target quant=4.00
MSP: 6
VHQ: 4
b-vhq: enabled
chroma motion

My AVS script chain is: Telecide.Decimate.Crop.Undot.ConvYUY2.PixieDust.ConvYV12.LimitedSharpen.Undot

I lend 256MB to VDM 1.5.10.1/2439.

After about 11h in the encode, the memory consumption is up to 317 604kB (or around 310MB). Something is leaking at an avg. rate of 5MB per hour.

Could it be due to XviD 1.1 alpha? I'll try to find more evidence... I'll let the script run during the night.

thanks.

Edit:Well, the encoding is finished and the memory usage oscillated at around 310MB during the last minutes. I don't know why VDM didn't respect the 256MB limit (it used to). Anyway.. sorry for hijacking this thread (?).

[Didée]

Hmh, I don't think XviD is to blame. I suspect any plugin, or Avisynth itself, or even hole-y Windows (see PM with lots of off-topic Avisynth stuff).

[Jawor]

Originally posted by celtic_druid
There were some older custom builds around with selectable VBV if I recall correctly.
They are here (http://jawormat.republika.pl). Check out the builds from 25.06.2004.

[trbarry]

I guess I'm still a bit confused on VBV. The options are specified in the 2-pass section but it seems it might be very useful to help a nice constant bit rate in 1-pass CBR, say especially for things like streaming.

Is VBV intended to work in 1-pass CBR?

- Tom

[stegre]

I think this fixes all of the decoder's flaky AR behaviour:
HRESULT CXvidDecoder::SetMediaType(PIN_DIRECTION direction, const CMediaType *pmt)
{
if (*pmt->FormatType() == FORMAT_VideoInfo)
{
VIDEOINFOHEADER * vih = (VIDEOINFOHEADER *) pmt->Format();
BITMAPINFOHEADER * hdr = &vih->bmiHeader;
ar_x = vih->bmiHeader.biYPelsPerMeter * abs(hdr->biWidth);
ar_y = vih->bmiHeader.biXPelsPerMeter * abs(hdr->biHeight);
}
else if (*pmt->FormatType() == FORMAT_VideoInfo2)
{
VIDEOINFOHEADER2 * vih2 = (VIDEOINFOHEADER2 *) pmt->Format();
ar_x = vih2->dwPictAspectRatioX;
ar_y = vih2->dwPictAspectRatioY;
}
if (direction == PINDIR_OUTPUT)
{
return ChangeColorspace(*pmt->Subtype(), *pmt->FormatType(), pmt->Format());
}
return S_OK;
}

[celtic_druid]

Tried it and it still doesn't work without packed bitstream. Same files worked fine via ffdshow.

Ok here's something interesting, it isn't so much packed not packed, but the DivX999b000p flag. Add that and it works fine, however then you get the whole jerky playback thing.

[sysKin]

Originally posted by stegre
I think this fixes all of the decoder's flaky AR behaviour:
HRESULT CXvidDecoder::SetMediaType(PIN_DIRECTION direction, const CMediaType *pmt)
{
if (*pmt->FormatType() == FORMAT_VideoInfo)
{
VIDEOINFOHEADER * vih = (VIDEOINFOHEADER *) pmt->Format();
BITMAPINFOHEADER * hdr = &vih->bmiHeader;
ar_x = vih->bmiHeader.biYPelsPerMeter * abs(hdr->biWidth);
ar_y = vih->bmiHeader.biXPelsPerMeter * abs(hdr->biHeight);
}
else if (*pmt->FormatType() == FORMAT_VideoInfo2)
{
VIDEOINFOHEADER2 * vih2 = (VIDEOINFOHEADER2 *) pmt->Format();
ar_x = vih2->dwPictAspectRatioX;
ar_y = vih2->dwPictAspectRatioY;
}
if (direction == PINDIR_OUTPUT)
{
return ChangeColorspace(*pmt->Subtype(), *pmt->FormatType(), pmt->Format());
}
return S_OK;
}

Hmmmmm where did you get this code? It looks just like old v1.0.2 code that reads AR info from avi container (removed from 1.1) and from matroska splitter (still there). It doesn't have new AR logic at all, so it can't fix this logic ;)

Radek

[stegre]

Oh yeah, that is old source, I'll have to see if I can confirm whether it's the same problem - I got identical flaky behaviour with both, though I meant to debug the new one. What I did was create a "nullnull" filter with logging and determined that it was sending a mixture of the two AR's to the renderer as the negotiated the pin connection. I pasted a copy of a code snippet from CheckMediaType() into SetMediaType() which fixed the variable at that point and stabilized it. So it may be the same problem - in other words, it may be getting the right AR from the container or the stream or whatever, but just not getting it to the renderer properly.

[stegre]

here, this fixes the latest XviD version in my tests, including packed bitstream. I'd have to study more how those base classes work before I could "justify" it, though ;)HRESULT CXvidDecoder::SetMediaType(PIN_DIRECTION direction, const CMediaType *pmt)
{
DPRINTF("SetMediaType");

if (direction == PINDIR_OUTPUT)
{
if (*pmt->FormatType() == FORMAT_VideoInfo2)
{
BYTE* pFormat = pmt->Format();
VIDEOINFOHEADER2* pVideoInfoHeader = (VIDEOINFOHEADER2*)pFormat;
ar_x = pVideoInfoHeader->dwPictAspectRatioX;
ar_y = pVideoInfoHeader->dwPictAspectRatioY;
}
return ChangeColorspace(*pmt->Subtype(), *pmt->FormatType(), pmt->Format());
}
return S_OK;
}

[Koepi]

Using that code with my xvid-1.1-build completely disables AR correction :p

But then I decided to take a deeper look into the sources again and I fixed the forced aspect ratio stuff.

Find the new build as usual on my homepage www.koepi.org .

(there were some changes in the CVS on 30.10.2004 but I didn't notice which changes exactly. I think it was an altivec assembler code addition.

Regards
Koepi

[SeeMoreDigital]

Hi Koepi,

Has the DSdec filter been modified so it can correctly display the AR of PAR encodes with B-VOP but without packed bit-stream?

If so, I've just tried it myself and it's still not working correctly :(


Cheers

[Koepi]

I posted an entry concerning that on my homepage ;) it reads "I don't know yet if it also fixes the auto-resize-with-unpacked-bframes-issue, but forcing the aspect ratio to i.e. 4:3 or 16:9 works again."

I didn't find the problem with that yet, it seems to be in the core - the internal VOL-stats data gets overwritten before it can be read by the DSF.

Regards
Koepi

[SeeMoreDigital]

Your confirmation over here on Doom9 is most welcome all the same ;)

I just wish I knew how to help out :( But this sort of stuff is right out of my depth.


Cheers

[Koepi]

You could help me with PMing me your email address again so i can send you a testing-build ;)

EDIT: well, that doesn't help either (yet), I tried a small sample myself and the things I could do properly don't work. Sorry for the fuzz.

Regards
Koepi

[SeeMoreDigital]

Originally posted by Koepi
You could help me with PMing me your email address again so i can send you a testing-build ;) Job done!


Cheers

[Sharktooth]

Ok, i can confirm decoder AR options work (with PB).
However:
1 - brigthness is still not set to the default value after installation (you have to manually click the RESET button to do it as in the previous build).
2 - deinterlace doesnt work.

[stegre]

Originally posted by Koepi I posted an entry concerning that on my homepage ;) it reads "I don't know yet if it also fixes the auto-resize-with-unpacked-bframes-issue, but forcing the aspect ratio to i.e. 4:3 or 16:9 works again."

I didn't find the problem with that yet, it seems to be in the core - the internal VOL-stats data gets overwritten before it can be read by the DSF.
That's the problem I was looking at, but yeah, the patch doesn't work for the general case. Note, though, that the correct value is always available when the file is played - it's too late, though, as the renderer won't change AR "on the fly". See log (http://headbands.com/misc/0x1d0.htm)

[pogo stick]

Forcing AR is OK now. Auto-AR is not.
I am sure not the one who can give you good advice but auto-AR is connected with DivX999b000p flag and not with packed bitstream as Celtic Druid pointed. Because if user data have DivX999b000p auto-AR works even in mp4 file.
And have anyone looked at deinterlacing bug yet?