Blu-ray subtitle timing / rendering problems with TrueHD Audio

[GoogleCodeExporter]

Subtitle timing problems:

There seems to be a timing problem with certain PGS subtitles, in the sample 
clip some of the ending songs subtitles show up late when played using the 
Dolby TrueHD audio tracks (eng or jpn). When using the core 5.1 AC3 audio track 
(sub), eng or jpn the subtitles are displayed without being delayed.

When using FFDShow as the subtitle renderer there are no timing problems, 
subtitles are shown on time using any audio track during playback (TrueHD or 
AC3). 

Dirty looking subtitles:

The subtitle "Anyway, the bandage came off" at 00.07 for some reason is not as 
clean looking as the rest of the subtitles.

Tested using Win7 Pro 64 bit, Zoom Player 810build012, LAV Splitter / Video / 
Audio 0.43 (bitstreaming), xy_VSFilter_stable_20111226 and EVR renderer.

Zoom Player
http://forum.doom9.org/showthread.php?t=163460

Separate subtitle files
http://www.zshare.net/download/980050500f8d7fee/

Sample, taken from FLCL episode1 (Fooly Cooly) Blu-ray Disc

Use to merge the file parts
http://www.zshare.net/download/97999382ff98be22/

Part-1
http://www.zshare.net/download/98000435c1eefb27/

Part-2
http://www.zshare.net/download/98001329da153f9e/

Part-3
http://www.zshare.net/download/98002034b465769d/

Part-4 
http://www.zshare.net/download/9800331864b39b43/

Original issue reported on code.google.com by s_irela...@optusnet.com.au on 29 Dec 2011 at 4:55

[GoogleCodeExporter]

All these issues exist in VSFilter 2.40 as well. Why is this bad? xy-VSFilter 
PGS code is copied from VSFilter 2.40, and the developer here @ xy-VSFilter 
doesn't known anything about PGS subtitles so it's unlikely we would be able to 
fix any bugs in the PGS parser.

I found this on the LAV Filters issue tracker:
http://code.google.com/p/lavfilters/issues/detail?id=128

The subtitle sync issue sounds like it's a unique problem with TRUEHD tracks 
not allowing enough time for processing subtitles. nevcairiel increased the 
audio buffer and marked the issue 'fixed', but maybe it needs to be increased 
even further to work properly with PGS subtitles rendered by VSFilter? 

I'd recommended opening a new issue with LAV Filters @ GoogleCode:
http://code.google.com/p/lavfilters/issues/entry

And also MPC-HC projects issue tracker (since this happens with both VSFilter 
2.40 & the MPC-HC TS Splitter, but not the internal MPC-HC subtitle filter for 
whatever reason):
http://sourceforge.net/apps/trac/mpc-hc/newticket

As for the "Anyway, the bandage came off" quality issue, that may be fixable by 
us. It only happens with the original M2TS, but not when muxed into MKV. It 
also doesn't seems to happen when pre-buffering is enabled in VSFilter 2.40, 
but happens when pre-buffering is disabled. We saw and fixed a similar quality 
problem that affected all PGS subtitles in our initial test builds using 
VSFilter's 2.40 PGS code, though it's odd it only happens with the one line.

Original comment by cyber.sp...@gmail.com on 29 Dec 2011 at 10:34

[GoogleCodeExporter]

The timing problem is there when using FFDShow audio (TrueHD) and xy-VSFilter 
as well, it only seems to happen with the intro / ending song subtitles (not 
sure what is different about those subs) the rest of the video is fine.

I don't think it's a LAV problem, FFDShow's subtitle renderer has no timing 
problems using LAV or FFDShow's audio decoder (TrueHD or AC3).

Would it be possible to use another projects code to parse PGS subtitles, 
FFDShow or FFMpeg's?

I played the disc again and there are some other subs that have a similar dirty 
look (not many), just caught that line by accident when making the clip.

Original comment by s_irela...@optusnet.com.au on 29 Dec 2011 at 1:17

[GoogleCodeExporter]

The audio or video decoder used is irrelevant. This would be a splitter 
compatibility issue with VSFilter if anything.

Yet, the question isn't who's problem it is, but rather who is capable of 
actually fixing it. If nobody is capable of fixing it in VSFilter, the hope is 
that LAV Splitter or similar could add special VSFilter handling when TrueHD 
audio is used.

I'd highly recommend you report this issue @ 
http://code.google.com/p/lavfilters/issues/entry to see if nevcairiel can 
workaround the problem in LAV Splitter.

By the same measure by reporting it to the MPC-HC team @ 
http://sourceforge.net/apps/trac/mpc-hc/newticket there is a chance they may 
have someone knowledgeable enough to fix it in either VSFilter 2.40 or their 
own splitter.

