Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[codpiece]

I've been wondering for awhile why are subtitles slower to appear onscreen when using ROHQ vs RO standard for blu-ray folder rips. 

It's forced me to use Custom video settings and choose EVR for bdmv files.

I realize I can adjust the subtitle timing but this is not a great solution for when I'm watching something I've never seen before and didn't know had subtitles (forced or otherwise).  Nothing worse than interrupting a movie to fidget with a setting. 

Just curious why this might be.

I'm running HD4000 i3-3225.

[Symus35]

Hello,

Same issue here.

Running RO HQ with madvr, i always have a small delay with the subtitles.

Everytime i start watching a movie, i set a delay of +400 , and then subtitles are perfectly synchronized , regardless of the subtitle stream i chose. Thats a nice solution, to a weird problem indeed.

Athlon II X4 620
Gt430 Nvidia

[Hendrik]

I think i saw this too. PGS subtitles from Blu-rays or also in a MKV seem to show up a tad bit too late. I didn't do a comparison to RO Standard, but noticed it with ROHQ in comparison to MPC-HC.

[codpiece]

Yeah, I typically have to set the timing anywhere from -500 ms to -1000 ms.  

If it doesn't happen in MPC with madvr, then something's going on in ROHQ.

[6233638]

I can confirm this. Whether using the ROHQ preset, or using Custom to set it up exactly the same as MPC-HC.

Two hours into a two and a half hour film (The Girl with the Dragon Tattoo Blu-ray) people are finishing their sentences before the subtitles even appear.

Using the same filters in MPC-HC, subtitles work as expected.

[codpiece]

Any ideas what the problem may be?

[Matt]

We assume that the madVR interface IMadVROsdServices will show an image (subtitle in this case) right away when we provide it, but there must be a delay.

I wonder if madVR could report this latency somehow so we could adjust for it?

[Hendrik]

It probably depends on the number of frames in the various queues, so i guess madVR could potentially give you that info (depending which queues exactly count), but i wonder if it wouldn't be easier to render subtitles using a more subtitle specific interface in madVR, which gives you full timing control?

Specifically i'm talking about http://madshi.net/SubRenderIntf.h
It will cost some dev effort to interface with it, but it will give you full flexibility.

Since your subtitle renderer is completely internal to MC18, you can skip a lot of parts about loading and whatnot, and go directly to the implementation.

[Matt]

It probably depends on the number of frames in the various queues, so i guess madVR could potentially give you that info (depending which queues exactly count), but i wonder if it wouldn't be easier to render subtitles using a more subtitle specific interface in madVR, which gives you full timing control?

Specifically i'm talking about http://madshi.net/SubRenderIntf.h
It will cost some dev effort to interface with it, but it will give you full flexibility.

Since your subtitle renderer is completely internal to MC18, you can skip a lot of parts about loading and whatnot, and go directly to the implementation.

I talked to madshi about that interface when he added it, but it wasn't clear that it would be better than what we already do.  Our subtitle engine renders all subtitles to a single graphical buffer, and we just need an easy way to have the renderer show this buffer.

Currently we use IMadVROsdServices which is designed to show graphical overlays.  We share the overlay code between the OSD and subtitles.

So the easiest change for us would be if madVR could report the latency of IMadVROsdServices, and we could just adjust for this.

I'll send madshi this thread to see what he thinks.

[madshi]

madVR does show the OSD bitmaps "immediately", but that only means they're shown for the next frame that is getting rendered/presented. If you have e.g. a 12 frame presentation queue in madVR FSE which is nicely "full" all the time, with Blu-Ray playback there is practically a latency of 12 video frames until the OSD images make it to the screen. This is the price to pay for pre-presenting so many frames in advance. The simple problem with D3D FSE presentation is that you can't "take back" any frames which were already delivered to D3D. The only way to solve this would be to lower the number of pre-presented frames to make OSD changes react quicker. So basically there's no good solution to make OSD react quicker.

