Slashdot Mirror

Does VLC play MOD, S3M, XM, IT, or other tracked formats?

Yes.

Does VLC play NSF, SGC, GBS, VGM, SPC, PSF, USF, PSF2, GSF, 2SF, or any other video game console-oriented formats?

Some of them but maybe more of your list as well.

Heck, it also plays MIDI on Linux and other systems with glib.

The basic thing is - if there's an open-source codec, VLC plays it without requiring any plugins.

For a reason I can't fathom VLC actually can play a fair amount of old video game music files. Surprised me when I learned about it. https://wiki.videolan.org/Gme/ But yea, it doesn't cover all the file types you listed.

You joke, but the first place I saw that happen was in GNOME. Personally I would prefer the application name to be central with the description subdued (basically reverse of how they have it in MATE, which is the limit of my current GNOME experience).

Whichever way it's done, I will say it's better than just the application name. Even better though, the files that govern what is displayed are easily (and very often are) internationalized. Eg, when you have your language set in English VLC might say "Media Player" but if you select Esperanto it might say "amaskomunikiloj ludanto" or whatever (google translate, there) - meanwhile "VLC" means nothing to someone who doesn't already know what it does.

Thank you, you are correct, in haste I posted a bug which appears to be related to screen rotation but not the one iPhone users have.

IIRC the post was in the forums, and it was answered in a similar manner as these bug reports, e.g., it's not a standard so VLC doesn't consider it a "bug", if a user requires this extra functionality they need to take the appropriate steps to manually change the rotate transform in settings.

Just searching through the forum brings up various threads related to users asking for this functionality (searched on "rotate iphone"):

Reading through them now it appears that the issue, more specifically, is that EXIF tags are stored with the video clips that VLC is not reading.
https://forum.videolan.org/viewtopic.php?f=12&t=79068&p=260277&hilit=rotate+iphone#p260277

VLC is a fantastic free program, but the attitude some/one of their devs have towards it's users is disheartening for the project as a whole.

A friend recorded a video with her phone, and held it so the video was taken in "portrait mode" vs. "landscape mode". On a PC I was surprised when VLC was unable to correctly orient itself as I was use to my Mac's native application always orienting properly.

I spent the time looking for solutions on their forum and the devs responses is nothing short of arrogant:
https://trac.videolan.org/vlc/ticket/7766

Essentially users are told this is not a bug in VLC because the videos use a non-standard way of marking the video as rotated. Further they go on to say if a user wants to look at it, as it was shot, they need to manually tweak the rotation on the transform for playback. After a 7 step menu navigation process, this has the side effect of having to change the transform back for the next video you wish to play if it was shot in landscape mode. Essentially this has to be done on a video-by-video basis.

I'm hoping there are some Open Source projects that actually implement this correctly, but from the few I've tried so far, they all seem to have the same bug as VLC when it comes orientation. Standard or not, ignoring this rotation bit is rendering the program as crippled for 100,000's of people shooting videos this way. Coincidentally, I haven't found a commercial program that is subject to the bug, everyone I've tried (e.g., Quicktime, Adobe Premier, etc...) renders it properly.

I can always hope that, eventually, someone on the team will see the value in implementing this fix.

Could you have come up with a more convoluted workflow? You wouldn't let iTunes upgrade unless you were in no particular hurry. Authorized PCs have nothing to do with an unencumbered video, and if your video did have DRM, it isn't going to play on your Android without some kind of similar authorization setup. You want real trouble with passwords? Lose your Google credentials. "Customer support" is... non-existent.

Most people who want to play arbitrary video on iOS would install something like VLC rather than use the built-in player, just like most people on Android would install something like MX Player rather than depend on the gimped built-in player. VLC lets you transfer files over WiFi. My phone is Android, and my tablet is Android. We have an iPod and a few old iPhones that the kids play with. All I can tell you is that the Apple stuff is cleaner, but way too expensive for a toy. I can justify that cost on their laptops, where I'll actually use it for something productive - but I can't be bothered with $600 toys.

But I went down the China cheap pad route. No need to pay extra for something that'll go obsolete in a year. Hardware and software get upgraded at the same time ;-) If possible, get the model with the latest Android version because firmware support is spotty at best (although this is improving with some manufacturers now offering OTA updates). Or you can check if there's an active Cyanogenmod developer for the model so your tablet will be worth at least one Android revision (e.g. from 4.2 to 4.3).

