The VideoLAN Forums

When the VLC user downloads a file or generates a file from a capture source like a tuner,
there are 5 important pieces of information the user wants about that file:

1) what is the bit rate, resolution, encoding type of the video ,
2) the bit rate and encoding type of the audio, and
3) can this file be Read in by Windows Movie Maker 2 (the Microsoft video editor/converter application, free with Windows XP),
4) can Windows Movie Maker 2 Write this file,
5) can Windows Movie Maker 2, when it Writes the file, measure precisely the timing positions within the media, so that the segment of the file written is exactly the selected portion of the AV information, no more no less.

The VLC developers should aggressively present the information in 1 and 2 to the user.
Simple moving the mouse over the display window of VLC should display all of the information in 1 and 2, along with the pathname of the file. Otherwise, the right-click menu within the display window should have a single Media_Info selection which would display this information.

I have found that MPEG-1 is the format most likely to meet items 3,4 and 5 here.
Thus, the ability to convert media file to MPEG-1 remains a very important needed functionality.

Developers seem to be struggling with the Convert function in VLC.
VLC developers should focus on converting media into MPEG-1 format, debug it, test it, and allow users to Write media files they have into a format which can be used with Windows Movie Maker.
That is a critically important and needed feature.
And for some reason, there are certain media which only VLC can Read.

The one other important feature which VLC developers should focus on is Closed Captions.
When capturing from a TV Tuner, if that VLC feature is ever debugged and working,
1) it should be possible to capture the Closed Captions to a separate file
2) display the Closed Captions in a separate external window, which can be Scrolled backward to see any words missed

In fact, it would be useful to have VLC simply display Closed Captions in the said separate external window, in parallel with the regular operation of the application software which is included with the TV Tuner device performing display and audio generation.
That is, VLC would go directly to the Tuner driver/filters and fetch and display the Closed Captions of whatever is the current NTSC channel or current ATSC channel.

VLC project managers should limit any further work on VLC which does not address these problems.

VLC project managers should limit any further work on VLC which does not address these problems.

So, that means, you are going to come and help us ?
Thank you sooo much!

No.

You should send patches and contribute.

can this file be Read in by Windows Movie Maker 2 (the Microsoft video editor/converter application, free with Windows XP),

How can VLC know this? Movie Maker can open any files as long there are proper Directshow filters/codecs installed.

can Windows Movie Maker 2 Write this file

you mean, can the Windows Movie Maker 2 output similar file?

And if you want to do pure media conversion or video editing, there are better tools available than WMM or VLC.

can this file be Read in by Windows Movie Maker 2 (the Microsoft video editor/converter application, free with Windows XP),

How can VLC know this? Movie Maker can open any files as long there are proper Directshow filters/codecs installed.

can Windows Movie Maker 2 Write this file

you mean, can the Windows Movie Maker 2 output similar file?
And if you want to do pure media conversion or video editing, there are better tools available than WMM or VLC.

1) the VLC developers should be testing the compatibility of their output files with the ubiquitous Windows Movie Maker. Everyone has this video editor, for free with Windows XP (95% of the world).
2) Sometimes Windows Movie Maker succeeds in Reading a media file, generates clips, can play the file from the clips,
but cannot Write the file out from its Storyboard into the formats selectable within WMM
or Writes a file with stuttering video.
3) If those other video edit applications are free and work with Windows XP, then that would be interesting information.

No developers are on Windows... Therefore no developers has WMM.

At Microsoft ? That may be true. Windows Movie Maker 2 has not been improved in more than a year.
However, it is a reliable program with some nice features, which simply needs to be fed with media it is capable of digesting.
VLC development should assume the presence of WMM 2 on 95% of PCs out there, and ensure that VLC generates media output which can interoperate with WMM 2.

No VLC developers are on Windows...

Are you a troll or what?

No VLC developers are on Windows...
Are you a troll or what?

"Troll" ?
Now you are beginning to sound like a public relations firm, name calling in an attempt to silence dissent for corporations you serve.
You are saying that VLC developers use Linux or MAC exclusively ?
That should not affect the ability to generate certain media encodings and encapsulations, which could work with Windows Movie Maker 2.
Mpeg-1 generation should be trivial, since it is probably the earliest encoding type, with huge amounts of existing encoder code bases from which to choose.

