ffdshow tryouts project: Discussion & Development

[fastplayer]

I think that MPEG1 (both libavcodec and libmpeg2) decode is broken.
With ffdshow's libmpeg (rev1245) it plays fine and AR is correct. With ffdshow's libavcodec the AR is wrong (from the beginning) but no stutters at all.

Edit: AR is wrong with another MPEG1 file I have here when using ffdshow's libavcodec. If needed, I can upload it.

[Leak]

And the changelog opens only after pressing the F5 button a hundred times... :confused:
Yeah, it's rare that you'll get an actual changelog via SF's web page nowadays.

Works much better when I use TortoiseSVN, though, as that bypasses the web server...

[Sirber]

This dual core support for h264 decoding. You who are in the know; what time frame are we talking about before its implemented in ffdshow? Imo the single most important update since I dont know when.. :)

I've been waiting for ages for that! GREAT WORK!!!!!!!!!!!!! :D

[edit]

How do I set the number of decoding threads for H264?

[_xxl]

http://www.imagehosting.com/out.php/t744676_Capture.jpg (http://www.imagehosting.com/out.php/i744676_Capture.jpg)

[Sirber]

http://www.imagehosting.com/out.php/t744676_Capture.jpg (http://www.imagehosting.com/out.php/i744676_Capture.jpg)

Thanks!
The hint still says mpeg1/2 only ;)

[haruhiko_yamagata]

I think that MPEG1 (both libavcodec and libmpeg2) decode is broken.
With libavcodec, the AR is wrong and stutters.
With libmpeg2, the AR is correct and stutters.
With MPS's libmpeg2, the AR is correct and stutters.
With Microsoft's, no problem.

How about droping libavcodec-MPEG 1/2?
The bug with libmpeg2 has to be fixed.

[Delerue]

With libavcodec, the AR is wrong and stutters.
With libmpeg2, the AR is correct and stutters.
With MPS's libmpeg2, the AR is correct and stutters.
With Microsoft's, no problem.

Thanks, man. Just to be clear, when you say 'MPS's libmpeg2' you mean 'MPC libmpeg2'? Sorry if I'm saying something wrong.

How about droping libavcodec-MPEG 1/2? The bug with libmpeg2 has to be fixed.

Would be really great. :)

[haruhiko_yamagata]

Thanks, man. Just to be clear, when you say 'MPS's libmpeg2' you mean 'MPC libmpeg2'? Sorry if I'm saying something wrong.
Oops, it's a typo. MPC libmpeg2.

[Nicholi]

Slight bug reportage and other musings.

This was mentioned once in the ancient ffdshow thread concerning tryouts. I'm not sure if it was resolved then or perhaps it wasn't broken at all at that time, but it seems to be now. Motion Vector visualizations are not showing up for divx, xvid, h.264 (and probably more) when lavc is used for decoding. I double checked with the latest clsid available (r1245) tests to be sure it wasn't my own builds. Someone else pointed this out to me (quite a long time ago, just never got around to reported it) and when I asked a few others they all said motion vectors weren't working either, but the other two visualizations are fine. This sounds almost identical to that old report but a few people were also reporting it worked fine. It seems to be working fine from milan's svn though, what could be the problem? Can anyone else confirm motion vectors are not showing up? I can bring a whole slew of hosers who can report it not working, perhaps we can figure out what the problem is.

