Log in

View Full Version : ffdshow tryouts project: Discussion & Development


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 [134] 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308

Snowknight26
16th February 2009, 22:05
I was using ffdshow_rev2686_20090214_dbt.exe and r2671, forget which build. Both showed the issue.

1. Yes, because when I look at the second instance of ffdshow, the input is YV12. The first instance of ffdshow is outputting "YV12,adj."
2. The issue only seems to happen when there are two instances though, and only when taking screenshots with the one thats decoding the YV12.
3. Seems to happen every time there are two instances with whatever -> YV12 -> renderer. I'll try to find out which revision is the first one that shows the issue.

Edit: Switching to YUV2/RGB32 output in the first instance makes the issue disappear.
Just tried r2643 and it was fine. r2649 showed the problem again, so I'm guessing it was r2646.

mark0077
16th February 2009, 23:30
Guys, did something go wrong in some of these latest builds as now using ffdshow yv12 to rgbhq looks like the older versions... aka really bad.

Using build 2693 and tried both ffdshow and mpc-hc's mpeg2 decoder. Outputting yv12 fixes the problem... so its definitely the internal yv12 to rgbhq conversion. I have high quality conversion turned on. I will try and track down which build this started in.

mark0077
16th February 2009, 23:35
Guys, did something go wrong in some of these latest builds as now using ffdshow yv12 to rgbhq looks like the older versions... aka really bad.

Using build 2693 and tried both ffdshow and mpc-hc's mpeg2 decoder. Outputting yv12 fixes the problem... so its definitely the internal yv12 to rgbhq conversion. I have high quality conversion turned on. I will try and see what build this started in.

EDIT: Thats weird, restarting mpc a few times and the quality is back to perfect.... can't understand that...

iron2000
17th February 2009, 03:42
Is ffdshow dropping support for DScaler?

Tested and DVD plays alright on 2693 :)

Jeremy Duncan
17th February 2009, 07:52
All is well with the new ffdshow release clsid made today (2693).
The rgb conversion is good quality, and the audio is fine, and the root menu is ok too.
If nothing else is done to ffdshow then right now it looks ok to me. But keep up the good work as you see fit. :)

cca
17th February 2009, 08:43
Will there ever be a way for the user to prioritize the which colorspace to output? In ffdhsow-mt when I had all colorspaces checked I was getting NV12 as output, which is the best for my ATi card. In the recent ffdhsow builds after -mt merged into the main branch, it always outputs YUY2 unless I disable everything else! Disabling colospaces is a bad idea though, I prefer to have a priority order.

THX-UltraII
17th February 2009, 10:09
I just made a switch on my HTPC and skipped AC3Filter and going to use the ffdshow Audio Decoder for my audio signal.

I ll first tell you guys my setup and what I want:
I have a HTPC with three different types of media that I play: .mkv, .wmv and VIDEO_TS folders (standard def. dvd). I own the ATI HD4350 and managed to get sound over HDMI work. This way I can PCM passthrough the audio to my receiver. I also use ReClock and selected the internal AC3 encoder box in the ReClock properties.

So I ve installed ffdshow (the MMX version, this was the latest one. Dont know which version to use for best results, I have a intel quad-core processor, So first question id which version to use for my setup) and choose ONLY the audio decoder to install (I use other decoders for my video).

1.
codecs
I see that here I can disable and enable decoding for different formats. I think I ll have to select eg. AC3 here (my VIDEO_TS material contains an AC3 signal), but I see two option to decode: Liba52 and Libavcodec. Which one should I choose here? Am I correct when I say that when picking one of the two here decodes the AC3 signal and sends it as PCM to ReClock?

2.
mixer
Don t know if I have to set it on ENABLED and SAME AS INPUT or on DISABLED.

3.
output
- pass-through AC3/DTS: I think I don t have to check this one in my setup correct?
- Supported output sample formats: check 16,24 and 32 bit correct?
- Dont check AC3 encode (this is done by ReClock correct?) and LPCM correct?
- Connect to any filter; leave it like that?
- Allow direct-to-file output, check or uncheck?

that s it for now. Sorry for the bad English.

haruhiko_yamagata
17th February 2009, 11:00
EDIT: Thats weird, restarting mpc a few times and the quality is back to perfect.... can't understand that...I guess you had wrong settings about MPEG-2 interlacing flag in MPC.
MPC's settings about MPEG-2 decoder aren't saved if they are changed during playback. You have to launch MPC, change the settings and quit.