No, you are just telling developers what they should do... While you don't do anything.

If you don't understand that developers work on their free time on what they want, you still don't understand what is open source and what is VLC.
But how many time we state it, you seem to don't understand it, like on the other thread of this forum.

Don't complain if you are ignored, if you keep telling people what they should do and if you don't do anything.

Are you saying that the Linux version of this VLC program has better features and reliability than the Windows version ?
How is development of the Windows version accomplished without some of the developers working on a Windows development platform ?

Are you saying that the Linux version of this VLC program has better features and reliability than the Windows version ?
How is development of the Windows version accomplished without some of the developers working on a Windows development platform ?

Cross-compilation.

Are you saying that the Linux version of this VLC program has better features and reliability than the Windows version ?
How is development of the Windows version accomplished without some of the developers working on a Windows development platform ?

Cross-compilation.

Cross-compilation does not include debugging by the developer on the target platform of the cross-compiler. Are these VLC developers running some sort of Windows kernel virtualization engine, under Linux ?

Are you saying that the Linux version of this VLC program has better features and reliability than the Windows version ?
How is development of the Windows version accomplished without some of the developers working on a Windows development platform ?

Cross-compilation.

Cross-compilation does not include debugging by the developer on the target platform of the cross-compiler. Are these VLC developers running some sort of Windows kernel virtualization engine, under Linux ?

Correct. Atm we only release VLC media player for windows because it still happens to compile. There is no active Windows specific development at this moment.

To my knowledge there is not a kernel call compatibility between Linux and Windows.
Are you saying the same code base compiles for Linux and Windows ?
Or is there a huge amount of conditional compilation.

Code ain't 100% same on all platforms, there are some platform related #ifdefs in code and also different output modules for different platforms (for example DirectSound is Windows only), but most code works on all platforms. And you can compile all versions from one machine using toolchains and crosscompile settings (MingW turns nix stuff to Windows compatible code).

But there aren't full day devs to keep Windows code running so there are lots of bugs in Windows version.

Yes, there is a huge amount of conditional compilation.

Interesting. And what about the user interface elements ?
How is GTK/QT/X or whatever, converted to Windows GUI calls ?

QT4 does all by itself. Same for WXwidgets. It is compile time thingy so the libs and source files are different in Windows, Linux etc. but the API is 99% same. So one GUI code works in all platforms.

This program must have a magic makefile.
Still I doubt that this is a bug associated with Windows translation of the code. I would assume that the Linux version of this program fails to parse incomplete files to generate sporadic video within them, fails to perform closed captions, fails to convert properly and fails to readily display media information like video resolution, just like the Windows version.

Most part of vlc source code doesn't depend of the plateform.
But core function, video output, audio output, networking and a lot of over stuff depend of the plateform (that's why we want a windows dev)

This is more of an embedded guy, using Windows as the main cross-compilation platform. It is hard to imagine anyone locking themselves into using Linux development tools by choice, except for Linux kernel/driver development.
You say MingW converts the network code into Windows sockets calls ?

MingW does that.
http://en.wikipedia.org/wiki/MSYS

I do like the ability to get to the stream info quickly, and latest version makes that easier than before.
Although I would wish a tiny change, which would be to allow the information window to remain up even if the media fails to read, or the stream ends. In most cases that dialog disappears.
I would like to develop for you guys on Windows, although a bit rusty, there's a lot of stuff I would like to see, including CUDA support for transcoding, but that's a massive job.

I do like the ability to get to the stream info quickly, and latest version makes that easier than before.
Although I would wish a tiny change, which would be to allow the information window to remain up even if the media fails to read, or the stream ends. In most cases that dialog disappears.
I would like to develop for you guys on Windows, although a bit rusty, there's a lot of stuff I would like to see, including CUDA support for transcoding, but that's a massive job.

Rubbish.
I find it very difficult to obtain the resolution and bit rate information in the current version, usually having to use 2 commands to obtain the informationand often the resolution information is not available.
And the bit rate information is presented in an obscure statistical calculation page along with numerous other numbers and it is unclear which is the actual bit rate number.

The VideoLan project manager should be reprimanded and/or fired for the total waste of man-hours which has gone into this project over the past 2 or 3 years.