Next subject... 7.1 audio, ugh :(. Am I correct in assuming the mixing code is part of ffdshow, or is that from ffmpeg? Currently 7.1 audio passed through ffdshow gets all wonkified, not sure how to describe it. Its not as though certain channels are just lost or remapped incorrectly, it sounds totally weird. Has this already been discussed at length concerning ffdshow? Perhaps without going into the work of mixing combinations up to 8 channels a temporary fix could be used to just ignore the 2 new channels in 7.1? We could garnish samples from our friendly HD-DVD/BR consumers.

Last thing, which is just a minor inconvenience I've noticed and not that important but you might agree the functionality is a bit off. When you are mixing the audio and using a custom graph, the dropdown in mixing MUST be set to the number of output channels you desire. For example, if the source is 5.1 and the dropdown is set to '2/0 Stereo' it will not matter how many channels you have mapped to speakers in the custom graph, you will only get 2 channels out (L/R). I was thinking more along the lines that when a custom graph is used for mixing the option set in the dropdown should be ignored. Anyone else think the same? Obviously you catch on quickly when ffdshow displays only 2ch output, I think it would just make more sense from a usability perspective.

[_xxl]

Motion Vector visualizations are not showing up for divx, xvid, h.264 (and probably more) when lavc is used for decoding.
broken since:
ffdshow_rev1029_20070314

[Nicholi]

Ahh, it wasn't listed in the known problems on the first page when I posted. It seems clsid just updated that though.

Another random thing just noticed in my latest builds (was not apparent in clsid r1245 but is now in r1263). Start up graphedit, insert filters (ctrl+f), and open up the 'DirectShow Filters' tree. Graphedit immediately closes when doing that for some reason. Anyone else getting this?

[haruhiko_yamagata]

Ahh, it wasn't listed in the known problems on the first page when I posted. It seems clsid just updated that though.

Another random thing just noticed in my latest builds (was not apparent in clsid r1245 but is now in r1263). Start up graphedit, insert filters (ctrl+f), and open up the 'DirectShow Filters' tree. Graphedit immediately closes when doing that for some reason. Anyone else getting this?
It's a bug of GraphEdit.
It's since rev 1248 that add one Four-CC. That code is not wrong at all, but maybe ffdshow supports too many Four-CC for GraphEdit. The size of data is configured correctly, but GraphEdit has some assumption that the size is smaller...

[Nicholi]

I think thats a pretty big thing to say it is a Graphedit bug.... even if it is, it is a very useful tool that would now be rendered useless. I don't think thats really better off for ffdshow-tryouts. Theres no chance you can fix ffdshow for the "bug" in Graphedit?

[haruhiko_yamagata]

I think thats a pretty big thing to say it is a Graphedit bug.... even if it is, it is a very useful tool that would now be rendered useless. I don't think thats really better off for ffdshow-tryouts. Theres no chance you can fix ffdshow for the "bug" in Graphedit?Of course.
Four-CCs are listed in both lower case and upper case, which may not be always necessary. Lower case form of minor four-CCs could be removed. clsid and drevil_xxl, which four-CCs can be removed? Remoing any two four-CCs make it work.
Or more radically, we can add a new input pin, or if it does not work, add a new filter with different GUID. But this is not a very good option for now.

[_xxl]

Just keep 20 most used fourcc's:
H264,AVC1,X264,XVID,DIVX,DX50,DIV3,DIV4,3IVX,MP43,MP42,MP41,
MP4V,H263,HFYU,MPG2,WMV1,WMV2,WMV3,WVC1,
or remove:
CRAM,AASC,AVRN,CAVS,EM2V,FPS1,MMES,VIXL,CDVC,CDV5,DVIS,PDVC?

[clsid]

I have removed the least common FourCCs from the list of exposed codes. More than enough to workaround the GraphEdit bug.

The list may be further reduced by removing some lowercase ones. However, that would need some investigation about which FourCCs (uppercase vs lowercase vs mixed) actually occur in the wild.

Btw, why is it that both uppercase and lowercase are needed? Is DirectShow that dumb? Or is it a workaround for badly programmed applications?

[haruhiko_yamagata]

FourCC is case sensitive.
const AMOVIESETUP_MEDIATYPE TffdshowDecVideo::inputMediaTypes[]=
{
{ &MEDIATYPE_Video, &MEDIASUBTYPE_NULL },
{ &MEDIATYPE_DVD_ENCRYPTED_PACK, &MEDIASUBTYPE_NULL },
{ &MEDIATYPE_DVD_ENCRYPTED_PACK, &MEDIASUBTYPE_MPEG2_VIDEO },
{ &MEDIATYPE_DVD_ENCRYPTED_PACK, &MEDIASUBTYPE_AVC1 },
{ &MEDIATYPE_DVD_ENCRYPTED_PACK, &MEDIASUBTYPE_WVC1 },
// Few most used FourCCs
{ &MEDIATYPE_Video, &MEDIASUBTYPE_XVID },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_xvid },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_DIVX },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_divx },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_DX50 },

