Videolan looking for windows devs

[DGMurdockIII]

Videolan is currently lacking in support of windows dev it currently has no full time windows dev the current dev currently cross port vlc to windows and is looking for at least one person that could help out on the windows side of programing with videolan

if you think you may be interested in taking up this offer come join use on are irc chat room @ irc.videolan.org #videolan

here is the videolan site http://www.videolan.org/

[DGMurdockIII]

We need your help

[DGMurdockIII]

really could use your help

[stax76]

Main interest here is MPC-HC which also lacks devs.

[CruNcher]

And i was surprised that the current trunk was unusable currently for Windows (Fullscreen,Chroma(Overlay) on at least Nvidia Cards) problem, now that seems to explain it :)

[DGMurdockIII]

oh ok

[DGMurdockIII]

but videolan is a way better media player and works on linux , mac and windows but MPC-HC only works on windows do you see my point

[Revgen]

VLC isn't the only one losing devs due to the recession.

[DGMurdockIII]

there loosing devs? says who vlc has been looking for a a windows dev for a while at least 2 years

[Sina™]

only kmp, the current kmp dev is just 1.

[Leak]

but videolan is a way better media player
Except that, as always, all generalizations are false...

np: Nine Inch Nails - Survivalism (Year Zero)

[stax76]

And because of that we have the best/better forum rule. :)

Maybe we can agree they are both great.

[DGMurdockIII]

yes they are but why can the mpc_HC devs just work with VLC add the stuff they need to it make it like mpc-hc is then there would only be a need for one player

[neuron2]

Maybe they don't want to bother with all the Linux cross-platform testing etc. Or maybe they think you should put all the VLC stuff in MPC-HC. :)

[Dark Eiri]

but videolan is a way better media player and works on linux , mac and windows but MPC-HC only works on windows do you see my point

Yeah, and it's like, 40 megabytes bigger.

[stax76]

It's indeed big but on the other side it starts quickly and has a lot features so it's not just bloat.

[JonE]

Yeah, and it's like, 40 megabytes bigger.

O M G ... thats nearly 0.008% of my secondary hard drive :scared:

Maybe they don't want to bother with all the Linux cross-platform testing etc

I wouldn't like to say "dont want to bother", rather if you aren't already familiar with the way the code is put together and then throw in the need for understanding implications of cross-platform and throw in not being familiar with Linux then there is a very steep learning curve there.

TTFN,
Jon

[Gokumon]

but videolan is a way better media player

Well that is unless you like things such as proper subtitle support or DXVA support for playing back H.264 and VC-1 files. In those cases, vlc falls very short. There is nothing in VLC that I've seen that is superior to what I can do with MPC-HC except for a whole bunch of features that I don't want in a media player (transcoding, remuxing, etc) because I have better tools to do those jobs than VLC provides.

[Dark Eiri]

O M G ... thats nearly 0.008% of my secondary hard drive :scared:


It's not about the space itself, actually. I'm just curious to know how VLC can be so absurdly huge compared to MPC-HC, since it doesn't have that much features than it.

[LoRd_MuldeR]

It's not absurdly at all, if you understand how the size comes together:

VLC uses the Qt framework for it's GUI, because it's a cross-platform application! And the Qt runtime library alone is ~10 MB in size ;)

At the same time MPC-HC is Windows-only and can uses "native" Windows GUI, which needs no additional runtime library at all.

The next two "space hogs" in the VLC folder are the libavcodec and libavformat libraries. Together they are another ~10 MB in size!

Then comes skin support. MPC-HC has no skin support. And so and so on...

Last but not least there's some overhead in VLC for having each feature in its own Plugin instead of linking everything together statically.

IMHO it's absurd to complain about a 40 MB applications, in times where it's not unusual for the Operating System to take 7 GB alone!

[stax76]

which needs no additional runtime library at all


except MFC

IMHO it's absurd to complain about a 40 MB applications

It's 70 MB, I would welcome some shrinking.

[LoRd_MuldeR]

