Use QPel or BFrames?

[JimiK]

Hello I think this thread was unavoidable :)
I'm wondering if I should use QPel or Bframes in my next encodes, after they're not working together yet. After what I read in other threads, I had the impression, that QPel could help to make your image sharper and maybe the background more steady (second one is more guessed). Also it's said to decrease the filesize a little bit.
Bframes seem to result in a really noticable decrease in filesize. But that was with a setting of 200% where -h said that the Bframe quant would always be 4.
So has anybody an idea what would be the best for 1CD encodes and what for 2CD encodes? (I don't mind using ffdshow to decode Bframes).
If I find the time I'll do some test on my own, but I would be happy to hear from your experiences (iago certainly already did 10 encodes with different settings) :)

Thank you,
JimiK

[iago]

@JimiK

LOL! :D You're right pal. I've been asking the same question to myself since I downloaded Nic's 10/10/02 binary. And sorry but all my tests were with constant quant 3 so far, with QPel and with B-frames 2-%200 ;), and both seem very promising imho. Besides, neither cause any decoding problems (QPel -> Nic's DSF / B-frames -> ffdshow), which is really great. So it's really hard to choose which one to go with for a full 2-pass encode atm ;).

But I guess I'll soon start a full 2-pass with a 2hr hard-to-compress movie aiming for 1CD, using 512*288 / neutral bicubic / UltraHigh:6 (QPel) / h263 (together with lumoff=-2 and cpu=4 using Marc's MPEG2Dec3.dll) and no lumi, no Hinted ME of course ;).

Let's wait and see the results...

regards,
iago

[-h]

Just remember that while B-frames are decoding nicely with other MPEG-4 decoders, QPel isn't :)

-h

[Gaia]

Sorry -h, tried both ffdshow and divx5 decoders and they both couldn't decode b-frames right. Saw strange effects but i will try again. Also i got very very strange quantizer distripution, highest quantizer used for short clip was 24! QPel worked better but one short scene looked really ugly, lots of noise. This was just short test but anyway... I will do more testing but my advice, don't use neither b-frames or QPel for full movie, just try them for short clips.

[-h]

Sorry -h, tried both ffdshow and divx5 decoders and they both couldn't decode b-frames right.

Is that with the newest alpha of ffdshow? You may have to play with the packed b-frame options.

Also i got very very strange quantizer distripution, highest quantizer used for short clip was 24!

Yeah rate control with B-frames will be a bit funny.

-h

[HarryM]

Originally posted by -h
Sorry -h, tried both ffdshow and divx5 decoders and they both couldn't decode b-frames right.

Is that with the newest alpha of ffdshow? You may have to play with the packed b-frame options.

Also i got very very strange quantizer distripution, highest quantizer used for short clip was 24!

Yeah rate control with B-frames will be a bit funny.

-h

When I use 'packed bitstream'=ON, the video is from time to time crappy (mainly at higher max bframes)... Default setting + max bframes >=1 is O.K.

[cjv]

I find that with the latest ffdshow, DX50 compat=NO, packed bitstream=NO, and 2 b-frames @200%, it looks great.

Just finished Austin Powers 576x288, soft bicubic, 2-bframes@200%, 2-31 uncapped, internal linear, credits-20.
Target: 655858
Result: 655924
Quants:
Q:2:13220
Q:3:93819
Q:4:12765
Q:5:675
Q:6:98
Q:7:48
Q:8:7
Muxed w/Vorbis audio..result is great considering poor compresibility of Austin Powers...ended up at 66.3%

I had troubles with b-frames playback until I changed the FOURCC to divx/DX50.

cjv
PS Will try again with Qpel later today.

[serbersan]

I've done short clips from natural born killers with qpel, bframes and without any of them, all with constant quantizer 3. May results are :

Qpel: It's amazing, appears more and really noticeable detail, but the size it's in all clips slightly bigger. In a clip over 9Mb it's between 15kb and 120kb bigger the clip with qpel than the clip without it. Is this normal???