> Would it be possible to use another projects code 
> to parse PGS subtitles, FFDShow or FFMpeg's?

If VSFilter 2.40's PGS code has too many issues, we've already considered the 
possibility of using something FFDShow/FFMPEG based, but we've yet to look into 
how feasible porting such code to VSFilter would be. At present we are content 
that VSFilter's PGS code is working just as well in xy-VSFilter as it does in 
VSFilter 2.40. 

Without a developer knowledgeable about Blu-ray subtitles, chances are slim we 
would be able to fix anything but regressions in the PGS parser. It would take 
some insane luck, but if this issue turns out to have nothing to do with the 
PGS parser, it may actually be fixable by the xy-VSFilter dev. I wouldn't get 
your hopes up though.

Original comment by cyber.sp...@gmail.com on 29 Dec 2011 at 2:42

[GoogleCodeExporter]

Original comment by cyber.sp...@gmail.com on 29 Dec 2011 at 3:07

• Changed title: Blu-ray subtitle timing / rendering problems with TrueHD Audio

[GoogleCodeExporter]

Can anybody confirm if this is still an issue or not?

Original comment by cyber.sp...@gmail.com on 22 Jul 2013 at 2:33

[GoogleCodeExporter]

I just tested this and the problem is fixed when using the latest LAV Filters 
0.58.1 / MPC-HC nightly builds.

Original comment by s_irela...@optusnet.com.au on 26 Jul 2013 at 9:37

[GoogleCodeExporter]

Thank you, that's good to hear.

I can only assume that FFMPEG must have tweaked how the subtitle demuxing was 
handled with the tiny packet size of TrueHD audio at some point. In addition to 
LAV Filters, this issue doesn't seem to occur any longer with the MPC-BE 
internal filters either.

Original comment by cyber.sp...@gmail.com on 26 Jul 2013 at 11:56

• Changed state: Verified

[GoogleCodeExporter]

Re-opening this issue, as MPC-HC recently fixed a couple remaining problems on 
Ticket #3691 which we'll need to merge: https://trac.mpc-hc.org/ticket/3691

I've attached a Test build with the recent MPC-HC PGS timing fixes and VOBSUB 
animation support. Also includes the temporary crash fix from Issue #181, and 
the fix for Issue #174.

s_irelands, please check the behavior of this XySubFilter Test build against 
MPC-HC nightly 1.7.3.219+ and report back.

Original comment by cyber.sp...@gmail.com on 13 Apr 2014 at 11:48

• Changed state: Started

Attachments:

• XySubFilter_TestBuild(PGS_VOBSUB_Timing_Fixes).7z

[GoogleCodeExporter]

Thanks for the new build. 

The VOBSUB fix is working fine but there is a problem with PGS subtitles, when 
seeking forward the last buffered subtitles flash on the screen until you 
resume normal playback. 

No problems with MPC-HC nightly 1.7.3.219, this was one of the last problems 
fixed by Underground78. Double check and make sure to include all of 
Underground78's recent changes.

I think these were the last fixes made:

Subtitle queue: Ensure the queue is invalidated after seeking.
https://github.com/mpc-hc/mpc-hc/commit/69a89bd59a4b5ee4bba7482e669f6ccad8ab9159

Subtitle queue: Check the invalidation time against the segment end time.
https://github.com/mpc-hc/mpc-hc/commit/5312675193f4e4965c70f70c2ed12de77fb3e26e

PGS Subtitles: Ensure the bounding box is correct when the subtitle isn't 
rendered.
https://github.com/mpc-hc/mpc-hc/commit/b4402fb2acf85c36bbd256fff7bc242d2dda2d0d

PGS Subtitles: Correctly reset the parser after seeking.
https://github.com/mpc-hc/mpc-hc/commit/701ba7ea4ffc9c7a09b4594f6a4f54be87dcd03d

Thanks. 

Original comment by s_irela...@optusnet.com.au on 13 Apr 2014 at 3:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the feedback s_irelands.

> when seeking forward the last buffered subtitles flash 
> on the screen until you resume normal playback

Is this a new issue with only this test build, or does this also occur in Beta 
2?
Do you have a sample? I'm not seeing the issue from quick testing.

What I merged in so far were the following commits only:

Fix: PGS subtitle timings were sometimes wrong.
https://github.com/mpc-hc/mpc-hc/commit/d8deeda49e270d02e9eae795265494184f409b29

PGS Subtitles: Fix subtitles not being removed from screen after d8deeda
https://github.com/mpc-hc/mpc-hc/commit/8a25a55f2362ae65ebfc9c3d16474c20a5fb0291

