Hypothetic question about x264!

[Romario]

Hi guys, I am glad that I can ask questions on this forum, and get answer very soon?

My hypothetic question is:

If someone(not I) build new x264 build with new algorithms, which include 1/8 frame search(instead current qpel search), will such version of codec improve picture quality on very low bitrates(100 to 200) very much, or that won't be the case?

Please don't laugh if my question is obsolete, simply I want to know. :stupid: Thank you.:)

[Tommy Carrot]

Well, considering that JVT removed 1/8 pixel (not frame) precision from the spec cuz in their experiments the potential quality improvement couldn't justify the increased complexity, i would say it wouldn't help much.

Also it wouldn't be h.264 compliant anymore.

[Romario]

Well, what is your opinion, Tommy? How to improve picture quality on very low bitrates(under 200) in future specification of H.264 standard?

Perhaps someone must introduce some new compression tehnics.

[bond]

there are custom quant matrices, there are also custom deblocking matrices...
i think the possibilities of avc are not fully used yet

[Tommy Carrot]

Well, what is your opinion, Tommy? How to improve picture quality on very low bitrates(under 200) in future specification of H.264 standard?

Perhaps someone must introduce some new compression tehnics.
Curvelet, Bandelet, etc. seem to be the next big thing in image compression, they can be much more efficient than the currently popular transforms (dct, wavelet), although i'm not sure they can be effectively used for video compression. And they have nothing to do with h.264. ;)

[sysKin]

How to improve picture quality on very low bitrates(under 200)
The lower bitrates, the bigger relative cost of having motion vectors. So I'd say the quality will go down unless there's some way of disabling 8th-pel when it's harmful.
in future specification of H.264 standard?
This will no longer be h.264 will it :)

[foxyshadis]

Curvelet, Bandelet, etc. seem to be the next big thing in image compression, they can be much more efficient than the currently popular transforms (dct, wavelet), although i'm not sure they can be effectively used for video compression. And they have nothing to do with h.264. ;)
Damn it, I had things to do tonight. Now I have to spend all evening knee-deep in research again! (I love this stuff.)

[bugmenotwillyou]

@Bond

This is off-topic, but the quote in your signature is not from Jean-jacques Rousseau but from Henri Lacordaire.
Full french quote is:
"Entre le fort et le faible, entre le riche et le pauvre, entre le maître et le serviteur, c'est la liberté qui opprime et la loi qui affranchit."
see wikipedia
http://fr.wikipedia.org/wiki/Henri_Lacordaire

Just thought you'd like to know :)

As for your Socrates quote, I guess you already know that Socrates didn't wrote ANYTHING. All the quotes are actually reported by some of his disciples, mainly Plato who wrote many dialogues where Socrates is a character. There is no way we can know for sure if Socrates actually said all those quotes reported or not.
As far as I know this text is from The Apology Of Socrates by Plato. One of the first dialogue written by Plato which relates Socrates' trial. It's an interesting and easy reading which I suggest you.
Life is not only about h264 and so on...

[pest]

@Tommy Carrot

the papers i read showed very descent improvements.
some of the transforms work in wavelet-transform-space
too. they only improve upon wavelets because they
add some sort of geometrical ordering to the coefficients,
because wavelets work best at smooth regions. they are also
far too slow for a videocodec. try to implement an
ececow-type coder at realtime. that would be an
real improvement to an existing wavelet-codec like
snow but again it's far too slow. video-coding is a beast.

[emmel]

because wavelets work best at smooth regions.


Isn't the idea of wavelets just the opposite? Like they are good for compressing fingerprints, where dct-based methods like jpg sort of fail? Everything works well on smooth stuff...

To the original question: isn't 100k a bit modest nowadays? My cell-phone can handle that :)

[pest]

Isn't the idea of wavelets just the opposite?


no! you can improve the performance on edge-regions
if you decrease the number of vanishing moments.


Like they are good for compressing fingerprints, where dct-based methods like jpg sort of fail? Everything works well on smooth stuff...


the wavelet-transform (like many "new" transforms) itself does
not provide a significant improvemt over the dct. the
improvent you see in image-coding is mainly because of
improved coders like ezw and spiht. you can transform
the output from a 8x8 dct to a 3-level band-split
and it performs near as good as the wavelet transform.

[emmel]

no! you can improve the performance on edge-regions
if you decrease the number of vanishing moments.

Well, an edge is the opposite to smooth.

the
improvent you see in image-coding is mainly because of
improved coders like ezw and spiht. you can transform
the output from a 8x8 dct to a 3-level band-split
and it performs near as good as the wavelet transform.
Ok, I'll have to study that. Sounds good, if the basis really produces a more compressible set of coefficients with less entropy. Back to school :)
emmel

[Tommy Carrot]

@Tommy Carrot

the papers i read showed very descent improvements.
some of the transforms work in wavelet-transform-space
too. they only improve upon wavelets because they
add some sort of geometrical ordering to the coefficients,
because wavelets work best at smooth regions. they are also
far too slow for a videocodec. try to implement an
ececow-type coder at realtime. that would be an
real improvement to an existing wavelet-codec like
snow but again it's far too slow. video-coding is a beast.
I'm not saying they are always better, but they are trying to fix probably the biggest weakness of wavelets, the "blurry edges" problem. In some cases the ability to keep the edges and lines sharp even at low bitrates can make quite a big difference. The performance issue might be true though.

[Kostarum Rex Persia]

My hypothetic question is:

If someone(not I) build new x264 build with new algorithms, which include 1/8 frame search(instead current qpel search), will such version of codec improve picture quality on very low bitrates(100 to 200) very much, or that won't be the case?

Hmm, interesting thoughts, Romario. You certainly have some good ideas.:goodpost: I think that 1/8 pixel and frame search isn't possible, at this moment. :(

Of course, someone may try to build such complicated codec, but not very soon.:(

[berrinam]

Hmm, interesting thoughts, Romario. You certainly have some good ideas.:goodpost: I think that 1/8 pixel and frame search isn't possible, at this moment. :(

Of course, someone may try to build such complicated codec, but not very soon.:(Seriously, Kostarum Rex Persia, why do you do this? You go around constantly asking for improvements in everything, in places where people say repeatedly that no improvements can be made? The creators of the H.264 standard showed that 1/8pel is mostly negative, as Tommy Carrot said:

Well, considering that JVT removed 1/8 pixel (not frame) precision from the spec cuz in their experiments the potential quality improvement couldn't justify the increased complexity, i would say it wouldn't help much.

As I have said before, your posts are simply spam, so you are breaking either rule 5:

5) Do not spam.

or rule 11:

11) Don't post just to increase your number of posts

or both. Stop it, it's a waste of time.

[Kostarum Rex Persia]

Seriously, Kostarum Rex Persia, why do you do this? You go around constantly asking for improvements in everything, in places where people say repeatedly that no improvements can be made?

I just thinking about future standards, I am not spamming here. I am sorry if you get wrong impression.:cool: