Why is VLC discouraged?

[ForceX]

Originally Posted by 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.

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.

Originally Posted by namaiki

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]

Originally Posted by ForceX

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]

Originally Posted by roozhou

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-...-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]

Originally Posted by Ghitulescu

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]

Originally Posted by ForceX

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-...-vsfilter.html

ASS spec frozen for years? So where is the SPEC? Are you talking about this? Many features in that spec are not implemented by any render engine so far.

[Ghitulescu]

Originally Posted by MilesAhead

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]

Originally Posted by roozhou

ASS spec frozen for years? So where is the SPEC? Are you talking about this? 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]

Originally Posted by 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.

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

[roozhou]

Originally Posted by ForceX

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]

Originally Posted by roozhou

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]

Originally Posted by namaiki

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]

Originally Posted by ForceX

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.ph...72#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]

Originally Posted by ForceX

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]

Originally Posted by JanWillem32

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]

Originally Posted by roozhou

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]

Originally Posted by JanWillem32

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.