B Frames:
Maximum B-Frames: 2
Quantizer ratio: 200%
In some clips the decrease in filesize is no more than 7% in others until 10-15%, but the quality in scenes with more movement is really inferior... a lot and ugly macroblocks in fire or fast moving backgrounds. At 150% the blocks are less visible but they are there, and with 100% the blocks are almost gone but the quality in those scenes isn't as good as the version without bframes. Maybe I've made a mistake?? The differences in size between without bframes and bframes with Q ratio 100% are minimal and similar with 150%.

Maybe it's because I've used a constant quantizer 3 but the clips advice against the use of bframes totally.

[Manao]

I have some questions about Q-pel :

Qpel with Xvid does it work like qpel with DivX5 ? Especially, does it slowdown the decoding speed, and must we use it only with quarter resolutions ( ie 640*480 -> 320*240 )? and if yes, why?

[Acaila]

Who ever told you DivX5's Q-Pel has anything to do with resizing down to a quarter resolution?

[Manao]

In the Doom9's guide (http://www.doom9.org/divx5-vdub.htm), and also here (http://forum.doom9.org/showthread.php?s=&threadid=19205&highlight=quarter+qpel)

[TheXung]

This is a bold statement, but i'll say it anyway, doom9 is not always right. If more people would do their own testing instead of just reading about it, (1) we would have more people testing out a new feature, (2) more people would find that q-pel is really more of hit or miss feature on films (i.e. on DVD-ish resolutions, the q-pel artifacting usually isn't there on low quant encodes, and the amount of artifacting is really dependant on the actual movie.

People are lazy, so they like general methods that they can follow and be able to get good encodes the first time around. As a result, any new feature that doesn't give better encodes all the time tends to not ever get used or further tested. However, that does not mean that there aren't movies that greatly benefit from the feature. Then again most people would never even know what they're missing.

[Manao]

