B-frame woes...

[gldblade]

I think some of these problems may have been reported already, but just in case they haven't, here they are:

1)Nic's latest decoder does not play back B-frames correctly on my computer. Instead of playing the frames chronologically, it jumps back and forth. I guess it's failing to reorder them correctly...?

2)Koepi, I downloaded XviD-12102002-1.exe from your site today and it doesn't have Nic's latest decoder. Found out the hard way when Nic's build decoded B-frames and yours didn't.

3)I have WMP 6.4 set to restart from the beginning once the end of the video is reached. However, when I'm decoding a video encoded with B-frames using Nic's decoder, after the video plays through once, only the last frame of the video is shown when WMP 6.4 goes to play it again. It works fine if the video is not encoded with B-frames.

4)This has probably been reported already: When using ffdshow to decode B-frames, at the bottom of the video are grey blocks stick out from the bottom edge. If no one has reported this yet, I'll be glad to post a screenshot. *SOLVED* Using latest ffdshow build.

5)Also probably reported already: When I open an XviD-encoded video with B-frames in VirtualDub, it says at the bottom: "Error decompressing video frame 1: An unknown error occurred (may be corrupt data). (error code -100)" This is with using Nic's latest decoder.

I think I left out a few. I'll keep testing for more problems. B-frames look very nice though. :)

[gldblade]

6)Using XviD.dll to decode B-frames causes WMP 6.4 to crash when I try to exit.

7)If I use ffdshow with "Decode with XviD", WMP 6.4 crashes when trying to play B-frames.

Some of these problems may be one-time glitches. I'm going to test them again.

[HarryM]

I (very) highly tested b-frames in XviD (against DivX5's b-frames and b-frameless XviD) today.
B-frames in XviD have big reserves actually (I think). The quality isn't comparable to DivX5 still :(
DivX5 uses only one b-frame sequences(!), and his result is much better for look and smaller too.

XviD's b-frames are the right step on target. But correct, effective implementation of b-frames is hard. I hope, that b-frames implementation in XviD will be better than in DivX5 in future. :)

[Teegedeck]

Hi gldblade, old pal!

1)correct. Will be solved, it's Ishibaar's baby.
2)so what? It's a sneak preview and Koepi has (rightfully so, it seems) worries about just giving it out to anybody
3)again, the playback-support is in its early stages
4)solved
5)no dshow-filter is used for this. VDub doesn't support B-frames properly, only support for DX5-style (1) B-frames was hacked in. XviD is bleeding' cutting edge;)
6)don't know what causes this
7)AFAIK it's an ffdshow error in some of the later versions that occurs with or without B-frames

Please remember that this is NOT even a remotely stable release, expect errors and consider only the graver ones for report and make sure they haven't been reported, yet, and that they really are B-frames-related. Otherwise I fear we'll get flooded with so many reports, it will be hard to read all of them. Right now, I tend to change my mind and agree with Koepi that B-frame enabled builds shouldn't be made publicly available, anymore, even if this means I won't get one, either.

I hope you enjoy the new features in spite of the problems.

All best wishes,

Tee

[gldblade]

Otherwise I fear we'll get flooded with so many reports, it will be hard to read all of them

It can't be that bad, can it? :)

[Nic]

@gldblade:
Please try my new build at:
http://nic.dnsalias.com

& see if that helps any. Let me know if you still get problems.

Thanks,
-Nic

[cult]

Sorry Nic,but I only see yours 11 build...Is there a newer one??

[iago]

@cult

Try hitting the "refresh" button of your web browser. There "is" the 13/10/02 build on Nic's page ;).

regards,
iago

[gldblade]

Please remember that this is NOT even a remotely stable release, expect errors and consider only the graver ones for report and make sure they haven't been reported, yet, and that they really are B-frames-related. Otherwise I fear we'll get flooded with so many reports, it will be hard to read all of them. Right now, I tend to change my mind and agree with Koepi that B-frame enabled builds shouldn't be made publicly available, anymore, even if this means I won't get one, either.

I think I should have chosen a better title... These problems really aren't severe as "woes..." implies. I didn't mean to imply that XviD B-frames aren't working, just that there are a few glitches here and there.

@Nic

1)Wow, it works!
2)Doesn't matter
3)Works, possibly just a one-time glitch, sorry
4)Previously solved
5)Eh? Why does this work now? I thought Teegedeck said that VDub wouldn't support it.
6)Still occurs occasionally
7)Still there. I just want to emphasis that this only occurs when B-frames are used in XviD...

[Nic]

http://nic.dnsalias.com does say 13/11/02 on mine (?). Maybe your browser is cacheing the page?

Strange. Try downloading it anyway & check the readme.txt that comes with it. If that says 13/11/02 in it then its the right one.

Cheers,
-Nic

ps
Anyone else seeing 11/11/02 instead?

@gldblade:
You & me posted at the same time :)
Teege was right....But we put something into XviD to handle it for now.
Ill try & work out why it would crash WMP (is that without using mine or any other filter then? just the xvid.dll?)

