Why is VLC discouraged?

[Ziddy76]

I'm just curious and trying to find out why some encoders still discourage the use of VLC. What advantage does mplayer2 or MPC-HC/FFDShow Tryouts/Haali have over VLC?

[LoRd_MuldeR]

What encoder does discourage the use of VLC :confused:

A video encoder should produce a bitstream that conforms to a video compression standard. And every player/decoder that supports this standard should be able to play the video.

(There are some proprietary video formats that force the user to use a specific playback software, but for most video formats you can choose your favorite player)

[Ziddy76]

Maybe not discourage, but on IRC told, use CCCP instead of VLC. Just trying to find out what advantage CCCP/mplayer has over VLC. And some users hate VLC, but I've never found out why.

[Hypernova]

First, this is just my guess.

I think it is more about subtitle styling or, sometimes, mkv ordered chapter than the video itself that made those encoders (which my guess are fansubbers) discourage VLC. I do not use VLC so I don't know how good it is about these features. I think they (and their QCers) always test the releases against MPC-HC/ffdshow/Haali or CCCP (for Windows) and mplayer (for Mac/Linux) so that's why they recommended it. They probably don't want to answer questions about why it doesn't work in different softwares so VLC is discouraged. The most common question is sub styling goes wrong, I think.

So, if it works for you, I guess then go ahead and use VLC. However, if it doesn't work or something goes wrong, then don't expect them to answer why.

[Ghitulescu]

Maybe not discourage, but on IRC told, use CCCP instead of VLC. Just trying to find out what advantage CCCP/mplayer has over VLC. And some users hate VLC, but I've never found out why.

I think there are more threads and advices not to use CCCP than against VLC.

Besides, one doesn't need CCCP in order to see the movies s/he produces her/himself.

VLC has some problems, mostly related to "phoning home" rather than with stability, lack of codecs and the like.

CCCP on the other hand has lots of issues with stability of the system and related.

You may google for yourself.

[namaiki]

CCCP on the other hand has lots of issues with stability of the system and related.


You must be confusing CCCP with some other codec pack. Unless you are saying that decoding with FFDShow in software whilst using DirectVobSub for subtitles in MPC-HC "has lots of issues with stability of the system and related."

We don't even encourage the use of DXVA for the sake of compatibility/stability.

[Ghitulescu]

I'm not confusing CCCP with another codec pack. However I'm talking using 2nd hand info since I don't have it on my PC, because I did research at that time and I decided that the stability of the system was more important than to have a codec pack. VLC I use myself, on the other hand. VLC and SMplayer is all that I need to have a short idea of the media files I have ....

[Astrophizz]

I've seen VLC have issues playing back generic mkv files, like corrupting the video on seek. Also VLC doesn't support ordered chapters, advanced subtitles, or MadVR ;) There's no system stability to be lost from properly using codec packs. What research you did probably pulled up accounts of people who didn't follow instructions and installed codec packs on top of codec packs.

[Ghitulescu]

You're probably right. I think this is arguably THE CAUSE for many stability issues. I also think that CCCP evolved meanwhile. But for my needs, one maximal 2 players with integrated codecs are more than enough, especially on systems where one has no admin rights (to install and setup things).

[roozhou]

VLC has bad stability, bad subtitle support, no DXVA, bad renderer. Anything worse for a media player?

[Midzuki]

Many moons ago, I gave a try to VLC, and I disliked it, only because it could not keep its window maximized all the time.

[Ghitulescu]

VLC has bad stability, bad subtitle support, no DXVA, bad renderer. Anything worse for a media player?

I'm not defending VLC, but no crash in two-three maybe four years. I've never changed the version, it's still something 0.86 (not on this computer). Meanwhile MPlayer has about one a day (MPlayer SVN r28311) and Mplayer is supposed to be well supported.

I don't use the computer to play mediafiles (I still consider the PC not being suitable for DVD, CD or BD playback), just to play some files to check some issues or even their real name (like track 01.wav or VTS_03_2.VOB).

[roozhou]

I'm not defending VLC, but no crash in two-three maybe four years. I've never changed the version, it's still something 0.86 (not on this computer). Meanwhile MPlayer has about one a day (MPlayer SVN r28311) and Mplayer is supposed to be well supported.
MPlayer is better than VLC. 28311 is too old.