It's 70 MB, I would welcome some shrinking.

Start with UPX'ing all files that belong to VLC. This will reduce the size to ~30%. Then drop some unneeded plugins...

[stax76]

Thanks for the hint, does this work with all executables including .NET and what effect has it on startup times?

[LoRd_MuldeR]

Thanks for the hint, does this work with all executables including .NET

Although .NET assemblies still have the ".exe" extension, they do NOT contain executable code. They contain a "byte code", similar to Java's bytecode, that runs inside a VM.

UPX doesn't apply here.

and what effect has it on startup times?

UPX' decompression algorithm is very fast, ~200 MB/sec on an old AthlonXP. You probably won't notice any delay.

Sometimes it's even said that UPX'd executables actually start faster, because less data needs to be transferred from "slow" HDD to "fast" RAM.
That of course only applies for the very first launch, when the executable code is not cached in the RAM yet.

Note that UPX' LZMA mode, which compresses slightly better, starts up slightly slower. And if you don't care about a startup time, try this one:
http://www.farbrausch.de/~fg/kkrunchy/

[stax76]

Thanks for info, would be cool to have something similar for .NET but I guess the .NET runtime would have to support this as the runtime loads the assemblies.

[CruNcher]

I just say they all have their pros and cons for different scenarios but on linux with vdpau/va-api support all of the native GNU-Linux ones rock MPC-HC ;)
On Windows it depends what you need :) for Internet/Streaming playback VLC/Mplayer (where you have to life with all the rendering restrictions) rock for local playback MPC-HC (where you can enhance the rendering though for that loss GPU Decoding or get it back via workarounds like CoreAVC though for AVC only)

overall GNU-Linux wins for Media Playback :)
Linux = Excellent Rendering Quality and GPU Decoding support
Windows = Excellent Rendering Quality (though with the loss of GPU Decoding most of the time (scenarios))

some days ago Hardware Accelerated Decoding (today GPU Decoding) was a dominant Windows Place (DXVA1/2) that times are finally over :)

[Gokumon]

They contain a "byte code", similar to Java's bytecode, that runs inside a VM.

Bzzt. Wrong. The IL is JIT compiled into native code. It is not run in a VM like with Java (although you would be an idiot not to enable the Hotspot JIT compiler when running Java programs these days). It's amazing how many people keep spreading obviously wrong information about this.

[LoRd_MuldeR]

Bzzt. Wrong. The IL is JIT compiled into native code. It is not run in a VM like with Java (although you would be an idiot not to enable the Hotspot JIT compiler when running Java programs these days). It's amazing how many people keep spreading obviously wrong information about this.

We must distinguish between what is store in the file and what happens at runtime. Only the former is relevant for UPX ;)

It's a fact the .NET assemblies do not contain "native" executable code, but Bytecode similar (but of course not identical) to Java Bytecode. It's CIL (Common Intermediate Language) in M$ jargon.
That code cannot run on the CPU directly! It will run inside a VM or Interpreter, similar (but again not identical) to Java's JVM. It's called CLR (Common Language Runtime) in M$ jargon.

I'm aware the M$'s CLR uses JIT (Just-in-Time) compilation for faster execution. This is what any state-of-the-art VM does. The Java VM does the same thing with it's so-called "Hot Spot" compiler.
So while the .NET application is executing, the CIL code is not interpreted step-by-step, but compiled to "native" code at runtime. No doubt about that.

However this doesn't change the fact that in the .NET assembly file there is CIL code and not native machine code, like it would be the case with a "real" EXE or DLL file.
And that is exactly the reason why .NET assemblies cannot be UPX compressed. If was compiled to "native" code, then UPX would be able to compress it, like a "normal" EXE. That's not the case!

.NET assemblies contain code in CIL, which is usually generated from .NET languages, and then compiled into machine language at runtime by the CLR just-in-time compiler.

http://img137.imageshack.us/img137/3959/dotnet.gif

[neuron2]

Thread is now way way OT. Closing.