Most of the apps I need are from F-Droid or downloaded from the developer site and installed/upgraded via adb. For example, I use the VLC for Android nightly builds at http://nightlies.videolan.org/build/armv7-android/, which I install via a command like "adb install -r VLC-debug-20130726-1426.apk". The -r option is for reinstall, which is is how an app is upgraded, something which took me months to find out as there's no explicit upgrade command.

we have an agreement which allows us to utilize x264 code in x265

You don't need an 'agreement' to use x264 code because x264 is licensed under the terms of the GNU GPL v2.0. What, exactly, is this agreement supposed to permit?

Not only that, the software isn't Free, and so even if I want to look at the code, I can't.

VLC for iOS can play all your movies and shows in most formats directly without conversion.

: :

You can find the source code for the last release here:

• VLC for iOS 2.0.1 source code
• MediaLibraryKit 2.0.0 source code
• MobileVLCKit 2.1.0-pre1 source code

Additionally, the latest code is always available on our git repositories.

source: VLC for iOS 2.0

The chain of trust still depends on trusting the first install

There are ways to establish trust for the first install even if it is not from Google Play Store. For example, if I download the APK of VLC from https://www.videolan.org/ then I'm piggybacking on the SSL CA infrastructure, which assures me of one of the following:

• A. The APK is authentic.
• B. Somebody compromised www.videolan.org and uploaded a trojan.
• C. A man in the middle compromised the private key of www.videolan.org and my Internet connection.

How likely are the scenarios other than A?

Conversely, one of the reasons GNU+Linux on the desktop has not been a hit is because of the abhorrent support for commonly used multimedia file formats. The common user may not understand the technical names of software codecs and the multimedia formats they encode to and decode from, but they sure feel it when they are shipped a default installation that can read or create any possible format out there.

It's an immense achievement that an operating system with a Social Contract dedicated to only including Libre Software in its main repositories can be automagically more versatile at handing more media formats than proprietary OSes like Windows or Mac OS X. "Casual users" want their audio players, video players and editors, etc. to read and write anything, and the news here is that the complex libraries and codecs are included to be used by any software that needs to call them.

I prefer VLC but the point is well taken. Reclaim your freedom to watch the content you paid for in the manner that you wish by using open source software to re-enable your rights as a consumer.

'VLC' would make a pretty good VLC equivalent :) - http://www.videolan.org/vlc/download-ios.html

Way to ignore the facts, here are the FACTS. FACT 1, the "company" was made up of four of the lead devs of VLC, FACT 2, the "owner" was one guy out of dozens who had written code, FACT 3 the "owner" made it clear HE WILL NEVER ALLOW VLC to be placed in ANY appstore that "doesn't support the four freedoms".

So you can waste mod point and pretend black is white and straw is gold, but the facts are that with a "community project" if they didn't make every contributor sign a waiver that gives the head of the project sole ownership (which VLC most assuredly DID NOT do) then any place the program is ported to HAS TO support all the conditions of whichever GPL version they have the program under (which I do believe is GPL V3 which has even worse conditions than GPL V2) or the program can NOT be placed there PERIOD.

So make up your mind Ms AC, either the GPL can be ignored or it can't, which is it? Considering that RMS says Android is too locked down to be called FOSS do you HONESTLY want to try to sell us that the GPL isn't gonna have a problem with the locked down winRT? As you can see here there is NO place that it says you have to give them the rights to your contributions, and since it says quite clearly its a COMMUNITY project unless every. single. one. that donated their code agrees then it CAN'T BE DONE. To say different but be like me saying if I can get one guy on the Debian team to say "sure!" I could make a completely proprietary Debian, it don't work like that.

How fucking sad is it that the Windows guy knows more about the GPL than the koolaid drinkers?

Is the DRM stuff still applicable to the LGPL?

Parts of VLC are under LGPL now.

Dealing with multimedia codecs has fuck-all to do with your distro and everything to do with VLC.

BTW, "each" is singular.