I don't use the computer to play mediafiles (I still consider the PC not being suitable for DVD, CD or BD playback), just to play some files to check some issues or even their real name (like track 01.wav or VTS_03_2.VOB).
Because you are using VLC. PC is superior at post-processing than SAPs.

[patul]

VLC has bad stability, bad subtitle support, no DXVA, bad renderer. Anything worse for a media player?

Those were the reasons I left Portable VLC behind despite its portability. Yes, it plays everything, but I won't go back to it due to those reasons. There're a lot of better free alternative players nowadays. No offense intended.

[Ghitulescu]

Anything worse for a media player?

Windows Media Player? :p The original ... :p

Since I'm not using the PC to watch movies nor to listen hifi music, just to control the files for their content, I don't care about most quality issues other people care. Also I use the portable (no install versions) for the reasons exposed above. And if they work I don't upgrade them, I hate to learn each time how to circumvent the new bugs and/or limitations every build brings with.

Except for HD sound I have no problems playing blu-ray files with these old versions I have. I've heard that some versions of VLC (above 1, which are supposed to indicate a stable/mature product) are much worse than antique ones.

[ForceX]

First, this is just my guess.

I think it is more about subtitle styling or, sometimes, mkv ordered chapter than the video itself that made those encoders (which my guess are fansubbers) discourage VLC. I do not use VLC so I don't know how good it is about these features. I think they (and their QCers) always test the releases against MPC-HC/ffdshow/Haali or CCCP (for Windows) and mplayer (for Mac/Linux) so that's why they recommended it. They probably don't want to answer questions about why it doesn't work in different softwares so VLC is discouraged. The most common question is sub styling goes wrong, I think.

So, if it works for you, I guess then go ahead and use VLC. However, if it doesn't work or something goes wrong, then don't expect them to answer why.
This. I have seen most fansubs discourage VLC nowadays, probably because VLC can't handle animated karaoke, multiposition subs and styles correctly. Meanwhile Haali seems to be the only Matroska splitter which can handle Ordered Chapters which separate the OP and ED from the main video. Correct me if I am wrong on this.

[roozhou]

Fansubbers don't have a standard and probably will never agree on a single standard. They create subtitle effects based on VSFilter's features as well as bugs. They don't care how it looks on other subtitle engine or even other versions of VSFilter. The only thing that developers of other subtitle renderer have to do is to mimic VSFilter's features and bugs instead of following the specs.

[yetanotherid]

I wouldn't have thought CCCP is really a codec pack as such, despite it's name. It's really just MPC-HC, ffdshow and Haali media splitter, pre-configured according to the CCCP "standard".

I used CCCP for years.... many different versions... without any stability issues. The only problem I ever had was with the audio sync with some of those MP4s we're not allowed to discuss here, but remuxing them would fix it. If CCCP does have any problems (such as an audio sync issue) running the installer again and allowing it to disable any other splitters/codecs etc it doesn't like, should fix it.