haruhiko_yamagata
17th February 2009, 11:02
Is ffdshow dropping support for DScaler?

Tested and DVD plays alright on 2693 :)
It works for me. Please make sure you have installed DScaler plugins on installation of ffdshow. Also make sure you have working installation of DScaler.

haruhiko_yamagata
17th February 2009, 11:03
Will there ever be a way for the user to prioritize the which colorspace to output? In ffdhsow-mt when I had all colorspaces checked I was getting NV12 as output, which is the best for my ATi card. In the recent ffdhsow builds after -mt merged into the main branch, it always outputs YUY2 unless I disable everything else! Disabling colospaces is a bad idea though, I prefer to have a priority order.I would love to, just don't have enough time to do that.

Jeremy Duncan
18th February 2009, 00:30
ffdshow audio osd.

I can see the output integer, but I cannot see the input integer selected if I choose "All integer" from the uncompressed tab.

As I understand it. Ideally I would have 16 bit integer from the codecs tab, uncompressed tab.
And in the output tab I select 16 bit integer.
There is less, "Dither".

"Silence only results if the subtraction is of identical data. Staying withing the 16 bit realm, from beginning to end, will produce silence, working with 24 bit data, without converting to 16 bit, will produce silence. Not only the part that started as silence, but also the part of the file that has a signal can be zeroed out completely if all operations stay within the bounds of 16 bit, or 24 bit, where ever we are operating."

"The result is not silence because the “dither” subtracted is not the same data."

link (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=49843&view=findpost&p=615158)

If the input integer in uncompressed is the same as the output integer, then the dither will be the same and theoretially the sound should be good.

But I select All integer in the uncompressed tab, so want to be able to know which integer is being selected? :)

STaRGaZeR
18th February 2009, 00:45
I've been testing the now merged ffmpeg-mt and all I can say is that it works way better than when it was a different branch. No crashes whatsoever. The garbled frames issue when seeking is vastly reduced, I've only found it in some samples. There are no rainbows but instead there is a bit of blockiness and other frames rests:

http://thumbnails7.imagebam.com/2705/11619e27046860.gif (http://www.imagebam.com/image/11619e27046860)

As you can see the garbage is part of a previous frame. Found this in Blu-ray's with 4 ref frames and with MBAFF streams. Also it seems to be random, I can't reproduce the same blockiness when seeking to a concrete frame twice. Everything else is perfect in ffmpeg-mt as far as I've tested.

On a side note, I've been playing with clsid's and xvidvideo.ru's x64 builds and I found something interesting. With clsid's builds the Resize filter is slow as hell compared to the 32-bit version, while in xvidvideo.ru's builds isn't. In fact it's faster than 32-bit. But in clsid's libavcodec MP3 decoder works and with mp3lib the sound is garbled, in xvidvideo's libav MP3 and mp3lib both don't work.

shaolin95
18th February 2009, 02:50
Guys a quick Q.
My X-Fi Prelude max output seems to be 24bit so should I select output 24bit in ffdshow audio instead of 32bit float?
Thanks

Jeremy Duncan
18th February 2009, 03:11
Guys a quick Q.
My X-Fi Prelude max output seems to be 24bit so should I select output 24bit in ffdshow audio instead of 32bit float?
Thanks

If the material is 24 bit then you would be best to choose 24 bit integer in the codecs uncompressed tab, and 24 bit in the output tab.

But 16 bit is a standard that the audio industry uses, I gather or I understand by gleaming the audio thread I linked too
(last 2 pages.).
So it's easy to think movies use 16 bit integer as a standard too, rather than 24 bit which even audio professionals argue over it's value when compared to 16 bit integer.

Also, if you choose the wrong value for the integer the result is dithering which brings bad audio result.
if the material is 16 bit integer then just because your sound card does 24 bit integer and you use 24 bit integer output this does not mean the result would be better than if you used 16 bit integer.

The idea is to get the integers to match so the Dithering doesn't ruin the sound.
If the integer values are mismatched then there will be uneven dithering matching resulting in poor audio quality.

They use 16 bit integer for dvd's I'm guessing. :)

shaolin95
18th February 2009, 03:56
Im only using Bluray rips and lately isntead of ripping to mkv I am just ripping the full mt2s file.
That means that most of the time 16bit would be the one to choose according to your information then.
Also based on your info then having that 32bit float option serves no real purpose. Right?
Thanks for the reply btw. :-)