For subtitles you could simply modify the subtitle timestamps to account for the latency. However, the latency can vary depending on the fill state of the queues. E.g. if the queues are nearly empty, latency is very low, but if the queues are large and full, latency is high. madVR could report the fill state of the queues. But I have to say modifying the subtitle timestamps according to the fill state of the madVR queues doesn't "feel good" to me. But it would be possible and would probably work ok. I would expect timings to not be perfectly exact this way, though. Errors of 1-2 video frames could still occur because in the moment when you ask the fill state of the queues this information could already be outdated again.

Of course the ideal solution would be to use the new interface which allows you to sign each subtitle image with the correct timestamp. That way no timestamp manipulation would be needed at all and madVR would internally take care of everything, resulting in "perfect" sync. But I do understand that switching the interfaces would cost development work and come with the risk of running into new bugs. After all the new subtitle interface in madVR is not well tested yet.

[Hendrik]

1-2 frames timing difference would be fine for me, but 12 frames at 24p is already half a second, and that is quite noticeable.
Of course the people watching Anime with perfectly timed ASS might think otherwise, but luckily i'm not one of them. :p

[jmone]

I'm sure Matt would want to do it the "right way"

[Matt]

madshi, would you be willing to report a latency in milliseconds in the IMadVROsdServices interface?  I think something similar to this is available with the on screen statistics, so I'm hoping it would be an easy thing to try.

Even if we were off by a frame or two, it would be much better than what we have today.

It's sort of a big project for us to revise our render pipeline to deliver subtitles early with a timestamp.  I'm not opposed to doing this someday, but I'm looking for an easier way out for now.

Thanks for your consideration.

[madshi]

Sure, I'll put it on my to do list. Will notify you when it's implemented. It will not always be perfectly accurate, but it should provide a useful approximation.

[Matt]

Thanks.  I appreciate it.

[icstm]

sorry to awaken a dead post, but where did we get to with this?
It all sounded rather promising.

[Matt]

I believe madshi plans to add latency reporting to the next version of madVR (maybe in IMadVROsdServices), although last I heard he was pretty busy.

[madshi]

Correct, this is still planned for the next madVR build. And no, I don't have an ETA.

[madshi]

The latest madVR v0.86.2 now contains the requested information:

Code: [Select]

int osdLatencyInMilliseconds = 0;
IMadVRInfo::GetInt("osdLatency", &osdLatencyInMilliseconds);
More information in "mvrInterfaces.h", as usual.

If there's more/other information you'd like to get from madVR, just let me know and I'll add it to the IMadVRInfo interface.

P.S: The IMadVRRefreshRateInfo (which you're using) and IMadVRExclusiveModeInfo (not sure if you're using that) interfaces are now obsolete, but still working. The same information can now be retrieved via IMadVRInfo. E.g. you can do "IMadVRInfo::GetDouble("refreshRate", &refreshRate)".

[Matt]

Next build:
Changed: Updated to madVR v0.86 (thanks madshi).
Changed: Subtitles account for the madVR presentation latency by using the new IMadVRInfo interface.

Thanks!

[Hendrik]

Neat, thanks for the quick fix after the madVR update.

[6233638]

Excellent, thanks.

[icstm]

Surely I cannot be the only one who thinks it cool that madshi updates his API and JRiver rewrites its code to use the new API structure as well as make use of new calls within that structure!
Even better is that madshi updates us personally here so we all know what he has told Jim and gang! 

[CountryBumkin]

Surely I cannot be the only one who thinks it cool that madshi updates his API and JRiver rewrites its code to use the new API structure as well as make use of new calls within that structure!
Even better is that madshi updates us personally here so we all know what he has told Jim and gang! 

Yes, its a great team. JRiver + madshi + nevcairiel. We sure do benefit a lot from these guys. There used to be a way to show some appreciation to madshi and nevcairiel in the way of a modest cash donation. I don't see a link anymore on either of the doom forums. How is this done these days?

[6233638]

I agree, it's great that we have Nevcariel and Madshi working closely with the JRiver team.
I don't know about Nevcariel, but Madshi has said that he doesn't want to accept money at least until madVR hits 1.0

[codpiece]

woohoo!