What happened to Rv40 support in FFmpeg?

[iwod]

Just wondering coz all of sudden things seems to die down.

[iwod]

What ever happen to it? It seems we are so close yet so far away

[karl_lillevold]

I would also like to know the latest news on that :)

[Reimar]

I would also like to know the latest news on that :)

The code is in there, it just is incomplete and thus disabled unless you change the Makefile etc. by hand.
As I understand it, the person implementing it is waiting for (parts of) the "specification" of the RV40 inloop filter from someone else.
The picture it produces is recognizable but not much more.

[Kurosu]

More precisely, he would be trying to discover which JVT standardization meeting for H.264 this inloop filter is based on. The 1/3-pel MC filters in particular were a funny finding.

(note: this someone isn't me)

Karl, any pointer? ;-)

[Reimar]

Patches for the in-loop filter are on the FFmpeg list. Not sure if anything else is missing...

[bond]

rv40.c has been comitted to ffmpeg svn (havent tried whether it actually does anything already):
http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/rv40.c?sortby=file&view=log

kostya has posted a patch to enable it:
http://svn.mplayerhq.hu/soc/rv40/ffmpeg-rv.patch?sortby=file&view=log

moved and merged, as double posted in wrong forum

[karl_lillevold]

As I understand it, the person implementing it is waiting for (parts of) the "specification" of the RV40 inloop filter from someone else.

1) The RV30/RV40 specification is not available unless you have signed an agreement/license at helixcommunity.org. It is a breach of the license to share this licensed specification with anyone.

2) The VLC tables are not in the specs, and can not be reverse-engineered from binary code. They have to have been copied more or less verbatim from source code, licensed from helixcommunity.org

I am not a lawyer, but it should be pretty obvious that publishing stolen material is problematic from a legal point of view.

That's probably all I am going to say about this issue.

[Dark Shikari]

1) The RV30/RV40 specification is not available unless you have signed an agreement/license at helixcommunity.org. It is a breach of the license to share this licensed specification with anyone.

2) The VLC tables are not in the specs, and can not be reverse-engineered from binary code. They have to have been copied more or less verbatim from source code, licensed from helixcommunity.org

I am not a lawyer, but it should be pretty obvious that publishing stolen material is problematic from a legal point of view.

That's probably all I am going to say about this issue.Note of course that in most of the world, such reverse engineering is completely legal. But if Real doesn't want anyone to use their software or standard, I don't think most people are going to complain about it... they'll just continue to not use Real software ;)

Also, statements like "cannot be reverse-engineered" are almost guaranteed to be false. It would be more accurate to say that "nobody cares enough about RV30/RV40 to reverse-engineer them."

[karl_lillevold]

Yes, I am aware reverse-engineering is legal in most of the world. What I was trying to say is that in this case, both the specification (see earlier post in this thread), and original source code, have been used to implement the decoder. This is not reverse-engineering.


Also, statements like "cannot be reverse-engineered" are almost guaranteed to be false. It would be more accurate to say that "nobody cares enough about RV30/RV40 to reverse-engineer them."
I can not go into details about my statement in this regard in a public forum.

[karl_lillevold]

And of course, in most of the world, the kind of license agreement you described that prohibits reverse engineering is--again--not legal.

Hmm, I can not see how my posts say anything about licenses that prohibit reverse-engineering. The licenses I mentioned are for the specification and the source code. I am sure RealPlayer and Helix binary decoders are shipped with other kinds of licenses, that probably discuss reverse-engineering, like all other binary software licenses do (at least in the U.S.)

From my personal point of view, the more ways to play RealVideo, the better :) I have been using realmediasplitter myself since it first came out, and ffdshow is in use daily on all my computers..

[iive]

...As I understand it, the person implementing it is waiting for (parts of) the "specification" of the RV40 inloop filter from someone else...


More precisely, he would be trying to discover which JVT standardization meeting for H.264 this inloop filter is based on. ...

1) The RV30/RV40 specification is not available unless you have signed an agreement/license at helixcommunity.org. It is a breach of the license to share this licensed specification with anyone.

2) The VLC tables are not in the specs, and can not be reverse-engineered from binary code. They have to have been copied more or less verbatim from source code, licensed from helixcommunity.org

I am not a lawyer, but it should be pretty obvious that publishing stolen material is problematic from a legal point of view.

That's probably all I am going to say about this issue.

I think you got it all wrong.

Kostya have found out that some of the obscure features of rv30/40 have been proposed for inclusion in H.264 and could be found in early drafts of the H.264 standard. Most of them seem to have been dropped during the standard refinement.

He (and pretty much everybody from the community) had no idea that useful official specification from Real are available in any form. Nobody have told us (is that part of the NDA/License?), nobody dared to send us copy and obviously Kostya haven't signed his soul to Real.
AFAIK helix framework source includes codecs that are already well known or obsolete.

The current rv30/40 code is entirely result of clean-room code implementation, collaborative reverse engineering and (preferably) implementation of (rejected) JVT drafts.

So let's get back to the topic.
Karl, do you know if r30/r40 loopfilter have been proposed for inclusion in H.264 and do you think you can narrow the H.264 drafts that should be checked in order to find that info?

[Reimar]

Yes, I am aware reverse-engineering is legal in most of the world. What I was trying to say is that in this case, both the specification (see earlier post in this thread), and original source code, have been used to implement the decoder. This is not reverse-engineering.

I have not said specification but "specification" with quotation marks (I do not intend to say anything about the details of these efforts since I have only a very superficial idea of them, but a specification is the usual mid-step of clean-room reverse-engineering), and nobody has said anything about source code. This is really the kind of accusation you should never, ever make without double-checking your facts.

[karl_lillevold]

iive: Thanks for explaining these details. From my personal point of view, that's a very impressive effort!

RealNetworks did indeed actively contribute to the development of H.264. Some proposals were included, some included and refined, and some rejected. For instance, RealNetworks contributed CAVLC to H.264, but never used anything remotely like it in rv30/rv40. Another feature of H.264 contributed largely by RealNetworks, was intra prediction.

One reason for my post was to figure out some of this information, but then I should have of course have worded it differently. I am sorry I misunderstood the use of the word specification earlier in the thread. Regarding the second issue, I pointed this out due to certain details that are used in the binary releases of the decoder, and the Helix source code, but I will leave it at that and not say or do anything more about it. (yes, the source code to rv30/40 has been licensed to a large number of entities (https://helixcommunity.org/licenses/partners) - as of now, 264 for porting and optimization, and 88 for commercial use)

Karl, do you know if r30/r40 loopfilter have been proposed for inclusion in H.264 and do you think you can narrow the H.264 drafts that should be checked in order to find that info?

Best of luck in figuring out what is missing. I am sure it can be worked out, but I am afraid no H.264 drafts, documents, or proposals describe this well.