VLC works for me (I don't use subtitles a lot) but it won't use system codecs despite having a setting to tell it to do so (or I've never been able to get it to work) and it doesn't "feel" as good as MPC-HC.

These days I simply use MPC-HC on it's own for playback. Like VLC it has internal filters to play all the common file formats so there's no real need to install ffdshow or the haali splitter etc and you can bypass any CCCP stability issues that way.. I still install the other programs, but I use them for encoding. Rather than install the CCCP I install MPC-HC, ffdshow, haaali splitter and VobSub individually. As it comes "out of the box" MPC-HC will play pretty much all the usual formats without the need for anything else, so for most people installing MPC-HC on it's own for playback will probably be all they'll ever need (once again I don't use subtitles a lot but MPC-HC seems to render all the subtitles I've used on it's own without any problem).

[cyberbeing]

Fansubbers don't have a standard and probably will never agree on a single standard.
CCCP was a specialized playback pack designed by, tested by, and supported by anime fansubbers for guaranteed hassle-free playback and display of anime fansubs. CCCP is the fansubber standard, and it has served its purpose well for everybody involved. In this niche, VLC was the cause of 90% of playback problems for years, and thus earned a poor reputation because of it.

[namaiki]

This. I have seen most fansubs discourage VLC nowadays, probably because VLC can't handle animated karaoke, multiposition subs and styles correctly.
The newer VLC versions have an updated subtitle renderer (libass, I think) which supports animated karaoke at least.

Meanwhile Haali seems to be the only Matroska splitter which can handle Ordered Chapters which separate the OP and ED from the main video. Correct me if I am wrong on this.
There's Haali and awesomely some MPlayer2 builds as well.

On a side note, do any of you know how to set VLC Player to expand TV to PC levels for all video?
edit: OpenGL video output

[ForceX]

Fansubbers don't have a standard and probably will never agree on a single standard. They create subtitle effects based on VSFilter's features as well as bugs. They don't care how it looks on other subtitle engine or even other versions of VSFilter. The only thing that developers of other subtitle renderer have to do is to mimic VSFilter's features and bugs instead of following the specs.

That statement is highly misleading. As cyberbeing mentioned, CCCP project was established as a standardized filter pack and settings to support most of the fansubs out there, out of the box and without people needing to configure the specific settings for proper playback. H264 is now a universal standard in fansubs along with AAC/FLAC. The reason MKV got this much reception in the first place was mostly based on fansubs adopting the format, not the video industry. The reason there isn't a single standard in fansubs is because of hardware playback constrains, not fansub community interest. If you want PS3/X360 playback support, you can't have MKV with FLAC, and if you want good softsubs with karaoke, MP4 is a no-go.

As for caring about VSFilter, what alternative was there? No other subtitle renderer even had decent support for ASS subtitles, and libass is very new. Up until a few months ago PotPlayer's renderer was garbage and KMPlayer's one is out of date. The reason VSFilter is the de-facto standard is because it's used in Aegisub, the community-standard timing/typesetting/karaoke editor. They use a patched VSFiler for the software http://www.animereactor.dk/aegisub/readme-vsfilter.txt and that's the reason it will ever be supported by any fansub group, ever for SSA/ASS subs. As far as specs go, however Aegisub and VSfilter works IS the spec now. That's how de-facto works.

The newer VLC versions have an updated subtitle renderer (libass, I think) which supports animated karaoke at least.
I just tried a VLC nightly (after a long time) and the subtitle renderer does seem to have been greatly improved. It seems to handle kara effects and embedded font and styling quite well now, which is great to see. However using the default renderer in my Win 7 (I am thinking it's Direct3D output) I get the wrong hue for the sub color:
http://i55.tinypic.com/20f3mf9.png
The correct one is this:
http://i54.tinypic.com/2mpl8qw.png

However as you can see MPC-HC internal renderer has its own problems. I can't get the subs to render within the video frame itself, it renders throughout the window or outside the window and gets cropped, depending on whether the option of positioning relative to video frame is ticked or not. PotPlayer works better in this regard. VSFilter also works, of course.

[roozhou]

As for caring about VSFilter, what alternative was there? No other subtitle renderer even had decent support for ASS subtitles, and libass is very new. Up until a few months ago PotPlayer's renderer was garbage and KMPlayer's one is out of date. The reason VSFilter is the de-facto standard is because it's used in Aegisub, the community-standard timing/typesetting/karaoke editor. They use a patched VSFiler for the software http://www.animereactor.dk/aegisub/readme-vsfilter.txt and that's the reason it will ever be supported by any fansub group, ever for SSA/ASS subs. As far as specs go, however Aegisub and VSfilter works IS the spec now. That's how de-facto works.
De-facto is exactly the problem. MKV has a well-written spec, and all demuxers and muxers follow it. That's why more and more standalone players start to support it. Remember MKV is also an open-stardard.

There is a quite dated ASS spec, but no fansubbers try to improve it. Libass has supported karaoke effects since long ago, but a lot of ass subtitles created by fansubbers mess up in libass. They are using VSFilter "features" which are never mentioned in the ASS spec. Some subtitles are written in bad syntax, which are rejected by libass and ffdshow, but accepted by VSFilter. VSFilter itself is highly unportable. It relies heavily on Windows stuff, like fonts. And it cannot even be compiled by gcc because it uses a lot of MFC craps.

If I were a hardware engineer, how could I implement a subtitle renderer by investigating the bugs of VSFilter, instead of reading the spec?

P.S. another bug in VSfilter. When rendering subtitle on a YUV frame, it never takes BT601/BT709 issue into account. BT601 matrix is always used.

[cyberbeing]

Everybody is aware of the problems with VSFilter, roozhou.

jfs (Aegisub dev | former-VSFilter hacker) gave up fixing/expanding VSFilter way back in 2007, and decided it was best to write a new well-defined standard (AS5), authoring application (Aegisub 2), and reference rasterizer from scratch, which is well supported on Windows/MacOS/Linux from the get-go. That is the three-prong approach needed to gain support of the fansubbing community, but unfortunately all three projects appear to have stalled. If were lucky, someone will step-up within our lifetime and solve all our subtitle woes. Until then, we are stuck with a reference rasterizer made of numerous buggy patched VSFilter revisions and a messy ASS (ASS2/ASS3) spec which is a nightmare to support.

[ForceX]

There is a quite dated ASS spec, but no fansubbers try to improve it. Libass has supported karaoke effects since long ago, but a lot of ass subtitles created by fansubbers mess up in libass. They are using VSFilter "features" which are never mentioned in the ASS spec. Some subtitles are written in bad syntax, which are rejected by libass and ffdshow, but accepted by VSFilter. VSFilter itself is highly unportable. It relies heavily on Windows stuff, like fonts. And it cannot even be compiled by gcc because it uses a lot of MFC craps.

If I were a hardware engineer, how could I implement a subtitle renderer by investigating the bugs of VSFilter, instead of reading the spec?

P.S. another bug in VSfilter. When rendering subtitle on a YUV frame, it never takes BT601/BT709 issue into account. BT601 matrix is always used.
Fansubbers are hardly coders, they just improvise with whatever tools they have. The ASS spec has been pretty frozen for years now and nobody is asking for new feature. Moreover, Niels Martin Hansen at Aegisub has decided not to entertain any new addition to the ASS specs. http://blog.aegisub.org/2010/02/old-and-present-vsfilter.html

The basic notion is that people are still using very old VSFilter builds from 2004 which are somehow still in circulation, which creates incompatibility with new extensions added to VSFilter specs in 2008. Although I personally don't support such a backward thought, it's a fact that Aegisub is virtually the only ASS sub editor in the fansub community, and no matter how you improve or expand libass or VSFilter, unless Aegisub decides to support that, it's pointless. Yes, VSFilter has not been actually updated in a long long time, it doesn't even support NV12 output, but it's not like libass is that much better an option either. There isn't even a directshow filter based on libass, so it's pretty irrelevant to the people using VSFilter. You can expect more support for libass after there are actually third party renderers using it out there, not the other way around. Until then, VSFilter is here to stay.

[MilesAhead]

I'm not defending VLC, but no crash in two-three maybe four years. I've never changed the version, it's still something 0.86 (not on this computer). Meanwhile MPlayer has about one a day (MPlayer SVN r28311) and Mplayer is supposed to be well supported.

I don't use the computer to play mediafiles (I still consider the PC not being suitable for DVD, CD or BD playback), just to play some files to check some issues or even their real name (like track 01.wav or VTS_03_2.VOB).

I should have stayed with 1.0 but I kept looking for PGS subs support. They added PGS and XSubs support at the expense the window disappears every time I touch it. It's totally unusable for me now.
If you have 1.0 or earlier, if it ain't broke don't fix it. :(

[roozhou]

Fansubbers are hardly coders, they just improvise with whatever tools they have. The ASS spec has been pretty frozen for years now and nobody is asking for new feature. Moreover, Niels Martin Hansen at Aegisub has decided not to entertain any new addition to the ASS specs. http://blog.aegisub.org/2010/02/old-and-present-vsfilter.html

ASS spec frozen for years? So where is the SPEC? Are you talking about this (http://moodub.free.fr/video/ass-specs.doc)? Many features in that spec are not implemented by any render engine so far.

[Ghitulescu]

I should have stayed with 1.0 but I kept looking for PGS subs support. They added PGS and XSubs support at the expense the window disappears every time I touch it. It's totally unusable for me now.
If you have 1.0 or earlier, if it ain't broke don't fix it. :(

Maybe I should have added that I used portable versions, no install, thus no interferences with system's codecs and file associations and and and...

[serendipitydawg]

VLC from my perspective as an absolute newbie is absolutely wonderful.

I barely understand what most of you are on about here, but when I recently bought an Acer Revo R3700(Intel Atom+Ion) and got totally baffled trying to enable hardware acceleration to watch some HD TV I downloaded, it took a brief Google and checking one check box in VLC to achieve the desired result.

[ForceX]

ASS spec frozen for years? So where is the SPEC? Are you talking about this (http://moodub.free.fr/video/ass-specs.doc)? Many features in that spec are not implemented by any render engine so far.
Pretty much. The point here is that Aegisub doesn't actually support anything beyond what VSFilter offers, and they will not extend their support of the format further. As long as no editor is offering the functionality, whether the renderers support it is moot.

The problem here is not that renderers don't support all the functions of the spec, since none of the sub editors are creating codes which support these non-existent functionalities; the problem is that they don't even strictly conform to the standard for which they do. ASS subs support in players like DivX or Splash is just atrocious, and players like Zoom, AFAIK, rely on VSFilter, which does work and will work for 99% of all subs out there because Aegisub conformance. Even the sub editors don't actually strictly conform to specs. Imagine what H.264 would be if there weren't a complete spec-compliant encoder. No matter how much you make your decoder spec-compliant, it'd be pointless.

[namaiki]

VLC from my perspective as an absolute newbie is absolutely wonderful.

I barely understand what most of you are on about here, but when I recently bought an Acer Revo R3700(Intel Atom+Ion) and got totally baffled trying to enable hardware acceleration to watch some HD TV I downloaded, it took a brief Google and checking one check box in VLC to achieve the desired result.

The standalone MPC-HC will generally do that by default.

[roozhou]

Pretty much. The point here is that Aegisub doesn't actually support anything beyond what VSFilter offers, and they will not extend their support of the format further. As long as no editor is offering the functionality, whether the renderers support it is moot.

You don't need aegisub to create ASS subtitles. You can create and edit .ass files in any text editor. This is quite different from H264 because no one writes H264 bitstream in a hex editor. So whether subtitle editor supports it is not very important.

If aegisub needs a frozen feature set, write down the spec. It should define all supported syntax and how it is rasterized. ASS is not HTML and VSFilter is not IE6.

[ForceX]

You don't need aegisub to create ASS subtitles. You can create and edit .ass files in any text editor. This is quite different from H264 because no one writes H264 bitstream in a hex editor. So whether subtitle editor supports it is not very important.

If aegisub needs a frozen feature set, write down the spec. It should define all supported syntax and how it is rasterized. ASS is not HTML and VSFilter is not IE6.
The fact of the matter is that nobody is actually or will be using text editors for ASS subbing. That's time consuming and pointless. The main producers of ASS subs are not professionals, they could care less about ensuring compatibility. There are no commercial impetus of using the format, and much like most other open-source softwares out there, the developers aren't willing to invest time in writing down a spec rather than actually developing the software. As far as they are concerned, it works in the environment it was meant for (VSFilter) and that's enough, no need to redefine the wheel.

From one perspective, it IS like the IE6 and HTML scenario. When IE6 was the major browser out there, webmasters would constantly break standards to ensure compatibility. It sucks for developers but it works better for the general masses. There isn't even any guarantee that anyone will fix VSFilter if Aegisub even fixes all the non-conformant issues. With the lack of any decent alternative to VSfilter, breaking existing compatibility to just adhere to a spec that no one yet fully supports globally is rather stupid.

I don't quite see the issue in adhering to the feature subsets that VSFilter supports in the first place. Sure libass might some day provide full spec compliance but if Aegisub doesn't support a few of those extensions and you'd die without them, yes, you can always edit the file with a text editor and be done with it (of course it won't run anywhere but whatever). Libass needs to be everywhere before you should expect to see any change in the status quo, and even libass isn't fully feature complete or bug-free yet. Changing anything at this point, from Aegisub's perspective, is rather counter-productive.

[yetanotherid]

On a side note, do any of you know how to set VLC Player to expand TV to PC levels for all video?

If there's a setting to do so, I couldn't find it.
If your video card can be set for video levels, it's probably better to do it that way, as then all video will display using the same levels regardless of the video player being used.
For Nvidia cards at least, the option is under "adjust video settings" in the Nvidia control panel.

[roozhou]

I don't quite see the issue in adhering to the feature subsets that VSFilter supports in the first place. Sure libass might some day provide full spec compliance but if Aegisub doesn't support a few of those extensions and you'd die without them, yes, you can always edit the file with a text editor and be done with it (of course it won't run anywhere but whatever). Libass needs to be everywhere before you should expect to see any change in the status quo, and even libass isn't fully feature complete or bug-free yet. Changing anything at this point, from Aegisub's perspective, is rather counter-productive.
The funny thing is that aegisub suggest not to use any feature that VSFilter 2.23 dosn't support, but actually hardly any fansubbers are using 2.23 now. So how could I know which is the new feature? By looking at the diff between the source code of two versions? Should the bugs fixed in later version of VSFilter be considered new features?

BTW new features are important. The main advantange of ass is karaoke and drawing. Unfortunately the embedded bitmap is not supported by official VSFilter IIRC. It requires thousands of lines, sometimes one line per pixel, to draw a very simple pattern. One of my friend send me 200MB .ass file. The loading of the subtitle in VSFilter took 10+ minutes and finally ran out of 2GB address space. The inclusion of embedded bitmaps, which is present in the ASS spec, will ease all these things.

[ForceX]

I think you're getting the wrong idea here. You can always change the default patched VSFilter 2.39 renderer that comes with Aegisub with something newer (even the latest MPC-HC builds) or VSFilterMod. Their "support" goes as far selecting which version of VSFilter to include and not providing the access to functions which they consider to be extensions beyond which they consider the base spec (which is apparently some VSFilter in 2004). Here's the dev's comment to refresh your memory: http://forum.doom9.org/showthread.php?p=1375872#post1375872

If you want to support the latest VSFilter 2.40 then just replace Aegisub's VSFilter with MPC-HC's and you're good to go. You can actually see which of the effects work first hand, Aegisub will not actually stop you from creating ASS using extensions which are not officially supported, if you know the specs. It is however, very unlikely that anyone would bother changing the default renderer. Selecting an old version as default just makes it more probable to be more compatible with the larger audience. As for how you know how versions differ, well, you can blame that on the lack of documentation on VSFilter's part.

As for the bitmap part, yes that would be nice, but a lot of things would be nice in a lot of programs, you have to maintain a certain balance of features and feasibility when creating specs. ASS was never a well-thought-out spec with long-term vision to be supported by hardware players, it just threw in everything that ever seemed to be possible to do to subs. I am no engineer but I can guess bitmap image manipulation would be quite expensive to do on hardware. Again, if libass doesn't support it, blaming VSFilter is pointless (although I think VSFilterMod supports that). The fact is that there doesn't actually seem to be much development to VSfilter, so any problems and shortcomings now are likely to persist over the years.

[roozhou]

I am no engineer but I can guess bitmap image manipulation would be quite expensive to do on hardware.
This is completely wrong. Bitmap requires less hardware resources. Your video card can fill billions of triangles with texture within a second. Using D3D/OpenGL to render is simpler than rasterize it in pure software, for both comupters and programmers. Vector graphics are less effecient than rasterized images here.

[JanWillem32]

Actually, both pixel-based graphics and vector-based graphics have their use (if well-implemented). Note: for my explanation I'm ignoring that the ASS specification lacks gradients, other color notation formats than 8-bit RGBA (I'm not sure it's with sRGB, bt.709, bt.601 or other properties) and MPC-HC uses a single-threaded CPU approach to render the fonts, subtitles, OSD and stats screen.
The ASS specification should never have added bitmap support. Input of vector and bitmap data from a single data stream makes processing a disaster.

Normal 2D bitmapped subtitle image data requires a mixer to interpret the RGB/Y'CbCr/other binary format and write it on to a working texture of the native resolution. Next, the surface needs to be positioned and scaled to match the so-called world view projection in screenspace (a bunch of floating-point vectors in space, relative to the viewing position, but still only for a flat, 2D view of the object). For scaling and sub-pixel accurate positioning, you can use the dumbest mode of nearest neighbor projection with an 8-bit RGB target, a slightly better surface with bilinear filter, or an entire chain of texture rendering items, like the path I'm trying to create for the main video renderer. The last item is a screenspace blend on top of the images from the rendered video stream.

Vectorized subtitle image data in a modern rendering method requires a vector composition stage, which consists of a world view projection in screenspace that is filled with all vectors (usually just lines and curves for basic "2D" stuff, think of a sort of wireframe model). Those items form 2D or 3D surface parts that can be painted on during rasterization. The input doesn't use any pixel data, so there's no need for a mixer and input texture resources. The rasterization stage is where quality can be set. It's easy to change the anti-aliasing quality and the output surface bit-depth. The last item is again a screenspace blend on top of the images from the rendered video stream.

To use both bitmapped and vectorized input, two subtitle rendering engine parts would have to be active at the same time. It would require special care that the texture(s) generated from bitmapped input data is already properly scaled, rotated and clipped to make it possible to blend it directly with the output from the rasterizer. In essence, the only thing the two parts could share are the color controls, color management and dithering stages (together with the screenspace-sized texture that holds the image created from the video input stream, after its screenspace rendering stages).
I don't think any programmer would be happy to write such a shared rendering stage. On top of that, keeping performance in mind... I'd rather not think about having those two subtitle engine parts active at the same time when rendering animated subtitles. The only things that would be worse than that would be adding lighting, true 3D objects or ray-tracing support.

For choosing between the bitmapped and vectorized image formats, I very much prefer vector graphics for being able to scale infinitely, and not take up a lot of space. That is valid as long as the content isn't photographic or extremely pixel-based. I can't imagine that that applies to subtitles.

[roozhou]

For choosing between the bitmapped and vectorized image formats, I very much prefer vector graphics for being able to scale infinitely, and not take up a lot of space. That is valid as long as the content isn't photographic or extremely pixel-based. I can't imagine that that applies to subtitles.
How do you represent an existing logo with a vetorized image? Maybe the original logo was drawn in vectors and you have access to it, but convertion between different vector graphic formats is not as easy as convertion between BMP and JPEG.

And I don't think the programmer has to separate bitmap and vector rendering. Bitmap processing looks like mapping texture on polygons, while vector processing looks like drawing lines and fill triangles with color. You can use 3D APIs to do these and each job takes less than 10 lines to finish.

[JanWillem32]

How do you represent an existing logo with a vetorized image? Maybe the original logo was drawn in vectors and you have access to it, but convertion between different vector graphic formats is not as easy as convertion between BMP and JPEG.

And I don't think the programmer has to separate bitmap and vector rendering. Bitmap processing looks like mapping texture on polygons, while vector processing looks like drawing lines and fill triangles with color. You can use 3D APIs to do these and each job takes less than 10 lines to finish.Format conversions are indeed problematic. That still doesn't excuse the fact that for rendering an inserted bitmap, the programmer would have to make it possible to dynamically start and stop the renderer items needed to render it. It needs an additional mixer to read the bitmapped input and generate a working texture output. After that, it needs do scaling, rotation, subpixel positioning, clipping and whatever else the standard requires for rending these objects. That must be done independently from the vector rendering stage, as that one really can't deal with these things.
The vector renderer rarely draws a triangle patch. It usually doesn't if it's rendering fonts, as those typically use (quadratic) Bézier curves natively. Note that this type of rendering doesn't use a conventional 3D approach. For instance, if you use a pixel font, it will only use nearest neighbor for the basic scaling, as it converts all pixel borders to vectors prior to the filling stage. Of course, you are free to use 2D or 3D engines to use the texture generated by the rasterizer. That's even a requirement if you want to alpha-blend the (preferably small) output texture from the bitmap rendering part on the screenspace-sized texture.

MPC-HC's subtitle renderers and underlying parts consist of several tenthousands of lines (code is public, also includes a lot of inline assembly). My attempts to improve some parts of it, have only increased that amount of code so far. (More developers for this item are very welcome to join.)
Modern approaches to rendering vectorized items can reduce the amount code for that part, but not much. Also, the code parts that take care of bitmapped subtitle streams are only going to increase in size, as more formats are to be supported (most notably, the blu-ray PGS code needs a big update soon).

[roozhou]

Format conversions are indeed problematic. That still doesn't excuse the fact that for rendering an inserted bitmap, the programmer would have to make it possible to dynamically start and stop the renderer items needed to render it. It needs an additional mixer to read the bitmapped input and generate a working texture output. After that, it needs do scaling, rotation, subpixel positioning, clipping and whatever else the standard requires for rending these objects. That must be done independently from the vector rendering stage, as that one really can't deal with these things.
I don't think bitmap data has to be dynamically read. They can be read and load as texture at the beginning, similar to embedded fonts in ASS.

MPC-HC's subtitle renderers and underlying parts consist of several tenthousands of lines (code is public, also includes a lot of inline assembly). My attempts to improve some parts of it, have only increased that amount of code so far. (More developers for this item are very welcome to join.)
Modern approaches to rendering vectorized items can reduce the amount code for that part, but not much. Also, the code parts that take care of bitmapped subtitle streams are only going to increase in size, as more formats are to be supported (most notably, the blu-ray PGS code needs a big update soon).
Sounds interesting. I hope someone gets rid of MFC, GDI and VC inline-assembly from VSFilter's parser and render engine so it can be easily port to other projects.

[JanWillem32]

I don't think bitmap data has to be dynamically read. They can be read and load as texture at the beginning, similar to embedded fonts in ASS.If exposed at that stage by the file splitter and then the internal subtitle splitter, it's indeed possible to load several textures from the mixer. That's another complexity factor then, because it needs pooling, what the regular texture-based subtitles don't use. On the other hand, that does eliminate the mixing stage further on. The other rendering parts will still need to be loaded dynamically to make it possible to render those items to screenspace with the right properties.Sounds interesting. I hope someone gets rid of MFC, GDI and VC inline-assembly from VSFilter's parser and render engine so it can be easily port to other projects.I'm afraid that those are the main parts of the renderer that were written with some efficiency and performance in mind... (And it's at least commented for a good part.) Although changing the GDI parts to DirectX 10/11 items would be nice.

[Ghitulescu]

I've found by accident an older (2010) German PC magazine about VLC IIRC 1.05. They had only nice words about it (it wasn't a "hidden ad", just a comparison of features, tips, tricks and hints for newbies etc.).
For newbies is probably the best player, if correctly installed and configured.

[Dark Eiri]

I've found by accident an older (2010) German PC magazine about VLC IIRC 1.05. They had only nice words about it (it wasn't a "hidden ad", just a comparison of features, tips, tricks and hints for newbies etc.).
For newbies is probably the best player, if correctly installed and configured.

I'm really used to tweaking every single thing everywhere on players and codecs. I feel like crying when I see the configuration window for VLC. Specially the advanced one.

The fact it also doesn't use EVR or any other known renderer (or at least it doesn't call it by the appropriate names, all I see is retarded gibberish like DirectX or DirectDraw Renderer, when VMR/EVR are used in EVERY SINGLE OTHER PLAYER, and I don't even think they are the same thing) is really annoying too. It's a complete mess.

I think MPC-HC is much more user friendly, in every single aspect. VLC had the edge to play broken files in the past, but I never found anything that MPC-HC can't play just fine in the last 3 years.

[mr.duck]

I think MPC-HC is much more user friendly, in every single aspect. VLC had the edge to play broken files in the past, but I never found anything that MPC-HC can't play just fine in the last 3 years.

VLC does everything is seems (for most people). I use MPC-HC but still have to rely on VLC to watch files that are being written to (so I can watch the F1 live). Even better, with VLC I set it up to steam the file over the network so you don't even have to seek to the end to see the most recent bit, you just watch it.

Point is, if VLC is your main player, you don't need to rely on anything else. Not even codecs, etc.

[Vilx-]

I'm going to give a +1 for VLC. Ever since I migrated to it, I've never looked back and never used anything else (for movies). And never worried about codec packs or system stability either (when codec packs get messed up, things get REALLY hairy). Although I've had the odd VLC crash here and there, it's stable 99% of the time. Also I don't know what the complaints about subtitles are - I've watched hundreds of videos with subtitles, DVD and non-DVD alike, and I've never had any problems with them.

Just to be complete - yes, about 5 years ago I too disliked VLC because of its stability issues. For example, it would completely lock down the system if you ejected the DVD while it was playing it. But it's come a long way since then.

[Hera]

From a pure performance standpoint, MPC:HC is the de-facto winner for me.
Dark Eiri also has another criticism that I have for VLC.

[smok3]

gui wise i like this one:
http://www.youtube.com/watch?v=35DsphxQn_M

usage wise would be mplayer cli version.

(mpc-hc and vlc suffers from "featurities" > only my opinion)

[DGMurdockIII]

vlc i better at cross platform support

[Astrophizz]

Better than MPlayer?

[Przemek_Sperling]

Well, I have to say that VLC for Windows and VLC for Linux are like two different products. I used it with my underpowered laptop (with Win XP SP3) and my experience with the player was bad. Often crashes, bad subtitle support, and the high consumption of CPU cycles plus a lot of minor glitches. On the other hand, the Linux version of the player is rock stable, and not so resource hungry as I thought. Only the subtitle support is so-so, the rest is pretty OK.