XviD B-Frames Compile

[SirDavidGuy]

I got bored, so I thought I'd make one.

http://sirdavidguy.tripod.com/xvid_bframes.html

It's working very good now, try it.

[Koepi]

XVID BFRAMES ARE STILL PRE ALPHA

EXPECT UNUASUAL THINGS TO HAPPEN - AND YOUR ENCODING WILL LOOK LIKE SHIT.


Please, you shouldn't use too immature features and tell about the risks.

Wanna be yet another binary distributor?

[SirDavidGuy]

EXPECT UNUASUAL THINGS TO HAPPEN - AND YOUR ENCODING WILL LOOK LIKE SHIT.

Mine don't ;-)

Wanna be yet another binary distributor?

Hell no.

I have enough people angry at me already, to try and give away software and not offer support.

[Koepi]

"Also note that when using 2-Pass mode, set the maximum number of B-Frames to -1, and in the second pass, set them to 1."

Erm.
you're abusing rate control for things which it isn't supposed to handle. This will severely degrade quality in the wrong places. First pass and second pass should be _identical_ with settings which affect the compressability, I can't stress this enough, and it should be a very well known fact since _nandub_.

Kind regards,
Koepi

[SirDavidGuy]

I'll change it if you want, but my (single) test showed no noticeable difference, and it sped up encoding.

I'll do another one a different (and much longer) clip; my first was only about 30 min.

[SirDavidGuy]

B-Frames in the first pass are very unstable, it seems.

So I'll still stick with having them off, then.

[Edit: With the number of times I tried it, without success, I'm thinking that I probably made a mistake when I did the first test, and that B-Frames in the first pass weren't ever enabled.

This would explain why the two tests looked the same; they were.]

[Koepi]

See, this is why they're still experimental and not recommendet to use. Those things have to be fixed amongst some others (the resulting bitstream is NOT mpeg4 compliant yet, there's still some weirdness with the time counters etc).
It resulted in gruel asking me to take down any bframe related stuff.

Your way (1st pass without bframes, 2nd pass with them) is a no-no in quality terms. The bitrate curve scaling is somewhat wrong, as I mentioned above, spending bits on the wrong scenes, taking it -again- from the wrong ones.

I just want this to be VERY clear, and I'd like to ask you to give at least these remarks on your page - or even do as the xvid core developers prefer...


Regards,
Koepi

[SirDavidGuy]

or even do as the xvid core developers prefer...

Very well.

But I'm still not entirely sure that the bitrate curve is too terrible. It will give much better quality once optimized, point taken, but still improves the overall quality of the movie (IMO); I think that B-Frames helped it more than than the worsened CC hurt it.

[SirDavidGuy]

The bitrate curve scaling is somewhat wrong, as I mentioned above, spending bits on the wrong scenes, taking it -again- from the wrong ones.

Could it be fixed by doubling (Or multiplying by the B-Frame Quant Ratio) all the B-Frame quants on the first pass? Shouldn't be too hard, I'll try it sometime tommorow or the day after.

[Koepi]

I'm sorry to say this again, but unfortunately this stuff isn't so easy to predict.
We wouldn't need any new codec if it were that easy...

Good luck with that attempt anyways, and be careful not to sell it as hyper-hyper again and remind the people that they're dealing with experimental, non-MPEG4 stuff.

Thanks, also for your work,
Koepi

[Nic]

Also to point out, its not my DShow filter but XviD that has the problems decoding the B-Frames :D

-Nic

[SirDavidGuy]

, and be careful not to sell it as hyper-hyper again and remind the people that they're dealing with experimental, non-MPEG4 stuff.

Sorry to be so ignorant, but what is "hyper-hyper"?

Something that's really good?

[Koepi]

heh, a weird song by scooter (bad, bad techno). I thought it was international, sorry :)

It was meant as: please don't hype it, as it is still somewhat broken.

Regards,
koepi

[Nic]

@Dave:
Like your site :) I once ported r!sc's sd2 code to C, so thats a very nice little resource for info on that type of thing ;)

-Nic

[primitive]

!

Please go on and keep this xvid build around, at least for another day or two. I want to test QT6's mp4 capabilities, and apparently it doesn't like it unless you use a b-frame build, even if b-frames are disabled.

-p

*edit* If I were to use QT6 as my media player, it wouldn't use my DS filters, would it?

[SirDavidGuy]

Like your site[/B]

/me blushes

Please go on and keep this xvid build around, at least for another day or two. I want to test QT6's mp4 capabilities, and apparently it doesn't like it unless you use a b-frame build, even if b-frames are disabled.

If you really want it, you can e-mail me, but also remember, you can't accues Quicktime of not being MPEG-4 compliant for not playing non-compliant streams.

[sherpya]

Originally posted by primitive
!

Please go on and keep this xvid build around, at least for another day or two. I want to test QT6's mp4 capabilities, and apparently it doesn't like it unless you use a b-frame build, even if b-frames are disabled.

-p

*edit* If I were to use QT6 as my media player, it wouldn't use my DS filters, would it?

QT6 Player worked with xvid files for just follow everwicked guide to mpeg4ip tools
There is also a guide on doom9:
http://www.doom9.org/mp4.htm
Should also work.

[mac1929]

edgomez is making some surprising modifications to XviD code. As the todo.txt file says it seems that the final purpose is to get an stable version of XviD and to fix headers and copyrights. As a consequence Bframe code and SMP are being removed.

I hope this features will return sometime ;)

[-h]

edgomez is making some surprising modifications to XviD code. As the todo.txt file says it seems that the final purpose is to get an stable version of XviD and to fix headers and copyrights. As a consequence Bframe code and SMP are being removed.

There are now two branches in the CVS - "stable" and "dev". Gom is working on stripping out all the dev stuff that really doesn't belong in the stable branch, and all the fun new stuff will be in dev. Of course it will probably be bug-ridden, which is why it's in dev and not stable.

Big changes will happen in dev..

-h

[vla]

Probably a stupid question but is the 'dev' branch open to mere mortals as well ?
(and how does one access it ?)

-V

[-h]

Probably a stupid question but is the 'dev' branch open to mere mortals as well ?

Sure.

(and how does one access it ?)

You check out the modules from cvs as per usual (well only xvidcore at the moment), just specifying "dev-api-3" as the branch/tag.

-h