ffdshow tryouts project: Discussion & Development

[tal.aloni]

I see what you're saying. It seems like you can change this manually on the fly but doing so seems to crash a lot when you click apply. Also, it seems to only be related to NV12 output. I switched to Ati's plain adaptive deinterlacer which works under YUY2 and it didn't jerk but the deinterlacing wasn't nearly as good as vector adaptive.

I'm trying to understand what you and MatMaul are talking about. lets break it down:
Interlaced movie + output flag => hardware deinterlacing (actual deinterlacing if bob is selected)
Interlaced movie + no output flag => no hardware deinterlacing
progressive movie + output flag => no hardware deinterlacing
progressive movie + no output flag => no hardware deinterlacing

where is the problem?

Thanks for the feedback,
Tal Aloni

[tal.aloni]

Is there any chance to implement yadif deinterlacing? Is it even possible?

Its not perfect, but you can use it via AviSynth,
(there is a custom version for avisynth, see here: http://forum.doom9.org/showthread.php?t=124284).
direct integration seems somewhat complicated.

[haruhiko_yamagata]

No, I don't believe that is it. I have some material that mixes hard and soft telecine which exhibits the same behavior. It seemed to me that the flag was permanently set to interlaced if the option was checked. Do nVidia based cards have the same problem?If you are talking about MPEG-2 telecine samples, I imported code from MPC that flag telecine as "progressive". Does it help?

If the pictures are not flagged, it wouldn't be too CPU intensive to analyze the pictures to see if they are interlaced or not.
Field order should be more difficult though.

As for yadif, I'm reading the source code. It doesn't seem to be very easy.

[tal.aloni]

I've posted the two patches for the two new features,
both are very basic changes, and easy to understand.

which project admin is volunteering to review my work?

Thanks,
Tal Aloni

p.s. can't wait for the SVN fame! :)

[haruhiko_yamagata]

I managed to develop another essential feature,
this one has been requested several times in the past:
the ability to deinterlace only interlaced sources (interlaced flag is set)

I added another checkbox to the top of the "Deinterlacing" section, labeled "Deinterlace all frame types" (perhaps this is not the best name)
Not a very good label, please re-consider. Users may not be able to understand what the check box does.

Is more simple implementation possible? Is it really required to patch for all deinterlacers?

Please do not use tabs.
Please create a separate patch file for cosmetic changes (and please change minimumly). I know it's a bit of work, but it is necessary to review the patch and strictly done in FFMpeg and most other projects.

[haruhiko_yamagata]

I've posted the two patches for the two new features,
both are very basic changes, and easy to understand.

which project admin is volunteering to review my work?

Thanks,
Tal Aloni

p.s. can't wait for the SVN fame! :)
I think the audio part is OK.
clsid, _xxl: Could you comment or commit?

[DigitalDeviant]

I'm trying to understand what you and MatMaul are talking about. lets break it down:
Interlaced movie + output flag => hardware deinterlacing (actual deinterlacing if bob is selected)
Interlaced movie + no output flag => no hardware deinterlacing
progressive movie + output flag => no hardware deinterlacing
progressive movie + no output flag => no hardware deinterlacing

where is the problem?

Thanks for the feedback,
Tal Aloni

The problem is progressive movie w/ pulldown flags + output flag is causing the video to jerk back and forth.

[_xxl]

I think the audio part is OK.
clsid, _xxl: Could you comment or commit?
Yes, please commit it.

[_xxl]

I remembered that some time ago I had compiled libavcodec for x64 using MinGW GCC 64 and no crashes were reported.
Maybe that build was not properly tested...
You could try to disable all asm from ffmpeg and compile just C part with MinGW GCC 64?

[tal.aloni]

Not a very good label, please re-consider. Users may not be able to understand what the check box does.

Is more simple implementation possible? Is it really required to patch for all deinterlacers?

Please do not use tabs.
Please create a separate patch file for cosmetic changes (and please change minimumly). I know it's a bit of work, but it is necessary to review the patch and strictly done in FFMpeg and most other projects.

1. I agree, I changed it to "Process frames flagged as progressive". (I'm open to suggestions)

2. I'm pretty sure there is no better, simpler implementation, but I could be wrong.
(if I remember correctly, mpeg2 could be a mix of interlaced and progressive parts, so a check of each frame is necessary)

3. You're absolutely right, I shoud have kept more closely to the project standard, and I created a new patch files (one for each feature) without tabs. [I did a few cosmetic changes in two / three places to improve readability, but I'm sure you'll agree it was justified]

http://iknowu.net/files/public/ffdshow/ffdshow-ProcessProgressive-RC4-OnePassNorm-RC4.zip

4. for the change-log / svn:

Added after beta4:
* Added an option to perform one-pass normalization. active when "Normalize" is checked and "Regain volume" is unchecked. (this mode is used to reach the highest possible loudness with minimum of possible artifacts)

* Added an option to deinterlace only frames flagged as "interlaced".

Thanks,
Tal Aloni

[MatMaul]

I'm trying to understand what you and MatMaul are talking about. lets break it down:
Interlaced movie + output flag => hardware deinterlacing (actual deinterlacing if bob is selected)
Interlaced movie + no output flag => no hardware deinterlacing
progressive movie + output flag => no hardware deinterlacing
progressive movie + no output flag => no hardware deinterlacing

here is the thing :
bob + interlaced => deinterlacing
weave + interlaced or progressive => no deinterlacing
bob + progressive => ?? adaptative or deinterlacing on a progressive content (beurk :p) ? I don't know and I prefer to rely on ffdshow rather on my graphic driver ^^

the bob or weave flag is set in a per-frame basis so I think it is easy to do the modification by adding an "auto" option.
in auto mode it would be good to deactivate HW deinterlacing (aka weave mode) if deinterlacing is used in ffdshow

EDIT : about your one pass normalization patch you mix functional and cosmetical (tab in a new if for example) changes and it is really difficult to read it. moreover your text editor doesn't seem to use the same number of spaces for the tab
it would be good to have 2 patchs : one functional and one cosmetical.

[tal.aloni]

bob + progressive => ?? adaptative or deinterlacing on a progressive content (beurk :p) ? I don't know and I prefer to rely on ffdshow rather on my graphic driver ^^

but when the content is flagged as progressive, interlaced flag will not be set at all! (the "bob" will not be passed down the stream, so you're "auto detection" is already implemented)

EDIT : about your one pass normalization patch you mix functional and cosmetical (tab in a new if for example) changes and it is really difficult to read it. moreover your text editor doesn't seem to use the same number of spaces for the tab
it would be good to have 2 patchs : one functional and one cosmetical.

as requested, I already got rid of all of the tabs, see 2 posts above, I hope it's ok.

Thanks for the feedback,
Tal Aloni

[haruhiko_yamagata]

Tal Aloni, thank you for your work.
I have committed.

const float TaudioFilterVolume::MUL_MAX=32.0f; //this is the max amplification allowed
I thought 32.0f is a bit too big. If the audio is very silent at the beginning, it creates noise if 3200% is applied. I prefer 400 for my setting, at max 1000 as upper limit IMO. I have changed to 10.0f.

1. I agree, I changed it to "Process frames flagged as progressive". (I'm open to suggestions)Much better :) .
Please wait a bit more.
(if I remember correctly, mpeg2 could be a mix of interlaced and progressive parts, so a check of each frame is necessary)
Yes, it's OK.

[MatMaul]

but when the content is flagged as progressive, interlaced flag will not be set at all! (the "bob" will not be passed down the stream, so you're "auto detection" is already implemented)
cool I haven't seen that
so I can use bob for all the video I am happy :)

and thanks a lot for the normalization patch it was my only reason to use ac3filter, now I don't need it anymore

[tal.aloni]

Thanks :)


I thought 32.0f is a bit too big. If the audio is very silent at the beginning, it creates noise if 3200% is applied.
Incorrect, this is only the initiall value and it will never be actually used, once a sample has been fed to the filter, mul will be equal or less then the max amplification selected.

EDIT:
Sorry, I got it now, but if some users select max amplification of 3200%. that's what they should get.

I recommend raising it back to 32.0f. (as long as this is the max amplification ffdshow allowes).


I prefer 400 for my setting,

me too.

[haruhiko_yamagata]

Sorry, I got it now, but if some users select max amplification of 3200%. that's what they should get.Correct, but allowing a value that is not recommended is not what I like to do.

[tal.aloni]

reason to use ac3filter, now I don't need it anymore

1. Thank Albain, if he wouldn't have started working on TrueHD / DD+ support, I would still be using AC3Filter.

2. There is a tiny difference between my implementation and AC3Filter's when handling overflow, without going into technicals, mine remains closer to the source (drastic drop of amplification when needed), while AC3Filter's takes a safer approach and "smoothing out" when exiting overflow.
I'm not sure the difference is audible at all.

Tal Aloni

[tal.aloni]

Correct, but allowing a value that is not recommended is not what I like to do.

then I recommend that you limit ffdshow's max amplification to 1000% as well.

[Leak]

then I recommend that you limit ffdshow's max amplification to 1000% as well.
What's happening now when a value is out of range?

Is it wrapped or clipped?

Personally, I like to set the amplification such that the "normal" parts don't hit any limit when amplified, but that the loud parts are quieted down - without having the overall volume stay down.

That really helps when watching at a low volume setting at night - I guess your patch fixed the distortion that this mode of operation caused now and then, right?

np: New Order - True Faith (Eschreamer Dub) (Brotherhood Extras)

[tal.aloni]

Personally, I like to set the amplification such that the "normal" parts don't hit any limit when amplified, but that the loud parts are quieted down - without having the overall volume stay down.

That really helps when watching at a low volume setting at night - I guess your patch fixed the distortion that this mode of operation caused now and then, right?


I was afraid to touch the existing "auto volume control" (a.k.a. "night mode" / DRC mode / regain volume checked), but I noticed that it has many problems.
[I may dig into it in the future, if the administrators will show readiness to let me modify existing code]

I just added another mode, it's the opposite of night mode, because it keeps the original dynamic range as much as possible.

[Reimar]

Using MinGW64 is easy. You can get the complete toolchain here:
http://sourceforge.net/project/showfiles.php?group_id=202880


You have a weird idea of easy, it does not come with MSys, nor does it integrate with msys as is (you have to copy the binaries and includes to the toplevel bin and includes), also the MSys uname is broken since it returns "i686" instead of e.g. "amd64" for uname -m.
Worse though, winnt.h is not compatible with -std=c99 which gcc uses due to using anonymous unions.
I noticed that most of the incorrect uses of "long" in FFmpeg have been replaced by x86_reg typedef - still dsputil_mmx.c does not compile for me with errors like
Error: `(%rcx,%r8d)' is not a valid base/index expression
(which makes no sense to me) or
Error: `(%r10,%eax,2)' is not a valid base/index expression
which obviously is true and probably a bug in the code.
I really don't see how someone should have managed to get a working compile of libavcodec with MinGW64...

[clsid]

You are correct that it is a bit crippled. Compiling complex projects will indeed be nearly impossible. But MSYS is not needed for compiling the stuff in ffdshow. We have fixed makefiles, so no need for stuff like configure. I basically just run make from the Windows command line.

The libavcodec code, as present in ffdshow SVN, compiles fine for me using MinGW64. The errors you mention look familiar to me. I have seen them before. Can't remember exactly when, might have been with an old build of MinGW64.

[tal.aloni]

As requested, here is a patch file with no cosmetic changes:
(Note: necessary changes in ffdshow_constants.h and resource.h are already comitted to the SVN)

http://iknowu.net/files/public/ffdshow/ffdshow-ProcessProgressive-RC6-Patch.zip

p.s.
here is a build based on rev 2232, I haven't modified anything of my own except for the label:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2232_20081019-RC6.exe

[Reimar]

You are correct that it is a bit The libavcodec code, as present in ffdshow SVN, compiles fine for me using MinGW64. The errors you mention look familiar to me. I have seen them before. Can't remember exactly when, might have been with an old build of MinGW64.

Sure they would, you just commented out the offending code. I will submit a proper patch to FFmpeg.
Meanwhile I can say that with the FFmpeg binary both AAC to AC3 and AC3 to MPEG layer 2 audio conversion works just fine.
Don't have DTS or EAC3 files around just now though.

[tal.aloni]

That really helps when watching at a low volume setting at night - I guess your patch fixed the distortion that this mode of operation caused now and then, right?

Well, now I did.
It has nothing to do with "one pass normalization",
but I made modifications to the Nomalization when "Regain volume" is unchecked, there should be no clipping now.
If you tend to use the old style normalization, please check out this build and tell us if you think we should replace the old one with the new one.
(I think there is a clear winner)

Build:
http://iknowu.net/files/public/ffdshow/AutoVolumeControl/ffdshow_rev2232_20081019-AutoVolumeControl-RC2.exe

Source & Patch:
http://iknowu.net/files/public/ffdshow/AutoVolumeControl/ffdshow-AutoVolumeControl-RC2-Patch.zip

p.s. I changed the GUI a little bit, to make it more clear that "Buffer Length" is only required when "Regain volume" is checked. I also changed "Normalization" to "Auto volume control".

[Leak]

p.s. I changed the GUI a little bit, to make it more clear that "Buffer Length" is only required when "Regain volume" is checked. I also changed "Normalization" to "Auto volume control".
Maybe you should gray out the dropdown box when "regain volume" isn't checked?

Anyway, I found a bit of audio (http://leak.no-ip.org/Stuff/SuddenDropInAudio.avi) (1,3MB, at the 3.5 second mark) where the amplification suddenly drops from +18dB to +8dB (with an audible click) for me - but without any apparent reason...

Without "regain volume" it stays that low, but I don't think that should happen as looking at that part of the audio in Audacity didn't show a sudden spike in the audio or anything...

[tal.aloni]

Anyway, I found a bit of audio (http://leak.no-ip.org/Stuff/SuddenDropInAudio.avi) (1,3MB, at the 3.5 second mark) where the amplification suddenly drops from +18dB to +8dB (with an audible click) for me - but without any apparent reason...

Without "regain volume" it stays that low, but I don't think that should happen as looking at that part of the audio in Audacity didn't show a sudden spike in the audio or anything...

Are you talking about ffdshow_rev2232_20081019-RC2.exe?
I played the file over and over, it plays perfect. with and without regain / normalize (drops from 12db to 8.7db)
are you sure you took the right sample?

Tal

Edit: I got you now, you're using a very high "max normalization" value (800%), so it takes time for the gain to rebuild after the peak. I suggest lowering "max normalization" to 400%.

[Leak]

Edit: I got you now, you're using a very high "max normalization" value (800%), so it takes time for the gain to rebuild after the peak. I suggest lowering "max normalization" to 400%.
Sorry, but using a high "max normalization" value is exactly what I want - I want to make sure I can still understand lowly spoken passages when I have to keep the volume down, without any gunshot waking up all our neighbours.

Basically, I'd want something that works like VLevel (http://vlevel.sourceforge.net/about/), but with a really fast response time as far as regaining volume is concerned - what's the current speed it regains volume at, and would it perhaps be possible to make that configurable?

np: New Order - Dracula's Castle (Waiting For The Sirens' Call)

[nautilus7]

I want to make sure I can still understand lowly spoken passages when I have to keep the volume down, without any gunshot waking up all our neighbours.What you need is called DRC. You can activate it for AC3, E-AC3, DTS, TrueHD decoding.

[tal.aloni]

Sorry, but using a high "max normalization" value is exactly what I want - I want to make sure I can still understand lowly spoken passages when I have to keep the volume down, without any gunshot waking up all our neighbours.

Basically, I'd want something that works like VLevel (http://vlevel.sourceforge.net/about/), but with a really fast response time as far as regaining volume is concerned - what's the current speed it regains volume at, and would it perhaps be possible to make that configurable?

Tehcnically, its tied to the source sampling rate, but @ 44,100hz it's about 100% every 20 seconds, it may be too slow for some purposes, but the idea is to adapt to scenes (keep low at gunshots scene). 10x faster than that, you'd be killing the frequency response completely.
maybe x2 / x3 will be better for some purposes.

In the video you sent me, the peak was 0.57 (float). when normalizing to 400%, 0.57 will sound exactly like 0.25 peak in another scene, which is still reasonable.
when choosing 800%, you're making 0.57 and 0.125 sounds equal, I'd say it's a bit too much, but that's just my opinion.

[Leak]

What you need is called DRC. You can activate it for AC3, E-AC3, DTS, TrueHD decoding.
I did, and I didn't like the effect - and it isn't tweakable, either. (At least in ffdshow...)

[tal.aloni]

I did, and I didn't like the effect - and it isn't tweakable, either. (At least in ffdshow...)

1. ffdshow's "Volume Control" / "Normalization" is actually a DRC.

2. DRC should have some control over it, maybe next week :)

3. I'm pretty sure you couldn't be satisfied, because you're asking for the impossible. (in real time, anyway), but just out of curiousity, here are two builds on steroids, I wonder what you would think:
one has x3 regain speed, the other x5.

http://iknowu.net/files/public/ffdshow/AutoVolumeControl/ffdshow_rev2232_20081019-AutoVolumeControl-RC2-Step-0.03.exe

http://iknowu.net/files/public/ffdshow/AutoVolumeControl/ffdshow_rev2232_20081019-AutoVolumeControl-RC2-Step-0.05.exe

[Leak]

1. ffdshow's "Volume Control" / "Normalization" is actually a DRC.
It is, but it's done waaay to early - if anything, DRC needs to be done as a postprocessing step; for instance I'm using the equalizer to filter out most bass at night so doing DRC before that is rather useless.

2. DRC should have some control over it, maybe next week :)
Looking forward to it. :)

3. I'm pretty sure you couldn't be satisfied, because you're asking for the impossible. (in real time, anyway), but just out of curiousity, here are two builds on steroids, I wonder what you would think:
one has x3 regain speed, the other x5.
I'll try them tomorrow - I'm going to bed now... ;)