Because "&MEDIATYPE_Video, &MEDIASUBTYPE_NULL" is listed, all the MEDIATYPE_Video are queried and ffdshow can judge accept or not. So we don't have to add minor FourCC there.
Without "&MEDIATYPE_Video, &MEDIASUBTYPE_NULL" even MPC cannot find ffdshow if the FourCC's case does not match.

[Leak]

I've checked in a change with rev. 1272 to always pass the object containing the frame information and statistics used in the OSD as a pointer; I assume somewhere along the way one of the references used for it previously actually caused a copy to be made and thus any changes couldn't propagate back to where they should.

I'll still make changing the aspect ratio an AviSynth function, but I want to see that OSD problem fixed first.

The skewered aspect ratio when using ffdshow's internal resizer before AviSynth should also have been fixed by my other checkin earlier today. :)

np: Popnoname - Mother Earth (White Album)

[chros]

New test build:
http://rapidshare.com/files/35616997/ffdshow_rev1249_20070606_xxl.exe.html
Yes, it's working with the apple's trailers (I have tried 1080p contents) too, but with none of my reencodes which were made with Sharktooth HQ-Slower profile.

Probably the cause of this what "check" mentioned:
Just a note to say that the h264 parallelisation going on there is slice level, which means unless the video was encoded with slices, you will see no benefit at all. I'm not sure how useful this will be in general, no HDVDs/BDs come with sliced video (afaik), and x264 does not slice anymore either.

Which is a very sad thing ... :( I hope ffmpeg guys will implement the other method instead of this.

[Leak]

I've checked in a change with rev. 1272 to always pass the object containing the frame information and statistics used in the OSD as a pointer; I assume somewhere along the way one of the references used for it previously actually caused a copy to be made and thus any changes couldn't propagate back to where they should.
Now that's yet another spectacular case of FAIL... :(

I'm getting a constant "requested none" with drevil_xxl's 1272 build again. Could you (or clsid) perhaps enlighten me what you're doing different with your builds?

Everytime I compile a ffdshow unicode release build here with Visual Studio 2005 SP1 and install it, the OSD simply works as expected. Those are simply checkouts of whatever version is current in SVN, exported to my temp dir and built there, so there's no residue of any earlier builds left...

Everytime I install one of your builds, I get "requested none" instead of information which frame was requested from ffdshow_source, even though the filter itself clearly works.

What's the voodoo I'm missing here to make my builds fail the same way? Debugging stuff that won't reliably break is hard... :confused:

Or is this somehow because I'm using VS 2005 and you're using an older version?

Could one of you perhaps debug this a bit for me? Does the problem even show up with debug builds?

Anyway, just set a breakpoint at the start of TimgFilterAvisynth:: ffdshow_source:: process and before the GetFrame() call in TimgFilterAvisynth:: Tavisynth:: process() and check whether any of the statistics that are changed in input in ffdshow_source are reflected in Tavisynth after the GetFrame() call, and whether both inputs are even pointing to the same memory location... I really can't think of anything else that could cause such behaviour...

np: Porn Sword Tobacco - Do The Astrowaltz (New Exclusice Olympic Heights)

[_xxl]

My builds are ansi and ffdshow.ax is compiled by MSVC2003 sp1 + SDK windows server 2003 r2.
{ &MEDIATYPE_Video, &MEDIASUBTYPE_XVID },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_xvid },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_DIVX },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_divx },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_DX50 },
{ &MEDIATYPE_Video, &MEDIASUBTYPE_dx50 },

Where are lower case xvid,divx,dx50... used?Are any app's that use them?Are they safe to remove?

[_xxl]