@TheXung : I have to admit, I never tested DivX5. I always used Xvid since its beginning, mainly because of its easyness ( compared to DivX3 ). But when I read the DivX5 forum, to learn a little more about qpel, all I found was a feature that gives unexpectable results, depending of the machine we playback on, in a way nobody could explain ( or I didn't search enough ). I agree with you when you say that all new features can't improve the things all the times, but at least, we should expect to understand a little bit how they work.

[Nic]

In defence of Doom9, I must say that he has to write these things quickly to keep up with current events & he is not a codec developer. So he has to go on what others advise him. So its not Doom9s fault, however it is the fault of people that state things without knowing what they are talking about.

Im glad to say that doesn't ever really happen in the XviD forum :) But ive seen it elsewhere.

Also on guides Doom9 does not always author the whole guide. The XviD guide has a bit of my writing in there (it is a lot harder than it looks! I didn't do a very good job...so if you dislike the xvid guide..blame me! :) )

But anyway more on topic, ill run some tests tomorrow to see the impact on QPel decoding in XviD. But I dont think ive noticed any impact at all...(but I do use a 1ghz computer, so maybe I wouldn't notice.)

Take Care,
-Nic

[cjv]

For now, I would definately have to put my vote in for b-frames...the results are just unbelievable!
For example (first pass sizes):
No b-frames, 640x272, h263, lanczos: 1,671,786
2-bframes @200%, 704x304, h263, lanczos: 1,337,168

Compressibility went up from 61% to 94% @ 704!
Visual result is MUCH better with the 704x304 b-frame encode, probably due to keeping the full anamorphic resolution.

Hopefully we will be able to use the MPEG quant with b-frames soon, I doubt it will hurt compressibility that much, and will give an even sharper picture!

cjv

[TheXung]

I don't place any blame on doom9; he has to write guides for "the masses". There needs to be clear, concrete steps in his methodologies, steps that always lead towards better encodes, not a hit or miss implementation of q-pel. What annoys me are people repeating "partial truths" that they have hardly verified.


here are certains things I've noticed about DivX's q-pel:
pros:
- On some scenes, it will give a smaller filesize. Some will produce a slightly larger filesize but it's really fractions of a percent larger.
- It has a sharpening/detail preservation effect. Film encoded through it will often come out sharper than the original, at virtually no cost in filesize.
- q-pel tends to work well in somewhere in middle and dark films.


cons:
- It is slower to encode, but the performance hit of q-pel alone is not that much more than the performance hit of b-frames. What really causes a performance hit is the use of b-frames and q-pel together, but to be honest, a first pass on my 1.4 ghz goes at 14~16 fps while using lanczosresize which is less than 2x movie length. Has everyone been that spoiled in speed that they can't tolerate the wait?
- q-pel tends to produce "artifacts" in bright films. Namely, the characteristic look of teen movies. Bright background, colorful characters, I dunno, it just doesn't work well with those for some reason.
- q-pel tends to also produce artifacts when the quant gets high. For movies with an average quantizer of high 4's or higher, I usually check the movie for artifacts.



There seems to be some quality "bugs" in Divx's implementation of q-pel. In all theory, q-pel should never worsen quality at a specific quant but it does on some (one that comes to mind is American Pie 2). However, there are movies that do benefit from q-pel and you do get better quality using the feature than if not. To name a few, Magnolia, A Knight's Tale, The Others, X-Men. In fact, The Others, doing the whole movie at DVD res with quant 2 and b-frame quant 2, came out to only 516 MB video. This file size was not achievable without q-pel, though I don't remember how large it was.


P.S. All my observations are from 1-CD rips using b-frames as well.

[TheXung]

I don't trust ffdshow to properly decode DivX q-pel. There are issues with the two working together. When ever I install Divx, it always has the postprocessing automatically set to 2 or 5. Perhaps it is a combination of these inconsistencies to cause different output on different machines. From my experience, everyone on campus who I've played q-pel movies on has reliably reproduced the right output.

[tanksimpson]

Dunno if anybody is interested, but I just used the Envivio plugin to play back an xvid mp4 clip (Chapter 15 of The Matrix) encoded at quant=2 with qpel (6-Ultra High, H263) and b-frames (1, 200%) and muxed with mp4ui (mpeg4ip 0.9.5.1) and the result was... perfect. Nice job XviD team! There is a tiny bit of faint mosquito noise around the edges if you stick your nose up to the screen, but this is to be expected with b-frames, right? I remember a while back that some people were saying that DivX's b-frames were not strictly mpeg-4 compliant, and that's why they don't work with the Envivio plug-in. This, in and of itself, has me leaning towards using XviD for all my mp4 encodes.

[lat3ralis]

Interesting,

I just made 2 mpeg4 compliant samples, one with qpel and one with bframes. Envivio managed to decode the bframes sample fine, but it displayed weird artifacts with the qpel sample.

lat3ralis

[Gazza]

Originally posted by TheXung
cons:
- It is slower to encode, but the performance hit of q-pel alone is not that much more than the performance hit of b-frames. What really causes a performance hit is the use of b-frames and q-pel together, but to be honest, a first pass on my 1.4 ghz goes at 14~16 fps while using lanczosresize which is less than 2x movie length. Has everyone been that spoiled in speed that they can't tolerate the wait?


I have just completed two encodes with Nic's 7 Oct binary and I noticed that the fps dropped from 11/12 down to 7/8 for a non B-Frame encode. And it dropped to 4/5 fps when I set Max B-frame to 2. I have a 1GHz machine so it's nearly up to yours and I wouldn't expect such a drastic drop in performance. I had 6-Ultra High, MPEG and b-frames at 2, 200%.

Has anybody else noticed a similar drop? Is there something I missed setting that has caused the drop in speed?

I will continue to test but am interested if anyone else is seeing this as well. Note the quality difference with and without B-frames was not noticeable and the file size reduction was only a few Mb's.

[Koepi]

You can't use QPEL _and_ bframes in xvid (unstable).

There's no qpel bframe code in it, when using bframes, qpel is simply not working/used.

I thik it's time to take down public development binaries as everyone is just usng them without reading the posts about the issues involved with that :(

Koepi

[glenn]

I thik it's time to take down public development binaries as everyone is just usng them without reading the posts about the issues involved with that

Please don't lose faith in all of us, there are still those that appreciate what an experimental developer build is, and don't expect developers to play helpdesk.

[Nic]

@Koepi:
I know how your feeling, it almost feels like we should password protect the dev3 api builds & only give it out to those we can trust (iago, rui, etc). But that would be silly (& we'd only get other people trying to compile it & at present its a bit more complex to compile correctly, so that would cause more problems).
All we can do, I guess, is keep on reminding people :)

Cheers,
-Nic

[Teegedeck]

I also feel that there's been an overwhelmingly positive reaction on the b-frames- and q-pel-activated builds. Everybody's celebrating...

We've always had some ignorants, it's not exceeding our usual level ATM, I believe.

This is the time for all people involved in the XviD project to receive the thanks of an applauding audience and relax for a moment. Take my thanks for your great work, developers of my favourite piece of software!

[MaTTeR]

I'm with Teegedeck on this one:) Outstanding work the XviD team is cranking out. Many thanks for all the effort guys.

The Qpel implementation in XviD is very impressive considering I'm virtually seeing no real CPU usage increase during decoding. Keep up the good work!

[cult]

should mv hints with qpel or with b frames?Everytime I enable it with qpel or bframes I get a crash

[Koepi]

MV hints doesn't work with them. Even if you don't get a crash (e.g. with qpel only, as written above, qpel and bframes are an exclusive OR at the moment), your encode will mess up.

Koepi

[rui]

So, for testing only b-frames we should choose motion search 5 (no qpel), no HME or lumi, correct?

EDIT: Nic, i for one am in favour of everybody to have access to the dev builds. I think that most people on this forum are smart to know that it's name (dev) alone means that it could have some little bugs.
I guess that the more testers the better.

[Koepi]

<repeat>If you activate bframes, qpel isn't used as there is no qpel code for bframes.</repeat>
Thus, setting motion search precision to 5 doesn't change much - you can use sp6 but it hasn't qpel for bframes activated. It might have other results than sp5 as between the i+pframes there can be qpel ME, but I've to look deeper in the ME sources to see if with bframes activated this code still gets used for those frame types.

Regards,
Koepi

[Gazza]

Koepi & the other developer's,

I also appreciate the huge amount of effort and huge advances achieved. B-frames (even though a little buggy) is very much appreciated and I am always (most of the time) around to do some testing and feed back the results.

Keep up the excellent work.

Gazza

[iago]

@Koepi and Nic ;)

First of all, I really would like to thank both of you for providing all XviD users with the opportunity of testing the new/currently experimental features of QPel and B-frames with your new dev builds.

I'm about to start the second pass of my current encode with Nic's 10/10/02 build using QPel (6.UltraHigh) and h263 quantization type (no lumi, no MVH), together with cpu=0 and lumoff=-2 with Marc's MPEG2Dec3.dll and also with convolution3d to increase compressibility and get rid of some source artifacts, which are really big problems with my current encode ;).

I'll report back the results and my impressions when finished (after watching the resulting file using Nic's DSF ;).

And finally I want to say -after some short 2-pass test encodes with B-frames 2/%200 and using ffdshow to decode- that though B-frames "might" improve the overall look of the encode by increasing compressibility considerably, it "might" also decrease the quality of certain scenes (with some motion in my case) by introducing obviously more blockiness.

In my short 2-pass tests with QPel, I had no problems actually and this feature seems to work well for me so far ;).

