Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VLC for the new Windows 8 User Experience ("Metro")

kickstarter.com

Post reply on HN
Print view View original

1–10 of 33 posts

Re: VLC for the new Windows 8 User Experience ("Metro")

#4

Post by untog »

dkersten wrote: post #2

Not really on topic, but am I the only person who finds metro to be really really REAllY ugly?

Yes it is off topic, and no you aren't. There have been lengthy, lengthy discussions between members of HN of whether Metro is a good or bad thing. I think at this point we probably all have to agree to disagree.

Re: VLC for the new Windows 8 User Experience ("Metro")

#7

Post by jbk »

ComputerGuru wrote: post #6

I'm all for funding 40k pounds (~65k USD) for VLC (they deserve it), but 40k under the guise of Metro seems a bit much, no?

Well, no, this is not too much.

This is an excellent question.

Designing a UI above VLC for Metro is quite easy, and we've already done some proof of concept. Finding a designer would be simple and 1k$ for the project would be too much already :) It would take a couple of months and be done with it.

The issue is to get on the store. And this is hard.

Why is that?

VLC (and its underlying libraries, including codecs, networking and demuxers) represents around 7M LoC of C, C++ and ASM. All of this is very C99 code and inline ASM. Visual Studio cannot eat that in any way. Believe me, we tried. A lot. So we need to compile the VLC for Windows on Linux, using gcc+mingw.

Unfortunately, this does not work on WinRT ("Modern UI" or whatever you like to call it). WinRT restricts a lot the Win32 APIs. And only Visual Studio knows which ones. Oh, and the BSD sockets are gone...

So, we need to change and update the toolchain, fix MingW for WinRT, rewrite the code that is using Win32 APIs since 10 years (and in all underlying libraries too...), write a new UI above this, fix the code using HWND for rendering, port the audio and video outputs, work-around the sandbox for DVD playback, probably write a WinSock2 replacement library to build all the cross-platform libraries that expect a BSD-socket-like library, etc...

Add to that the need to modify MingW to output dlls that we can load on ARM (Windows RT) and fix all the same different APIs for WP8.

Of course a lot of the work is not really on VLC, but on being able to compile for WinRT with open source tools, and a lot will be re-usable.

So, yes, we will need quite a few developers, and therefore money.

Re: VLC for the new Windows 8 User Experience ("Metro")

#8

Post by Todd »

jbk wrote: post #7
ComputerGuru wrote: post #6

I'm all for funding 40k pounds (~65k USD) for VLC (they deserve it), but 40k under the guise of Metro seems a bit much, no?

Well, no, this is not too much. This is an excellent question. Designing a UI above VLC for Metro is quite easy, and we've already done some proof of concept. Finding a designer would be simple and 1k$ for the project would be too much already :) It would take a couple of months and be done with it. The issue is to get on the store. And this is hard. Why is that? VLC (and its underlying libraries, including codecs, n…

It sounds like it's going to be a real challenge, then. Much of the restriction around API usage is related to IO and other things that can block for more than about 50ms. As you know, the APIs that are allowable have been converted to be asynchronous, or have been replaced entirely with an async equivalent (more or less). This will make it difficult to just link with a gcc lib unless it's been purged of these references. In addition, there are no database APIs, for example. So it's really a crap shoot about how much difficulty a given project will take to port.

Re: VLC for the new Windows 8 User Experience ("Metro")

#9

Post by PaulHoule »

Todd wrote: post #8
jbk wrote: post #7

Earlier quoted context omitted.

Well, no, this is not too much. This is an excellent question. Designing a UI above VLC for Metro is quite easy, and we've already done some proof of concept. Finding a designer would be simple and 1k$ for the project would be too much already :) It would take a couple of months and be done with it. The issue is to get on the store. And this is hard. Why is that? VLC (and its underlying libraries, including codecs, n…

It sounds like it's going to be a real challenge, then. Much of the restriction around API usage is related to IO and other things that can block for more than about 50ms. As you know, the APIs that are allowable have been converted to be asynchronous, or have been replaced entirely with an async equivalent (more or less). This will make it difficult to just link with a gcc lib unless it's been purged of these refere…

Async comm is relatively easy to deal with in the context of media players than it is in other applications because in media players there is a fairly direct flow of information from a file or a network connection to the video and sound subsystems.

If you're building the kind of app I was building a few years ago, such as semantic graph editors, where a change in one UI element might have effects that propagate to other UI elements in an uncontrolled way, then, yes, the async comm in Windows 8 (the same problem that exists in Javascript, Flex and Silverlight) requires you to have a systematic approach to how information gets into the app.

(One thing I'd definitely note is that the Windows 8 apps like "Photos" and "Mail" are really a joke when you compare them to the Windows 7 era "Windows Live Essentials", which are really competitive -- Windows Live Essentials can handle mail spools on my crappy 2GB shojou netbook that destroy Thunderbird on a 32GB machine. My experience is that async I/O sets an upper limit on the complexity of what you can do)

VLC will have the option of bending their UI to be something that fits the Metro mold easily, so async I/O and comm should not be such a big deal.

Post reply on HN