Jeremy Duncan
18th February 2009, 04:21
Im only using Bluray rips and lately isntead of ripping to mkv I am just ripping the full mt2s file.
That means that most of the time 16bit would be the one to choose according to your information then.
- I think so.

Also based on your info then having that 32bit float option serves no real purpose. Right?
- I think so. After reading a few threads on this it's really between 16 and 24 bit integer, not float.

Thanks for the reply btw. :-)

Having set my audio to 16 bit integer I find the sound to be better in sddvd movies. That tells me the movie uses 16 bit integer.

Dark Shikari
18th February 2009, 04:39
Having set my audio to 16 bit integer I find the sound to be better in sddvd movies. That tells me the movie uses 16 bit integer.Most audio formats rely on floating point encoding internally regardless of the "actual" input bit depth. That is, they decode to 32-bit float, too. Outputting to 16-bit integer after that requires extra processing to downsample the resulting values.

Jeremy Duncan
18th February 2009, 05:37
Most audio formats rely on floating point encoding internally regardless of the "actual" input bit depth. That is, they decode to 32-bit float, too. Outputting to 16-bit integer after that requires extra processing to downsample the resulting values.

Yes, I read that integers use more cpu. But that's not what were talking about. Were talking about dithering and how to get the best result.

I think your saying using a output of 16 bit integer is not as good as using 32 float?
But that statement is based on the uncompressed in Codecs using 32 float?

Edit.
I just did a basic test and the speed is roughly the same is I choose 16 bit integer for uncompressed and output, or if I choose 32 bit float in uncompressed and output.

- The correct one would be to use 32 bit float in the codec uncompressed tab and in the output tab?

Edit,
I discovered that if I use 32 bit float in the codecs uncompressed tab and the ffdshow audio output tab I can open and use wmp to play mp3 again! :D

It now works regardless if I use spdif or analog, ffdshow audio doesn't get used and wmp opens as a result!

So I will use float 32 unless somebody gives a pretty good reason not too. :)

THX-UltraII
18th February 2009, 08:25
I just made a switch on my HTPC and skipped AC3Filter and going to use the ffdshow Audio Decoder for my audio signal.

I ll first tell you guys my setup and what I want:
I have a HTPC with three different types of media that I play: .mkv, .wmv and VIDEO_TS folders (standard def. dvd). I own the ATI HD4350 and managed to get sound over HDMI work. This way I can PCM passthrough the audio to my receiver. I also use ReClock and selected the internal AC3 encoder box in the ReClock properties.

So I ve installed ffdshow (the MMX version, this was the latest one. Dont know which version to use for best results, I have a intel quad-core processor, So first question id which version to use for my setup) and choose ONLY the audio decoder to install (I use other decoders for my video).

1.
codecs
I see that here I can disable and enable decoding for different formats. I think I ll have to select eg. AC3 here (my VIDEO_TS material contains an AC3 signal), but I see two option to decode: Liba52 and Libavcodec. Which one should I choose here? Am I correct when I say that when picking one of the two here decodes the AC3 signal and sends it as PCM to ReClock?

2.
mixer
Don t know if I have to set it on ENABLED and SAME AS INPUT or on DISABLED.

3.
output
- pass-through AC3/DTS: I think I don t have to check this one in my setup correct?
- Supported output sample formats: check 16,24 and 32 bit correct?
- Dont check AC3 encode (this is done by ReClock correct?) and LPCM correct?
- Connect to any filter; leave it like that?
- Allow direct-to-file output, check or uncheck?

that s it for now. Sorry for the bad English.

Leak
18th February 2009, 09:59
Please stop re- and crossposting the same post over and over again - it's against the forum's rules.

You won't get more of an answer if you do that, you'll just manage to get on people's nerves.

And before you ask - no, I can't answer this as I never used SPDIF and/or HDMI and just have 2 speakers hooked up to my PC...

leeperry
18th February 2009, 10:37
So it's easy to think movies use 16 bit integer as a standard too, rather than 24 bit which even audio professionals argue over it's value when compared to 16 bit integer.
AC3 & DTS are lossy, but if properly encoded they "can" reach between 18 and 20bit(and 24 for "DTS 96/24" obviously) :
http://www.google.com/search?hl=en&newwindow=1&safe=off&q=ac3+dts+20+bit&lr=