PGS Subtitles: Correctly reset the parser after seeking.
https://github.com/mpc-hc/mpc-hc/commit/701ba7ea4ffc9c7a09b4594f6a4f54be87dcd03d

Vobsub: Avoid parsing the complete subtitle entry when possible.
https://github.com/mpc-hc/mpc-hc/commit/96754dc280b697cdab314ff4b078b3264294b142

Vobsub: Support animated subtitles (with fade in/out).
https://github.com/mpc-hc/mpc-hc/commit/ec3fd94af5a6b9a666ab2bc0f7dafb3c2ac2f4ae

We already had our own fixes the following issues prior to MPC-HC's commits, so 
they were non-applicable:

PGS Subtitles: Ensure the bounding box is correct when the subtitle isn't 
rendered.
https://github.com/mpc-hc/mpc-hc/commit/b4402fb2acf85c36bbd256fff7bc242d2dda2d0d

DVB and PGS subtitles: Subtitles were sometimes one frame late.
https://github.com/mpc-hc/mpc-hc/commit/e8d8fc95f0fedf65d6401b2c27f2c22e49448f01

I did not yet merge in the follow because of code differences (functions being 
changed did not exist in our code):

Subtitle queue: Ensure the queue is invalidated after seeking.
https://github.com/mpc-hc/mpc-hc/commit/69a89bd59a4b5ee4bba7482e669f6ccad8ab9159

Subtitle queue: Check the invalidation time against the segment end time.
https://github.com/mpc-hc/mpc-hc/commit/5312675193f4e4965c70f70c2ed12de77fb3e26e

PGS subtitles: Update RemoveOldSegments to account for unknown end time.
https://github.com/mpc-hc/mpc-hc/commit/c66f112f046fef01cbf58fbde2c2af87452589ff

Original comment by cyber.sp...@gmail.com on 14 Apr 2014 at 2:48

[GoogleCodeExporter]

Hmm, well I'm still seeing a timing issue one of the samples you posted:

http://www.mediafire.com/download/b8q0aks8s3uka5i/bds2.zip

Unfortunately, we had to rush out Beta 2 before we had a chance to review and 
merge any relevant MPC-HC subtitles code changes. It looks like our developer 
will need to do some more significant updates of the PGS code, so everything in 
sync with MPC-HC. I'll keep this in mind as something we'll need to resolve 
before we release Beta 3.

Original comment by cyber.sp...@gmail.com on 14 Apr 2014 at 3:40

[GoogleCodeExporter]

"Hmm, well I'm still seeing a timing issue one of the samples you posted:"

http://www.mediafire.com/download/b8q0aks8s3uka5i/bds2.zip

Yeah I tested that sample again with EVR-CP and had problems with it. I tried 
madVR and there were no problems, switched back to EVR-CP and it played back 
fine after that.

The flashing subtitles problem when seeking only happens with Zoom Player, it 
also happens with beta 2, seems like an existing problem not caused by updates 
to the test build.

Disable Smart Play and disable the MS Audio and Video Decoders using 
Win7DSFilter Tweaker.
http://www.codecguide.com/windows7_preferred_filter_tweaker.htm 

Tested with madVR 0.87.9 an LAV Filters 0.61.2

Here is a sample, open from 00010.mpls.
https://www.dropbox.com/s/xe7wb13rky50egu/test2.zip

Thanks.

Original comment by s_irela...@optusnet.com.au on 14 Apr 2014 at 6:21

[GoogleCodeExporter]

Tested the bds2.zip sample which had the PGS delay @00:40 a bit more, and the 
issue only seems to occur if I enable the PGS subtitle track a few seconds 
after playback has started. If I stop playback first, enable PGS subtitle 
track, and only then begin playback, there is no delay.

PGS subtitles: Update RemoveOldSegments to account for unknown end time.
https://github.com/mpc-hc/mpc-hc/commit/c66f112f046fef01cbf58fbde2c2af87452589ff

PGS and DVB subtitles: Fix missing subtitles after resizing the window.
https://github.com/mpc-hc/mpc-hc/commit/885c54a405e70ef8250e2f209edfb958adff8c45

I merged in the above two commits, but it didn't make any difference.

I've also noticed that those commits do not fix the problem in xy-VSFilter at 
all, only XySubFilter. So it would seem the remaining issues likely reside in 
code specific to our project.

> The flashing subtitles problem when seeking only happens with Zoom Player

I still cannot seem to reproduce this, though this sounds like something which 
could be a madVR bug. Did you have ZoomPlayer (Playback -> Video) forcibly 
enabling/disabling madVR SmoothMotion? Are the filters being used in ZoomPlayer 
the same as other media players?

