• 1
  • 16
  • 17
  • 18(current)
  • 19
  • 20
Jerky playback Dharma B2 and SVN /Ion
ezechiel1917 Wrote:Regarding these bugs, no updates afaik, subtitles caching is most annoying one for me as it stutters even with 720p videos. I really wish you can track it down and incorporate fix. Thumbs up!

Yes, it annoys the hell out of me too. The resolution will not affect this I think. Ideally the subtitle renderer needs to be made into a separate thread so that it can't block the video render. I had stopped looking because this one looked the most difficult to solve. I have been using my fixes for 1., 2. & 5. now and they seem to work well or at least better then the trunk I started with. A/v sync is always well maintained through different actions (as well as ffmpeg will allow I think), and the visible required adjustment to video for no drift seems quite accurate. I would think it would be quite easy to implement 7. and I have so far seen no real need for 3. So attempt thorough testing on other files/fps/xbmc-sync-settings/windows-7 is probably the next thing for me to do.
Reply
Gujs Wrote:Hi,

They changed to git now. You can fin them on github:
https://github.com/xbmc

Ah...that would explain it. Darn it...now I have to learn this and it doesn't look so friendly. Certainly not so easy to peruse the diffs.
Reply
I've found out problem causing subtitle stutter may be default arial.ttf font itself. I've tried different custom fonts (Arial, Calibri) and I couldn't notice stutter anymore! Not properly tested through whole video yet, but I'm definitely not seeing that annoying stutter compared to default font when first time normal or styled subtitles appear (also no WARNING: Decode - avcodec_decode_video didn't consume the full packet. in log). Is it possible that default one is more resources hungry? Original arial.ttf is 4,2MB size vs 700-800KB those I've tested.

Even with this fact I think playback should be stutter free with builtin font, and I don't remember having this issue with 9.11 version.

Hope this helps.
Reply
ezechiel1917 Wrote:I've found out problem causing subtitle stutter may be default arial.ttf font itself. I've tried different custom fonts (Arial, Calibri) and I couldn't notice stutter anymore! Not properly tested through whole video yet, but I'm definitely not seeing that annoying stutter compared to default font when first time normal or styled subtitles appear (also no WARNING: Decode - avcodec_decode_video didn't consume the full packet. in log). Is it possible that default one is more resources hungry? Original arial.ttf is 4,2MB size vs 700-800KB those I've tested.

Even with this fact I think playback should be stutter free with builtin font, and I don't remember having this issue with 9.11 version.

Hope this helps.

Thanks. That is useful to know - I will have a play (though now I am not sure whether to first try to sync up with latest git version - I see some useful adjustments for the GetCacheTime/GetDelay functions that might make a/v sync more accurate and I think there might be some ffmpeg adjustments).

I am probably off the mark but I suspect the font is in some way loaded into the graphics controller and it is this initial load that takes some time. I certainly can't see any operating system related paging during the pause that would make me think it is xbmc or file caching related. Anyone feel free to correct my slightly wild guess.
Reply
Might just be the rendering of the font that takes a long time, if that's the case it should be offloaded to a different thread.
Reply
bobo1on1 Wrote:Might just be the rendering of the font that takes a long time, if that's the case it should be offloaded to a different thread.

But why only the first subtitle?
Reply
As far as I know every glyph of the font is rasterized and uploaded to a texture on the first subtitle, so that only has to be done once.
Reply
If changing the font fixes the issue, that would be awesome. Smile I will test it this weekend.
Reply
bobo1on1 Wrote:As far as I know every glyph of the font is rasterized and uploaded to a texture on the first subtitle, so that only has to be done once.

You mean uploaded into the graphics controller? If so that would confirm what I understood as the issue, as I believe I see some seemingly slow responding graphics controller hardware level comms (ioctl's) at the time of the issue. IF this is really the case I doubt there is any solution outside early preloading or separating this into another thread for the font in question.
Reply
a11599 Wrote:If changing the font fixes the issue, that would be awesome. Smile I will test it this weekend.

Well let me know which font to try and if not installed already the steps to take etc. My code tweaks show the stutter as video render drops without me having to watch the film.
Reply
TheSwissKnife Wrote:You mean uploaded into the graphics controller? If so that would confirm what I understood as the issue, as I believe I see some seemingly slow responding graphics controller hardware level comms (ioctl's) at the time of the issue. IF this is really the case I doubt there is any solution outside early preloading or separating this into another thread for the font in question.

No, I mean rasterized, as in render a vector font onto a raster.
The upload should be fast enough.
Reply
bobo1on1 Wrote:No, I mean rasterized, as in render a vector font onto a raster.
The upload should be fast enough.

Yes but is that done by CPU or GPU if using VDPAU/DXVA? I seem to see no CPU bottleneck at the time but some graphics controller ioctl's which take longer than usual - hence I have surmised some sort of upload even if it is not the data transfer itself which is slow). In other words how would it be made quicker by hardware alone - faster CPU of faster GPU?
Reply
ok, tested few 720p videos and as long as there are no italics or bold subtitles, there is no stutter with custom font anymore. But styled subs still occasionally stutter, but it's much better (shorter and not so often) than with default font. So this will do it for me for now.
Reply
TheSwissKnife Wrote:Yes but is that done by CPU or GPU if using VDPAU/DXVA? I seem to see no CPU bottleneck at the time but some graphics controller ioctl's which take longer than usual - hence I have surmised some sort of upload even if it is not the data transfer itself which is slow). In other words how would it be made quicker by hardware alone - faster CPU of faster GPU?

The rasterizing is done by the cpu, problem is if it's done in the render thread and it takes 500 ms, you won't get any rendering.

Can you provide some steps or a sample to reproduce this issue? I want to take a closer look.
Reply
bobo1on1 Wrote:The rasterizing is done by the cpu, problem is if it's done in the render thread and it takes 500 ms, you won't get any rendering.

Can you provide some steps or a sample to reproduce this issue? I want to take a closer look.

Maybe I missed the busy CPU then. Take any old mkv with a subtitle track included to reproduce - I am running at 1080p24. I can try to make a sample if required. If I disable the border font processing loop in RenderOutline() the problem seems to go way (and font still looks fine on screen), but I haven't thoroughly looked at it that is a complete resolution.
Reply
  • 1
  • 16
  • 17
  • 18(current)
  • 19
  • 20

Logout Mark Read Team Forum Stats Members Help
Jerky playback Dharma B2 and SVN /Ion0