New ffdshow build (?) [Archive] - Page 11

bob0r

8th November 2005, 19:00

16:55 on Nov 08, 2005
updated libavcodec
http://cia.navi.cx/stats/project/ffdshow/.message/6335701

I see what files are updated, but i dont see what what exactly in libavcodec is updated. Is there anyway to see a CURRENT CVS changelog via cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ffmpeg co -P modulename ?

also:

17:24 on Nov 08, 2005
autoupdate version for GCC builds
http://cia.navi.cx/stats/project/ffdshow/.message/6336306

What is that support to mean, autoupdate??

marcellus

8th November 2005, 19:31

Kurosu

8th November 2005, 20:13

16:55 on Nov 08, 2005
updated libavcodec
http://cia.navi.cx/stats/project/ffdshow/.message/6335701
I see what files are updated, but i dont see what what exactly in libavcodec is updated. Is there anyway to see a CURRENT CVS changelog
cvs -H log to see how to check the unreadable log.
Or alternatively, use something like cvs2cl.pl with perl installed somewhere.

autoupdate version for GCC builds
[...]
What is that support to mean, autoupdate??
If you check the Makefile, you see that now bin/verinc.exe gets build with gcc. This updates src/version.ver which gets included by src/version.h
This allows updating the ffdshow version displayed in the About part of the ffdshow dialog window.

bob0r

8th November 2005, 20:38

...

If you check the Makefile, you see that now bin/verinc.exe gets build with gcc. This updates src/version.ver which gets included by src/version.h
This allows updating the ffdshow version displayed in the About part of the ffdshow dialog window.

You mean this?
http://mirror05.x264.nl/public/ffdshow_version.jpg

It already updates on a new compile?

Edit:
Quote by Milan:

It was enabled for VS builds only.There is pre-link action
which increases version stored in src/version.ver and I tried to
add similar behavior to makefile too.

https://sourceforge.net/tracker/index.php?func=detail&aid=1351583&group_id=53761&atid=471490

It already did this, thats why i was confused, thanks.

Edit2:
Quote by Milan:

It's about different version number: the one stored in dll file
which isn't displayed anywhere in ffdshow, but can be used,
for example, by installers to compare file versions.

Its all clear now.

Lemonzest

8th November 2005, 22:27

any chance of a regular SSE2 GCC build? it works great on my Athlon64

Rash

9th November 2005, 01:31

Whoosh! It's hard to keep up! It seems the ffdshow development is in its full force right now. :D And for that I only came here to express my real gratitude to the developers. Thank you very much guys.

And not just ffdshow, of course. Doom9 and MeGUI, the x264, MPC amongst many others. You guys rule it!

Czarek Kwasny

9th November 2005, 07:08

i hope i won't be ignored. If it's wrong place for posting please correct me.
I tried playback of HDTV content via MPlayer and after some optimizations it plays fine. I find FFDShow much more versatile thus I'd like to switch to it. The problem remains in performance. If I playback files in MPlayer with parameters: -vfm ffmpeg -lavdopts lowres=0:fast:skiploopfilter=all I get very good performance. Is it possible to implement or somehow turn on such optimization for FFDShow?

videomixer9

9th November 2005, 12:53

skiploopfilter ... isn't that turning of all h264 deblocking ... you can select in ffdshow to skip deblocking and increase h264 playback performance. You find that option in the codec selection page, select h264 in the list and two checkboxes appear, check "skip deblocking always" there. However the video may now suffer from macroblocking, especially if it's encoded with x264. dshow doesn't like to drop frames very much and pretty many players don't offer to drop frames, cannot help on that trick mplayer usually does when it starts lagging. If you're talking about usual MPEG4 or MPEG2 HDTV content I wouldn't know much of a way to speed up decoding. However if your PC is too slow, don't use VMR9 for playback, VMR is a total CPU muncher. mplayer pretty much offers the same things as ffdshow, it also comes with many filters you can use via -vf but which are almost all not documented well. The drawback is the crappy DVD menu support and the crappy subtitle renderer.

Egh

9th November 2005, 13:22

skiploopfilter ... isn't that turning of all h264 deblocking ... you can select in ffdshow to skip deblocking and increase h264 playback performance. You find that option in the codec selection page, select h264 in the list and two checkboxes appear, check "skip deblocking always" there. However the video may now suffer from macroblocking, especially if it's encoded with x264.