I also output 32 float so both Ozone4(through a VST>winamp2 wrapper) and Reclock work in the highest possible resolution(Reclock will convert to this anyway as this is its internal working res)...hell I even send 32 float to my audio drivers(24/96 M-Audio Audiophile USB) :D

each integer/float conversion is theoritically highly lossy, so refrain from doing them....and just for the record Ozone4 internally works in 64bit float :o

ikarad
18th February 2009, 11:53
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

haruhiko_yamagata
18th February 2009, 12:54
I've been testing the now merged ffmpeg-mt and all I can say is that it works way better than when it was a different branch. No crashes whatsoever. The garbled frames issue when seeking is vastly reduced, I've only found it in some samples. There are no rainbows but instead there is a bit of blockiness and other frames rests:

As you can see the garbage is part of a previous frame. Found this in Blu-ray's with 4 ref frames and with MBAFF streams. Also it seems to be random, I can't reproduce the same blockiness when seeking to a concrete frame twice. Everything else is perfect in ffmpeg-mt as far as I've tested.

I think the problem may be coming from the incomplete parsing of access units. It's being discussed here (http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=968).

Reimar
18th February 2009, 13:54
I think the problem may be coming from the incomplete parsing of access units. It's being discussed here (http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=968).

Assuming I understood correctly what you need here (namely detection of access unit boundaries from a stream of NAL units)...
This was discussed for MPlayer once, and we decided that complete parsing is actually not needed, and I think ff_h264_find_frame_end in libavcodec/h264_parser.c basically uses the same method.
It is in libmpdemux/video.c and this is the main part, maybe it helps ("i" contains the NAL unit number including the 0x100 - it is intended for annex B codec files, but should be easy to modify for the format mp4/mov uses):

// here starts the access unit end detection code
// see the mail on MPlayer-dev-eng for details:
// Date: Sat, 17 Sep 2005 11:24:06 +0200
// Subject: Re: [MPlayer-dev-eng] [RFC] h264 ES parser problems
// Message-ID: <20050917092406.GA7699@rz.uni-karlsruhe.de>
if((i&~0x60) == 0x101 || (i&~0x60) == 0x102 || (i&~0x60) == 0x105)
// found VCL NAL with slice header i.e. start of current primary coded
// picture, so start scanning for the end now
in_picture = 1;
if (in_picture) {
i = sync_video_packet(d_video) & ~0x60; // code of next packet
if(i == 0x106 || i == 0x109) break; // SEI or access unit delim.
if(i == 0x101 || i == 0x102 || i == 0x105) {
// assuming arbitrary slice ordering is not allowed, the
// first_mb_in_slice (golomb encoded) value should be 0 then
// for the first VCL NAL in a picture
if (demux_peekc(d_video) & 0x80)
break;
}
}

clsid
18th February 2009, 15:04
There is a bunch of discussions on the ffmpeg-dev mailinglist about thus subject. Someone is working on implementing it.

tetsuo55
18th February 2009, 21:01
Guys a quick Q.
My X-Fi Prelude max output seems to be 24bit so should I select output 24bit in ffdshow audio instead of 32bit float?
Thanks

I know its a bit late but the X-Fi uses 32bit internally, so if you feed it anything lower it will convert anyway.
It''s probably best to use 32bit

bwlonsdale
18th February 2009, 21:40
Hi all - does someone know if there should be any difference in having FFDShow decode AC3 against passing it through to my AMP and have it do the decoding?

I've noticed that the bass is reduced when I let FFDShow decode the stream.

I'm using an ATI 4600, set for multichannel out (5.1). I've made sure there are no options selected in the sound control panel applet, i.e. no effects or any bass management settings are selected, it shouldn't be doing anything to the audio.

My amp is a Denon 1909. I only noticed this the other day when I was messing with Slysoft's Reclock. I had an issue with it so I uninstalled it and then had FFDShow temporarily pass through the AC3 direct to the amp and then I noticed the bass volume either seemed to be louder or at least it gave more of a thump. It's not my imagination at work, I had someone else check too :)

I have it in my head that there was some issue around bass being 15db quieter when decoded by FFDShow, but that was something I either read in passing or have just made up in my head.

I have FFDShow configured to decode AC3 and the mixer set for 5.1 output, no other options selected for bass management etc. Pretty much everything is at defaults in the audio side of things.

