Translated cellphone texts: stutter
 

Hi everyone, I've been experiencing stuttering issues with some soft-subbed videos. This happens for instance when translated cellphone texts are shown. By 'translated texts' I mean texts whose English translations are displayed on the phone screen itself (I believe there might be a more specific term for this type of subbing). I don't have that problem with 'regular' bottom subtitles (e.g. for dialogues).

I use MPC-HC with LAV filters and madVR. I also have xy-vsfilter for subtitle rendering.

I think playing such scenes with translated cellphone texts is quite demanding in terms of CPU resources. Do you think my CPU (see my profile for details) is simply too slow?

Your CPU is relatively strong. Are you sure xy-vsfilter is actually being used? Sample file? What xy-vsfilter version?
http://code.google.com/p/xy-vsfilter...Downloads?tm=2

Thanks for your reply. Based on the xy-vsfilter website's FAQ I'm fairly positive it's being used properly. I have the latest stable 32-bit release (3.0.0.211).

Some details I forgot to mention:
- the video temporarily stutters or freezes but the audio keeps playing normally
- in some cases it makes MPC-HC crash
- disabling the subs during the scene prevents the problem

Here's a screenshot of a scene that caused the video to stutter and MPC-HC to crash. It's not really a text but this is the type of subtitle rendering that sometimes (though not always) causes issues:
http://img209.imageshack.us/img209/3856/tu0l.jpg

An actual sample file would be great, a screenshot is fairly useless.

My bad, I thought you wanted a screenshot to see what I meant exactly. Here's a 20-second sample file:
http://www.mediafire.com/?q74exj91ncpahw8

I've just tested this file: the video still stutters and MPC-HC still ends up crashing, so it should be a representative sample for this problem :)

That sample acts rather peculiar on my system as well, so it's not just you. xy-vsfilter does not display the subtitles from ~2s to ~5s (when zoomed in) at all. XySubFilter displays them but they are definitely too complex for real time playback even for my core i7. Same with libass based players.

One of the xy guys is active here - let's wait what he has to say about it. Maybe xy can be optimized more (plus xy-vsfilter fixed, if it really is a bug) but the group is most certainly going overboard and should be slapped on the fingers.

It played without a hitch using mplayer2 on Ubuntu Linux. I see the subtitles in the early phone sequence where the character asks the boy to name her. That's with the default xv output driver, too, not one that uses hardware decoding. The machine is an i5.

This is sort-of a known issue with how xy-VSFilter/XySubFilter currently handles caching and rendering, but scripts such as this will always be rather CPU heavy.

Currently, long lines which may reside mostly off-screen are rendered and cached as a single massive rectangle, which can eat through a lot of RAM and hurt performance on samples such as this where blur, bord, fscx, fscy, are all changing dynamically per single-frame lines. That zoom in section likely creates around 120 4000x1000 rectangles in those few seconds which each need to be renderered/scaled/blurred basically from scratch and finally off-screen clipped.

There is definitely room for improvement by making the caches more intelligent or addition of look-ahead prediction, but no easy short term fix. Even so, I wouldn't expect performance any better than Libass currently achieves here.

What about xy-vsfilter not displaying the subs at all?

I tested VLC, mplayer2 and mpv. Core i7-860 (Lynnfield, 2.8 GHz stock, 3.0 Turbo)

What do you mean? xy-VSFilter 3.0.0.211 shows the subtitles just fine, and so do all of our GIT builds. You must be using an unofficial build with modified commits.

Spot on (I guess you tested?). Was using 3.0.0.237 from CCCP experimental. 211 does not exhibit the problem.

@SeijiSensei: I already use Ubuntu for work. When it comes to video playback, however, I seem to have some hardware compatibility issues which translate into poor performance, tearing and no audio through HDMI.

By the way, I ran some tests again but this time I compared MPC-HC with XBMC (Windows version). There is some stutter with XBMC too but it's much less noticeable. And it doesn't crash. As cyberbeing suggested, the problem might be RAM-related: while playing the file XBMC uses 200-300MB RAM, whereas MPC-HC eats up over 2.00GB. CPU use, on the other hand, is not much higher for MPC-HC than for XBMC (in fact it's even a little lower).

My issue with XBMC is that it is more likely to stutter when playing subbed openings and endings, which MPC-HC + xy-vsfilter usually handles flawlessly. Well, you can't (always) have everything.

I recommend installing SMPlayer from the repositories which is an excellent front end for mplayer. If you don't have mplayer installed already, "sudo apt-get install smplayer" will pull it in as a dependency automatically. Ubuntu now distributes the "mplayer2" fork of mplayer as the default.

If you have an NVIDIA or ATI card, you can choose drivers that offload the graphics decoding to your video card. (Modern Intel cards also support the VAAPI interface that ATI cards use.) As I say even with the stock xv driver and an i5, I have no problem playing the clip with mplayer2.

A bit of a slow responce, as I only noticed this thread now.
This is due to the fact that somewhere along early 2013 someone came up with a sample that would just cause xy-VSFilter to OOAS (Out Of Address Space) on 32bit systems during playback. We discussed it with cyberbeing back then, and have had two checks added to our builds since then, the latter of which (that has been in the CCCP releases for some time now) basically blocks textures that are greater than (8000 * 8) * (500 * 8) samples large (the * 8 is due to the fact that VSFilter internally renders at 8x scale).

I have also responded in more detail on our forums for those who want a more extensive explanation.

I don't like it, I didn't or don't want to do it, but at the time it looked like the only thing to do.

Edit:
I got irritated by this enough to just go and debug the first crashing sample. After a few hours and about ten crash dumps, I seem to have been able to not have xy-VSFilter crash with the known samples.

Large things will still allocate a lot of memory, and will thus be slow, but since the sanity check was far from perfect (and because, while the Aegisub folk agreed on limiting VSFilter, they are currently shipping a VSFilter that doesn't limit, which creates a disparity), I guess there's not much else to do for now but to remove it and instead use this uncanny fix until the next crashing sample at another code path that doesn't get checked :) .

Things that could not allocated of course will just not show up, but that's kind of the thing: You either get a crash or you just bail out of that part of the rendering chain.

More information here.

I did a quick test with SMPlayer and xv: the video stutters a bit (though it doesn't crash), and the audio gets and stays out of sync. Also, I still have screen tearing and the HDMI audio problem anyway. I might give it another try with VAAPI, but not right now because of work work work.


edit: Actually the driver I used was x11. xv doesn't work for some reason.

VAAPI does not work on 10 Bit H.264 (like your sample) anyways.

Is that so? Well, I guess I won't bother then. Thanks for saving me some time.