Well, depends on the bitrate of the video and [de]blocking filter settings used. As a rule of thumb, the higher is bitrate for same frame size, the less is impact on macroblocking. With something like 1600kbps bitrate it's safe to turn of blocking inloop filter completely.

Also there's an option "skip when safe". It uses a bit more resources than skipping always, but doesn't produce any artefacts.

Czarek Kwasny

9th November 2005, 13:53

Thank you very much for the inforamation!
"skip deblocking always" works just great! I tried Skip when safe but i got a little jerky playback so decided to stay with "always". Now I get the mplayer's performance with support for subtitles, and AAC 5.1 sound :). Makes me happy. I had troubles with setting up mplayer for QuickTime HD trailers (H.264 + 5.1 LC-AAC), this seems to be the problem no more... I also switched from VMR to Overlay Mixer in MPC setup to speedup the performance.

bob0r

9th November 2005, 17:24

http://cia.navi.cx/stats/project/ffdshow

ffdshow-20051109.exe online (see signature)

Compiled files up to:
08:54 on Nov 09, 2005
"remember virtualdub plugins folder"
http://cia.navi.cx/stats/project/ffdshow/.message/6343176

Main reason for update:
16:55 on Nov 08, 2005
"updated libavcodec "
http://cia.navi.cx/stats/project/ffdshow/.message/6335701

+ all other many updates

All files gcc 4.0.2 (SSE2 Disabled)

Enjoy.

(SSE2 build for those interested: http://mirror05.x264.nl/public/ffdshow/ffdshow-20051109-gcc4.0.2-sse2.exe)

signatory

9th November 2005, 17:56

Thanks Bob0r ! :D

MacAddict

9th November 2005, 18:08

Cool! Thanks for the new builds.

asasadad_1

9th November 2005, 18:19

libmpeg2_ff.dll(gcc) had a higher cpu usage than libmpeg2_ff.dll(msvc or icl 9) :confused:

ExtraEye

9th November 2005, 18:24

thx for the new (SSE2) build bob0r.
i still have the problem with the avisynth filter.

Lemonzest

9th November 2005, 18:56

(SSE2 build for those interested: http://mirror05.x264.nl/public/ffdshow/ffdshow-20051109-gcc4.0.2-sse2.exe)

Thanks :)

madman1980

10th November 2005, 02:08

Is there any chance you could make these settings default in future ffdshow builds?

http://img108.imageshack.us/img108/66/ffdshowanamorphicoverlaysettin.png

It enables the aspect ratio to change to the ratio specified in the file, which might be different from the ratio according to the pixel ratio. This should really be natural behavior, just look at MPEG2, both DVD and SVCD data need the aspect ratio info to play correctly. I have a big problem now with divx/xvid files that have big black bars vertically and horisontally and look really squeezed.

MacAddict

10th November 2005, 02:12

Does the overlay mixer have to be selected though?

Sharktooth

10th November 2005, 03:25

LoRd_MuldeR made me notice milan restarted his daily builds:
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

Egh

10th November 2005, 04:48

Does the overlay mixer have to be selected though?

IIRC you need to make it half-on :) aka not checked and not unchecked.

But, imo, then it doesn't use software resizer to do actual resizing. Since i prefer quality (and my card doesn't support PS 2.0 anyway :P) I use ffdshow software resizer both to resize the frame to fullscreen and to adjust aspect ratio. Keep on bugging Milan to implement using DAR automatically :P

Thomas_AR

10th November 2005, 04:53

The last build from Milan is amazing. The setup file is 1MB smaller and testing the same avi video with other last ffdshow builds (same configuration) i have 15% less CPU usage.

madman1980

10th November 2005, 07:17

Does the overlay mixer have to be selected though?

Yep, to clarify, those two marked boxes are not checked by default.

marcellus

10th November 2005, 09:23

The last build from Milan is amazing. The setup file is 1MB smaller and testing the same avi video with other last ffdshow builds (same configuration) i have 15% less CPU usage.
Yes, I got about the same result (~10% lower CPU usage). FFDshow gets faster and faster. A few days ago the fastest build for my Athlon XP was still celticdruid's 20051103. But now the top looks like this:
1. milan's 20051109 (by far)
2. bob0r's 20051109
3. celticdruid's 20051103 <-- which is fast anyway
Conclusion: a) GCC gains speed vs. ICL, b) milan has a "magic" trick in his sleeve when it comes to compiling.
Anyway, good bye dropped frames :cool: :cool: :cool:
Big :thanks: to everyone involved!

bob0r

