View Full Version : ffdshow tryouts project: Discussion & Development
avivahl
5th March 2009, 08:12
Probably I have added this bug recently. I'll take a look.
Thanks. :)
mark0077
5th March 2009, 22:53
haruhiko_yamagata
Just coming briefly back to my issue with dvd menu placement and aspect ratio problems.
It seems the problem with the menu positioning is NOT the mpeg2 ffdshow decoders, its something ffdshow itself is doing. Even if I do use the mpeg2 decoder within mpc-hc and have ffdshow in the chain doing nothing, the menu highlights come out in the wrong places. The moment I disable ffdshow from the chain, the problems are gone again, perfect menu positioning. I think originally we / you thought it was some decoding code / mmx within ffdshow causing the weird placement of the highlights.
------
I can also confirm your recent work on the aspect ratio output has broken something.
With a 4:3 source
"Set pixel aspect ratio in output media type" off + resize off = aspect ratio is correct.
"Set pixel aspect ratio in output media type" semi-checked + resize off = wrong aspect ratio (looks like 16:9)
"Set pixel aspect ratio in output media type" off + resize on + "no aspect ratio correction" on = wrong aspect ratio (looks like 16:9).
"Set pixel aspect ratio in output media type" off + resize on + "keep original aspect ratio" on = aspectio ratio is correct
Shouldn't every combination of these result in the visible AR being correct as the AR flags get sent to the next item in the chain. This would be a good test to see if changes you make work, ie try as many combinations of the resize options, and "set pixel aspect ratio....." option to see if they all correctly give the same final AR on maybe 4:3 and 16:9 material for a start.
------
Now that I can confirm the menu positioning problem is not decoder related, but something else in ffdshow, maybe both of these are related :D
v0lt
6th March 2009, 07:45
Hi!
My fix reg_formats.iss (look attach file)
Fix registration Div3 in VFW.
turbojet
6th March 2009, 09:52
iirc, lavc doesn't support vc-1 interlaced streams...
Ya I've heard this before too, I mainly wanted to provide (another) sample to help them with development if they are planning on supporting it, anyone know?
This sample is kind of a special case because not even wmv9 decodes it properly. I've heard of other streams where this is the case from the BD-RB thread but I haven't seen any clips posted.
ikarad
6th March 2009, 18:38
I see a bug with ffdshow-mT.
In some blu-ray there is some bugs of decompression (or decoding)
screenshot here
http://nsa05.casimages.com/img/2009/02/18/mini_090218114945228794.jpg (http://www.casimages.com/img.php?i=090218114945228794.jpg)
sample here
http://www.zshare.net/info.html?55808118-1186c8d37659ccdc7c113ea973577df5
video captured by fraps to show this bug
http://www.zshare.net/info.html?55808947-2327e7dd24f9e7c0fc51bbeac433d69b
bugs appear between 1min40 and 1min45
- With ffdshow not MT, there isn't this bug.
- With H264 codec of MPC-HC there isn't this bug.
- If in ffdshow-Mt, I select 1 in the number of decoding threads (only 1 core used) there is no bug. If I select 2,3 or 4 there is the bug
http://nsa05.casimages.com/img/2009/02/18/mini_090218120751123616.jpg (http://www.casimages.com/img.php?i=090218120751123616.jpg)
I notice that this bug appear only with blu-rays at 29.970 fps but I am not very sure because I don't have many blu-rays to test (with blu-rays at 24fps, I have never seen this bug)
My config:
Q6600 (quad core), gtx280, xp sp3,ffdshow-mt2694 or 2733
I have the same problem with ffdshow-MT 2744.
The update of ffmpeg-mt doesn't change the problem.
georgevalkov
6th March 2009, 23:18
The ffdshow video encoder DirectShow filter is broken. When I try to encode any video source to any format (I tested H264 and Xvid), ffdshow encoder indicates:
Frames encoded:0; FPS:0; kbps:0...
GraphEdit indicates Play, but is not using any CPU resources. If I try to interrupt the encoding, GraphEdit will freeze for 10 seconds and show an error:
The graph was unable to complete pause within 10 seconds.
Press Retry to wait another 10 seconds for completion
or Cancel, to attempt to stop the graph.
This version works properly:
ffdshow_rev2477_20081211_clsid_sse_icl10.exe
This and some versions before it are broken (I don't know since when):
ffdshow_rev2744_20090305_clsid.exe
Please see the composited screen shot!
PS:
ffdshow Video Codec works properly in VirtualDub with the same source and destination formats and settings. I guess that only the DirectShow version is broken.
alexins
7th March 2009, 01:20
Hi!
My fix reg_formats.iss (look attach file)
Fix registration Div3 in VFW.
I think, need to do so:
Index: bin/distrib/InnoSetup/reg_formats.iss
===================================================================
--- bin/distrib/InnoSetup/reg_formats.iss (revision 2744)
+++ bin/distrib/InnoSetup/reg_formats.iss (working copy)
@@ -371,6 +371,7 @@
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp4v"; ValueData: "0"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: NOT video\mpeg4
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "xvid"; ValueData: "0"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: NOT video\xvid
+Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "ffv1"; ValueData: "1"; Components: ffdshow\vfw
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "fvfw"; ValueData: "1"; Components: ffdshow\vfw
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "h264"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\h264\libavcodec
@@ -379,12 +380,12 @@
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp42"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp43"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4
#if include_xvidcore
-Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
+;Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "dx50"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "xvid"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\xvid
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp4v"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4
#else
-Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
+;Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "dx50"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "xvid"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\xvid
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp4v"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4
clsid
7th March 2009, 13:41
I have the same problem with ffdshow-MT 2744.
The update of ffmpeg-mt doesn't change the problem.
There is no need to continually repeat your problem.
avivahl
7th March 2009, 14:18
The "delete preset" bug is now fixed. :-)
what about the default value (http://forum.doom9.org/showthread.php?p=1257021#post1257021) for the Normalize Matrix? Anybody knows?
And guys... could you please add "16:10" to the drop down box in the subtitles' letterbox option? Most wide computer screens have 16:10 native resolutions.
ikarad
7th March 2009, 16:40
There is no need to continually repeat your problem.
why?
I though that the recent update of ffmpeg-mt corrected this problem.
clsid
7th March 2009, 19:35
Unless the SVN changelog specifically mentions a fix, it is unlikely that an existing problem was fixed.
Snowknight26
7th March 2009, 19:36
I've got some 2.0 channel AC3 Surround files that eac3to identifies as such, but when I play them with ffdshow, it says the input is 6-channel AC3. Normal?
Sample: http://stfcc.org/misc/threekings.ac3
georgevalkov
7th March 2009, 20:54
I've got some 2.0 channel AC3 Surround files that eac3to identifies as such, but when I play them with ffdshow, it says the input is 6-channel AC3. Normal?
Sample: http://stfcc.org/misc/threekings.ac3
I don't understand much about AC3, but If I feed the built-in decoder of the my X-fi card, it will play more like a 6 ch. sound (the card was in 5.1 mode when I made the test). I used an AC3 decoder from Cyberlink configured in AC3 pass through mode; the sound card was configured to decode AC3 bit streams to analogue sound.
Graphedit indicates 2 channels, but all of the 6 speakers play different sounds.
albain
8th March 2009, 11:33
In the future DirectShow support will be dropped (actually I think that it will be still supported but without updates)
In Windows 7 Microsoft integrates a divx decoder which is coded with Direct Media Foundation, the replacement of DirectShow.
So no possible subtitles, postprocessing... with MPEG4 formats.
Same thing with H264
This is annoying because DirectShow filters have no way to override or replace any DMF codec because they deal with a separate merit.
In Vista this was not a problem because only mp3 and MS codecs was integrated into DMF. But now the most commonly used codecs are migrated to Direct Media.
MS claims that DMF is better for High Definition, tearing and streal synhcronization. Personnally I don't share this opinion but the things are that in the future DirectShow will disappear.
Looking at the samples, DMF coding seems simpler than DirectShow, but the cost of transcoding FFDShow to DMF seems very high considering the high level of customtization of FFDShow. If someone has leads, I don't know maybe it is possible to develop a generic DMF filter that would call or encapsulate FFDShow ?
Just want to raise a debate
Damien
clsid
8th March 2009, 16:02
ffdshow currently is one big entangled mess with an eroded architecture. My suggestion would be to start new filter from scratch. That would have several advantages:
- It does not interfere with development of current ffdshow.
- Should result in clean code with a better architecture.
- Allows separation of audio and video into two filters.
I have tested Windows 7 and the MS DMO decoders work fine in DirectShow players. The MS decoder even works with DXVA in MPC-HC. Subtitles work as well.
RadScorpion
8th March 2009, 21:48
If the "directshow ffmpeg" project is to be reborn I'd suggest making multiple filters - not one big superfilter.
That way all features (encoder/decoder) could be used or configured in much simpler way. The biggest problem with ffdshow is its evil interface. It has a nice GUI, but making it do simple task like resize into specified resolution is a pain in the ass.
Also the video/audio processing stuff might be separated completely.
georgevalkov
9th March 2009, 01:37
In the future DirectShow support will be dropped (actually I think that it will be still supported but without updates)
Albain, I think it's okay if you don't want to update or support the DirectShow functionality of ffdshow, but please don't remove it! And Please restore the ffdshow encoder filter (see my post #6807 (http://forum.doom9.org/showthread.php?p=1258405#post1258405)).
I've used Windows 7 beta for a few weeks, seems better than Vista. I like it, however the interface does not respond in real-time. Both Vista and Windows 7 have good new features, but in the end it's just an OS - Users want to run their programs and manage their documents.
So consider the fact that there are still a lot of people using windows XP. I don't know if it supports DMF, but it will probably be better to keep the DirectShow functionality, even if not updated.
I suggest that a second DMF component may be added to complement ffdshow (together in the same installer). In the part of it's development it's functionality will increase as more parts from the original ffdshow project are added to it. It's not a single step but a long process.
I think it will be a bad idea to separate the ffdshow developers on the two variants (DirectShow vs. DMF) - this will make you weaker.
This is annoying because DirectShow filters have no way to override or replace any DMF codec because they deal with a separate merit.
An application can still add ffdshow to the graph and use it. It's better than nothing (for now) ;)
MS claims that DMF is better for High Definition, tearing and streal synhcronization. Personnally I don't share this opinion but the things are that in the future DirectShow will disappear.
Could be true or no quite?! I don't take anything from them for granted, until I try it. They also said that Vista is faster. Hm :devil: If I use Win 2008 or Win 7 for some time and than switch back to the Win 2003 installation, my computer really speeds up a lot :cool:
Looking at the samples, DMF coding seems simpler than DirectShow, but the cost of transcoding FFDShow to DMF seems very high considering the high level of customtization of FFDShow. If someone has leads, I don't know maybe it is possible to develop a generic DMF filter that would call or encapsulate FFDShow ?
Just want to raise a debate
Damien
Is DMF supported on Win 2003 or XP? Anyway, c++ codding and multimedia are only my hobby, I'm studying electronics.
One thing I learned from the HTML codding is to separate code design and data. The basic idea is to create a common way for adding DSP filters and formats to the ffdshow project. Something like the plug-in architecture model, except that the whole project is compiled together in the end.
~ The main part has to be fast and simple;
~ Each DSP filter appends itself to a list of effects;
~ Each format appends itself to a list of codecs.
~ Each effect and codec is independent from the other; can be added or removed from the project, without breaking it. E.g.
add a .cpp file to the project; it registers at run-time (so that the main code knows about it) and is ready to use.
~ Multiple instances of one and same effects can be pipelined together with other effects. Multiple threads can be used for pipelined effects to better utilize multi core CPUs.
Leak
9th March 2009, 09:48
Albain, I think it's okay if you don't want to update or support the DirectShow functionality of ffdshow, but please don't remove it!
Errr... he was saying that in the future DirectShow support in Windows will be dropped *BY MICROSOFT*, not by ffdshow...
haruhiko_yamagata
9th March 2009, 11:34
ffdshow currently is one big entangled mess with an eroded architecture. My suggestion would be to start new filter from scratch. That would have several advantages:
- It does not interfere with development of current ffdshow.
- Should result in clean code with a better architecture.
- Allows separation of audio and video into two filters.
I have tested Windows 7 and the MS DMO decoders work fine in DirectShow players. The MS decoder even works with DXVA in MPC-HC. Subtitles work as well.
I'm bit tired of coding for mainstream of ffdshow and playing with subtitles. It's mainly cleaning of the code as I can't code any further without cleaning it. Cleaning code is easier than writing code from scratch. My new code isn't clean enough, but it's just my skill.
However, as for me, I'm not motivated enough to code for MF for now. I'm already overwhelmed enough.
albain
9th March 2009, 12:18
I agree, but I would like to know how huge is the work to port FFDShow to become "FFDMF".
So I am willing to give it a try (locally on my side first), of course it will take time.
Too bad that MS has not delivered a DirectShow to DirectMedia developers guide.
This is the reason why I was asking this : if there is any material (code, documentation) to begin with, I would be more motivated to begin with.
I think that there are lots of similarities between DirectShow/DMF, most work (I am probably naive) would be to reconnect the old methods with the new ones.
Before talking about splitting project or anything, it would be great that I could adapt current code. First thing would be to make FFDShow compile with windows SDK 7.0, which is not the case for now.
tetsuo55
9th March 2009, 14:41
How is windows 7 backwards compatible with DirectShow?
Does it emulate it through MediaFoundation?
I fully agree that the move to MediaFoundation should be made sooner than later.
Like clsid said it might be a better idea to start a new version for MediaFoundation.
What it needs is a better framework, designed to do everything we want now and in the future. Then we can plug existing ffdshow code into the framework and update that later. (like mame)
albain
9th March 2009, 14:55
Yes WMP and WMC emulate DirectShow but I don't know if this emulation is based upon DMF or works in parallel
Inventive Software
9th March 2009, 14:59
I agree, but I would like to know how huge is the work to port FFDShow to become "FFDMF".
So I am willing to give it a try (locally on my side first), of course it will take time.
Too bad that MS has not delivered a DirectShow to DirectMedia developers guide.
This is the reason why I was asking this : if there is any material (code, documentation) to begin with, I would be more motivated to begin with.
I think that there are lots of similarities between DirectShow/DMF, most work (I am probably naive) would be to reconnect the old methods with the new ones.
Before talking about splitting project or anything, it would be great that I could adapt current code. First thing would be to make FFDShow compile with windows SDK 7.0, which is not the case for now.
DMF is a completely different framework to DirectShow. The fact ffdshow (the name implies it) is based around DirectShow only serves to show how big the task is. Not to mention, ffdshow also includes a VFW decoder/encoder, which should ideally be separate from ffdshow.
In a totally ideal ffdshow world, the following elements of ffdshow would be separate:
video decoder,
post-processing,
post-filtering,
audio decoder,
subtitle decoder,
VFW encoder/decoder.
Anybody else wanna add things to it, feel free.
If we could have it, along with possibly taking some more ffmpeg components, the libavformat splitter/parser would be a separate entity too. It would make ffdshow a more complete codec with it, but granted the core philosophy of it is that it's a decoder, not a parser.
albain
12th March 2009, 09:50
Here are some interesting information I got from MS :
Link to original post (http://social.msdn.microsoft.com/Forums/en-US/mediafoundationdevelopment/thread/0eb66fc9-6cf2-4f6e-b575-9739d36bc643/?ffpr=0)
The Media Center TV application still uses DirectShow. It might also use Media Foundation for certain tasks, but for live and recorded TV, it uses DirectShow.
I don't have a document that describes how to port a DirectShow filter to Media Foundation. (This is a good idea though.)
In the specific case of a decoder filter, you'll want to implement a Media Foundation Transform. Here are some things to consider:
Understand the new media type API. There are some conversion functions to convert between DirectShow and MF types.
The MFT data processing model is very similar to the DMO model.
A DirectShow filter typically delivers an output sample inside its Receive method. For an MFT, input and output are distinct steps. The pipeline will call ProcessInput to give you an input sample, and will call ProcessOutput to get an output sample from the MFT. It may call these two methods in any order, so the MFT must return error codes indicating "need more input" or "not ready to receive input"; these are documented in the IMFTransform documentation.
End-of-stream and flushing are indicated through the IMFTransform::ProcessMessage method.
Discontinuities, key frames, and per-frame interlacing are indicated through media sample attributes.
An MFT does not have to worry about run, pause, and stop states.
If you support DXVA, read Supporting DXVA 2.0 in Media Foundation.
The MFT_Grayscale sample in the SDK shows a simple video effect. You can use this as a starting point. It shows type negotiation, the basic processing model, and MFT registration.
Hopefully this is enough to get started. Let me know if you have more questions.
- Mike
Jeremy Duncan
12th March 2009, 17:41
ffdshow currently is one big entangled mess with an eroded architecture. My suggestion would be to start new filter from scratch. That would have several advantages:
- It does not interfere with development of current ffdshow.
- Should result in clean code with a better architecture.
- Allows separation of audio and video into two filters.
I have tested Windows 7 and the MS DMO decoders work fine in DirectShow players. The MS decoder even works with DXVA in MPC-HC. Subtitles work as well.
In that post to msdn albain made. Microsoft said it's intention is to erase the use of direct show in time.
"the goal is that Media Foundation will replace DirectShow in the long term."
And Albain said he was gonna try and port ffdshow to directshows replacement with a new unnamed project.
So I humbly ask you to help him.
Maybe start a new thread so you and him can discuss this and get it going.
albain
12th March 2009, 19:23
Thank you but not so fast, I am not sure that I won't give up.
For now I am trying to integrate a new DMO filter inside FFDShow based on existing classes.
I will get back to you when I will have come to something that (nearly) works.
Advancement so far :
Like Haruhiko said earlier, it is always easier to modify existing code rather than create a new one from scratch.
So this is what I am trying to do. It is possible to make a directshow and DMO filters coexist with some adaptations
ffdhow.ax now contains existing directshow filters + a DMO decoder (that decodes nothing for now).
mrcorbo
12th March 2009, 23:05
If we could have it, along with possibly taking some more ffmpeg components, the libavformat splitter/parser would be a separate entity too. It would make ffdshow a more complete codec with it, but granted the core philosophy of it is that it's a decoder, not a parser.
I think that a libavformat-based Media Source object for WMF would be a worthy project on its own. It would certainly make a potential ff(wmf?) much more useful.
Mtz
13th March 2009, 15:33
clsid, I tested ffdshow_rev2754_20090310_clsid with a .ts file from here: http://rapidshare.com/files/206456698/TVR_HD.ts and the decoding is broken.
With some previous version was working and also I tested with ffdshow_rev2734_20090301_xxl.exe and is working OK.
enjoy,
Mtz
clsid
13th March 2009, 16:01
Please test rev2744 as well
http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2744_20090305_clsid.exe
Your file is working here. So please give a more specific definition of 'broken'.
Mtz
13th March 2009, 17:31
I think the problem is in libavcodec.dll.
In attachment are 4 screenshots. The name of the files represent the number of ffdshow releases.
Sorry for not taking the screenshot at the same frame, but with the buggy versions all frames are bad decoded so the frame number is not important.
http://www.sendspace.com/file/rtzn6m
Latest Haali used.
enjoy,
Mtz
mark0077
13th March 2009, 18:34
Guys is there a problem with vc-1 playback using the ffdshow vc1 libavcodec decoder.
Watching a 1080p movie using the internal decoder I am getting 50% of my frames shown 50% dropped. Using mpc-hc internal decoder I get 100% drawn.
Just surprised. I am using ffdshow 32bit 2754 with just rgb color conversion enabled. Using 1080p .ts file.
Inventive Software
13th March 2009, 18:36
What's your CPU usage? What happens when you don't have RGB conversion?
mark0077
13th March 2009, 18:44
CPU Usage is 15% (Core i7 @ 4ghz). Just restarted the video again and now I am losing approx 20% of frames and slowly seems to calm down to not dropping as many.
RGB Conversion doesn't have any effect. Just now out of 500 frames, I lost 47 which isn't too bad, but using mpc-hc I lose 0, perfectly smooth.... It actually took alot of effort on my part to get mpc to drop even 1 frame.... but it definitely does show dropped frames. Got it to drop 3 now with some high cpu usage in other apps. ;)
Maybe some ffdshow code is dropping frames unnecessarily... not sure whats wrong. I have a very simple setup.
I was hoping to move to ffdshow decoders rather than mpc-hc's ones because of the bad communication between the two regarding interlaced flags. Decoding in ffdshow for the moment seems to have advantages at least with DVD playback and crashing / freezing with de-interlacing.
clsid
13th March 2009, 19:10
Fixed the interlaced H.264 bug in revision 2768.
Mark, does it make a difference if you uncheck "Drop frame on delay" on the decoder options page in ffdshow settings?
leeperry
13th March 2009, 22:44
guys, small question please :)
Seb.26(an occasional ffdshow coder) told me that ffdshow couldn't resize horizontally while retaining AR....Haruhiko told me that it wasn't true.
so here's a real world example : a 672x384 AVI file w 7/4 DAR
resized to 1024*768 w/ these settings :
http://www.image-load.eu/out.php/t152284_ffd.jpg (http://www.image-load.eu/out.php/i152284_ffd.jpg)
yet Info() in the Avisynth filter shows : 1022*584, which is not mod4....and none of my scripts work because of that :(
is there a way to force ffdshow to actually resize to 1024*585 or 586 :confused:
if I force 1.78 AR in ffdshow, then it is 1024*576....
Mtz
13th March 2009, 23:44
I think the problem is in libavcodec.dll.
In attachment are 4 screenshots. The name of the files represent the number of ffdshow releases.
http://www.sendspace.com/file/rtzn6m
Latest Haali used.
The bug from: 0305_clsid.jpg and 0310_clsid.jpg is solved in the ffdshow_rev2768_20090313_clsid release.
Maybe that .ts capture have some bugs because sometimes is dropping about 25-45 frames from ~650 frames. But not always.
enjoy,
Mtz
mark0077
14th March 2009, 02:14
Fixed the interlaced H.264 bug in revision 2768.
Mark, does it make a difference if you uncheck "Drop frame on delay" on the decoder options page in ffdshow settings?
Hi clsid, yes unchecking that does stop most of the dropping of frames. I still get a few hundred frames dropped, but mostly at the start of playback then it settles down to no dropped frames.
Unchecking this option also fixed some dropped frames I was having when using the mpc-hc decoder in certain situations. Now using the mpc-hc decoder I am getting 0 dropped frames. Just wondering why ffdshow drops so many frames at the beginning of playback, and.... well if this drop frame setting is buggy in general. Its doing a fine job disabled.... I wonder if mpc-hc is doing some sort of buffering of frames, does ffdshow think the frames wern't "drawn" yet and .... start dropping frames. I don't know I will leave it to you guys ;)
Mirabel
14th March 2009, 11:49
Hello, I'm sorry but I don't now if I ask sth. stupid or if this is really a problem.
I used ffdshow-mt (I speak about the time before the builds were merged) and noticed that "NV12" in the colorspaces wasn't checked. I activated it and now ffdshow(-mt) used NV12 as output color space.
After the builds were merged, ffdshow started to use YUY2. I unchecked YUY2 and it used a different space but not NV12.
http://img147.imageshack.us/img147/103/ffd1.png
I decided not to try to enforce NV12 cause to my eyes there was something wrong. No my color spaces config looks like this:
http://img12.imageshack.us/img12/1995/ffd2.png
I'm using an ATI Mobility Radeon HD 2400, the drivers should be up to date. Windows Vista 32.
At the moment my ffdshow build is ffdshow_rev2768_20090313_sse_icl10.
Questions:
- What's going on?
- Is this a bug?
- Does NV12 have any advantages about YUY2? If that's not the case, I do not mind what's happening.
Thanks.
georgevalkov
14th March 2009, 12:24
Fixed the interlaced H.264 bug in revision 2768.
Hi clsid!
There is a bug in the 'ffdshow video encoder' filter.
To reproduce:
1. clean install ffdshow_rev2768_20090313_clsid.exe
2. Try to encode some video source,
http://www.mediafire.com/file/jd5bwcmmymm/RGB24.avi.7z
add the 'ffdshow video encoder' to GraphEdit (I used the default configuration - MPEG-4 encoder, but any other including uncompressed will fail too).
3. Connect the input of the filter and open the properties on the 'Out' tab.
4. Preferred media types indicate:
Major Type: Video - Sub Type: {0020002C-0000-0010-8000-00AA00389B71} - Format: RGB 16777216x524712, 8 bits
rcSrc=(0,0,917546,524720)
rcDst=(0,0,917546,524720)
Major Type: Stream - Sub Type: None - Format: None
This strange format seems invalid and unsupported by any other filter. Could be some uninitialized variable?
5. Replace the 'ffdshow video encoder' with the 'ffdshow Video Codec' and connect the input. Open the properties on the 'Out' tab.
6. Preferred media types indicate:
Major Type: Video - Sub Type: {44495658-0000-0010-8000-00AA00389B71} - Format: XVID 640x480, 24 bits
rcSrc=(0,0,0,0)
rcDst=(0,0,0,0)
7. Connect 'ffdshow Video Decoder' and 'Video Renderer' to decompress and preview the encoded frames.
8. Click Play: 'ffdshow Video Codec' works properly, but the 'ffdshow video encoder' filter needs to be fixed.
Please help!
edit: fixed after rev2832. Thank You!
georgevalkov
14th March 2009, 12:34
- Does NV12 have any advantages about YUY2?
See this link for details about the YUV formats:
http://www.fourcc.org/yuv.php
NV12 and YV12 are 12 bit, decoding is faster (less CPU than YUY2 and UYVY - which are both 16 bit), but in NV12 and YV12 there is a more colour information loss, also I think they are not suitable for interlaced movies.
You may try to force only NV12 (uncheck the others) and see if the Video Renderer supports it.
Mirabel
14th March 2009, 14:28
See this link for details about the YUV formats:
http://www.fourcc.org/yuv.php
NV12 and YV12 are 12 bit, decoding is faster (less CPU than YUY2 and UYVY - which are both 16 bit), but in NV12 and YV12 there is a more colour information loss, also I think they are not suitable for interlaced movies.
You may try to force only NV12 (uncheck the others) and see if the Video Renderer supports it.
Thank you very much. Actually, I do not insist on NV12.
If anyone could tell me what - regarding the available color spaces in ffdshow - is the best choice as colorspace if I rather take quality instead of speed, I'd be really lucky. N.b.: I can't remember to have had contact with any interlaced video in all the years I used ffdshow. I use MPC-HC's internal decoders for DVDs.
I still wonder why the output color space was changed by ffdshow, I didn't changed anything but it moved from NV12 to YUY2.
yesgrey
14th March 2009, 14:41
I use MPC-HC's internal decoders for DVDs.
I still wonder why the output color space was changed by ffdshow, I didn't changed anything but it moved from NV12 to YUY2.
MPC-HC decoders output YUY2, so that's the reason you are getting YUY2 in ffdshow, it selects the nearest colorspace from the ones you have selected.
Ger
14th March 2009, 16:47
About the color space thing, this is the situation on my system with DVBViewer + ffdshow + Nvidia 8800GT + Vista32-SP1 and a live interlaced MPEG-2 DVB-S channel:
If I enable YUY2 in ffdshow, then YUY2 is used according to ffdshows extended tray info like in Mirabel's screenshots, however I can clearly see visible interlacing lines, so the hardware deinterlacing (no matter if it's auto or force bob) is not working properly.
If I disable YUY2 and leave NV12 as the only checked output color space in ffdshow, then the tray info says "NV21,VU" whatever that means, and there are no visible interlacing lines anymore, so now the hardware deinterlacing works.
Richardw322
14th March 2009, 17:58
Didn't know where else to put his, but I wanted to let everyone what happened here with Windows 7 Beta 7048 and FFDshow 2754 yesterday.
I had a day off, and I had downloaded the 7048 beta of Windows 7. I thought I would try it as it had built in h264 decoding, and I saw an article on how to play MKV files in Media C3enter. So, I thought I'd play a bit. Loaded Windows 7 7048, installed FFDshow and Haali Splitter, then a couple REG patches. Set up Media Center, (easy setup, busy program) and when I went to Videos there were the MKV files. And they played!!
I was playing just pieces of them, and I when I got to my DVD rip of Iron Man I started to notice it was "sputtering" badly. The sound was fine, but the video looked like everyone was doing the "Robot" (remember that dance?) I tried to get it to use FFDshow, and Media Center just kept using it's internal codec. At least I think it did, the FFDshow tray icon never showed up. Then I installed GBPVR and set that up. I set the preferred decoder in GBPVR to FFDshow and tried again. The same stutter, and no tray icon. I tried Media Player Classic Home Cinema and no stutter. (Using the internal codec). I tried forcing the merit on FFDshow to highest and still no FFDshow.
I think when Microsoft included the H264 codec they block all others in Windows from using any other codec for H264 playback on the computer, even third party software. I wish I had thought to try Graphedit to figure it out, but instead went to Beta 7022 (no H264 codec) and everything went back to normal. I smell a rat here.
ikarad
14th March 2009, 18:13
Fixed the interlaced H.264 bug in revision 2768.
H264 from blu-ray or not?
is-it for ffmpeg-mt or just ffmepg
What is the bug?
in the readme there is:
"Bugfix for revision 2744. Fixed decoding issue with interlaced H.264 video"
but with my blu-ray there is always a decoding issue that I reported here
https://sourceforge.net/tracker2/?func=detail&aid=2612226&group_id=173941&atid=867360
i would like to have a confirmation if it is the same thing.
If not, I'm sorry to disturb you.
clsid
14th March 2009, 19:15
Its the bug that was reported yesterday. Nothing else has been fixed.
Mirabel
14th March 2009, 20:18
MPC-HC decoders output YUY2, so that's the reason you are getting YUY2 in ffdshow, it selects the nearest colorspace from the ones you have selected.
In WMP I get YUY2 too. I assume WMP decodes to YUY2 too..?
BatKnight
14th March 2009, 21:35
Thank you very much. Actually, I do not insist on NV12.
If anyone could tell me what - regarding the available color spaces in ffdshow - is the best choice as colorspace if I rather take quality instead of speed, I'd be really lucky. N.b.: I can't remember to have had contact with any interlaced video in all the years I used ffdshow. I use MPC-HC's internal decoders for DVDs.
I still wonder why the output color space was changed by ffdshow, I didn't changed anything but it moved from NV12 to YUY2.
I've read somewhere that ATI Radeon owners benefit from NV12 over the other colorspaces.
I ticked NV12 only and it displays (NV21,VU). I've noticed that only NV12 enforces the Edge Enhancements and De-noise settings at the AVIVO tab inside Catalyst Center. All other colorspaces ignore those settings.
Bat
mark0077
14th March 2009, 21:44
Hi guys, especially those of you interested in colorspace conversion. Now that Beliyaal has discovered how to set the levels flag in the output type of mpc-hc, I had an idea.
Wouldn't it be beneficial to have colorspace conversion and levels conversion in yv12 itself, not just when converting to RGB.
So what I was thinking was the following config.
decoder outputs in yv12 or yuy2 -> ffdshow does colorspace and levels conversion ALSO within yv12 or yuy2 (not RGB) -> mpc-hc outputs with levels flag set correctly so drivers don't touch levels -> hardware de-interlace if necessary (sweeeeet) -> output to display
This would be excellent and would mean we can have the best of both worlds, the excellent hardware de-interlacers, aswell as levels and colorspace conversion done in ffdshow (yv12 with original colorspace and levels -> yv12 colorspace and levels corrected).
Do you think it would hard to change the current "RGB Conversion" area to something else like "Levels / Colorspace Conversion) instead and not be limited to just RGB :D
clsid
14th March 2009, 23:08
I might be wrong, but the flag Beliyaal was talking about is not usable by ffdshow afaik. It is a flag that is set by MPC when initializing its custom version of EVR.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.