I guess milan will have to look into the ffdshow filter problem...
Glad its working better :)

[cult]

I refreshed my ie,even cleared history cache.Strange thing stills shows 11.But yhe build I downloades is 278kb whereas 11's build was 297kb,so guess it must be the new.I cant install it to be sure cause I am in a middle of encoding...

[cult]

sorry for the disturbance nic.It shows 13 now...

[iago]

@Nic

Yeah, it says 13/10/02 on the page but I'm not sure if it really "is" 13/10/02 binary, so I'm downloading it again and will take a look at the readme file.

iago

EDIT: I downloaded it as "13/10/02" but in the readme file it still says "11/10/02". Wouldn't it be better if you name the installation files with the date of the binary Nic? :)

[Nic]

Easiest way to check is, does it decode bframes? :D lol. Im pretty sure it should be right, sometimes ive had it cache on me (but its almost like its not my computer/software, but my ISP or something).

Cheers,
-Nic

[iago]

@Nic,

In the codec's "about" tab, it says Oct.11 (11/10/02) too, just like in the readme file :D.

iago

[MaTTeR]

hrm...copied straight from the readme file-
_________________
CVS 13/10/02

Changes:
new dev3-api build (with bframes)
QPel is implemented for motion search 6 (Ultra)
Decoder now decodes BFrames
_________________

Also the about tab is showing the proper date. Some how you guys got the older build. Strange.

[iago]

@MaTTeR

Yes, really strange! Although I downloaded and installed it again several times it still shows 11/10/02 build in the readme file and Oct.11 in the codec "about" tab ;). I guess I won't be able to use Nic's latest build! :D

iago

[MaTTeR]

iago,

Check your PM box.

[gldblade]

Woah, this thread exploded with the mention of a new build. :)

is that without using mine or any other filter then? just the xvid.dll?
Yeah, WMP crashes when exiting when using only xvid.dll. But don't worry about it. It's intermittent and there are probably more important things to worry about. Such as getting B-frames and Q-pel to work together. :) (Damn, intermittent problems are both hard to track down and reproduce...)

As for ffdshow crashing with "Decode using XviD" and B-frames, it may be related to ffdshow rather than XviD.

PS

Can anyone else verify these problems? I don't want Nic and milan to work unnecessarily.

[MaTTeR]

Originally posted by gldblade
As for ffdshow crashing with "Decode using XviD" and B-frames, it may be related to ffdshow rather than XviD.


Yes I can confirm this as well and I had just posted this in the ffdshow thread. The B-Frame encodes work perfectly with Nic's latest filter though.

Only thing I noticed was when seeking in the OGM file with B-Frames, large blocks appeared momentarily. This isn't a big deal of course, just never noticed it happening before. Other than that I'm still amazed at how well the B-Frames are actually working right now:) As always, many thanks to all the contributors who makes these builds possible.

Work week is starting, my weekend of massive testing is over I'm afraid:mad:

Edit- @gldblade, Did you notice any horizontal lines appearing during playback of your B Frames clip? I'm seeing a faint horizontal window shade like effect, mainly shows up in darker scenes but not in bright.

[dattrax]

Hi,

don't know if this has been reported before, but I was doing some testing of b-frames using monsters inc. I set the max number of bframes to 4 and left everything else as default. During the title sequence which can only be described as cutout paper moved on a black background there are pieces of colour left on the black background.

If it narrows it down, then the problem is exhibited within the first 400 frames.

It could be ffdshow, but equaly could be the encoding.

Jim

[Emp3r0r]

Edit- @gldblade, Did you notice any horizontal lines appearing during playback of your B Frames clip? I'm seeing a faint horizontal window shade like effect, mainly shows up in darker scenes but not in bright.Matter: funny you should mention this because when I did some tests last week with b-frames I noticed this in the Divx5 (b-frames only) encode. I didn't see it in any of the different settings used for Xvid on either B-frames, no B-frames or qpel. I'll check again with the updated decoder.

[dragongodz]

tested b-frames in Xvid with 1-pass cbr.
did some quick (short encodes) using nic's 10-13 build.
using "maximum b-frames" set to 1 reduced file size to roughly 60%.
setting to 2 reduced closer to 50%. very nice. these are compared to encoding with "Maximum b-frames" set to -1 (so no b-frames in other words).
"Packed bitstream" is where some wierdness happened. set "Packed bitstream" and "Maximum b-frames" to 1 and play back with Xvid and it appears in slow motion (its not really as the time taken and scene changes all happen on time). also on some scene changes the last scene wasnt cleaned up first so you have part of the old picture still there. set fourcc to DX50 (so Divx decodes) and it plays fine (speed) but the scene change problem is still there.
change "Maximum b-frames" to 2 and the scene change problem is fixed using both Xvid and Divx. the slow motion using Xvid decoding still remains though.
oh and file size with "Packed bitstream" and b-frames ? reduced down to roughly 30% of original size. as i also said, using DX50 fourcc plays it fine so it isnt missing frames etc that are the problem.

so can someone else try those out and see if they get the same things happening ?