Parallelized h264 decoder
New test build:
http://rapidshare.com/files/36550005/ffdshow_rev1273_20070611_xxl.exe.html

[jeffy]

Well, it happened a few days ago...
I decided to give AddGrain at the playback time a chance and so I added these lines into the Avisynth section of FFDSHOW:
#Addgrain(4, 0.2, 0.3)
AddGrain(3,0,0)
AddGrain(3,0,0)


When I try to subsequently play the mp4 files created in x264, I get the error "Failed to query the needed interfaces for playback", usually starting from the second file. It doesn't matter if there are a few files in the playlist or if I just close the first file and try to open another one.

Short hw info: Asus P5W DH Deluxe, E6600/3.46 GHz, 2 GB DDR2/800 MHz (770 MHz running), Windows XP Professional SP2
Application: Media Player Classic 6.4.9.0
Avisynth: 2.57 tsp MT version 5, build: Mar 1 2007 21:27:12
MPC Option: Use the same player for each media file

If I do not use this option, the file opened after the last one will be opened without the error message, but it doesn't work for the playlist files anyway.

The options "Avisynth" and "OSD" are the only ones checked in the left pane.
If I uncheck Avisynth, there are no such errors even with playlist!
Version: ffdshow tryouts revision 1269 Jun 10 2007 12:45:49 (msvc 2003, x86, unicode)
Downloaded from free-codecs.com

Does anyone have some clues what to do or the same experience? Thank you in advance!

[Nicholi]

I'm surprised no one else has continued to bring this up. I guess everyone is just using the older mingw headers. Still a problem in SVN for libfaad (http://forum.doom9.org/showpost.php?p=977180&postcount=950). As someone already found out from poking around the problem is from the update in mingw-runtime-3.12, in which stdlib.h also includes stdint.h. I assume everyone here is using mingw, so its eventually going to be a problem in the future. Unless the mingw dev reverts something back.