Well, that's all for now!

And I wanna finish my words with many thanks again for your invaluable efforts!

best regards,
iago

[Koepi]

You're always welcome, iago :) As our official serial tester you should get some medal or similar :)

Just wanted to note that overflow / curve treatment isn't rewritten for bframes yet, so the artefacts you're experiencing with 2pass/bframes are caused by curve compression going nuts :-/

try bframes in 1pass quality / fixed quant and you'll see what I mean.

Take care my friend,
Koepi

[vlad59]

Originally posted by Koepi
You're always welcome, iago :) As our official serial tester you should get some medal or similar :)

Yes I totally agree, we should give a medal to iago the famous "serial tester" (IIRC I was the first to give you this nickname).

It's really a pleasure to code/build binaries when you know you can rely on someone to make complete tests.

Thanks again iago, take care....

PS : I'm beginning a second pass on a very noisy anime with bframe.

[Teegedeck]

Testing two-pass with B-frames a bit, it all works nicely at lower quantizers, in spite of the lack of a proper rewrite of of the two-pass code that Koepi mentioned. Letting XviD insert up to 8 B-frames in a row ain't yet the thing to do tho:rolleyes: And I think I see a nice side-effect of B-frames; I had visibly less ringing in some low-motion scenes with B-frames activated than in the same scenes with B-frames deactivated (at quantizer 3 - using the hvs-best quantizer that I don't exactly know for suppressing such stuff). I'll have to make some more encodes to be sure. But anyway, XviD's implementation of B-frames is so good; I honestly didn't expect it to be THAT good!