Can anyone confirm or deny I need to be doing anything with bass management if I let FFDShow do the decoding?

This is in Vista Media Center - didn't try anything else yet. I like to let FFDShow do the decoding because then I can use the volume control on the VMC remote rather than reach for another one when I need to turn it down/mute.

Well at least I know I didn't imagine this now:-

http://www.avforums.com/forums/home-cinema-pcs/805938-bass-setup-htpc-av-receiver.html

The LFE channel is reduced 10db when it's encoded on DTS/DD tracks.

So....does FFDShow compensate in anyway for the -10db loss, or do I need to set that manually via LFE Crossover configuration?

I notice the default on there is -2db gain, which seems a little arbitrary. Maybe there was a decision made not to do any compensation or have that level for some other reason? I would guess a tick box on the LFE Crossover tab to apply -10db correction could be useful? However, I don't want to have to specify a crossover frequency when my amp is doing all that side of things itself, something separate would seem more logical.

There's maybe a setting on my amp for this, but since the HTPC isn't only going to be processing DD/DTS, to have a universal -10db gain on the amp is going to make the opposite problem appear on other sources.

shaolin95
19th February 2009, 05:37
I know its a bit late but the X-Fi uses 32bit internally, so if you feed it anything lower it will convert anyway.
It''s probably best to use 32bit
Thanks all of you for the answers to this.
I will then use 32bit float indeed. :-)

haruhiko_yamagata
19th February 2009, 11:32
ffdshow's grab function takes screenshots with bad colors:
http://www.stfcc.org/misc/ffdshow.r2686.png
http://www.stfcc.org/misc/mpc-hc.r990.png

The filter chain was something like Haali Media Splitter -> ffdshow (decoding H.264) -> ffdshow (decoding YV12 - took screenshot) -> Renderer (in MPC-HC).
Thanks, I have fixed at rev 2699. It was more generic problem than just one of grab filter.

haruhiko_yamagata
19th February 2009, 11:33
Assuming I understood correctly what you need here (namely detection of access unit boundaries from a stream of NAL units)...
This was discussed for MPlayer once, and we decided that complete parsing is actually not needed, and I think ff_h264_find_frame_end in libavcodec/h264_parser.c basically uses the same method.
It is in libmpdemux/video.c and this is the main part, maybe it helps ("i" contains the NAL unit number including the 0x100 - it is intended for annex B codec files, but should be easy to modify for the format mp4/mov uses):

Thank you for the info.
Then I might have guessed wrong. The issue may not related to parsing.

leeperry
19th February 2009, 12:20
I'm not sure anyone cares, but it would appear that the mixer coeffs for stereo are not too accurate :
http://ac3filter.net/guides/mixing_matrix

ffdshow sets them all to 1, so the center channel is too loud, and so is the LFE....and it doesn't accept 4 digits after the coma so it's not possible to use the 0.7071 value.

the ac3filter site doesn't say anything about BackL/BackC/BackR...so I'm not too sure about these....setting them to 1/0.7071/0 for L and 0/0.7071/1 for R seems to work pretty fine :

http://www.image-load.eu/out.php/i145749_mix.png

STaRGaZeR
19th February 2009, 13:17
Thank you for the info.
Then I might have guessed wrong. The issue may not related to parsing.

As you can see in the image the garbage has the form of a slice, and almost always happens in the bottom of the frame.

LSudlow
19th February 2009, 19:03
leeperry, I don't know if it's related, but I've always felt the same way about the Dolby Pro Logic II decoder. The center is WAY too loud and the surrounds are way too weak. I don't know what the correct matrix values are, but I doubt the current ones are right.

mark0077
19th February 2009, 21:09
Hi all,

Just started playing with ffdshow resize in build 2699.

I happened to be playing a 1920 x 1080 .ts file, but when I set resize to "Specify Horizontal Size" and begin typing into the "New Size" width, media player classic+ffdshow crash. Have to restart them both.

Reproducible time after time. Maybe someone could take a look? Means I can't reliably use the resize to test different settings without a crash.

mark0077
19th February 2009, 22:05
Hi all,

I am back to tracking down bugs / quality differences in the following decoders.

libmpeg2 (in mpc-hc), libmpeg2 (in ffdshow) and libavcodec mpeg2 (in ffdshow)