But my ideal view of volume normalization would look something like this:

* buffer ahead a certain amount of seconds (like, say, 5)
* apply something similar to replaygain analysis to this 5 second window (which is probably done in smaller blocks anyway so it shouldn't be too processor-intensive to update it along the way)
* calculate an average volume for this floating window and let the user specify a certain volume towards which to adjust the overall volume
* do a second pass with a much shorter window (like 0.25 seconds) over the result and lower the volume of the parts that either clip or exceed some user-specified maximum upwards deviation, since short loud bursts probably don't account enough to the average volume

That way volume would be continuously (and slowly) averaged out while overly loud sounds would also be kept in check...

Now if only I had the time to actually implement this... :p

np: New Order - Touched By The Hand Of God (Singles (Disc 1))

[tal.aloni]

* buffer ahead a certain amount of seconds (like, say, 5)

I stopped reading there.
like I said. impossible in real time. :(
In any way I look at it, it's not very practical, ffdshow's infrastructure does not support this as far as I know.

Tal

[Leak]

I stopped reading there.
like I said. impossible in real time. :(
Even if I would get crazy and try to buffer 5 seconds ahead, think about the insane amount of RAM i would need to buffer 5 seconds of 1080p24, just to match the audio. (~711MB)
(Sheesh, I'm still not asleep... :p)

Ummm... audio and video are decoded separately and joined by the renderer according to the timestamps both streams have - if you look at the DirectShow graph in graphedit you'll see that there's separate instances of ffdshow chugging away at audio and video...

Doing what I'm doing for video in the AviSynth filter should be just as possible for audio - just keep on decoding, but don't return the decoded samples from the filter until you've buffered enough; with the difference that decoding and buffering audio should be less resource-intensive.

Sure, it might give a bit of a hiccup at the start, but since I hardly ever seek around while watching a DVD I'd have no problem with this - and it'd be optional anyway, of course...

np: New Order - Run 2 (Singles (Disc 2))

[tal.aloni]

(Sheesh, I'm still not asleep... :p)

Ummm... audio and video are decoded separately and joined by the renderer according to the timestamps both streams have - if you look at the DirectShow graph in graphedit you'll see that there's separate instances of ffdshow chugging away at audio and video...


you beated me to it. it may be possible, but ffdshow's infrastructure does not support this.
(I wonder if the splitter have to output synced audio and video, or if you can read audio ahead)

Tal

[MatMaul]

I just did some test with the accuracy of interlaced detection in libavcodec/libmpeg by just writing the value in a file and that's bad (tested with mpeg2 dvb-t interlaced sample and DVD) :

libavcodec reports my dvb-t sample randomly, some frames are reported progressive and some others tff
no problem with libavcodec and a DVD
libmpeg2 reports both of them as tff......

so I think it would be cool to can really force hardware deinterlacing by adding an "auto" option which acts like the current "bob" option and really force deinterlacing with bob selected.

[Leak]

you beated me to it. it may be possible, but ffdshow's infrastructure does not support this.
(I wonder if the splitter have to output synced audio and video, or if you can read audio ahead)
(Need... sleep...)

Errr... like I said - the last big AviSynth filter code rewrite in ffdshow came from me, and that kind of buffering was exactly what I implemented - for video, granted, but I don't see how it should be less possible for audio... also, DirectShow in (IIRC) push mode works by trickling samples (which can be frames of any kind of stream) downstream from the source, but a filter can always hold back frames and report to it's upstream filter that there's nothing to do currently, or it might not even notify the upstream filter at all.

Take a look in src\imgFilters\avisynth if you're interested... :)

Granted, I found that taking too long to return samples from ffdshow will make DirectShow unhappy, but for audio normalization (as opposed to the largely unknown demands of an arbitrary AviSynth script) it surely would suffice to decode two frames of audio for every frame of audio returned until you've buffered up to my hypothetical 5 seconds ahead...

np: New Order - Spooky (Singles (Disc 2))

[STaRGaZeR]

I just did some test with the accuracy of interlaced detection in libavcodec/libmpeg by just writing the value in a file and that's bad (tested with mpeg2 dvb-t interlaced sample and DVD) :

libavcodec reports my dvb-t sample randomly, some frames are reported progressive and some others tff
no problem with libavcodec and a DVD
libmpeg2 reports both of them as tff......

so I think it would be cool to can really force hardware deinterlacing by adding an "auto" option which acts like the current "bob" option and really force deinterlacing with bob selected.

That issue with DVB-T happens to me too, but only in 2 or 3 channels, the others are fine. That forces me to use libmpeg2. I vote for the "Force bob" option.

[tal.aloni]

Leak,
Thanks for the enrichment, I've learned a thing or two about Direct-Show.
now you'll have to find someone who actually want this kind of DRC as bad as you, my neighborhood is totally up to the full spectrum, so my part was done with the One-Pass-Normalization. :helpful:

p.s.
you can always do I did.

Tal

[Shakey_Jake33]

Can I just ask, now we have all these different test builds that add features like HD Audio codec support, proper volume normalisation, improved multithreading support etc, are these going to find their way into the main ffdshow Tryouts builds? It's becoming a bit of a jungle!

[tal.aloni]

Can I just ask, now we have all these different test builds that add features like HD Audio codec support, proper volume normalisation, improved multithreading support etc, are these going to find their way into the main ffdshow Tryouts builds? It's becoming a bit of a jungle!

I guess the project admins are a bit worried about replacing existing functionality before it has been properly tested:
Improved multithreading support for example has some problems with interlaced content (makes you feel like you're watching "the butterfly effect").
One pass normalization is already in the main trunk,
and I think "Deinterlacing only interlaced content" is soon to be joined.

If you want the admins to include features more quickly, help them out by testing the new functionality, and tell us what you think.
I got almost no feedback yet about the improved normalization algorithm (regain volume checked).

and by the way, I think Albain's build is ready for the main trunk.

Tal

[albain]

I have posted an official build on sourceforge.

We are waiting for feedbacks before merging the new audio codecs branch to the trunk.

Please try it and report it if you have issues

Thanks

[tal.aloni]

Well, now I did.
It has nothing to do with "one pass normalization",
but I made modifications to the Nomalization when "Regain volume" is unchecked, there should be no clipping now.
If you tend to use the old style normalization, please check out this build and tell us if you think we should replace the old one with the new one.
(I think there is a clear winner)

Build:
http://iknowu.net/files/public/ffdshow/AutoVolumeControl/ffdshow_rev2232_20081019-AutoVolumeControl-RC2.exe

Source & Patch:
http://iknowu.net/files/public/ffdshow/AutoVolumeControl/ffdshow-AutoVolumeControl-RC2-Patch.zip

p.s. I changed the GUI a little bit, to make it more clear that "Buffer Length" is only required when "Regain volume" is checked. I also changed "Normalization" to "Auto volume control".

Here is a quick comparison between the old Normalization and the suggested one, 17 seconds from the "Iron Man" trailer.

http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdOldNorm-selection.flac

http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdshowBetterNorm-selection.flac

[MatMaul]

I have posted an official build on sourceforge.

We are waiting for feedbacks before merging the new audio codecs branch to the trunk.

Please try it and report it if you have issues

Thanks
are you sure you re-build ffdshow ? because I can't see the normalize change in your build.

[nautilus7]

His build is rev 2224. The normalize change is from a newer revision.

[MatMaul]

oups I saw the backport in the SVN and I didn't check the rev sorry :p

I confirm the little glitches reported a while ago with libavcodec ac3 when you jump of title or chapter in a DVD. no problem with liba52.

[albain]

are you sure you re-build ffdshow ? because I can't see the normalize change in your build.

I am making a merge from the trunk and will post an updated build next

oups I saw the backport in the SVN and I didn't check the rev sorry :p

I confirm the little glitches reported a while ago with libavcodec ac3 when you jump of title or chapter in a DVD. no problem with liba52.

Have you met the same problem with mplayer (and libavcodec used) ?

[STaRGaZeR]

Have you met the same problem with mplayer (and libavcodec used) ?

Doubt it, because it only happens when you play the DVD in DVD mode. If you play the .vob's independently the problem doesn't happen.

Also seeking is way slower, thing that also doesn't happen when playing the .vob's independently.

EDIT: http://www.megaupload.com/?d=S2YOGNS5 (500KB) --> This sample plays fine with liba52 and MPlayer, but there is a little jump in the middle when ffdshow+libav is used. The sound you'll hear when the jump starts is the same one that happens in the DVD problem.

[haruhiko_yamagata]

Improved multithreading support for example has some problems with interlaced content (makes you feel like you're watching "the butterfly effect").
Thank you, I have sent your sample to the author.