[iago]

@Koepi and vlad59,

Heya friends! Guess I'm losing my power and turning out to be a fallen-serial-tester recently, since I'm over-busy/over-exhausted these days in real-life, mostly due to some extra responsibilities at work ;).

Anyway, out of curiosity and impatience (thanks to my fantastic Celeron900) I cut my problematic 2-pass encode that I'd mentioned above half-way through the second pass and watched the resulting avi. Unfortunately, I must admit that (with the parameters stated above) the half-encode (;)) came out really crappy! And the worst thing is that I cannot make sure now if this disappointing outcome is due to some QPel problems or my convolution3d settings (1,6,8,6,8,2.8,0) or both. It may even be that the cause is none of the above but the crappy (though not much noisy), compression-resistant ;) source itself. Well, I don't know actually. In some short tests QPel had worked fine for me, but now my experience is very similar to Acaila's problems mentioned in another thread (blocks and blocks and blocks, especially over the skies ;))...

I think I'll go on testing B-frames and QPel only after I encode this trouble-movie using a stable build and make it come out as acceptable as possible! ;)

ciao everyone,
iago


P.S. @vlad59: Unfortunately I don't have noisy enough sources these days for your great filter to perform its job perfectly! And I'm still looking for generally-agrreable-upon-values to use convolution3d with clean DVD sources that are hard to compress / or with sources that are not already very compressible. I'm still for something like (0,4,4,4,4,3/2.8,0). best regards.

[ReferenceDivx]

Great work Xvid coders. I know that coding takes some serious thought and conmitment. I finally got my jpeg coder to work(I think there might be a bug in the msvc compiler). So I hope to have a custom matrix program done over the next few days.

Keep up the good work guys!!!!!!!!

[Rrrough]

:) Yippie :)
i also want to thank all developers for the new toys !
been away for over a week, coming back and still can't believe those giant leaps in development ! WOW !
just one question from a curious mind : are custom quantization incompatible with b-frames ? I did a test clip w/ b-frames 2/200 both with and without cust-quant-matrices, the resulting clips had the same size and visual quality...!? with qpel, custom quants seem to work ! I was just dreaming of spending those saved bits with enabled bframes on a better quantization.
ANYWAY !!! GREAT WORK GUYS !!! :D

[Teegedeck]