10th November 2005, 10:54

Do note, most of Milan's compiled files seem to be ICL 8.
Celtic_Druid's compiled files are mostly ICL 9.

Milan does not support ICL 9, so this might be the reason why ICL 8 builds are faster than ICL 9.

As for GCC, we are getting there :cool:

celtic_druid

10th November 2005, 12:07

gcc with specific CPU flags might be faster. I guess I could re-install ICL8 and see if there is indead some magic involved or it is just faster than ICL9. I guess on Intel chips ICL9 should be faster.

Smiff

10th November 2005, 15:13

are we getting consistently stable builds yet? is Milan's good for Sempron K8 SSE2? i've stopped on 2005-10-06 build (not sure whose, oops) becuase that was stable, but would like to update again when its safe :p

Sharktooth

10th November 2005, 15:49

get it ... find it by yourself...
if you dont like it reinstall your old version.

Smiff

10th November 2005, 18:13

heh thanks but no thanks, friends and family like to be able to watch movies without crashes, if it was just on my own machine for my amusement, yeah.
was just a friendly request for anyone who's done the research on similar CPU, no point everyone repeating the trouble.. sorry but i don't have time to contribute to everything i would like to. i just think it would be worthwhile, someone maintaining a list of which builds are confirmed good on which CPUs, this is only a suggestion for someone with the time so don't get all angry please. and thanks again to everyone spending time making compiles etc etc, love you even when they don't work so well, 'cos i couldn't do it :)

i can (only) confirm the 2005-10-06 build with installer MD5 hash 5B9F67AA1ACE3049FEA7AB6527025E1D
is stable on K8 SSE2 Sempron, for DVD levels and MPEG4
as long as you don't use resizers etc, then things get iffy.

Egh

10th November 2005, 18:33

i can (only) confirm the 2005-10-06 build with installer MD5 hash 5B9F67AA1ACE3049FEA7AB6527025E1D
is stable on K8 SSE2 Sempron, for DVD levels and MPEG4
as long as you don't use resizers etc, then things get iffy.

There were plenty stable builds after 1006. E.g. 1013 celtic's. And most instability/slowdowns problems were with gcc builds. Once those gcc-specific issues were fixed, gcc now is as good or excels ICL builds.

So just grab 1109 b0b0r's one :)

videomixer9

10th November 2005, 21:38

I wonder what ppl got with the resizers, imo the hardware resizer used on overlay mixing is enough with any modern graphics card and also uses zero CPU. All those 3D Hardware using renderers are total bloat anyways, and they rarely deliver real better quality, it's just a solution to render the video into the same colorspace as the rest of the screen and obviously shows how reduced the colorspaces used for videos are. Basically it just eats up performance that modern graphic cards are handling internally usually. There are a few bonuses, but they aren't really worth it.

For me the last gcc build works great and still has better performance than milans build on athlon xp (barton). After some issues it had before with libmpeg2 using too much CPU it works great and stable now, never crashed. But for decoding I don't use all those stupid toys anyways, as I have no need for them, nvidia drivers correct tv out overscan perfectly for me, resizing is done in the hardware just fine too, and postprocessing on most videos just make them lose all details, with the most cpu intensive spp postprocessing being the most crappy one even, but it was always crap since it hit mplayer.

oddball

10th November 2005, 22:11

For anyone like me who likes to transcode 6 channel Ogg or 6 channel AAC rips to AC3 SPDIF output (To be played by on your AC3 reciever) whilst leaving 2 channel PCM untouched. Here is a great tip from Milan.

http://sourceforge.net/tracker/index.php?func=detail&aid=1350413&group_id=53761&atid=471492

Socio

11th November 2005, 14:13

_xxl

11th November 2005, 14:23

http://www.elecard.ru/movies/Olesya/OLESY_SIF_90kbps.mp4
ffdshow avc h.264 mobile
Microsoft Visual C++ Runtime Library
Assertion Failed!
Program...Media Player Classic 6.4.8.6 and Media Player 2
File libavcodec/h264.c
line 7755
EXPRESSION Pict--Data[0]
Amd XP 1600+ winXP Sp2
Tested with:
Milan's compiled fdshow-20051109.exe ICL8 and bob0r's fdshow-20051109.exe sse GCC.

Egh

11th November 2005, 15:03

I don't know if it has been reported yet but I found a bug in the ffdshow-20051109-gcc4.0.2-sse2 version I am using , I don't know if it is just this this version or if it is happening with the other 200051109 version.
The bug is with Gradual denoise, if I try to enable it, it will crash any program I am using ffdshow with.

