Log in

View Full Version : New ffdshow build (?)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 [67] 68 69 70 71 72

cc979
7th December 2006, 14:31
How did you test. Was it "visually" or did you make a "screen-grab" and perform a spot test?

I don't seem to be able to find this setting....


Cheers

i took screen grabs for all the modes apart from overlay

the colour correction is in video/television panel using advanced settings

http://img392.imageshack.us/img392/8835/clipboard1de5.th.png (http://img392.imageshack.us/my.php?image=clipboard1de5.png)

fastplayer
7th December 2006, 14:50
@clsid:
I noticed in your install_script.iss that you ship 2 versions of ffdshow.ax and ff_wmv9.dll. I suppose both are compiled for different CPUs but where in your script is the CPU detection part? Or is this done automagically by the Inno installer?

Edit: Never mind. One file is built with ANSI, the other with Unicode support.

clsid
7th December 2006, 16:30
edit: nevermind

fastplayer
7th December 2006, 23:00
In case someone missed it:
Build 654 aka proposed stable is out!
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=213872&release_id=469134

Romario
7th December 2006, 23:07
I downloading it now!!!

clsid, I don't know how to report bug to ffmpeg devs. So, can you, please, instead of me, report x264 interlaced bug to them.

Thanks.

I think that when this bug get fix, ffdshow devs can declare stable build.

LoRd_MuldeR
7th December 2006, 23:19
I just noticed that the German installer says: "Unverarbeitete Videodaten" (unprocessed videodata)
shouldn't it be: "Unkomprimierte Videodaten" (uncompressed videodata)
instead?

fastplayer
7th December 2006, 23:37
Since eragon4ever translated "RAW Audio" with "Unkomprimierte Audiodaten", he should change it for consistency's sake. PM him.

Eragon4ever
7th December 2006, 23:42
No need for PM. I'll change it.

fastplayer
7th December 2006, 23:47
That was fast! :eek:
Thanks!

clsid
8th December 2006, 00:30
I think I have found a bug in the ffdshow subtitle filter.

If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position.

fastplayer
8th December 2006, 00:41
For me the subtitles play faster than in normal mode.

Px
8th December 2006, 13:10
Downloaded Build 654 aka proposed stable, only remaining problem - with vfw encoder

foxyshadis
8th December 2006, 16:25
Er, what error would that be, exactly? It doesn't crash or corrupt anything for me.

Px
8th December 2006, 16:52
Er, what error would that be, exactly? It doesn't crash or corrupt anything for me.
http://forum.doom9.org/showthread.php?p=900177#post900177
8) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)".

ilpippo80
8th December 2006, 19:34
I've tested ffvfw+virtualdub 1.6.16 reencoding an avi file and a mpeg1 file. I used "full processing mode" for video and "no audio" settings. The ffvfw were the default ones, with one step and constant bitrate.
Here's my results:

- The following encoders gave me the error "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100):"
MPEG-4 MPEG-1 MPEG-2 (with the avi but no problems with the mpeg1)
H261
H263
DV
ISO MPEG-4 Video V1
Windows Media MPEG-4 Video V3
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2

- the mjpeg files created crashed with ffdshow decoder (in mpc) but not vlc.

- the wmv8 files created gave me corrupted video with both ffdshow decoder and vlc

_xxl
8th December 2006, 19:52
Sample file please.
the mjpeg files created crashed with ffdshow decoder (in mpc) but not vlc.
What version are you using?This bug was fixed in rev 400.
- The following encoders gave me the error "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100):"
MPEG-4 MPEG-1 MPEG-2 (with the avi but no problems with the mpeg1)
H261
H263
DV
ISO MPEG-4 Video V1
Windows Media MPEG-4 Video V3
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2

EDIT:
H263+ is working?
I don't think that it is possible to reencode to any video codec? :confused:

clsid
8th December 2006, 20:07
sample input file (http://www.mytempdir.com/1105695)

ilpippo80
8th December 2006, 20:18
I'll upload the files later this evening, anyway I'm using rev641_20061206_clsid_icl9

egandt
9th December 2006, 01:23
Using the rev654 20061207 I can not resize as the aspect ratios is always 9x16 and not source derived, I've tried 3 builds from the 7th all with the same MO. The input resolution is 640x480 resize is set to "no aspect ratio correction", the output video is always 16x9 no matter what setting is used in Zoomplayer (which has had no changes since I upgraded from an 11/17 build). Note: turning off resize in ffdshow resolves the issue.

Also flawed in the rev601_20061130-sse2.

ERIC

ilpippo80
10th December 2006, 12:16
Sorry for the lack of news, I've been a bit busy yesterday...
Anyway, here's the files:
http://www.sendspace.com/file/yk37wq

I just made some other tests, and I've seen that the mpeg1,2,4 compression problem is with some avi files and not with others, while I had no problems with mpg files so far...

H263+ is working?

Yes, H263+ is working...

I don't think that it is possible to reencode to any video codec? :confused:

What do you mean?

haruhiko_yamagata
10th December 2006, 14:15
Using the rev654 20061207 I can not resize as the aspect ratios is always 9x16 and not source derived, I've tried 3 builds from the 7th all with the same MO. The input resolution is 640x480 resize is set to "no aspect ratio correction", the output video is always 16x9 no matter what setting is used in Zoomplayer (which has had no changes since I upgraded from an 11/17 build). Note: turning off resize in ffdshow resolves the issue.

Also flawed in the rev601_20061130-sse2.

ERIC
No aspect ratio correction means ffdshow respects the setting of "Specify size".
If you want to respect source aspect ration, you have to choose "Keep original aspect ratio".

vlada
10th December 2006, 15:32
I have some questions regarding default setting of ffdshow. I'm writing a beginners guide on how to set up video playback on computers with MS Windows. Of course ffdshow is here the base. I don't want to confuse the readers so I'd like to ask you a couple of questions:

1) Why are MPEG-1 and MPEG-2 not checked by default. I had some troubles with some MPEG-1 videos and ffdshow. But I never had a problem with MPEG-2 videos using libmpeg2. On the other side libavcodec always causes very choppy playback with MPEG-2. What are the reasons that MPEG-2/libmpeg2 is not enabled by default?

2) Why isn't FLAC enabled? Are there any problems?

3) Why is tremor the default decoder for Vorbis? I heard libavcodec should have higher quality. But there used to be a bug in 5.1 decoding. Is it already fixed?

4) Why is postprocessing off by default? I even can't select it in installer.

Thank you.

fastplayer
10th December 2006, 15:47
1) Why are MPEG-1 and MPEG-2 not checked by default. I had some troubles with some MPEG-1 videos and ffdshow. But I never had a problem with MPEG-2 videos using libmpeg2. On the other side libavcodec always causes very choppy playback with MPEG-2. What are the reasons that MPEG-2/libmpeg2 is not enabled by default?
I can only guess so... Since most people have some 3rd party MPEG2 decoder installed on their system, enabling libmpeg2 in ffdshow would override the default MPEG2 decoder which some people don't like. As for MPEG1, Windows already ships with a basic MPEG1 decoder which handles most MPEG1 videos. At least for me... :D
And most people use MPC as their default player anyway which already has libmpeg2 integrated and enabled by default. So I don't see any problems with ffdshow regarding libmpeg2...

clsid
10th December 2006, 17:03
Playing .flac files requires a source filter. ffdshow is only a decoder. If you install the source filter, then it also comes with a decoder.

Post-processing should never be on by default. PP is only useful for bad quality videos, and even then the best settings depend on the specific video and the users eyes and taste.

fastplayer
10th December 2006, 18:23
3) Why is tremor the default decoder for Vorbis? I heard libavcodec should have higher quality. But there used to be a bug in 5.1 decoding. Is it already fixed?
AFAIK, celtic_druid released once a version which had this bug fixed. I don't know if it has been incorporated into the tryouts... :confused:

Eragon4ever
10th December 2006, 18:37
It has been fixed it rev 4.

Jeremy Duncan
10th December 2006, 21:14
Since Lanczos Resizing is Multithreaded on Dual Core cpu's and not Hyperthreading ones.
What else is hyperthreaded on Dual core only and not hyperthreading cpu's, Is Queue output samples useful on Hyperthreading cpu's ?

MatMaul
10th December 2006, 21:21
I have tried to make a trunk folder in the repository, and I totally break the repository, sorry.

:stupid: (it's me...)

anyone who have a svn access can make a trunk folder with the development version in it please (the last non-broken version is the 674) ? like that :

/branches/ => beta1, beta 2 etc
/trunk/ => the development version

like that if anyone want only the development version he can have it without download all the branches

thanks a lot and sorry again.

EDIT : I actually try to resolv that, I think it was good in about 5 minutes. sorry...

clsid
10th December 2006, 21:27
uploading now

MatMaul
10th December 2006, 21:30
ok, I stop my own upload.

fastplayer
10th December 2006, 22:15
Why does ffdshow need a branch? It's not like some sort of backwards-compatibility has to be maintained like the Mozilla guys having Firefox branches for version 1.0.x, 1.5.x.x, and 2.0.0.x, or am I wrong?
Why not stay with one branch and release monthly/quarterly etc. a stable version? The decision could be based on a democratic poll here on the forums or the main developers decide among themselves which build to release.

Eragon4ever
10th December 2006, 22:24
This way new features can be added to trunk while fixes are in both. And maybe it will be deleted after a release and the source code will be packed?

Mangix
10th December 2006, 22:26
got a question here. why is the ALAC decoder not included with ffdshow? the current libavcodec has the code needed to decode ALAC but ffdshow isn't using it...

_xxl
10th December 2006, 22:30
got a question here. why is the ALAC decoder not included with ffdshow? the current libavcodec has the code needed to decode ALAC but ffdshow isn't using it...
http://sourceforge.net/tracker/index.php?func=detail&aid=1359547&group_id=53761&atid=471492

fastplayer
10th December 2006, 22:46
This way new features can be added to trunk while fixes are in both. And maybe it will be deleted after a release and the source code will be packed?
You got a point. Although most of the development work is updating ffmpeg and fixing bugs. So I'm not entirely sure if adding branches is of any advantage. Maybe I'm just too short-sighted... :D

clsid
10th December 2006, 22:55
I got a timeout twice during commit. MatMaul, can you upload it?

Here is the latest source code:
http://www.mytempdir.com/1109364

MatMaul
10th December 2006, 23:02
ok i upload now.

haruhiko_yamagata
11th December 2006, 00:21
Since Lanczos Resizing is Multithreaded on Dual Core cpu's and not Hyperthreading ones.
What else is hyperthreaded on Dual core only and not hyperthreading cpu's, Is Queue output samples useful on Hyperthreading cpu's ?
Yes. Resize is the only one that P4HT is excluded from multithreading.
Because P4HT does not have extra core for MMX, resizing and decoders would get little effect from multithreading.
Queue output samples does not depend on MMX and so it is best match with P4HT.

clsid
11th December 2006, 15:20
List of known issues in revision 684:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Some files with interlaced H.264 video don't decode properly. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). FFmpeg bug or perhaps a x264 VFW bug? (Reported by Romario)

Other bug reports:

3) Writing an OGM file via VFW interface creates a corrupt file. (reported by clsid)
4) FLV muxer seems to be buggy as well.
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". At least some of these encoders do work for others? Seems to depend on the input? Sample input file (http://www.mytempdir.com/1105695). (reported by: a few people)
6) I think I have found a bug in the ffdshow subtitle filter. If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position. (reported by clsid)

ToDo:

7) Add WM9 decoder passthrough
8) Update and fix SNOW support
9) Fix VMnc decoding
10) Fix VC-1 decoding
11) Update libavcodec vorbis

Other issues:

12) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). These files should be very rare. Funny thing however is that the files play fine and without crash if you first play another file and then play the 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)

MatMaul
11th December 2006, 17:03
7) Add WM9 decoder passthrough
I don't understand this feature :o

EDIT : when I tick "VMR9 mixer mode" in MPC, queue is not actived (rev684 by clsid) : it is normal ?

mpioner
11th December 2006, 18:12
developers pls add suport for this http://cia.navi.cx/
How
https://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1#scripts
like http://cia.navi.cx/stats/project/ffdshow

Liisachan
11th December 2006, 18:31
you mean this? [ 1577522 ] ffdshow "Queue output samples" support (http://sourceforge.net/tracker/index.php?func=detail&aid=1577522&group_id=82303&atid=565651)
patch is included in celtic_druid's 611-2, tho it is reported that 611-2 has a problem about Dts

MatMaul
11th December 2006, 18:55
you mean this? [ 1577522 ] ffdshow "Queue output samples" support (http://sourceforge.net/tracker/index.php?func=detail&aid=1577522&group_id=82303&atid=565651)
patch is included in celtic_druid's 611-2, tho it is reported that 611-2 has a problem about Dts
I have the last celtic druid mpc.
I'm not talking of this bug.

If I haven't "vmr9 mixer mode" ticked, no problem queue is active.
if I tick "vmr9 mixer mode", I have a "not effective : the video renderer in use does not support queue."
I use vmr9 renderless as renderer.

KoD
11th December 2006, 20:01
Libavcodec vorbis in current ffdshow does work with 6 channel vorbis. You can look at a test file here http://www.cccp-project.net/beta/test_files/[CCCP]_Manhole_Test_Your_5.1_[revamped].mkv

There is an issue with drevil's installer (at least in build 685). It installs the ansi version of files (at least considering what the about box says) instead of the unicode ones on my Windows XP. Clsid's 684 build installs the unicode version as expected.

LoRd_MuldeR
11th December 2006, 20:11
I have the last celtic druid mpc.
I'm not talking of this bug.

If I haven't "vmr9 mixer mode" ticked, no problem queue is active.
if I tick "vmr9 mixer mode", I have a "not effective : the video renderer in use does not support queue."
I use vmr9 renderless as renderer.

yeah, same here!

haruhiko_yamagata
11th December 2006, 23:46
EDIT : when I tick "VMR9 mixer mode" in MPC, queue is not actived (rev684 by clsid) : it is normal ?
fixed at rev 682. Though it was a simple bug, I decided to enable queue in VMR9 renderless and disable in VMR9(except for renderless) for beta 1. After beta1, I'll try to enable queue in VMR9 only when it is safe.

MatMaul
11th December 2006, 23:56
fixed at rev 682. Though it was a simple bug, I decided to enable queue in VMR9 renderless and disable in VMR9(except for renderless) for beta 1. After beta1, I'll try to enable queue in VMR9 only when it is safe.
Are you sure ?
I have test with beta 1 and rev 684, same behaviour.

haruhiko_yamagata
11th December 2006, 23:59
There is an issue with drevil's installer (at least in build 685). It installs the ansi version of files (at least considering what the about box says) instead of the unicode ones on my Windows XP. Clsid's 684 build installs the unicode version as expected.
ANSI build work fine in Windows XP. It's the spec of my and drevil_xxl's builds.
If you use more than 3 languages(English, Windows version of language, another language), UNICODE build have the advantage. It may be two, if you use English version of Windows.

haruhiko_yamagata
12th December 2006, 00:15
Libavcodec vorbis in current ffdshow does work with 6 channel vorbis. You can look at a test file here http://www.cccp-project.net/beta/test_files/[CCCP]_Manhole_Test_Your_5.1_[revamped].mkv

Vorbis? The sample looks like dts.

haruhiko_yamagata
12th December 2006, 00:16
Are you sure ?
I have test with beta 1 and rev 684, same behaviour.
Yes, both beta 1 and 684 work for me. VMR9 renderless + queue, YUY2 or RGB32.