Originally posted by Rrrough
just one question from a curious mind : are custom quantization incompatible with b-frames ? Duh! :o This would explain the 'smoothered look' I got on my test-files...

[serbersan]

Originally posted by Koepi

Just wanted to note that overflow / curve treatment isn't rewritten for bframes yet, so the artefacts you're experiencing with 2pass/bframes are caused by curve compression going nuts :-/

try bframes in 1pass quality / fixed quant and you'll see what I mean.


I'm not sure if you have read my post but I've used 1pass fixed quant and I have the same artifacts (blockyness) in fast motion and moving backgrounds.

Have you ignored it??

[unplugged]

Does B-Frame value with XviD encoding mean only a limit or it sets a fixed pace for ex. like IBBPBBPBBPBBP? (when set to 2)
P.S.: For the moment the AVS script DirectShowSource("myvideo-just-encoded-with-Bframes.avi",25) seems the solution to analyze B-frame result with VirtualDub,
HEEEY! They looks greatly homogeneous even with 2 & 200% !!! :eek:

Yes, this result has really nothing to share with DivX B-Frame implementation ;)

[Koepi]

@unplugged:
BFrames are inserted "dynamically", e.g. if you set them to 8 and have a high motion scene, the resulting sequence can be IPPPPPIPPBPPI (wow, weird to read).

@Nic, -h, Foxer, sysKin, Isibaar,...:
For proper 2 pass treatment we need a new flag that tells us what's a bframe - any objections here against a #define NNSTATS_BFRAME (1<<30) in NNS.drf ? I think the curve treatment can be adopted relatively easy.
I need to send out another mail so Michael Niedermayer helps with his huge knowledge to find out min. framesize for bframes (it looked like 8 bytes to me, but I'm not sure).

Hm, plenty things in 1 post ... ;)

[Didée]

After I finally was able to put 'Contact' within 800MB, I analysed the 2-pass dbgview-logs.

(BTW: 'Contact' was 656*272, had a b/p*f of 0.16, and with Bframes=2/200% it came out with an averagequant of 2.7 or so ... YUMMY! It looks really great! Some filtering against the heavvy EE was used.)

Okay, about 2-pass. Nic's 10-10 build was used.

It's obvious that, with the current implementation, overflow treatment is a little funny. Not surprising.

BUT, from the logs, it seemed to me that in 2nd pass a fair amount of I-frames are not inserted in the right place.
Looking at xda's output, a lot of I-frames seem to be put 1 or 2 frames after the corresp. scene change.
Furthermore, the codec was not interested at all in my max. I-frame-distance: it was as high as 400 or 500 frames in some places, were I had set it to 200.
Investigating this a bit more, I found that some scene changes (hard cuts) had no I-frames at all.

(Remember, that was only the analyse of xda1.6. I could not cross-check in Vdub, 'cause it can´t read XviD+Bframes directly, and via avisynth/dshowsource, the clip consists of 100% I-frames ...)

So, there are some points yet to solve.
But, looking at what can be done so far, I feel like in a dream ...

IT'S AWESOME WORK, GUYS!!!

Looking at Divx5, my grinning gets only bounded physically by my ears ;)

[sysKin]

Originally posted by Didée
BUT, from the logs, it seemed to me that in 2nd pass a fair amount of I-frames are not inserted in the right place.
Looking at xda's output, a lot of I-frames seem to be put 1 or 2 frames after the corresp. scene change.[/B]
I'm pretty sure that this is all because of the hack used to store Bframes in AVI.
When codec recieves first frame of the new scene, it:
- detects scene change
- codes all B-frames stored in memory *and outputs them to avi*
- the last frame before scene change is coded as P frame, and put to avi. This is not done if "divx5 compatibility" is off but should be done, so use divx5 compatibility as it's better that way
- then, I frame is created and put to the stream. As you can see, it's delayed. There is not much we can do about it. The good news is that this is correct - it's exactly in the place where it should be. No need to worry about your movies :)