Are you sure you have SSE2 cpu? :P At least generic build 20051109 doesn't have that problem (tested on Athlon XP).

@ Earlier reporters comparing daily build and b0b0rs:

WHERE the hell you see any speed *increase*? As for playback of avc streams, I didn't notice any and if not some DEcrease was actually spotted.

Anyhow, plain gcc build is now terrific in speed :) I managed (but with all quality options disabled) only in YUY2+overlay and no softsubs, no resizing to playback a video. But WHAT a video! :P 960*544 *HIGH-PROFILE-AVC*!!! [ref=3,b=1]. Used separete fields on .TS [1088i] source and then resized horizontally. So that's 960*544 and 29.97fps all the way with average bitrate 2500kbps! And was able to play it without any frame drops on 1800+ XP (though somehow only with b0b0r build, with same settings Milan build was somewhat slower). That's terrific improvement in speed in the last month for gcc!

Edit
BTW, just now experemented a bit and somehow managed to play normally (though 99% of times cpu usage is 100%) in VMR9 renderless mode in RGB32 colorspace. Heh, I thought that wasn't possible for my cpu at all :P

IgorC

11th November 2005, 15:39

marcellus

11th November 2005, 15:53

@ Earlier reporters comparing daily build and b0b0rs:
WHERE the hell you see any speed *increase*? As for playback of avc streams, I didn't notice any and if not some DEcrease was actually spotted.

I'm sorry, ffdshow seem to have many uses (not only many users) and sometimes maybe we are comparing apples to oranges. I use ffdshow almost exclusively for encoding/recording (as I don't like to watch anything on my PC, I watch on standalone + TV set). It's in fact the most customizable libavcodec based encoder (besides mencoder) that has also a DShow interface that makes it suitable to work with capturing applications.

