Closed GoogleCodeExporter closed 8 years ago
I cannot reproduce this on Win7 x64 or Win8 x64 with our latest XySubFilter GIT
& madVR 0.86.9.
Closing as invalid since we do not accept bug reports for non-official builds
of unknown origin. If this issue still occurs for you in an official release,
comment here and I'll reopen it.
Original comment by cyber.sp...@gmail.com
on 18 Jul 2013 at 3:32
Can't reproduce this one on my PC, either, using the latest XySubFilter build.
Original comment by mad...@gmail.com
on 18 Jul 2013 at 8:28
still happens on official 3.1.0.546 beta (madVr 0.86.9, mpc-hc 1.7.0.7634)
attached madVr crash report
Original comment by ZeRO9...@gmail.com
on 19 Jul 2013 at 3:07
Attachments:
Could you place create a new crash report with debug symbols?
Extract the attached pdb file in the same directory as XySubFilter.dll
Also since you are using LAV Filters, please extract these into the LAV Filters
0.58.1 directory:
http://files.1f0.de/lavf/LAVFilters-0.58.1-symbols.zip
I've also noticed you are using an unofficial version of xy-VSFilter 3.0.0.486
(VSFilter.dll). Please remove it, and see if you can still reproduce the crash.
I also see mpc-hc-gf.exe, what is that? If that is a custom version of MPC-HC
please test with an official build from http://mpc-hc.org/ or official nightly
from http://nightly.mpc-hc.org/
Original comment by cyber.sp...@gmail.com
on 19 Jul 2013 at 5:56
Attachments:
xy-vsfilter was blocked in mpc-hc during those tests. unregistered it and
removed the dll, but crashes still persist.
attached crash Report with debug symbols
Original comment by ZeRO9...@gmail.com
on 19 Jul 2013 at 7:10
Attachments:
ah, forgot about the mpc-hc-gf.exe thing. it's an official nightly but renamed,
because Nvidia Optimus drivers are hardcoded to force usage of the iGPU (rather
than the GT540M) for mpc-hc.exe
Original comment by ZeRO9...@gmail.com
on 19 Jul 2013 at 7:13
I happen to encounter this crash also.
For me this crash only occurs at certain window sizes.
For example in MPC-HC open the monogatari file and immediately pres decrease
size (Numpad 1) 4 times. This causes the crash for me 100% of the time at the
5sec mark.
Original comment by lpsh...@gmail.com
on 19 Jul 2013 at 7:48
[deleted comment]
Thanks lpsh.m, I was able to reproduce the crash following those steps.
Original comment by cyber.sp...@gmail.com
on 19 Jul 2013 at 7:59
Original comment by cyber.sp...@gmail.com
on 19 Jul 2013 at 8:37
This looks like a bug in XySubFilter. According to my log "GetBitmap()" returns
the following values:
pitch: 4732, pixels: 00B5D3C8, size.cx: 722, size.cy: 666
So if you do the math, the pixels buffer should reach from 00B6D3C8 up to
00E5EA60. But according to the crash report, the crash occurs when trying to
read 00E5E000. So either the pitch/size is reported incorrectly, or the buffer
isn't allocated large enough.
FWIW, when not scaling the video, I'm getting this instead:
pitch: 5120, pixels: 1CBD3418, size.cx: 780, size.cy: 720
And that works without any problems.
BTW, I'm wondering why the size.cy is so big? It's not as big for the other
subtitles in the same sample. Why does XySubFilter sends such a large image to
madVR? Does XySubFilter currently enforce "combineBitmaps"??
Original comment by mad...@gmail.com
on 20 Jul 2013 at 11:48
[deleted comment]
> I'm wondering why the size.cy is so big?
> It's not as big for the other subtitles in the same sample.
In this case "size.cx: 780, size.cy: 720" is the monogatari sample is the
actual size of the "clock", but areas outsize the frame are
clipped/transparent. See attached.
> Does XySubFilter currently enforce "combineBitmaps"??
Yes and no. We do not enforce combinesBitmaps to combine everything to a single
bitmap unless the consumer requests it (as defined by the subtitle interface).
But do combine bitmaps after a certain threshold of proximity as well as a hard
limit on maximum number of bitmaps.
The combining bitmaps function does seem to be the cause of these crashes.
___________________
Workaround:
Run the attached "max_bitmap_count_16.reg", which should workaround the crash
on three provided samples.
This value could be increase higher if anyone finds other samples which crash
XySubFilter Beta under these conditions. We don't recommend setting it insanely
high though, as that will likely hurt performance. Eventually during beta we
are going to need to do some performance tests to find the optimal value to use
as a threshold for combining bitmaps. In Beta it currently defaults to
MAX_BITMAP_COUNT=8.
Original comment by cyber.sp...@gmail.com
on 20 Jul 2013 at 11:20
Attachments:
This has been fixed for the XySubFilter next release.
Original comment by cyber.sp...@gmail.com
on 22 Jul 2013 at 2:18
https://github.com/Cyberbeing/xy-VSFilter/commit/7b374700059022465ce8cfb17ae3292
b6be5f6ec
Original comment by cyber.sp...@gmail.com
on 22 Jul 2013 at 2:20
Issue 180 has been merged into this issue.
Original comment by cyber.sp...@gmail.com
on 2 Mar 2014 at 10:17
Fixed in XySubFilter Beta2
Original comment by cyber.sp...@gmail.com
on 8 Apr 2014 at 12:50
Original issue reported on code.google.com by
ZeRO9...@gmail.com
on 18 Jul 2013 at 1:16