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. |
2nd February 2007, 15:51 | #181 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
I'll upload latest build asap.
VP5/VP6 decoding seems to be broken in current SVN revision. Picture freezes at the beginning. Sample file. Edit: revision 865 broke it
__________________
MPC-HC 2.1.7.2 Last edited by clsid; 2nd February 2007 at 17:08. |
2nd February 2007, 17:11 | #182 | Link |
Curious BetaTester
Join Date: Oct 2005
Posts: 430
|
got error building rev866
make -C ffmpeg make[1]: Entering directory `/home/user/svn/ffdshow-tryout/trunk/src/ffmpeg' make[1]: *** No rule to make target `libavcodec/lzo.h', needed by `libavcodec/cscd.o'. Stop. make[1]: Leaving directory `/home/user/svn/ffdshow-tryout/trunk/src/ffmpeg' make: *** [FFMPEG] Error 2
__________________
Asrock N68-S AMD Athlon(tm) II X4 620 Processor (2.6GHz) - Crucial 2GB PC6400 800MHz DDR2 - Nvidia 9600GT Tools: ProcessExplorer & ProcessMonitor - BatchCompressor Guide: MinGW Compiling GCC |
2nd February 2007, 17:24 | #184 | Link |
Curious BetaTester
Join Date: Oct 2005
Posts: 430
|
i tried other day, still not compile ffdshow with gcc-4.2 or gcc-4.3 still patches needed i think
__________________
Asrock N68-S AMD Athlon(tm) II X4 620 Processor (2.6GHz) - Crucial 2GB PC6400 800MHz DDR2 - Nvidia 9600GT Tools: ProcessExplorer & ProcessMonitor - BatchCompressor Guide: MinGW Compiling GCC |
2nd February 2007, 18:50 | #186 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
@cc979, make clean and remove cscd.d
__________________
MPC-HC 2.1.7.2 |
3rd February 2007, 01:11 | #189 | Link | |
Registered User
Join Date: Feb 2006
Location: Japan
Posts: 1,560
|
Quote:
What kind of case do you assume? |
|
3rd February 2007, 01:15 | #190 | Link | |
Registered User
Join Date: Nov 2006
Posts: 799
|
Quote:
|
|
3rd February 2007, 11:05 | #191 | Link | |
Registered User
Join Date: Feb 2006
Location: Japan
Posts: 1,560
|
Quote:
// EDIT added at rev 870. Ideally the extensions in the dialog should be dragable so that user can drag and re-order. Considering the users who use this feature would be experts, the simplified dialog may be enough. Last edited by haruhiko_yamagata; 3rd February 2007 at 15:49. |
|
3rd February 2007, 16:13 | #192 | Link | ||
Registered User
Join Date: Nov 2006
Posts: 799
|
Quote:
Wow, this feature required more changes than I expected... I hope this feature is not just useful for me but for others as well! Quote:
Last edited by fastplayer; 3rd February 2007 at 16:17. |
||
3rd February 2007, 18:51 | #193 | Link | |
ffdshow/AviSynth wrangler
Join Date: Feb 2003
Location: Austria
Posts: 2,441
|
Quote:
Code:
Info() SelectEvery(30,0) AssumeFPS(1) Obviously AviSynth's seeking ahead does nothing - shouldn't the ffdshow source decode ahead 30 frames in that case? Referencing past frames (within limits) is handled by AviSynth's cache usually, but of course it can't look into the future... And as far TIVTC is concerned, TFM works of course, but TDecimate doesn't, for similar reasons. As for TIVTC producing load spikes for each cycle, like you said earlier - I rather doubt it. After all, it bases it's decisions on metrics calculated by comparing each frame with it's previous and next frame, for each frame in the cycle, which can be done as soon as each frame is coming in, which distributes the load nicely. At least I didn't get any weird CPU spikes when decoding a ripped VOB file and using the AviSynth filter with just TFM() followed by TDecimate() - CPU usage stayed somewhere between 20 and 30 % according to Task Manager. When figuring out which frame to drop, it just looks at the metrics that have been calculated for the past frame, which shouldn't be noticeable performance-wise. Of course, what you do need to do is decoding ahead 5 (or 10) frames before returning the first frame, then always buffering those frames and returning frames from that buffer - but that'd only give you a slight hiccup/load spike at the very beginning or after seeking (unless you ignore seeking and let TDecimate figure out what to do - shouldn't be treated much different than any other scene change), which shouldn't be too much of a problem. So here's my question - is it possible to request some frames ahead via DirectShow when ffdshow is not doing the decoding (dunno how the graph thing works exactly)? I guess it should at least be possible as soon as ffdshow itself is used as the decoder - but it's not done currently for AviSynth, as far as I can see... EDIT: Yeah, looking at the source for Tffdshow_source, the passed in frame number (n) isn't used, ever. np: Mira Calix - Belonging (No Longer Mix) (Eyes Set Against The Sun)
__________________
now playing: [artist] - [track] ([album]) Last edited by Leak; 3rd February 2007 at 19:21. |
|
3rd February 2007, 19:05 | #194 | Link |
Registered User
Join Date: Nov 2006
Posts: 799
|
Bug?
about rev870:
When setting the vertical subtitle position from 90% (default) to 95%, then only the first row of subtitles with 2+ lines is shown. In case of vobsubs, nothing is displayed. The only way to bypass this, is to reduce font size resp. the scale factor when dealing with vobsubs but this makes the subtitles harder to read... |
3rd February 2007, 22:58 | #196 | Link |
Otaku
Join Date: Sep 2006
Location: Portugal
Posts: 576
|
Build 875 and wmv3/9
I've been waiting for the wmv9 codec to be added as a decoding alternative to libavcodec. Thanks.
However after doing some tests I have registered the following cpu usage (dual-core cpu): Internal wmv9 decoder => 10 to 25% cpu usage (no artifacts). ffdshow libavcodec => 25 to 45% cpu usage (some artifacts like trails or something) ffdshow wmv9 => 20 to 35% cpu usage (no artifacts). Internal wmv9 + ffdshow raw processing => 20 to 35% cpu usage (no artifacts). Is there any special reason to ffdshow use more cpu? Details: Video: Windows Media Video 9 1280x720 29.97fps 3.8Mbit (VBR) Media Player Classic v6.4.9.0 v3.2+ (same settings for all codecs) CPU: Intel Pentium D 930@3.6ghz ffdshow build 875 with no extras like post-processing active. Kado |
5th February 2007, 13:04 | #197 | Link | |
Registered User
Join Date: Feb 2006
Location: Japan
Posts: 1,560
|
Quote:
fixed at rev 883. Some other bugs related to italic characters are fixed at the same time. |
|
5th February 2007, 14:09 | #199 | Link | |
Registered User
Join Date: Jun 2004
Posts: 577
|
Quote:
i have the same problem too, when the ffdshow source code was in my drive D:, mingw gcc was in C:, then i moved the ffdshow source code back to drive C: and the problem is gone |
|
5th February 2007, 14:40 | #200 | Link |
Registered User
Join Date: Oct 2002
Location: The Pandorica
Posts: 527
|
gcc4 isn't stable under mingw, that's why there are no builds using gcc4 in mingw.
__________________
PC specs for bug reports: Intel Core i7-4790K @4Ghz Win10(Linux VM) PCI express NVIDIA RTX 2060 SUPER graphics card http://twitter.com/cwebdesign |
Tags |
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl |
Thread Tools | Search this Thread |
Display Modes | |
|
|