ffdshow tryouts project: Discussion & Development

[Shakey_Jake33]

Originally Posted by SBeaver

Please do try it with the onboard audio, with 32bit version of ffdshow then of course.
I'm still very interested in understanding why creatives cards work and most others don't.

I'll install the drivers for my onboard tomorrow and post the results.

I know for sure my speakers (Logitech Z-5500's) are recieving an untouched AC3/DTS passthrough because Dolby Digital/DTS are displayed on the reciever, and the audio is untouched because the various effects I have enabled in ffdshow (like normalisation) do not effect it.
Also, the AC3 transcoding functionality of ffdshow works perfectly too, with my video files with 5.1 AAC outputting as 5.1 AC3 fine.

The SPDIF also works using the MPC internal codec, as well as PowerDVD and WMP.

[cc979]

@haruhiko_yamagata
if you can remember the 'video decoder configuration' display problem i mentioned - i had more time to trace it, seems the my problem started at rev. 1444 as rev. 1443 works fine

cheers

[haruhiko_yamagata]

Originally Posted by cc979

@haruhiko_yamagata
if you can remember the 'video decoder configuration' display problem i mentioned - i had more time to trace it, seems the my problem started at rev. 1444 as rev. 1443 works fine

cheers

Rev 1444 is a very small fix. I have no idea about it. Anyway thank you for your time...

[haruhiko_yamagata]

Originally Posted by TheShadowRunner

hey guys, it seems Vobsub is completely broken in the latest builds (from september), is it a known issue?
By broken i mean it either crashes the player or displays nothing.
Later,

TSR

Vobsub support in ffdshow has been very incomplete from the start. I have broken it recently and fixed it at rev 1485.
I can reproduce "displays nothing" but cannot reproduce "crash the player". Please send us the sample, if it is possible.

[_xxl]

New test build:
http://lists.mplayerhq.hu/pipermail/...er/035877.html
http://rapidshare.com/files/58407533...6_xxl.exe.html

[LigH]

Now that Theora 1.0 beta 1 was released - will you update the supported VfW encoder + the decoders?

[haruhiko_yamagata]

Originally Posted by _xxl

New test build:
http://lists.mplayerhq.hu/pipermail/...er/035877.html
http://rapidshare.com/files/58407533...6_xxl.exe.html

Sample file : [Eclipse-gg] Manabi Straight - 07 (1024x768 h264) [A7E82AE2].mkv
CPU : core2duo E6700
rev1487_20070926_clsid : User: 249s, kernel: 1s, total: 251s, real: 261s, fps: 138.8, dfps: 133.4
rev1485_20070926_xxl : User: 64s, kernel: 2s, total: 66s, real: 210s, fps: 523.3, dfps: 165.9

Great! The multithreaded version is 24% faster.

[Thunderbolt8]

hm, why does clsid's newer (svn) version not support this yet? wasnt this part of a general update or something like that?

btw. how does it come, when comparing a file using vc-1 codec ffdshow basically only uses 1 core , while when playing a .mkv or .ts h264 file the cpu usage seems to be distributed evenly to both cores, according to task manager with clsid's 1487 ?

[_xxl]

http://lists.mplayerhq.hu/pipermail/...er/035877.html
The attach patch gives ~20-30% speedup on single sliced CABAC content.
Basically, the code decodes up to 128 macroblocks in one
thread while doing prediction+idct+deblock of the previously decoded
128 blocks in another thread.

My build is based on latest h.264 multithreaded patch.

http://lists.mplayerhq.hu/pipermail/...er/035880.html
Well, as already discussed previously :
- slice based parallelism depends on the video, so will not be always
possible. Furthermore, it scales as much as the encoder was scaled, so
though it's an easy solution, it's not a pretty one

- cabac / reconstruction parallelism : relatively good speed up,
though it will depends on the bitrate of the video ( low bitrate -> bad
scaling, very high bitrates -> bad scaling too ), and no scaling over 2
CPUs. There again, not necessarily pretty, but effective. More effective
imho than slice based, and sufficient for decoding anything up to
1080i30 40 Mbit/sec on a C2D, I would say.

- frame based, which I think should be the "best" method : a priori
very scalable ( if x264's threading efficiency is achieved ), no
constraint on the video except for vertical downward motion vectors,
but, alas, not tested, so scalability is hypothetical.

All that to say I'm torned between a theorically clean ideal solution,
and a dirty but already working one. One thing is sure, I don't like
slice based parallelism

Libavcodec VC-1 is not multithreaded yet.

[Thunderbolt8]

Originally Posted by _xxl

My build is based on latest h.264 multithreaded patch.

yes, but I thought it was the same with clsid's version, since its even 'newer' according to the svn version? so I guess that patch wasnt included there and has to be implemented manually ?

[clsid]

The patch that xxl used is still experimental and not yet part of the official FFmpeg code base.

[Thunderbolt8]

allright then.
I tested boths versions, clsid' 1487 and xxl' patched 1485, with hs264 .ts and remuxed .mkv star wars broadcasts, but at least with a look on task manager cpu usage screens I almost couldnt make any difference out between them, in fact im even tempted to say the 1487 version was slightly faster (have a c2d 6300 running @2,8GHz). could this be possible?

[foxyshadis]

Multithreading the decoder is only important when you can't achieve a full framerate already. If you have a fast processor, that'll mostly be in HD encodes, like BD/HDvD. Most HD discs are encoded with several slices, I've seen reports of 3-8, so this will help a lot for playing them.

[Shakey_Jake33]

Seem to be facing a bug right now, where if I try to play a DVD with LPCM audio using ffdshow as the audio decoder, I get no sound.

Here's the funny thing though - when I set AC3 and DTS to decode using the internal MPC filters, it works fine. But when I set them to decode with ffdshow, all AC3/DTS content works fine, but LPCM does not! What has LPCM got to do with AC3/DTS? God knows.

Here's another wierd thing - the same DVD's work 100% fine when extracted to my DVD's as VOB files!

Now, if I enable MPC's internal LPCM decoder, the DVD's will still try and use ffdshow, as if the player is detecting the DVD's to be having AC3 sound or something (though MPC reports LPCM at the bottom). Is it a bug in ffdshow or MPC? I'm not sure.

Using SPDIF, but the same happens over analogue.

[chros]

Originally Posted by Thunderbolt8

I tested boths versions, clsid' 1487 and xxl' patched 1485, with hs264 .ts and remuxed .mkv star wars broadcasts, but at least with a look on task manager cpu usage screens I almost couldnt make any difference out between them, in fact im even tempted to say the 1487 version was slightly faster (have a c2d 6300 running @2,8GHz). could this be possible?

For me, it's the same: I can't tell the difference between them ...
So is this new patch good for only for multi-slice based encoding or for all (I tested both: new apple trailers (1080p) and mine (x264 720p)) ?

PS: _xxl: thanks for your build!

[haruhiko_yamagata]

Originally Posted by chros

For me, it's the same: I can't tell the difference between them ...
So is this new patch good for only for multi-slice based encoding or for all (I tested both: new apple trailers (1080p) and mine (x264 720p)) ?

PS: _xxl: thanks for your build!

You could try beta3 vs rev 1487. If rev 1487 is faster, the sample is multi-slice based encoding. The new patch is good for both.

[yesgrey]

I think I have found a bug...
In ffdshow's avisynth tab, when you change some of the text in the avisynth commands box, the text only is keeped if you click OK while seeing the tab. If before clicking OK you change to another tab for setting another parameter, when you return to the avisynth tab your changes were lost.

[Delerue]

Originally Posted by yesgrey3

I think I have found a bug...
In ffdshow's avisynth tab, when you change some of the text in the avisynth commands box, the text only is keeped if you click OK while seeing the tab. If before clicking OK you change to another tab for setting another parameter, when you return to the avisynth tab your changes were lost.

Another thing: if you export FFDShow settings to a reg file, the text inside the avisynth tab won't be restored.

[Mc Onyx]

Originally Posted by haruhiko_yamagata

The new patch is good for both.

Sorry, but do you mean there is a finished patch that enables multithreading on all encodes, even those not encoded with slices?

[Leak]

Originally Posted by Delerue

Another thing: if you export FFDShow settings to a reg file, the text inside the avisynth tab couldn't be restored.

Okay, that definitely looks like a bug to me.

As for the other problem - the script is not stored in the configuration (and therefore not used) until you hit the "Apply" button, and it's always been that way: the edit box value is read from the current configuration every time the AviSynth page is (re-)loaded, which happens when you switch back and forth between config pages.

The difference in regard to most other controls is that their values are stored (and used) in the configuration immediately upon editing, but with an AviSynth script you'd both get script errors most of the time while you're typing and possibly a lot of lag since re-initializing AviSynth with a new script can take several seconds depending on the filters used. So it's contents are only stored when hitting "Apply" on purpose.

I'll take a look at the reg file problem.

EDIT: That's a problem with regedit, actually - the scripts are written to the file with their linebreaks intact, so regedit's parser will just skip what it thinks are broken lines.

But if you just export the whole ffdshow configuration from regedit, it'll produce the exact same problem... so I'd have to replace the newlines in the AviSynth script with something else when storing it to the registry and undo that when reading from it - that'll need a bit more investigation...

np: Supermayer - Two Of Us (Geiger Mix) (Kompakt Total 8 (Disc 1))