I noted that morituri supported AccurateRip when I was doing some research on whether it would be possible to implement AccurateRip in rubyripper, and, when I found the licensing issue, I concluded that you might not have noticed it, as it's rather subtle (my apologies in not bringing it up to you directly before now). In short, it's basically the same issue that resulted in VLC being removed from Apple's App Store

The basis for my interpretation was the fact that the AccurateRip database is, according to their website, "free for non-commercial usage, [while] commercial usage is restricted to prior agreement". This imposes an "additional restriction" under the terms of section 7 of GPLv3. As such, any end-user is permitted to "remove that term" (i.e. the restriction on commercial usage) from their license of your GPL program and thus make commercial use of morituri. But as this violates the terms of agreement to use the AccurateRip database, it becomes effectively impossible to meet both the requirements of both the GPL and the AccurateRip license (since you don't have the right to add the commercial restriction to the GPL for your end-users, per section 10 of GPLv3 (section 6 of GPLv2)). As such, you are not legally permitted to distribute any object or source code licensed under the GPL that also makes use of the AccurateRip database.

Now of course as the author of morituri, you could relicense your code under an alternative license that was compatible with AccurateRip's commercial-use restrictions such as the BSD or MIT licenses (caveat: any contributors would also have to relicense their code under said license), but you could not use (or for that matter modify) the GPL to do so.

That would be git-a74f292, the current compiled revision in that page at the time of writing is 5 revisions older than that.

Given that this page exists in Europe and hasn't been forcibly taken down?

http://www.videolan.org/developers/x264.html

Pretty much. You can't enforce software patents alone in Europe. When you put them into hardware (e.g. a TV that decode H.264, for instance), things become a little more tricky, and there is still "licensing", just not necessarily patent licensing going on.

For example, the people who developed the VLC implementation and library actually license their version to other people for a fee. It's quite possible it's already inside some audio-visual equipment that you own, if someone big licensed it:

http://x264licensing.com/

You can always download it from the Nighties

http://nightlies.videolan.org/build/android-v7-neon/VLC-debug.apk
or for Tegra 2:
http://nightlies.videolan.org/build/android-v7-tegra2/VLC-debug.apk

Plays all files, in all formats, like the classic VLC.
Audio and video media library, with full search.
Support for network streams, including HLS.
Supports Android from version 2.1 (platform-7).
Supports ARMv6, ARMv7 and ARMv7+NEON.
Subtitles support, embedded and external, including ASS and DVD subtitles.
Multi audio or subtitles tracks selection.
Multi-core decoding, for Cortex-A7 A9 and A15 chips.
Experimental hardware decoding.
Gestures, headphones control.

I sincerely doubt its due to an unavailability of US/Canadian test devices because late model GSM HSPA/UMTS devices from all the major manufacturers are pretty much the same world wide. I actually prefer buying unlocked international versions of these devices rather than carrier models.

I suspect this is really another patent fight over Codecs used or worked around by VLC, and the Google Market (play store) is making sure they don't end up on the wrong side of the MPAA, (not to mention trying to keep Google's YOUTube ox from being gored.

It does work, but won't necessarily play everything the desktop version plays just yet. The software decoding is slow and jerky for videos recorded on the android device it self, and the sound is out of sync, where as the embedded video player, or the desktop version works perfectly playing the same files.

It has a hard time of finding media on External_SD or attached USB storage on some tablets.
Still its a beta. And its nice to see progress,

You can always download it from the Nighties

http://nightlies.videolan.org/build/android-v7-neon/VLC-debug.apk
or for Tegra 2:
http://nightlies.videolan.org/build/android-v7-tegra2/VLC-debug.apk

Plays all files, in all formats, like the classic VLC.
Audio and video media library, with full search.
Support for network streams, including HLS.
Supports Android from version 2.1 (platform-7).
Supports ARMv6, ARMv7 and ARMv7+NEON.
Subtitles support, embedded and external, including ASS and DVD subtitles.
Multi audio or subtitles tracks selection.
Multi-core decoding, for Cortex-A7 A9 and A15 chips.
Experimental hardware decoding.
Gestures, headphones control.

I sincerely doubt its due to an unavailability of US/Canadian test devices because late model GSM HSPA/UMTS devices from all the major manufacturers are pretty much the same world wide. I actually prefer buying unlocked international versions of these devices rather than carrier models.

I suspect this is really another patent fight over Codecs used or worked around by VLC, and the Google Market (play store) is making sure they don't end up on the wrong side of the MPAA, (not to mention trying to keep Google's YOUTube ox from being gored.

It does work, but won't necessarily play everything the desktop version plays just yet. The software decoding is slow and jerky for videos recorded on the android device it self, and the sound is out of sync, where as the embedded video player, or the desktop version works perfectly playing the same files.

It has a hard time of finding media on External_SD or attached USB storage on some tablets.
Still its a beta. And its nice to see progress,

+1 informative.

Do apple ban redistribution of sourcecode? No. VLC for iPhone's source code was available for download. (before VLC was pulled on request of one of the authors of VLC)

Actually, it's still available. You just have to build it yourself.
http://www.videolan.org/vlc/download-ios.html

For anyone who is worried about this, VLC player should get around this. Bugger MS and their money grubbing bullshit.

I don't know the answer to this question. As a user (and not a KDE/QT developer), all I know is that VLC will do this in Windows and in GNOME. The fact that VLC (as with several other applications like XMMS) will not stream in KDE seems to (apparently to the user) be a problem with KDE and not the various applications themselves.

Well you would be wrong in that assumption, and frankly I'm disappointed that someone with a UID as low as yours would be unable to track down the actual problem; a bug in VLC, which is already fixed.

http://trac.videolan.org/vlc/ticket/6158

There's a reason why VLC can play basically anything, on any system, far better and more reliably then anything else on the planet.

LMAO. The only thing VLC can do reliably is play back crappy AVI files.

Until the recent version 2.0 VLC hasn't been able to play any h264 files of HD resolution without macroblocking on sudden scene changes or scrubs, it didn't supported ordered chapter MKVs (and the support that's there now is half-baked), resource usage was higher than ffdshow-based playback apps, and picture quality wasn't as good.

There's a reason VLC has been considered a joke in the fansubbing world for awhile now.

"Its a throwback to the times when every program used to include its own graphics, sound, and printer drivers. We moved away from those times for a very good reason."

There's a reason why VLC can play basically anything, on any system, far better and more reliably then anything else on the planet. And it sure as hell isn't because they're leveraging whatever maze of codec hell happens to be lying around a user's system.

System codecs were a nice idea in theory that never delivered in practice. Too many bad codecs included with every random software application that all register themselves to try and be the first priority codec for every format for the entire system... Did I mention there's no sane way for users to adjust codec priority order? The best of tools are 3rd party and at best can be described as incredibly cryptic. And they each are trying to reinvent that wheel because the ones actually shipped with the base OS are themselves, bad.

Mozilla using system codes would increase crash reports 100 fold overnight, as well as security breaches, 99.9% of which would have nothing to do with Mozilla but damned if the users know or care about the distinction, and there wouldn't be a damned thing Mozilla could do to fix it if they wanted to.

Depends what country you're in:

Libdvdcss works wonders, even if you only want to view DVDs on Linux.

Maybe if I link it again, Slashdot will get a takedown notice.

Libdvdcss

Lets try for one more:

Libdvdcss

Depends what country you're in:

Libdvdcss works wonders, even if you only want to view DVDs on Linux.

Maybe if I link it again, Slashdot will get a takedown notice.

Libdvdcss

Lets try for one more:

Libdvdcss

Depends what country you're in:

Libdvdcss works wonders, even if you only want to view DVDs on Linux.

Maybe if I link it again, Slashdot will get a takedown notice.

Libdvdcss

Lets try for one more:

Libdvdcss

repo: http://download.videolan.org/pub/videolan/vlc/SuSE/ No phonon backend yet it seems

The VLC developer made the claim because Apple's TOS is incompatible with the GPL. Apple is 100% to blame for that incompatibility.

Actually, the VLC developer that made the claim was unaware that Apple had actually changed it's TOS to accomodate FOSS licenses. See discussion on the VideoLAN list around October / Novemer 2010. Also take a look at Jean-Baptiste Kempf's legal analysis in the latter link.

It turns out that the last stumbling block - as explained in a comment above - is that the GPL license specifically dictates you can’t block the user's ability to redistribute binaries himself. This is conflicts with the iOS security model of only allowing software that is signed by a special certificate (or other enterprise certificates).

Now consider if VLC changed their license to be consistent with the app store TOS. VLC would be allowed on the app store, but it would no longer be free software.

This is plainly wrong, as only GPL licensed software has trouble with this model. Fres software under e.g. Apache, Mozilla or BSD licenses are easily distributed through the App Store.

The VLC developer made the claim because Apple's TOS is incompatible with the GPL. Apple is 100% to blame for that incompatibility.

Actually, the VLC developer that made the claim was unaware that Apple had actually changed it's TOS to accomodate FOSS licenses. See discussion on the VideoLAN list around October / Novemer 2010. Also take a look at Jean-Baptiste Kempf's legal analysis in the latter link.

It turns out that the last stumbling block - as explained in a comment above - is that the GPL license specifically dictates you can’t block the user's ability to redistribute binaries himself. This is conflicts with the iOS security model of only allowing software that is signed by a special certificate (or other enterprise certificates).

Now consider if VLC changed their license to be consistent with the app store TOS. VLC would be allowed on the app store, but it would no longer be free software.

This is plainly wrong, as only GPL licensed software has trouble with this model. Fres software under e.g. Apache, Mozilla or BSD licenses are easily distributed through the App Store.

Guess what: They just did that thing you said they couldn't do.

http://www.videolan.org/press/lgpl.html

Pretty rich of you to accuse others of "bullshit", then.

You may have been mistaken from the case of VLC, which was pulled because of a copyright claim made by one of the VLC developers. It was not pulled because it was open source.

You're oversimplifying...
http://news.ycombinator.com/item?id=2082505

VLC for iOS Pulled from the App Store (videolan.org)

Disclaimer: VideoLAN Chairman and lead VLC developer here.

I've written the most important analysis on the matter http://mailman.videolan.org/pipermail/vlc-devel/2010-November/077457.html and http://mailman.videolan.org/pipermail/vlc-devel/2010-December/078262.html

Some VLC developers (for Mac mainly), with the company Applidium, have ported VLC on iOS. Applidium published it on the store, for free.

Some developer complained (quite lately, btw...) afterwards and quoted a FSF analysis. Their analysis was totally wrong (spoke about redistribution), and based on old version of AppStore terms.

After my remarks about changes of the AppStore terms that made this analysis obsolete and wrong, they shifted their criticism onto another part, which was the "usage" part of the ToS. They complained that the terms did not allow all uses, especially commercial ones.

Indeed, one part could be interpreted in different ways. Therefore, I've mailed Apple Copyright Agent for explanation, twice. Once in November, once in December...

Apple has refused to answer, to explain or to help in any matter. They then decided to pull the Application unilaterally from the AppStore.

Of course, they are allowed to do that, and noone can complain, but this is yet another push from Apple against VLC, that adds to the very long list of past issues. It just makes me think Apple doesn't really want competition...

You may have been mistaken from the case of VLC, which was pulled because of a copyright claim made by one of the VLC developers. It was not pulled because it was open source.

You're oversimplifying...
http://news.ycombinator.com/item?id=2082505

VLC for iOS Pulled from the App Store (videolan.org)

Disclaimer: VideoLAN Chairman and lead VLC developer here.

I've written the most important analysis on the matter http://mailman.videolan.org/pipermail/vlc-devel/2010-November/077457.html and http://mailman.videolan.org/pipermail/vlc-devel/2010-December/078262.html

Some VLC developers (for Mac mainly), with the company Applidium, have ported VLC on iOS. Applidium published it on the store, for free.

Some developer complained (quite lately, btw...) afterwards and quoted a FSF analysis. Their analysis was totally wrong (spoke about redistribution), and based on old version of AppStore terms.

After my remarks about changes of the AppStore terms that made this analysis obsolete and wrong, they shifted their criticism onto another part, which was the "usage" part of the ToS. They complained that the terms did not allow all uses, especially commercial ones.

Indeed, one part could be interpreted in different ways. Therefore, I've mailed Apple Copyright Agent for explanation, twice. Once in November, once in December...

Apple has refused to answer, to explain or to help in any matter. They then decided to pull the Application unilaterally from the AppStore.

Of course, they are allowed to do that, and noone can complain, but this is yet another push from Apple against VLC, that adds to the very long list of past issues. It just makes me think Apple doesn't really want competition...

Or they can demand that all copyright is signed over to them so even though GPL they could fork a version with a different license. Some projects already do this, eg x264 which is now selling non-GPLed versions.
See the bottom of http://www.videolan.org/developers/x264.html

Does Apple not add any restrictions on what you can do with apps you buy from the App Store? Yes, they absolutely do.

The GPL doesn't allow you to add any restrictions past what it specifies, so it's fairly clear that you can't distribute GPL'd binaries on the App Store. See http://mailman.videolan.org/pipermail/vlc-devel/2010-November/077486.html for the FSF's official position. It does not matter if you charge or not, there are conflicts in the ToS even for free apps. For example, "(i) You may download and sync a Product for personal, noncommercial use on any device You own or control." Again, the GPL doesn't allow further restrictions to be placed, and that is a pretty big restriction. Ergo, you have to either ignore the GPL (which is fine if you wrote all of the GPL'd code), or you can't distribute the app.

http://wiki.videolan.org/AndroidCompile

It's very simple. I have it running on my Android phone. Its lacking features but my music and vieos are playing.

Wrong.

VLC is GPL3.

It's useful to actually know what you're talking about before calling someone out like that. I'm not sure what you're basing this post on because VLC is quite clearly GPLv2 and *not* v3 as you can see here:

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

You can also have a look in the COPYING file in the source code and you will find:
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
...

Wrong? That's so wrong it's right. Not only is VCL under GPL2, the VCL project has even spoken out against GPL3 http://www.videolan.org/press/2007-1.html because of the Tivo clause - and the VCL engine is about to move to LGPL2.1 http://www.videolan.org/press/lgpl.html to make it even more open.

It's called VLC (originally for Video LAN Client), not VCL.

Wrong? That's so wrong it's right. Not only is VCL under GPL2, the VCL project has even spoken out against GPL3 http://www.videolan.org/press/2007-1.html because of the Tivo clause - and the VCL engine is about to move to LGPL2.1 http://www.videolan.org/press/lgpl.html to make it even more open.

It's called VLC (originally for Video LAN Client), not VCL.

Wrong.

VLC is GPL3. GPL3 is incompatible with the App Store due to the anti-Tivoisation provisions. On that basis, nobody has the right to publish an iOS App Store version without the consent of all contributors.

Wrong? That's so wrong it's right. Not only is VCL under GPL2, the VCL project has even spoken out against GPL3 http://www.videolan.org/press/2007-1.html because of the Tivo clause - and the VCL engine is about to move to LGPL2.1 http://www.videolan.org/press/lgpl.html to make it even more open.

Wrong.

VLC is GPL3. GPL3 is incompatible with the App Store due to the anti-Tivoisation provisions. On that basis, nobody has the right to publish an iOS App Store version without the consent of all contributors.

Wrong? That's so wrong it's right. Not only is VCL under GPL2, the VCL project has even spoken out against GPL3 http://www.videolan.org/press/2007-1.html because of the Tivo clause - and the VCL engine is about to move to LGPL2.1 http://www.videolan.org/press/lgpl.html to make it even more open.

Tell that to x264 and FFmpeg.

They aren't located in a place where software patents are valid.

Tell that to x264 and FFmpeg.

I did. They said something about being based in France...

Tell that to x264 and FFmpeg.

Looks like VLC may have caught up - http://wiki.videolan.org/VLC_GPU_Decoding , http://wiki.videolan.org/VLC_GPU_Decoding#Requirements_for_Windows_DxVA2_in_VLC
I don't do much transcoding myself but I've tried playing multiple vids in both MPC and VLC and the CPU usage barely budges with either.

Looks like VLC may have caught up - http://wiki.videolan.org/VLC_GPU_Decoding , http://wiki.videolan.org/VLC_GPU_Decoding#Requirements_for_Windows_DxVA2_in_VLC
I don't do much transcoding myself but I've tried playing multiple vids in both MPC and VLC and the CPU usage barely budges with either.

And the solution is .. go directly to the Download site ...

Yeah, I know it's silly to complain about 'news' headlines, but it sounded like the official distribution had been infected. That is not the case and http://www.videolan.org/vlc/ is still a safe provider of the software.

Until someone hacks into the server.