Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
9th July 2011, 15:39 | #13782 | Link | |
Registered User
Join Date: Sep 2006
Posts: 3
|
Quote:
Every file that requires more than one cpu core to decode. Looks like threading problem. Quad-core cpu utilisation (same m2ts file): builds 3904-3925 - 25-30%, lags. build 3892 and earlier - 40%, no lags. Last edited by dwild; 9th July 2011 at 15:43. |
|
9th July 2011, 15:51 | #13783 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
I have a fast CPU. CPU usage is below 10% here when playing 1080p H.264 in TS. No lag at all.
Please point to a sample file I should test. Also try builds in between 3892 and 3904.
__________________
MPC-HC 2.1.7.2 |
9th July 2011, 16:09 | #13784 | Link | |
Registered User
Join Date: Sep 2006
Posts: 3
|
Quote:
From previous quote - that doesn't matter. It's every .m2ts file. Sorry, but I'm seeing only those two on your site, nothing in-between. |
|
9th July 2011, 16:17 | #13785 | Link |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
@clsid: any BD will do, however I sent you a 15s sample via pm (look at fps in MPC's Statistics pane)
p.s. also you should use a utility to slowdown speed of your CPU for testing purposes, or wait! there's a neat trick - rightclick a player process in Windows' TaskManager, select Affinity and set it to only 1 core. This way you'll be able to spot any problems at once. and btw, you're not using DXVA, are you? Last edited by wOxxOm; 9th July 2011 at 17:01. |
9th July 2011, 18:28 | #13786 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
BD playback is smooth here. Even with a single thread. No DXVA.
Here are two other builds: http://www.xvidvideo.ru/ffdshow-tryo...4-x86-x64.html http://www.xvidvideo.ru/ffdshow-tryo...7-x86-x64.html
__________________
MPC-HC 2.1.7.2 |
9th July 2011, 20:02 | #13788 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
I have to agree that there seems to be a performance regression or a synchronization regression around revision 3888 or so with H.264 that comes up mostly with blu-ray streams (mpeg-ts, splitter doesn't seem to matter). Haven't done specific testing, but when building things on the 26th of June trunk HEAD seemed to already have the regression, and revision 3887 seemed to be alright (the libavcodec multithreading used in both cases). This seems to have been reported at the Japanese 2ch board as well (example).
Other than with just plain eyes, the difference can be seen by looking at the green and red lines on MPC-HC's stats output. 3887 and before might have had some sudden rises in the synch difference or whatever it shows, but with a revision affected by this regression the rises would be MUCH bigger. As the effects of this regression are seemingly overall smaller with newer CPUs (I'm on a 2.26GHz Penryn C2D), I would guess that the difference would be visible via this kind of output in case of no visible stutter. Will try to build and test revision-by-revision later on. MSVS2010 SP1, GCC 4.5.3
__________________
[I'm human, no debug]
|
9th July 2011, 20:13 | #13789 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=...a6218a016a3af5
__________________
MPC-HC 2.1.7.2 |
9th July 2011, 21:09 | #13790 | Link | |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Quote:
Edit: the libavcodec/h264.c change, that is. Edit2: I take my words back, same problem came up with mplayer2, and reverting that commit fixed it in there. Uploading a sample for BBB now.
__________________
[I'm human, no debug]
Last edited by JEEB; 9th July 2011 at 21:44. |
|
10th July 2011, 04:56 | #13791 | Link | |
Registered User
Join Date: Sep 2006
Posts: 81
|
Quote:
I mentioned the similar problem at 25th June. (http://forum.doom9.org/showthread.ph...05#post1510105) |
|
10th July 2011, 18:10 | #13792 | Link | |
Registered User
Join Date: Apr 2008
Posts: 546
|
Quote:
By curiosity I would like to know. Moreover i don't know if anybody works on sub renderer (which is still buggued) today but this problem is not yet corrected https://sourceforge.net/tracker/inde...41&atid=867360 |
|
10th July 2011, 19:24 | #13793 | Link |
Registered User
Join Date: Nov 2008
Posts: 454
|
Too bad
But here is video what happening. Tested h.264 in mp4/m2ts/mkv container - all of them crash Graphstudio when deleting FFDshow DXVA decoder from graph. No problem with FFDshow video decoder - tested on xvid AVI.
__________________
Working machine: Win10x64 + Intel Skull Canyon My HTPC. How to start with Bitcoin |
10th July 2011, 19:45 | #13794 | Link | |
*****
Join Date: Feb 2005
Posts: 5,642
|
Quote:
The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.
__________________
MPC-HC 2.1.7.2 |
|
10th July 2011, 20:23 | #13795 | Link | |
Registered User
Join Date: Apr 2008
Posts: 546
|
Quote:
If you speak about ffdshow-mt, I never have bugs with ffdshow-mt since one or two year with blu-ray movies or anime in h264 (I stop at version 3614 (I only test briefly the next versions then I don't know if the next versions are buggued with ffdshow-mt). Last edited by ikarad; 10th July 2011 at 20:27. |
|
10th July 2011, 20:41 | #13796 | Link | |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Quote:
Code:
// packets can sometimes contain multiple PPS/SPS // e.g. two PAFF field pictures in one packet, or a demuxer which splits NALs strangely // if so, when frame threading we can't start the next thread until we've read all of them Now, of course I have no idea if this fix actually touches us, as in -- is it needed in our use case of ffdshow-tryouts (probably is), but BBB answered my calls right away, and I gave him out a ~420MB sample that might help him develop something that not only fixes the borked cases, but also does less damage towards decoding capabilities with frame-based multithreading (slice-based multithreading is unaffected, as is single-threaded decoding).
__________________
[I'm human, no debug]
|
|
10th July 2011, 21:09 | #13797 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
You can enable slice-based threading by modifying "ffcodecs.h". I did a quick test and it gives similar performance here for a BR sample. Slice was even marginally faster than frame-based. Can you test on your PC if slice-based balances the load better?
Using slice-based threading on streams without slices will of course give crappy performance, so if we would ever use it it must be done conditionally. Who is BBB btw?
__________________
MPC-HC 2.1.7.2 |
10th July 2011, 21:53 | #13798 | Link | ||
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Quote:
Quote:
__________________
[I'm human, no debug]
|
||
10th July 2011, 22:10 | #13799 | Link |
Registered User
Join Date: Apr 2008
Posts: 546
|
I don't know where I can post this thing but Ihave noticed that in the versions from xvidvideo.ru (icl12 and mvsc2010), deband filter doesn't work since several months. With versions from ffdshow site deband filter works well.
|
11th July 2011, 12:17 | #13800 | Link | |
Registered User
Join Date: Sep 2006
Posts: 212
|
Quote:
|
|
Tags |
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl |
Thread Tools | Search this Thread |
Display Modes | |
|
|