View Full Version : ffdshow development #2
bond
25th July 2004, 14:15
ok, now that, after more than one year of development and testing, a new build of one of the best mpeg-4 (and more) directshow decoders existing, ffdshow, has been officially released, i take this opportunity to close the good old 65 sites strong ffdshow development (http://forum.doom9.org/showthread.php?s=&threadid=48511) thread, as its simply not possible anymore to find any infos in it
everyone is invited to continue the discussion about ffdshow development in this thread or start new threads for discssing specific issues in seperate threads :)
grap ffdshow here (http://sourceforge.net/projects/ffdshow/)
Soulhunter
25th July 2004, 18:05
@ Coroner
Thanks for the info !!!
Only asked coz there is this winamp plugin...
Version 1.2
SBLive! Resample BugFix output plug-in for Winamp2
Freeware component!
USE THIS SOFTWARE AT YOUR OWN RISK !!!
I will not be responsible for anything regarding the use of this software!
If you are not looking for highest audio quality or have no idea about what
distortion is, than this component is of no use for you ... it will only make
your CPU work more on music
but for those with SBLive! or Audigy series of soundcards and there are a lot more
with this issue! this will give you the perfect sound you wanted to hear when
you've bought that soundcard !!!
[The SBLive! issue]
SBLive! has a low quality resample to 48KHz algoritm (or multirate filter
kernel too small...) maybe because to keep low latency to audio stream ...
This is the SBLive! (and not only) problem:
absolutely any audio stream is converted to 48KHz.
the worst performance is 44.1KHz audio streams (cd audio).
Audigy has the same issue except it resamples to 96000Hz but still
kernel size too small so 1% IMD at 16KHz for Audigy2 (www.tomshardware.com)
[The solution:]
my high quality resample to 48KHz (or any >= 48000, that means 96000Hz too)
component for Winamp3.
Testing results:
using SBLive! to resample to 48000:
19KHz IMD=20%
18KHz IMD=10%
16KHz IMD=5%
14KHz IMD=1%
You don't believe me ...???? I've included in component pack generated tones
used in my test versions of 44100Hz and 48000Hz ... Should sound the same !!!
using my component for KernelLength=16000 samples:
19KHz IMD=0.01%
18KHz IMD=0.001% ; can't measure less than this
16KHz IMD=0%
CPU Load:
<14% on Duron 825MHz for KernelSize 16000
<5% on Duron 825MHz for KernelSize 6000
<1% on AthlonXP2000+ for KernelSize 20000
[known issues]
there are no known issues
<TargetSampleRate> specifies resample target frequency of filter (should be
48000 for SBLive! cards, 96000 for Audigy, and this must be the working
Samplerate of the DSP on your soundcard!!!
<KernelSize> is the multirate kernel filter length in samples of the lowpass
filter. Here are some hints for 48000&96000:
16000 samples for quality described above
6000 samples are enough for 0.1% IMD @ 19KHz and no audible IMD
(IMD is above 20khz and should be rejected by the hardware
lowpass filter of your soundcard)
altering this results:
higher KernelSize => higher quality more CPU load.
lower KernelSize => lower quality less CPU load.
don't alter this if you do not know what means this or if you do not check
the results on a spectrum analyzer!
I've used as spectrum analyzer Goldwave 4.23 and CoolEdit2000 to measure
IMD. To record result just loopback your soundcard output to Line-In and
view the result over SpectrumAnalyzer in realtime.
[some hints]
If you really want your SBLive/Audigy/Audigy2 to sound perfect I recommand you
to download and install KX Drivers wich you can find at: www.kxproject.com.
These drivers are opensource and also freeware.
Best sound : KX Drivers + SBLive!Bugfix plugin. Try it!
[Contact:]
email: adi111p@yahoo.com
P.S. Haven't you noticed that DVD movies (sampled to 48000Hz) sounded perfect
on your sound system and Audio CD's didn't????? This is why!
another advice: Use KX drivers for SBLive and Audigy and Audigy2 soundcards. You will get
professional EQ-s, filters, 5.1,6.1,7.1 Decoders, but you will need some time to understand
how to configure it
download it from www.kxproject.com
So, still need to know this about ffdshows upsampling...
- Is Kaiser "the best" upsampling algorithm of ffdshow ???
- Is it better than the Audigy's "bad" resampling ???
- When yes, how much better is it ???
Tia n' Bye
unmei
25th July 2004, 19:19
great it even comes with a built in microwave :eek:
I don't know it this is ultimately new, but it wasn't in the 2004-06-29 i used so far: keyboard shortcuts to toggle PP, noise etc ..good idea, very useful!
Coroner
26th July 2004, 00:26
@Soulhunter
Haven't seen that one before. Same trick as resample in foobar by the looks of it. Would avoid the resample at 48Khz, although it's still not going to sound as good as a non-resample card, depending on the resampler it would probably sound better than the creative one. Suggest you might get better info by posting a question here Head-Fi Computers as a source forum (http://www4.head-fi.org/forums/forumdisplay.php?f=59)
Hope that helps
saratoga
26th July 2004, 01:04
Any chance of an Athlon or P4 optimized build? Or is that not worth the effort?
opsis81
26th July 2004, 14:50
Please fix the broken MPEG-1 and MPEG-2 decoding...
Please make me get rid of any other MPEG-2 decoder I have registered in my PC...
Thank you in advance!:)
SeeMoreDigital
26th July 2004, 15:12
Originally posted by opsis81
Please fix the broken MPEG-1 and MPEG-2 decoding...
Please make me get rid of any other MPEG-2 decoder I have registered in my PC...
Thank you in advance!:) I second this request!
It would be great if it could support Mpeg2 HiDef pixel frame sizes right up to 1920x1080/88...
Cheers
SeeMoreDigital
26th July 2004, 19:14
Originally posted by bond
... Grap ffdshow here (http://sourceforge.net/projects/ffdshow/) It's probably worth pointing out that the FFdshow builds on the SourceForge web site are by Milan Cutka.
Cheers
athos
26th July 2004, 19:41
Originally posted by SeeMoreDigital
It's probably worth pointing out that the FFdshow builds on the SourceForge web site are by Milan Cutka.
Cheers
The ffdshow-alpha builds are actually by me.
Did you notice the new ffdshow homepage that Milan put up?
http://ffdshow.sourceforge.net/tikiwiki/
bond
26th July 2004, 19:46
Originally posted by athos
Did you notice the new ffdshow homepage that Milan put up?
http://ffdshow.sourceforge.net/tikiwiki/hm, cant reach it atm :(
hellfred
26th July 2004, 20:01
It sure took its time, but finally a side came up in my browser.
So do not give up.
Here is a deep link (http://ffdshow.sourceforge.net/tikiwiki/tiki-view_articles.php)
Hellfred
SeeMoreDigital
26th July 2004, 20:02
Originally posted by athos
The ffdshow-alpha builds are actually by me.
Did you notice the new ffdshow homepage that Milan put up?
http://ffdshow.sourceforge.net/tikiwiki/
I apologise Athos. But why is Milan's name slapped all over the change logs?
http://sourceforge.net/project/shownotes.php?group_id=53761&release_id=255667
If this has confused me, I can't imagine how the newbies are going to get on :confused:
Cheers
athos
26th July 2004, 21:02
Originally posted by SeeMoreDigital
I apologise Athos. But why is Milan's name slapped all over the change logs?
http://sourceforge.net/project/shownotes.php?group_id=53761&release_id=255667
If this has confused me, I can't imagine how the newbies are going to get on :confused:
All CVS commits are by Milan. I just compile the binaries.
DAvenger
27th July 2004, 13:53
Many thanks to Milan for 'fixing' the wildcard issue. Now RadLight users can use FFDShow once again :D
(Milan, to bolo teda rychle hehe :p )
faxmactor
1st August 2004, 12:20
Sorry for taking over this matter from the previous thread, but I haven't replied this reply ;), and besides the problem still exists.
Originally posted by faxmactor
I have video that is likely to be made with an buggy, early Xvid 1.0 (or earlier) build. It has lots of b-frames but no keyframes in the beginning.
Xvid is able to display it correctly as well as mplayer (which uses libavcodec, too), so I came to a conlusion that this issue could be fixed in ffdshow as well. Milan, please have a look at.
A screenshot: HERE (http://ozdtersegi.axelero.net/ffdshow_issue.jpg), a short clip (2,5M): HERE (http://faxmactor.port5.com/Excel%20Saga%20-%2001%20-%20The%20Plan%20To%20Murder%20Koshi%20Rikudo%20(AHQ).ogm)
Originally posted by Bogalvator
Did you try setting the IDCT setting to XviD? (under the "Miscellaneous" section)
Yes, I did. No use...
Andy2222
2nd August 2004, 02:20
new SSE2 release up
NOTE: This is just a preview version, means its not as "rdy" as the older releases since im reworking kinda lots of stuff in the resizer and had no time to finish all.
I released this versions mainly cause milan added all this new audio stuff and this seemed usefull for the SSE2 version too.
PS: read the sse2 changelog first before u update since some small stuff is missing in this preview version!
u can download it from the sig location
Soulhunter
2nd August 2004, 02:53
Yay, milan added the SRC resampling Ive requested... :cool:
Cant await the non SSE2 version !!!
Tia n' Bye
Audionut
2nd August 2004, 10:56
Originally posted by Andy2222
new SSE2 release up
Thanks Andy2222 for your sse2 releases.
And to Athos for giving you somewhere to stash your realeases.:D
Alvy
3rd August 2004, 11:53
Ffdshow really got awesome in its possiblilities :) !
Thank you for your work.
It would be great if the hotkeys settings could get more powerful. So the user could comfortably take control over ffdshow.
For my personal usage it would be fantastic it one could control:
misc:
video delay +/- (10 ms) per keypress
resize:
black borders
+/- per keypress or at least toggle on/off
much less important
zoom +/-
shapen strength +/-
I would be very glad if someone could improve the functionality of the hotkeys.
Thanks
Alvy
Soulhunter
3rd August 2004, 17:53
Please could someone with a Audigy2 ZS help me to confirm something ???
Do the following steps with the 20040725 build...
- Set your Audigy2 to 5.1 setup
- Disable all extras (EAX, CMSS, EQ etc.)
- Connect a headphone to the L/R output of the card (or a 2ch amp)
- Activate ffdshows raw audio processing (no decoding/filters/mixer)
- Playback some stereo content (a simple mp3 file should do it...)
So, playback should be balanced (same loud @ L/R channel) !!!
When yes...
- Enable ffdshows audio resampling (96000Hz / Kaiser)
Do you hear a difference in the channel balance now (is one channel louder) ???
EDIT:
Addition to the last post...
Plz, try the above stuff with the default integer output (all checked -> 16/24/32) !!!
If the R channel gets louder (ca. 25%) after activating the resampling...
Disable 16bit integer and use 32bit floating point to see if it helps !!!
Tia n' Bye
Soulhunter
12th August 2004, 19:04
Ok, forget the stuff above !!!
Problem is solved with the last build... :)
Bye
omion
13th August 2004, 04:25
I've been having a problem with the latest (20040808) ffdshow build. It gives wierd 8x16 blocks in most b-frames of most movies. All of my movies are XviD or DivX (a whole bunch of versions... I don't know which ones are which) The blocks only appear when decoding b-frames with the latest build, and decoder set to libavcodec.
I have tested it in MPC and The Core Media Player, with the same results.
I have a P4 1.5GHz with 512MB RAM.
You can see an example here. (http://people.ucsc.edu/~rswilson/other/sakura-vs-ffdshow.jpg) Note that all the things that look like JPEG artifacts are actually JPEG artifacts. :p
Thanks!
Ana
13th August 2004, 10:28
I have the same problem with ffdshow (20040808) that omion has, when libavcodec is used to decode xvid. I think this has something to do with custom matricies.
Xvid (1.0.1) setting used to encode:
matrix: Andreas 78er
Qpel
GMC
max b-vobs: 2
VHQ 4
chroma on
Gooop
13th August 2004, 12:01
I don't think it has something to do with custom matricies, as I have the same problem on many videos which were encoded using h263.
2 bframes as well, QPEL but no gmc. I don't know if it can help but it seems that the problem is not exactly the same if the video is muxed in a mkv : in avi I can see the same artefacts as omion, but once muxed in mkv the video just crashes my player, mpc 6482 with its builtin matroska splitter. Another weird thing is that the player doesn't crash if I play the same mkv file with the same mpc but another matroskasplitter I registered (matroskasplitter_20040111-2). In this case the video plays with the same bugs as described before.
And I think (not sure, long time ago...) the problem occurs with videos that I encoded with older xvid builds as well (koepi-19062003-1).
arno
13th August 2004, 12:02
Is there already somebody out there that has some info on what "Mplayer Accurate Deblocking" exactly does (or has a link with an explanation)? If I interprete it right it sounds like a nice feature but a solid explanation would be nice :-D
masken
13th August 2004, 12:07
(repost from closed thread)
Is there any chance of improving the installer so that it supports silent installs? (/Silent switch for example).
...and perhaps also return an errorcode upon failure.
Perhaps also some additinal switches, like:
/DisplayProgress
/PostProcessing:[0-6]
/AutomaticQualityControl
...etc.
Or alternatively, the HKLM keys explained so one could just import values silently after an install to set the preferences.
This would really help me (and many other I guess) when installing new PC's....
swalker
13th August 2004, 15:47
Originally posted by masken
(repost from closed thread)
Is there any chance of improving the installer so that it supports silent installs? (/Silent switch for example).
It already does. The ffdshow installer is your standard NSIS based installer which supports /S for silent installations.
winman
13th August 2004, 21:03
@omion & ana
I also has the same weird blocks with some XviD and DviX movies. However, after changing the IDCT from the default "simple" to "auto", the weird blocks went away.
Previous version ffdshow-20040725 has IDCT default at "auto".
omion
13th August 2004, 21:17
Originally posted by Gooop
I don't think it has something to do with custom matricies, as I have the same problem on many videos which were encoded using h263.
2 bframes as well, QPEL but no gmc. I don't know if it can help but it seems that the problem is not exactly the same if the video is muxed in a mkv : in avi I can see the same artefacts as omion, but once muxed in mkv the video just crashes my player, mpc 6482 with its builtin matroska splitter. Another weird thing is that the player doesn't crash if I play the same mkv file with the same mpc but another matroskasplitter I registered (matroskasplitter_20040111-2). In this case the video plays with the same bugs as described before.
And I think (not sure, long time ago...) the problem occurs with videos that I encoded with older xvid builds as well (koepi-19062003-1).
I have strange things happen with Matroska, too. The screen shot I posted was from a Matroska, decoded with the external splitter (1.0.2.3 + sub patch) I demuxed the video, and tried to play the resulting AVI, but it crashed. Using the internal Matroska splitter, it also crashed.
Again, everything is magically fixed when using either an older version of ffdshow, or not using libavcodec.
I also just noticed that the blocks ONLY occur on the right half of a 16x16 macroblock, NEVER on the left.
@winman:
Doesn't help for me. :( I have mine set at XviD (libmpeg2) all the time.
Blkbird
14th August 2004, 02:04
OK, I asked this in the "old" thread, but it wasn't answered, so here I try it again.
Why are only TrueType fonts listed for subtitle display? The Type-1 and OpenType fonts are not showing up in the list.
ViCroié
14th August 2004, 14:44
I've been having a problem with the latest (20040808) ffdshow build. It gives wierd 8x16 blocks in most b-frames of most movies. All of my movies are XviD or DivX (a whole bunch of versions... I don't know which ones are which) The blocks only appear when decoding b-frames with the latest build, and decoder set to libavcodec.
I have the same problem, i tried both H.263 and Custom (HVS) matrice... but the only way for me to not have these blocks was to disable QPEL... when i use XviD's own decoder... it plays fine... for some encodes i used XviD with VHQ for B-Frames, but i tried XviD 1.0.1 and had same problem. :(
aketon
15th August 2004, 16:46
One good and one bad thing about ffdshow 20040808!
The good thing:
h.264 decoder can finally play encoded videos with all the analyzer flags enabled with no problems! :)
The bad thing:
Theora is broken!!!:(
timeismoney
16th August 2004, 09:41
I feel 0806 is better than 0808
I use 0808 to decode any AVI/MKV encoded by DivX Pro 5.11 will cause any player crash on my system, only videos encoded by DivX Pro 5.11, other version of divx is just fine
BTW, the audio codec is perfect under MPC and any version of WMP below 9.0, but under WMP9 it says like "Can't connect PINs", both AC3/DTS/AAC, and AAC is not friendly to some .aac and media contains aac audio track, m4a is all OK
arno
16th August 2004, 09:56
Originally posted by timeismoney
I feel 0806 is better than 0808
I use 0808 to decode any AVI/MKV encoded by DivX Pro 5.11 will cause any player crash on my system, only videos encoded by DivX Pro 5.11, other version of divx is just fine
BTW, the audio codec is perfect under MPC and any version of WMP below 9.0, but under WMP9 it says like "Can't connect PINs", both AC3/DTS/AAC, and AAC is not friendly to some .aac and media contains aac audio track, m4a is all OK
Yep, I agree. And 0808 also seems to hang my BSplayer a lot more often than 0806...
LigH
17th August 2004, 12:18
I just tried to run a test with makeAVIS, and read from another user that he does not get filtered output when he uses ffdshow's VfW interface to decode YV12 (he wanted to compare MPEG2Dec3's PP with ffdshow's PP). So I tested three configurations: ffdshow as VfW converter for YV12, ffdshow as frameserver for AVIS fake AVIs, and ffdshow as true decoder for FFV1 AVIs.
Result: No filter (deblocking/deringing, brightness/gamma, noise/grain) was applied to the decoded video in either case.
Is this intentional? Then I'm confused because the VfW interface looks like it provides image filtering, just like the DirectShow filter. Or may it be possible to miss one simple checkbox to enable image filtering in the VfW interface in general?
marcellus
19th August 2004, 00:01
Hi, I have two issues to bring to attention:
1. There is a problem with the Logoaway function. In mode "XY" and with a blur value equal and greater than 1 a green shade is cast over the logoaway rectangle that makes it easy to spot on an uniform background (otherwise it wouldnt be seen). The amplitude of this green shading increases in direct proportion with the blur setting (at 0 the problem doesn't show, at 10 is obvious). I use this function in realtime capture to increase compresibility.
Here is a frame that shows the issue. Look at the arrow to see greenish rectangle that should have the same colour as the surounding background.
Logoaway issue example (http://www.marcellusvcd.netfirms.com/Logoaway_01.html)
2. It seems there is an internal error in converting interlaced YUY2 to YV12. When I capture from YUY2 TV and I deinterlace in real time with almost any deinterlacer provided (including dscaler dll's) chroma of the resulted movie is somehow delayed half a frame from luma (This is easy seen at a scene change). When I check the "swap fields" box chroma is behind luma with half a frame. It's like the chroma of 2 consecutive frames is blended together. The only deintelacing method that does not show this "chroma delay" issue is "5 tap low pass" but that is normal since with this method the result is blended frames anyway.
Here is a succesion of frames that show the bug:
Frame1 (http://www.marcellusvcd.netfirms.com/Chr_blend_01.html)
Frame2 (http://www.marcellusvcd.netfirms.com/Chr_blend_02.html)
(Look at the arrow to see the chroma coresponding to the face of the character in frame number 1. The face of the curent frame character is pale because it doesn't have proper chroma like in Frame3.)
Frame3 (http://www.marcellusvcd.netfirms.com/Chr_blend_03.html)
best regards
marcellus
stephanV
19th August 2004, 17:31
Some issues with ffdshow's vfw MPEG4 encoder:
1. Enabling b-frames causes files to be undersized by a ratio of 1:5 or more
2. B-frames in combination with qpel crash VirtualDub (several versions) and also graphedit. Here's a crashinfo.txt (http://www.fesite.nl/grotesteph/crashinfo.txt)
Using qpel and b-frames with avs2avi gives me a ICSeqCompressFrame failed: The system cannot find the file specified
I cant remember this behaviour from earlier builds, although im not sure about the b-frames undersizing problems.
hope this is useful. :)
Bogalvator
19th August 2004, 20:46
I remember reading somewhere (here?) that ffdshow MPEG-4 with B-frames results in all B-frames being encoded at quant 31 when used in 2 pass - can someone confirm?
The avs2avi could be caused by the fact that ffdshow no longer installs the "ffvfw.dll" for the vfw section (guess work)
On a separate note: I notice that KernelDeint has succesfully been introduced into ffdshow. Would it also be possible to have DGBob integrated in to the deinterlace section without too much difficulty? This would be useful to those who store interlaced encodes on their PC (for things like sports clips, which aren't smooth enough when deinterlaced)
stephanV
19th August 2004, 21:37
just to be clear: if i didnt enable b-frames and qpel at the same time, avs2avi did work.
Andy2222
21st August 2004, 18:26
Originally posted by Bogalvator
On a separate note: I notice that KernelDeint has succesfully been introduced into ffdshow. Would it also be possible to have DGBob integrated in to the deinterlace section without too much difficulty? This would be useful to those who store interlaced encodes on their PC (for things like sports clips, which aren't smooth enough when deinterlaced)
DGBob was added by milan some days ago and can be used in a new release.
LigH
25th August 2004, 13:00
@ milan, athos, Andy2222:
Does ffdshow's VfW interface apply image filters at all? (^)
Soulhunter
25th August 2004, 15:51
Source...
http://img69.exs.cx/img69/2770/Source.jpg
Source -> VFW -> Blur 255 -> FFV1
http://img69.exs.cx/img69/1444/Blur255.jpg
Bye
LigH
25th August 2004, 16:22
When used as encoder: A little bit, it seems to me (shouldn't 255 soften a lot more?)...
But I'm rather interested in "when used as VfW decoder for AVIS".
bond
26th August 2004, 19:09
Originally posted by aketon
The good thing:
h.264 decoder can finally play encoded videos with all the analyzer flags enabled with no problems! :)what analyser flags?
The bad thing: Theora is broken!!!:/
aketon
26th August 2004, 22:27
Originally posted by bond
what analyser flags?
:/
Previous releases of ffdshow couldn't play properly the videos encoded with "Inter Analyzer Flag PSUB8x8" and "CABAC" ON at the same time! Now it can play them with no problems! Mplayer can play them also! VLC media player still can't play them properly!
Every time I am trying to encode with THEORA using ffdshow 20040808, the video I get is full of garbage in it! When I swithed back to previous releases of ffdshow, I could encode with no problems!
AS USUAL: "Sorry for my english"
BYE!!!
bond
26th August 2004, 23:23
ah yes indeed, afaik this has nothing to do with "analysing" but is basically the block size.
it should have worked for some time already, cause basically the ffmpeg guys fixed this because i made a bugreport at sourceforge, which was two months ago or so
i think i updated my h.264 sticky already with this info, i will have a look, ffmpegs h.264 decoder should be fully useable already i think
athos
28th August 2004, 13:29
New release up on SF. I decided not to include skl_drv_mpg.dll. Get it from earlier release, or here:
http://athos.leffe.dnsalias.com/skl_drv_mpg.zip
libavcodec.dll is smaller because i compiled without -funroll-loops.
mpeg-1/mpeg-2 decoding through libmpeg2 seems to work fine in this release, including seeking.
Gooop
28th August 2004, 14:06
thanks athos for the new build
xvid with bframes / qpel (don't know what caused the bug actually, didn't have time enough to test) works again, at least for me.
athos
28th August 2004, 16:05
Originally posted by Gooop
thanks athos for the new build
xvid with bframes / qpel (don't know what caused the bug actually, didn't have time enough to test) works again, at least for me.
It might have had something to do with the compiler flags i used for GCC. I tried to use only safe flags for this one.
Worf
28th August 2004, 17:01
Hi Athos,
i can't see the ffdshow-20040828 files in http://athos.leffe.dnsalias.com/?M=D
Im do something wrong?
Thanks
Worf
28th August 2004, 17:08
Oupsss!!! I find your file in SouceForge but not in your link... Sorry for my reply!
Thanks for your builds...
BR
SeeMoreDigital
28th August 2004, 20:40
Originally posted by Worf
Oupsss!!! I find your file in SouceForge but not in your link... Sorry for my reply!
Thanks for your builds...
BR Everybody please look here: -
http://sourceforge.net/projects/ffdshow/
Shinobu
28th August 2004, 21:22
too bad that vp3 decoding is alway bugs.
great works on audio filter.
++
aketon
28th August 2004, 21:27
At last! The latest version of ffdshow 20040828 has a new option to use bitrate in x264! It was about time!:D
[edit]
It is awesome! It has scene detection too (not so good though)! I've just encoded LOTR 3 trailer (resolution: 640x256 bitrate:900) and the result was good in the first 30 seconds, because after that 30 seconds, something strange happened to the codec! The encoder start to lower the bitrate from time to time and to use quantizers between 40-51!:confused: :confused:
[edit2]
I've just found where the problem is with the bad encode I mentioned! When I use "Inter Analyzer Flag PSUB8x8" and "CABAC" at the same time something strange is happening in the encoder and the result is to have (after a certain period of time) a video with quantizers 40-51! If you disable "Inter Analyzer Flag PSUB8x8" or "CABAC", then everything is going well!!!
SeeMoreDigital
28th August 2004, 21:53
Hi Athos and Milan,
Just a small thing. But can the 'menu' headings be altered slightly. My proposal is as follows: -
http://img9.exs.cx/img9/2975/SMD_FFdshow_proposal.gif
If it's okay with everybody that is?
Cheers
BoNz1
28th August 2004, 22:27
Originally posted by aketon
At last! The latest version of ffdshow 20040828 has a new option to use bitrate in x264! It was about time!:D
There is also a 2pass rate controller that is waiting to be added to the subversion.
EDIT: It would be nice if justin or min chen could update the vfw and the project file for the 1pass and 2pass. Please remove mc-c.c from the build also. Thanks.
Phanton_13
28th August 2004, 22:49
It's not posible to play VP3 using the theora library using a preprocesor filetr based in the reference lossles vp3 to theora trancoder .
virus
29th August 2004, 01:08
Originally posted by aketon
At last! The latest version of ffdshow 20040828 has a new option to use bitrate in x264! It was about time!:D
too bad the "1 pass fixed quantizer" option doesn't work anymore... it always encodes at roughly the same rate no matter what quantizer you use.
One good thing is that it apparently uses adaptive quantization within a frame (unless ffdshow's visualization tool is b0rked ;)). Some blocks are encoded at QP=24, others up to QP=30. Nice. But still too much bugs! :(
aketon
29th August 2004, 11:34
Originally posted by virus
too bad the "1 pass fixed quantizer" option doesn't work anymore... it always encodes at roughly the same rate no matter what quantizer you use.
Yes! The only working good (not so good though) option is "1 pass constant bitrate"! "1 pass fixed quantizer" is useless right now and it hasn't got scene change detection also!
Originally posted by virus
But still too much bugs!
Yes, inded!!!:(
pankov
29th August 2004, 17:20
@Athos, Andy & Milan
Gyus can you cooperate for integrating the "Green Fix" that Andy did
for the SSE2 builds for the non SSE2 builds?
2004-07-01 Andy2222 (ffdshow-20040701_SSE2.exe)
...
* fixed "green" shift resize bug
...
I really can't believe that this is not the the top priority fix as this is visible on all NVidia cards and especially in VMR9 mode which is supposed to be the mode used in the future.
I'm on the brink of stop using FFDShow for resizing and I will really hate to do this
PLEAAAASE, guys, kill this annoying bug
Andy2222
29th August 2004, 20:54
Originally posted by pankov
@Athos, Andy & Milan
Gyus can you cooperate for integrating the "Green Fix" that Andy did
for the SSE2 builds for the non SSE2 builds?
2004-07-01 Andy2222 (ffdshow-20040701_SSE2.exe)
...
* fixed "green" shift resize bug
...
I really can't believe that this is not the the top priority fix as this is visible on all NVidia cards and especially in VMR9 mode which is supposed to be the mode used in the future.
I'm on the brink of stop using FFDShow for resizing and I will really hate to do this
PLEAAAASE, guys, kill this annoying bug
i will write a normal mmx2 version for the normal build if my relocation chaos (new job, new location ... need to visit ikea, get a fridge..) is over
marcellus
2nd September 2004, 00:32
Hi, in latest build (20040828) avisynth processing inside ffdshow is broken :(.
dZeus
2nd September 2004, 16:11
Hi, are there any plans to improve the RGB conversion routines in ffdshow? I wanted to do a comparison of mpeg2 decoder filters by capturing frames with ffdshow, but I keep getting horrible artifacts caused by the conversion algorythm in ffdshow to rgb colourspace rather than the clean output I see on the overlay/vmr on my screen.
The routines in dvd2avi (http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/) produce much, much better results than the one in ffdshow (and also are GPL, so easy to copy/implement? ;) ).
Affar
3rd September 2004, 22:53
i Don´t know if developers know this error in last versiones of FFDSHOW (ALPHA) when is decoding old XviD compressed videos.
http://www.divxhouse.com/temp/error_ffdshow.28.8.2004.jpg
And here little sample of this error >> here (http://www.deco-flower.com/error_ffdshow.28.8.2004.zip)
Thanks and seeya :)
stephanV
3rd September 2004, 23:05
file works fine with ffdshow 28082004 in WMP and MPC...
Affar
4th September 2004, 00:37
Ops, the problem is in old configuration. Unistall and install and error is disappears :)
Sorry for the error :/
Rober2D2
6th September 2004, 09:52
About MPEG1, MPEG2 support.
1) Thank you for fixing decoding. It's been a long time :)
2) Aspect ratio does not work correctly for the moment. I am using bsplayer 1.0 and ffdshow 28-08-2004. Using an alternative MPEG decoder (intervideo for example), display correct aspect ratio.
Krismen
9th September 2004, 18:06
Hi
I have problem with mov video clips encoded with Sorenson video 3. I've got ffdshow-20040808 and 3ivx 4.5.1 installed. In ffdshow configuration svq3 is set to libavcodec. Allow Unsupported Decoders is checked in 3ivx media splitter configuration.
Here is a sample frame (no. 324) form Ocean 12 trailer (http://www.apple.com/trailers/wb/oceans_12/medium.html):
http://priv.twoje-sudety.pl/~divxpl/Dj_AnT/o12_bad_324.png
It was saved in VDMod using following script as input:
LoadPlugin("C:\Program files\AviSynth 2.5\plugins\directshowsource.dll")
DirectShowSource("o12.mov")
I've checked all IDCT algorithms if ffdshow properties but clip still dosen't plays properly.
I can watch it without any problem when I install QT Alternative, but it would be nice to wrap some SV3 clips into AVI container using GraphEdit (without any recompress, except qdesign audio :() and decode it through ffdshow.
In this (http://forum.doom9.org/showthread.php?s=&threadid=48511&perpage=20&highlight=svq3&pagenumber=16) thread:
Originally posted by ferrous66
Now that the latest unofficial build includes the Sorenson 3 codec, can you playback .mov files with ffdshow + 3ivx .mov splitter?Originally posted by Stux
It works with our latest builds, not sure what happens with 4.0.4
I thought it shouldn't be any problem with playing SV3, but I was wrong :-(.
Regards
SeeMoreDigital
9th September 2004, 18:21
Have you at anytime installed QuickTime Alternative?
If you have and are also running an official version of the QuickTime player, you might run into a few problems!
If you have not installed QuickTime Alternative you could try installing and registering this QuickTime DSdecoder filter (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/QuickTime_DSdec_Filter.zip).
Let us know how you get on please?
Cheers
Krismen
9th September 2004, 20:15
Have you at anytime installed QuickTime Alternative?
Yes, but I completly unistalled it (I had to uninstall QT Player as well) and installed QT Player and Cyberlink qt ds source filter. When I done this I couldn't manually construct filter graph in GraphEdit. GE crashed all the time when connecting output pin of File source async. to 3ivx media splitter. So I unistalled ds filter and everything back to normal except decoding :(.
If you have and are also running an official version of the QuickTime player, you might run into a few problems!
Yes I was aware of that. That's why I installed only ds filter later.
In a few days time I'll check how this trailer is decoded on another PC and then I'll post the result.
lalo
10th September 2004, 11:16
Hi Krismen!
You can try Nero's directshow filters in GE with installed quicktime alternative. I saved the graph and load it with directshowsource in avisynth. I've reencoded some trailers with this method in virtualdub.
You need: NeQTVdec.ax, NeQTAdec.ax, ndparser.ax and Avisynth 2.54 or newer.
It works fine me.
lalo
SeeMoreDigital
10th September 2004, 12:03
Originally posted by lalo
You can try Nero's directshow filters in GE with installed quicktime alternative. I saved the graph and load it with directshowsource in avisynth. I've reencoded some trailers with this method in virtualdub.
You need: NeQTVdec.ax, NeQTAdec.ax, ndparser.ax and Avisynth 2.54 or newer.Hi lalo,
Can you confirm if you've had any success using Nero's filters to decode "Sorenson/QD2 .mov" files (as currently used in all Apple QuickTime Trailers)?
I've only been able to use Nero's QT filters to decode "Mpeg4/AAC .mov" files - It would be good to have clarification?
Cheers
lalo
10th September 2004, 12:39
Hi SeeMoreDigital,
Yes, I managed to decode "Sorenson3/QD2 .mov" files using Nero's filters.
Cheers
SeeMoreDigital
10th September 2004, 13:57
Originally posted by lalo
Yes, I managed to decode "Sorenson3/QD2 .mov" files using Nero's filters. Jeez this is good news!
Have you able to play "Sorenson3/QD2 .mov" files in Nero's ShowTime player? I can't!
Cheers
easyfab
10th September 2004, 18:21
I see that the cvs was update with 2 pass support for x264 :)
With the next binaries release the true x264 test will begin.
Blight
11th September 2004, 08:32
The nero filters are riddled with bugs, they don't detect all audio tracks, they won't connect to ffdshow for Sorenson 3 decoding, they won't accept a disconnect/reconnect of the filter (required to fix the VMR9 scaling bug that is STILL in DirectShow, even after SP2/DirectX9c, etc... a shame, they are quite close to playing most quicktime files.
And I did get them to decode the QDesign Music 2 audio format.
aketon
11th September 2004, 10:43
Originally posted by easyfab
I see that the cvs was update with 2 pass support for x264 :)
With the next binaries release the true x264 test will begin.
Great news!:)
aketon
12th September 2004, 15:28
Is there anybody that can encode properly to theora with ffdshow?? In the last two versions of ffdshow, theora seems to be broken! Am I the only one who see this problem? Or it is just something that I did wrong during encoding?:(
Krismen
13th September 2004, 13:52
I've tested trailer mentioned ealier on another PC and it was played the same way as on my machine (using 3ivx + ffdshow). Then I converted this trailer into AVI with mov2avi using Sorenson Video 3 compression and ffdshow played this AVI correctly. So I think it's probably (???) 3ivx's fault not ffdshow.
virus
29th September 2004, 05:23
*bump* :D
@Athos, Andy
please pretty please, could you prepare a new build? The last one is 1 month old right now and there are a lot of improvements in x264 that we like to test.
Also: could you pass on to Milan the request to change the Quantizer slider when encoding to H.264 to the proper range defined in AVC (1-51) instead of the 1-31 used by default? That would be very appreciated ;)
cheers & thank you :)
virus
Kurtnoise
29th September 2004, 15:59
I've made a compile of ff_x.264.dll (http://atlas2.tgv.net/~media-video/forum2/download.php?id=1452) from the CVS...;) Just put it in the ffdshow directory and test it.
Tommy Carrot
29th September 2004, 17:01
Originally posted by Kurtnoise13
I've made a compile of ff_x.264.dll (http://atlas2.tgv.net/~media-video/forum2/download.php?id=1452) from the CVS...;) Just put it in the ffdshow directory and test it.
Thank you for your effort, but it crashes when i want to encode with it. And another thing is that we cannot use the 2-pass RC if only the dll is updated, since the older ffdshow doesn't have it in the GUI.
Kurtnoise
29th September 2004, 17:30
arff yes. Sorry :( I haven't test it.
Stay tune...
virus
30th September 2004, 01:25
Originally posted by Tommy Carrot
And another thing is that we cannot use the 2-pass RC if only the dll is updated, since the older ffdshow doesn't have it in the GUI.
yep. also the new options for subpel refinement (level range from 0 to 5) would require a new GUI element.
colin.findlay
30th September 2004, 04:19
Sorry if this is a little off-topic, but does anyone know if it's possible to force Windows Media Player 9+ to use the ffdShow audio MP3 decoder by default? WMP seems to only use l3codeca.acm, and not even try to use any of the directshow filters.
It's bizzare....
LigH
30th September 2004, 08:53
Since I know why, I would never install any newer MS-WMP version, but rather use really powerful media players instead (like Media Player Classic, VideoLan Client, ZoomPlayer, BSPlayer, The Core Media Player, ...) - I can control them as I decide, and they don't phone home.
You may try to disable or even uninstall this outdated MP3 codec (Control Panel, Sound & MM, Audio Codecs...). If this makes problems, you may re-install the Radium codec afterwards. And if you decide to substitute it, you may try the LAME ACM (RareWares, MP3, latest stable pack, right-click on .INF, Install).
DKDIB
30th September 2004, 11:38
LigH wrote:
> [...] if you decide to substitute it, you may try the LAME ACM
> (RareWares, MP3, latest stable pack, right-click on .INF, Install).
lameACM is not an audio decoder (unlike other implementations of LAME).
LigH
30th September 2004, 13:13
You mean, it is an "encoder only"? It does not contain mpg123 for decoding MP3? - Well... Is there a MAD "decoder only" ACM codec? :p
Anyway: For playback, a DS filter shall be enough, and for conversion, better use import plugins of your favourite editor, BeSweet/HeadAC3he for direct conversions, or MAD bundle for HQ decoding to WAV.
aketon
2nd October 2004, 16:47
Originally posted by virus
yep. also the new options for subpel refinement (level range from 0 to 5) would require a new GUI element.
I believe that x264 must start have its one GUI! Using ffdshow to encode isn't something I really like! Unfortunately I don't know anything about programming to make one and the only person that I know who made a GUI ("Justin Clay" I thing) has stopped! I hope that someone can spend some time to make a new one with the new options on it!!!
Sirber
2nd October 2004, 16:49
FFDshow ain't that bad. Just get used to it. Less troubles :)
Tommy Carrot
2nd October 2004, 17:44
Originally posted by aketon
I believe that x264 must start have its one GUI! Using ffdshow to encode isn't something I really like! Unfortunately I don't know anything about programming to make one and the only person that I know who made a GUI ("Justin Clay" I thing) has stopped! I hope that someone can spend some time to make a new one with the new options on it!!!
Oh, FFDShow does have the subpel refinement option (and IMO there is nothing wrong with the ffdshow GUI), just a build from it has not been released so far. But don't worry, you don't miss too much, the new option doesn't make wonders, i couldn't see any significant quality gain with subpel ref. 5. Not to mention that the h.264 encoder of the current cvs version is severely buggy (i don't know if this is x264's or ffdshow's fault).
aketon
2nd October 2004, 18:44
Originally posted by Sirber
FFDshow ain't that bad. Just get used to it. Less troubles
Originally posted by Tommy Carrot
Oh, FFDShow does have the subpel refinement option (and IMO there is nothing wrong with the ffdshow GUI), just a build from it has not been released so far. But don't worry, you don't miss too much, the new option doesn't make wonders, i couldn't see any significant quality gain with subpel ref. 5. Not to mention that the h.264 encoder of the current cvs version is severely buggy (i don't know if this is x264's or ffdshow's fault).
It is not just that! I know some poeple that don't really like to use ffdshow (because when they see all these stuff in it, they find it difficult, they see it difficult)! They prefer to have each one codec installed separately in their system from the others! It has to do with how a simple user see it!!! I can't explain exactly what I fully want to say (because my english are not very good), but I think that you can understand what I am trying to say!:rolleyes:
Simple things are better to use! All in one things are difficult!(from the newbie aspect)!!!;)
SeeMoreDigital
2nd October 2004, 18:56
Can anybody confirm whether FFdshow's Mpeg1/2 decoder filter is able to auto DAR content correctly?
Cheers
Sharktooth
3rd October 2004, 15:49
No new builds since august... uhm...
athos
3rd October 2004, 20:09
New build up @ SF.
BoNz1
3rd October 2004, 20:49
Originally posted by athos
New build up @ SF.
Cool :cool: 2-pass x264 encoding :).
Sirber
3rd October 2004, 20:52
I just checked this morning :(
http://prdownloads.sourceforge.net/ffdshow/ffdshow-20041003.exe?download
BoNz1
3rd October 2004, 20:56
Originally posted by Sirber
I just checked this morning :(
http://prdownloads.sourceforge.net/ffdshow/ffdshow-20041003.exe?download
Yeah, it isn't there but it is in the changelog :(.
SeeMoreDigital
3rd October 2004, 22:13
Just installed ffdshow-20041003
Is it just me, or is Mpeg1 and Mpeg2 decoding b0rked :(
DTS works nicely though!
Sirber
3rd October 2004, 23:10
Is x2674 updated? Haven't a chance yet to install it. I'm in the middle of an encoding :(
SeeMoreDigital
3rd October 2004, 23:35
Originally posted by Sirber
Is x2674 updated? Dunno about x2674 my friend ;). But here's what Doom9 says about the changes: - ffdshow 20041003 (http://osdn.dl.sourceforge.net/sourceforge/ffdshow/ffdshow-20041003.exe) contains more than a long page of release notes (https://sourceforge.net/project/shownotes.php?release_id=272514) (as compared to the August 8th release I previously had for download).
We're basically talking about improved MKV and OGM support, various improvements in the subtitle area, support for Nero MPEG4 video, AAC audio support using Nero file source, x264 improvements (a H.264 codec) and the latest libavcodec is being used
Cheers
Tommy Carrot
3rd October 2004, 23:38
Originally posted by Sirber
Is x264 updated? Haven't a chance yet to install it. I'm in the middle of an encoding :(
Yes, there is the new subpel refinement option, but still no 2-pass. However, "more iterations" mode (the slowest subpel ref. mode) seems to be borked, ugly artifacts appear with it sometimes. The default mode (the second) seems to be ok though. I didn't try the other modes yet, so i can't comment on them.
netchris
4th October 2004, 00:09
Yes x264 is updated compared to the ffdshow built of 28/8/04.
Two pass is not available yet.
Some days ago Tommy Carrot (if I remember correctly) posted an ffdshow built. The built was removed some hours later, but I played with it and the x264 codec had some encoding bugs - white blocks appearing randomly, when using anything else than halfpel.
The next day I finally managed to compile on my own the ffdshow code (the 2/10/2004 one), and my built does not have these encoding bugs whatever subpel refinements I choose, but it is quite slower. Testing now the new 03.10 built and the encoding bugs are back (with the speed being as fast as tommy carrots).
The speed difference can be because i did not use any cpu optimazations (I dont know how), or because i got too many warnings when building the code. I used the visual studio net compiler.
I dont understand why the bugs are back,I guess they used older x264 code than the 2/10 one but cant understand why they would use older code.
Anyway the encodes made with my built are very nice, I can only hope the two pass option will make x264 more competitive.
Thanks for your time :)
*********************************************
update : Yes Tommy I am talking abouth these artifacts that are not present in my built
colin.findlay
4th October 2004, 00:55
Now, the reason I want WMP to use the ffdshow audio decoder is 2-fold.
a) I'm using a HTPC solution (mediaportal) which integrates with WMP only at this point.
b) I'd like ffdshow to auto-load a different preset for mp3 files. In this case 2.0 stereo out for mp3/wma/ogg & 2.0 stereo mixed to 5.1 out for any other stereo source. (ie. divx with mp3)
I may just end up assigning the presets to hot keys (if poss) and setting up my remote so I can manually switch (not nearly as cool)
BTW. You can replace the ACM with others, but what I would really need is an ACM wrapper for ffdshow with decode-only support, and maybe encoder pass-thru.
Regards
C.
Originally posted by LigH
Since I know why, I would never install any newer MS-WMP version, but rather use really powerful media players instead (like Media Player Classic, VideoLan Client, ZoomPlayer, BSPlayer, The Core Media Player, ...) - I can control them as I decide, and they don't phone home.
You may try to disable or even uninstall this outdated MP3 codec (Control Panel, Sound & MM, Audio Codecs...). If this makes problems, you may re-install the Radium codec afterwards. And if you decide to substitute it, you may try the LAME ACM (RareWares, MP3, latest stable pack, right-click on .INF, Install).
Tommy Carrot
4th October 2004, 01:44
Originally posted by netchris
update : Yes Tommy I am talking abouth these artifacts that are not present in my built
If they didn't occured in your build, i suspect that using the cpu optimizations at compilation causes this bug, since the x264 code wasn't touched in the last few days, probably that's the only difference between the 2 builds.
Edit: ok, i was wrong, there were changes in the x264 code 3 days ago, but i still stay with my opinion that using too strong optimization settings at compiling can cause those bugs.
obieobieobie
4th October 2004, 13:36
This latest ffdshow seems to crash the Windows Explorer shell when viewing a folder with video files.
aketon
4th October 2004, 14:16
Originally posted by Tommy Carrot
Yes, there is the new subpel refinement option, but still no 2-pass. However, "more iterations" mode (the slowest subpel ref. mode) seems to be borked, ugly artifacts appear with it sometimes. The default mode (the second) seems to be ok though. I didn't try the other modes yet, so i can't comment on them.
But in the changelog:
2004-09-09 20:20 milan_cutka
* x264 two pass encoding
:confused: :confused: :confused:
marcellus
4th October 2004, 14:39
Although the change log says this:
2004-09-06 08:37 milan_cutka
* use avisynth filter again
2004-09-06 08:30 milan_cutka
* use avisynth filter again
avisynth filtering inside ffdshow is still not working. Last working version was 20040808.
And I really need this.
:( :( :(
Edit:
To give more details:
-When I use it via vfw interface for realtime captures avisynth filtering simply does nothing
-When I open files via MPC (directshow interface) avisynth filtering does nothing and it shows this error on screen:
http://img59.exs.cx/img59/2360/snapshot_01.jpg
Edit 2:
Forgot to mention that is not particular script related, the simplest script like invert() or Info() triggers the error
aketon
4th October 2004, 14:55
At least, with this new build, I can encode to theora again!:)
Leak
4th October 2004, 19:53
Originally posted by marcellus
Although the change log says this:
avisynth filtering inside ffdshow is still not working. Last working version was 20040808.
And I really need this.
I'd assume he was writing about the AviSynth filter that's now included with ffdshow so you can use ffdshow's functions in AviSynth instead of the other way round. Of course, a fixed AviSynth support in ffdshow would be very nice too...
np: Yoko Kanno - Cream (Ghost In The Shell Stand Alone Complex OST Be Human)
marcellus
4th October 2004, 21:11
I'd assume he was writing about the AviSynth filter that's now included with ffdshow so you can use ffdshow's functions in AviSynth instead of the other way round.
Yes, that passed thru my mind too.
Of course, a fixed AviSynth support in ffdshow would be very nice too...
For me is a must. And I don't understand why got broken, for long time, untill version 20040828, it worked fine. If I copy ffdshow.ax ver. 20040808 over the current one it works for my purpose but it's not 100% safe, strange things could happen anytime.
I use ffdshow with my TV capture program to encode real time mpeg2 (SVCD as target resolution). This task is very demanding for my CPU so to be sure I don't have dropped frames I must use this chain:
Capture(704*576)->
(ffdShow)Crop(656*512)->
(ffdShow)Resize(448*512)->
(ffdShow)denoise3D->
(avisynth)[Decomb(eliminate phase shift)->KernelDeintMMX->AddBorders(480*576)]->
(ffdShow)Encode
This way intensive tasks as denoising and deinterlacing are made on a 448x512 picture.
The last part, especially Decomb and AddBorders I can't do it with FFDshow's filters, so I have to do it in AviSynth.
Of course I could do it at a later encode but my purpose is to obtain a SVCD compliant mpeg2 file without the need of a reencode (at least the video part), I'm pretty happy with the quality and I don't want to spend more CPU time for my every day quick and dirty captures.
To dream a little, I wish we could put in ffdshow 2 or more instances of one filter, for example I could use denoise3d after deinterlace and before addborders (so I would have to use avisynth 2 times).
virus
5th October 2004, 11:50
Looks like x264 2-pass is available, but not in the usual way. Here's what Milan wrote on SourceForge after I've submitted my requests:
by Milan Cutka:
x264 uses its own two pass algorithm which is similar to libavcodec's and so is the way to use it.
To do the first pass, select constant quantizer (preferred) or constant bitrate and on the Ouput page select Write from "Libavcodec stats" group (sorry, forgot to add x264). In the edit box below you can enter first pass stats file name. For second pass, select constant bitrate and select "Use"
from "Libavcodec stats group. Sorry, I know this isn't very user friendly, but it's because ffdshow's own two pass routines can't be used.
SeeMoreDigital
5th October 2004, 12:07
Originally posted by obieobieobie
This latest ffdshow seems to crash the Windows Explorer shell when viewing a folder with video files. Yes, I've noticed this too!
As soon as I have H.264 "libavcodec" enabled and go a hunting for my h.264 encodes, I receive a "Windows Explorer" warning...
Cheers
obieobieobie
5th October 2004, 14:46
It is added to the bugtracker over at the ffdshow sourceforge project page. Milan posted a new build (requires an sse capable cpu) which has fixed the problem at least for me.
link to bugthread (http://sourceforge.net/tracker/index.php?func=detail&aid=1039593&group_id=53761&atid=471489)
Stereodude
5th October 2004, 22:01
Any change FFDShow can be fixed to read the aspect ratio from Matroska files correctly?
I have 3 computers and only on 1 of them does FFDShow correctly use the aspect ratio / display size value in the .MKV even though the same exact software and filters are used on all 3.
SeeMoreDigital
5th October 2004, 22:31
Originally posted by Stereodude
Any change FFDShow can be fixed to read the aspect ratio from Matroska files correctly?
I have 3 computers and only on 1 of them does FFDShow correctly use the aspect ratio / display size value in the .MKV even though the same exact software and filters are used on all 3. What streams have you muxed into MKV?
The current build can't correctly AR Mpeg1 or 2. I've also tried FFdshow with anamorphic 3ivx, XviD, Nero and DivX Mpeg4 streams, in both AVI and MKV. And sadly it does not work!
So for me, I'm sticking with one of XviD's test DSdec filters with auto AR detection!
Cheers
Stereodude
5th October 2004, 23:20
Originally posted by SeeMoreDigital
What streams have you muxed into MKV?
The current build can't correctly AR Mpeg1 or 2. I've also tried FFdshow with anamorphic 3ivx, XviD, Nero and DivX Mpeg4 streams, in both AVI and MKV. And sadly it does not work!
So for me, I'm sticking with one of XviD's test DSdec filters with auto AR detection!
Cheers
I was doing Anamorphic 1080x720 xvid decoded to 1280x720 with AC3 audio. It works on one of my computers with FFDShow, the other 2 do not play it back correctly with FFDshow. They all work fine with using the official 1.02 xvid decoder.
SeeMoreDigital
5th October 2004, 23:35
Originally posted by Stereodude
I was doing Anamorphic 1080x720 xvid decoded to 1280x720 with AC3 audio. It works on one of my computers with FFDShow, the other 2 do not play it back correctly with FFDshow. They all work fine with using the official 1.02 xvid decoder. If you're re-encoding you're source to 1280x720 (with square) pixels then the encode is no longer anamorphic. It's a "true 16:9 frame" encode!
Cheers
Stereodude
6th October 2004, 04:03
Originally posted by SeeMoreDigital
If you're re-encoding you're source to 1280x720 (with square) pixels then the encode is no longer anamorphic. It's a "true 16:9 frame" encode!
Cheers
As I said I am encoding to 1080x720, and playing back at 1280x720. That is anamorphic.
SeeMoreDigital
6th October 2004, 10:28
Sorry my mistake!
1080x720 seems a rather odd source size. How did you manage to arrive at it?
Cheers
virus
6th October 2004, 15:28
OK, about x264: I've tested both ffdshow-20041003 and ffdshow-20041005-sse and both have the "blocking bug" when subpel refinement is set to something different than "hpel only".
It has been suggested that the problem may be due to compiler optimizations. So: what compiler has been used for those builds? What compiler flags? Is there a way to have a different build with different compiler/params to test it? At least, if we understand where the error actually is, we will be able to submit a bugreport...
some help please? :)
celtic_druid
7th October 2004, 06:48
http://celticdruid.no-ip.com/test/ff_x2641.7z
http://celticdruid.no-ip.com/test/ff_x2642.7z
First one I tried and it looked fine. Second one I don't know but it should be faster.
http://celticdruid.no-ip.com/test/ff_x2643.7z
http://celticdruid.no-ip.com/test/ff_x2644.7z
http://celticdruid.no-ip.com/test/ff_x2645.7z
http://celticdruid.no-ip.com/test/ff_x2646.7z
virus
7th October 2004, 10:57
thank you celtic_druid, I'm currently testing your 2nd build and the results seem strange to me. 95% of the blocks are gone but not all! There are still very few small artifacts... I'm trying to narrow down the problem and test more.
Anyway the PSNR results for x264 start to be pretty good (better than XviD). I'll report back on the x264 development thread about them later.
netchris
7th October 2004, 14:19
Thanks a lot celtic_druid!
The first and second builds are fine,they have exactly the same behaviour as my builds, so they are slow but block-bug free.
The files from 3 to 6 are twice as fast but they all have the block-bug.
What did you change in these builds?
95% of the blocks are gone but not all! There are still very few small artifacts...
The artifacts you see might be unrelated to the bug. I believe they are encoder immaturities.
Also the last mplayer/mencoder build that I did has x264 enabled. Build is optimised for athlon-xp's though.
could you please provide a link for the mencoder build?
celtic_druid
7th October 2004, 14:33
2nd build should be reasonably fast. Think it was ICL 7.1 with /O3 /G6 /Qipo /Qunroll /QaxiMK
3rd one was I think -O4 march=pentiumpro mtune=pentiumpro -pipe -ffast-math -fomit-frame-pointer
4th was basically default without -funroll-loops
5th was basically default without -finline
6th was basically default without -finline-functions
Here ya go:
http://celticdruid.no-ip.com/test/ff_x2647.7z
gcc without march, ffast-math or anything.
Hmmm, hang on I don't think that the MSVC project files have nasm enabled. Perhaps that is where the problem lies? Would also explain the speed difference.
netchris
7th October 2004, 14:55
The 7th build is slow again (a little faster than second) but without the block bug.
Hmmm, hang on I don't think that the MSVC project files have nasm enabled. Perhaps that is where the problem lies? Would also explain the speed difference.
I hope you are right so that we find the source of all evil.
virus
7th October 2004, 15:07
things start getting damn messy... 2nd build as before, but this time I've rised max ref. frames from 1 to 3... and guess what? A blockfeast! Even big blue blocks on white water... :(
I'm gonna check the 7th build with the same settings to see what happens. Right now the "bad" options are subpel ref. 4 ("qpel on all") + max ref. frames 3 + CABAC + in-loop filter + all analyze flags on.
@netchris: could you please try to re-encode with the settings above and see what happens?
netchris
7th October 2004, 15:20
I tried 2nd and 7th build that seem identical in quallity, with the options you asked but i dont see any problems here. I always used 3 reference frames. Subpel ref. 4 as well as 5 are clean in my tests.
Maybe there is something wrong with reference frames?(i doubt it)
I'll be gone for some hours so no more tests till then.
celtic_druid
7th October 2004, 15:48
Definatly no asm in the msvc project files. I couldn't get it to compile with asm when I added it either. Build 7 has asm, just no gcc opts so if 7 is ok then it isn't a problem with the asm anyway.
virus
7th October 2004, 19:49
Tested build 7. No way...
I believe it's a decoding problem. I've verified it under VDub and MPC. Seems to happen when you watch the "buggy" scene, go backwards and then rewatch the same scene. First display is OK, the 2nd is a blockfeast. According to a failed assert thrown by Vdub during decoding, the culprit may be libavcodec (or maybe the libavcodec sources embedded in ffdshow). More later.
Tommy Carrot
7th October 2004, 20:54
Originally posted by virus
I believe it's a decoding problem.
Definitely not, because the corrupted blocks are still there with the ateme decoder filter.
I checked build #1, and while it's slow as hell, at least it's working correctly (except the upper-left corner underquantizing problem).
netchris
7th October 2004, 21:08
It is not a decoding problem, when you have disabled 264 decoding support in ffdshow and decode it with nero's decoder the problem remains.
First display is OK, the 2nd is a blockfeast. According to a failed assert thrown by Vdub during decoding, the culprit may be libavcodec
what do you meen? In the first display the picture is ok? (without white block bug?)If that is the case, then there is a decoding bug that is unrelated to the white blocks. Appart from the decoding bug, the white blocks are definatelly an encoder's bug.
The problem must lie somewhere in icl's optimizations. I compiled with msvc(version 2003)choosing different options (with and without optimizations) and there never is a white block bug.The only problem is the resulting x264 dll is always quite slow (about as slow as builts 2 and 7). I also tried compiling with mingw-msys an the resulting dll is as fast as icl's fast builds but it also has the white blocks (though the bug might be less frequent with mingw,i am not yet sure about this).
I Also agree that nasm is not the problem as when compiling with msvc it is always enabled (though I dont know if it is being used by the code).
******************************************************************
I apologise in advance if I say something stupid,because I have no previous experience with the compilers, I am currently learning many basic stuff, thanks to x264 :) .
So if i dont make sense in some cases please be patient and you are welcome to correct me.
edit :
Tommy I didn't see your post while I was writing mine :) nice timing
virus
7th October 2004, 21:39
oh well, let's start from scratch then :rolleyes:
Let's say the decoding troubles are just a consequence of a broken bitstream then. I've tried to cut the video at the keyframe just before the Bad Things kick in... when I open the resulting clip VDub says that the first frame is bad, the rest good but undecodable (of course!).
But if I cut it a bit early everything works... and the bad blocks only appear if you go forward and backwards when decoding... well, in fact the decoding is rather unpredictable. Sometimes it displays almost no blocks, sometimes a lot of big bad blocks :rolleyes:
Anyway: build 2 and 7 both have the problem for me. Build 2 is ICL, build 7 is gcc... so it cannot be a bug in the compiler I'd say. I'll give a shot at build 1, then I'll try to invent something different.
:confused:
virus
7th October 2004, 23:04
All attempts failed miserably. Same problem.
Here's a sample (http://www.webalice.it/riccardo.stievano/video_stuff/x264-b0rked.avi) (930 KB) of my troubled clip, encoded with celtic_druid's build #1.
If you decode it starting from the 1st frame, you should not see any blocks (though I have the impression that some artifacts still lurk somewhere, I should make a frame-by-frame comparison with the source for that). BUT if you decode starting from the second keyframe, bad blocks should appear. If they don't appear, try going forward and backwards and then restart decoding again from the 2nd keyframe. I've checked that with both VDub and MPC.
I hope some of you can confirm what I'm seeing here.
No clue about what's going on. :(
snacky
7th October 2004, 23:13
That's not an encoder bug.
In H.264, a p-frame can be predicted from multiple previous reference frames, including (possibly) frames preceding the last iframe. This is the case for the first i-frame in your sample video. This particular i-frame shouldn't be used for seeking directly to, and shouldn't be used as a keyframe.
virus
7th October 2004, 23:34
Originally posted by snacky
This particular i-frame shouldn't be used for seeking directly to, and shouldn't be used as a keyframe.
Are you saying that seeking/cutting reliably in H.264 is impossible if you use multiple ref. frames?
If you don't seek to a keyframe, where are you supposed to seek then?
This won't explain the blocks some of us saw using different builds, though. I've seen blocks appear in the middle of a 1000 frames long sequence, decoding from the start (see the scrshots in the x264 thread). Others reported similar problems. Maybe 2 different issues?
netchris
7th October 2004, 23:56
I've seen blocks appear in the middle of a 1000 frames long sequence, decoding from the start (see the scrshots in the x264 thread). Others reported similar problems. Maybe 2 different issues?
Please dont mistake it with the white blocks bug. This is an encoding bug, and what you mention is a decoding one. Two seperate bugs. I understand why you mistake them, they produce a similar effect so it might be confusing.
And one question gcc = mingw? isn't gcc linux only?
akupenguin
8th October 2004, 02:11
Originally posted by virus
Are you saying that seeking/cutting reliably in H.264 is impossible if you use multiple ref. frames? No, but the seeker/cutter has to distinguish between an I-frame (can be decoded independently, but says nothing about the following frames) and and IDR-frame (which is an I-frame that is guaranteed to be seekable)
Originally posted by netchris
And one question gcc = mingw? isn't gcc linux only? gcc has been ported to everything under the sun. mingw ("Minimalist GNU for Windows") is one such port.
Stereodude
8th October 2004, 02:26
Originally posted by SeeMoreDigital
Sorry my mistake!
1080x720 seems a rather odd source size. How did you manage to arrive at it?
I used the native content ratio as DVDs do 1.5:1 which gets anamorphically stretched to 1.78:1.
virus
8th October 2004, 09:29
Originally posted by akupenguin
No, but the seeker/cutter has to distinguish between an I-frame (can be decoded independently, but says nothing about the following frames) and and IDR-frame (which is an I-frame that is guaranteed to be seekable)
uhm, I can foresee several problems because of this. No tool that I know of make such distinction (but maybe bond can say something more on that :))
Is there an option in x264 to avoid that P-VOPs reference frames before the I-VOP they depend on? Something similar to "closed GOV" for XviD? Maybe it would be useful.
Alvy
8th October 2004, 09:38
Versions before I controlled ffdshow via girder with keyboard commands.
This does not work any more.
I tried all options like "remote control api" and "accept keyboard messages".
Is there a way to get this to work or is that a bug :confused:
akupenguin
8th October 2004, 10:11
Originally posted by virus
uhm, I can foresee several problems because of this. No tool that I know of make such distinction (but maybe bond can say something more on that)
If the tool is H.264-aware, it's trivial to make the distinction by looking in the slice-header. Of course, no existing codec-agnostic tool does so, because the distinction didn't exist before H.264.
And as long as the muxer is H.264-aware, the demuxer/seeker doesn't need to be: You just mark non-IDR I-frames as not keyframes (because they really aren't).
Is there an option in x264 to avoid that P-VOPs reference frames before the I-VOP they depend on? Something similar to "closed GOV" for XviD? Maybe it would be useful.
GOVs are already closed. It's just that 1 GOV can contain multiple I-frames.
To answer your question, set IDR interval = 1. (may also be called idrint or idrframe, I don't know what the ffdshow interface looks like.) That will force every I-frame to be IDR.
... Come to think of it, I can't see any function in non-IDR I-frames, except in the rare case of (scene 1)(scene 2)(scene 1) where scene 2 wants an I-frame, but the return of scene 1 could use a long-term reference instead of another I-frame. Still, the codec would have to be smart enough to look that far ahead. And for that matter, you only lose a small overhead for using a P-frame full of I-blocks instead of an I-frame.
virus
8th October 2004, 10:46
akupenguin, every time you post we learn something new about H.264 :)
I've opened a feature request item on Sourceforge to have the "IDR interval" option added to the ffdshow GUI (it's not available right now) along with the "deblock{alpha|beta}" one which is missing as well.
snacky
8th October 2004, 11:04
Originally posted by akupenguin
... Come to think of it, I can't see any function in non-IDR I-frames, except in the rare case of (scene 1)(scene 2)(scene 1) where scene 2 wants an I-frame, but the return of scene 1 could use a long-term reference instead of another I-frame. Still, the codec would have to be smart enough to look that far ahead. And for that matter, you only lose a small overhead for using a P-frame full of I-blocks instead of an I-frame. [/B]
I have an interest in encoding video game replays, and in this specialized field, non-IDR I-frames are probably useful quite often. Very large flashing objects or sections sometimes occur, and the flashing alone can trigger scene changes. Much more commonly (but also less importantly), meters, counters, and icons usually persist unchanged across genuine scene changes.
akupenguin
8th October 2004, 11:23
That gives me an idea... whereby the first pass uses no IDR frames, but records how many times each frame uses each reference. Then the second pass can decide which I-frames should really be IDR (most of them, so you don't sacrifice seeking) but lose no efficiency on snacky's flashes (or even force them to be P, if necessary).
yaz
8th October 2004, 12:53
Originally posted by akupenguin
That gives me an idea... whereby the first pass uses no IDR frames, but records how many times each frame uses each reference. Then the second pass can decide which I-frames should really be IDR (most of them, so you don't sacrifice seeking) but lose no efficiency on snacky's flashes (or even force them to be P, if necessary). yep, a kinda auto-idr-ing would be quite beneficial. just like vhq in xvid :-) for simpletons like me it's pretty hard to set a reasonable idr. anyway i doubt that there'd be any good way of it other than analysing the 1st pass.
the bests
y
ps can anyone outline me how's this x264 development going on now? officially x264 is a part of the vlc project but vlc itself provides the less encoding options (at least in the wizzard) ffvfw offers much more but it has serious implementation problems (say, the gui does not accept a/o sets options properly) mencoder gives the more options (including some very exotic stuffs like 3pass encoding and such) but some of them have been never mentioned anywhere else. so, how's it all going ?
skynetman
8th October 2004, 13:15
I have got BIG problems with ffdshow-20041003.
Some movies have a strange "colorizing" effect that changes image color balance from standard, to red, to green, to blue without any reason an repeatedly within few seconds .
I just launched gspot for some testing.
Current problematic AVI is XVID with packed bitstream.
Same problem with simple MMX or XVID IDCT , with both postptrocessing and picture properties on and off (obvioulsy colorizing option is always set to zero).
I'll check for other avi with same problems to see if it is xvid related.
virus
8th October 2004, 15:05
@celtic_druid
here are the PSNR scores for the 3 builds I've tested. Same material, same encoding params, decoded once from the start so to avoid any problems with non-IDR frames.
build 1: 43.3490 dB
build 2: 43.3490 dB
build 7: 42.0704 dB
So, first 2 are OK, while build 7 has problems... no, not big blocks, but a generalized poor quality on some sections (with PSNR falling below 38 dB!). So maybe it's gcc with ASM the culprit then?
netchris
8th October 2004, 16:23
:D :D :D :D :D :D :D :D
OK virus I found whats wrong.
The problem is with the -O3 option.
You have to use -O instead and you get a dll than encodes fast and without the white blocks bug.
If you use -O2 the white blocks reappear.
If you dont use the -Ox at all the encodes are white blocks-free but they are as slow as builds 1,2,7.
All the other options (-funroll-loops, -finline-functions -mtune -march etc) have no relation to the white blocks
So just use -O :cool:
(The compiles were made with mingw-msys)
akupenguin
8th October 2004, 19:34
A nice constrast to libavcodec, which fails to compile with anything less than -O2. :D
You might also try running the 'checkasm' tool in x264 svn. It was presumably designed for detecting this sort of situation?
virus
8th October 2004, 23:30
Don't get me wrong, but I still have some doubts. I'm really just presenting my opinion, and I have no real proof that things are as I think they can be.
If there's something that I've learned in the last 7 years using gcc, is that gcc almost never fails when doing basic optimization of some C code. To be more precise: I've never seen -O2 produce b0rked code on my programs with -O1 solving the problem. And when -O2 failed, it was because of my errors... you know, sometimes bugs are not exposed until the code gets really and deeply optimized, instructions reordered, redundant expressions eliminated, and so on. Again, I might be wrong, but I'm still not 100% sure that the error actually comes from gcc itself.
just my 2 cents
netchris
9th October 2004, 02:06
Since virus you have the experience please try to make your own builds with -O and the other options, and prove me right or wrong.
I would like to give you my build, so you can test it but it seems that attachements here are not working, and I dont have any free web space to upload it.
I didn't change anything in the code, I took what was given by the ffdshow and x264 team and played with it. It was trial and error.
The point is that in the current state even if there is something wrong with the code, there is a workaround to achieve a fast build without the white blocks bug.
celtic_druid
9th October 2004, 08:45
8th build up, with -O
virus
9th October 2004, 12:25
@celtic_druid:
build 8 works OK, thank you. I've crosschecked build 7 and 8 to see what was wrong. It turned out that the "broken" build 7 encode uses higher QPs on some scenes (example: 21-22 instead of 20). The picture looks OK, just with a slight detail drop. Don't ask me why this happens.
@netchris:
uh! oh! don't be so upset :)
I do appreciate that you found a workaround. And I'm not trying to "prove you wrong"... I'm just outlining a possible source of the problem, maybe unlikely, but still possible. And no, whatever the error is, you're not the culprit ;)
EDIT: btw, Milan has already added the GUI options I requested yesterday... what a speedster :)
netchris
9th October 2004, 14:09
@celtic_druid
Has the 8th build been removed? I dont see it.
@virus
Sorry I sounded like this, I was a little drunk yesterday so I was maybe a little harsh,but i didnt feal offended or upset.
I have a lot of respect for you virus as well as for celtic_druid and akupenguin (and all the other members of the community).
:thanks: for your time, efforts and explenations!
celtic_druid
9th October 2004, 14:38
There never was a link for me to remove.
I didn't bother posting a direct link to 8... kinda figured that people could just swap an 8 with one of the other links.
Kurtnoise
12th October 2004, 18:38
ffdshow_20041012 is out on SF (http://sourceforge.net/projects/ffdshow) !!! Available in 3 versions (Normal, SSE and SSE2).
Changes:
MS ADPCM support
two preferred vobsubs languages
configurable swscaler gaussian blur strength for vobsubs
support bmp and gif as bitmap overlay image
option to use WAVEFORMATEX instead of WAVEFORMATEXTENSIBLE on output if no custom channelmapping
bug fix: don't always recompute letterboxing size and don't always check for subtitles file
more blending modes
IDR interval and deblock parameters for x264
working on image overlay
vobsubs scaling
proper alignment in ICL+GCC libavcodec build
key shortcut for subtitles language cycling
possibilty to override vobsubs position
dwstring substr and c_str related fix
recognize cz for Czech in idx, don't show duplicate languages in vobsub config
don't set merit to "not used" if it previously had different value than one of defined in ffdshow
yet another fix in corrections
another subtitles correction fix
fix in capital letters correction
more keys working
keyboard shortcuts and remote messages for cycling presets
orthography correction from subrip
separate page for text subtitles options, more complete subtitles correction from Subrip
adding text subtitles correction from subrip
support for 8-bit samples on input
fixed another crash in vobsub
fixed crash in getNext with pictFull==true and pictHalf==true
enabled trellis quantization for H.263(+)
Notes:
This build should fix Windows XP explorer crashes.
Three editions are available: special for SSE and SSE2 capable CPUs and generic for all others.
SSE a SSE2 build were compiled using Intel C++ Compiler 8.1, generic build was compiled with Microsoft VC6.
Known bug: in SSE and SSE2 builds Avisynth image processing filter in ffdshow isn't working.
Subtitles correction may not work correctly in all cases (but should not crash).
These feature was ported from SubRip and if SubRip will give different resulf for a given subtitles, please send them to me.
Inc
13th October 2004, 11:59
First I do apologize in andvance if some questions now of mine have been already treated in here BUT the browsing/searching through this forum actually is a pain via t-online provider in germany as it seems.
These following questions do refer to the last ffdshow version BEFORE this actual release of 2004/10/12! Im at work on a MAC and just found this new release of 20041012 in here, so I cant test it right now.
1. A Makeavis generated "AVIS" AVI wont be decoded in an fvw decoding environment like Vdub or CCE, even if it has benn set in the vfw configuration of ffdshow (decode Avisynth AVIS). In an Dshow decoding environment its no problem.
2. Also according to vfw decoding environments: If in ffdshows vfw decode setup a decoding of for instance RAW YV12 decoding has been setup, Vdub still uses my XVID decoder in the informations Box of Vdub when decoding an avsiynth .avs with an outgoing YV12 colorspace (same thing in case of other outgoing colorspaces as FFdshow/vfw wont be used in Vdubor CCE).
If for instance capturing an AVI by using "FFDS" FourCC in ffdshow via VirtualVCR .... VirtualDub does decode that one via FFdshow/vfw! BUT no filtering within ffdshow's vfw setup will be performed. I have to do a Graphedit .grf workout via Directshowsource() to get filtering via ffdshow enbaled when opening an avs in vdub.
3. When trying to use Avisynth filtering within! ffdshows filter section, it doesnt work anymore. An access violation error is reported by avisynth WITHIN ffdshows decoding when doing the preview of that via ffdshow decoded AVI file.
I do love ffdshow! But to me it seems beside some very nice additions in new releases, there are some risks that things of the past wont work anymore as for instance Forcc "AVIS" decoding via Vdub or CCE never was a Problem when using the old FFvfw from autum of 2003 for instance.
Thanks a lot in advance!!
Inc.
Leak
13th October 2004, 13:00
Originally posted by incredible
3. When trying to use Avisynth filtering within! ffdshows filter section, it doesnt work anymore. An access violation error is reported by avisynth WITHIN ffdshows decoding when doing the preview of that via ffdshow decoded AVI file.
This seems to be a problem caused by compiling ffdshow with Intel's C compiler; it should work in the latest ffdshow version without SSE/SSE2 optimizations - see here (http://ffdshow.sourceforge.net/tikiwiki/tiki-read_article.php?articleId=12) and here (http://sourceforge.net/tracker/index.php?func=detail&aid=1040852&group_id=53761&atid=471489)...
np: Vladislav Delay - Anima E (Nohuume)
pogo stick
13th October 2004, 16:27
Is it just me or new ffdshow is not appearing in VDub's encoders list? :confused:
netchris
13th October 2004, 16:35
I have the same problem with the latest build, so I after i istalled it, I copied the ffdshow's files to a temp folder, then uninstalled it.
I installed an older build that doesnt have this problem, and copied the files from the temp folder to the ffdshow folder, to replace the old ones with the new.
stephanV
13th October 2004, 16:42
doesnt show up here either
celtic_druid
13th October 2004, 17:24
Go into your registry and change the vidc.ffds entry to progra~1 instead of "program files". Should sort it.
stephanV
13th October 2004, 17:46
yep, thats it... its weird though
Yong
14th October 2004, 07:15
Can i post the ffdshow audio decoder bug report in here?
yaz
14th October 2004, 09:26
i got the same problem(s!) as incredible.
no way of using 'makeavi' anymore :-((( loading the fake avi into mencoder makes a crash (windows say msvcrt.dll is crashing???) is there anyone succeeding in this business? pls, drop a workaround, if u're aware of any.
avisynthing in ffdshow still seems to crash (or i do in a wrong way?)
thx
y
Leak
14th October 2004, 10:38
Originally posted by yaz
avisynthing in ffdshow still seems to crash (or i do in a wrong way?)
Works for me - what exactly are you doing?
Also, did you make sure to install the unoptimized version? The SSE/SSE2 versions will still crash.
np: Vladislav Delay - Huone (Nohuume)
yaz
14th October 2004, 11:26
Originally posted by Leak
... The SSE/SSE2 versions will still crash ... well. i was playing with the sse ver. i give a try to the non-opt ver. thx for the answ.
thx
y
Inc
14th October 2004, 11:40
Originally posted by yaz
i got the same problem(s!) as incredible.
no way of using 'makeavi' anymore :-((( loading the fake avi into mencoder makes a crash (windows say msvcrt.dll is crashing???) is there anyone succeeding in this business? pls, drop a workaround, if u're aware of any.
avisynthing in ffdshow still seems to crash (or i do in a wrong way?)
thx
y
a) For using avisynth scripting "within" ffdshow it seems that you have to install the generic build - I hadnt time to install the newest for testing till now.
b) Mencoder worked without problems in the past when using ffdshows! Makeavis (I use it via commandline to just go in using an avs into the batch file). I just copied the "old" ffvfw.dll & mplayerlib.dll into the same folder as mencoder.exe and added the description in the codecs.conf file thats it. But as I do remember now ... wasnt it you who gave me that advice? So did something change also related to "this" in the very recent release of ffdshow??? :eek:
yaz
14th October 2004, 12:38
Originally posted by incredible
... wasnt it you who gave me that advice? So did something change also related to "this" in the very recent release of ffdshow??? :eek: yep, it was me ... but yesterday evening it all drove me mad. whatever i tried all i got was a crash in msvcrt.dll. and no reading, of course :-( i'll give it another go this evening. maybe, a 'clean-the-house-before' will help.
i'm just annoyed, becuse the log says 'makeavis support is back'. but for me 'back' means 'away' :-(
the bests
y
Audionut
14th October 2004, 13:01
The latest SEE2 version works fine for me.
Just had to run "regsvr32 c:\**\ffdshow.ax" from the command line.
It appears that it does not register itself.:confused:
http://sourceforge.net/tracker/index.php?func=detail&aid=1046034&group_id=53761&atid=471489
Yong
15th October 2004, 06:26
Here's my ffdshow audio decoder settings,
Format Decoder
MP2 libmad
MP3 mp3lib
AAC libfaad2
Vorbis themor
MSADPCM Libavcodec
IMA ADPCM Libavcodec
FLAC can't work.
Allowed sample format for sound processing:
16 bit integer
Support output sample format:
32 bit float
Floating to integer conversion:
Dithering(Selected), Noise shaping: heavy
When playing AAC ,MP2 ,WMA, and Vorbis with only the 24 bit output sample format selected, the audio will become full of distrosion.
AAC only have problem with 24 bit out.
While MP3 only can work with 16/32 bit float output, when select 24 bit the sound will lowered and full of distrosion, select 32 bit integer out will crash.
Vorbis only can play with the 32bit integer /float ouput but have some distrosion, select 16 bit out will crash.
playing MP2 with 16 bit out will crash.
IMA / MS ADPCM crash with 32 bit integer out.
WMA is work fine but can't properly decode some WMV audio.
Only the 32 bit float is safe to use.
ffdshow video decoder bug:
Playing mpg with ffdshow now can work, but still can't play some video-stream-only mpg file.
Sorry for my english...:stupid:
Mug Funky
15th October 2004, 15:34
w00t! the vobsub functionality is really good.
i'm pushing my machine to it's limit, and it seemed vobsubbing through ffdshow and disabling Dvobsub was just enough to decode in real time.
how's the development of the loading of embedded subs? i'm experimenting with muxing the .idx into a .mkv file, but nothing except media player classic can find these subs, and it renders them too slow.
i'm playing back xvid @ 50fps, 512x384... just to see if i can. i was so sick of field-blends and what to do with them that i just up and smartbobbed the whole thing and encoded it without touching the blends.. . this presents the problem of decoding speed, of course, which is why i'd like ffdshow to do as much of the processing as it can.
i suppose for now i can just leave the .idx and .sub in the same directory, but i find whole files are tidier.
oh, also, yellow subs seem to come out grey...?
APF_Gandalf
16th October 2004, 23:48
Originally posted by Audionut
The latest SEE2 version works fine for me.
Just had to run "regsvr32 c:\**\ffdshow.ax" from the command line.
It appears that it does not register itself.:confused:
http://sourceforge.net/tracker/index.php?func=detail&aid=1046034&group_id=53761&atid=471489
it seems to me that it's the "old" folder name bug that is back. if you install it in a folder without spaces, it works: "c:\ffdshow" works, "c:\program files\ffdshow" fails even if I try to register it myself using "c:\program files\ffdshow\ffdshow.ax" or "c:\progra~1\ffdshow\ffdshow.ax"
I submitted a way to avoid this bug long ago when it first appeared. it worked, but it seems that it was forgotten in the latest official builds.
arman68
17th October 2004, 00:58
Originally posted by Mug Funky
w00t! the vobsub functionality is really good.
i'm pushing my machine to it's limit, and it seemed vobsubbing through ffdshow and disabling Dvobsub was just enough to decode in real time.
Yes, it is coming along very nicely. I did some tests on a P4 2.2Ghz, and VSFilter adds an extra 30% cpu usage, as opposed to VobSub in ffdshow. And that's using swgaussian blur, which is very nice. For the first time I can now use the post-processing options I wanted :D
Seems that the new keyboard shortcut for subtitle cycling are broken, and broke the toggle as well though.
kittychan
17th October 2004, 09:48
yooooo
I am quite happy ffshow can replace the vsfilter.dll and decrease the cpu load ^_- , but I can't play subtitle embedded in .ogm ot .mkv...
I did tick the "accecpt embedded sutitles" box, but no subs appears, so I still have to use vsfilter for .ogm (and .mkv)
Did I do something wrong?
++
kittychan
EDIT : OK my wrong....
I have to set the VRM7 for the video direct show in MPC option...
sorry for having ask ^^
++
2nd EDIT....
re-sorry, when set the VRM7 for the video direct show in MPC option, sub are played by MPC but still not by ffdshow...
I still can not make ffdshow play ogm sub.
++
Mug Funky
17th October 2004, 14:35
there's a little tooltip that says "very incomplete and experimental. Send me samples which don't work".
i'm guessing it'll only do textsub? not sure, but i'm certain it'll be completed soon.
in the meantime you'll have to live with cluttered directories full of .idx and .sub files :)
The Shemeta
17th October 2004, 15:51
hi,
i upgraded to the latest ffdshow-20041012 & now i don't have the vfw when i open a movie in VirtualDubMod.
anyone with the same problem?
the good thing is that if fixed the explorer.exe crash.
esby
17th October 2004, 17:36
@The Shemeta:
you could READ this thread a bit...
Now take this answer, go back 4-5 replies ago, and READ!
esby
therealjoeblow
18th October 2004, 04:03
The .idx file of a VobSub set has numerous user-definable settings that can be changed to suit, including custom colors:
custom colors: OFF, tridx: 1000, colors: D2D2D2, 000000, 000000, 000000
Would it be possible to add support for overriding this setting when ffdshow reads the file (colors would do fine for now, and maybe in the future, all of the special settings when you have time)?
If it's a big deal to add this functionality, then don't worry about it, but I just thought the ffdshow configuration interface could have a couple of more tabs where a user could enter their preferred color (and other) settings, and then ffdshow would use those if they were entered, instead of the ones contained in the .idx file.
Many thanks,
therealjoeblow
18th October 2004, 17:51
One more note on the vobsub colors:
There appears to be a small glitch in basic interpretation and display of colors. The following line shows correctly with directvobsub as white text outlined in black for one particular set of subs:
custom colors: ON, tridx: 1000, colors: 000000, 000000, 000000, D2D2D2
However, with ffdshow, it shows the text in all black with black outline, impossible to read. If I change the line as follows, then the subs appear correctly with white text outlined in black:
custom colors: ON, tridx: 1000, colors: D2D2D2, 000000, 000000, 000000
I'm not sure exactly which one is correct (directvobsub or ffdshow), but since vobsub was around much longer, I'm assuming it's interpretation would govern, having been burned to thousands of cd's around the world already.
LigH
18th October 2004, 18:33
If that was about the order of the masking (transparency) bits, it would have been at least understandable:
Either "tridx: 3210" (bit-position order) or "tridx: 0123" (ascending order) would look possible to me; I'd prefer "ascending" order.
But the colors... shall always be connected in ascending order, shouldn't they?
colors: (col. for pal.-index 0) (col. for pal.-index 1) (col. for pal.-index 2) (col. for pal.-index 3)
I would be very confused if it wasn't so! :scared:
So the second line shall be nonsense, because color 0 is transparent, so it shouldn't matter which color it got - the fact that it is white, obviously shows a shift or mirror in the palette index interpretation.
Yong
19th October 2004, 07:28
ffdshow version Oct 12 2004 08:06:04 SSE2
Bug report:
My computer spec,
Pentium 4 2.4GHz
512 MD DDR 266
Windows XP SP1
DirectX 9.0c
ATI RADEON 9600XT
Software:
Media Player Classic 6.4.8.2
Matroska container,
Using Haali Matroska Splitter Sep 8 2004 14.06.02
ffdshow configuration:
All video decoder using libavcodec,
except MPEG1 and MPEG in AVI using libmpeg2.
Only the postprocessing filter is used.
Other setting use default setting.
ffdshow postprocessng configuration:
[* = Selected option]
*process whole image
*only right half
*Postprocessing
*Custom
--*Dering, Luminance
--*Deblock H, Luminance
--*Deblock V, Luminanve
Processing Strength: 512
Processing method:
--*mplayer
--*Accurate deblocking
Level fix
--*luminance
--*Full luma range
--*Nic's Nic's First
--* X threshold: 20
--* Y threshold: 40
I can start playing video normally sometimes when using setting above, But i drag new video to the player, it crashed.
If the video can start normally, it will crashed if i close the video.
Sometimes can't start playing at all, crashed.
If i unselect the "Dering, Deblock H, Deblock V(All Luminance)" option, crashed won't happen again.
This three settings crashed with "only right half" option selected.
select "Dering , Deblock H, Deblock V(all Chroma)" don't have this problem.
BoNz1
19th October 2004, 07:32
Encoding video with x264 with ffdshow video codec in virtualdubmod crashes here. Anyone else with the same problem?
LigH
19th October 2004, 09:14
No crash with x264; but some strange over-softening occured (I wonder if the loop filter was the reason, or enabling all subdivisions); I miss a "reset" to default options (except for re-installing).
yaz
19th October 2004, 11:41
Originally posted by LigH
No crash with x264; but some strange over-softening occured (I wonder if the loop filter was the reason, or enabling all subdivisions); I miss a "reset" to default options (except for re-installing). the same here. with celtic's compile it 'cuts like hell' for me.
the quality is amazing (for me) but, yes, the overall look is somehow softer than i like. (yes, i'm one of that crisp-freaks:-)
the bests
y
akupenguin
19th October 2004, 21:39
Originally posted by LigH
some strange over-softening occured (I wonder if the loop filter was the reason, or enabling all subdivisions)
Do you have normal ffdshow postprocessing on, in addition to the H.264 loopfilter?
LigH
20th October 2004, 09:30
Of course! ;) - I tried both; It looks like after a scene change, the first frames are quite crisp, then suddenly the following frames become flat. I'm not sure if this still occurs with the current version shipped with the latest ffdshow, it occured with the previous version and celtic_druid's test version 8. I'll try to check it more soon (sorry, don't have much free time)...
celtic_druid
20th October 2004, 10:37
As far as I can tell there haven't been any changes to src/codecs/x264 since I compiled those versions, although there have been a couple of changes to x264.
hellfred
20th October 2004, 14:03
VDubMod and ffdshows x264 works for me,too.
Win98
PIII
VDubMod 1.5.10.1 build2439
ffdshow 20041012 with cletic_druids ff_x264.dll #8
2pass with default settings. quant 12
Hellfred
celtic_druid
20th October 2004, 14:25
In case anyone is interested:
http://celticdruid.no-ip.com/test/ff_x2648-AthlonXP.7z
http://celticdruid.no-ip.com/test/ff_x2648-Pentium4.7z
Might give a bit of a speed boost over the previous pentiumpro build.
yaz
20th October 2004, 15:50
Originally posted by celtic_druid
In case anyone is interested ... many many thx ! just for sure; did u recompile the previous source or is it a new cvs-snapshot ?
this or that, it always occurs to me that would we ever be able to make any return for u for your contribution ? if u got a clue, just call me :-)))
thx again
y
celtic_druid
20th October 2004, 16:12
Well I have done several cvs updates since the last compile, however the src/codecs/x264 files have not changed so yeah it is basically a recompile.
yaz
21st October 2004, 09:28
Originally posted by yaz
... if u got a clue, just call me :-))) ... thx again
y Microsoft Internet Explorer Detected - Downloaded Blocked would it be that ? :-(((
y
Yong
21st October 2004, 09:29
I can't download...
When i click the link above,
after 2 swcond i was see "Microsoft Internet Explorer Detected - Downloaded Blocked"...
can someone plz tell me why...:confused:
EDIT: plz ignore my post, it worked:D :D :D
LigH
22nd October 2004, 23:46
I'd guess, the MSIE detected a META-REFRESH or script initiated download, and the MSIE blocked a not-user-initiated download (for security reasons).
Your message looks like the webserver detected an access using MSIE, and the webserver blocked the download - what I would not expect at all... :D
celtic_druid
23rd October 2004, 08:28
Originally posted by LigH
Your message looks like the webserver detected an access using MSIE, and the webserver blocked the download - what I would not expect at all... :D
That is exactly the case, however I turned off the IE block days ago.
Yong
23rd October 2004, 12:13
Big Thanks celtic_druid for the ff_x264 dll and the mencoder!!:D
But still encounter an error when encoding video using the h264 codec... :eek:
My comp, spec. is P4 2.4GHz.
I've read the mencoder+x264 thread, i'll try the new build [mplayer20041022p4].
It's worked. :D
@LigH:
I'm using shared computer(internet cafe), so i don't know the computer admin's using what kind of secutity setting...
I'm using firefox(R) at my own computer!;)
New bug report here:
ffdshow config:
format: MPEG1/2
codec: libavcodec
ffdshow will crash when playing mpeg 1/2 video with the visualization "Motion vector" is on or selected while playing.
Rumbah
24th October 2004, 15:22
The ffdshow SSE2 build crashes Premiere Pro 1.5 with ffv1 (I have a P4). With the non SSE2 bild, everything works fine.
celtic_druid
26th October 2004, 11:29
updated x264: filesize (bits) in a 32 bit int will overflow after 250MB, screwin.
core/common.h
encoder/encoder.c
Someone want to test this (http://celticdruid.no-ip.com/test/ff_x2649.7z)
, not sure if it effects the problem with -o3 or not, so I compiled this new dll with -o3.
Doubt it fixes the -o3 so I also put up two new dll's with -o.
Links for the updated dll's with -o in case anyone was wondering:
http://celticdruid.no-ip.com/test/ff_x264-AthlonXP.7z
http://celticdruid.no-ip.com/test/ff_x264-Pentium4.7z
netchris
26th October 2004, 11:54
The problem with -O3 remains, the patch is irrelevant to the problem.
celtic_druid
26th October 2004, 12:15
Yeah, I thought as much.
netchris
26th October 2004, 12:45
Made some tests with this dll, and the 1 pass constant bitrate behaviour has changed. It gives a quite improved picture, but often gives oversized files. My guess is you have included all the latest patches so we have an up to date x264?
It seems the codec gives an even better picture now.
Havent made any 2 pass tests so take these with a grain of salt.
bond
28th October 2004, 00:19
i dunno if milan actually follows this thread (i hope so), but i wanted to mention that it would be great if ffdshow could support the small letter "s264" fourcc, which moonlight uses with their h.264 stuff, to make ffdshow able to connect to it
gotaserena
28th October 2004, 01:31
Perhaps it is worth mentioning that this seems to be the only way to play h.264 from .mp4s using ffdshow: since 3ivx mp4 splitter doesn't support h.264, we are forced to use moonlight's or pay for nero's.
celtic_druid
30th October 2004, 02:55
@bond, I added s264 myself, seems to work fine with the moonlight splitter.
ffdshow.s264.7z (http://celticdruid.no-ip.com/xvid/misc/ffdshow.s264.7z)
ffdshow.s264.7z (http://s14.yousendit.com/d.aspx?id=89A176BA463D60E2236FB90C1610B8C7)
Works fine with the version of ffdshow that you can find in the same directory, not tested with any other ones, although I guess it would work, just things like SNOW encoding might be stuffed due to an old libavcodec.dll.
movmasty
31st October 2004, 19:36
where do i could find a guide,or something similar, to ffdshow settings??????????
Mug Funky
1st November 2004, 00:39
just to check... are b-frames working in x264? i seem to remember using them in mencoder, so maybe b-frames should be un-greyed in ffdshow?
or are they currently way too unstable?
[edit]
aaah, that's right - they don't work with CABAC yet.
i suppose they can be allowed provided CABAC is unchecked, at least for now.
i'm just thinking the bitrate/quality is so good now, that b-frames would make it ven more amazing. but possibly there's inherently less to be gained from b-frames in H-264 than there is in ASP MPEG-4. i don't know enough about either to be able to tell :(
celtic_druid
1st November 2004, 01:13
bframes: CONF RANGE 0, 16.
Guess you have to stick with mencoder or wait for Milan to add it in ffdshow. Default for mencoder is 0 by the way, probably a good reason for it to.
akupenguin
1st November 2004, 01:36
libavcodec should be able to decode B-frames with CABAC now.
H.264 B-frames should help just as much as MPEG-4 ASP B-frames, or more.
But they're much more complicated than in ASP, and very few of the B modes are implemented in x264. So currently they make compression worse.
celtic_druid
1st November 2004, 02:25
Did a build with bframes enabled, seems to work. Playback is a different story. Just jitters.
wata
3rd November 2004, 03:12
how about multi-language support for text subs, like vobsub
eg
moive.english.srt
movie.german.srt
movie.chinese.srt
etc
i know you can select files from submenu "Subtitle files", but if i put another location that contain alots of subs, it show every of those subs as well regardless if the filename is different or not
thanks
Amour
3rd November 2004, 09:01
How do I know if my computer supports SSE or SSE2 ?
I think I got a Pentium 4 from Intel.
LigH
3rd November 2004, 09:18
How about CPUInfo (Freeware)?
http://www.pcanalyser.de/download/cpuinfofree212.zip
__
BTW: You don't know your PC? So why did you buy it? :sly: ;)
Leak
3rd November 2004, 13:28
Originally posted by Amour
How do I know if my computer supports SSE or SSE2 ?
I think I got a Pentium 4 from Intel.
I think you got both SSE and SSE2, then - since every P4 has them. :)
Dark_Angel_PT
3rd November 2004, 21:11
When will we see a stable version of fddshow?
Its nice to add new stuff, but there's always bugs and problems being left behind.
I stopped using ffdshow because of this.
Its an incredibly powerfull software without a goal. There isn't like a "1.0 version" to achieve.
It's like it's trapped in an ever-ending beta stage, with no final version in the future.
Why isn't ffdshow frozen at current state, developers get a few goals planned, and set as a first objective to get all the bugs solved before any new stuff is added.
Probably the problem I had in the past is solved, but I bet that new ones will show up.
In its current state, ffdshow is capable of replacing every "regular" codec out there for the "average Joe".
With a full subtitle suppport, and all the filters and features it as, getting this to a 1.0 Final, would make a lot of people happy outthere.
All those crappy codec packs would come to a short end in no time.
But this is just my opinion...
Sharktooth
5th November 2004, 14:32
FFDShow is still in ALPHA!
if you want a stable version download the 2002 version...
Defiler
5th November 2004, 14:57
Originally posted by Sharktooth
FFDShow is still in ALPHA!
if you want a stable version download the 2002 version... The fact that the last stable branch came out 2.5 years ago is, of course, exactly the issue that Dark Angel is getting at. If someone could work up a time estimate for a new stable fork, I would be willing to contribute funds toward developer time.
Yong
7th November 2004, 06:04
ffdshow version NOV 1 2004 10,28,49
ffdshow audio decoder crash with following settings,
codec: mp2, vorbis
decoder: libmad, thermor
audio filter: libavcodec resampler filter.
I found a new audio codec ffmpeg sonic lossy/lossless in ffmpeg encoder,
but the new audio codec only can decode by recent build mplayer (bulid by celtic_druid), i hope the new release ffdshow can decode the ffmpeg sonic audio...
Dark_Angel_PT
7th November 2004, 23:34
Originally posted by Defiler
The fact that the last stable branch came out 2.5 years ago is, of course, exactly the issue that Dark Angel is getting at.
Does this answear your question, Sharktooth?
vinouz
8th November 2004, 03:27
In ffdshow encoder, in the "override framerate" setting in the "output" section, the value is an unchangeable 25fps.
It wrecks the constant bitrate 1 pass estimation with different framerates.
More than this, trying to encode a video for a nokia 3g phone using H.263, the raw h.263 stream contains information that makes it override the 15fps setting both in the original file I compressed and in the .mp4 information (using -rate=15 un mp4creator) and play at 25fps.
In an AVI container, the framerate settings of the AVI get the priorities so it doesn't appear (the file plays at 15fps)...
Hope it will be fixed soon. I'm confused such a big and simple bug hasn't been found and corrected earlier....
And, thanks to the developper for such a great piece of code !
yaz
8th November 2004, 10:25
@celtic_druid
in your compile (041108 hasn't been tested) the deinterlacer bug seems to be reinvented. any change in the pane (even wout pushing accept/ok!) breaks 'ffdshow.ax,configure'. hacking the registry (the good old workaround:-) seems to work. thx for the compiles, anyway.
y
Sharktooth
8th November 2004, 14:52
Originally posted by Dark_Angel_PT
Does this answear your question, Sharktooth?
Yes sure, but maybe milan has some goals to reach before thinking to a stable build...
Dark_Angel_PT
8th November 2004, 22:58
Originally posted by Sharktooth
Yes sure, but maybe milan has some goals to reach before thinking to a stable build...
Yes, but thats's what I mean.
To organize things a little bit, set some goals...something!
celtic_druid
9th November 2004, 01:52
@yaz, I think that could be another compiler issue. Unfortunatly I can't get it to compile with gcc/mingw.
yaz
9th November 2004, 09:16
@celtic_druid
sorry to say, 041108 goes the same way :-(
btw, should i change ff_x264.dll to yours or is that included ?
thx
y
celtic_druid
9th November 2004, 10:19
The ff_x264.dll that is included is a generic version. If you happen to have a P4, AthlonXP or I guess AMD 64 CPU then there might be some kind of speed gain from the XP/P4 versions.
Still used ICL for the 041108 version which is I think where the problem comes in, although using MSVC doesn't make any difference, it does however for the problem with libavcodec's resampler. If I could get it to compile with gcc/mingw then I suspect that the problem would disappear.
mav_top
11th November 2004, 17:24
i don't know if this is the right post to ask features in ffdshow, so if i'm wrong i'm sorry about it
anyway i would like to have the OSD with a timer, just to see it for
"n" seconds and then it would be disabled (the OSD) automatically, and also if possible know which filter i'm using actually
i ask for this, because sometimes i don't know if ffdshow is running and which settings it is using, so i need to go in the filter proprierties page and look,
if i could in the osd show all these stuffs for specified seconds it would be better
thanks in advance
mav_top
pogo stick
11th November 2004, 18:23
Is ffavisynth working already?
Here is what ffdshow's help says:
ffavisynth
ffavisynth - Avisynth filter to directly use ffdshow image processing filters from Avisynth scripts
Syntax
ffdshow(string "preset", string "options")
preset - existing ffdshow preset to be used
options - array of "name=value" pairs separated by commas
Both parameters are optional. If preset is not specified, a new preset called ffavisynth is created temporarly. Options override preset settings. List of allowed options names and values is to be written, for now look at registry key HKEY_CURRENT_USER\Software\GNU\ffdshow\default to get the idea.
Limitation
Input and output colorspaces are equal. Even if ffdshow image processing filter chain would produce image with different colorspace, it will be converted to match that on input.
I tried to follow instructions, but it doesn't seem to work or I am missing something.
Any help, please. Thanks in advance.
Socio
12th November 2004, 00:18
Originally posted by pogo stick
Is ffavisynth working already?
Here is what ffdshow's help says:
I could only get Avisynth to work in the latest non-SSE SSE2 version if you try it under the SSE or SSE2 version you get a script error.
pogo stick
12th November 2004, 01:56
I don't get any errors. It just don't make a difference in video. Can you post examples of options that work for you?
Leak
12th November 2004, 08:24
Originally posted by Socio
I could only get Avisynth to work in the latest non-SSE SSE2 version if you try it under the SSE or SSE2 version you get a script error.
Well, the SSE/SSE2 versions only have a problem if you use AviSynth from *WITHIN* ffdshow while playing. The functionality this thread is about is using ffdshow as a filter in AviSynth, so I don't think the same bug will byte, errr, bite here...
Socio
12th November 2004, 14:53
Originally posted by Leak
Well, the SSE/SSE2 versions only have a problem if you use AviSynth from *WITHIN* ffdshow while playing. The functionality this thread is about is using ffdshow as a filter in AviSynth, so I don't think the same bug will byte, errr, bite here...
Yes I was thinking from with inside as that is how I use it and Pogo was refering to from with outside my error.
Flash_Git
13th November 2004, 23:27
I was wondering if it was possible to have multiple instances of ffdshow. For some files I'd find it useful to have two instances of logoaway and some of the time two sets of subtitles would be useful although I could manage that with VSFilter.
Leak
13th November 2004, 23:36
Originally posted by Flash_Git
I was wondering if it was possible to have multiple instances of ffdshow. For some files I'd find it useful to have two instances of logoaway and some of the time two sets of subtitles would be useful although I could manage that with VSFilter.
I'd say being able to use the same ffdshow internal filter several times in one instance would be even better - you can reorder the filters already, so it might be possible to invoke them more than once with the current architecture. I'm not Milan, though... :)
np: Triola - AG Penthouse (2. Epoche) (Im Fünftonraum)
swalker
16th November 2004, 06:28
Originally posted by celtic_druid
If I could get it to compile with gcc/mingw then I suspect that the problem would disappear.
What gcc version are trying to compile with? gcc3.4.2 builds the mplayer, ffmpeg, libmpeg2, mpeg2enc, and x264 code although I'm currently building the main ffdshow project with Visual C++.
pogo stick
16th November 2004, 06:42
Originally posted by pogo stick
I tried to follow instructions, but it doesn't seem to work or I am missing something.
It was my mistake with options. :o
Seems to work fine! And since this filter is for preprocessing and not for postprocessing I thought it deserves it's own thread in Avisynth section. Here (http://forum.doom9.org/showthread.php?threadid=85447) it is. :)
Yong
16th November 2004, 11:47
@mav_top:
May be you should PM or mail to milan about the feature request, because he say he lazy to read this long thread!:eek:
therealjoeblow
16th November 2004, 18:56
Originally posted by wata
how about multi-language support for text subs, like vobsub
eg
moive.english.srt
movie.german.srt
movie.chinese.srt
etc
i know you can select files from submenu "Subtitle files", but if i put another location that contain alots of subs, it show every of those subs as well regardless if the filename is different or not
thanks
Or carrying that further -
1) support for multiple subs based on a standard naming convention (as noted above, could be language, or close-captioning as in "filename.cc.sub.srt", or the unicode version of the close-captining "filemame.unicode.cc.sub.srt"
-basically, the filter should look for the 'filename' portion up to the first '.' to match the movie name; then differentiate the various versions by the text up to the next '.'; then discard the rest; and finally, recognize the subs by the file extention after the last '.' - this appears to be the way that vsfilter works.
and
2) UNICODE support would be great - normal text subs can't display the special characters like musical notes that wrap around lycics in text subs - Unicode can. Vsfilter supports these, current version of ffdshow doesn't appear to.
also,
several replies ago I suggested the color interpretation of VobSubs wasn't handled correctly, it would be great if ffdshow could have settings for the 4 vobsub color settings to override to a user's preference anyways.
Mug Funky
19th November 2004, 03:52
um... i'm thinking this is just me here, but are vobsubs broken in the latest few compiles? or did i do something to break them?
ffdshow is the only thing that will be able to sub my movies and play them back at sufficient speed, so i'm a little eager to find out how to get them working again.
tried complete uninstall + reinstall, but they don't seem to come back.
i'm using fast bilinear if that makes a difference. haven't played enough to see if any other types make them come back :(
[edit]
it appears to load them but not display them. i can choose "language" in the vobsub config and everything.
maybe it's doing something odd like rendering them offscreen or something? thing is i don't think i installed a new version before the subs broke.
hellfred
19th November 2004, 09:51
Unvisible subtitles? That reminds me that in MediPlayerClassic one has to set a special DirectShow video output to get them displayer, I think it was DirectShow VMR9 renderless. Get yourself a copy of MPC and play with the settings:
View->Options->Playback->output.
I have looked it up, it is DirectShow VMR9 renderless. See footnote (**).
Hellfred
Vitos
19th November 2004, 12:25
Originally posted by hellfred
Unvisible subtitles? That reminds me that in MediPlayerClassic one has to set a special DirectShow video output to get them displayer, I think it was DirectShow VMR9 renderless. Get yourself a copy of MPC and play with the settings:
View->Options->Playback->output.
I have looked it up, it is DirectShow VMR9 renderless. See footnote (**).
Rendering subtitles in ffdshow is completely independent from output you choose in your video player. VMR9 is needed in MPC if you use its built-in subtitling...
Mug Funky
19th November 2004, 14:37
aha... and MPC's subtitling (though pretty) isn't anywhere near as fast as i need to avoid framedrops and frozen-till-next-keyframe issues. my machine is old.
i'm on VMR9 renderless, i've tries windowed as well, plus overlay, etc. (no VMR7 because i refuse to install winXP - my machine's in a happy place, and that kind of disruption would prove my undoing).
[edit]
now this has worked before, so i don't know what's happened.
i might go and use the last binary from sourceforge. i'm encoding now, so i'll do this once it's finished.
Didée
19th November 2004, 15:51
Originally posted by Mug Funky
... my machine is old.
i'm on VMR9 renderless ...
If you are short with CPU horsepower, why do you let VMR9 burden the CPU with all that drawing stuff, while the g-card could provide a HW overlay, but instead is cleaning its fingernails only?
Mug Funky
19th November 2004, 16:11
hmm... it didn't make a difference, actually. i think VMR is using 3d stuff from the card.
the difference to me was that (a) nvidia's overlay messes up chroma sampling, and (b) MPC gave me a decoding framerate under VMR9, whereas in overlay it always reported 0 fps.
as far as performance goes, i saw no difference - if a scene froze in VMR9, it would freeze in overlay too.
btw, after regressing back to ffdshow-20041012-sse.exe, subs came back.
has anyone else noticed this? i'm the only person reporting this, so i guess it's just an issue with my box.
it's a p3 733, 384 RAM (pc133 i think, probably not brand-name), with asus nvidia geforce DDR 32 (that's a geforce 1...) running latest drivers.
[edit]
in win2k...
[edit 2]
my monitor is fine, thankyou very much :) hitachi cm715. 19 inches of CRT goodness. degauss makes me feel like i'm at a rave :o
Didée
20th November 2004, 04:27
Originally posted by Mug Funky
it's a p3 733, 384 RAM (pc133 i think, probably not brand-name), with asus nvidia geforce DDR 32 (that's a geforce 1...) running latest drivers.
[edit] in win2k... Damnit! That's exactly my office PC at work! Except for a nvidia TNT2 with outdated drivers, and those 384 MB are built by three different no-name brands ;)
And the monitor is a bad joke.
Mug Funky
20th November 2004, 16:30
so my question to you:
do vobsubs work on that machine? :)
i love this computer. it's very loyal :) it's extremely stable, doesn't overheat (well, it went ga-ga once on a ~44 degree day when i was doing an xvid encode. no air-con here, and a tiny room).
i think if i were to put winXP on this machine the whole fragile house of cards i've constructed of it over the years would come crashing down. it runs slackware 'nix distros well, and i'm just working up the guts to mess the partitions up and put a real OS on this thing (linux :)). lots of backing-up to do first.
Didée
20th November 2004, 19:38
>> do vobsubs work on that machine?
Mind you, I don't know. My needs in respect to subtitles are rather low in general. In office, they are _zero_ ;)
Mug Funky
21st November 2004, 10:44
what? you mean you don't watch anime at work? hehe :)
hellfred
21st November 2004, 20:31
Originally posted by Mug Funky
it's a p3 733, 384 RAM (pc133 i think, probably not brand-name), with asus nvidia geforce DDR 32 (that's a geforce 1...) running latest drivers.
There is something seriously messed up in your OS, or the clip you want to play back is much harder to decode than anything i threw on my system up to now.
I have a P3-550MHz (PC100 chipset) running Win98 and WinXP, just installed. I only have one file with a VOBsub subtitle (MPEG4 with resolution of about 640x480, I am too lazy to search the file) and I clould play it on win32 using mplayer with only very few frames dropped. Booting to linux helped me to get a perfect smooth playback. I have never tryed the file with any dshow filters, though. Get yourself a movix boot cd and try playing the file with it to see what you can get from your hardware.
Hellfred
EDIT: I have digged up the file: it is MPEG4 603x306, I have a nVidia TNT 1 graphic adapter, 312MB ram, and i use DirectVOBSub and ffdshow v20041012 in BSPlayer v1.0 in this very moment to display the file. System reacts somewhat slow, but ffdshow OSD tells me that 100% CPU is hardly ever needed to decode the file. I will try using ffdshow to display the *.sub and *.idx file next.
EDIT2: On Win98 i did not get ffdshow to display the subtitles while DirectVobSub is installed, and as I do not want to touch a running system, i have booted into WinXP where there is no DirectVobSub installed. But there even without displaying any subtitle, decoding the very same clip rises the CPU load to 100% :(
I have a mplayer win32 compile on the system, and when using it to decode the clip and displaying the subtitle, i get a CPU load of 60 to 80% for most of the frames. You can get the a precompiled binary for win32 from the download section of mplayers homepage (http://mplayerhq.hu). Just unpack the archive and drag and drop the avi onto the mplayer.exe. When the subtitles are named after the main file and are lying next to the main file, they get loaded automatically. Rotate through the different subtitles by pressing 'j'.
Hellfred
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.