Original comment by cyber.sp...@gmail.com on 14 Apr 2014 at 11:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I tested using Windows 7 Pro x64, Zoom Player v9.0 MAX, LAV Filters 0.61.2 and 
madVR 0.87.9.

I only use LAV Filters and madVR / EVR for playback, here are the Video / 
Subtitle settings I use in Zoom Player.

Video:
http://www.mediafire.com/view/7xp877ptpznifub/Video.JPG
Subtitles:
http://www.mediafire.com/view/vqe3bz4fl09co86/Subtitles.JPG

Zoom Player is setup to use the default madVR settings for SmoothMotion, only 
to be used if there would be judder without it. I use 1920*1080@120Hz so 
SmoothMotion only activates for 25/50 FPS video.

To reproduce the problem use the test2.zip sample, open 00010.mpls and when the 
subtitles are displayed Fast Foward (press the f key), let it play and you 
should see the subtitles flash on and off while seeking.

It happens using Software or Hardware decoding and in both Windowed and FSE 
mode.

I tried the VSFilter.dll from the latest nightly standalone filters 
1.73.226.x86 and there were no problems when using it.

Thanks. 

Original comment by s_irela...@optusnet.com.au on 14 Apr 2014 at 3:39

[GoogleCodeExporter]

> subtitles are displayed Fast Forward (press the f key),
> let it play and you should see the subtitles flash on and off while seeking.

Ah, didn't realize you meant fast forwarding.

From what I see in Zoomplayer 9 fast forward (x8) test2.zip PGS subtitles:

MPC-HC VSFilter 1.73.226: Displays some lines
xy-VSFilter 3.0.0.211: Displays nearly all lines

XySubFilter Beta2: Stuck displaying an old line after a couple seconds (flashes)

While in MPC-HC fast forward (x8) test2.zip PGS subtitles:

MPC-HC VSFilter 1.73.226: Displays nearly all lines
XySubFilter (any version): Displays nearly all lines

xy-VSFilter 3.0.0.211: Does not display any lines

Zoom Player appears to have designed their fast forward method specifically for 
xy-VSFilter compatibility. VSFilter has always had quirks regarding fast 
forwarding, but we'll look into improving upon this.

Original comment by cyber.sp...@gmail.com on 15 Apr 2014 at 12:23

[GoogleCodeExporter]

"Zoom Player appears to have designed their fast forward method specifically 
for xy-VSFilter compatibility. VSFilter has always had quirks regarding fast 
forwarding"

Thanks I didn't know that, I'm a bit confused now, I thought it was normal for 
subtitles to not be displayed when using FF / RW during playback.

Both MPC-HC and Zoom Player don't display subtitles while using FF / RW during 
DVD playback so I just assumed that it was the standard behaviour to not 
display subtitles when seeking.

Out of curiosity I put a disc into a Panasonic DVD Player that hardly ever gets 
used and at 2x FF subtitles were displayed but at 4x and above they were not.

Is it up to the Player / Subtitle renderer to control? Like MPC-HC does, 
subtitles are displayed when seeking.

Thanks.    

Original comment by s_irela...@optusnet.com.au on 15 Apr 2014 at 7:07

[GoogleCodeExporter]

> I thought it was normal for subtitles to not be displayed 
> when using FF / RW during playback.

If subtitles are enabled, nominally they should be displayed. How well it 
functions, depends on how aggressive the subtitle renderer invalidates and 
drops frames, and how well the splitter sends subtitle packets in such a 
situation. They usually start to disappear when rendering is slower than the 
fast forward playback speed. If you never see subtitles when fast forwarding, 
it probably has to do with CPU speed.

ZoomPlayer fast forward appears to function by constantly seeking in large 
frames step multiples at original playback rate.

MPC-HC fast forward functions by increasing the playback rate (i.e. 8x 
23.976fps = 191.808 fps).

The issue with ZoomPlayer fast forwarding PGS subtitles with XySubFilter is 
definitely a bug though. The remaining bugs we're seeing with PGS all appear to 
be seeking related as well. Aside from observations about the bds2 sample I 
made in Comment #14, we also have had a know issue with seeking external PGS 
subtitles ever since we added such support in XySubFilter Beta 1 from MPC-BE.

Original comment by cyber.sp...@gmail.com on 15 Apr 2014 at 12:25

[GoogleCodeExporter]

Thanks for taking the time to explain, that cleared things up.

Cheers.     

Original comment by s_irela...@optusnet.com.au on 15 Apr 2014 at 2:44