x264 in Cucusoft Video Converter

[agayar]

Hi,
I've downloaded the Cucusoft IPod Video converter and I wonder which codec it uses to encode the H.264 video. After looking up the distribution, I’ve found an avcodec.dll which seems to be an libavcodec build which also exports the x264 encoding functions. Isn’t the x264 codec supposed to be GPL?

If yes, how can it be used in this very proprietary app?

[PuzZLeR]

I can't tell you for sure which encoding engine it uses, but I can tell you for sure it's not one from Cucusoft. Building a true H.264 codec takes about 18 months, so if Cucusoft built one, we'd know about it.

Until someone gives you a "for sure" answer, I would still bet big money it's x264.

There are several such companies selling packages that do iPod/PSP conversions, etc. Of the ones I know for sure, they all use x264 in their H.264 conversions, even though they may rename the file something like "encoder.exe". Among the others, I can't see them using a very expensive one such as that from Ateme (Nero Recode), or other. I'm sure they would rather use a more common, and just as good, H.264 codec such as x264 that is available for free, especially since alot of these companies are basement operations run on a small budget (believe it or not).

Note: Many of these companies however are scams. Most sell garbage and look for the quick buck riding the iPod wave. From the ones that actually do use H.264, they may use x264, but they don't do it justice by only calling it out with weaker encoding features, and only 1-pass in the name of selling a "fast encoder" package in their marketing.

Even though I'm not implying Cucusoft is one of them, I personally stay away from unproven GUIs that use an "unknown" codec. This always makes me suspicious and hence, wouldn't trust it with my valuable video. This is especially true when these companies offer features that are a small subset of those apps discussed in this forum, which most are available for free.

[celtic_druid]

Pretty much all the iPod encoding apps use ffmpeg with x264 for AVC encoding. VSO's ConvertXtoDVD also uses libavformat/codec. Not sure how many of them have GPL enabled or not. Definitly if they have x264 enabled. Then again ffmpeg has its own limited H.264 encoder.

[Manao]

Building a true H.264 codec takes about 18 months, so if Cucusoft built one, we'd know about it.That's simply not true. One guy with the right knowledge ( and there are many out there ) can make a viable encoder in less than two months.

[PuzZLeR]

That's simply not true. One guy with the right knowledge ( and there are many out there ) can make a viable encoder in less than two months.

Hey Manao,

The original implementations took alot longer when the technology was much newer. I guess with today's available resources such as more information, software subroutines even hardware modifications I imagine it would take less time today.

So I agree somewhat.

However, I'm referring to a core implementation, such as x264 or Ateme's codec, not a GUI, front-end or software app that may harness it. I'm sure you're referring to the same thing as well, but I think 2 months is rather quick even for a fully functional GUI.

I've gotten my information by talking to some knowledgable engineers throughout the field, and I would feel that they would disagree with such a short time frame of 2 months for such a demanding project, even today.

I could however ask them again if people are interested and report back.

[akupenguin]

I agree with Manao. If you already have the format-agnostic parts of an encoder (motion estimation, ratecontrol, rate-distortion optimization, api, ui, optimized versions of lots of common dsp functions, ...) and only have to write the H.264-specific parts, then that could be pretty quick.

[bobololo]

I've gotten my information by talking to some knowledgable engineers throughout the field, and I would feel that they would disagree with such a short time frame of 2 months for such a demanding project, even today.

Actually it's really a matter of experience and skill. With the right codec design knowledge and experience, it wouldn't surprise me to implement a working codec in a few weeks (that still requires some time to tune and optimize though). Without this know how, it could take years.

And on a side note, I don't agree with manao on the fact that there are plenty of people out there that are skilled enough to design a codec. The learning curve is actually quite hard and therefore that competence is definitely not as widespread as other skills like graphic programming, GUI design, etc. As an example, look at x264 development, while it's a very exciting project that could attract lots of talented devs, only a couple of them managed to get involved into the internals. And if today pengvado would decide to stop his contributions, I doubt there would be someone to replace him before months.

[YayKitties]

Hey guys,

Let me clarify a few things. I was speaking to puzzler a while ago about what it would take to make an h.264 (competitive with x264 and Ateme's) from the ground up and said around that time, so this confusion is my fault. However, I was thinking about the time from a whole big picture which starts from business planning, to recruiting new devs all the way to release. Of course I always tend to "sandbag" these estimates as things usually take a lot more time than when first planned. Open source has these advantages where only a handfull of people can steam ahead with little corporate bureaucracy gets in the way.

I agree with Manao and akupenguin that an H.264 encoder from the right people can be made very in a relatively short amount of time. However, not many people/firms have a current IP portfolio that can save devs from learning about and writing basic functions for ME, RDO and the DSP routines. For those of us in countries where software patents are valid, this can be more complicated - I personally know people that hold patents on ME - any many corps will not release something into the commercial public with some of these risks as well as protecting proprietary algorithms they may come up with. This does not mean that I agree with sw patents. Very few firms will also let an encoder/decoder into the public without rigorous testing for quality and conformance to the standard. IIRC, the Ateme beta program (for main profile) lasted for quite some some, as well as the beta that added high profile. I'm almost certain these beta programs lasted for more than two months each.

I also agree with Bobololo that there are truly few people that have these abilities and they are very hard to find with open source devs being the natural place to begin the search and it also looks like they've been snagged up by enterprising individuals and firms. Right now, it looks like Akupenguin still contributes the vast bulk of code to x264. How long was it in between fenrir stopped working on x264 and akupenguin took over?

Besides, we've all seen the XVID AVC encoder at the 2005 Doom9 codec shootout. Have we seen a full public release yet?

Again, I apologize.

[Manao]

I personally know people that hold patents on METhat's a moot point, since in order to enforce those patents, they would have to reverse engineer your soft, which is even more illegal in those countries.

The rest, of course, is quite true. You need to find the right people to code, and testing needs either time or lots of people.