ffdshow tryouts project: Discussion & Development

[albain]

Originally Posted by cbemoore

//pDataOutW[4] = 0x0b77; // AC3 syncword (removed because works only for DTS, not for DD)

I've looked at a few other code samples on the web, and they all seem to include the AC3 syncword. Maybe re-adding it would solve the problem?
Chris

I removed it because it made AC3 streams not work (only DTS did).
I had a look on ac3filter code, and it seems to be far more complicated than FFDShow code, and maybe this is the issue : the buffer may need to be scanned for syncword...

[foxyshadis]

Originally Posted by Inventive Software

FLV4 had inloop? Then why do Youtube videos look so bad?

And foxy: are you talking about adding an option enabling / disabling the H.264 inloop deblocking filter, as opposed to adding H.264 postprocessing deblocking? The latter isn't good, the former is a good idea.

EDIT: On second thoughts, the method you use probably wouldn't work for most video. I think it's only unique to H.264 that particular inloop deblocker.

Inloop disabling is already available on the codecs page. I mean adding a PP option, but unrelated to whether it's playing h.264 or not, it'd be available for mpeg-4 and other streams too. Same algorithm Donal Graft's Deblock uses, and it works pretty well there, just has a different character than mplayer deblocking.

Some of the early Google Videos were done in VP6, until they switched to Spark everywhere (yuck).

[albain]

One more thing : the new SPDIF behaviour also solves the messup with the audio channels on some multichannel formats.
Besides ac3filter also uses 10 buffers (new behaviour) instead of 4 (old behaviour), so I do believe that the solution is not far

Otherwise I have tried some other methods to fill in the buffer with no success for now

To people where the new behaviour does not work : please tell me if the no sound issue occurs for any audio format (5.1 dolby digital, 5.1 dts), and if you have dev skills you can try to play with the buffer filling (in tffaudiodecoder.cpp / deliversamplespdif). The problem is that I am completely blind on that subject

[haruhiko_yamagata]

Originally Posted by cc979

@haruhiko_yamagata here is a picture of the bug

I can't reproduce. Could you give a try on the downloads from souceforge.net?

[haruhiko_yamagata]

Originally Posted by foxyshadis

I mean adding a PP option, but unrelated to whether it's playing h.264 or not, it'd be available for mpeg-4 and other streams too.

It's a good idea. Could you write the code?

[Shinjite]

Is the latest lavc h264 decoder multi-threaded?
Does it have an impact on P4HT procs?

I have tested clsid's rev 1465, it seems like the H264 decoding still fully utilises 1 thread instead of 2....

[Sharktooth]

the very latest lavc uses multiple threads for decoding h.264 BUT only if the stream was encoded with multiple slices.

http://forum.doom9.org/showthread.php?t=129702

[cc979]

Originally Posted by haruhiko_yamagata

I can't reproduce. Could you give a try on the downloads from souceforge.net?

i checked svn 1443 that is fine, but around svn 1451+ it started - maybe the text is stored different but not sure

[Kado]

Something regarding subtitles... I've been comparing (again) ffdshow renderer and MPC renderer and i've realized that you can get even better subs from ffdshow if you use resize the video before the subs are rendered.
ffdshow places the subs over the video and mpc feeds them to the renderer, thats why (probably) we can't have s subtitle resolution option like mpc has because in ffdshow the subs are dependent on the video resolution.
what's the best settings for resizing a video that can match haali renderer's quality, I'm resizing to 1680pix horizontal.
also, haali resize is done in hardware right (ps2.0)?

[EDIT]Is the resizing done in a different thread from the decoding as well?[/EDIT]

[foxyshadis]