In my DVD Quality thread which I am currently updating with as much info as I can give, one thing i came accross before was very bad dvd menu rendering with ffdshow. Below is a comparison of all three decoders. You would expect the highlighted area to be the same in at least libmpeg2 in mpc-hc and libmpeg2 in ffdshow but no, again ffdshow has a problem. This has been a problem for months, through many operating systems and drivers. It has nothing to do with interlacing settings as everything is been treated as progressive at every stage.

Note: I can't understand why the colors look so different also on these menu highlights.

http://img24.imageshack.us/img24/6749/comparisonty8.th.png (http://img24.imageshack.us/my.php?image=comparisonty8.png)
http://img511.imageshack.us/img511/4188/comparison2ux2.th.png (http://img511.imageshack.us/my.php?image=comparison2ux2.png)

leeperry
19th February 2009, 22:08
leeperry, I don't know if it's related, but I've always felt the same way about the Dolby Pro Logic II decoder. The center is WAY too loud and the surrounds are way too weak. I don't know what the correct matrix values are, but I doubt the current ones are right.
well try my coeffs, and see how it goes ;)
in the DPL/DPL2 matrixes, the "-" characters are definitely wrong I think.....they invert the phase of the left channel, not something you wanna do :o

LSudlow
20th February 2009, 00:19
well try my coeffs, and see how it goes ;)
in the DPL/DPL2 matrixes, the "-" characters are definitely wrong I think.....they invert the phase of the left channel, not something you wanna do :o

I pretty much do that, using the sliders rather than the custom matrix. 70% on the center and 140% on the surrounds sounds pretty close to my reciever's DPLII decoder. But I do hope some of the wizards here can figure out why the center is so overpowered and the surrounds underpowered when the matrix values of 1.0 should be right. It looks like the mixer's input or output aren't handling something correctly.
:thanks:

leeperry
20th February 2009, 12:06
I pretty much do that, using the sliders rather than the custom matrix. 70% on the center and 140% on the surrounds sounds pretty close to my reciever's DPLII decoder. But I do hope some of the wizards here can figure out why the center is so overpowered and the surrounds underpowered when the matrix values of 1.0 should be right. It looks like the mixer's input or output aren't handling something correctly.
:thanks:
well don't use the sliders on the DPL/DPL2 matrixes, as their left channel has inverted phase..
you can't use 1.0 for each channel, there are coeffs(0.7071 for center channels) that need to be followed....see the link above on the ac3filter website.

anyway, I've tried my matrix on many movies, it's great! :cool:

Kado
20th February 2009, 23:29
@shaolin95, Jeremy Duncan
Check this article (http://mp3decoders.mp3-tech.org/24bit.html) regarding 16 and 24bit audio.

squid_80
20th February 2009, 23:52
in the DPL/DPL2 matrixes, the "-" characters are definitely wrong I think.....they invert the phase of the left channel, not something you wanna do :o
IIRC that's not strictly wrong, the channel may be inverted before encoding. But the decoder should be taking care of fixing it since it has access to the specific flag in the AC3 stream

haruhiko_yamagata
21st February 2009, 03:46
I'm not sure anyone cares, but it would appear that the mixer coeffs for stereo are not too accurate :
http://ac3filter.net/guides/mixing_matrix

ffdshow sets them all to 1, so the center channel is too loud, and so is the LFE....and it doesn't accept 4 digits after the coma so it's not possible to use the 0.7071 value.

the ac3filter site doesn't say anything about BackL/BackC/BackR...so I'm not too sure about these....setting them to 1/0.7071/0 for L and 0/0.7071/1 for R seems to work pretty fine :

http://www.image-load.eu/out.php/i145749_mix.pngIt should be 0.7071. I meant to set 0.7071, actually did not.
Is any developer interested in ffdshow audio? I'm not interested in it too much.

lych_necross
21st February 2009, 07:29
@shaolin95, Jeremy Duncan
Check this article (http://mp3decoders.mp3-tech.org/24bit.html) regarding 16 and 24bit audio.

That confirms what I suspected about 24bit audio. For the most part, it is not needed, but nice when it is done properly.

Mr VacBob
21st February 2009, 07:45
I've been testing the now merged ffmpeg-mt and all I can say is that it works way better than when it was a different branch. No crashes whatsoever. The garbled frames issue when seeking is vastly reduced, I've only found it in some samples. There are no rainbows but instead there is a bit of blockiness and other frames rests:

http://thumbnails7.imagebam.com/2705/11619e27046860.gif (http://www.imagebam.com/image/11619e27046860)

As you can see the garbage is part of a previous frame. Found this in Blu-ray's with 4 ref frames and with MBAFF streams. Also it seems to be random, I can't reproduce the same blockiness when seeking to a concrete frame twice. Everything else is perfect in ffmpeg-mt as far as I've tested.

Even if it's a race condition (= not reproducible), I can try to fix it with a sample. It can take pretty much forever to binary-search that kind of bug, though.

leeperry
21st February 2009, 10:13
It should be 0.7071. I meant to set 0.7071, actually did not.
Is any developer interested in ffdshow audio? I'm not interested in it too much.
well, it's user selectable, so no big deal :o
I'm not sure I could hear a diff between 0.707 and 0.7071 anyway :D
That confirms what I suspected about 24bit audio. For the most part, it is not needed, but nice when it is done properly.
each integer/float conversion is potentially very lossy...avoid them if you can.

also, how can I make sure that audio files remain in 32 float from start to end ? by decoding w/ the internal decoders ?
coz if I use madflac or MPC's audio MP3 decoder, the source is shown to be "PCM uncompressed"....meaning it's converted to 32 float when it goes through my winamp2 plugin? and then remains in 32 float when sent to my audio drivers(I've only checked 32float in the output section)

I've tried to use the internal FLAC decoding, but it lacks a source filter apparently...but FLAC is lossless so it's not as important as mp3 for instance.

haruhiko_yamagata
21st February 2009, 14:45
Even if it's a race condition (= not reproducible), I can try to fix it with a sample. It can take pretty much forever to binary-search that kind of bug, though.
Well, it may be DirectShow specific. I would rather like to ask you to take a look at this (http://forum.doom9.org/showthread.php?p=1251292#post1251292).
I have copied the sample here (http://ffdshow-tryout.sourceforge.net/doom9/full_metal_panic_blocky_at_100-105sec_with_ffmpeg-mt.m2ts) for convenience.

mark0077
21st February 2009, 15:28
haruhiko_yamagata any ideas about the bug I posted earlier regarding DVD Menu highlighting and positioning problems with ffdshow. I imagine it would be a small fix but would be great to get it off the list of ffdshow problems. :D

haruhiko_yamagata
21st February 2009, 16:29
haruhiko_yamagata any ideas about the bug I posted earlier regarding DVD Menu highlighting and positioning problems with ffdshow. I imagine it would be a small fix but would be great to get it off the list of ffdshow problems. :D
It won't be a easy fix. Because I know nothing about how DVD menu is handled, I have to read all the code. And search technical documentation about DVD menu and read it. If I could read through the code, still it may be difficult to understand...

leeperry
21st February 2009, 16:45
haruhiko_yamagata any ideas about the bug I posted earlier regarding DVD Menu highlighting and positioning problems with ffdshow. I imagine it would be a small fix but would be great to get it off the list of ffdshow problems. :D
w/ what player/renderer?
MPC HC and HR/EVR are not too DVD-friendly, mostly the m$ DVD Navigator is at fault I think :o
KMP lets you select other DVD navigators(nero/cyberlink/intervideo/nvidia), did you try that?
your last resort will be the keyboard arrows plus CTRL(or ALT, can't remember) to navigate the menus.

clsid
21st February 2009, 17:10
Maybe Leak knows how to fix that DVD menu issue.

STaRGaZeR
21st February 2009, 17:24
Even if it's a race condition (= not reproducible), I can try to fix it with a sample. It can take pretty much forever to binary-search that kind of bug, though.

This can perfectly be a ffdshow issue. You can use MSG00 ED.mkv, here you have a larger sample to test: http://www.megaupload.com/?d=XFE6RWJ0 (407MB)

I've tested Haali's splitter and Gabest splitter with the same result. You may need to seek a lot to see it. It seems that the larger the file the easier it is to see the blockiness when seeking and this one is "small".

Well, it may be DirectShow specific. I would rather like to ask you to take a look at this (http://forum.doom9.org/showthread.php?p=1251292#post1251292).
I have copied the sample here (http://ffdshow-tryout.sourceforge.net/doom9/full_metal_panic_blocky_at_100-105sec_with_ffmpeg-mt.m2ts) for convenience.

I confirm that with other MBAFF sources.