The VideoLAN Forums

dear vl-team! thanks for the great vlc!!!
i often visit your website in hope to download a vlc-version that supports iv50. i really can't understand that such a common codec (used by webcams from logitech and a lot of others) isn't supported in vlc. i have a lot of such videos. at this time vlc is my default player, but it's everytime a hell to open M$ media player to view iv50 videos.

it is really so hard to implement iv50
how big is the chance that vlc will support iv50-codec in the future

thx!

IV50 is proprietary, that's why VLC doesn't support it, VLC is an open-source, GPL project, so unless someone were to reverse-engineer Indeo Video 5, come out with an open-source implementation, it won't be in VLC.

Reverse-engineering a CODEC is painful, time consuming. CODECs generally work by doing some pretty advanced mathematical operations on the video data -- various Fourier and wavelet transformation techniques, working with the video in the frequency domain, a bunch of matrix math things, various mechanisms to predict movement and only sent small blocks of data at a time (inter frames), all in pursuit of high video quality at minimal bandwidth (a lot of compression).

Companies that use IV50 are idiots. It produces totally uncompatible video that is only viewable on Windows 2000 and later.
I advice you to write a complaint to Logitech that you are unable to view the video you produced in the environments you desire (mac, linux and VLC) (even though you might not want to use it on a mac or on linux, it's important too let companies know that you are not satisfied with their 'limited' support).

thanks for your answers.
the main feature of vlc that i'm using is the ability to view incomplete videos. after a hdd crash i recovered some private stuff (coded with iv50) and i'm not able to view that in any player because some video data (fourcc header etc.) is lost. i tried "divfix" and others but they helped me just a little bit.
i know it's offtopic, but any ideas in that matter

iv50 may be proprietary but vlc supports so many codecs and i think iv50 would "round up" vlc and give mac and linux users a chance to view such stuff. even if iv50 is "dumb & old" there are a lot of that stuff on the internet (afaik) and it would be great if vlc can view those existing vids... but maybe the vl-team has other more important things to code

thx again, al

@The DJ
"It produces totally uncompatible video that is only viewable on Windows 2000 and later. "

that's one more reason to support that codec, so mac & linux users can view it!
AFAIK win9x-me also supports iv50

How many freaking times do we need to explain this?

When a free and open source codec becomes available, VLC will support it. As long as no one has written such a implementation (which is very complicated and not something usually done by the VLC team, as markfm explained above) VLC will not support IV.

VLC does not usually use it's own video decoders. It is an application that uses video codecs (mostly ffmpeg) and wraps them in a program to create a media player and streamer.

@The DJ
hey mr.president, take it "frekin'" easy because nobody forces you to answer my "freaking" thread. thanks

It gets a bit frustrating to some extent because bulletin boards like this really do have a good Search feature. All of the Forums have a permanent message asking people to search before asking a question.

VLC has a Features list, available off of the main VLC page, which lists the things that VLC does, and does not, support. People just don't seem to read that. It's pretty obvious, only the second paragraph on the page.
http://videolan.org/vlc/features.htm is the list

Concerning Search, if you select it, then put IV50 in the search area, hit the button, you will get multiple hits -- take a quick look and you will see it explained several times, that VLC doesn't support IV50, won''t unless/until an open-source version comes out.

It's an excellent application, but VLC doesn't do everything (just more things than most).

well i was brave and used the search funktion "before" i wrote this thread!
i found some threads about iv50 and readed them all. i know that vlc doesn't support iv50 but nobody in the found threads answered WHY. i think that a "requests-forum" is here to make requests. and that's what i did. however, thanks again for your previous explanation. such comments like "How many freaking times do we need to explain this?" don't belong in this forum. but forget it...

Good job using the Search function! It really does work.

Sorry you hadn't noticed the answer to your question -- I had explained it in a couple of the threads, usually a one or two line thing talking about how VLC does not support certain proprietary (closed source) CODECs. This is the first time I explained a bit more of the "why", that it is a pretty nasty mathematical puzzle, determining what the proprietary CODECs are using for their processing algorithm; this explanation applies equally to WMV3, IV50, the various Real CODECs, basically any CODEC that's closed source -- it really is a "code breaking" exercise to reverse engineer CODECs, trying to determine the transform for a given set of source frames that results in a given set of output frames.

DJ and the other developers have probably hit this question enough times that it's burned into their minds ("Oh, no, not the proprietary CODEC question again"

A good question might be where to put such information (pre-canned answers). It's clear that a lot of people aren't reading the features list (there are many questions saying that "fourcc video CODEC designation XYZ is not supported", and the answer is "You're right, this is shown in the Features List), else don't quite understand the material there. There's also a FAQ for VLC, I believe, and there's a wiki.videolan.org, a user-contribution knowledge base to capture things like how-tos or information specific to VLC operation with a given operating system.

The developers have clearly been trying to get the information out, but it seems that there are a lot of repeat queries.

(I'm lucky -- I'm not a developer, but do a lot of research for work, so am comfortable poking about in various areas, using search tools, etc.)

To be totally honest, for the safety of others, i just might not answer this question anymore in the future.

@The DJ
hey mr.president, take it "frekin'" easy because nobody forces you to answer my "freaking" thread. thanks

Oh yes they do. If I don't answer you get people screaming 'why doesn't no one answer my question. someone please answer my question, I really do need help.

Besides the question had already been answered in the first reply by markfm and you ask the same question again????
I don't get that.

better you say nothing than to scream around but enought of that. i'm sure you with your >1000 posts know that such freakin' things don't belong into a serious forum. now excuse me, i'm gonna learn some more english

What I can't understand is how can Linux / FreeBSD etc users have the ability to watch Indeo Video 3/4/5 files using MPlayer and yet we OS X users can't?

Also, there is XAnim which lets users watch these file formats on Unix X11 machines.

Please can someone from VideoLAN explain why this isn't available for OS X?

Relevant links...

http://www.mplayerhq.hu/homepage/design7/news.html

http://www.mplayerhq.hu/MPlayer/releases/codecs/

http://smurfland.cit.buffalo.edu/xanim/home.html

> Please can someone from VideoLAN explain why this isn't available for OS X?

I don't believe these DLL codecs are open source? That's why they aren't available for OS X. Really lame, but that's the way it is. Funny though that Linux users can view Indeo Video 4 and 5 files and OS X users can't.

Funny though that Linux users can view Indeo Video 4 and 5 files and OS X users can't.

That's because these DLLs are compiled for intel/amd processors (so-called x86 CPUs), which aren't compatible with the ones, which are used in Macs (PPC CPUs). Furthermore, these DLLs are not compiled by MPlayer team, but copied from existing proprietory apps, so you cannot create a Mac version of them. Additionally you might have noticed that there are no DLLs on Macs (there's something similar, but technically not the same at all).
Thus, the different architecture of Macs and x86 PCs (including Win32, most Linux, FreeBSD, NetBSD, etc.) is also the reason, why the Mac-Edition of MPlayer does not support Indeo Video either.

As stated above, the source code of the DLLs is not accessible by the public, so they cannot used in VLC because its license forbids this. You might say that MPlayer uses the same license (GPL) as VLC and still uses them. That's true, but MPlayer violates its own license by doing this from our point of view.

Regards.

As stated above, the source code of the DLLs is not accessible by the public, so they cannot used in VLC because its license forbids this.

But it should be possible to use proprietary DLLs in some way - just distribution along with VLC would be a violation of the license IIRC, or am I wrong here?
Don't many open-source-projects work around this issue in a similar way? It's just that the user has to get and install the DLLs or .so-files as I prefer to call them:) on his or her own.

So it would be great if I could put my proprietary DLLs into a codec-folder that VLC can access and use...

Hugh

So it would be great if I could put my proprietary DLLs into a codec-folder that VLC can access and use...

I do not know whether the GPL supports this. I think even the FSF does not know this, as you can read in their FAQ on the GPL. This would have to be discussed by the team. As far as I understand the GPL, it forbids such a solution.

Another reason why we do not support such a way is that nearly all developers do not use Win32 and want nearly every part of VLC the most portable possible. So if we include such a solution in VLC, it won't run on PDAs or Mac OS X.
In the time after such a release, we would receive support messages like "my friend can play this and that file with VLC under Win, but I cannot play it on my mac. WHY??", which are rather annoying to reply.
Thus, I'd be against such a solution. Possible that other team member do see this differently.

Regards.

As far as i understand you can do what Hugh said. The player would only have the ability to load the lib, the user would download the proprietary dll and the USER would violate the license by loading the proprietary dll.

We see this more as a maze in the GPL license then that it is actually a possibility and an intention of the license. Therefore we choose not to pretend we don't know what would be going on if this were implemented and won't be adding it to VLC.

BTW wmv3 support will be there in WMP trough the directX layer. And in the future it might also be possible to load helix plugins, since the helix framework will become GPL compatible...

The player would only have the ability to load the lib, the user would download the proprietary dll and the USER would violate the license by loading the proprietary dll.

Not neccesarily the user violates the lizecense. He can have the dll legally.

We see this more as a maze in the GPL license then that it is actually a possibility and an intention of the license. Therefore we choose not to pretend we don't know what would be going on if this were implemented and won't be adding it to VLC.

Is this a problem with YOUR license? I can't understand that this is a no-go.

I searched for Indeo and this was the first interesting thread. The last reply is 1,5 years old. What is the current state of your decision? There are a lot of interest in this Indeo Codec. --lemmi

Well, you can take the Windows DLL and use it in Linux. This doesn't necessarily violate the license, although distributing it together with VLC might. That still doesn't help Mac users with PowerPC processors.

I don't know why Logitech used this codec in their webcam, but you don't have to buy their product either. There are plenty of other webcams on the market. Caveat emptor.

If someone wants to figure out IV50 encoding and write us a decoder then maybe it can be supported in VLC. But I don't see why anyone would waste their time when they could have bought a better webcam instead. It's not like there is a huge price difference.

I don't know about "a lot of interest" in IV50, I see a lot more interest in WMV3 and RV30/RV40.

Well, you can take the Windows DLL and use it in Linux. This doesn't necessarily violate the license, although distributing it together with VLC might.

I want to look the videos with VideoLAN. They do not need to distribute the libraries.

If someone wants to figure out IV50 encoding and write us a decoder then maybe it can be supported in VLC.

There is no need to write the encoder, the encoder is in the libraries.

The player would only have the ability to load the lib

But I don't see why anyone would waste their time when they could have bought a better webcam instead.

The webcam was only one point to use the encoder.

I don't know about "a lot of interest" in IV50

just search the posts

I see a lot more interest in WMV3 and RV30/RV40.

just open a new thread

I want to look the videos with VideoLAN. They do not need to distribute the libraries.

Well hypothetically VideoLAN could use the codec if it was already installed. But this would only work for people who bought the quickcam and installed the logitech software. It wouldn't work for anyone else. You couldn't send the videos to anyone else and have them watch it. So this is rather pointless.

But this would only work for people who bought the quickcam and installed the logitech software.

NOBODY cares about the webcam, I agree.

There are a lot of other interests for this codec.

Do I need to open a new thread?

The subject is IV50 Support. Nice of you guys pointing out that nobody needs the movies from this webcam and I agree in this. Well, maybe the origin author is dead anyway.

This is not the point. The point is that reverse engineering a codec is a TON of work. The kind of work a single person might spent a year of his time on.
Now if someone was getting PAID, then that might happen, but if they are not, then you can just HOPE that someone needs it enough to do by himself.

Still, this is not work the VLC people usually do. VideoLAN builds the player software, not the codecs that decode the video. That's a different gig all-together. Usually the ffmpeg people do work like this. Don't expect us to do this.

Thanks for your awnser.

The point is that reverse engineering a codec is a TON of work.

Yes, I understand this.

There was another idea.

Just write a wrapper to USE the codec. You don't distribute the Codec. You may specify a codec-folder where the user puts the DLLs.