Haali uses bicubic, and in hardware, yes. (But it's configurable, whereas ffdshow only has one sharpness setting, 0.6 iirc. Also apparently it uses ps 1.4 now.) MPC's subtitle alpha blending is also in hardware, so it gets a free speed boost ffdshow can't. You'll probably want to use Letterbox 16:10 in subtitles after the resize.

I'll see what I can do for the PP stuff.

[Kado]

thanks for the info. I've noticed that subs have less resolution when using haali if compared to vmr9 and evr from mpc subs renderer.


I have found some positioning errors when using ffdshow subs renderer, japs text goes on top of english text, luperry.com in wrong place etc, can be seen at min 1.06


Sample here.

Audio and video have nothing to do with the subs but have the same aspect ratio. subs are from "[LuPerry]_Sumomomo_Momomo_-_01_(1280x720_x264).[F5CDB4ED].mkv"

[haruhiko_yamagata]

Originally Posted by Kado

thanks for the info. I've noticed that subs have less resolution when using haali if compared to vmr9 and evr from mpc subs renderer.

I know MPC has better quality, but you can get better quality from ffdshow. First, check haali's splitter settings (double click the tray icon, Options->Input->Load embedded fonts). Second resize to 1680 horizontally and place subtitle after resize (last is best). Use RGB32 output if CPU can catch up. When ffdshow's subtitle filter get complete, the average CPU would be much faster .
I'm learning what MPC does for the good quality. It's quite well written, but hard to understand for me.

I have found some positioning errors when using ffdshow subs renderer, japs text goes on top of english text, luperry.com in wrong place etc, can be seen at min 1.06

Thank you. I can reproduce. The difference in size is more anoying (hard to fix).

//EDIT The positioning errors are collisions, animation effects and rotation ({\frz}). They are not implemented yet. I have plans to do, but at least after a few months.

[Mc Onyx]

It seems that FFMPEG's E-AC3 a.k.a. Dolby Digital Plus decoder is finished and i'm wondering if it's possible for someone to make a FFDShow build, that has the decoder integrated... Thanks

[haruhiko_yamagata]

Originally Posted by Kado

Something regarding subtitles... I've been comparing (again) ffdshow renderer and MPC renderer and i've realized that you can get even better subs from ffdshow if you use resize the video before the subs are rendered.
ffdshow places the subs over the video and mpc feeds them to the renderer, thats why (probably) we can't have s subtitle resolution option like mpc has because in ffdshow the subs are dependent on the video resolution.
what's the best settings for resizing a video that can match haali renderer's quality, I'm resizing to 1680pix horizontal.
also, haali resize is done in hardware right (ps2.0)?

[EDIT]Is the resizing done in a different thread from the decoding as well?[/EDIT]

Yes, ffdshow cannot have subtitle resolution option like mpc. It's impossible. ffdshow does the software alpha blending in the main memory.
Resizing is done in the decoding thread. It uses more than two threads if CPU supports it.
Preparing subtitle should be done in separate thread, but currently it is done in the decoding thread. If you are dropping the frame or experiencing a delay when a new subtitle pops up, queing may help.

[SBeaver]

Hi there I have a question, something I might have touched on before.
Is it possible for 32bit ffdshow to pass on ac3/dts somehow to a 64bit application (like ffdshow 64bit for example).
Since ffdshow is pretty much the only 64bit dshow decoder available except some MS decoders, it's hard to stay away from 32bit media players, since the only one for 64bit is wmp11 which has a lot of limitations.
Any direction to another 64bit media player would appreciated

[Leak]

Originally Posted by SBeaver

Any direction to another 64bit media player would appreciated

Since you can't mix 32 and 64bit code in an application this is rather unlikely.

Then again, media playback isn't exactly something that begs for a 64bit app anyway in my book... so why not use a 32bit player on a 64bit OS? All the extra address space and registers isn't going to make a world of a difference...

np: New Order - Everything's Gone Green (Singles (Disc 1))

[SBeaver]

Originally Posted by Leak

Since you can't mix 32 and 64bit code in an application this is rather unlikely.

Then again, media playback isn't exactly something that begs for a 64bit app anyway in my book... so why not use a 32bit player on a 64bit OS? All the extra address space and registers isn't going to make a world of a difference...

np: New Order - Everything's Gone Green (Singles (Disc 1))

ac3/dts passthrough requires a 64bit app, or some kind of hack.
This goes for all vista x64 systems afaik, and so far 64bit ffdshow is the only thing that works.
Which in turn forces me to use a 64bit player and that is where the trouble starts. This should be a more important problem to solve when more and more move to vista x64.

edit: couldn't the 32bit player + ffdshow split out the audio as usual, and then send that to a 64bit application? There must be some line of communication that can be used

[Romario]

Can someone update x64 builds of ffdshow, please? And add multi-thread decoding to 64-bit ffdshow.

Thanks.

[cca]

Originally Posted by SBeaver

ac3/dts passthrough requires a 64bit app, or some kind of hack.
This goes for all vista x64 systems afaik, and so far 64bit ffdshow is the only thing that works.
Which in turn forces me to use a 64bit player and that is where the trouble starts. This should be a more important problem to solve when more and more move to vista x64.

Strange, since I use 32 bit ffdshow along with Zoom Player and Media Player Classic and my S/PDIF Passthrough works perfectly. I do need to check the "Maximize S/PDIF Compatibily" checkbox though. That's on Vista 64 with a Sound Blaster X-Fi Platinum.

[SBeaver]

Originally Posted by cca

Strange, since I use 32 bit ffdshow along with Zoom Player and Media Player Classic and my S/PDIF Passthrough works perfectly. I do need to check the "Maximize S/PDIF Compatibily" checkbox though. That's on Vista 64 with a Sound Blaster X-Fi Platinum.

Well ever since vista was released I've been reading about people like you who say everything is ok, maybe creative has some workaround in their drivers but it doesn't work for anyone else.