Also were there any ideas on the last thing I mentioned in this post (http://forum.doom9.org/showpost.php?p=1012120&postcount=1459)? Is that the expected behavior for audio Mixing with a custom matrix? The user is required to select the correct number of output channels via the dropdown?

[foxyshadis]

Nicholi, what do you think about disabling the columns that aren't allowed by the current speaker selection? It's possible to change the speaker settings based on what the user enters, but seems like a lot of work for little gain; at least disabling them would make it obvious something has to be selected.

Didn't realize the mingw headers had changed, thanks for the heads up.

[homerpez]

Sorry to butt in, but I wondered if this was a known bug in FFDShow?...

I was using the add-a-border feature in FFDShow in order to compensate for overscan on my HDTV, while playing anime fansubs (the overscan would cut off 1/2 the subtitles, and Nvidia doesn't offer that feature for HDMI out yet).

Well, the good news is, under "Resize Aspect --> Borders", I can set border to 5% outside, resize unchecked, and this does exactly what I wanted to compensate for overscan...

However I noticed that in Windows Media player, the border itself is blacker than the surrounding empty space.

As an example, picture a 4:3 image on a 16:9 screen. In the center is the picture, then around that is the 5% border, which is pitch black. The space beyond that on either side is a dark gray color, not black.

WMP seems to show dark gray here, PowerDVD shows black throughout, but with a line between the 5% black border and the surrounding black space.

Media Player Classic, of course, shows black as it should (you cant see any difference between the black border and the surrounding black space.)

Just wondering if anyone else noticed this?

[check]

It's most likely an issue with your WMP setup. Have you set it to use the VMR7 renderer? On many setups it causes this error.

[Nicholi]

Nicholi, what do you think about disabling the columns that aren't allowed by the current speaker selection? It's possible to change the speaker settings based on what the user enters, but seems like a lot of work for little gain; at least disabling them would make it obvious something has to be selected.
That would work too. The user can obviously see what channels aren't going out then at least, I'm sure they'll figure out at that point to change the dropdown. One would hope at least. Perhaps a tooltip also for a nudge in the right direction?

[homerpez]

It's most likely an issue with your WMP setup. Have you set it to use the VMR7 renderer? On many setups it causes this error.

I can't seem to find anywhere in WMP 11 (Vista) that lets me specify the renderer, one way or another...

That's ok though, as Media Player Classic seems to display what I want the right way. It's clunky, but dammit, it works. :D

Just seeing if this was anything I could fix system-wide... but a working solution is a working solution.

[chros]

If I uncheck Avisynth, there are no such errors even with playlist!
Confirmed !
The last week I have posted this, but I didn't realize that it's the cause of the problem.
I was using asharp (and I'm using the modded avisynth.dll):
MT("asharp(1,6,-1,true)",3)

Then I must disable Avisynth, and set these settings in the Sharpen section (but in this case it's not multithreaded), because it was driven me crazy ... :)

[Leak]

When I try to subsequently play the mp4 files created in x264, I get the error "Failed to query the needed interfaces for playback", usually starting from the second file. It doesn't matter if there are a few files in the playlist or if I just close the first file and try to open another one.
Aiiieee... I thought that was a problem with Casimir666's updated MPC builds, but I guess I broke something... :(

I'll have a look at it when I get home.

[jeffy]

Confirmed !
The last week I have posted this, but I didn't realize that it's the cause of the problem.
I was using asharp (and I'm using the modded avisynth.dll):
MT("asharp(1,6,-1,true)",3)

Then I must disable Avisynth, and set these settings in the Sharpen section (but in this case it's not multithreaded), because it was driven me crazy ... :)


Well, still testing, but with non-MT AviSynth, version:
2.57 build: Dec 31 2006 13:16:28, the problem is gone!

[chros]

Well, still testing, but with non-MT AviSynth, version:
2.57 build: Dec 31 2006 13:16:28, the problem is gone!
OK, thanks.
I told tsp about this here: http://forum.doom9.org/showthread.php?t=94996&page=27

[chros]

New test build:
http://rapidshare.com/files/36550005/ffdshow_rev1273_20070611_xxl.exe.html
it's working the same way as the previous one ...
Changes?

[_xxl]

Previous test build didn't worked with this:
http://rapidshare.com/files/35755611/Star.Wars.V.mkv.html
if threads=>2.Image was wrong.

[chros]

Didn't worked with this:
http://rapidshare.com/files/35755611/Star.Wars.V.mkv.html
It's working here: MPC, built-in mkv splitter .

Edit: what do you mean: working?
If you mean the distributed decoding, then it's not working ... (But it plays the file.)

[Leak]

Well, still testing, but with non-MT AviSynth, version:
2.57 build: Dec 31 2006 13:16:28, the problem is gone!
Oh... I guess I didn't break it after all, then... :)

I did all testing with the non-MT version until recently, so it never cropped up.

[Px]

New test build:
http://rapidshare.com/files/36550005/ffdshow_rev1273_20070611_xxl.exe.html
No crash but also no parallelization......

[clsid]

It only uses multiple threads if the H.264 video uses slices. Most videos don't use slices.

[Px]

It only uses multiple threads if the H.264 video uses slices. Most videos don't use slices.
Oh, I forget, somebody write this before.
Ok, how can I check that video use slices, or not?

[_xxl]

Latest libavcodec DV encoding is broken.
3086a94d: 660f6f4110 movdqa xmm0, [ecx+10h] <-- FAULT
3086a952: 660f6f4960 movdqa xmm1, [ecx+60h]

[Zep]

interesting bug. (I think it is ffdshow )


ok I'm not sure which version this started happening but I use mplayerc and go full screen with the auto change the screen rez to 1280 x 720 option to watch 720p stuff. When I do I get a massive freeze just after the screen switches rez and is drawn black to get ready to start showing the video.

the real pain in the butt of this is that I can't access anything via mouse and when I go to keyboard and hit the mplayerc close key combo nothing happens. I can press ctrl alt del and process explorer loads and sometimes I can see it in and sometimes I can't. Everything is super slow because mplayerc is using 100% CPU and all drawing on screen is super slow. I mean like taking minutes to draw the tasks window. (all windows and other apps slow too ) The only way for me to fix things is key combo a log out and back in since all on screen drawing at that new rez is hosed.

Now this only happens with ffdshow video being used. if I turn off the codec of whatever I was about to watch in ffdshow and use a built in codec or the codec directly in xvid's case the rez switch works fine but I lose all the cool extra's of ffdshow :(

There is no crash per se'. mplayerc is stuck in some crazy 100% cpu loop and does not respond to keyboard input. There is no crash log. If I do decide to wait it out and use process explorer to kill mplayerc as soon as I kill it speed and drawing are back to normal and I am still in the 1280 x 720 rez.

Just going full screen without the rez switch works fine so it seems that somehow the rez switch confuses ffdshow?


I'm using clsid June 3 version. Thoughts?


thx

[Nicholi]

Just a random note concerning r1278 that might be useful to know. The problem was not specifically the latest DivX (i.e. 6.6.1). The qpel workaround was damaging DivX videos with qpel since 6.1 actually (the build number being 1814 you see in the patch). All the patch does is only use the qpel workarounds on anything lower then DivX 6.1.

[Delerue]

A strange bug found with this video (http://www.ftp2share.com/folder/ed4bc48b-3122-4aba-84fc-d57948e04668/pearl_jam?system=*) (to test you don't need to download all the parts) if we use 'Kernel Bob' deinterlacing. The memory usage grows fast and indefinitely. In 10 seconds the usage is around 1 GB (!!!). The most weird thing is that if you stop the video and play it again the usage doesn't reset. Build tested: 1281_20070612_xxl

[Dr Pizza]

I can't seem to find anywhere in WMP 11 (Vista) that lets me specify the renderer, one way or another...

That's ok though, as Media Player Classic seems to display what I want the right way. It's clunky, but dammit, it works. :D

Just seeing if this was anything I could fix system-wide... but a working solution is a working solution.

WMP in Vista uses EVR.

[haruhiko_yamagata]

interesting bug. (I think it is ffdshow )


ok I'm not sure which version this started happening but I use mplayerc and go full screen with the auto change the screen rez to 1280 x 720 option to watch 720p stuff. When I do I get a massive freeze just after the screen switches rez and is drawn black to get ready to start showing the video.

The feature doesn't work for me with or without ffdshow.
ffdshow may be concerned, but it's more likely video driver or MPC's problem. I use GeForce 7900.

[haruhiko_yamagata]

A strange bug found with this video (http://www.ftp2share.com/folder/ed4bc48b-3122-4aba-84fc-d57948e04668/pearl_jam?system=*) (to test you don't need to download all the parts) if we use 'Kernel Bob' deinterlacing. The memory usage grows fast and indefinitely. In 10 seconds the usage is around 1 GB (!!!). The most weird thing is that if you stop the video and play it again the usage doesn't reset. Build tested: 1281_20070612_xxl
Confirmed. I'll look into it.

[B.F.]

Are you planning ALAC support?
http://craz.net/programs/itunes/alac.html

As far as I know it already a part ffmpeg.

[_xxl]

http://sourceforge.net/tracker/index.php?func=detail&aid=1359547&group_id=53761&atid=471492
Read about alac.

[Zep]

The feature doesn't work for me with or without ffdshow.
ffdshow may be concerned, but it's more likely video driver or MPC's problem. I use GeForce 7900.

interesting. it works fine for me without ffdshow. I use an ATI 1950XT with latest drivers (well I haven't checked for new ones in a few weeks anyway) hmmm I wish we could figure out exactly where the problem is so it could be fixed by the proper party :)

I guess I could let it hang and wait it out then go into process explorer and see what thread is maxed out CPU wise. That may be a place to start?

is there a way to see video driver threads?


what is strange is that mplayerc does not respond to keyboard input so it seems like the problem is there in some crazy low level loop that somehow never lets the input code get a chance to run to check for key presses. Which would mean mplayerc is a single thread for whole app? (I find that hard to believe) guess I will find out soon enough :)