So, to be exact, my chain is(In general, when I post in this thread, this is what I'm talking about):
PAL TV capture -> leakkerneldeinterlace -> mpeg2 encoding. This is (way) faster with milan's build.

At some point it may be useful to make a test of speed for different builds but all made on the same CVS version and the same filterchain for decoding/encoding. There are so many cases that I'm scared (CPUs, compilers, codecs, audio, video, filters) but this is ffdshow and we love it for what it is :)

ExtraEye

11th November 2005, 16:54

Egh

11th November 2005, 18:43

bah... avisynth filter not working for me at any of the recent versions.
am i doing something wrong?
about the colorspace...
it used to take much less cpu to convert to RGB32. now it makes playback jerky for me (AMD 64 3000+).
is there any profit from making the output yuy2 instead of yv12?
last question, what's the advantage in playing the video through VMR9 renderless?

w00t? Well, no idea why you think RGB32 conversion is taking more. In fact for gcc builds there was a problem until last October builds which caused terribly slow and screwed YV12-->RGB conversion. Now VMR9+RGB32 playback prooly a bit faster than even Celtic builds. As I said already, I was shocked to discover practically non-framedrop playback of avc 960*544@29.97fps in RGB VMR9. Judging from previous builds performance, I thought that it would be slightly out of reach for my 1800+, but last b0b0r build prooved I was wrong :P

About VMR9 :readguid: . In short [for MPC] : VMR9 subtitle rendering plugin, DirectX9 rendering (means PS 2.0 support if your card has it). For at least older cards, VMR9+RGB32 typically has better quality than overlay. My card is GForce4MX (128MB DDR), so no pixel shaders but i still use VMR+RGB cause it simply has better quality (better colors and sharpness of the picture).

ExtraEye

11th November 2005, 19:10

hmmm
o.k thx for the info.
i tried switching to bob0r's latest instead of milan's and now it works great.
umm egh, does avisynth filter work for you?

Socio

11th November 2005, 21:47

Are you sure you have SSE2 cpu? :P At least generic build 20051109 doesn't have that problem (tested on Athlon XP).

Yes I have a P4 3.06 which has SSE2,

Liisachan

12th November 2005, 00:46

I'm getting this "Assertion failed!" for AVC.mp4 too:
File: libavcodec/h264.c
Line: 2590
Expression: pic->data[0]

Tested: milan 20051109, celtic_druid 20051103, bob0r 20051109 etc,
with or without Haali.

x264 settings (a shorter test clip with the exatctly same settings IS OK!):

"x264.exe" --pass <1|2> --bitrate 1150 --stats "stats.log" --keyint 240 --min-keyint 24 --ref 16 --bframes 1 --filter 3:0 --subme 7 --weightb --trellis 2 --analyse all --8x8dct --qpmin 8 --qpmax 30 --qpstep 12 --ipratio 1.3 --pbratio 1.4 --me umh --merange 32 --threads 1 --progress --scenecut 35 --fps 23.976 --output <NUL|"out.mp4"> "in.avs"

I used celtic_druid's 361M, and i think it ended normally with this msg "encoded 34259 frames, 1.56 fps, 1150.02 kb/s"

Egh

12th November 2005, 01:00

umm egh, does avisynth filter work for you?

Date: 2005-11-11 20:02
Sender: milan_cutka Project Admin

Fixed. Thanks for reporting this, it was very stupid mistake.

BTW I rewrote calling of avisynth to make in compatible with
GCC and this might introduce another bugs.

Also for those who not actively watches ffdshow development trackers would be interested in this info from Milan concerning different builds:

Date: 2005-11-11 16:36
Sender: milan_cutkaProject Admin

I'm sure ffdshow build with GCC won't run on Athlons without SSE. With -msse option which is required to compiler ffdshow using GCC, it generates code which use SSE registers. And with recently added -mfpmath=sse almost all floating point calculations use SSE.

Please report any problems which might be specific to GCC build, because I'm almost sure there are still some present. I'll be glad to replace ICL with GCC when GCC build won't contain more bugs than those created by Intel's compilers. However, ICL will still be needed for building versions which wouldn't require SSE.

I didn't get it :) I thought that plain gcc generic builds work on casual Thunderbirds, right?

So though developer is surely trying eventually to use only gcc for builds, but as for now he is not sure if gcc compilations are safe enough (though i personally think they are :P)

tritical

12th November 2005, 01:06

@Liisachan
I recently had the exact same problem with a number of x264 encodes produced with x264cli (r362 and few r350's, sharktooth's and x264.nl builds). I got the exact same error you posted with both my own compiles of ffdshow and celtic druid's. Through process of elimination I have found it too be a problem with x264cli's mp4 output... because if I redid the exact same encodes with the exact same settings, but used raw .264 output from x264cli and then muxed the result into mp4 with mp4box it would play perfectly. Another interesting result was that the second pass with raw output was noticeably faster than with mp4 output. The problem with mp4 output from x264cli doesn't seem to always happen as I could also make shortened encodes of the same clips, or other clips, with the same settings and they would play correctly.

Thomas_AR

12th November 2005, 01:43

@IgorC
Same here, MPC with ffdshow (tested various builds) alone won't play this video. But...
i installed 'Nero Digital MPEG 4 AVC h.264 dshow decoder v2.02'. Even with this codec installed the video is playing badly in MPC, only 4 seconds of 21 as it says in properties and no sound. Looks like a bad cut of a whole mp4 video. Possible?

Liisachan

12th November 2005, 03:06

@tritical
Thank you very much I'll try that :)

Axed

12th November 2005, 08:18

I didn't get it :) I thought that plain gcc generic builds work on casual Thunderbirds, right?

I've still got one of these egg cookers, ill try it and tell you.

Yep Milans correct, the GCC builds just crash straight away on an Thunderbird.
It is possible to get it to run XviD movies by turning off Post Processing and MP3 decoding albeit very, very, slowly.

Alternatively, i tried Milans build and it ran the XviD movie, handling the audio decoding and all at an average of 50% CPU usage using mplayer deblocking, brightness enhancement and a stereo - 5.1 upmix.

bob0r

12th November 2005, 13:40

I was planning on making ffdshow-2005Nov11.exe yesterday (new filename)
Now i wanted to make it today, but ffdshow sourceforge CVS is not updating anymore :confused:

Maybe its time to move over to SVN? :)

Expect a new build, with a new filename for less confusion, when CVS is updating again!

Edit:
http://sourceforge.net/docs/A04/

Project CVS Service: Partial Outage In-Progress Last updated: 2005-11-11 Pacific

( 2005-11-11 12:47:03 - Project CVS Service ) As of 2005-11-11 developer CVS is back online and operational. Anonymous CVS will be out of sync throughout the weekend as updates are processed.

( 2005-11-11 06:27:36 - Project CVS Service ) As of 2005-11-11 developer CVS service is presently offline for unplanned maintenance, estimated time of service restoration to be determined.

Guess can update after the weekend again :goodpost: