ffdshow tryouts project: Discussion & Development [Archive] - Page 5

Liisachan

25th August 2008, 00:49

Hmm considering general crappiness of XP, I guess FFD will be better choice :)
Yeah, maybe that's safer. But there are more than one mp3 decoders in ffdshow itself, and I'd say you might want to use something other than libmad. libmad has not been maintained anymore, more than 4 years or so now, and known as seriously-buggy-but-no-one-fixed-it for some years, with several reports, at least on mplayer (-ac mad). The problems are not about quality, mostly AV-sync related, especially in VBR.
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/244722

It may be ok in ffdshow (so far no obvious problems have been found in ffdshow-libmad), but the bug is in libmad itself, outdated and not maintained, so it should be safer to use another decoder. Besides, basically you don't get anything by selecting libmad unless your CPU only supports integer math, and not floating.

IIRC libmad is the default mp3 decoder in ffdshow (I don't know why. WHY?), and so you might want to change that option manually.

Liisachan

25th August 2008, 00:55

try Gabest's MP3 decoder.
huge soundstage, very clear audio, IEEEE float output. If you mean the one in MPC, that's libmad too. So it may be actually ok, and even excellent, but I can't help but feel it's not safe...

IgorC

25th August 2008, 04:58

As many people already know about new AAC decoder http://multimedia.cx/eggs/aac-decoder-is-in/
There is no information about stability but are there some plans to include it to ffdshow in future?
It has better performance than faad.

Octo-puss

25th August 2008, 05:43

Yeah, maybe that's safer. But there are more than one mp3 decoders in ffdshow itself, and I'd say you might want to use something other than libmad. libmad has not been maintained anymore, more than 4 years or so now, and known as seriously-buggy-but-no-one-fixed-it for some years, with several reports, at least on mplayer (-ac mad). The problems are not about quality, mostly AV-sync related, especially in VBR.
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/244722

It may be ok in ffdshow (so far no obvious problems have been found in ffdshow-libmad), but the bug is in libmad itself, outdated and not maintained, so it should be safer to use another decoder. Besides, basically you don't get anything by selecting libmad unless your CPU only supports integer math, and not floating.

IIRC libmad is the default mp3 decoder in ffdshow (I don't know why. WHY?), and so you might want to change that option manually.

Well, there is this mp3lib which I've been using and didn't encounter any problems.

pitch.fr

25th August 2008, 09:57

Yeah, maybe that's safer. But there are more than one mp3 decoders in ffdshow itself, and I'd say you might want to use something other than libmad. libmad has not been maintained anymore, more than 4 years or so now, and known as seriously-buggy-but-no-one-fixed-it for some years, with several reports, at least on mplayer (-ac mad). The problems are not about quality, mostly AV-sync related, especially in VBR.
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/244722

It may be ok in ffdshow (so far no obvious problems have been found in ffdshow-libmad), but the bug is in libmad itself, outdated and not maintained, so it should be safer to use another decoder. Besides, basically you don't get anything by selecting libmad unless your CPU only supports integer math, and not floating.
thanks for the bug report.
I mostly use Gabest MPC's MP3 decoder for music(so A/V sync is irrelevant), and I might have watched a few AVI's with VBR MP3.....they seemed fine to me ?!

I use Reclock and HR, so my movies are under tight supervision :D

I'd guess that Gabest would have seen and fixed such an A/V bug, considering he really knows what he's doing :)

so this bug might either be only MPLAYER-related, Gabest would have fixed it in his DSHOW filter or I didn't encounter the bug yet ?!

I'll run more tests, and compare with ffdshow's built-in MP3 decoders.

Mangix

25th August 2008, 23:21

mp3lib is faster. not that it makes a difference...

Liisachan

26th August 2008, 00:29

@Octo-puss
@Mangix
Yup, my choice now is mp3lib too. That's mplayer's standard default too. I have no real reason to like it, but I do have a reason to dislike libmad, so relatively...

@pitch.fr
No, this bug is probably in libmad, not in mplayer. If you select another decoder (-ac3 mp3 or -ac3 ffmp3), mplayer is happy with MP3 including VBR. Besides, I was told that madplay (the reference implementation of libmad) has bugs too.

Maybe things are ok on Windows, which uses it's own sync system, just letting libmad decode, not asking it what time it is now. It's just that I really can't trust libmad anymore, now that I know how it's broken on mplayer. I wouldn't make it ffdshow's default mp3 decoder. Many years ago, when I found that ffdshow's default Vorbis decoder was really bad, milan told me that he would still like to keep Tremor in Low Quality Mode for slower CPUs. Maybe libmad is there for the same reason. But I tend to think it shouldn't be the default.

libmad might behave differently than other DirectShow mp3 decoders on Windows if the first mp3 frame is a VBR tag frame ("LAME", "Xing", "Info"), especially a LAME tag frame. libmad is fully VBR-tag-aware. But the difference is like 24 ms, so hard to detect. And actually this part may be related to the bug.

When my friends and I found that mplayer -ac mad didn't like VBR MP3, we first assumed that it just didn't like the hack to put VBR audio in AVI. Some also suggested that packed bvops were bad too. However, like that bug report says, we then noticed libmad didn't like VBR MP3 in (x264+VBR MP3).mp4 .mkv etc. either. So the problem is more fundamental: libmad itself is broken, and you can't blame Nandub's hack or DivX's hack here.

I am under impression that mpalyer's libmad goes crazy especially when you put VBR MP3 *without* the VBR tag (lame -t), but it's not really stable *with* the tag either. LAME tag might be a cool hack for audio-only files, but depending on it is a bad idea for movies, since it exists only as the first mp3 frame and you might edit your movie removing the first part, or dividing it into 2 or more. Or you might concatenate 2 movies, and if each of them has this tag, you end up having the hack padding in the middle of your movie.

clsid

26th August 2008, 13:30

I have never noticed any VBR related problems with libmad and I am not aware of any ffdshow users that are. So you are probably right that the bug doesn't manifest itself with DirectShow, or at least not in a noticeable way.

fastplayer

26th August 2008, 13:37

With libmad being the default MP3 decoder in ffdshow and MPC, any problem would have been noticed and reported straight away. The user base is way too large and picky to let this go unnoticed :D

pitch.fr

26th August 2008, 14:04

With libmad being the default MP3 decoder in ffdshow and MPC, any problem would have been noticed and reported straight away. The user base is way too large and picky to let this go unnoticed :D
well, EVR/VMR are nowhere near as smooth as HR jitter-wise.
yet noone complains, mostly coz they watch movies in 60Hz on crappy flat screens.

so this user base is not too picky when it comes to A/V sync and dropped frames ;)

thuan

26th August 2008, 14:41

@pitch.fr: You haven't look at MPC-HC thread, have you?

pitch.fr

26th August 2008, 17:32

haha.

no, what is MPC HC again ? :D

well simply put, I play my movies in 24fps in 24Hz with Reclock and HR.

HR offers an extremely low jitter such as 0.01ms :

http://pix.nofrag.com/3/7/2/f9dd4bb16cde2c99452be634e747f.png

MPC in custom EVR/VMR9 is UNABLE to keep up with such a low jitter, let alone not dropping frames for no reason.

MPC is great for watching movies in 60Hz w/o Reclock I guess :D

so if that madlib is giving 24ms delay, I guess no MPC user would notice it anyway.

just for fun, try to play 29.97fps in 89.91Hz....MPC HC in exclusive mode will fail....look at the CTRL+J infos :D

the MPC HC custom renderers are really not tight enough, HR plays 29.97@89.91Hz w/o a itch and with <1ms jitter.

TheShadowRunner

26th August 2008, 18:01

hi leeperry, huh pitch.fr...
Still trying all you can to get a stable playback or did you find the holy grail yet?
I just want to react on the EVR/VMR jitter statement. VMR9 is perfectly stable here, not a single dropped frame, ever; a perfect job with Reclock. So don't generalize please.
Later,

TSR

pitch.fr

26th August 2008, 18:15

SBeaver

27th August 2008, 05:55

I don't know you TSR, I'm sorry :)

yeah, if you don't find HR smoother than EVR/VMR, I think the problem might be on your display(not all of them offer perfect VSYNC in the first place) ;)

I'm far from being the only one who finds HR a lot smoother than EVR/VMR on HCFR.

HR is as smooth as a cinema projector, I usually suffer from 10ms jitter(a quarter of a frame in 24fps) over a 2H movie w/o a single dropped frame.

HR and Reclock work perfectly fine here, offering the ultimate 24fps goodness :)

try to play 29.97fps@89.91Hz in MPC EVR/VMR, and lemme know how it goes.

but we should drop it anyhow, I can feel clsid is gonna complain that it's OT(which it is ;))

I think that could depend on the hardware also.
When I had a regular LCD with 60Hz HR always gave me good results but now when I have a projector it's a lot harder to get perfect tearing-free playback.
My perfect setup is EVR custom with d3d fullscreen (without this I get slowdowns/drops or tearing) and 47,952Hz (23.976*2) using powerstrip.
24Hz was impossible, sometimes it would seem to work but most of the time there was tearing, and with Haali there was always tearing.
Also haali has those ghost lines when rescaling on my Radeon so I wouldn't want to use it anyway.
I'm sure it can be improved though, I used to use haali all the time.

Liisachan

27th August 2008, 07:59

With libmad being the default MP3 decoder in ffdshow and MPC, any problem would have been noticed and reported straight away. The user base is way too large and picky to let this go unnoticed :D

I don't think that way. For example, many encoders use LAME without -t, causing bad AV sync and they are still happy about the results. Plus users in general are slow to report a problem even if they notice there are or there may be something wrong. But the conclusion that libmad is ok on Windows is perhaps correct anyway.

pitch.fr

27th August 2008, 10:54

I think that could depend on the hardware also.
When I had a regular LCD with 60Hz HR always gave me good results but now when I have a projector it's a lot harder to get perfect tearing-free playback.
My perfect setup is EVR custom with d3d fullscreen (without this I get slowdowns/drops or tearing) and 47,952Hz (23.976*2) using powerstrip.
24Hz was impossible, sometimes it would seem to work but most of the time there was tearing, and with Haali there was always tearing.
Also haali has those ghost lines when rescaling on my Radeon so I wouldn't want to use it anyway.
I'm sure it can be improved though, I used to use haali all the time.
I'd say it comes from your graphic card/motherboard, or possibly some settings in the BIOS or in CCC(is it on the primary device?)

well look at the CTRL+J infos in D3D exclusive mode, it's a jerky party :)

what I really enjoy in HR is that it remains smooth no matter how much post-processing you got running in ffdshow(when ffdshow reaches h264 bitrate peaks, MPC will drop frames more often than you'd think) and the jitter(the interval between each frame) is constant and very low.

when I watch 24fps stuff in MPC+EVR/VMR9 I have the feeling that I'm getting 23.5fps.....but it's the same in other players, you can't except a software only renderer to offer the same jitter as a hardware based coded by one of the main video rendering expert on PC.

like I said HR is like an unstoppable train, it won't take sh*t from anybody :)

to avoid ghost lines when upscaling with HR, you need to upscale in ffdshow instead(in spline if you can) ;)

ACiD GRiM

29th August 2008, 19:12

I'm trying to compile the 64 bit version of ffdshow, but i get the following errors:

Error 62 error PRJ0019: A tool returned an error code from "Performing Post-Build Event..." ff_vfw
Error 65 error PRJ0019: A tool returned an error code from "Performing Post-Build Event..." ff_acm
Error 56 error PRJ0019: A tool returned an error code from "yasm assembling c:\Users\Ben\Desktop\ffdshow-tryout\src\cpuid64.asm" ffdshow

I'm using Visual Studio 2008, and have compiled some other projects before. I'm wondering if I'm missing some libaries from my VC/lib folder, but I'm not sure. Could someone give me some tips

Tom Keller

30th August 2008, 00:20

pitch.fr

30th August 2008, 09:08

3ngel

30th August 2008, 09:14

CruNcher

30th August 2008, 12:18

Does anyone knows, why this recorded H.264 stream (http://www.megaupload.com/?d=66YZOX7I) crashes ffdshow after a couple of seconds? It doesn't matter which player i use - i always get a Visual C++ runtime error after 13-16 seconds. But there aren't any problems with CoreAVC or with the Cyberlink H.264 decoder :confused: ...

Seems to be a generic Libavcodec Decoding Problem also ffplay crashes (picture buffer overflow), mplayer segfaults vlc doesn't but skips alot of the frames anyways ;)

PS: Superdump is doing a Bug Report for the ffmpeg guys on this thx Superdump :)

clsid

30th August 2008, 13:46

What about developing a Lagarith decoder implementation?

The codec works really well in coding phase and it would benefit from a DirectShow chain decoding (actually is limited by the internal VFW decoder implementation).

I hope you find this interesting and think about it :)
First of all, ffdshow uses external libraries for decoding. It does not have its own decoder implementations.

Secondly, there are currently zero developers that are actively working on ffdshow. Which means no bug fixes and certainly no new features.

3ngel

30th August 2008, 17:50

Oh, i see i didn't know about this situation.

Mine was just an idea.

Tom Keller

30th August 2008, 19:23

Seems to be a generic Libavcodec Decoding Problem also ffplay crashes (picture buffer overflow), mplayer segfaults vlc doesn't but skips alot of the frames anyways ;)

PS: Superdump is doing a Bug Report for the ffmpeg guys on this thx Superdump :)
Thanks for your answer. Seems you're right: the ffmpeg based built-in H.264 decoder from mpc-hc crashes too. Hopefully it's possible to fix it...

lych_necross

31st August 2008, 07:36

Secondly, there are currently zero developers that are actively working on ffdshow. Which means no bug fixes and certainly no new features.

If that's true, then what why are there new tryout releases about every week? What exactly is being changed to justify a version change from ffdshow-20041012 to ffdshow_rev2079_20080815? :confused:

_xxl

31st August 2008, 07:43

Please read:
http://forum.doom9.org/showthread.php?t=120465

Mercury_22

31st August 2008, 12:26

Since now (http://forum.doom9.org/showthread.php?p=1177473#post1177473) FFmpeg now supports E-AC-3 decoding as of SVN revision 15103. can we hope for E-AC-3 DECODING TOO ? ! :helpful: :thanks:

clsid

31st August 2008, 14:11

If that's true, then what why are there new tryout releases about every week?Lately, changes are mostly insignificant updates. Like importing updates from FFmpeg project.What exactly is being changed to justify a version change from ffdshow-20041012 to ffdshow_rev2079_20080815?An enormous amount of improvements have been made to ffdshow in the past years. When I made a comment about a lack of developers, I was talking about the current situation.

can we hope for E-AC-3 DECODING TOO Only if someone volunteers to take up the task.

jmartinr

1st September 2008, 12:59

I'd like to resize in the avisynth filter of ffdshow, but is there a way to enforce the ffdshow OAR ?

the idea would be to resize to spline 1280*720 and keep the OAR..

maybe with ffdshow_dar_x/ffdshow_dar_y ?

it's not very clear :
http://ffdshow-tryout.sourceforge.net/html/en/avisynth.htm

thanks,

I use the following script in ffdshow to tinker with the OAR, and to crop off anything that's outside a 16/9 window. I have a small TV-set and have no use for this superwide stuff. It should not be very hard to do what you want.

#ffdshow_setDAR(16,9)
#ffdshow_setDAR(4,3)
#ffdshow_setSAR(12,11)
#wanted dar x
wx=16
#wanted dar y
wy=9
maxwidth=round(last.height*float(ffdshow_sar_y)*wx/ffdshow_sar_x/wy)
maxwidth=maxwidth-(maxwidth%16)
maxwidth=min(last.width,maxwidth)
crop((last.width-maxwidth)/2,0,maxwidth,0)

lych_necross

2nd September 2008, 07:14

Lately, changes are mostly insignificant updates. Like importing updates from FFmpeg project.An enormous amount of improvements have been made to ffdshow in the past years. When I made a comment about a lack of developers, I was talking about the current situation.

Okay, thanks clsid. Hopefully sometime soon more people will decide to actively develop it soon (I would like to see new features).

Joniii

2nd September 2008, 07:32

I just installed Vista x64 (SP1) and i'm having severe problems with FFDShow.

Every HD movie I play stutters alot and is unwatchable with x64 builds of FFDShow. I'm using MPC-HC x64 matroska & mpeg splitters for .mkv and Blu-ray .m2ts. It happens in all content (VC-1, H.264 and MPEG-2).

If I disable for example MPEG-2 in FFDShow so that Default Microsoft MPEG-2 codec is used, all MPEG-2 Blu-rays plays smoothly.

I had no problems with Vista x86 & FFDShow. I have the same problem also with MPC-HC and it's internal splitters.

_xxl

2nd September 2008, 08:01

x64 builds are slow because libmpeg2 is compiled from plain C only.

Which Cpu do you have?

Joniii

2nd September 2008, 08:42

x64 builds are slow because libmpeg2 is compiled from plain C only.

Which Cpu do you have?

Core 2 Duo 6400.

MPC-HC MpegSplitter.ax (x64)

MPC-HC x64 or WMP11 x64 (x64 FFDShow VC-1, H.264 & MPEG-2)
-Unwatchable VC-1, H.264 & MPEG-2 Blu-rays.

MPC-HC x64 or WMP11 x64 (x64 MPCVideoDec.ax VC-1, H.264)
-Unwatchable VC-1 and H.264 Blu-rays.

It seems strange because those both scenarios work like a dream in Vista x86.

Leak

2nd September 2008, 08:52

It seems strange because those both scenarios work like a dream in Vista x86.
Like clsid said, there is no optimized 64-bit code for the decoders, so they *WILL* be slow.

Use a 32-bit media player and the 32-bit version of ffdshow instead; it's not as if video decoding would actually need the extra address space a 64-bit app has...

Joniii

2nd September 2008, 09:01

I tried this with Vista x64:

MPC-HC MpegSplitter.ax (x86)

MPC-HC x86 or WMP11 x86 (x86 FFDShow VC-1, H.264 & MPEG-2)
-Everything works like a dream.

Joniii

2nd September 2008, 09:08

Like clsid said, there is no optimized 64-bit code for the decoders, so they *WILL* be slow.

Use a 32-bit media player and the 32-bit version of ffdshow instead; it's not as if video decoding would actually need the extra address space a 64-bit app has...

Oh, I didn't know about that.

It's just that I watch TV/Movies with my Media Center computer. VMC comes only as 64-bit in Vista x64 and can't use 32-bit WMP11 or 32-bit codecs.

I guess I'll have to install 32-bit Vista then.

Jong

2nd September 2008, 09:57

Hi everyone.

I have a problem with output settings when using profiles.

If I set one of my profiles to RGB it seems that all profiles do RGB conversion, even if set correctly for YV12.

I have profiles/presets for "SD", "720p" and "1080p" (defined by horizontal resolution). I need to do RGB conversion on SD titles so I can force use of the BT.601 colorspace for upscaled SD material. However, it is a complete waste of cycles to do RGB conversion in software for native HD material and the processing power required actually prevents me doing any other post-processing. ffdshow appears to allow different profiles to use different output colorspaces but it does not seem to work. RGB conversion is done on all once I set it in my SD profile. I do not know why the SD profile seems to take priority, except maybe because it was the first of the profiles to be created. Or maybe it is just that RGB is used if ANY profile is set ot RGB. The RGB Conversion tab DOES work correctly, so at leat I can use BT.709 for HD and BT.601 for SD.

Does anyone have any idea why this is happening and how to resolve it?

Thanks.

clsid

2nd September 2008, 15:45

Actually, the 64-bit builds DO contain optimizations. At least when libavcodec is build with GCC, which I use for my 64-bit builds. Libmpeg2 on the other hand, as xxl said, does not use the assembly optimizations, and therefore can be slow.

But the slowness issues with 64-bit builds seem to have another cause. Possibly related to colorspace (conversion). Two known workarounds:
1) Enable NV12 colorspace in ffdshow options. Might only work for ATI cards (need confirmation on that). You might also need to disable YV12 (not sure, need confirmation as well).
2) Enable OSD. (Dunno why this makes a difference. Anyone have an idea why? Does it trigger a colorspace conversion?)

Reimar

2nd September 2008, 20:36

Use a 32-bit media player and the 32-bit version of ffdshow instead; it's not as if video decoding would actually need the extra address space a 64-bit app has...

No, but since we are talking about x86 they very much can use the extra 8 registers and SSE/SSE2 being mandatory that x86_64 provides in addition to 64 bit address space (which to be pedantic is currently "only" 40/48 bit anyway).
Also since libavcodec and at least MPlayer's libmpeg2 work fine in 64 bit builds, I'd expect it should take an interested developer with a 64 bit system not too long to fix the issue. Now how to find such a developer is a different point...

_xxl

2nd September 2008, 20:41

MPlayer's libmpeg2 work fine in 64 bit builds
Win64 is not the same with ARCH_X86_64. The same issue is with x264 encoder. No Win64.

LoRd_MuldeR

2nd September 2008, 23:58

The ffdshow_rev2097_20080002_dbt_sse_icl10.exe build doesn't work for me :(

DVBViewer will simply show a black picture (like no decoder found) and in ffdshow settings (via Rundll32) it will crash/starve when I click the "Version details" button.
I updated my "Microsoft Visual C++ 2008 Redistributable" as suggested by the installer...

Went back to the ffdshow_rev2094_20080830_clsid.exe build and everything works fine again :)

betaking

3rd September 2008, 14:09

pitch.fr

4th September 2008, 08:46

humm indeed, some problems with post-processing WMV files...crashes my player

went back to ffdshow_rev2083_20080821_dbt_sse_icl10.exe

BTW, the ICL10 versions from Albain have disappeared ?!
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=229162

EDIT: clsid made a new ICL10 build anyway(ffdshow_rev2099_20080903_clsid_sse_icl10.exe), everything works fine again..thanks :)

LoRd_MuldeR

4th September 2008, 11:41

EDIT: clsid made a new ICL10 build anyway(ffdshow_rev2099_20080903_clsid_sse_icl10.exe), everything works fine again..thanks :)

Confirmed :cool:

Mercury_22

4th September 2008, 14:40

Only if someone volunteers to take up the task.

It looks like adding E-ac3 it's not that hard :helpful:

http://forum.doom9.org/showthread.php?p=1179393#post1179393

So.. no one can do this ? :thanks:( Only if I knew how to ...:stupid:)

clsid

4th September 2008, 15:52

If it were easy it would have already been added...

Inventive Software

4th September 2008, 16:17

What exactly is required to add it? I'm aware that 24 bit decoding is a problem with ffdshow, but is that it? I know ffdshow doesn't use libavcodec for vanilla AC-3 decoding, but if the E-AC3 part was a separate entry in the decoder, would that help? Does E-AC3 require AC-3 to decode properly, or is it a completely different decoder?

clsid

4th September 2008, 17:29

The difficult part is to make ffdshow feed the proper (meta-)data to libavcodec. Many codecs require 'extradata' that usually contains all kind of information from headers etc. Some knowledge of the format/specification is required to implement that.

I have no idea if 24bit is a problem. I am no expert regarding the source code of ffdshow, I have only read a few tiny portions of it. I am not a C++ developer.

albain

5th September 2008, 09:26

Hi CLSID,

don't know why but my ICL builds work partially.

I have ICL 10.1 with VS 2008 SP1, and to compile it I had to replace for linking msvcrt.lib by libcmt.lib.

Then it compiles fine and FFDShow work ok with media player but crash under media center.

If I compile FFDShow with visual studio it works ok

You have an idea ?

In the meantime I replaced my ICL builds by generic builds.

Thanks

Damien BT

clsid

5th September 2008, 15:20

Settings that are used by the 2003 ICL project:
AdditionalOptions += /Qip /Qunroll0
EnableEnhancedInstructionSet=1 (SSE)
AdditionalDependencies += libirc.lib libm.lib svml_disp.lib (these are Intel libs)

albain

6th September 2008, 10:31

Ok, thank you

Mercury_22

7th September 2008, 10:45

Revision 2101 - Directory Listing
Modified Sat Sep 6 13:56:57 2008 UTC (19 hours, 44 minutes ago) by albain
Updated libavcodec : imported E-AC3, AC3 and AAC decoders (not coded yet into ffdshow).
So there is HOPE for E-AC3 in FFdshow ?! :thanks::p

Kurtnoise

8th September 2008, 08:57

@albain: you should put a warning or something like that for the lavc aac decoder coz it doesn't support SBR & PS yet...

albain

8th September 2008, 10:19

Kurtnoise

8th September 2008, 11:49

both MPC-HC & MPC crash with my own libavcodec compile to decode AC-3 & E-AC-3 streams. Nevertheless, those files play fine with FFplay.

I'm using gcc 4.3 though, not cc...

clsid

8th September 2008, 12:34

_xxl

8th September 2008, 13:03

@albain

You could commit all ac3, eac3, dca and aac decoders from libavcodec and just disable them from ffdshow, until they are fixed. I have send a small patch for it. 2 channel aac samples doesn't work with libavcodec. Only dca libavcodec decoder seems to work properly, but I don't have many samples to test.

albain

8th September 2008, 13:41

@xxl

Hi, thanks for your patch

I applied your patch, except for 1 file : aacdectab.h, I don't know why but the signs are inverted between your file and the one from ffmpeg.
I also disabled the decoders (AAC & AC3 from libavcodec).
To test them in the future and make them available you will have to define a preprocessor macro : INCLUDE_UNSTABLE_DECODERS.
Those decoders remain included and registered into libavcodec

I will also try to upload the 2 EAC3 samples that I tested (successfully).

Damien

albain

8th September 2008, 13:51

I have posted 2 working EAC3 samples :
Sample 1 (http://rapidshare.com/files/143599722/Battle.Of.The.Bulge.1965.HD-DVD.Re.x264.720P.EAC3-C_SiLU-Sample.mkv.html) (31Mb)

Sample 2 (http://rapidshare.com/files/143601275/eac3mono64kbit.mka.html) (6MB)

MatMaul

8th September 2008, 14:32

files lpc.c and lpc.h from libavcodec are missing ;)

it is weird the ac3 decoder is unstable, it is in the main branch since a while now.

Mercury_22

8th September 2008, 14:38

Can someone provide some small sample files with E-AC3 in it? Preferably one that is working now and one that doesn't work.

I haven't build a new version yet, but the current changes are pretty much the same as what xxl already tried a while back, and then it also crashed on most files.

E-AC3 sample here (http://rapidshare.com/files/143609863/Test_E-AC3.ts.html) ! but I don't have a new version of FFDShow to test the E-AC3.. :helpful: Can someone compile a new SVN version with E-AC3 PLEASE ! :thanks:

P.S. x64 version (too) :thanks::p:stupid:

albain

8th September 2008, 14:51

Sorry, I forgot to add them. Fixed in revision 2107

EDITED :
I have posted a new build on sourceforge including those decoders, and with the possibility to activate them. Just select libavcodec

Mercury_22

8th September 2008, 15:23

Sorry, I forgot to add them. Fixed in revision 2107

EDITED :
I have posted a new build on sourceforge including those decoders, and with the possibility to activate them. Just select libavcodec

Thanks working here with the above samples !! :thanks:

Any chance for a 64-bit compile too !! PLEASE! :thanks:

rack04

8th September 2008, 15:38

albain

8th September 2008, 15:45

So I just change AC3 from liba52 to libavcodec?

Yes that's all

nautilus7

8th September 2008, 15:51

Thanks for the new decoders. It works here, too!

May I ask for Dolby TrueHD support also (if it's similar to E-AC3 to add)?

albain

8th September 2008, 15:57

No :
EAC3 is Dolby Digital Plus, an improvement of Dolby Digital signals wheras TrueHD is a new lossless format used on blueray discs

nautilus7

8th September 2008, 16:00

No :
EAC3 is Dolby Digital Plus, an improvement of Dolby Digital signals wheras TrueHD is a new lossless format used on blueray discs
Yes, I'm aware of this. :) I meant, if adding TrueHD support needs the same amount of work to be done. If it's a trouble, forget it. (you know that there's a trueHD decoder in ffmpeg right?)

MatMaul

8th September 2008, 16:02

trueHD is basically the same as MLP and ffmpeg have a MLP decoder since one month. I wrote basically because bluray truehd tracks have a "core" part which is an ac3 stream and I don't know how it has to be handled in directshow (does the splitter splits the ac3 from the mlp stream ? or it has to be done in the decoder ?)

nautilus7

8th September 2008, 16:04

Actually, it's not a core (inside TrueHD track). It's an individual AC3 track, just "attached" to the TrueHd. But, I don't know further than this...

MatMaul

8th September 2008, 16:19

albain

8th September 2008, 16:21

Well, according to FFMPeg site,

"Also, FFmpeg now has floating point PCM support and supports MLP/TrueHD decoding "

So maybe True HD decoding is already working...

clsid

8th September 2008, 16:29

albain

8th September 2008, 16:38

what about dts libavcodec support ? here is a patch but I can't compile so I can't test.
http://www.etud.insa-toulouse.fr/~mvelten/bordel/dca_libavcodec.diff

libavcodec aac decoder crash every time I tried but no problem with the ac3 decoder.

I reproduce the crash on my AAC file. Weird, it used to work on it.

I have applied your patch and built a new setup, let me know if DTS decoding is also functional :
http://rapidshare.com/files/143635622/ffdshow_rev2107_20080908_dbt_patched.exe.html

albain

8th September 2008, 16:48

Actually, AAC decoder (libavcodec) crashes under WMP, but not under Media player classic (of course I disabled MPC internal AAC decoder), so maybe it has to do with the splitter

albain

8th September 2008, 17:00

Haali Media Splitter exposes two media subtypes for files with E-AC3 audio:
MEDIASUBTYPE_DOLBY_AC3 and {0000EAC3-0000-0010-8000-00AA00389B71}

Currently, ffdhsow only looks at the first mediatpye it gets. If we can make ffdshow take the second mediatype in consideration, then it would be possible to separate EAC3 decoding from AC3 decoding. Allowing to use a different decoder for regular AC3.

Now ffdshow uses the same decoder for both AC3 and E-AC3. Not a big problem since both decoders are currently compatible with each other. But the annoying thing is that the Info&CPU page in ffdshow will always show that the input is AC3.

I have also checked on this and I didn't see any moment where Direct Show transmitted this second subtype to FFDShow : FFDShow always receives the AC3 subtype from the splitter, and directshow base classes do not provide a way to receive more than one subtype.
Rather, wouldn't it be better that Haali splitter always transmits the EAC3 subtype for EAC3 streams ?

MatMaul

8th September 2008, 17:33

Rather, wouldn't it be better that Haali splitter always transmits the EAC3 subtype for EAC3 streams ?
does E-AC3 is backward compatible with AC3 decoder ? If I remember correctly it is and in this case it is mandatory to expose the AC3 subtype then the stream can be decoded by standard AC3 decoder.
Actually, AAC decoder (libavcodec) crashes under WMP, but not under Media player classic (of course I disabled MPC internal AAC decoder), so maybe it has to do with the splitter
you right, it works with MPC MP4 splitter but crashs with haali splitter.

albain

8th September 2008, 17:42

does E-AC3 is backward compatible with AC3 decoder ? If I remember correctly it is and in this case it is mandatory to expose the AC3 subtype then the stream can be decoded by standard AC3 decoder.
That's not good news : if it is backward compatible it means that the decoder used by libavcodec is AC3, not EAC3 so there won't be the benefits of EAC3 format, unless AC3 decoder is able to detect the right format and redirect it ?

MatMaul

8th September 2008, 17:51

I was wrong :
Dolby Digital Plus software is not directly backward compatible with existing Dolby Digital decoders. However, Dolby Digital Plus capable players are required to be able to transform the output to a backwards compatible Dolby Digital signal.
So I think it is a non sense to use the same subtype for non compatible formats.... I hope not all splitters does that :P

compunett

8th September 2008, 21:14

That's not good news : if it is backward compatible it means that the decoder used by libavcodec is AC3, not EAC3 so there won't be the benefits of EAC3 format, unless AC3 decoder is able to detect the right format and redirect it ?

You got thing wrong, an EAC3 decoder is backward compatible in the sense that it con decode AC3 and EAC3. However an AC3 decoder cannot decode a EAC3 stream.

EAC3 stream has more information than an AC3 stream, and those additional informations are not understood by a normal AC3 decoder.

Justin can certainly explain thing better than me, as he is the guy who coded the EAC3 decoder. And he certainly can correct me if i'm wrong on something :)

jruggle

8th September 2008, 23:52

You got thing wrong, an EAC3 decoder is backward compatible in the sense that it con decode AC3 and EAC3. However an AC3 decoder cannot decode a EAC3 stream.

EAC3 stream has more information than an AC3 stream, and those additional informations are not understood by a normal AC3 decoder.

Justin can certainly explain thing better than me, as he is the guy who coded the EAC3 decoder. And he certainly can correct me if i'm wrong on something :)

For the record, I did not code the decoder, I cleaned it up after Bartek, a student in last year's (and this year's) GSoC for FFmpeg, wrote the majority of it. I was the project mentor.

Most of what has already been said here is correct. First, an E-AC-3 decoder is required to handle normal AC-3 as well. An AC-3 decoder cannot decode E-AC-3, but it can recognize it as an AC-3 variant with an unknown bitstream id, so it will skip those frames. This means that an AC-3 decoder will work with a mixed AC-3/E-AC-3 stream such as those in Blu-ray. That is the only "backwards compatible" part.

albain

9th September 2008, 08:24

For the record, I did not code the decoder, I cleaned it up after Bartek, a student in last year's (and this year's) GSoC for FFmpeg, wrote the majority of it. I was the project mentor.

Most of what has already been said here is correct. First, an E-AC-3 decoder is required to handle normal AC-3 as well. An AC-3 decoder cannot decode E-AC-3, but it can recognize it as an AC-3 variant with an unknown bitstream id, so it will skip those frames. This means that an AC-3 decoder will work with a mixed AC-3/E-AC-3 stream such as those in Blu-ray. That is the only "backwards compatible" part.

This means that the splitter has to send the right codec id (EAC3) or else the stream will be decoded in compatibility mode.

=> Haali developer should be informed to correct this wrong codec ID in output (I have posted a request on his mailing list but if someone knows better how to contact him)

ACrowley

9th September 2008, 09:43

Didn't know about the lack of support concerning AAC

I just added a new AC3 decoder (libavcodec) that supports both AC3 and E-AC3 streams.

I have tested it locally, it seems to work, please report if something's wrong

Damien

Hello

I have wrong 5.1 channel output with libavcodec when playing EAC3 and AC3 Files.
Center Channel Output comes out of all front speakers.

Other Decoders(odler ffdshow): AC3/DTS in 5.1 works as usual with correct channel mapping

Also dts decoding is corrupt now

albain

9th September 2008, 09:48

Hello

I have wrong 5.1 channel output with libavcodec when playing EAC3 and AC3 Files.
Center Channel Output comes out of all front speakers.

Other Decoders(odler ffdshow): AC3/DTS in 5.1 works as usual with correct channel mapping

OK, this is not surprising, because the channel mapping is different from standard AC3 so this is normal.
It can be easily fixed in FFDShow, the problem is that FFDShow receives the wrong codec ID from the splitter, so unless there is a trick to detect the right format before calling libavcodec, the problem will stay

nautilus7

9th September 2008, 10:32

This means that the splitter has to send the right codec id (EAC3) or else the stream will be decoded in compatibility mode.

=> Haali developer should be informed to correct this wrong codec ID in output (I have posted a request on his mailing list but if someone knows better how to contact him)
No.

Only Blu-ray E-AC3 with more than 5.1 channels (7.1) have an 5.1 AC3 core inside. These tracks will decode as 5.1 from an AC3 decoder and won't decode at all from the libav E-AC3 decoder, because it doesn't support 7.1 channels yet.

HD DVD E-AC3 (1.0, 2.0, 5.1, 7.1) and Blu-ray E-AC3 up to 5.1 don't have an AC3 core, so there's no compatibility issue. They can't decode from an AC3 decoder. Try it with mpc's internal AC3 decoder. They won't play at all. Here (http://www.sendspace.com/file/3oz3wq) is a 5.1ch HD DVD E-AC3 (without AC3 core). It will only decode with the new E-AC3 decoder in ffdshow. That's proves there's no backwards compatibility.

So, I believe that the splitter sending the E-AC3 streams as AC3 is no problem at all.

My sample is from Dolby Demo Disc (HD DVD version) and names the channels, so it would be good for testing channels mapping also.

Also, there's no need to separate AC3 from E-AC3 decoding in ffdshow, because that won't work with the only backwards compatible E-AC3 track (and that's 7.1 Blu-ray E-AC3).

clsid

9th September 2008, 11:35

So, I believe that the splitter sending the E-AC3 streams as AC3 is no problem at all.Wrong. It is a HUGE problem because all the sample files that I have that contain E-AC3 will fail with regular AC3 decoders which all attempt to decode the audio. The specification is simply retarded and should be ignored. Splitter can detect E-AC3 and should pass that info along.

Mercury_22

9th September 2008, 11:41

No.

Also, there's no need to separate AC3 from E-AC3 decoding in ffdshow, because that won't work with the only backwards compatible E-AC3 track (and that's 7.1 Blu-ray E-AC3).

AC3 needs to be separate from E-AC3 because libav FAILS TO DECODE AC3 after 1-2 seconds so we need one filter for AC3 and one for E-AC3 (at least for now) ! :eek:

clsid

9th September 2008, 11:41

Yes, decoding regular AC3 is very broken right now with libavcodec.

Inventive Software

9th September 2008, 11:43

If the decoder is implemented *correctly*, we can work on the splitters sending correct information to the decoder. I'd see how madshi did it in eac3to (via constructive PMs) and get his advice on putting it correctly in ffdshow.

clsid

9th September 2008, 12:04

ffdshow is not a splitter. It gets its mediatype info from the upstream filter.

The AC3 decoder probably fails because it isn't getting the appropriate extradata.

albain

9th September 2008, 12:05

Is there a way to detect if the stream is EAC3 when the input codec is AC3 ?
By analyzing the header, the bitrate ?
I don't know this part at all, but maybe we can implement a hack to detect the stream before sending it to the decoder

madshi

9th September 2008, 12:23

Some pieces of information:

(1) Haali told me that his way of reporting E-AC3 separately from AC3 is not really standard and he did it just for fun, or rather so he can directly see whether a stream is AC3 or E-AC3. But the way splitters are *supposed* to work is to report both AC3 and E-AC3 as simple AC3. I understand that it would be nice to have the ability to handle AC3 and E-AC3 separately. But I think ffdshow can not rely on splitters signaling E-AC3 differently. However, isn't it possible in DirectShow for a decoder to request an audio frame before deciding whether it accepts the connection? Finding out whether an audio frame is AC3 or E-AC3 is really easy. So maybe you could add a solution like that to ffdshow. But honestly, IMHO it would be good enough if you didn't add any special handling for E-AC3, but treated E-AC3 just like normal AC3 tracks. Ok, then you can't use different decoders for AC3 and E-AC3. But I don't consider that a deal breaker cause the libav AC3 decoder works really well (at least the older revision I'm currently using in eac3to).

(2) MLP and TrueHD have slightly different headers, but ffmpeg/libav has a decoder which decodes both perfectly fine. Which means that it should be really easy for you ffdshow guys to add support for this decoder. FWIW, here are the GUIDs used by Nero and ArcSoft splitters to signal TrueHD/MLP:

Nero: {1E889BE7-B276-4064-9A39-160A06895B52}
ArcSoft: {4288B843-610B-4E15-A53B-43007FCFF614}

IIRC PowerDVD uses just another GUID for TrueHD/MLP, but I don't know that right now. There doesn't seem to be a standard GUID for TrueHD/MLP, but every splitter seems to use its own GUID.

(3) There's one complication with TrueHD tracks: Some of them are pure TrueHD while others have AC3 frames interweaved. The AC3 frames are not needed/used for TrueHD decoding, though, so they could (or maybe must) be filtered out before sending the data to the libav decoder. Not sure, maybe the libav parser can remove them, maybe not. In eac3to I'm only using the libav TrueHD/MLP decoder and I'm feeding it with my own parser/splitter which removes the AC3 frames.

Let me know if you need any more information.

nautilus7

9th September 2008, 12:23

An E-AC-3 decoder is required to handle normal AC-3 as well. An AC-3 decoder cannot decode E-AC-3, but it can recognize it as an AC-3 variant with an unknown bitstream id, so it will skip those frames.

Wrong. It is a HUGE problem because all the sample files that I have that contain E-AC3 will fail with regular AC3 decoders which all attempt to decode the audio. The specification is simply retarded and should be ignored. Splitter can detect E-AC3 and should pass that info along.

AC3 needs to be separate from E-AC3 because libav FAILS TO DECODE AC3 after 1-2 seconds so we need one filter for AC3 and one for E-AC3 (at least for now) ! :eek:
How does what you said agree with what Justin said? The E-AC3 decoder can decode AC3. It works with AC3 here.

madshi

9th September 2008, 12:27

Is there a way to detect if the stream is EAC3 when the input codec is AC3 ?
By analyzing the header
Something like this:

eac3 = ((((char*) audioframe)[5] & 0xf8) >> 3) >= 11;

Mercury_22

9th September 2008, 14:13

How does what you said agree with what Justin said? The E-AC3 decoder can decode AC3. It works with AC3 here.

Please test this (http://rapidshare.com/files/143875772/Test_LibavAC3.avi.html) with ffdshow's (svn 2111) libav for AC3 for at least 10 -20 sec and let me know how it works for you !
At my side after 6-7 sec I'm geting just noise instead of sound ! :helpful:

Edit: The 64-bit version of FFDShow svn 2111 it's CRASHING any AC3 or E-AC3 file when I'm using libav for AC3/E-AC3
Please help !
:helpful:

nautilus7

9th September 2008, 14:38

Well, I tested it. The file indeed doesn't decode correctly, but that's NOT a libav problem. There's something wrong with your file, because I remuxed it to matroska and plays perfectly! I am listening to it right now.

I have tested some more AC3 files with libav. 100% success here! Everything plays as it should be. (windows xp sp2 - 32bit)

clsid

9th September 2008, 14:43

AC3 in MKV works here too. But AC3 in AVI does not. And all files are 100% valid.

nautilus7

9th September 2008, 14:56

nevermind...

_xxl

9th September 2008, 15:23

But AC3 in AVI does not. And all files are 100% valid.
The same here. Only dca libav decoder seems to work properly.

madshi

9th September 2008, 16:03

You guys make it sound as if the decoder was at fault. But how can the decoder be at fault when decoding succeeds as soon as the AC3 track is muxed to MKV? I rather think that the decoder is not being fed correctly. IIRC some libav decoders depend on being fed exactly one frame at a time. Not all splitters do that.

Do you feed the libav decoder directly? Or do you run the data from the splitter through the libav parser before sending it to the decoder?

clsid

9th September 2008, 16:35

ffdshow is clearly at fault, not libavcodec. Data gets send directly to libavcodec afaik.

_xxl

9th September 2008, 16:35

I rather think that the decoder is not being fed correctly
True. Do you feed the libav decoder directly? Or do you run the data from the splitter through the libav parser before sending it to the decoder?
No, directly. That part to fed libavcodec audio decoder has to be implemented.

albain

9th September 2008, 18:03

I have built a new version with channel remapping. Please tell me if this is okay (for AC3, EAC3, AAC streams)

http://rapidshare.com/files/143901134/ffdshow_rev2111_20080909_dbt_ch_remap.exe.html

_xxl

9th September 2008, 18:20

AC3 and DTS no sound with:
http://x264.nl/h.264.samples/force.php?file=./premiere.hd.ts
http://samples.mplayerhq.hu/A-codecs/AC3/TomorrowNeverDies-2.1-48khz-192kbit.ac3
DTS:
http://samples.mplayerhq.hu/A-codecs/DTS/dtsac3audiosample.avi
AAC:
http://samples.mplayerhq.hu/A-codecs/AAC/file.avi
Doesn't load aac libav decoder.
More samples here:
http://x264.nl/h.264.samples/
http://samples.mplayerhq.hu/A-codecs/AC3/
http://samples.mplayerhq.hu/A-codecs/DTS/
http://samples.mplayerhq.hu/A-codecs/AAC/

albain

9th September 2008, 18:32

Something like this:

eac3 = ((((char*) audioframe)[5] & 0xf8) >> 3) >= 11;

It is not working : I get audioFrame[5] = 48 (0x30)
0x30 & 0xf8 = 0x30, 0x30 >> 3 = 6 which is not >= 11

So I get 6 for an EAC3 stream, and 8 for an AC3 stream

Something I missed ?

clsid

9th September 2008, 19:04

There is a difference in pin details:
http://i37.tinypic.com/mmst4y.png

nautilus7

9th September 2008, 19:07

AC3 and DTS no sound with:
http://samples.mplayerhq.hu/A-codecs/AC3/TomorrowNeverDies-2.1-48khz-192kbit.ac3

This sample starts with an incomplete frame. Run it though delaycut and it plays, BUT it is identified as 6ch (it's 2.1) and plays in faster speed. Though this behavior is completely different than playing as it is. :confused:

Liisachan

9th September 2008, 19:13

"audioframe" is a synch frame, maybe you'll need to find a sync word first

BYTE* pSync=NULL;
p=audioframe;
while(p<audioframe+framesize-6)
{
if( *p == 0x0B && *(p+1) == 0x77 )
{
pSync = p;
break;
}
++p;
}
if( ! pSync ) return;

bsid = ( pSync[ 5 ] >> 3 );
if( bsid == 0x08 )
{
//normal ac3
}
else //if( bsid == 0x10 )
{
//eac3
}

albain

9th September 2008, 22:09

Ok, the buffer has to be decoded first (which makes sense) and a sync flag detected

I wanted to detect it before sending the buffer to the decoder...

Thing to do : implement into FFDShow the decoding of the first frame before going further (this is what is done info mplayer).

cc979

10th September 2008, 03:37

compiling ffdshow-tryout svn:2112 using gcc-4.2.4 i get this error, does anyone else get this or have any ideas ?

cheers

In file included from ffdshow_imgfilters_all.cpp:7:
TffPict.cpp: At global scope:
TffPict.cpp:54: warning: 'AVPaletteControl' is deprecated (declared at ../ffmpeg/libavcodec/avcodec.h:2067)
In file included from ffdshow_imgfilters_all.cpp:19:
TimgFilterOSD.cpp: In member function 'virtual long int TimgFilterOSD::process(std::list<TfilterQueueItem, std::allocator<TfilterQueueItem> >::iter_list, TffPict&, const TfilterSettingsVideo*)':
TimgFilterOSD.cpp:501: error: no matching function for call to 'TsubtitleTextBase<char>::format(TsubtitleFormat)'
../subtitles/TsubtitleText.h:229: note: candidates are: void TsubtitleTextBase<tchar>::format(TsubtitleFormat&) [with tchar = char]
In file included from ffdshow_imgfilters_all.cpp:39:
avisynth/TimgFilterAvisynth.cpp: In member function 'void TimgFilterAvisynth::Tavisynth::process(TimgFilterAvisynth*, std::list<TfilterQueueItem, std::allocator<TfilterQueueItem> >::iter_list&, TffPict&, const TavisynthSettings*)':
avisynth/TimgFilterAvisynth.cpp:765: warning: deprecated conversion from string constant to 'char_t*'
avisynth/TimgFilterAvisynth.cpp:775: warning: deprecated conversion from string constant to 'char_t*'
make[1]: *** [ffdshow_imgfilters_all.o] Error 1
make[1]: Leaving directory `/home/User/svn/ffdshow-tryout/ffdshow-tryout/src/imgFilters'
make: *** [lib] Error 2

Liisachan

10th September 2008, 04:53

Ok, the buffer has to be decoded first (which makes sense) and a sync flag detected [...] Thing to do : implement into FFDShow the decoding of the first frame I'm not sure if I understand you correctly but you don't need to decode the AC3 stream to detect bsid. When decoded, the result is PCM or something? sync word and bsid are something that are in undecoded AC3 stream, not in the decoded ones, and if you can access the raw binary data, all you have to do is to check it starting from the beginning one byte by one byte until you find a sync word, and you're sure it is actually a sync word if the things after it make sense.

btw.. checking the 1st frame should help a lot. But theoretically each SyncFrame has a sync word and those header flags, meaning, even if the first frame is the normal ac3, for example 10th frame may have an eac flag

CiNcH

10th September 2008, 06:53

Haali Media Splitter exposes two media subtypes for files with E-AC3 audio:
MEDIASUBTYPE_DOLBY_AC3 and {0000EAC3-0000-0010-8000-00AA00389B71}

Currently, ffdhsow only looks at the first mediatpye it gets. If we can make ffdshow take the second mediatype in consideration, then it would be possible to separate EAC3 decoding from AC3 decoding. Allowing to use a different decoder for regular AC3.

Now ffdshow uses the same decoder for both AC3 and E-AC3. Not a big problem since both decoders are currently compatible with each other. But the annoying thing is that the Info&CPU page in ffdshow will always show that the input is AC3.

Things are really getting worse. If an application added a decoder selection for EAC3, this means that it would include all decoders with the AC3 subtype, whether they support EAC3 or not. My opinion is... define a proprietary subtype.

There is a lack of specification for new A/V formats in the DirectShow world. But it is IMHO better to define something proprietary instead, than to adapt something that just does not really make sense and increases confusion big time.

We are running into severe problems with AC3, EAC3, EAC3-BDMV (with compatible AC3 "core"), TrueHD, TrueHD-BDMV (again with compatible AC3 "core") if we can't distinguish decoders from each other.

madshi

10th September 2008, 07:20

I'm not sure if I understand you correctly but you don't need to decode the AC3 stream to detect bsid. When decoded, the result is PCM or something? sync word and bsid are something that are in undecoded AC3 stream, not in the decoded ones, and if you can access the raw binary data, all you have to do is to check it starting from the beginning one byte by one byte until you find a sync word, and you're sure it is actually a sync word if the things after it make sense.
Correct.

btw.. checking the 1st frame should help a lot. But theoretically each SyncFrame has a sync word and those header flags, meaning, even if the first frame is the normal ac3, for example 10th frame may have an eac flag
I've never seen a track which changes from AC3 to E-AC3 or vice versa. I'm not even sure if that is allowed. I wouldn't bother with that because it doesn't really occur in real life...

ACrowley

10th September 2008, 07:47

I have built a new version with channel remapping. Please tell me if this is okay (for AC3, EAC3, AAC streams)

http://rapidshare.com/files/143901134/ffdshow_rev2111_20080909_dbt_ch_remap.exe.html

No...still wrong mapping with libavcodec on EAC3 and AC3
Center Channel/Voices are coming aout of the back speakers

Also some AC3 Files are not working anymore. Output is corrupted

albain

10th September 2008, 09:25

OK, my mistake.

I have tested your code and actually I get the same result (i.e 8 for AC3 and 6 for EAC3 streams, not 0x10).
This is normal that I get the same result because I analyse the first frame and the first frame has always the sync word.

However your piece of code is useful for one reason : unlike ffmplay, directshow streams may not start from the beginning, so we have to wait for the first sync frame to detect its format.

One other thing that may explain why AC3 works for a few seconds with an avi file : clsid posted a difference in the input pin between MKV and AVI. AVI splitter detects wrongly the format.

In ffmplay the header is updated in the initialisation (it does not trust the given input format). In direct show we have no frame in input to do this. So the initialisation part should be completed in the decoding. Don't know if this is a problem.

albain

10th September 2008, 15:43

Decoding is always successful from libavcodec but the sound is garbled : I tried to feed the decoder only by sync frames, it is better but far from perfect.

In mplayer the buffers are :
1/ Input stream (not the buffer) is demuxed (ds_get_packet_pts). Don't know why it has to be done, this is the job of the splitter ?
2/ Decoded

In FFDShow the input buffer (from the splitter) is directly fed into the decoder and the output buffer is directly fed into the output pin.

Liisachan

10th September 2008, 17:06

@albain
The value 6 kind of makes sense too: a_52b.pdf says bsid=6 for Alternative Bit Stream (Annex D). Although, it's not what is called Enhanced AC-3 in Annex E, where bsid=16 (0x10).

PS.
from PDF
http://www.atsc.org/standards/a52.html

It is not necessary for decoders to be
aware of this alternate syntax in order to properly reconstruct an audio soundfield; however those
decoders that are aware of this syntax will be able to take advantage of the new system features
described in this Annex. This alternate bit stream syntax is identified by setting the bsid to a value
of 6.

...
D3.2 Legacy Decoder Processing
Legacy decoders do not recognize the alternate bit stream syntax, but rather interpret these bit
fields according to their original definitions in A/52B. The extra bit stream information words
(xbsi1e, xbsi2e, dmixmod, etc.) are interpreted as time code words (timecod1e, timecod1, timecod2e, and
timecod2).
As described in A/52B, the time code words do not affect the decoding process in legacy
decoders. As a result, the alternate bit stream syntax can be safely decoded without causing
incorrect decoder processing. However, legacy decoders will not be able to take advantage of new
functionality provided by the alternate syntax.

nautilus7

10th September 2008, 18:07

Do you feed the libav decoder directly? Or do you run the data from the splitter through the libav parser before sending it to the decoder?

Data gets send directly to libavcodec afaik.

No, directly. That part to fed libavcodec audio decoder has to be implemented.
What about this? Could this be the problem?

albain

10th September 2008, 18:52

MatMaul

10th September 2008, 19:15

why not ask on the libav-user mailing list ?
https://lists.mplayerhq.hu/mailman/listinfo/libav-user

Mercury_22

11th September 2008, 09:34

Maybe this will help In FFmpeg, libavformat separates E-AC3 from AC3. I understand that ffdshow uses libavcodec for the decoding, but does it have a libavformat "splitter" for demuxing? If not, they can look at the code in libavformat/raw.c and libavcodec/ac3_parser.c to see how it's done.

madshi

11th September 2008, 10:20

From the sample code that I've seen (drdivx) the data is also sent directly (have not tested it, maybe it doesn't work either). But sample code based on directshow+libavcodec is rare.

And code from mplayer is quite complicated and is not the same issue : decoding data from a file is different from decodingdata from a buffer.

Any help would be greatly appreciated...
Where exactly is the problem? As far as I can see you have 2 options:

(1) Either run the DirectShow data coming from the splitter through the libav *parser* before sending it to the libav *decoder*. Or:
(2) Add a little buffer which collects data coming from the DirectShow splitter and then parse the data yourself and feed the decoder exactly one audio frame at a time.

Both should correct the problem. Probably doing (1) would be a lot easier cause it should work with any codec libav supports. So you wouldn't have to do anything AC3 or E-AC3 specific. You'd just need to figure out the libav parser API - which is not too complicated, IIRC. So instead of this:

DirectShow input pin -> libav decoder -> DirectShow output pin

... you'd do this:

DirectShow input pin -> libav parser -> libav decoder -> DirectShow output pin

The libav parser does the following tasks:
- searches for the first sync frame
- throws away all trash before the first sync
- splits the data into audio frames
- returns always exactly one valid and complete audio frame at a time

Some libav decoders need this careful data preparation, others don't. But it should never harm running any audio data which you want to decode with a libav decoder through a libav parser, first. That includes all those codecs ffdshow is supporting for a long time, e.g. FLAC. The libav parsers are specifically written to work well together with the libav decoders, of course. So you shouldn't lose anything by adding the libav parser in between...

albain

11th September 2008, 10:22

Maybe this will help

No, I tried to force the codec ID to EAC3 and this did not solve the problem.

This is really a problem because FFDShow is not a splitter so it receives the demuxed packets from the input filter.
MKV splitter does this well, but not AVI splitter.

From the other hand, internal liba52 decoder decodes AC3 streams well whereas going through libavcodec gives garbled sound for both AC3 & EAC3 streams.

The solution is not easy to implement : the input data that is received should be reformated into correct audio frames before feeding the decoder (or the renderer).

Inventive Software

11th September 2008, 11:10

It isn't a splitter, but for the purposes of these kinds of audio formats, maybe adding basic libavformat support before passing it to libavcodec wouldn't be such a bad thing.

albain

11th September 2008, 11:25

I agree, I wish it could be avoided : libavformat is not imported into FFDShow code.

I am currently doing this import, this is some kind of work...

MatMaul

11th September 2008, 11:45

isn't parser directly implemented in libavcodec (and not in libavformat) ?
if you look inside avcodec.h you can find a function avcodec_parse_frame

CiNcH

11th September 2008, 12:08

Hey guys,

something about H.264 and VC-1 frame parsing...

we finally found the problem with ffdshow not working with most splitters/demuxers in case of H.264 and VC-1 (actually it only works with Haali and the MPC MpegSplitter who have adopted the ffdshow approach).

The ffdshow filter uses ffmpeg/libavcodec to decode the two formats. What this library expects is the Elementary Stream (ES) of a complete H.264/VC-1 frame, in case of H.264 also called a NALU (so from startcode to startcode). ffdshow has taken this approach a level higher to DirectShow as it also expects a whole frame within one DirectShow sample on its input which is then sent directly to the library.
So with knowing this, a splitter could adopt that approach of course (like Haali and MPC did), but in this case the splitter would have to parse the H.264/VC-1 bitstream already. Our understanding of a splitter is that it knows nothing about the bitstream or ES data in particular, nothing about frames, nothing about NALU's, nothing about startcodes. A decoder for a specific format has to deal with that.

Casimir666 from the MPC-HC project implemented a parser within the MPC Video Decoder (which is also a ffmpeg wrapper and also adopted the ffdshow approach) that collects whatever ES data it gets from the splitter (whether it is a whole frame or 10K junks or 100K junks of ES data, whatever) and parses it, means, it builds the frames on its own (from startcode to startcode) and finally sends them to the ffmpeg lib. This basically works now.

Most of todays splitters output a certain amount of ES data per DirectShow sample not knowing what it actually is. In your case a splitter has to exactly know what it is to collect the data that makes up a frame which is a major design flaw IMHO and the reason why it does not work with most splitters for H.264 and VC-1.

Hope I was precise enough and you understood the problem. Casimir will hopefully check the parser code into the MPC-HC project reporistory (MpcVideoDec (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/mpcvideodec/?pathrev=784)). MPC MpegSplitter should have such a frame parser already as it sends out exactly what ffdshow currently needs..

clsid

11th September 2008, 12:39

Hmmm, doesn't ffdshow already have such code? There is a function called 'decodeH264SPS' in ffglobals.cpp. I don't know what it does exactly, but I suspect it is related to what you said.

CiNcH

11th September 2008, 13:26

Right, it synches to the stream there. But where does it get the char-Buffer from (hdr) from? Maybe it is the buffer it gets from the splitter? SPS and PPS may be in there but not the whole data that makes up the frame. But I think I did not get the whole NALU, SPS, PPS, frame thing completely yet.

Shakey_Jake33

11th September 2008, 14:10

This is a stupid as hell question, but also one that bugs me. I assume that if I enable Deinterlacing in ffdshow, it's smart enough to skip deinterlacing on files that aren't interlaced?

albain

11th September 2008, 16:02

isn't parser directly implemented in libavcodec (and not in libavformat) ?
if you look inside avcodec.h you can find a function avcodec_parse_frame

No there is not, this method is dedicated only to MPEG streams.

I have not given up on importing libavformat...

LoRd_MuldeR

11th September 2008, 16:16

This is a stupid as hell question, but also one that bugs me. I assume that if I enable Deinterlacing in ffdshow, it's smart enough to skip deinterlacing on files that aren't interlaced?

No it doesn't! There is no reliable way to find out whether a video is interlaced or not, except for your own eyes. So ffdshow cannot know it!

Even if the stream was encoded as interlaced, this doesn't mean that the content actually is interlaced :rolleyes:

Some kind of automated film/video detection could be implemented into ffdshow, but such algorithms don't work 100% reliable and eat CPU cycles...

albain

11th September 2008, 21:51

I have finished importing libavformat.

Before going further I would like your feedback on possible regressions on FFDShow

Here is the link of the patch (based on FFDShow revision 2111) :
http://damienbt.free.fr/FFDShow_libavformat.zip

Normally, there will be no interferences.

If I have the go, I will commit the code to SVN

Damien

clsid

11th September 2008, 22:33

Exact what changes did you make to the functionality of ffdshow?

Your patch seems to contain the whole codebase of libavformat. That is a lot of unneeded stuff. Why not include just those few parts that are actually getting used?

Currently the patch contains a lot of junk. Please don't commit this. Make smaller patches for individual changes. Lets take one step at a time, instead of jumping to the moon.

albain

11th September 2008, 22:59

Right, except that this is not that easy : most of libavformat files are dependant with each other.
Libavformat is just a library, nothing is used inside FFDShow code for now.

Importing small parts is more work than importing the library itself.

Anyway, I will continue on it until I get decoding working, after I will see if some parts can be removed...

_xxl

12th September 2008, 07:33

Don't hesitate to create a new branch ex: ffdshow-libavformat and commit your patches. It is easier then to have a lot of patches for trunk.

I can't apply your patch.

clsid

12th September 2008, 12:11

If it isn't used, then we won't need it and it should not be added.

You only want to parse an audio bitstream. Take should take no more than a couple hundred lines of code. Not a 2,3 MB patch.

_xxl

12th September 2008, 12:40

Changes from trunk could be reverted and re added when finished? I'm talking about libavcodec audio decoders that don't work.

madshi

12th September 2008, 12:49

If it isn't used, then we won't need it and it should not be added.

You only want to parse an audio bitstream. Take should take no more than a couple hundred lines of code. Not a 2,3 MB patch.
I think the point is that adding libav parsers to ffdshow would make sure that all the funny libav audio decoders could be easily made to work, including AC3, E-AC3, TrueHD, AAC etc etc. Without adding the libav parsers some of those decoders might not work properly cause some of them have strict requirements on how they want to get the data fed. Now a parser for just AC3 and E-AC3 would be only a couple of lines long. But it would be nice to make *all* libav audio decoders work.

Thoughts?

albain

12th September 2008, 12:50

Changes from trunk could be reverted and re added when finished? I'm talking about libavcodec audio decoders that don't work.

Which ones ? I am not aware of that. The only things that I have changed is adding a new available decoder for AC3/DTS streams.
Not using this decoder and select the former will (should) give the same behaviour as before.

@clsid : the patch is heavy you said, this is your point of view, but isn't it easier to update ffmpeg when you are closer to their code ?
Also, several decoders are not imported yet into FFDShow and they could be. So why not seing this as an "investment" for the future ? Although I agree that all the parts that will never be used should be removed...
Anyway, this is politics, I won't argue with it, this is the reason why I made a new "tryout" branch. The useful part of it will be merged when everyone will report it as ready...

_xxl

12th September 2008, 12:53

When ffmpeg audio decoders will work ok, then those: liba52, libdca and realacc should removed from ffdshow?

Inventive Software

12th September 2008, 12:54

I think the point is that adding libav parsers to ffdshow would make sure that all the funny libav audio decoders could be easily made to work, including AC3, E-AC3, TrueHD, AAC etc etc. Without adding the libav parsers some of those decoders might not work properly cause some of them have strict requirements on how they want to get the data fed. Now a parser for just AC3 and E-AC3 would be only a couple of lines long. But it would be nice to make *all* libav audio decoders work.

Thoughts?

Sounds good madshi, but I've seen it said that ffdshow has first and foremost been a decoder only, not a parser. But if this is the only way to get audio working properly, then I can see it working. It may also be beneficial for the video decoder with, for instance, game video formats. :)

BTW, I think libmad MP3 decoding is partially broken in ffdshow. I'm on 2073 IIRC, and I have a 44100Hz 16-bit file in an AVI that was resampled from 48000Hz 16-bit in VirtualDub. It exhibits clicks and pops alongside the normal audio, but the built-in Windows DShow Decoder (Fraunhofer IIRC) plays it back without problems.

_xxl

12th September 2008, 12:55

Which ones ? I am not aware of that. The only things that I have changed is adding a new available decoder for AC3/DTS streams.
I was talking about those changes that aren't used in trunk: libav ac3, dca and aac.

clsid

12th September 2008, 12:56

albain

12th September 2008, 12:57

When ffmpeg audio decoders will work ok, then those: liba52, libdca and realacc should removed from ffdshow?

I think they should, especially liba52 decoder that has been tricked by Haruhiko and I to fix high bitrates decoding issue and which is still not up to date

clsid

12th September 2008, 12:58

When ffmpeg audio decoders will work ok, then those: liba52, libdca and realacc should removed from ffdshow?
Just realaac. Having alternatives is useful. If libavcodec proves to work ok, then the other can be removed after a couple of months.

_xxl

12th September 2008, 13:03

Not now, until finished and tested libav audio decoders. What could be removed is AudX. It crashes with some files. Maybe libavcodec mp3, mp2 should be added to replace it.

albain

12th September 2008, 13:06

There is a difference between adding some parsers and the whole of libavformat. The current branch contains 223 !!!!! modified/added files. That is a bit much don't you think? Also, there have been many unrelated changes to libavcodec, just blindly merged from FFmpeg. That must be undone. This branch is a giant mess right now. All differences from FFmpeg are intentional!

Well, thanks for your support of the job I have done, I appreciate

Changes that I have brought is synching with FFMPeg code but I did not modified the existing methods and structures (only added new members to existing structures)
New code added is only unused code (for now), and AFAIK I made "smart" merge between the modified code by FFDShow and updated code from FFMPeg, and it actually works from the tests I have made.

Like I said, I will remove non useful code from the branch when I will have finished. I am not the admin of this project so I won't merge anything to the trunk without a go.
Anyway, decision about what to merge can be postponed, can't be ?

Inventive Software

12th September 2008, 13:13

What clsid's objecting to is importing the whole libavformat lib into ffdshow-tryouts. I'd do it locally on your system, then submit what's necessary.

_xxl

12th September 2008, 13:13

I think of ffdshow only from 3 components: ffdshow.ax, libavcodec and mplayer. The rest isn't used from most users anyway...

nautilus7

12th September 2008, 13:16

Wouldn't be useful to release a new version of ffdshow with all latest additions, so we can test and report? Then it would be easier for you (developers) to decide whether should or shouldn't remove the unused parsers.

clsid

12th September 2008, 13:26

@albain
Well, your work is appreciated, don't get me wrong. I would just like to keep things tidy. The branch being a mess now doesn't matter if it is going to be cleaned up later. Please take all the time you need. Merging won't be an issue until everything is properly tested.

Some questions:
You are parsing the audio bitstream to see whether it contains AC3 or E-AC3, right? Will this lead to separation of the two decoders? So will a user be able to for example enable E-AC3 decoding in ffdshow and use a different decoder for AC3?
I saw you added some kind of channel re-ordering functionality to libmplayer. Isn't there any code from the Mixer that you can re-use for that purpose (just an idea)?
Are you planning to add parsing code for other audio formats? If so, which formats?

@_xxl
audx can be removed.

albain

12th September 2008, 13:26

No problem, I will clean it before merging it, and before merging it I will submit a patch and a suposely working build version

Concerning parsing, from what I have seen from libavcodec code there is no need to separate EAC3 or AC3 codec ID : the decoder does it internally. However, it is necessary to separate them in order to use a different decoder from ffdshow config. We all agree with this.
I thought that using a wrong codec ID (AC3 instead of EAC3) caused the garbled sound but this has nothing to do.
Concerning the reording channel issue, I don't think (but I am not sure of that) that this is the same issue : channels are not delivered into the same order by libavcodec, depending of the audio format, which is the goal of the code that I have added.
However the goal of the mixer is to reorganize the channels according to your audio setup, right ?

Concerning the other audio formats : I have seen that FFMPeg will bring full decoding support for AAC in the next few weeks, so for now I guess that just disabling libavcodec AAC but keeping the code is a good idea.
Next step (after making AC3/EAC3 working) : adding a new decoder and a new input format for bitstream and truehd (I did not digg this around for now)

_xxl

12th September 2008, 13:32

Having libavformat integrated in MPC-HC would be great.

Inventive Software

12th September 2008, 13:34

Contact the MPC-HC devs then. ;)

clsid

12th September 2008, 14:24

I think it would be easier to add DXVA to MPlayer instead (which already uses libav*) than trying to wrap everything into a DirectShow filter. But this is getting offtopic.

_xxl

12th September 2008, 14:32

I don't know what it is easier, but mplayer has many developers and maintainers. ffdshow and mpc have few.

madshi

12th September 2008, 15:00

Maybe it would make sense to compile libavcodec and libavformat to dlls and then use those from ffdshow? That would keep the ffdshow code very clean and still allow to use all audio codecs ffdshow supports. That's also what I'm doing in eac3to. Although my major reason for linking to the libav dlls is that I'm using Delphi for my programming projects.

davidw89

12th September 2008, 15:08

Does anyone know how to tweak and maximize the settings for upscalling all content to 1080p and maximum quality (i have a powerful comp)

clsid

12th September 2008, 15:35

madshi

12th September 2008, 16:14

We have always already compiled libavcodec as a dll.
Ooops, didn't know that. Great! So why not doing the same thing with libavformat, so that ffdshow can access the parsers?

clsid

12th September 2008, 16:21

All libav* stuff will be in a single dll. The debate was never if the parsers should be included or not. I just want to include only stuff that is actually being used by ffdshow. We only need maybe a few % of the libavformat code base.

madshi

12th September 2008, 16:26

Ah, I see. Sorry, I'm not intimate with the ffdshow code internals.

albain

12th September 2008, 16:29

Good news : EAC3 and AC3 decoding seem to work now, maybe AAC too, I did not test it.

There is a remaining problem : audio channels are not in the right order.

You can test the build :
http://rapidshare.com/files/144693711/ffdshow_rev2116_20080912_dbt_beta.exe.html

_xxl

12th September 2008, 16:33

Thanks!
I''ll test soon and post the results.

Inventive Software

12th September 2008, 16:57

Audio channels can be sorted via the "Mixer" tab for an interim solution. eac3to AFAIK does it's own channel (re-mapping) correctly. I'm currently finding the page/post with the channel details in that thread. Wait 5.

MLP channel orders: http://forum.doom9.org/showthread.php?p=1136976#post1136976

DTS channel orders: http://forum.doom9.org/showthread.php?p=1179314#post1179314

Can't find E-AC3 channel orders, but maybe madshi can provide an immediate insight. :)

albain

12th September 2008, 17:01

I have fixed the problem for incorrect channel mapping too

_xxl

12th September 2008, 17:03

Ok:
7_pt_1.eac3
broadway-5.1-48khz-448kbit.ac3
buggy_aht_5.1_384.eac3
bbc.hd.ts samples from x264.nl
No:
matrix2_commentary1_stereo_192.eac3
tomorrowneverdies-2.1-48khz-192kbit.ac3
casablanca_aht_mono_64.eac3
are playing to fast.
Also aac libavcodec doesn't load.
Dca just crashes.

Minor: current input bitrate is always 0 kbps.

albain

12th September 2008, 17:04

Here is the updated version fixing channel mapping :
http://rapidshare.com/files/144701690/ffdshow_rev2116_20080912_dbt_beta2.exe.html

The good news is that I didn't use libavformat.
I have to check this just in case, but all the methods that I called are located into libavcodec + the methods that I added to mplayer for channel remapping.

EDIT : AAC decoder is still not working correctly, but this is normal (ffmpeg team will update it soon)

@xxl : this problem may be due to incorrect information reported by the splitter. May be solved by updating from libavcodec context to directshow structures ?

I have posted my last sources on the branch, if you want to play around with it and fix the problems.

I will try to remove libavformat completely if it is not used at all.

nautilus7

12th September 2008, 18:00

E-AC3 channel mapping still wrong.

It's L-SR-C-R-SL-LFE while it should be L-R-C-LFE-SL-SR

albain

12th September 2008, 18:14

E-AC3 channel mapping still wrong.

It's L-SR-C-R-SL-LFE while it should be L-R-C-LFE-SL-SR

And with AC3 is it okay ?
It should be easy to fix

nautilus7

12th September 2008, 18:29

Exact same problem with AC3.

(sorry, should have test it along with E-AC3)

clsid

12th September 2008, 19:18

I have done some cleanup, Now there are just 19 files that are different between trunk and the test branch.

Edit: test build rev. 2120 (http://www.zshare.net/download/18660707c250563e/)

ACrowley

13th September 2008, 08:36

E-AC3 channel mapping still wrong.

It's L-SR-C-R-SL-LFE while it should be L-R-C-LFE-SL-SR

yep....its still a little bit wrong for EAC3 and AC3 so far i can "hear"

albain

13th September 2008, 09:28

I have found the origin of the problem concerning audio files playing too fast : number of channels was not correct

Here is an updated build :
http://rapidshare.com/files/144879929/ffdshow_rev2124_20080913_dbt_beta3.exe.html

If all samples are okay, next step is to fix the incorrect channel mapping (maybe it will be fixed by the previous fix).

(I have posted the fix to subversion rev 2124 on the branch libavformat)

MatMaul

13th September 2008, 12:57

It doesn't work with aac : the player stays at 00:00

works fine with ac3 and dts (I haven't checked the channel order)

albain

13th September 2008, 13:17

Where can I find a TrueHD sample ?

Thanks

nautilus7

13th September 2008, 13:27

Where can I find a TrueHD sample ?

Thanks

I will send you some samples asap.

EDIT:

TrueHD 5.1ch 48KHz (http://www.sendspace.com/file/i3ddtz)
TrueHD 5.1ch 48KHz (with AC3 track) (http://www.sendspace.com/file/i3hsxq)
TrueHD 7.1ch 48KHz (with AC3 track) (http://www.sendspace.com/file/aehzk3)
TrueHD 7.1ch 96KHz (http://www.sendspace.com/file/19crol)

Atak_Snajpera

13th September 2008, 13:46

TrueHD sample
http://www.mediafire.com/?dcdoyvf0sgs

albain

13th September 2008, 17:43

How do you play those ?
I found no way to mux them into a container that supports this format.

I also tried arcsoft player but it does not detect this media file either.

:confused:

EDIT : also tried with mplayer, I got several errors
"[mlp @ 003E5050]Stream parameters not seen; skipping frame."

nautilus7

13th September 2008, 17:59

Oh, you need them into a container... Wasn't sure so i demuxed them. :o

Will re-upload them into their original containers (.m2ts and .evo). Starting now.

EDIT:
TrueHD 5.1ch 48KHz into .evo (http://www.sendspace.com/file/kvg83h)
TrueHD 5.1ch 48KHz (with AC3 track) into .m2ts (http://www.sendspace.com/file/ffzfhh)
TrueHD 7.1ch 48KHz (with AC3 track) into .m2ts (http://www.sendspace.com/file/fxpmum)
TrueHD 7.1ch 96KHz (with AC3 track) into .m2ts (http://www.sendspace.com/file/ul4f3x)
TrueHD 7.1ch 96KHz into .evo (http://www.sendspace.com/file/8k0l20)

_xxl

13th September 2008, 18:45

Still no sound with: cine.premier.hd.astra.19e.05.feb.2008.ts.
Dca is crashing with: x264.dts.sample.mkv
http://rapidshare.com/files/144998756/samples.7z.html

K1ngp1ng

13th September 2008, 18:53

How do you play those?
http://www.winamp.com/plugins/details/221516

pitch.fr

13th September 2008, 20:22

nautilus7

14th September 2008, 09:16

DTS decoding with libavcodec has serious problems. It crashes with every single DTS-HD track, instead of just decoding the DTS core and dropping the -HD extensions. With simple DTS is ok.

_xxl

14th September 2008, 11:27

With simple DTS is ok.
Is this sample working with ffdshow's dca libav decoder?
http://samples.mplayerhq.hu/A-codecs/DTS/dtsac3audiosample.avi
For me it crashes.

madshi

14th September 2008, 11:36

DTS decoding with libavcodec has serious problems. It crashes with every single DTS-HD track, instead of just decoding the DTS core and dropping the -HD extensions. With simple DTS is ok.
libav/ffmpeg doesn't know and isn't able to handle DTS-HD. The DTS-HD data blocks must be stripped before sending the data to the libav DTS decoder.

nautilus7

14th September 2008, 11:54

The problem is caused by the exact same reason as in DTS-HD tracks.

The sample is cut in such way so it starts with a cut dts frame (the frame header is missing). This frame is recognized as garbage by the decoder and it crashes. The correct behavior should be to drop these garbage until the next dts frame header is found. Here (http://www.sendspace.com/file/gmv53m) is the dts track of this sample, but without the cut frame in the beginning. It plays fine. I found this out while trying to mux the sample to mkv. I got this message by mkvmerge:

skipping 629 bytes (no valid DTS header found)

Same should happen with DTS-HD. Decode the 1st DTS frame, skip all data (aka. the HD extensions) until the 2nd DTS frame header, decode the 2nd frame, skip all data (aka. the HD extensions) until the 3rd DTS frame header, etc.

nautilus7

14th September 2008, 11:55

libav/ffmpeg doesn't know and isn't able to handle DTS-HD. The DTS-HD data blocks must be stripped before sending the data to the libav DTS decoder.

OK, they must be stripped before they reach the decoder. Not by the decoder. Agreed. :)

madshi

14th September 2008, 12:05

Same should happen with DTS-HD. Decode the 1st DTS frame, skip all data (aka. the HD extensions) until the 2nd DTS frame header, decode the 2nd frame, skip all data (aka. the HD extensions) until the 3rd DTS frame header, etc.
I think this may be problematic because the DTS syncword can also "accidently" occur inside the DTS-HD block (I think). In such a case the splitter would see a part of the DTS-HD block as the beginning of the next DTS core frame. A crash could be the result again.

It would be better to properly strip the DTS-HD blocks by asking their length. That works like this:

if GetBits(bits, 32) = $64582025 then // DTS-HD sync dword
begin
GetBits(bits, 8);
GetBits(bits, 2);
blownUpHeader := GetBits(bits, 1) = 1;
if blownUpHeader then begin
GetBits(bits, 12);
sizeOfDtsHdBlockInBytes := GetBits(bits, 20) + 1;
end else begin
GetBits(bits, 8);
sizeOfDtsHdBlockInBytes := GetBits(bits, 16) + 1;
end;
end;

martino

14th September 2008, 19:53

This is perhaps a bit slightly offtopic, however I'd like to know whether anyone has tried to run ffdshow in wine and managed to get huffyuv (yv12) vfw decoding working. It installed fine for me, but I can't change any of the dropdown boxes (yet the registry entries seem to be set on 1) which results in a "couldn't locate a decompressor for fourcc ffds in VDub. Any help would be greatly appreciated. Thanks.

yesgrey

14th September 2008, 21:36

I got a question about resampling in ffdshow audio.

I find libavcodec to sound better than libsamplerate.

but was ffdshow updated with the recent updates from March and July ?
http://www.mega-nerd.com/SRC/history.html

would that be doable ?

thanks,

No it wasn't. I have looked now in svn and it's the old code.
I will take a look to see if I could update the code. If I could, I will create the new files and then I will request here some help on how to do it in the svn...

nautilus7

14th September 2008, 21:41

clsid was against this update: http://forum.doom9.org/showthread.php?t=138534

pitch.fr

14th September 2008, 22:06

home about some crazy packing ? like .7z ?
or some optional component ?

I can pack the Resampler.dll from Reclock to 480k with Winrar, so the diff with the older version wouldn't be 800k ?!

rickardk

14th September 2008, 22:50

No it wasn't. I have looked now in svn and it's the old code.
I will take a look to see if I could update the code. If I could, I will create the new files and then I will request here some help on how to do it in the svn...

I hope he reconsider as their is a big diffrence in sq.

yesgrey

14th September 2008, 23:55

I have finished the look at the code and it seems to be a very easy thing to do. The difference in sound quality from the old to the new is very big, especially using the best mode. I hope clsid reconsiders the change. I understand his point of view, but only if the quality diference was small.
He could always test reclock with the new resampler and test for himself if the quality improvement justifies the change...

Liisachan

15th September 2008, 05:12

@pitch.fr
btw did you read this recent post of Inventive Software?
BTW, I think libmad MP3 decoding is partially broken in ffdshow. I'm on 2073 IIRC, and I have a 44100Hz 16-bit file in an AVI that was resampled from 48000Hz 16-bit in VirtualDub. It exhibits clicks and pops alongside the normal audio, but the built-in Windows DShow Decoder (Fraunhofer IIRC) plays it back without problems.

see? libmad is not really reliable, it's as broken as hell in mplayer too, and the worst part of this is there's practically no one, especially no original libmad developer, to fix any bug...

And this is ffdshow's default mp3 decoder...:confused:

tal.aloni

15th September 2008, 06:04

Hello Albain,
first, thanks for all of your your efforts.
I waited a while for a free E-AC3 Codec, and I'm glad it's finally here. (ffdshow is great in general)

Just making sure you know, I'm currently using rev 2124 beta3, and the channel mapping problem is still present in 5.1 sources. (libavcodec)

unfortunately, swapping channels isn't a real workaround.
(since other sources doesn't have the wrong input mapping in the first place)

Note:
1. the problem is gone when liba52 is doing the decoding.
2. the problem does not exit when utilizing libavcodec using eac3to.

I can provide some AC3 / E-AC3 samples if needed (dolby setup tests)

Thanks,
Tal Aloni

nautilus7

15th September 2008, 06:35

2. the problem does not exit when utilizing libavcodec using eac3to.

Wrong. Libav does outputs channels with incorrect order and eac3to does it's own remapping after the decoding.

It's a general problem of the libav decoder.

tal.aloni

15th September 2008, 07:16

Wrong. Libav does outputs channels with incorrect order and eac3to does it's own remapping after the decoding.

It's a general problem of the libav decoder.

Thanks for the clarification.

Tal Aloni

CiNcH

15th September 2008, 08:16

Hey guys, is someone into MP3 parsing/decoding? We have implemented MP3 support into our splitter. What we do is splitting the MP3 Elementary Stream into 2K IMediaSamples and send them downstream. Now ffdshow fails to reconstruct the MP3 frames on some VBR files and introduces hiccups. It works properly with the Fraunhofer MP3 decoder coming with MS Windows.
MPA Audio Decoder shows the same effect as certain things within the OpenSource community seem to have spread ;) .

We then implemented a frame parser into the splitter and send them downstream which works around the problem. But this introduces a major flaw into our design.

Conclusion is that ffdshow tries to rebuild frames but fails somewhere, the decoder itself seems to work properly. Is it possible that the padding field within the MP3 header is not evaluated? Padding bytes are especially common with 44.1 kHz files where the encoder sometimes "fails" to meet frame length.

If you like I could provide player + splitter + sample. Just tell me who is in charge of that and is willing to solve the issue. I would be more than happy to contribute.

BTW, I am currently working with Haruhiko Yamagata to solve the NALU/frame thing for H.264/VC-1. A parser is indeed missing in this case only supporting Haali and MPC splitters..

albain

15th September 2008, 10:35

Still no sound with: cine.premier.hd.astra.19e.05.feb.2008.ts.
Dca is crashing with: x264.dts.sample.mkv
http://rapidshare.com/files/144998756/samples.7z.html

Crashing problem was due to a bad linking. It is working now.

Concerning your no sound issue, this is quite a problem because on this AC3 2 channels stream the parser seems to clean all the stream before feeding the decoder...

albain

15th September 2008, 10:41

If I disable the parser for 2 channels stream, it is working. :confused: weird

The parser can parse only multichannel streams ? (at least for AC3)

EDIT : actually, the parser works great for some 2 channels AC3 streams (Test_LibavAC3.avi), but not for some others (cine.premier.hd.astra.19e.05.feb.2008.ts from xxl)

By the way it would be great to have the channel remapping code if available (I don't have any HT receiver to make this fix)

madshi

15th September 2008, 10:53

By the way it would be great to have the channel remapping code if available (I don't have any HT receiver to make this fix)
Here's what eac3to is doing:

procedure RemapAc3ChannelsLibav;
begin
case audioDetails.Channels of
3 : if audioDetails.ChannelStr = '3/0' then
source.AddChildUpStream(ChannelMapper('0,2,1,3,4,5'));
4 : if audioDetails.ChannelStr = '2/1.1' then
source.AddChildUpStream(ChannelMapper('0,1,3,2,4,5'))
else
if audioDetails.ChannelStr = '3/0.1' then
source.AddChildUpStream(ChannelMapper('0,2,1,3,4,5'))
else
if audioDetails.ChannelStr = '3/1' then
source.AddChildUpStream(ChannelMapper('0,2,1,3,4,5'));
5 : if audioDetails.ChannelStr = '2/2.1' then
source.AddChildUpStream(ChannelMapper('0,1,4,2,3,5'))
else
if audioDetails.ChannelStr = '3/1.1' then
source.AddChildUpStream(ChannelMapper('0,2,1,4,3,5'))
else
if audioDetails.ChannelStr = '5.0' then
source.AddChildUpStream(ChannelMapper('0,2,1,3,4,5'));
6 : source.AddChildUpStream(ChannelMapper('0,2,1,5,3,4'));
end;
end;

procedure RemapDtsChannelsLibav;
begin
case audioDetails.Channels of
3 : if audioDetails.ChannelStr = '3.0' then
source.AddChildUpStream(ChannelMapper('1,2,0,3,4,5'));
4 : if audioDetails.ChannelStr = '2/1.1' then
source.AddChildUpStream(ChannelMapper('0,1,3,2,4,5'))
else
if audioDetails.ChannelStr = '3.1' then
source.AddChildUpStream(ChannelMapper('1,2,0,3,4,5'))
else
if audioDetails.ChannelStr = '3/1' then
source.AddChildUpStream(ChannelMapper('1,2,0,3,4,5'));
5 : if audioDetails.ChannelStr = '2/2.1' then
source.AddChildUpStream(ChannelMapper('0,1,4,2,3,5'))
else
if audioDetails.ChannelStr = '3/1.1' then
source.AddChildUpStream(ChannelMapper('1,2,0,4,3,5'))
else
if audioDetails.ChannelStr = '5.0' then
source.AddChildUpStream(ChannelMapper('1,2,0,3,4,5'));
6 : if audioDetails.ChannelStr = '5.1' then
source.AddChildUpStream(ChannelMapper('1,2,0,5,3,4'))
else
source.AddChildUpStream(ChannelMapper('1,2,0,3,4,5'));
7 : source.AddChildUpStream(ChannelMapper('1,2,0,5,3,4'));
8 : source.AddChildUpStream(ChannelMapper('1,2,0,5,3,4'));
end;
end;
This is for a quite old libav build, but I guess it should still be correct for the latest build, too. Channel remapping for AC3 and E-AC3 should be identical.

nautilus7

15th September 2008, 11:16

Concerning your no sound issue, this is quite a problem because on this AC3 2 channels stream the parser seems to clean all the stream before feeding the decoder...
I demuxed the ac3 track from the "cine.premier.hd.astra.19e.05.feb.2008.ts" file with eac3to. The ac3 plays just fine.

I have to say that some of these samples that produce problems are "weird". I can't tell if this could be the problem here, but eac3to reports a delay of 7secs for this .ts file which sounds uncommon for a cut sample. :confused:

albain

15th September 2008, 11:22

Thank you madshi, I will try to implement your code

Concerning this sample, I agree that the sample may be weird, but the libavcodec parser seems be too buggy too : it wipes out too many bytes, whereas this file doesn't need to be parsed at all (works great if directly passed to the decoder)

albain

15th September 2008, 13:31

Crashing on the DTS file occurs in ff_imdct_half_sse function.

I had the same error a while ago and it was fixed by installing a previous version of binutils, but here it goes again

_xxl

15th September 2008, 13:37

Crashing on the DTS file occurs in ff_imdct_half_sse function.

I had the same error a while ago and it was fixed by installing a previous version of binutils, but here it goes again

I'm using previous version of binutils. Can you share your mingw environment?

albain

15th September 2008, 13:52

I'm using previous version of binutils. Can you share your mingw environment?

MSYS 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 unknown; targ=MINGW32
Target: mingw32
Configured with: ../gcc-4.2.4/configure --prefix=/mingw --host=mingw32 --target=mingw32 --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags=-fno-function-sections -fno-data-sections --enable-fully-dynamic-string --enable-sjlj-exceptions
Thread model: win32
gcc version 4.2.4 (TDM-1 for MinGW)
binutils-2.17.50-20060824-1

albain

15th September 2008, 14:01

The file also crash with mplayer (and also plays fine with no optimization) :
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders

MPlayer interrupted by signal 11 in module: init_audio_codec
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug

_xxl

15th September 2008, 14:01

binutils-2.17.50-20060824-1
I was using binutils-2.17.50-20070129-1.
Thanks!

albain

15th September 2008, 18:05

Here is a new build with I hope the wrong channels mapping fixed.

If this is not the case, please tell me the expected mapping, and the actual one.

http://rapidshare.com/files/145520560/ffdshow_rev2131_20080915_dbt_beta4.exe.html

Concerning the crashing on DTS, this is definetely a compilation problem (binutils/gcc version) or a ffmpeg bug.
I tried binutils 2.17 & 2.18, same problem.
Disabling mmx optimization solves the problem.

tal.aloni

15th September 2008, 21:19

Here is a new build with I hope the wrong channels mapping fixed.

Hey Albain,
I'm glad you're working on the problem,
I've tested you're latest build, but I still have problems with mappings:

5.1 channels:
Front Left Channel (1) > Front Left Speaker (1)
Front Right Channel (2) > Front Right Speaker (2)
Center Channel (3) > Surround Left (5)
LFE Channel (4) > Surround Right Speaker (6)
Surround Left Channel (5) > Center Speaker (3)
Surround Right Channel (6) > LFE Speaker (4)

Thanks a lot,
Tal Aloni

nautilus7

15th September 2008, 22:00

Yes, I confirm the above wrong mapping for both AC3 and E-AC3.

It was L,RS,C,R,LS,LFE
It is now L,R,LS,RS,C,LFE
It should be L,R,C,LFE,LS,RS

Inventive Software

16th September 2008, 09:57

Hey Albain,
I'm glad you're working on the problem,
I've tested you're latest build, but I still have problems with mappings:

5.1 channels:
Front Left Channel (1) > Front Left Speaker (1)
Front Right Channel (2) > Front Right Speaker (2)
Center Channel (3) > Surround Left (5)
LFE Channel (4) > Surround Right Speaker (6)
Surround Left Channel (5) > Center Speaker (3)
Surround Right Channel (6) > LFE Speaker (4)

Thanks a lot,
Tal Aloni

The mapping on the left is for WAV only, the one on the right is for AC-3.

nautilus7

16th September 2008, 23:45

What do you mean by this?

Every decoder should output the same channel order (this the "wav" channel order), or else we 'll have to change the speaker's configuration each time we listen to a different audio format. We don't care what is the order of the channels inside the tracks. We just need them to be decoded in the same order.

Zep

16th September 2008, 23:52

Hi I just installed ffdshow_rev2110_20080908_clsid.exe and I have a few questions about subtitles.

for ffdshow subs to work I have to

Subtitle-Vobsob-enabled correct? I ask because I can't get subs to work other wise and it seem redundant to have.
Subtitle-enabled then have to have also have Subtitle-Vobsob-enabled unless you can turn off vobsub and still get subs working. I need both enabled?

With both enabled because that is only way I can see subs I am unable to change the rendering in 2 areas no matter what I try. the areas being

Subtitle-text
Subtitle-font

nothing changes. I even apply then restart MPC after each change to make sure but still nothing changes. I tried other players and same thing happens. So I do no think it is a MPC thing but I'm not 100% sure.

I do not have the external vobsub older stand alone or the VSFilter.dll as I only want this handled by ffdshow.

Subtitles-Vobsub area everything does work there but I want to change font and text formats as well. Right now I am stuck with white only subs in Arial. Am I doing something wrong or missing a step?

Thanks

Anima123

17th September 2008, 04:38

When enable dolby decoder, it still affect with plain stereo audio, which could get unwanted sound if the stereo audio track already does rear channels delay when convert from original 5.1 track. I wonder if we can add an option to make it not affect when rear channels are not fed.

Note: I've got only stereo speaker setup, thus no need to change stereo track up to 5.1 channels.

Snowknight26

17th September 2008, 05:43

ACrowley

17th September 2008, 08:18

I only just recently noticed that ffdshow doesn't include any decoders for WMA lossless. Are there any decoders that can do it (I can only dream of libavcodec) that could perhaps be included in ffdshow?

WMAudiodecoder DMO can handle WMA 9 lossless ,but not ffdshow/libavcodec
But you can process any Audio with ffdshowaudio processor "behind" WMAudioDecoder

Inventive Software

17th September 2008, 10:45

I only just recently noticed that ffdshow doesn't include any decoders for WMA lossless. Are there any decoders that can do it (I can only dream of libavcodec) that could perhaps be included in ffdshow?

Funny you should mention that, I posted something on the ffmpeg-devel mailing list asking much the same thing, and the response I got was "if you know or can get the bitstream specifications, we can implement it". MS has the source code licensing for $5000. :)

What do you mean by this?

Every decoder should output the same channel order (this the "wav" channel order), or else we 'll have to change the speaker's configuration each time we listen to a different audio format. We don't care what is the order of the channels inside the tracks. We just need them to be decoded in the same order.

I wasn't aware it worked like that. All I know is that LFE 4th as channel is WAV, 6th properly is Dolby Digital.

clsid

17th September 2008, 12:04

for ffdshow subs to work I have to

Subtitle-Vobsob-enabled correct? I ask because I can't get subs to work other wise and it seem redundant to have.
Subtitle-enabled then have to have also have Subtitle-Vobsob-enabled unless you can turn off vobsub and still get subs working. I need both enabled?

With both enabled because that is only way I can see subs I am unable to change the rendering in 2 areas no matter what I try. the areas being

Subtitle-text
Subtitle-font
There are different kinds of subtitles. Text based and image based (VobSubs). It is a separate option because vobsubs do not always work properly with ffdshow.

The text/font options only apply to text based subtitle formats (like SRT) and not to vobsubs.

pitch.fr

17th September 2008, 12:44

I hope he reconsider as their is a big diffrence in sq.
so what do you say CLSID ?
you can compare Reclock 1.7b4 and 1.809 to witness the huge quality improvement.

maybe using some 7z/RAR packing could fix the size issue ?

I can compress the new Reclock DLL to 400k with winRAR.

Thanks,

Snowknight26

17th September 2008, 18:52

Funny you should mention that, I posted something on the ffmpeg-devel mailing list asking much the same thing, and the response I got was "if you know or can get the bitstream specifications, we can implement it". MS has the source code licensing for $5000. :)

So I guess the foobar2000 devs must have coughed up that much sometime or another. :p

Zep

17th September 2008, 19:17

There are different kinds of subtitles. Text based and image based (VobSubs). It is a separate option because vobsubs do not always work properly with ffdshow.

The text/font options only apply to text based subtitle formats (like SRT) and not to vobsubs.

ok I am beginning to understand lol

Anyway, I see the 2 formats in the avi dir are

.idx
.sub

how do I go about changing font and font collor and font size then? I see in the .idx many things that look tweakable haha but surely there is a better way than to change this stuff?

thanks

clsid

17th September 2008, 19:29

.idx/.sub are VobSubs. You can't change the font.

pitch.fr

17th September 2008, 19:41

@clsid : should I take your silence as a "no" ?

albain

17th September 2008, 22:25

Anima123

18th September 2008, 01:40

AAC decoder still won't work with albain's beta5.

Zep

18th September 2008, 04:10

.idx/.sub are VobSubs. You can't change the font.

wow that sucks. I guess I am stuck installing the old external vobsub since at least I can change the font color and stretch/squish the font with that version.

thanks

rack04

18th September 2008, 04:23

AAC decoder still won't work with albain's beta5.

Works here.

Kurtnoise

18th September 2008, 07:13

.idx/.sub are VobSubs. You can't change the font.
you are wrong here...you can change the font and/or colors from vobsub files as well with SubtitleCreator.

AAC decoder still won't work with albain's beta5.
As I said earlier, the AAC decoder from lavc (libavcodec) supports only LC streams, not HE or PS for the moment.

Anima123

18th September 2008, 09:18

I've tried lc-aac audio wrapped in mp4 container but failed to play. Definitely not working for me. :(

nautilus7

18th September 2008, 10:49

Finally, the channel order seems to be correct for AC3/EAC3/Vorbis/AAC multichannel streams using libavcodec

Here is a test build :
http://rapidshare.com/files/146146686/ffdshow_rev2131_20080915_dbt_beta5.exe.htmlThanks it works with AC3 and E-AC3 which i tested.

The libav decoder still crashes with every DTS track i try.

clsid

18th September 2008, 11:27

you are wrong here...you can change the font and/or colors from vobsub files as well with SubtitleCreator.
Sure, everything is possible with enough effort. But it would require a conversion step to change the font.

_xxl

18th September 2008, 15:51

The libav decoder still crashes with every DTS track i try.
Has this been reported to ffmpeg dev team?

Kurtnoise

18th September 2008, 16:27

Sure, everything is possible with enough effort. But it would require a conversion step to change the font.
what do you mean by a conversion step ? Just load your file, choose a font/color and save. That's all...:)

clsid

18th September 2008, 16:27

I doubt that it is a bug in FFmpeg. Wasn't it a binutils bug? Just disable whatever function is crashing.

Kurtnoise

18th September 2008, 16:28

I've tried lc-aac audio wrapped in mp4 container but failed to play. Definitely not working for me. :(
I'll try to do some tests on my side...

Leak

18th September 2008, 16:43

what do you mean by a conversion step?
DVD subs (aka .idx/.sub) are bitmaps. If you want to change the font, you'll have to OCR all subtitle images, possibly re-position them and save them in some other format or create new subtitle images.

I think you'll agree that this is a wee bit more complicated than "just changing a setting"...

np: Soul 223 - Q (Soul Jazz Records Singles 2006-2007 (Disc 1))

tal.aloni

18th September 2008, 19:11

Hey albain, thanks for your efforts, I'm very happy with your latest build. all mapping problems are gone. :)

I've tested several 5.1 AC3 & E-AC3 tracks, and haven't had a single problem.

a few notes:
1. this may be on purpose, but on the list of Codecs, I only have E-AC3. this may confuse some.

2. I've tried testing some 7.1 E-AC3 tracks from the Dolby Demonstration Blu-Ray, they all play as 5.1. (side surround merges with rear surrounds).
Sonic Cineplayer played them as 5.1 as well.
Power DVD played them as 7.1 just fine in blu-ray mode, and player them as 5.1 in single file mode.
This may have to do with the demuxer and not with the decoder

Thanks for the amazing work!
Tal Aloni

nautilus7

18th September 2008, 19:27

2. If you 're talking about E-AC3, libav doesn't output 7.1 yet. Merging the 2 extra channels into the surround ones, is the normal behavior of any E-AC3 decoder not capable of outputting 7.1.

tal.aloni

18th September 2008, 19:35

albain

18th September 2008, 21:21

Has this been reported to ffmpeg dev team?

Not yet, I have troubles to post on their mailing list. If someone can do this, it would be great.

Concerning AAC, I will try to digg this more but the samples that I tested successfully a few days ago on libavformat branch no more work with my last builds, don't know why

tal.aloni

18th September 2008, 21:31

Albain,
Unfortunately, now (beta 5) flac (which utilize libavcodec) have wrong channel mapping!

jruggle

18th September 2008, 22:29

2. If you 're talking about E-AC3, libav doesn't output 7.1 yet. Merging the 2 extra channels into the surround ones, is the normal behavior of any E-AC3 decoder not capable of outputting 7.1.
A little clarification:
If the 7.1 E-AC3 you have is from Blu-ray, I believe it is usually encoded as a 5.1 pre-downmixed base AC3 stream mixed with a 4-channel supplemental E-AC3 substream which replaces the surround channels and adds the 2 back channels. The lavc decoder skips the supplemental substream, so the result is indeed 5.1 with the extra channels mixed-in, but it's from the original encoder, not from the decoder.

Full 7.1 output will eventually be supported in lavc.

darbid

19th September 2008, 04:07

Hello, I have been using ffdshow with WMP(media centre) for over a year now. One of the most annoying things about windows is how it deals with codecs. Direct Show can be misled, currupted or changed so easily.

So the problem is I have no sound when I play DVDs, just the picture. Ffdshow (audio/video) does not pop up in the system tray either.

Using graphedit I have checked which audio/video filter it uses for a VOB file and it has ffdshow (audio and video). I can even play that file with graphedit and ffdshow audio and video pops up in the system tray confirming it is being used.

With a filter manager i have even checked the merits of ffdshow and it is preferred.

Then if i play the same dam VOB file with WMP as soon as the film starts, no sound, no ffdshow audio is started, i just get picture. It must be using another filter for the picture as well.

Could someone please help.

EDIT: Even Gspot will render the video and audio of a VOB (mpeg) with ffdsow. So I imagine I have done something to WMP or Windows itself.

albain

19th September 2008, 08:06

Albain,
Unfortunately, now (beta 5) flac (which utilize libavcodec) have wrong channel mapping!

My mistake, I forgot some necessary updates

Mercury_22

19th September 2008, 08:42

@albain Can you post a x64 version of beta 5 ? PLEASE ! :thanks: :helpful:

pitch.fr

19th September 2008, 09:57

I doubt that it is a bug in FFmpeg. Wasn't it a binutils bug? Just disable whatever function is crashing.
OK thanks for your help clsid, always appreciated :D

yesgrey3 will update ff_samplerate.dll with the latest libsamplerate version then :sly:

clsid

19th September 2008, 14:58

yesgrey3 will update ff_samplerate.dll with the latest libsamplerate version then :sly:
Not needed. I have uploaded it here (http://tinyurl.com/3dg). :p

pitch.fr

19th September 2008, 15:25

Not needed. I have uploaded it here (http://tinyurl.com/3dg). :p
w00t, thanks!!!!

it's so great to have an awesome tool such as ffdshow maintained by such a knowledgeable and friendly person as you......I envy you actually, you're so awesome :D

rack04

19th September 2008, 15:31

OK thanks for your help clsid, always appreciated :D

yesgrey3 will update ff_samplerate.dll with the latest libsamplerate version then :sly:

Sorry if I'm slow but what bug is this referring too?

clsid

19th September 2008, 15:32

I don't need a mirror. So I don't have a reason to click on your bogus link.

Rule 14: Multiple registrations are prohibited and are grounds for immediate account deletion.
Can a mod please ban pitch.fr (aka leeperry)?

clsid

19th September 2008, 15:33

Sorry if I'm slow but what bug is this referring too?
None. He is just annoyed that I ignored him.

pitch.fr

19th September 2008, 15:34

I don't need a mirror. So I don't have a reason to click on your bogus link.

Can a mod please ban pitch.fr (aka leeperry)?
I'm your biggest fan, besides I'm not leepiryy(who's that :confused: )

I wonder why you don't wanna update libsamplerate ?

pitch.fr

19th September 2008, 15:35

Sorry if I'm slow but what bug is this referring too?
well, there's been a major update of libsamplerate but the man doesn't care :
http://www.mega-nerd.com/SRC/history.html

what's the point to update ffdshow after all :D

thankfully, yesgrey3 will update the DLL :)

PS: problem solved on my end, have a wonderful day :

clsid has now been successfully added to your ignore list.

Kurtnoise

19th September 2008, 16:01

DVD subs (aka .idx/.sub) are bitmaps. If you want to change the font, you'll have to OCR all subtitle images, possibly re-position them and save them in some other format or create new subtitle images.

I think you'll agree that this is a wee bit more complicated than "just changing a setting"...

Sounds like you haven't tested SC yet...no, it doesn't use OCR engine for this part.

to stay on the topic, I can confirm that the AAC lavc decoder doesn't work with AAC streams embedded in mp4 container using the last beta from albain.

yesgrey

19th September 2008, 19:11

OK thanks for your help clsid, always appreciated :D

yesgrey3 will update ff_samplerate.dll with the latest libsamplerate version then :sly:

pitch.fr,
Please put me out of your fights, I will not allow you, or anyone, to use me to provoque anyone else. I have PMd you saying that I will try to update the libsamplerate because I did not agree and did not like clsid's position, but now, publicly, I have to tell you that I did not like that you have come here and have used me to attack clsid. I am not here to fight or to help anyone in a fight. I am here willing to learn, to give some suggestions, and trying to help whenever I can, without expecting to receive anything but respect.
I will still try to update and post here the new code for ffdshow's ff_samplerate.dll; not because of you, but because I feel that everyone who wishes to try and use the new version, besides the increased size, should be allowed to do it. If the developers of ffdshow tryouts decide to accept the updated code and use it it's their decision, because it's their software.

Not needed. I have uploaded it here (http://tinyurl.com/3dg). :p

clsid,
I have learned to respect you during the time I have spend here, but this "words" of yours reduced it considerably.

Sorry for the off-topic, but my name has been introduced without my consent.

pitch.fr

19th September 2008, 19:47

pitch.fr,
Please put me out of your fights

humm ?
you told me yesterday in PM that you were awaiting Mr Big Stuff's answer on whether he was gonna update it.

and because he prefered to ignore OUR(you, richardk and I) request from the previous page, you'd try to do it.

anyway, I wanted to let him know that he can ignore OUR request as much as he wants.....it'd still be done, thanks to your mad coding skills :rolleyes:

thanks for your endless efforts yesgrey, but rejoice.....we got a new Reclock developer, how cool is that :eek: :D

I'm not the one who used the F word here, if you look closely ;)

I'm a reasonable person, not the case of everyone around here....it seems :rolleyes:

albain

20th September 2008, 08:38

Wow, there was some interesting debates...

Getting back to serious things : AAC decoder does not work or crash when compiling FFDShow (not libavcodec) under release mode. In debug mode it works. When it crashes it is raised from libavcodec dll. Weird...

Let's hope that the upcoming major updates of AAC decoder will solve this problem.

I will post an updated version (32 & 64 bits) very soon

STaRGaZeR

20th September 2008, 14:11

My experience with beta5:

1 - E-AC3 decoder works fine :)
2 - Using livabcodec for normal AC3 decoding sometimes makes ugly high pitch sounds that last miliseconds with AC3 in AVI and when playing DVDs with MPC-HC. Matroska is fine so far, but it'll be nice to separate E-AC3 from normal AC3 so we can select libavcodec and liba52 respectively.
3 - AAC decoder does not work, like the others have said.
4 - libavcodec DTS crashes always. libdts is perfectly fine though.

TrueHD would be a nice addition now.

rack04

20th September 2008, 16:15

4 - libavcodec DTS crashes always. libdts is perfectly fine though.

I can't get any codec to work with DTS. Well, correction they work, but the audio is screwed. Sorry don't know of a better way to explain it. Is libav recommended for all stable audio formats?

yesgrey

20th September 2008, 18:06

I have updated here (http://forum.doom9.org/showthread.php?p=1186274#post1186274) ffdshow's libsamplerate to version 0.1.4.

If you want, try it and let us know what you think about it.

foxyshadis

21st September 2008, 22:39

I'm your biggest fan, besides I'm not leepiryy(who's that :confused: )

I wonder why you don't wanna update libsamplerate ?

I think you are. I've been looking through both accounts, and I'm ready to ban you for skirting your 30-day suspension. You're provocative enough in this thread to earn a rule 4 anyway.

yesgrey, clsid, I believe it should be offered as an optional package, along with other things that are rarely used, updated, or outdated: libmad, realaac,& tremor (all need to be removed generally anyway, libavcodec is far superior), plus theora, and xvidcore.

Lux Delux

22nd September 2008, 02:58

Just an observation, as suggested by Lord Mulder ( ;) ) I found this thread, with ffdshow_rev2135_20080921_clsid.exe I got weird blocking in a brighter area

I'm using megui with the latest skystrife build, just now I noticed (in just 1 scene for now) a strange blocking in an area

http://img217.imageshack.us/img217/1049/snapshot20080922004609uq2.jpg (http://imageshack.us)

below is the 1st and 2nd pass settings

Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 1 --bitrate 1137 --stats "D:\WALKER S1\01\udegrain2.stats"
--ref 16 --mixed-refs --no-fast-pskip --bframes 6
--b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2
--partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--me tesa --merange 32 --threads auto --thread-input --sar 59:65 --progress
--no-dct-decimate --no-psnr --no-ssim --output NUL "D:\WALKER S1\01\udegrain2.avs"

Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 1137
--stats "D:\WALKER S1\01\udegrain2.stats"
--ref 16 --mixed-refs --no-fast-pskip --bframes 6
--b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2
--partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--me tesa --merange 32 --threads auto --thread-input --sar 59:65 --progress --no-dct-decimate --no-psnr
--no-ssim --output "D:\WALKER S1\01\udegrain2.mkv" "D:\WALKER S1\01\udegrain2.avs"

with the official beta release everything is fine. BTW keep up the good work :)

Liisachan

22nd September 2008, 06:34

other things that are rarely used, updated, or outdated: libmad, realaac,& tremor (all need to be removed generally anyway, libavcodec is far superior), plus theora, and xvidcore.

Don't remove xvid as vfw decoder please. libavcodec is NOT superior, it has b-frame delay, making frame number messed up when ffdshow is used by software like VirtualDub, av sync problems are possible too.
Also last time I tested Tremor was better than lavc for multichannel Vorbis. Multichannel Vorbis is only rarely used and honestly I'm not interested in this bug, but the point is, don't believe in lavc blindly. It's not like libavcodec is superior in everything. I agree with you about libmad however.

albain

22nd September 2008, 10:44

Here is the updated versions of the branch for AC3/EAC3 decoding :

FFDShow 32 bits
http://rapidshare.com/files/147368880/ffdshow_rev2134_20080922_dbt_beta7.exe.html

FFDShow 64 bits
<On the way>

Nothing new on DTS and AAC decoding

Mercury_22

22nd September 2008, 11:25

clsid

22nd September 2008, 12:48

yesgrey, clsid, I believe it should be offered as an optional package, along with other things that are rarely used, updated, or outdated: libmad, realaac,& tremor (all need to be removed generally anyway, libavcodec is far superior), plus theora, and xvidcore.The only reason I was against updating libsamplerate is because of its radical increase in size. The large size itself isn't the biggest issue. It is the 900% increase that makes me suspect something is wrong. Maybe GCC is able to do a better job. But atm I can't be bothered to try it, maybe someone else here wants to.

Realaac can indeed be removed as I am not aware of any samples that fail with libfaad2 and work with realaac.

I don't like the idea of multiple versions or an addon pack much. Most of the non-essential components aren't very large in size comapred to the core components.

Nothing new on DTS and AAC decodingDoes the DTS decoder always crash in the same function? If so, just disable that function in libavcodec.

fastplayer

22nd September 2008, 13:06

Why remove codecs from ffdshow at all? Is it that difficult to maintain them? I mean it's not like they're updated on a daily basis (unlike ffmpeg code). The Xvid guys maybe release an update once a year...
Having the option to choose from multiple codecs for some of the A/V formats is definitely an advantage. Especially at zero cost...

clsid

22nd September 2008, 13:31

The cost is bandwidth/diskspace. There is only an advantage is one decoder can do things that its alternative can't.

yesgrey

22nd September 2008, 13:56

The only reason I was against updating libsamplerate is because of its radical increase in size. The large size itself isn't the biggest issue. It is the 900% increase that makes me suspect something is wrong.

From inspecting the code, the large size increase is due to the new files high_qual_coeffs.h and mid_qual_coeffs.h; the size went from 486kB and 151kB, respectivelly, to 8973kB and 593kB!!! I think there is nothing to do to decrease the size, these coefficients are all hardcoded in the dll...

I also think there is nothing wrong, it was the way the author find to increase the quality of the best two modes. See the differences below (these numbers are described in the source code)

Old Resampler best three modes:
1: 97dB SNR, 96% BW
2: 97dB SNR, 90% BW
3: 97dB SNR, 80% BW

New Resampler best three modes:
1: 145dB SNR, 96% BW
2: 121dB SNR, 90% BW
3: 97dB SNR, 80% BW

After all this, what is really important is the answer to the question:
Is the new best mode of libsamplerate better than the best mode of libavcodec?
If it's not, it's not worth it to update the code. In fact, if it's not, we should also consider removing libsamplerate, because there is no need to have something that is of lower quality...

I will try to test both carefully and will post here the results. It would be great if more people test the sound quality and post here the results.

madshi

22nd September 2008, 14:00

After all this, what is really important is the answer to the question:
Is the new best mode of libsamplerate better than the best mode of libavcodec?
If it's not, it's not worth it to update the code. In fact, if it's not, we should also consider removing libsamplerate, because there is no need to have something that is of lower quality...

I will try to test both carefully and will post here the results. It would be great if more people test the sound quality and post here the results.
Would it also be possible for you to do a cross comparison to the free r8brain? I've always wondered how good r8brain is compared to libsamplerate...

http://www.voxengo.com/product/r8brain/

albain

22nd September 2008, 14:07

Does the DTS decoder always crash in the same function? If so, just disable that function in libavcodec.

I am unable to detect in which function it crashes as it does crash only in release mode, not in debug mode.
I will try to play with the compilation flags in order to get debugging + crash

clsid

22nd September 2008, 14:24

I suspect one of the float_to_int16_interleave_* functions from dsputil_mmx.c crashes. Try disabling those.

yesgrey

22nd September 2008, 15:00

Would it also be possible for you to do a cross comparison to the free r8brain? I've always wondered how good r8brain is compared to libsamplerate...

http://www.voxengo.com/product/r8brain/

It's funny, A few days back I've suggested pitch.fr to do exactly that, because I thought that if you have decided to use r8brain in eac3to was because you thougt it was the best... now I know we are in the same boat: we don't know. :)

I will compare all three.

madshi

22nd September 2008, 15:09

It's funny, A few days back I've suggested pitch.fr to do exactly that, because I thought that if you have decided to use r8brain in eac3to was because you thougt it was the best... now I know we are in the same boat: we don't know. :)
You're quite right - I don't know!! :o I had read an article at some time comparing the professional (non free) r8brain version to libsamplerate and several other free and commercial resampling applications, and r8brain came out very good. But the free version is not as good as the commercial one. So I never knew for sure.

I will compare all three.
Great - thanks much! Looking forward to your results...

albain

22nd September 2008, 15:59

The DTS decoder crashes in function ff_imdct_half_sse.

It works when disabling it

tal.aloni

22nd September 2008, 17:00

Inventive Software

22nd September 2008, 18:01

Anybody got any samples and a recent build I can test this with? I'm eager to try this out. :)

What's the status on MLP / TrueHD decoding?

ACrowley

23rd September 2008, 07:33

Albain,
In beta7, I'm getting the correct channel mapping for all of the formats! (Flac, AC3, E-AC3)

We finally have 100% Free and 100% Working Direct Show E-AC3 Decoder! That's amazing!

Thanks a lot!
Tal Aloni

yeah...fine

But what about 24bit output ? i get alwys 16bit ? Shouldnt it be 24bit ?
eac3to output with NeroAudioDecoderII and Sonic decoder is 24bit

albain

23rd September 2008, 08:25

yeah...fine

But what about 24bit output ? i get alwys 16bit ? Shouldnt it be 24bit ?
eac3to output with NeroAudioDecoderII and Sonic decoder is 24bit

Is it a problem with the decoder or with FFDShow : I mean should the output format be configured into the decoder itself or else when the output format selected in FFDShow is 24 bit, it would not be taken into account by the decoder ?

Concerning 64 bit build, I have troubles to compile it since I switched to the branch (problem with yasm on imgfilters/skl..., I will spare more details). As soon as it compiles I will post updated versions with the working DTS decoder too

Mercury_22

23rd September 2008, 08:52

Is it a problem with the decoder or with FFDShow : I mean should the output format be configured into the decoder itself or else when the output format selected in FFDShow is 24 bit, it would not be taken into account by the decoder ?

Concerning 64 bit build, I have troubles to compile it since I switched to the branch (problem with yasm on imgfilters/skl..., I will spare more details). As soon as it compiles I will post updated versions with the working DTS decoder too

Why not switching back ? I think it's time / good (enough) to go back to main ! :thanks::helpful:

P.S. We can keep liba too (just in case) but why not making it official ?:confused:

shambles

23rd September 2008, 09:09

Is it a problem with the decoder or with FFDShow : I mean should the output format be configured into the decoder itself or else when the output format selected in FFDShow is 24 bit, it would not be taken into account by the decoder ?

i think it's a problem with the decoder itself.. selecting 24bit output in ffdshow and dumping output creates 24bit files but with the last 8 bytes padded.

madshi has hacked the libavcodec (e-)ac3 decoder for eac3to (http://forum.doom9.org/showthread.php?p=1094167#post1094167) so it outputs floating point and that is then dithered down to 24bit

albain

23rd September 2008, 09:48

This is not my call, and there is still work to do concerning TrueHD decoding, I didn't have the time to work on it yet

albain

23rd September 2008, 10:37

Mercury_22

23rd September 2008, 10:59

Here are the updated versions with EAC3/DTS decoding :

32 bits :
http://rapidshare.com/files/147650229/ffdshow_rev2138_20080923_dbt_beta8.exe.html

64 bits :
http://rapidshare.com/files/147650547/ffdshow_rev2138_20080923_x64_beta8.exe.html

64 bits it's crashing with Libav for E-AC3 / AC3 / DTS tested with WMP 64-bit and MPC-HC 64-bit
Samples: E-AC3 (http://rapidshare.com/files/143609863/Test_E-AC3.ts.html), AC3 (http://rapidshare.com/files/143875772/Test_LibavAC3.avi.html), DTS (http://rapidshare.com/files/147667691/Test_DTS.ts.html)
Problem signature:
Problem Event Name: APPCRASH
Application Name: wmplayer.exe
Application Version: 11.0.6001.7000
Application Timestamp: 47919dbe
Fault Module Name: libavcodec.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 48d8b260
Exception Code: c0000005
Exception Offset: 000000000034bec8
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 38fa
Additional Information 2: ac7e3f1ebb373830e789317be6c118ae
Additional Information 3: f834
Additional Information 4: 455055a6a1260056002639897fbd0fa0
:helpful:

clsid

23rd September 2008, 13:14

Why not switching back ? I think it's time / good (enough) to go back to main !#$%@^$^%$@$@$% *deep breath* *deep breath* !$#%@@!@

Several problems have been reported that have not yet been fixed afaik. AAC is still completely broken. Does 2 channel AC3 work yet? What about the AC3 decoding quality issues that were reported?

Are AC3 and E-AC3 configurable separately yet? NO.
Have things been properly tested yet? NO.

fastplayer

23rd September 2008, 13:26

clsid, please watch your blood pressure! :thanks:
:D

Mercury_22

23rd September 2008, 13:43

#$%@^$^%$@$@$% *deep breath* *deep breath* !$#%@@!@

Several problems have been reported that have not yet been fixed afaik. AAC is still completely broken. Does 2 channel AC3 work yet? What about the AC3 decoding quality issues that were reported?

Are AC3 and E-AC3 configurable separately yet? NO.
Have things been properly tested yet? NO.

Ok !
But how using libav as second option for all this decoders can hurt ? Cause keeping this as a separate branch can lead to more other problems.:mad: See ...Concerning 64 bit build, I have troubles to compile it since I switched to the branch ... :confused:
I thought having multiple branches it's similar to what you've said before ...
I don't like the idea of multiple versions or an addon pack much. So...:confused:

_xxl

23rd September 2008, 14:27

Ok !
But how using libav as second option for all this decoders can hurt ? Cause keeping this as a separate branch can lead to more other problems.
Until most important bugs are fixed this is the only option.

Inventive Software

23rd September 2008, 14:33

Am I right in thinking libavcodec has an MP3 decoder? If so, is this in the ffdshow-tryout trunk yet?

clsid

23rd September 2008, 15:35

Ok !
But how using libav as second option for all this decoders can hurt ?I don't want half broken functionality in the trunk. Period.
Cause keeping this as a separate branch can lead to more other problems.:mad: See :confused:Not a valid argument for dumping unstable/incomplete stuff in the trunk. Albain can and will fix this minor problem eventually.
I thought having multiple branches it's similar to what you've said before So...:confused:No, it is quite different.

STaRGaZeR

23rd September 2008, 17:00

Does 2 channel AC3 work yet? What about the AC3 decoding quality issues that were reported?

Yes, AC3 2.0 is working in beta8 and also in previous betas. Now that you mention it, the high pitch sounds I was refering in my last post only seems to affect 2ch AC3 so far, no problems with 5.1 but I need more testing as they're very random. But once I find them they sound at the same time always. Want a sample?

EDIT: When playing a R1 DVD with AC3 2.0 audio in MPC-HC and doing a medium jump forward or backward the same pitch also occurs.
With libav seeking is slow compared to liba52, but only when playing DVDs, normal files are fine.
The volume is higher using libav. Is it applying dialog normalization by default?
Inside Info and CPU, in input description bitrate is not show with libav. Also when playing DTS files it says '6 channels dca (libavcodec)', it should be dts.

clsid

23rd September 2008, 19:05

Actually, the DTS decoder in libavcodec is really called dca. This confusion could be avoided by displaying the long_name value of the decoders in libavcodec instead of the decoder name. (who is going to patch that?)

There still seems to be a problem with channel mapping. I am using headphones here, so I have Mixer set to 2.0. When playing 5.1 AC3, the Center/BackL/BackR channels are wrongly mixed. Center gets mixed to Right. BackL to Left+Right. BackR to Left.

DTS is wrong as well.

Weird thing is that the volume levels on the Volume page are displayed correctly.

Here is a good file to test with:
download (http://www.zshare.net/download/1928530218d16665/)

tal.aloni

23rd September 2008, 20:55

There still seems to be a problem with channel mapping. I am using headphones here, so I have Mixer set to 2.0.

I have a different experience.
with the mixer set to 2.0, and headphones connected directly to the computer,
5.1 Flac, 5.1 AC3, 7.1 E-AC3 still gets mapped correctly.

Tal Aloni

Edit:
tested your file as well, still perfect playback.

STaRGaZeR

23rd September 2008, 21:12

I don't have any problems with your sample in my 5.1 system. In 5.1 mode, like it should be in all formats. When using Mixer set to 2/0/0 - stereo too: BackL to Left, BackR to Right, Center to Left+Right, Left to Left and Right to Right. All formats are fine except MP3 of course and AAC, both LC and HE hang. AAC no problems with libfaad.

clsid

23rd September 2008, 21:59

Thanks guys. I found the problem. Mapping is ok now after rebuilding libmplayer.dll

jruggle

24th September 2008, 00:02

Yes, AC3 2.0 is working in beta8 and also in previous betas. Now that you mention it, the high pitch sounds I was refering in my last post only seems to affect 2ch AC3 so far, no problems with 5.1 but I need more testing as they're very random. But once I find them they sound at the same time always. Want a sample?
Try updating to the latest FFmpeg SVN. There was a bug in the AC3 parser, which usually manifested with smaller frame sizes or in containers such as avi or mpg. From what I've found so far, a recent commit (r15381) has fixed these issues.

The volume is higher using libav. Is it applying dialog normalization by default?Dialog normalization is not applied at all. The amount of DRC applied is controlled by AVCodecContext.drc_scale.

STaRGaZeR

24th September 2008, 01:03

Try updating to the latest FFmpeg SVN. There was a bug in the AC3 parser, which usually manifested with smaller frame sizes or in containers such as avi or mpg. From what I've found so far, a recent commit (r15381) has fixed these issues.

Nice, can anyone compile the lastest version then for testing?

Dialog normalization is not applied at all. The amount of DRC applied is controlled by AVCodecContext.drc_scale.

So how can we completely disable DRC? The checkbox is greyed out when libav is selected, but with liba52 it can be used.

jruggle

24th September 2008, 03:38

So how can we completely disable DRC? The checkbox is greyed out when libav is selected, but with liba52 it can be used.
I don't know the internals of ffdshow. As for using lavc, AVCodecContext.drc_scale can be set from 0.0 to 1.0 to apply a percentage of DRC.

albain

24th September 2008, 07:58

Nice, can anyone compile the lastest version then for testing?

So how can we completely disable DRC? The checkbox is greyed out when libav is selected, but with liba52 it can be used.

Good news, I am on it. Concerning DRC, I will try to implement it too on libavcodec

_xxl

24th September 2008, 08:00

Spdif for AC3 and DCA can be moved to libavcodec so liba52 and libdts could be removed?

albain

24th September 2008, 09:11

Try updating to the latest FFmpeg SVN. There was a bug in the AC3 parser, which usually manifested with smaller frame sizes or in containers such as avi or mpg. From what I've found so far, a recent commit (r15381) has fixed these issues.

Dialog normalization is not applied at all. The amount of DRC applied is controlled by AVCodecContext.drc_scale.

Unfortunately that did not make it. Please test on your side with the following sample :
http://rapidshare.com/files/147929764/cine.premier.hd.astra.19e.05.feb.2008.zip.html

If you disable the AC3 parser, the file plays fine.
The parser seems to clean up too many bytes from the input buffer

About selecting a different decoder for AC3 & EAC3, the solution will be quite complex but doable : the input codec ID may be AC3 even if the format is EAC3, so for each AC3 stream detected, enable the libavcodec AC3/EAC3 parser on the first frame, and if it detects EAC3, then switch to the other decoder if different selected

Last thing, I have added DRC setting to libavcodec for AC3/DTS formats. However this is a switch, so it will be 0 or 1.0.
One thing missing in FFDShow is the ability to define custom settings for the decoders. Currently the 2 checkboxes are not enough. Just a thought...

STaRGaZeR

24th September 2008, 11:02

Unfortunately that did not make it. Please test on your side with the following sample :
http://rapidshare.com/files/147929764/cine.premier.hd.astra.19e.05.feb.2008.zip.html

If you disable the AC3 parser, the file plays fine.
The parser seems to clean up too many bytes from the input buffer

It's playing perfectly fine here with libav. If you're using MPC, disable the internal splitter as it does not properly iniciate the audio. The working graph is Haali Media Splitter - ffdshow (beta8).

Last thing, I have added DRC setting to libavcodec for AC3/DTS formats. However this is a switch, so it will be 0 or 1.0.
One thing missing in FFDShow is the ability to define custom settings for the decoders. Currently the 2 checkboxes are not enough. Just a thought...

Nice, I'll use lbav for DTS for now on and see if there are any problems. What's the range of DTS formats libav can decode (Master Audio, 96/24, etc.)?

albain

24th September 2008, 11:05

It's playing perfectly fine here with libav. If you're using MPC, disable the internal splitter as it does not properly iniciate the audio. The working graph is Haali Media Splitter - ffdshow (beta8).
I agree but the same file works with mpc and liba52, so shouldn't libavcodec handle wrong input better ?

STaRGaZeR

24th September 2008, 11:36

I agree but the same file works with mpc and liba52, so shouldn't libavcodec handle wrong input better ?

Indeed. it's interesting that if you use the internal splitter, the audio won't play. But if you random seek the audio will start in that point like it should be. Maybe the problem is in the beginning of the sample.

Also can you please compile a test version with the lastest ffmpeg to see if it solves the high pitch sound I'm experiencing?

nautilus7

24th September 2008, 22:31

jruggle

25th September 2008, 00:19

If you disable the AC3 parser, the file plays fine.
The parser seems to clean up too many bytes from the input buffer
The lavc AC3 parser should not be "cleaning up" any bytes from the input buffer. The current behavior is to pass every byte to the decoder. This is why you will always get a decoder error if your stream doesn't start and end on a frame boundary. So, if extra non-AC3 bytes are sent to the parser, it WILL send them to the decoder. The job of the parser is to split-up the stream, not to sanitize it. The decoder requires data which starts at a frame boundary. Anything else will cause an error.

Snowknight26

25th September 2008, 19:52

the_provider

25th September 2008, 22:11

Greetings.

I have a Leadtek TV-card that came with WinFast PVR2 software that promised it can deliver MPEG4 encoded .avi's using third party codecs.
Well, that maybe true but I am still struggling to find out how...and one of the attempts was made with ffdshow video encoder. So I found out that there are some problems that I will like to share:
1. from ffdshow I only chose 3 filters: resize to 320 x 240, deinterlace with bicubic and iDCT. When trying to use it in conjunction with Fraunhofer's MP3 Pro ver. 3.4.0.0 I noticed that encoding freezes randomly after less than 1 minute, sometimes after 15 seconds sometime after 55.
I have though reasons to belive that MP3 is guilty for that so I change MP3 with Qdesign MPEG audio codec that delivers MP2 audio.
Well, now it doesn't stops anymore but the resulted video has some broken frames regardless of the codec used: libavcodec MPEG4 or XviD. I concluded that because I fed Avidemux with the resulted video and from "Tools" menu I used "Rebuild frames (I&B)" and I saved the result. And now I can use the .avi directly in my PMP (MP4 player) - it requires 320 x 240 XviD SP encoded .avi with MP2/MP3 audio - whereas the original .avi was not playable.
Another funny thing is that after rebuild the size of the video drops with 10-35% but still keeps the same number of frames, fps and qf.
FPS, yes I must add something about them too, the resulted fps in the initial video is not 25 but , according to GSpot 25,002...and the capture was made from YUY2 input, and PAL-B TV standard.
I got the same results with ffdshow-rev1890_20080306 and ffdshow-rev2099_20080903_sse.

If somebody cares to analyze this I can provide video samples and screen captures from the rest of the settings.
BTW, I tried to make an account at ffdshow tryouts Forum to report the above in Bugs section but for some reasons I can't log in...

I am looking forward to hearing opinions and advices.
Thank you in advance.

Anima123

26th September 2008, 01:44

Can we expect any changes to the FIR filter and Resample panels in the audio config? Seems silly to have something like "I'm very new to this and all this dialog and functionality may be wrong," or "Press Apply or OK to change resampling frequency" respectively.

There's a lowpass implementation of Butterworth filter which is now part of ffmpeg. Can somebody incorporate this IIR filter as one option of lowpass filter of audio in the GUI of ffdshow-tryout?

tal.aloni

26th September 2008, 19:58

It would be really neat if we could have a checkbox in the "Deinterlace" Section that said "Only Deinterlace When Internal decoder mark Source as Interlaced"
So only interlaced Mpeg2 / AVC stream would be deinterlaced.

of course I can set interlace flag in output media type,
but than I have very little control over the process, for me, selecting 'Bob' result in 100% cpu usage for 1080i video. (Phenom 8450 + Geforce 8200)

this is the only reason I use CoreAVC for AVC playback.

Thanks,
Tal Aloni

albain

27th September 2008, 11:20

The lavc AC3 parser should not be "cleaning up" any bytes from the input buffer. The current behavior is to pass every byte to the decoder. This is why you will always get a decoder error if your stream doesn't start and end on a frame boundary. So, if extra non-AC3 bytes are sent to the parser, it WILL send them to the decoder. The job of the parser is to split-up the stream, not to sanitize it. The decoder requires data which starts at a frame boundary. Anything else will cause an error.

OK but how do you explain that when using the parser the sample (that I posted in a message above) does not work at all, and disabling the parser make it work.

The problem seems to come from the input splitter giving wrong information but liba52 handles it well unlike the AC3 parser.

Could you have a look on it ?

Thanks

PS : I have added the MP1,MP2 audio libavcodec decoder. I will post an updated version soon. I also reproduced the crash on my 64 bits config.

Does the 64 bits version of gcc uses a different version of binutils than 32 bits ? I say this because while debugging it crashed in the same location where it used to with binutils 2.18.5

clsid

27th September 2008, 11:34

MinGW64 uses GCC 4.4.0 SVN trunk and binutils SVN trunk afaik.

jruggle

27th September 2008, 14:31

OK but how do you explain that when using the parser the sample (that I posted in a message above) does not work at all, and disabling the parser make it work.

The problem seems to come from the input splitter giving wrong information but liba52 handles it well unlike the AC3 parser.

I'm sorry, but I cannot reproduce the results because I don't have ffdshow. The sample you gave works fine with ffmpeg and ffplay.

liba52 itself requires the same thing that the lavc AC3 decoder does, that is, input data aligned at frame boundaries. Since you say both work without the AC3 parser, something in ffdshow must be already splitting the frames up properly. That still doesn't explain why the AC3 parser isn't working for you. It could be a bug in the parser itself or in how ffdshow uses the parser.

When I get some time I'll take a look at the ffdshow source to see if I can tell what's going on.

albain

27th September 2008, 15:30

I'm sorry, but I cannot reproduce the results because I don't have ffdshow. The sample you gave works fine with ffmpeg and ffplay.

liba52 itself requires the same thing that the lavc AC3 decoder does, that is, input data aligned at frame boundaries. Since you say both work without the AC3 parser, something in ffdshow must be already splitting the frames up properly. That still doesn't explain why the AC3 parser isn't working for you. It could be a bug in the parser itself or in how ffdshow uses the parser.

When I get some time I'll take a look at the ffdshow source to see if I can tell what's going on.

Yes but as said stargazer in the following post (http://forum.doom9.org/showthread.php?p=1187698#post1187698), the problem seems to come from the AVI splitter : when muxing the stream from the avi file to an matroska file, the audio plays fine with FFDShow + libavcodec AC3 parser & decoder.
So incorrect frames would be sent to the parser which would parse them incorrectly.

So this is normal that you won't reproduce the problem with full ffmpeg code

ACrowley

27th September 2008, 15:47

@albain , one question:

Is DRC "enabled" in libavcodec for eac3/ac3 in latest beta build ? And what about DialogNormalization ?

albain

27th September 2008, 16:34

@albain , one question:

Is DRC "enabled" in libavcodec for eac3/ac3 in latest beta build ? And what about DialogNormalization ?

Not in this build, in the code for now

I haven't done anything about dialog normalization

STaRGaZeR

27th September 2008, 17:28

@albain , one question:

Is DRC "enabled" in libavcodec for eac3/ac3 in latest beta build ? And what about DialogNormalization ?

From jruggle:

Dialog normalization is not applied at all. The amount of DRC applied is controlled by AVCodecContext.drc_scale.

So the only concern should be DRC, and a simple on/off button is fine IMO.

avivahl

28th September 2008, 11:31

I think I found a bug w/ the subtitles parser.
I inserted srt subtitles into a mkv file... the subtitles have Windows-1255 encoding (Hebrew).
When showing up, I've noticed the last letter of every line does not show!
I think the source of the issue is at src\subtitles\Tstream.cpp:
char* TstreamMem::fgets0(char *buf, int len) const
{
int c=0;
char *cs=buf;
bool wasr=false;
while ((--len > 0) && (c=getc())!=EOF)
{
if (c=='\r')
{
if (crln)
{
*cs++=(char)c;
}
wasr=true;
continue;
}
if (c=='\n')
{
if (utod && !wasr)
{
*cs++='\r';
}
if (crln)
{
*cs++=(char)c;
}
break;
}
*cs++=(char)c;
}
if (c==EOF && cs==buf)
{
return NULL;
}
*cs='\0';
return buf;
}
--len? Is that true? makes no sense to me. len-- would probably work. Can anybody comment?

Btw, I think the subtitles code is ugly like hell. Wow. I formatted the above code, but the rest of the stuff has:
1. Ugly formatting.
2. Messed up coding.
3. No documentation.
4. Bad naming of variables (not descriptive).

Sorry for my English (it's a second language for me),
Avi Vahl

tal.aloni

28th September 2008, 12:04

Avi,
not a solution, but I suggest you try to Convert the file to UTF-8 before muxing. this may be an effective work-around.

also, DirectVobSub can handle subtitles as well as ffdshow.

avivahl

28th September 2008, 12:36

Avi,
not a solution, but I suggest you try to Convert the file to UTF-8 before muxing. this may be an effective work-around.

also, DirectVobSub can handle subtitles as well as ffdshow.
I already know that using UTF-8 works. That's the workaround I found when I wrote about it in Israeli forums. Read here (http://www.qsubs.co.il/index.php?s=&showtopic=15829&view=findpost&p=155736) (in Hebrew).
The UTF-8 code is fine... It's the ANSI (/code-page-specific) code which has this bug.

I like using ffdshow for doing all the decoding... video, audio, and subtitles. So using DirectVobSub is not a great option for me.

albain

28th September 2008, 16:24

Albain, DTS-HD tracks wont play at all with libav. Simple DTS play fine, but with DTS-HD all data are dropped instead of just the HD extensions. sample (http://www.sendspace.com/file/v70bii) (contains various formats).

I tested the DTS-HD track from your sample with mplayer, and it also does not work correctly : a 2 channels stream is detected, not 7.1 and the 15% of the file is played correctly then the decoder crashes with a
Input frame size larger then DCA_MAX_FRAME_SIZE!
[dca @ 0961CEC0]Not a valid DCA frame

I still don't understand the interest of libavformat : is it necessary to add it in the loop for a decoder or is it needed only for the splitter ?

EDIT : same thing here, disabling the DCA (DTS) parser makes DTS-HD track work. I think I need a little hand of the implementation of the parser inside FFDShow code which must not be correct : I have 2 buffers, one for the parser, and one for the decoder.
1/ The parser is fed with the input data from the parser and outputs in the first buffer with the written length (dstLength2)
2/ The decoder is fed with the output data from the parser (first buffer) and outputs in the second buffer with the written length (dstLength)
3/ The second buffer with length (dstLength) is fed to the renderer

Here is the part of the code that I wrote :

ret=libavcodec->av_parser_parse(parser, avctx, (uint8_t**)&dst2, &dstLength2,
(const uint8_t*)src, size, AV_NOPTS_VALUE, AV_NOPTS_VALUE);
if (dstLength2 > 0)
{
libavcodec->avcodec_decode_audio(avctx,dst,&dstLength,(const uint8_t*)dst2,dstLength2);
}
else dstLength = 0;

SCRATCHY

28th September 2008, 17:30

hallo

you don't make icl10 versions anymore ?
I like them more than normal ones, a little faster :)

and when I use avisynth scripts, sometimes ffdshow stays in memory when I close MPC and I have to kill it with the task manager.

if I dont use the avisynth script in ffdshow, it never happen...

I use avisynth 2.5.7 with the MT dll on Windows XP SP3

can I give you logs, or do you know how to fix the problem please ?

I also have a problem with mpc hc and evr on vista64, I have posted in the other thread

sorry for bad english, thank you very much

albain

28th September 2008, 17:56

I think that I fixed the problem for AC3/DTS decoding : all the samples that failed are working now.

Here is the link to the updated version (32 bits):
http://rapidshare.com/files/149144673/ffdshow_rev2158_20080928_dbt_beta9.exe.html

I need some feedback on the followings while using libavcodec:
- AC3 and EAC3 decoding on 2.0 , 5.1 and 7.1 channels
- DTS decoding
- DTS HD decoding (I remuxed the DTS HD track from the audio.test DTSHD.mka sample into a single track mka file and it is working, else it does not. To be confirmed)
- DRC (dynamic range compression) checked/unchecked in the codec section : check that DRC is working for libavcodec AC3/DTS decoders

Also :
- MP3 libavcodec has been added
- MP1,MP2 libavcodec has been added

Known issues :
- AAC decoder is still broken, this is not my priority for now
- Dolby TrueHD not implemented (still need to be studied)
- Not sure about DTS HD decoding
- 64 bit version crashes, maybe due to binutils of gcc64. I think the problem comes from my cross compiler gcc 4.4 (whereas gcc 32 bits is 4.2.3) and some binutils coming with. So if someone can compile and test the libavformat branch on his side under 64 bits... or sending a link for a working x86_64-pc-mingw32...
- libavcodec does not output 96Khz. Current limitation of ffmpeg
- libavcodec does not output more than 5.1 channels. Current limitation of ffmpeg

avivahl

28th September 2008, 18:34

Nice. What about the subtitles bug I wrote about? Any chance you can check this issue? (I already wrote the problematic line)

albain

28th September 2008, 19:57

Nice. What about the subtitles bug I wrote about? Any chance you can check this issue? (I already wrote the problematic line)

Well, sorry but I don't have the time to work on this for now : some tests are necessary by the way. I will have a look on it though.

How do you explain that no one has met this problem yet ?
As far that I can see this only concerns embedded subtitles but how the file encoding could affect this ?

nautilus7

28th September 2008, 20:33

avivahl

28th September 2008, 20:34

How do you explain that no one has met this problem yet?Other people reported the problem on Israeli forums.

As far that I can see this only concerns embedded subtitlesTrue. External file subtitles use the TstreamFile class which has a different fgets0() function (obviously; it calls stdio's ::fgets).

but how the file encoding could affect this ?That's simple... When the file is UTF-8, the fgets0() is not being called. ugets() is being called instead. Look at Tstream::fgets()...

Avi Vahl.

K1ngp1ng

28th September 2008, 20:55

i noticed that dtswav files don't work with libav.

STaRGaZeR

28th September 2008, 20:55

I need some feedback on the followings while using libavcodec:
1 - AC3 and EAC3 decoding on 2.0 , 5.1 and 7.1 channels
2 - DTS decoding
3 - DTS HD decoding (I remuxed the DTS HD track from the audio.test DTSHD.mka sample into a single track mka file and it is working, else it does not. To be confirmed)
4 - DRC (dynamic range compression) checked/unchecked in the codec section : check that DRC is working for libavcodec AC3/DTS decoders

Also :
5 - MP3 libavcodec has been added
6 - MP1,MP2 libavcodec has been added

1 - AC3 perfect in 2.0 and 5.1, don't know about 7.1 . While the high pitch sounds have dissapeared from avi files, seeking a DVD in MPC-HC will still produce them before the video resumes (AC3 2.0 at least).
2 - DTS decoding fine, but failed in this old sample. It also has a LPCM track that doesn't sound right (warning, 100MB): http://rapidshare.com/files/113953595/Bhack_Hawk_Down_LPCM_problem_Sample.ts.html
3 - Same, but when remuxing in mkvmerge says the file is damaged so I think this should not be considered as a valid sample.
4 - AC3 confirmed, can't confirm DTS.
5 - MP3 decoding works fine, but ffdshow recognizes the streams as "stereo mp2", not MP3.
6 - MP2 working fine, well recognized as "stereo mp2". From DVB.

nautilus7

28th September 2008, 20:55

Here (http://www.sendspace.com/file/xoialq) are the DTS-HD samples.

Testoteron and Sexy Beast are DTS-HD Hi Res (5.1ch @ 2082kbps both) and others are Master Audio.

madshi

28th September 2008, 21:19

I still don't understand the interest of libavformat : is it necessary to add it in the loop for a decoder or is it needed only for the splitter ?
You don't need libavformat in order to make the libav decoders work, as long as you feed the decoders correctly. The decoders expect to be fed exactly one clean audio frame at a time.

So let's say you throw away libavformat and don't use it at all. No problem, you can do that. But if you do that, you need to parse the raw audio data yourself, split it nicely into single audio bitstream frames and feed them properly to the libav decoders one frame at a time. No big problem, but if you go this way you'll have to write a little bitstream parser for any audio format you want to support. Using libavformat should mean that you only need to do the work to implement libavformat once, then you should be done for all audio codecs. That's why it was suggested to use libavformat. But as I said, you can do the splitting work yourself instead of using libavformat. If you want to do the splitting work yourself, I can help you with that cause I've written my own splitters for my eac3to tool, anyway.

For DTS-HD you need to remove the DTS-HD blocks before feeding the data to libavcodec/libavformat because even libavformat can't really handle DTS-HD yet. Check out my earlier comments. I've already posted detailed information in this thread about how to properly recognize and remove DTS-HD data blocks.

tal.aloni

28th September 2008, 22:55

Albain,
1. AC3 decoder does no longer crash (I have some videos that lost sound at specific points with beta 8. with beta 9, the sound just repeat itself for a slight moment,
but continues to play just fine throughout the entire video.
please note that the stream does not contain any error, and liba52 / AC3Filter plays it just fine.

2. E-AC3 seems to work great (as with beta-8).

3. DTS-HD MA: when using matroska splitter, the DTS-Core plays just fine. (input bitrate is reported to be 1536kbps so I assume it's the core), when trying to play the DTS-HD directly, or from mka, I get six seconds of silence, and then the playback stops. (this is a scene from the "DTS-HD Master Audio Presentation Disc", but it's possible that the stream does not have a proper start)

4. haven't tested it yet, but Thanks for the DRC support.

5. with 2 DTS files, If I try to seek when playing them using libavcodec, My player gets stopped (mplayerc / TCMP), this does not happen with libdts / AC3Filter. (could be two problematic files, but every other decoder deals with them)

I can post some samples if needed,
Thanks a lot,
Tal Aloni

skystrife

28th September 2008, 23:43

Just an observation, as suggested by Lord Mulder ( ;) ) I found this thread, with ffdshow_rev2135_20080921_clsid.exe I got weird blocking in a brighter area

with the official beta release everything is fine. BTW keep up the good work :)

I'm noticing this bug as well in the svn builds. Like you said, the official beta is fine.

UPDATE:

System: MS Vista x64
Player: mplayerc (32-bit)

If I disable multithreading in the ffdshow video decoder dialogue the blocking issue vanishes. Interesting. I can't test with the ffplay builds in the thread's beginning as they crash instantly for me. *shrug*

Anima123

29th September 2008, 03:24

I've tested the mpeg-1 audio decoder of libavcodec and found a bug, i.e., the mp3 stream showed as mp2 @ info&cpu.

SCRATCHY

29th September 2008, 09:23

sorry for bouncing, but not one knows what I can do to avoid freezing when closing MPC ? thank you

hallo

when I use avisynth scripts, sometimes ffdshow stays in memory when I close MPC and I have to kill it with the task manager.

if I dont use the avisynth script in ffdshow, it never happen...

I use avisynth 2.5.7 with the MT dll on Windows XP SP3

can I give you logs, or do you know how to fix the problem please ?

sorry for bad english, thank you very much

ACrowley

29th September 2008, 10:39

All my AC3 and E-AC3 tracks play fine. DRC works also.

DTS also works good, but DRC isn't working. It seems it's always off.

DTS-HD is still in trouble. DTS-HD Master Audio doesn't play at all, while DTS-HD High Resolution playback ok, but if i seek through the track then it stops playing. I am sending some samples right now.

All tests with DTS/DTS-HD were done with demuxed audio tracks and muxed into mkv. Same result.

Im not sure if there is DRC for DTS ?

The off. DTS Pro Series Surround Encoder from dts has no DRC option, only DialogNormalization.
I never had a dts Track with DRC so far i can remember

Question :
-Is it possible to add support for DTS ES 6.1 discrete/matrix ?

Ah, AC3/EAc3 works perfect with latest Build. dts too. But dts hd output is corrupted

nautilus7

29th September 2008, 12:14

DRC is decoder related. It's not a value stored in the track like DN.

DTS-ES 6.1 is not possible with libavcodec, so ffdshow developers can't do anything about this.

ACrowley

29th September 2008, 16:17

DRC is decoder related. It's not a value stored in the track like DN.

DTS-ES 6.1 is not possible with libavcodec, so ffdshow developers can't do anything about this.

Dolby Digital has the Dynamic Range Compression Profile encoded into the track, ofcourse.
And a Decoder can enable it.

Thats what i mean..and the dts encoder has no DRC Profile Option

Theres no DRC Info stored in the Track for dts...thats what youre talking about ,right ?

avivahl

30th September 2008, 12:31

Any word on that embedded subtitles issue? I practically found the problematic line for you, I think. :)

Eragon4ever

30th September 2008, 12:39

Revision 2160 - Directory Listing
Modified Tue Sep 30 09:12:32 2008 UTC (2 hours, 24 minutes ago) by albain

Embedded subtitle file : fixed missing character at the end of line with non UTF8 encoding (thanks to avivahl)

Judging from that it's fixed.

avivahl

30th September 2008, 12:58

YAY! :D Thanks! :)

STaRGaZeR

30th September 2008, 14:31

I've found a problem when decoding Blu-ray 1080i files with 4ref frames, the video starts to stutter at some point in time (it may happen in 1 or 20 seg). No deinterlacing, just play the file. MPC's internal software decoder does exactly the same so I assume this is a ffmpeg bug?

Sample: http://www.megaupload.com/?d=TZ5WRSKX (73MB)

clsid

30th September 2008, 16:08

I have added a new build of FFplay to the opening post.

albain

30th September 2008, 18:29

For DTS-HD you need to remove the DTS-HD blocks before feeding the data to libavcodec/libavformat because even libavformat can't really handle DTS-HD yet. Check out my earlier comments. I've already posted detailed information in this thread about how to properly recognize and remove DTS-HD data blocks.

I will see with time if the integration of libavformat is necessary.

I am working on the integration of your algorithm to detect and strip off DTS-HD blocks from DTS streams.
It should work soon...

Atak_Snajpera

2nd October 2008, 00:48

I have a question. Will we see Yadif deinterlacer as another option under Deinterlacing section?

albain

2nd October 2008, 11:13

Hi,

I have built a new version following Madshi guidelines (thank you)

Here is the link:
http://rapidshare.com/files/150209996/ffdshow_rev2169_20081002_dbt_beta10.exe.html

New features :

Better DTS decoding
DTS-HD decoding (DTS-HD blocks are stripped off, not decoded as libavcodec does not support it yet but now the DTS-HD streams play correctly)

Next step : working on better AC3 and Dolby TrueHD decoding...

madshi

2nd October 2008, 11:19

I have built a new version following Madshi guidelines (thank you)
And thanks go back to you for improving ffdshow! :)

nautilus7

2nd October 2008, 11:58

All DTS(-HD) files I have play fine now. Thanks both!

Mercury_22

2nd October 2008, 12:15

tetsuo55

2nd October 2008, 12:27

How does the updated ac3/dts decoding compare to AC3filter?

Is it faster/slower?
Does it support more types of ac3/dts?

Basically, has it reached the point where i can ditch AC3filter and finally use only FFdshow for everything? :D

K1ngp1ng

2nd October 2008, 13:00

dts-hd decoding:

- runtime is wrong

- dtswav not working. sample: http://rapidshare.com/files/150231773/17_-_Harmony.7z.html

madshi

2nd October 2008, 15:10

dts-hd decoding:

- runtime is wrong
With raw DTS-HD files? It's (nearly) impossible to show a correct runtime because DTS-HD Master Audio is variable bitrate. Also the runtime is defined by the source filter and not by ffdshow.

STaRGaZeR

2nd October 2008, 15:13

With the lastest beta:

- DTS in WAV not working.
- This DTS sample doesn't work right: http://forum.doom9.org/showpost.php?p=1189485&postcount=4344
- And the usual high pitch sound playing DVDs. Playing the individual VOBs livab works flawlessly though.

avivahl

2nd October 2008, 15:53

I'm afraid to report that the patch for the "last letter missing in embedded non-UTF-8 subtitles" did not help. It's still missing. :( I used ffdshow-tryouts rev2168 from xvidvideo.ru...

EDIT: Alright... I looked more into this issue. It might not be a ffdshow bug at all (although the patch was still necessary after checking it over and over again). I muxed the non-UTF-8 subtitles into the mkv using mkvmerge GUI (which uses mkvmerge)... then, when I checked the new mkv file, I saw it has a UTF-8 text stream. So that means mkvmerge does the UTF-8 convertion automatically (:O)! Anyway, I demuxed the new stream from the new mkv, and then opened it using notepad. The stream is indeed UTF-8, but the last character is missing on every line. So that means it's a mkvmerge bug (with the encoding conversion! I'll look into their code and try to find the cause there.

EDIT2: I've submitted a mkvmerge bug: https://www.bunkus.org/bugzilla/show_bug.cgi?id=302

nautilus7

2nd October 2008, 16:50

With the lastest beta:

- This DTS sample doesn't work right: http://forum.doom9.org/showpost.php?p=1189485&postcount=4344
I have the same problem (sound plays very slow) with all my blu-ray samples. I originally thought it was due to the mpc-hc internal splitter, but it works with libdts. So it seems is an ffdshow problem. Weird is that DTS-HD into matroska works perfect.

albain

2nd October 2008, 18:50

Right, I will try to compare libdts parsing code with mine.

Anyone has a WAV sample with dts inside ?

nautilus7

2nd October 2008, 19:31

OK, thanks albain for your efforts. I 'll try to find you a dts wav sample later.

Mercury_22

2nd October 2008, 19:50

Right, I will try to compare libdts parsing code with mine.

Anyone has a WAV sample with dts inside ?

Look here http://www.diatonis.com/downloads_dts_ac3.html :)

STaRGaZeR

2nd October 2008, 20:08

Right, I will try to compare libdts parsing code with mine.

Anyone has a WAV sample with dts inside ?

It'll be interesting to compare both libdts and liba52, they play whatever you throw at them without a single problem.

Here you have a DTS in WAV sample:
http://www.megaupload.com/?d=0ASMH2BQ (34MB)

ACrowley

3rd October 2008, 08:24

I have the same problem (sound plays very slow) with all my blu-ray samples. I originally thought it was due to the mpc-hc internal splitter, but it works with libdts. So it seems is an ffdshow problem. Weird is that DTS-HD into matroska works perfect.

yes...same Problem here with m2ts Files with DTS HD.

DTS HD Files outside Container and in mkv are working perfect

decodes libavcodec the Full DTS HD or only the core ?

albain

3rd October 2008, 10:43

I think I fixed it. I did *not* studied the DTS in wav problem though.
You have to use a recent splitter : MPC internal splitter does not work well (slow playback) but Haali does. I tested it with the sample from URL http://forum.doom9.org/showpost.php?p=1189485&postcount=4344

New build :
FFDShow libavf branch beta 11 (http://www.megaupload.com/?d=M3HHCOA8)

However, I have troubles with TrueHD/MLP decoding, maybe due to the splitter.
Which player/splitter and file format should be used to be in the right conditions ?

STaRGaZeR

3rd October 2008, 11:02

ACrowley

3rd October 2008, 11:45

ah, ok...

Sonic Audio Decoder can do DTS HD fully (5.1), but the Decoder cant be used in mkv container (dont know any Splitter that can conect to Sonic in mkv?)
Arcsoft Decodre can fully decode DTS HD, but the Speaker etc Settings cant be saved.

nautilus7

3rd October 2008, 12:18

But it's the same decision as before, Haali plays the file right and MPC don't, but libdts, PowerDVD, etc. all work with both.+1
And i'm using mpc-hc r814 (latest) here.

BTW with beta11 I'm getting ffdshow.ax errors, and ffdshow won't load.Same problem here. It seems beta11 is broken.

However, I have troubles with TrueHD/MLP decoding, maybe due to the splitter.
Which player/splitter and file format should be used to be in the right conditions ?
Well, haali and mkvmerge don't support truehd/mlp. That's a problem. I think only way is to use mpc-hc internal mpeg splitter, but i can't tell if it works correctly or not.

albain

3rd October 2008, 12:58

But it's the same decision as before, Haali plays the file right and MPC don't, but libdts, PowerDVD, etc. all work with both. I'd always use Haali for (m2)ts files, but it just doesn't detect LPCM tracks present in Blu-ray so it's a no go.

BTW with beta11 I'm getting ffdshow.ax errors, and ffdshow won't load.

Only the core for now, libavcodec limitation.

ok, my mistake...

After digging this around, I suspect a bug in ffmpeg : with MPC internal splitter, the DTS parser skips 1 block of 2, unlike libdts. So 50% of the blocks don't reach the audio renderer.
I don't know why it does that though, my internal parsing seems fine...

nautilus7

3rd October 2008, 13:08

But does this explain why libav works ok with haali splitter? Maybe the mpc-hc developers could help.

albain

3rd October 2008, 17:31

After looking on ffmpeg mailing list, they advise to use libavformat to create the correct audio frames.

But I don't want to waste time integrating libavformat into FFDShow if it gives the same results...

CiNcH

4th October 2008, 08:46

Which player/splitter and file format should be used to be in the right conditions ?
MPC MpegSplitter IMHO outputs the full ES for a BDMV TrueHD stream within m2ts, so AC3 and MLP interleaved.
Our DVBSource filter currently only extracts AC3 frames from a BDMV TrueHD stream.

chadamir

4th October 2008, 17:12

Would ffdshow be able to pass the bitstream of truhd or dts-hd (ma) via hdmi without PAP on say a 4xxx series radeon?

madshi

4th October 2008, 19:57

After looking on ffmpeg mailing list, they advise to use libavformat to create the correct audio frames.
Sure they do. But it's not necessary if you have your own splitters. My eac3to tool has no problems whatsoever with any of the libav audio decoders, although eac3to doesn't use libavformat. I've simply written my own splitters instead.

I think the main reason why the Haali splitter works and the internal MPC splitter is not is that the Haali splitter "collects" data and tries to send full frames to the output pin. In contrast I think the MPC internal splitter sends every small data bytes forward as soon as it gets them. So with the MPC internal splitter you'll likely get small packages of 100 bytes each (or something like that). In order to make your ffdshow branch work with that you need to buffer the data internally until you have enough data available for at least one audio frame.

albain

4th October 2008, 22:56

Sure they do. But it's not necessary if you have your own splitters. My eac3to tool has no problems whatsoever with any of the libav audio decoders, although eac3to doesn't use libavformat. I've simply written my own splitters instead.

I think the main reason why the Haali splitter works and the internal MPC splitter is not is that the Haali splitter "collects" data and tries to send full frames to the output pin. In contrast I think the MPC internal splitter sends every small data bytes forward as soon as it gets them. So with the MPC internal splitter you'll likely get small packages of 100 bytes each (or something like that). In order to make your ffdshow branch work with that you need to buffer the data internally until you have enough data available for at least one audio frame.

This is what I did (i.e collecting full blocks before feeding the parser then the decoder then the renderer) but that did not make it.
For an unknown reason the parser rejets 1 blocks of 2 on my sample.

From the other hand, I spent some time studying libavformat and it appears that it would be useless for audio formats : libavformat constructs frames from the buffer for the parser for video streams only whereas audio buffers are sent directly to the parser.

So libavformat seems to be useful only for developing a "FFDShow splitter" which is not his role for now

albain

5th October 2008, 11:50

The buffer given by mplayerc splitter is not the same as haali's on a DTS sample. The beginning is the same but not the end :

Haali's buffer :
7FFE8001FC3C3ED275E0D3A098C63189CE73980002DB6DB6DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF400000000000000000195755555533110CCA88733CA86242222222222399710ECA86666444666553E864422222222222355E864222222222222200000000000015CD34

MPC's buffer :
7FFE8001FC3C3ED275E0D3A098C63189CE73980002DB6DB6DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40000000000000000019597577533330EA8886353EC82222222222222399710CA8886646668685732A884222222222222353C8844222222222222000000000000154D4D

nautilus7

5th October 2008, 14:00

The dts sample you got this buffer is a DTS-HD sample in a container (and which)?

I did some tests and realized that haali media splitter outputs the core of the DTS-HD track on m2ts and evo files, while it outputs the complete DTS-HD stream in mkv files only. MPC-HC's splitter outputs the full DTS-HD info. So i tried the next graphs:

m2ts: haali (dts core) --> libav --> ok
m2ts: mpc (dts-hd) --> libav --> problem
m2ts: mpc (dts-hd) --> libdts --> ok
mkv: haali (dts-hd) --> libav --> ok
evo: haali (dts core) --> libav --> ok

ffdshow is beta 10 because beta 11 doesn't work at all.

madshi

5th October 2008, 16:53

The buffer given by mplayerc splitter is not the same as haali's on a DTS sample. The beginning is the same but not the end
I think that must be 2 different frames. I'd suggest doing this:

(1) In ffdshow dump all the DTS input data into a test file.
(2) Use eac3to (or any other working demuxer) to extract the raw DTS data from the source file.
(3) Compare the ffdshow dump to the eac3to dump.

Do that with both Haali and MPC splitter. That might help finding out what's going on.

albain

5th October 2008, 18:14

I made my tests with a regular DTS sample (no DTS-HD blocks in it).

This is Bhack_Hawk_Down_LPCM_problem_Sample.ts (don't remember from whom I got it).

I tested it with MPC and then with windows media player (that uses Haali splitter)

I made deeper analysis, and the DTS headers are fine in both cases.

This is clearly a ffmpeg bug which does not know how to handle the subframes in all cases. I won't go further in the anlysis

However libdts is okay to decode those.

albain

5th October 2008, 18:18

I think that must be 2 different frames. I'd suggest doing this:

(1) In ffdshow dump all the DTS input data into a test file.
(2) Use eac3to (or any other working demuxer) to extract the raw DTS data from the source file.
(3) Compare the ffdshow dump to the eac3to dump.

Do that with both Haali and MPC splitter. That might help finding out what's going on.

Maybe but this is just the first buffer FFDShow receives in both cases.

EDIT : I spoke too quickly, actually the parser acts as the same way for Haali and MPC.

albain

5th October 2008, 18:40

I may have good news, but this must be confirmed : the problem comes from the input splitter that gives wrong information about the number of channels and the bitrate.

Making my own DTS parsing and updating the libavcodec structure seems to fix the problem

madshi

5th October 2008, 21:24

That makes a lot of sense. In my experience you can't trust the media type information of the input pin for compressed audio sources. All you can reliably (?) get from the media type information is which codec is being used. The media type information is reliable only for PCM, I think. E.g. just today I created a 7.1 AAC test encoding with the new Nero AAC encoder. Then I played that file back with the Nero DirectShow Audio Decoder. The source filter reported 7 channels (instead of 8).

albain

8th October 2008, 11:35

I have made a new build that should (I hope) decode all DTS formats including DTS in wav when using libavcodec

Here is the link :
http://rapidshare.com/files/152004436/ffdshow_rev2186_20081008_dbt_beta12.exe.html

However I have troubles to make TrueHD/MLP decoding work :
when I strip off MLP/TrueHD blocks (and keep AC3 blocks) to make decode by the AC3 decoder
or when I strip off AC3 blocks (and keep MLP/TrueHD blocks) to make decode by the MLP decoder
this does not work.

I hope to find the solution soon

STaRGaZeR

8th October 2008, 13:35

Testing the lastest beta now, it works! All DTS files and DTS in WAV also! Perfect.

However, this lastest betas are incomplete or something? Opening a video with ffdshow = crash, Vorbis = doesn't load, TTA = freeze. But DTS works now :p

rack04

8th October 2008, 14:11

albain

8th October 2008, 14:40

It should not.

Here is an updated version (with the last updates from the trunk).

I recompiled it completely

Link :
http://rapidshare.com/files/152044555/ffdshow_rev2186_20081008_dbt_beta12.exe.html

MatMaul

8th October 2008, 15:25

I've tested the mpeg-1 audio decoder of libavcodec and found a bug, i.e., the mp3 stream showed as mp2 @ info&cpu.
same "problem" here

otherwise everything works fine for me :)

rack04

8th October 2008, 15:33

STaRGaZeR

8th October 2008, 15:37

Nice, now everything works like it should. If I find any bug I'll post it.

EDIT: It seems there are still some files that will show mp2 instead of mp3.

albain

8th October 2008, 16:54

Nice, now everything works like it should. If I find any bug I'll post it.

EDIT: It seems there are still some files that will show mp2 instead of mp3.

Indeed, there was a bug, fixed in revision 2192

flanger216

9th October 2008, 00:54

Works perfectly for me, too. Great stuff! Any chance we could get an x64 build?

LoRd_MuldeR

9th October 2008, 01:47

I recently tried "ffdshow_rev2183_20081007_clsid_sse_icl10.exe " and it gave me black screen in DVBViewer :(

With "ffdshow_rev2176_20081003_clsid.exe " all works fine though...

CruNcher

9th October 2008, 03:06

@albain
i use your latest build but something is strange i put every WMV/VC1 on libavcodec though WMVA .wmv arent playbacked with it, i even tried to block the WMVideo Decoder, Windows Media Video Decoder,Windows Media Advanced Decoder no chance it then errors out.

C:\x264\Guitar.wmv::Raw Video 1

Media Type 0:
--------------------------
Video: WMVA 1280x720 59.94fps 6910Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {41564D57-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 110

VIDEOINFOHEADER:
rcSource: (0,0)-(1280,720)
rcTarget: (0,0)-(1280,720)
dwBitRate: 6910990
dwBitErrorRate: 0
AvgTimePerFrame: 166833

BITMAPINFOHEADER:
biSize: 62
biWidth: 1280
biHeight: 720
biPlanes: 1
biBitCount: 24
biCompression: WMVA
biSizeImage: 197012
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 ............Ð...
0010: 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 ............Ð...
0020: 0e 74 69 00 00 00 00 00 b1 8b 02 00 00 00 00 00 .ti.....±‹......
0030: 3e 00 00 00 00 05 00 00 d0 02 00 00 01 00 18 00 >.......Ð.......
0040: 57 4d 56 41 94 01 03 00 00 00 00 00 00 00 00 00 WMVA”...........
0050: 00 00 00 00 00 00 00 00|25 00 00 01 0f db fe 27 ........%....Ûþ'
0060: f1 67 88 80 00 00 01 0e 10 44 9f c5 9c 80 ñgˆ€.....DŸÅœ€

ffdshow is missing WMVA as ident for VC1 content ???

ACrowley

9th October 2008, 08:41

fixed build works perfect with all dts Tracks ive tested so far.
dts hd (core)decoding works on all m2ts files

Now we need the TrueHD decoder working ,would be so great

Thx for all your work

CiNcH

9th October 2008, 08:57

haruhiko_yamagata

9th October 2008, 09:47

I recently tried "ffdshow_rev2183_20081007_clsid_sse_icl10.exe " and it gave me black screen in DVBViewer :(

With "ffdshow_rev2176_20081003_clsid.exe " all works fine though...Sorry for that bug. The latest svn should be fine.

albain

9th October 2008, 10:09

Got some questions concerning EAC3 and TrueHD since we want to support that as well:

Will (or does) ffdshow support pure EAC3? (so without interleaved AC3 as specified by BDMV)
Will (or does) ffdshow support BDMV EAC3 with interleaved AC3? So does it strip EAC3 off all by itself or is this up to the demuxer filter?

Will ffdshow support pure TrueHD? (so without interleaved AC3 as specified by BDMV)
Will ffdshow support BDMV TrueHD with interleaved AC3? So does it strip TrueHD off all by itself or is this up to the demuxer filter?

What is the connection media subtype for all those possibilities? Always AC3? Will ffdshow detect the type of stream all by itself?

I am happy to announce that TrueHD/MLP decoding is fully functional. There was a bug in the libavcodec MLP parser that does not support interweaved streams (I hope that this was a bug and not a bug on my side).

Anyway, here is the status of the libavformat branch :
- Regular AC3 is fully supported as liba52 does
- Regular DTS is fully supported as libdts does
- EAC3 is fully supported
- DTS-HD decoding is supported (only DTS core is decoded)
- Dolby TrueHD and MLP *should be* fully supported (to be confirmed)

Concerning TrueHD/MLP decoding, here is how it works :
- If the stream contains interweaved regular AC3 and TrueHD frames, 2 thing can happen :
1/ If the AC3 output is selected in FFDShow config, then MLP blocks are stripped off and AC3 blocks are sent directly to the libavcodec AC3 decoder
2/ Otherwise the current decoder (which is libavcodec AC3 as this is the mediatype detected by the splitter) is closed and switched to libavcodec MLP decoder which decodes TrueHD/MLP blocks
- If the stream only contains TrueHD/MLP blocks, then MLP decoder is used

Things need to be improved on the detection of MLP/TrueHD. I did not add any separate codec for AC3/EAC3/TrueHD/MLP because for now things are not clear in the mediatype world.

Here is a corresponding build :
http://rapidshare.com/files/152298627/ffdshow_rev2195_20081009_dbt_beta13.exe.html

This build also fixes the MP3 streams showing as MP2

Concerning the issue with wmv VC1, please post a link to a sample so that I debug this

When this last issue + feedbacks on TrueHD/MLP + a global feedback on AC3/DTS will be positive, I think that we can merge the branch into the trunk.

For the record, I did not use libavformat at all (all the parsers & decoders are included into libavcodec), so the name of the branch is wrong...

Regards,

Damien

EDIT : some TrueHD files won't play. For example the sampleTrueHD 7.1ch 96KHz.m2ts won't pass (an error is raised by ffmpeg "Number of substreams 3 is larger than the maximum supported by the decoder"). So I guess that the ffmpeg MLP decoder does not support all the formats.

LoRd_MuldeR

9th October 2008, 10:29

Sorry for that bug. The latest svn should be fine.

Thanks for answer. I will report back as soon as a new ICL build is available :)

CiNcH

9th October 2008, 10:38

For the record, I did not use libavformat at all
That would have been my next question.. Does the demuxer have to exactly deliver one audio frame within one IMediaSample or is the parsing done somewhere within ffdshow?

albain

9th October 2008, 10:41

That would have been my next question.. Does the demuxer have to exactly deliver one audio frame within one IMediaSample or is the parsing done somewhere within ffdshow?
I have developed my own ac3/eac3/truehd/mlp/dts/dtshd internal parser (basing on libdts,liba52,ffmpeg and madshi's help) so the answer is no

nautilus7

9th October 2008, 10:44

EDIT : some TrueHD files won't play. For example the sampleTrueHD 7.1ch 96KHz.m2ts won't pass (an error is raised by ffmpeg "Number of substreams 3 is larger than the maximum supported by the decoder"). So I guess that the ffmpeg MLP decoder does not support all the formats.

Damien, well done! Thank you very much for all the improvements.

Regarding this issue with 7.1 TrueHD, i am sure that libav supports 7.1 96KHz streams, as eac3to can decode them perfectly using the same decoder. AFAIK, the truehd decoder is complete and supports all kind of streams, plus true 7.1 channel output.

CiNcH

9th October 2008, 10:54

So libavformat is not used in any respect, right? I have recognized that also MP3 parsing is buggy. If we for example send constant rate IMediaSamples, ffdshow does not perfectly reconstruct the frames and distortions are audible. We then did the parsing within the demuxer filter and packetized exactly 2 frames within one IMediaSample. mp3lib now does its job properly, with libmad, there are still distortions, think it only works with exactly one frame per IMediaSample.

albain

9th October 2008, 10:57

Damien, well done! Thank you very much for all the improvements.

Regarding this issue with 7.1 TrueHD, i am sure that libav supports 7.1 96KHz streams, as eac3to can decode them perfectly using the same decoder. AFAIK, the truehd decoder is complete and supports all kind of streams, plus true 7.1 channel output.

Well, I did not say that 7.1 is not supported, but on this sample the number of substreams is 3 which is a limitation of mlp decoder.

I guess that this sample sould not pass in eac3to...

nautilus7

9th October 2008, 10:59

albain

9th October 2008, 11:06

OK, I will figure this out with Madshi.
Maybe I have an old version of the decoder...

There is no MLP codec for now because there is no mediatype sent by the splitters to say that the stream is MLP or TrueHD.

M2TS files with TrueHD/MLP are detected by media player classic as AC3.

The switch is made inside FFDShow when it detects a MLP/TrueHD block

MatMaul

9th October 2008, 11:52

1/ If the AC3 output is selected in FFDShow config, then MLP blocks are stripped off and AC3 blocks are sent directly to the libavcodec AC3 decoder
are you talking about ac3 passthrough for SPDIF output ? then I think you mean send it directly to the output without decoding it.

clsid

9th October 2008, 12:48

When this last issue + feedbacks on TrueHD/MLP + a global feedback on AC3/DTS will be positive, I think that we can merge the branch into the trunk.Once everything is working, I propose an additional test period of about a week or so, with a public build on the sourceforge page so that we have a much larger test group. If no problems or side effects are reported after that period, then the merge can take place.

I want to perform the merge manually, not automatically since that will surely mess up things. Maybe an hours work for me, so no problemo.

Great work so far btw :)

If you would be able to make each format a separate option, then it would be even greater. Many users shall want that functionality.

albain

9th October 2008, 14:10

I just decoded it without problems with eac3to... All trueHD samples i 've sent you decode fine with eac3to and libav.

btw, shouldn't be an option for truehd/mlp in codecs menu in ffdshow? I don't see anything.

Indeed the file works with eac3 : it is parsed correctly to a .thd file and then extracted (not decoded) to an ac3 file.
But not with the MLP decoder (unless I am wrong)

Concerning the SPDIF passthrough, I realised that I made a mistake.
Actually, the AC3 decoder should never be used unless the MLP decoder fails (due to unsupported format).
Otherwise, AC3 frames when they are present should be used only when AC3 output is selected and/or SPDIF selected in AC3 codec ?

I've never understood why there is an AC3 checkbox in the output section and a SPDIF selection in the codec section

tal.aloni

9th October 2008, 14:19

I've never understood why there is an AC3 checkbox in the output section and a SPDIF selection in the codec section

me too, if you want to pass-through, you can choose SPDIF from the drop down menu.

MatMaul

9th October 2008, 14:21

spdif passthrougth works only for ac3 and dts.
for the other formats ffdshow decodes and then reencode in ac3 (if the option in the output page is selected of course).
so I think you should decode with MLP decoder except if spdif passthrougth is activated (and not the ac3 output option).

if someone who uses thoses functionalities can confirm ^^

STaRGaZeR

9th October 2008, 16:04

Has anybody been able to reproduce the high pitch sounds when playing DVDs? It doesn't matter if the audio is 2.0 or 5.1, PAL or NTSC DVDs... You can hear it when seeking, changing between chapters, inside the menus when selecting different options, etc. just before the video resumes after the seek so I assume it's a problem with the first audio frame. This is the only problem I have with the lastest beta.

nautilus7

9th October 2008, 16:32

Indeed the file works with eac3 : it is parsed correctly to a .thd file and then extracted (not decoded) to an ac3 file.
But not with the MLP decoder (unless I am wrong)I am not sure i understand you.

eac3to can extract TrueHD frames or AC3 frames from this sample and can decode both TrueHD and AC3 part with libav just fine:

eac3to "TrueHD 7.1ch 96KHz.m2ts" 2: truehd.thd <--truehd extraction
M2TS, 1 video track, 1 audio track, 0:00:12
1: h264/AVC, 1080i60 /1.001 (16:9)
2: TrueHD/AC3, 7.1 channels, 96khz
[a02] Extracting audio track number 2...
[a02] Extracting TrueHD stream...
[a02] Creating file "truehd.thd"...
Video track 1 contains 360 frames.
eac3to processing took 1 second.
Done.

eac3to truehd.thd <--confirmation
TrueHD, 7.1 channels, 96khz

eac3to truehd.thd truehd.wav <--truehd decoding with libav
TrueHD, 7.1 channels, 96khz
Decoding with libav/ffmpeg...
Remapping channels...
Writing WAV...
Creating file "truehd.24bit.wav"...
This audio track contains more than 16 bits of information.
This audio track has a constant bit depth of 24 bits.
eac3to processing took 2 seconds.
Done.

eac3to "TrueHD 7.1ch 96KHz.m2ts" 2: ac3.ac3 <--ac3 extraction
M2TS, 1 video track, 1 audio track, 0:00:12
1: h264/AVC, 1080i60 /1.001 (16:9)
2: TrueHD/AC3, 7.1 channels, 96khz
[a02] Extracting audio track number 2...
[a02] Extracting AC3 stream...
[a02] Creating file "ac3.ac3"...
Video track 1 contains 360 frames.
eac3to processing took 1 second.
Done.

eac3to ac3.ac3 <--confirmation
AC3, 5.1 channels, 0:00:12, 640kbps, 48khz

eac3to ac3.ac3 ac3.wav -libav <--ac3 decoding with libav
AC3, 5.1 channels, 0:00:12, 640kbps, 48khz
Decoding with libav/ffmpeg...
Remapping channels...
Loading white noise (needed for dithering)...
Writing WAV...
Creating file "ac3.wav"...
eac3to processing took 1 second.
Done.

If it is more convenient for you, you can demux both TrueHD and AC3 part in their original interleaved form by running:

eac3to "TrueHD 7.1ch 96KHz.m2ts" 2: truehd-ac3.thd+ac3 <--truehd+ac3 extraction
M2TS, 1 video track, 1 audio track, 0:00:12
1: h264/AVC, 1080i60 /1.001 (16:9)
2: TrueHD/AC3, 7.1 channels, 96khz
[a02] Extracting audio track number 2...
[a02] Creating file "truehd-ac3.thd+ac3"...
Video track 1 contains 360 frames.
eac3to processing took 1 second.
Done.

eac3to truehd-ac3.thd+ac3 <--confirmation
TrueHD/AC3, 7.1 channels, 96khz

fastplayer

9th October 2008, 22:48

I get jittery (>30ms) Xvid/DivX playback with the latest generic 2201 build (using MPC + WMP). It happens when using libavcodec as decoder but not with xvidcore.dll. Can somebody else confirm this?

LoRd_MuldeR

10th October 2008, 00:05

The "ffdshow_rev2201_20081009_clsid_sse_icl10.exe" build is fully functional with DVBViewer again :)

Thanks guys :thanks:

moshmothma

10th October 2008, 05:23

How are you splitting truehd to feed to ffdshow? MPC's splitter looks like it is only passing the ac3 core and not the full bitrate file. Which splitter is everyone using? Thx

wyrd

10th October 2008, 07:20

I get jittery (>30ms) Xvid/DivX playback with the latest generic 2201 build (using MPC + WMP). It happens when using libavcodec as decoder but not with xvidcore.dll. Can somebody else confirm this?
Hi,fastplayer.
Confirmed here.
http://tirnanog.fate.jp/tmp/snap/jitter_libavc_t.jpg (http://tirnanog.fate.jp/tmp/snap/jitter_libavc.png)http://tirnanog.fate.jp/tmp/snap/jitter_Xvid_t.jpg (http://tirnanog.fate.jp/tmp/snap/jitter_Xvid.png)
test sample (http://tirnanog.fate.jp/tmp/sample/divx/ffdshow-jitter-test02.avi).(1MB)
I've tyied on icl10 build.
Thanks

Octo-puss

10th October 2008, 08:48

I got a question regarding video decoder.
I couldn't play this VC-1 video at all only to realize I had to set VC-1 decoder to libavcodec. Wmv9 didn't work. Why was that? What would I have to have installed in order to choose that one? (I assume it would be a bit faster)

ACrowley

10th October 2008, 09:22

Octo-puss

10th October 2008, 09:25

I got Haali of course.
I muxed it into mkv.
My main question is about the wmv9 option...

fastplayer

10th October 2008, 09:45

Hi,fastplayer.
Confirmed here.
http://tirnanog.fate.jp/tmp/snap/jitter_libavc_t.jpg (http://tirnanog.fate.jp/tmp/snap/jitter_libavc.png)http://tirnanog.fate.jp/tmp/snap/jitter_Xvid_t.jpg (http://tirnanog.fate.jp/tmp/snap/jitter_Xvid.png)
test sample (http://tirnanog.fate.jp/tmp/sample/divx/ffdshow-jitter-test02.avi).(1MB)
I've tyied on icl10 build.
Thanks
Thanks for confirmation, wyrd!
Maybe this build should be pulled off of the server. Xvid and Divx are both not exactly uncommon decoders...

haruhiko_yamagata

10th October 2008, 10:02

albain

10th October 2008, 10:45

How are you splitting truehd to feed to ffdshow? MPC's splitter looks like it is only passing the ac3 core and not the full bitrate file. Which splitter is everyone using? Thx

I am using MPC home cinema v1.1.604 and I can assure you that it feeds FFDShow with complete AC3+TrueHD interweaved frames.

The new internal splitter of FFDShow splits up the frames (only AC3 or only TrueHD)

fastplayer

10th October 2008, 11:36

Oops, sorry. I have fixed at rev 2202.
:thanks:

clsid

10th October 2008, 12:04

I will try to make fresh builds later today.

albain

10th October 2008, 13:24

I confirm, there is a bug in ffmpeg code concerning MLP decoder.

Madshi uses code from an older revision and that has been patched.

If I apply the patch, all the TrueHD samples work.

albain

10th October 2008, 18:58

Here is an updated build with I hope full TrueHD/MLP support
http://rapidshare.com/files/152734338/ffdshow_rev2203_20081010_dbt_beta13.exe.html

It works with Media Player classic with internal M2TS splitter enabled and m2ts files (Haali does not work, I haven't searched why).
Be sure to enable libavcodec for AC3, DTS and MLP.
EAC3 is not mapped yet but it will be decoded if you select libavcodec for AC3

New features :
- TrueHD/MLP decoding
- Separate codecs for AC3, EAC3, and MLP/TrueHD
- Internal parser that is able to detect if the input stream is AC3, EAC3, AC3+TrueHD interweaved, TrueHD only, MLP, DTS, DTS-HD

Things remaining to do :
- Better interactions between the codecs : implement the internal parser on top of libavcodec (done), liba52 (to be done), libdts (to be done). This will let decode the first frames and switch to another decoder if the input stream is not what expected.

tal.aloni

10th October 2008, 19:28

what I'm really missing in ffdshow audio decoder is one-pass Audio Normalization.
all of the infrastructure is already there, and I would appreciate if anyone would implement it,
I think I'm not the only who would enjoy this feature.

Thanks,
Tal Aloni

Snowknight26

10th October 2008, 21:04

Is EAC3 SPDIF passthrough possible, not necessarily by way of ffdshow?

clsid

10th October 2008, 21:34

what I'm really missing in ffdshow audio decoder is one-pass Audio Normalization.There is a normalize option on the Volume page.

albain

10th October 2008, 21:53

Is EAC3 SPDIF passthrough possible, not necessarily by way of ffdshow?

I was wondering the same thing. For now EAC3 is decoded and can be reencoded to AC3 if AC3 output is selected.
Is SPDIF able to transport EAC3 stream ?
If the answer is yes, I will try to add a SPDIF output to EAC3 codec

tal.aloni

10th October 2008, 22:07

There is a normalize option on the Volume page.

I know, but it results in distortion, I was refering to one-pass normalization, which reduce the amplification every time an overflow is occured. (without raising it back like ffdshow does)

such feature is implemented in AC3Filter for example.

Thanks,
Tal Aloni

tal.aloni

10th October 2008, 22:19

I was wondering the same thing. For now EAC3 is decoded and can be reencoded to AC3 if AC3 output is selected.
Is SPDIF able to transport EAC3 stream ?
If the answer is yes, I will try to add a SPDIF output to EAC3 codec

unlikely, Don't waste your time on it.
the only legal path for DD+ is HDMI v1.3, and even if you could find a receiver that will accept DD+ over spdif (not likely) there will be no point, because:
a. computer spdif implementation is usually limited to 1.5mbps, most dd+ tracks consume more (this might be incorrect for blu-ray tracks, which are limited to 1.7mbps).
b. most receivers that support DD+, support PCM over HDMI.

Tal Aloni

p.s. if you do try to implement it, I have the equipment to test it (TX-SR576)

nautilus7

10th October 2008, 22:51

TrueHD 5.1ch 48KHz into .evo (http://www.sendspace.com/file/kvg83h)
TrueHD 5.1ch 48KHz (with AC3 track) into .m2ts (http://www.sendspace.com/file/ffzfhh)
TrueHD 7.1ch 48KHz (with AC3 track) into .m2ts (http://www.sendspace.com/file/fxpmum)
TrueHD 7.1ch 96KHz (with AC3 track) into .m2ts (http://www.sendspace.com/file/ul4f3x)
TrueHD 7.1ch 96KHz into .evo (http://www.sendspace.com/file/8k0l20)
From these samples, only TrueHD 5.1ch 48KHz seems to work. All other .m2ts files produce jerky playback with noise or no sound at all and make mpc crash sometimes. Does this have to do with the libavcodec patch?

Also if i set the mlp decoder to disabled and ac3 to libavcodec, mpc/ffdshow crashes for all .m2ts samples.

All tests were done with mpc-hc 1.1.814 internal splitter.

We can't test TrueHD in EVO because Haali doesn't support TrueHD at all and MPC-HC mpeg splitter doesn't support EVO. :(

Finally, this (http://www.sendspace.com/file/z08elm) DTS-HD Master Audio 7.1ch 96KHz sample doesn't play ok.

madshi

10th October 2008, 23:53

Don't waste your time on it.
the only legal path for DD+ is HDMI v1.3
Agreed.

and even if you could find a receiver that will accept DD+ over spdif (not likely) there will be no point, because:
a. computer spdif implementation is usually limited to 1.5mbps, most dd+ tracks consume more (this might be incorrect for blu-ray tracks, which are limited to 1.7mbps).
Incorrect. HD DVD DD+ tracks are usually either 640kbps (Warner), 768kbps (Universal dubbed tracks) or 1536kbps (Universal original track). I'm not aware of any DD+ tracks with more than 1.5mbps. Technically higher bitrates are allowed for DD+, but they were never used in real life (AFAIK).

rack04

11th October 2008, 00:04

All the mkv files with h264 and AC3 crash with beta13. They play fine with beta12.

Bathrone

11th October 2008, 02:59

Having switched to Linux I have not used ffdshow in some time. When I was encouraging a mate to use it, I installed the latest compile on his laptop. Some questions please:

1. Why is h264 decoding disabled by default? I had to manually specify libavcodec.

I could no longer see the ffdshow tray icon thingy.

2. What happened to the video and audio tray icons?

I was showing him megui, avisynth, dgmpgdec etcetc. I had some strange results with decoding. One file, with fourcc avc1 failed to playback even though I had libavcodec enabled.

3. Why would wmp fail to playback avc1 when I have enabled libavcodec decoding?

Then strangely, on another sample with an avc1 fourcc it would playback with no error message, but then it would fail to provide video with audio only.

4. Why the inconsistency?

I get none of these problems with own Linux SVN compiles of ffmpeg / ffplay / mplayer.

Many thanks for the help :)

chadamir

11th October 2008, 03:18

Is there a way to pass the eac3/truehd as bitstream through hdmi?

rack04

11th October 2008, 04:01

Libav AC3 is broken in the latest build.

ACrowley

11th October 2008, 08:11

Is there a way to pass the eac3/truehd as bitstream through hdmi?

When you have a new Ati Card ... yes.

4870 has a Soundchip to pass Audio trough HDMI .

"Integrated HD audio controller with support for stereo and multi-channel (up to 7.1) audio formats, including AC-3, AAC, DTS, DTS-HD & Dolby True- HD4, enabling a plug-and-play audio solution over HDMI"

But the cant send out the Bistream...only PCM!

You have to select the Ati HDMI Audio in Windows Sound Options.... And then you get all Audio as PCM to HDMI out and you Receiver can handle it as Multichannel PCM...i think so , but im not sure.

Also there a some new Sound Cards like the Asus Xonar HDAV with HDMI..they can send the Bitstream trough HDMI. But you need Decoders that can passtrough a DTSHD/THD,DD+ Bitsstream via HDMI
http://www.asus.com/news_show.aspx?id=11638
"Dolby TrueHD, Dolby Digital Plus, and DTS-HD Master Audio pass-through upgradeable by TotalMedia player"

I will by such a Card next Time...maybe i wait for some new cards from Creative...dont know. Im happy with my X-fi Titanium PCI_E at the Moment. I use dtsconnect to SPDIF all Audio Formats as 1.5Mbps dts

CiNcH

11th October 2008, 08:15

It works with Media Player classic with internal M2TS splitter enabled and m2ts files (Haali does not work, I haven't searched why).
When I tested Haali and TrueHD within m2ts it didn't even detect the TrueHD streams...

tal.aloni

11th October 2008, 09:10

I'm not aware of any DD+ tracks with more than 1.5mbps. Technically higher bitrates are allowed for DD+, but they were never used in real life (AFAIK).

I have 1640kbps DD+ tracks on the "The Sound of High-Definition" Blu-Ray, but it seems that I was too quick to extrapolate, because I can't find any other example that have DD+ larger than 1536kpbs.

Thanks,
Tal Aloni

tal.aloni

11th October 2008, 12:11

Kurtnoise

11th October 2008, 12:21

Libav AC3 is broken in the latest build.
confirmed...

Keep the good work albain. :)

madshi

11th October 2008, 12:22

I have 1640kbps DD+ tracks on the "The Sound of High-Definition" Blu-Ray, but it seems that I was too quick to extrapolate, because I can't find any other example that have DD+ larger than 1536kpbs.

Thanks,
Tal Aloni
Yes, the Dolby demo discs are "special"... :)

K1ngp1ng

11th October 2008, 14:19

when using libav for dtswav the channels are wrong: SL=L, L=C, C=SL

i enabled mlp decoding but i can't play .mlp files at all.

clsid

11th October 2008, 16:36

CiNcH

12th October 2008, 10:26

I have now tried ffdshow/libav with live DVB where random access plays an important role. I have enabled libav for both MPEG layer 2 and AC3 audio and ffdshow crashes a lot of times when formats change on-the-fly on channel switching.
It is also interesting that when I am tuned to a channel with AC3 audio then go to the DVBViewer's DirectShow options and let the DVBViewer rebuild the graph, ffdshow also crashes in case libav is chosen as AC3 decoder within ffdshow (does not happen with liba52). But I did not change the audio decoder/renderer so the audio path of the graph may not be rerendered at all.

phunqe

12th October 2008, 10:32

Hi,

it feels liks I'm missing something basic, but I can't figure out what it is.

I did a fresh install of Vista x64 (Business version) and installed the October 10th x64 ffdshow tryout.
I can't get any movie to play in the x64 version of WMP11 (nor the x86 version for that matter). I tried h264 and DivX.

Furthermore, if I try to use for example Media Portal, ffdshow doesn't show up as valid codec selection for video playback (as if it wasn't registered properly).

Did I miss something?

Cheers.

albain

12th October 2008, 10:34

There was some bugs in my code.

Now all the TrueHD samples are working.

I also did not recompile completely the project so it explains why libav AC3 was broken

Finally, this DTS-HD Master Audio 7.1ch 96KHz sample doesn't play ok.
This sample now works on my side

The last thing to fix would be the wrong channel order. A sample would be helpful.

I will post a new release soon

nautilus7

12th October 2008, 10:55

Wrong channel order with DTS? What samples do you need?

albain

12th October 2008, 14:24

Wrong channel order with DTS? What samples do you need?

Well, according to :

when using libav for dtswav the channels are wrong: SL=L, L=C, C=SL

DTS wav would have wrong channel order (I was not aware of that), so if someone has a sample saying "Left", "Right", "Rear Left"... in order to test and fix this problem correctly....

nautilus7

12th October 2008, 15:02

tal.aloni

12th October 2008, 15:29

I just made the test myself, (using my own sample)
there is a mapping problem with dts wav using libavcodec.

I'm Having this Mapping (revision 2203):

1. Left Front Channel > 2. Right Front Speaker
2. Right Front Channel > 5. Left Surround Speaker
3. Center Channel > 1. Left Front Speaker
4. LFE Channel > 4. LFE Speaker
5. Left Surroud Channel > 6. Right Surround Speaker
6. Right Surround Channel > 3. Center Speaker

Tal Aloni

tal.aloni

12th October 2008, 15:35

If i load the file in mpc, i get just noise, which means the dts is not recognized. The check for dts in wav option in ffdshow is enabled of course.

Do you have normalization, down-sampling, or any other audio processing involved using MPC?
also, check to see which filters are used before ffdshow, probably something tamper with the wav before it arrives to ffdshow.

K1ngp1ng

12th October 2008, 17:06

Here (http://www.sendspace.com/file/wbbiui) you are. Exactly what you asked.
apparently ffdshow doesn't detect 48 khz dtswav. what's the point of dtswav if it's not cd-player compatible anyway? :confused:

nautilus7

12th October 2008, 17:10

Ah, you might be right about 48KHz dts wav and ffdshow.

But this file was made with official DTS pro encoder, so if that encoder allows such output, i believe it is legitimate.

I am creating a dts wav @ 44,1KHz this time with same content (channel positions).

EDIT: Actually, i created dts wavs of all possible combinations (16 & 24 bits, 44,1 & 48 KHz and 768, 1411 & 1536 kbps bitrate). Don't know what a standalone player is supposed to play, but all these kinds are detected correctly from eac3to. Uploading...

12th October 2008, 17:33

Did I miss something?
x64 splitter? ;)

saint-francis

12th October 2008, 17:58

x64 splitter? ;)

I"m assuming that the divx file can be split by wmp but the h.264 file probably needs either haali x64 (nonexistent) or the file will need to be played with mpc. Can wmp split .avi? If so there is another problem.

nautilus7

12th October 2008, 18:03

DTS WAV (http://www.sendspace.com/file/k7vi32) samples (the previous one is included but with different name).

Legitimate or not, i think it's not hard to support all.

phunqe

12th October 2008, 18:21

Oh... Yea I was using the regular ones from Haali's homepage, I'll try the x64 one. Although a regular DivX didn't play either.
Registering the .ax file manually didn't produce any errors...

_xxl

12th October 2008, 18:36

Latest build is crashing if libavcodec ac3 decoder is used.
http://rapidshare.com/files/153346332/_manhole-fansubs_test_your_5.1__ac3_._aac_.mkv.html
and
http://x264.nl/h.264.samples/force.php?file=./feb.2008/CINE.PREMIER.HD.astra.19e.05.feb.2008.ts

Mercury_22

12th October 2008, 18:39

Here (http://www.sendspace.com/file/wbbiui) you are. Exactly what you asked.

I have a question though... How do i play dts wavs with ffdshow? If i load the file in mpc, i get just noise, which means the dts is not recognized. The check for dts in wav option in ffdshow is enabled of course.
DTS in WAV still NOT working for me too ! :( :helpful:

Tested with WMP & MPC-HC; 32-bit & 64-bit; libdts & libav (libav just 32-bit);

WAV sample with dts inside : http://www.diatonis.com/downloads_dts_ac3.html

P.S. AC3Filter it's working with DTS in WAV

SeeMoreDigital

12th October 2008, 19:08

The 44.1KHz DTS in WAV samples work for me, but only when the "Uncompressed" option is set to "All Supported" ;)

Mercury_22

12th October 2008, 19:12

The 44.1KHz DTS in WAV samples work for me, but only when the "Uncompressed" option is set to "All Supported" ;)

Yes thanks for the tip but it's working just with MPC with WMP still NOT working !:thanks:

P.S. Some splitter missing maybe ?

nautilus7

12th October 2008, 19:15

Yes, works here too, but channel mapping is wrong.

Also WMP crashes, but i don't care much... :D

albain

12th October 2008, 20:06

Here is an updated build :
http://rapidshare.com/files/153369315/ffdshow_rev2210_20081012_dbt_beta14.exe.html

New features :
- Bug fixes : all DTS samples should pass. Wrong channel mapping to be checked (I didn't modify anything on this part). All TrueHD samples should pass.
- Codec switching : if input stream is AC3 (according to splitter) and you selected liba52 for AC3, then liba52 is used for decoding. But if on the incoming data the parser detects an EAC3 stream, then FFDShow switches the decoder to the one selected for EAC3 (libavcodec only). Same thing for TrueHD/MLP.
- If SPDIF is selected for AC3 and a TrueHD/AC3 interweaved stream is detected by the internal parser, then AC3 frames are extracted (TrueHD frames are thrown) and sent directly to SPDIF. Otherwise MLP frames are decoded.

albain

12th October 2008, 20:09

apparently ffdshow doesn't detect 48 khz dtswav. what's the point of dtswav if it's not cd-player compatible anyway? :confused:

This does not surprise me, the existing code parses just the header sync, not the sample rate and so it assumes that DTS in wav is always at 44Khz.
However the internal parser I added parses all the header

So this is easy to fix. Please remind me this if I don't do this soon

clsid

12th October 2008, 20:16

albain

12th October 2008, 20:40

What happens if the EAC3 decoder is enabled and the AC3 decoder is set to disabled and a regular AC3 stream is detected? Will ffdshow then refuse the graph connection, allowing another filter to decode the audio?

Yes, this is the problem but it is just not possible to receive some buffers before saying "I won't decode this"

As long as there won't be any media guid that identifies EAC3 against AC3.

Same problem with MLP/TrueHD

Today everything starts from AC3 format

madshi

12th October 2008, 20:50

Yes, this is the problem but it is just not possible to receive some buffers before saying "I won't decode this"
Are you sure? I think it must be possible somehow, but I don't know how...

nautilus7

12th October 2008, 21:01

@albain, first feedback:

-TrueHD 7.1 and 96KHz works fine!
-DTS-HD Master Audio 7.1 96KHz works fine!
-DTS WAV 44,1KHz play fine, but channel mapping is wrong. Currently the output is C,L,R,LS,RS,LFE instead of L,R,C,LFE,LS,RS. Plain DTS is fine.

albain

12th October 2008, 21:52

Are you sure? I think it must be possible somehow, but I don't know how...
With DirectShow ?
In direct show the steps are following :
1/ Checking if filter accepts the given media type
2/ If yes, enable connection, else go to the next available filter (step1)
3/ Feed the filter with buffers (Receive method)

A while ago I used a trick to make FFDShow video working with uncompressed format in Vista (there was a regression from XP to Vista) by accepting all the media types and then inside FFDShow finding a compatible decoder by myself.
But I don't see a way to do the opposite, i.e. pulling ffdshow out of the loop : directshow will scan all the compatible filters again including ffdshow

@albain, first feedback:

-TrueHD 7.1 and 96KHz works fine!
-DTS-HD Master Audio 7.1 96KHz works fine!
-DTS WAV 44,1KHz play fine, but channel mapping is wrong. Currently the output is C,L,R,LS,RS,LFE instead of L,R,C,LFE,LS,RS. Plain DTS is fine.
Good to hear. I will try to fix this issue

madshi

12th October 2008, 22:00

With DirectShow ?
In direct show the steps are following :
1/ Checking if filter accepts the given media type
2/ If yes, enable connection, else go to the next available filter (step1)
3/ Feed the filter with buffers (Receive method)

A while ago I used a trick to make FFDShow video working with uncompressed format in Vista (there was a regression from XP to Vista) by accepting all the media types and then inside FFDShow finding a compatible decoder by myself.
But I don't see a way to do the opposite, i.e. pulling ffdshow out of the loop : directshow will scan all the compatible filters again including ffdshow
I know that e.g. the Sonic Audio Decoder works only if you feed it multiple audio frames at once. If you only feed it one audio frame at a time, the connection is refused. So maybe the trick is to accept the connection at first but to break it later when the first data arrives? Or maybe in the media type check function you can ask for data? I've no idea...

ACrowley

13th October 2008, 10:08

TrueHd/MLP decoding works only inside m2ts/evo ,correct?

Actually i use the Sonic Decoder/Filter v 5.0 from Cinevision 2.5.
Filesource(async)-SonicHDDemuxer-SonicCinemasterAudioDecoder works very good ony demuxed TrueHd/Mlp Files (v4.3 Decoders had Problems with Thd).
SonicHDDemuxer (v5.0.0.3) detects the truehd Stream very well, but the Demxuer cant connect to ffdshow.

But it would be also nice to get ffdshow working on demuxed TrueHD Files..but we must have a Source Filter and Splitter first ?

albain

13th October 2008, 10:35

I made a new build that removes the old DTS parser and use the new one. Normally multichannel and >44Khz DTS in wav should work correctly.
Maybe it will correct the wrong channel mapping too, if someone can confirm it.
I also added the new formats to the installer.

http://rapidshare.com/files/153530687/ffdshow_rev2212_20081013_dbt_beta15.exe.html

Concerning the sonicaudio demuxer, for now there are 2 media guids that are detected as MLP/TrueHD (in addition to AC3 format that is parsed for MLP frames) :
DEFINE_GUID(MEDIASUBTYPE_NERO_MLP ,0x1e889be7, 0xb276, 0x4064 ,0x9a, 0x39, 0x16, 0x0a, 0x06, 0x89, 0x5b, 0x52);
DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_MLP ,0x4288b843, 0x610b, 0x4e15 ,0xa5, 0x3b, 0x43, 0x00, 0x7f, 0xcf, 0xf6, 0x14);

So I think that this is just a matter of media guid to add.
You should be able to get it with graphedit (I think)

ACrowley

13th October 2008, 10:50

what should i get with graphedit ? What do you mean ?

This is the PIN info from SonicHDDemuxer on a Bluray TrueHD File (SonicHDDemuxer-SonicCinemasterAudioDecoder)

In :

CLSID: {250D7B7D-4344-41FD-A284-7299B7765F18}
Filter: Sonic HD Demuxer

- Connected to:

CLSID: {E436EBB5-524F-11CE-9F53-0020AF0BA770}
Filter: D:\10000BC\english - 3 - TrueHD+AC3, 5.1 channels, 48khz.thd
Pin: Output

- Connection media type:

Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

-----------------------------------------------------------
out :

CLSID: {250D7B7D-4344-41FD-A284-7299B7765F18}
Filter: Sonic HD Demuxer

- Connected to:

CLSID: {9F062738-CD84-4F54-A3C4-BD5EB44F416B}
Filter: Sonic Cinemaster® Audio Decoder 4.3.0
Pin: Audio in

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 6912Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {4094A857-7891-44AC-92B5-C1CFF37AF2E7}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 864000
nBlockAlign: 18
wBitsPerSample: 24
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 24
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 2f 0d 00 12 00 18 00 þÿ..€».../......
0010: 16 00 18 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

STaRGaZeR

13th October 2008, 11:17

Albain, with beta15 the same old problems with DTS playing too slow when internal MPC's splitter is used are back. No problems with beta14.

Keep up the good work :)

nautilus7

13th October 2008, 12:30

Yes, dts-hd problems are back.

DTS WAV channel mapping is correct. Only 44,1KHz are supported though.

Also, if the truehd/mlp decoder is disabled, TrueHD/AC3 tracks from blu-ray don't play correctly. I had a look at the info tab and the AC3 stream is not detected correctly (number of channels and samplerate is changing during playback).

7.1 TrueHD decoding has wrong channel mapping. The back channels are in the position of the side channels. Now it is L,R,C,LFE,SL,SR,BL,BR while it should be L,R,C,LFE,BL,BR,SL,SR.

albain

13th October 2008, 13:38

Yes, dts-hd problems are back.

Indeed, I can reproduce it.

DTS WAV channel mapping is correct. Only 44,1KHz are supported though.
EDIT : right, there was a limit that was hardcoded

Also, if the truehd/mlp decoder is disabled, TrueHD/AC3 tracks from blu-ray don't play correctly. I had a look at the info tab and the AC3 stream is not detected correctly (number of channels and samplerate is changing during playback).

This is normal, if you disable the MLP decoder, then the current decoder (AC3) will handle the decoding.
For now AC3 frames are extracted only when SPDIF AC3 is selected
2 possibilities :
1/ If MLP codec disabled or if SPDIF AC3 is enabled, then extract only AC3 frames (if there are) and send them to the AC3 decoder.
2/ Stop FFDShow from decoding this stream and find a compatible decoder.

7.1 TrueHD decoding has wrong channel mapping. The back channels are in the position of the side channels.
I guess this has never been correct, right ?

nautilus7

13th October 2008, 13:42

DTS WAV (http://www.sendspace.com/file/k7vi32) with 48 KHz don't work. The zip is the same i uploaded yesterday, it contains all kinds of dts wav.

Regarding 7.1 TrueHD, i guess you 're right. It's the first time i test 7.1 TrueHD channel order.

albain

13th October 2008, 14:54

With this new build this works better :
http://rapidshare.com/files/153589853/ffdshow_rev2213_20081013_dbt_beta16.exe.html

Changes :
- 48Khz (and I guess more) DTS wav and DTS-HD files work with MPC internal splitter
- If MLP decoder is disabled and input stream is AC3/TrueHD interweaved, then AC3 decoder is used on stripped off AC3 frames
- I configured libavcodec AC3 EAC3 and MLP channels to the same mapping (EAC3 and MLP channels were not remapped with previous builds). Hope that MLP/TrueHD channels will be correctly ordered
- DTS (and DTS-HD streams too) showing as "dts" instead of "dca" in the tray icon.
EDIT : I have also added the Sonic HD demuxer to the accepted media guids for MLP. To be tested

ACrowley

13th October 2008, 15:29

albain.... SonicHDDemuxer now connects to ffdshow with MLP/THD demuxed Files:)

Filesource(async)-SonicHDDemuxer-ffdshowaudiodecoder

Working in graphedit but its very Tricky with mpc etc

We really need a new Source Filter and Splitter for THD/MLP Files

STaRGaZeR

13th October 2008, 16:19

albain

13th October 2008, 17:47

Beta16 doesn't work with normal PCM (in Matroska at least) and DTS in the Black Hawk Down sample you already have albain. ffdshow is loaded but no info in "Info & CPU" and the video is frozen at the first frame with no sound. Maybe you haven't recompiled everything?

Indeed, there was a bug.

Strange concerning your DTS sample, it is working on my side...

I have fixed the bug and recompiled it, hope that it will work

http://rapidshare.com/files/153644648/ffdshow_rev2213_20081013_dbt_beta17.exe.html

STaRGaZeR

13th October 2008, 18:12

Let me try with this one.

EDIT: Yes, everything works now with beta17. It surely was my fault :)

CiNcH

13th October 2008, 18:54

nautilus7

13th October 2008, 21:00

Working so far (all retested with latset beta)

* AC3 with correct channel mapping.
* E-AC3 (5.1 or 7.1, with or without AC3 core) with correct channel mapping.
* DTS, DTS-HD (Hi Res & Master Audio), DTS WAV (all variants, legal or not, up to 96KHz), DTS 24/96, DTS-ES 6.1 (matrix and discete), all with correct channel mapping.
* TrueHD (5.1 or 7.1, 48KHz or 96KHz) with wrong channel mapping. I haven't test MLP.

Not working

* AC3 decoding of TrueHD/AC3 streams when the TrueHD decoder is disabled.
* TrueHD channel order for 5.1 is L,C,R,RS,LFE,LS instead of L,R,C,LFE,LS,RS.
* TrueHD channel order for 7.1 is L,R,C,LFE,Side L,Side R,Back L,Back R instead L,R,C,LFE,Back L,Back R,Side L,Side R, (nothing changed with previous beta).

Cosmetic & other bugs

* Even if the libavcodec is selected for MP1,MP2 during the installation, the libmad decoder is actually selected in the ffdshow audio configuration.
* In Info and CPU page, the channel naming for any 5.1 track is L,R,C,LFE, back left, back right. Actually, in 5.1 the channels are called surround or side. Naming them as Back could make people confuse them with the Back channels of the 7.1 tracks. (that's just cosmetic)
* In Info and CPU page, some E-AC3 tracks are reported with wrong bitrate. This (http://www.sendspace.com/file/uy023r) 7.1 E-AC3 track from HD DVD is reported as 930kbps, while eac3to reports it as 1662kbps. (also just cosmetic)

Additional Notes

* Some DTS-HD or TrueHD samples contain interlaced video and may produce non smooth playback if decoded with libavcodec. In any case the audio is decoded fine, but there are a lot of dropped video frames in the renderer. For me switching to powerdvd video decoder gives 100% ok playback.

STaRGaZeR

13th October 2008, 22:55

Snowknight26

14th October 2008, 05:18

Is it possible to show the bitrate for vorbis tracks (in either the Info & CPU pane or the extended info in the tray)?

albain

14th October 2008, 08:21

Weird problem here: playing .mkv files with PCM audio (demuxed from Blu-ray using eac3to and muxed to Matroska using mkvmerge) will randomly result in the audio being silenced. If I look at "Filters" in MPC, ffdshow reports sometimes 2 channel dts and others 5 channel dts. The only solution is to close the player and reopen it. This didn't happen with previous betas, and I guess this is due to the new parser detecting something strange and switching codecs in consequence. But as I say it's totally random, if it happens at 2:00 I restart MPC, go to 2:00 and the file plays fine, but fails at 11:00 for example. Does the new splitter allow to change codecs at every time?

There was a bug with beta16 fixed in beta17. Is this the one you used ?

Otherwise no, the parser will allow only one change of format, in order to avoid this kind of problem. There is a hardcoded limit that can be changed. Maybe it is wrongly applied in some cases.
However I update the channels, bitrate and sample format for each frame. This things don't usually change but this was necessary to make libavcodec work correctly. I will try to reproduce the problem. The file you muxed was a DTS wav right ?

About TrueHD decoding when MLP decoder is disabled, I did not reproduce the problem : when MLP decoder is disabled (and AC3 decoder is set to liba52, or libavcodec or SPDIF), AC3 frames are extracted and I can hear the sound

EDIT : I found THE bug that caused this erratic behaviour. Also I updated channel mapping for TrueHD. I think it is okay for 5, 6 and 8 channels but I am not sure for 7 channels

MatMaul

14th October 2008, 09:43

anyone have tried the ffdshow multithread branch ?
here is a build for those who want to test (I have a single core:p )
http://www.xvidvideo.ru/content/view/310/1/

carnage_pl

14th October 2008, 11:01

[QUOTE=MatMaul;1196289]anyone have tried the ffdshow multithread branch ?
here is a build for those who want to test (I have a single core:p )
http://www.xvidvideo.ru/content/view/310/1/[/QUOITE]
It's working but there any changes in cpu usage in 720p

_xxl

14th October 2008, 12:19

It isn't finished, when done I''ll post a test build.

haruhiko_yamagata

14th October 2008, 13:33

It's not ready for open test, but it works for most progressive H.264 samples.
Do not try to play MPEG-4 part 2 or PAFF/MBAFF.
If you still want to play with it, set decoding thread = 8 (and do not report any bugs).

STaRGaZeR

14th October 2008, 14:33

There was a bug with beta16 fixed in beta17. Is this the one you used ?

Otherwise no, the parser will allow only one change of format, in order to avoid this kind of problem. There is a hardcoded limit that can be changed. Maybe it is wrongly applied in some cases.
However I update the channels, bitrate and sample format for each frame. This things don't usually change but this was necessary to make libavcodec work correctly. I will try to reproduce the problem. The file you muxed was a DTS wav right ?

About TrueHD decoding when MLP decoder is disabled, I did not reproduce the problem : when MLP decoder is disabled (and AC3 decoder is set to liba52, or libavcodec or SPDIF), AC3 frames are extracted and I can hear the sound

Yes, beta17. And no, normal WAV. eac3to demuxes LPCM tracks to .wav files, and then I mux to Matroska. So they're standard uncompressed PCM audio. I think this has to do with the way your parser detects channels, bitrate and sample format in this beta.

I've found a point where beta17 always changes the decoder. I've cut 6 seconds of video, the change happens around 00:03. Look quickly at Info & CPU. It changes from uncompressed to 48KHz 6 channels dts and then to 96KHz 6 channels dts. No problems with earlier betas. It happens with libdts also, so most probably the problem is in the parser.

http://www.megaupload.com/?d=AKPQ37VX (32MB)

albain

14th October 2008, 14:54

New build for new audio codecs : DTS-HD, Dolby TrueHD/MLP, EAC3 and AC3/DTS with libavcodec

I feel that this is one of the last builds before making it more public

http://rapidshare.com/files/153921556/ffdshow_rev2217_20081014_dbt_beta18.exe.html

Changes :
- No more erratic behaviours whith AC3/TrueHD/DTS decoding
- Channel order fix for TrueHD (to be confirmed, especially for 7 channels mode)

STaRGaZeR

14th October 2008, 15:02

It still fails with my previous sample.

albain

14th October 2008, 15:30

It still fails with my previous sample.

Right, please try with this build :
http://rapidshare.com/files/153932360/ffdshow_rev2217_20081014_dbt_beta19.exe.html

The old DTS parser only parsed the first PCM frame so it assumed that the sync word would always be in it whereas the new parser parses all the frames.
I reverted to the old behaviour (only for PCM) but this situation could occur, if you start playback in the middle of a file, the splitter may not send the first frame with a syncword.
To sum up : in the TODO list, improve the internal DTS parser so that I would not recognize a non syncword frame as it so that the parser scan again the whole stream.

albain

14th October 2008, 16:57

Working so far (all retested with latset beta)
...
[B][U]Cosmetic & other bugs
...
* In Info and CPU page, some E-AC3 tracks are reported with wrong bitrate. This (http://www.sendspace.com/file/uy023r) 7.1 E-AC3 track from HD DVD is reported as 930kbps, while eac3to reports it as 1662kbps. (also just cosmetic)

This file fails to be decoded with eac3to (I have v2.66)

Besides, if you make the calculation, this sample lasts 45 seconds x 1662kbps/8 => 9.3Mb whereas the samples makes 5.2Mb.

The bitrate given by ffdshow (930kbps) gives 5.2Mb so this is the one which is correct.
The reason I guess is that the version of libavcodec that I use with FFDshow is newer

ACrowley

14th October 2008, 17:10

mhh.... ffdshow connect clean to SonicHDDemuxer on truehd/mlp demuxed files inside Graphedit.

But i cant get it working in any player. There must be a Problem because no Dshowplayer can connect the audio out pin from SonicHDDemxuer with ffdshow. Works only in graphedit

madshi

14th October 2008, 17:31

This file fails to be decoded with eac3to (I have v2.66)
Works for me. With v2.68, though.

Besides, if you make the calculation, this sample lasts 45 seconds x 1662kbps/8 => 9.3Mb whereas the samples makes 5.2Mb.
Both Nero and libav decoders output only 25 seconds. How do you get to 45 seconds?

The reason I guess is that the version of libavcodec that I use with FFDshow is newer
Does libav support 7.1 E-AC3 decoding in the meanwhile? I thought it only supports 5.1? Not sure, though. Either way, eac3to extracts the AC3 core of that 7.1 track and decodes only that. The E-AC3 channel extension is stripped away, just like DTS-HD blocks are. This results in 25 seconds runtime...

STaRGaZeR

14th October 2008, 17:49

Right, please try with this build :
http://rapidshare.com/files/153932360/ffdshow_rev2217_20081014_dbt_beta19.exe.html

The old DTS parser only parsed the first PCM frame so it assumed that the sync word would always be in it whereas the new parser parses all the frames.
I reverted to the old behaviour (only for PCM) but this situation could occur, if you start playback in the middle of a file, the splitter may not send the first frame with a syncword.
To sum up : in the TODO list, improve the internal DTS parser so that I would not recognize a non syncword frame as it so that the parser scan again the whole stream.

Indeed, it works so far. It seems you have found the problem. Also you should know that with the lastest changes in the parser changing between different streams is much better (before there was some crashes and weird behaviour in general). GOOD WORK!

For cosmetics, wouldn't it be better to use DTS, AC3, PCM, etc. instead of dts, ac3, pcm, etc.?

albain

14th October 2008, 18:35

Works for me. With v2.68, though.

Both Nero and libav decoders output only 25 seconds. How do you get to 45 seconds?

Does libav support 7.1 E-AC3 decoding in the meanwhile? I thought it only supports 5.1? Not sure, though. Either way, eac3to extracts the AC3 core of that 7.1 track and decodes only that. The E-AC3 channel extension is stripped away, just like DTS-HD blocks are. This results in 25 seconds runtime...

Well, there is a problem : when using MPC it shows 45 seconds, but the time is moving too fast (although the sound plays fine).
So the bitrate is wrong.

@Madshi : I don't know how you calculate 1662, I have followed libavcodec EAC3 parser code and on the first frame I get :
number of blocks : 1 (is wrong ?)
frame size : 620 (is wrong ?)
sample rate : 48000 (OK)
=> bit_rate=(uint32_t)(8.0 *frame_size * sample_rate /
(num_blocks * 256.0)) = 732.000
But the EAC3 decoder calculates 930000

Weird...

Anyway, the sound plays fine, so I guess that there is a beginning of 7.1 support on EAC3

nautilus7

14th October 2008, 19:25

@ madshi, albain

the sample is 7.1 from hd dvd. No ac3 core, but it has 2 sub frames per audio frame, as for every track of its kind (madshi explained that a lot time ago). Maybe that causes the wrong bitrate detection. libavcodec doesn't decode 7.1 yet.

nautilus7

14th October 2008, 21:05

Only remaining bug (from the ones i found) from the previous builds is the channel mapping for 7.1 TrueHD. Now the channel order is like it was initially with 7.1: L,R,C,LFE,SL,SR,BL,BR. You should remap the back with the side channels: L,R,C,LFE,BL,BR,SL,SR.

For 5.1 is ok and there's not a single 6.1 track for testing, so we can't tell.

That last bug fixed, i think you could send it out for public testing. Thanks for the hard work.

Snowknight26

15th October 2008, 03:31

Can't confirm if this happens in the latest build, but in 2147, playing an audio cd (32-bit PCM) with ffdshow set to 'all supported' under Uncompressed will either make the CD unplayable (MPC) or there will be no sound outputted then the track will eventually skip to the next one after 10 seconds or so. (WMP, even though the volume bars in the config pane show it being played).

ACrowley

15th October 2008, 08:01

albain

15th October 2008, 08:30

I get skipping/silence/strange noise etc when i jump/seek bigger steps inside m2ts Files with TrueHD from Bluray. Same Problme when i change the AudioTrack and switch back to trueHD.

I have this on all my Bluray m2ts Files in any Player (latest Gabest MPC MpegSplitter)

This is what I feared : the problem with TrueHD is that not all the frames have a sync word. So as long as you play the file normally, no problem. But if you skip to another position in the file, then it is difficult to know where we are : in a middle of a truehd frame with a sync word, a non major truehd frame, or an AC3 frame interweaved ?
The only solution (I think) is to detect when there is a skipping :

@clsid, haruhiko, xxl : how do we detect this in FFDShow ?

and then when this happens, scan for a complete AC3, TrueHD major frame or else throw the bytes away.

About the second issue : when you switch of audio stream, FFDShow should be reloaded right ? The problem should not occur. Maybe a bug with the splitter

madshi

15th October 2008, 09:18

Well, there is a problem : when using MPC it shows 45 seconds, but the time is moving too fast (although the sound plays fine).
So the bitrate is wrong.

@Madshi : I don't know how you calculate 1662, I have followed libavcodec EAC3 parser code and on the first frame I get :
number of blocks : 1 (is wrong ?)
frame size : 620 (is wrong ?)
sample rate : 48000 (OK)
=> bit_rate=(uint32_t)(8.0 *frame_size * sample_rate /
(num_blocks * 256.0)) = 732.000
But the EAC3 decoder calculates 930000

Weird...

Anyway, the sound plays fine, so I guess that there is a beginning of 7.1 support on EAC3
With 7.1 E-AC3 tracks (from both HD DVD and Blu-Ray) there's one audio frame for 5.1 (which is AC3 for Blu-Ray and E-AC3 for HD DVD) and another one (always E-AC3) for the remaining channels. So you need to add up the bitrate for both frames to get the correct final bitrate.

But honestly, I don't think you really need to care much. The only 7.1 E-AC3 tracks we got are from demo discs. I don't know a single movie HD DVD or Blu-Ray E-AC3 track which has more than 5.1 channels.

Jeremy Duncan

15th October 2008, 09:22

ACrowley

15th October 2008, 10:18

This is what I feared : the problem with TrueHD is that not all the frames have a sync word. So as long as you play the file normally, no problem. But if you skip to another position in the file, then it is difficult to know where we are : in a middle of a truehd frame with a sync word, a non major truehd frame, or an AC3 frame interweaved ?
The only solution (I think) is to detect when there is a skipping :

@clsid, haruhiko, xxl : how do we detect this in FFDShow ?

and then when this happens, scan for a complete AC3, TrueHD major frame or else throw the bytes away.

About the second issue : when you switch of audio stream, FFDShow should be reloaded right ? The problem should not occur. Maybe a bug with the splitter

yes...when playing the File with thd without seeking = no Problems. Perfect Playback :)

albain

15th October 2008, 10:44

nautilus7

15th October 2008, 11:16

Tested beta21.

Nothing changed for 1) and 3).
How to test 2)? The splitter show only one audio track for TrueHD/AC3, i can't switch.

ACrowley

15th October 2008, 11:18

I have made 2 builds for the following purpose : decide how to fix the remaining issues :
1/ Incorrect channel mapping on 7.1 TrueHD (both builds have the same behaviour)
2/ Switching stream in a TrueHD file : build beta20 resets the parser. This results in a codec switch. It may revert back to AC3 then to MLP again. This build should work when you switch the stream from the parser (but again, FFDShow audio should be resetted, there is a bug in the parser).
About beta21, it does not reset the parser but only tells him to look for a sync frame. It results on a non codec switching (so a smoother playback)

3/ Skipping in MLP/TrueHD file : beta21 & beta20 should solve the problem but beta21 should be better on this issue.
I tested it but I am pretty sure that there is a bug in MPC : when you do a skip, MPC looses the position in the file.

Here are the 2 builds :
Beta 20 (http://rapidshare.com/files/154191552/ffdshow_rev2217_20081015_dbt_beta20.exe.html)

Beta 21 (http://rapidshare.com/files/154191553/ffdshow_rev2217_20081015_dbt_beta21.exe.html)

THX

Build 21 :

After seeking TrueHD m2ts, the Sound is skipping, some strange noise, but THD decoding is coming back after a few seconds. But not with all my m2ts Files. Only in remuxed. Untouched m2ts from bluray doesnt work after seeking.
Audioswitching still ends up in strange noise. THD isnt coming back

Ah, the THD seeking Problem exist in all Dshow Players...not only in MPC. But all Player use MPC MpegSplitter ofcourse. I use KMPlayer and zoomplayer. Same Problem in graphedit

clsid

15th October 2008, 11:24

Somebody told me that the ffdshow now has better support for sse3.
When was the last update made for sse3 since I can't access the svn to look for myself?
What built was it if it was a sse3 update build?
It does not contain sse3, it does have some ssse3. Sse3 and sse4 are pretty much useless for the stuff that ffdshow does.

dom_b

15th October 2008, 14:00

i downloaded this build...

http://rapidshare.com/files/153932360/ffdshow_rev2217_20081014_dbt_beta19.exe.html

and tried decoding e-ac3 5.1 audio wrapped in an mkv and it worked like a charm. this looks like a great update! will this be incorporated into the main ffdshow builds soon? keep up the good work!

albain

15th October 2008, 14:33

Last build ? I hope. Match to FFDShow revision 2220

There was a bug in the 8 channels switch (in fact the code did not exist in mplayer, so I added it).

Beta 22 (http://rapidshare.com/files/154245908/ffdshow_rev2217_20081015_dbt_beta22.exe.html)

This build fixes the wrong channel mapping.

About the seeking problem, there is nothing I can do about it : the problem comes from the splitter which looses itself (it doesn't know its position).

Anyway, with those last changes, seeking in TrueHD files should work in FFDShow once the splitter will be fixed.
About this, I keep the beta20 changes which avoid codec switching (instead of beta21 that resets the parser and would give MLP->AC3->MLP codec switch).

ACrowley

15th October 2008, 14:46

nautilus7

15th October 2008, 18:07

SeeMoreDigital

15th October 2008, 18:10

Sorry to bring you bad news, bad beta22 won't be the last build. TrueHD 7.1 channel mapping is still wrong. It is the same once again. Nothing changed.What source are you using again?

nautilus7

15th October 2008, 18:23

m2ts with 7.1 truehd from dolby demo disc. I compare channel mapping with eac3to output.

STaRGaZeR

15th October 2008, 19:09

An observation: when playing PCM tracks, bitrate is always reported as 0. This should be very easy to fix/add.

albain

15th October 2008, 22:10

Sorry to bring you bad news, bad beta22 won't be the last build. TrueHD 7.1 channel mapping is still wrong. It is the same once again. Nothing changed.

Why the name of the setup file says 2217 if it's revision 2220?

OK, I made a mistake in the code.
I hope that this one will be okay :

Beta 23 (http://rapidshare.com/files/154378319/ffdshow_rev2127_20081015_dbt_beta23.exe.html)

An observation: when playing PCM tracks, bitrate is always reported as 0. This should be very easy to fix/add.

This problem has always existed

Concerning the revision number, this is a typo, also in the last beta 23

nautilus7

15th October 2008, 22:29

Still no change with 7.1 truehd channel order. Same thing always. :(

STaRGaZeR

15th October 2008, 22:58

This problem has always existed

Yes, that's why it'd be nice to fix it :p

lych_necross

16th October 2008, 07:05

albain

16th October 2008, 07:57

It would be great to have a 8 channels TrueHD sample with a voice saying each channel separately.

Is it possible ?

tal.aloni

16th October 2008, 09:48

It would be great to have a 8 channels TrueHD sample with a voice saying each channel separately.

Is it possible ?

I have such sample (from the Dolby Demo disc),
I can upload it by evening.

albain

16th October 2008, 10:22

I have such sample (from the Dolby Demo disc),
I can upload it by evening.

Good, thank you

Still no change with 7.1 truehd channel order. Same thing always. :(
Are you sure about the still wrong channel order ?
I have tested the sample I have with the following method :
- Converted TrueHD 7.1ch 48KHz cut.m2ts to 8 channels wav with eac3to
- Played both 8 channels wav and m2ts by remapping side left side right channels with FFDShow mixer to left/right (I don't have any 8 channels setup) and switched off other channels and compared the sound : sounds similar.
Same test when remapping back left back right to left/right.
Though it is not easy with those samples to be sure

dom_b

16th October 2008, 10:33

Is there another link for beta 23 as rapidshare keeps saying my session has expired even though it hasn't!?!

albain

16th October 2008, 10:47

Here it is, no limit on this one :

http://damienbt.free.fr/ffdshow_rev2220_20081015_dbt_beta23.exe

dom_b

16th October 2008, 10:55

great, thanks for that!

tal.aloni

16th October 2008, 12:54

Albain,
I sent you a PM containing the download link to the TrueHD 7.1 channel test.

I haven't tested the channel mapping myself,
I'll do so in the evening.

Tal Aloni

albain

16th October 2008, 14:41

Thank you for your sample.

I found the problem : a silly bug.

Now 8 channels remapping is correct with TrueHD

I will perform a merge from the trunk and make this final build (for sure this time)

PS : I also added a new functionality (on the trunk this time), i.e. tag support in subtitles.

Until now, srt and ssa files were treated separately : with HTML tags from one side on SRT (<i>, <b>, <font...>...) and with SSA tags on SSA format ({\pos...). But today we can find both tags in both formats, I mean HTML tags in SSA files, and SSA tags in subtitle files. This is the reason why you will see 2 versions sometimes when you download subtitles : TAG, NOTAG
Now, this is merged into one format (but still 2 source parsers of course) in order to have both tags format managed

SeeMoreDigital

16th October 2008, 15:14

I have such sample (from the Dolby Demo disc),
I can upload it by evening.May I have this sample too please?

tal.aloni

16th October 2008, 15:58

I made a 27 seconds sample to demonstrate what's wrong with ffdshow Normalization (max amplification 400%, buffer: 512).
The sample was created using GraphEdit > WavDest, no other unnecessary filter / setting was selected.
This is the beginning of "Iron Man" Trailer, listen closely to the distortion in the Center channel when ffdshow normalize.
when AC3Filter's One-Pass Norm is used, it is distortion-free. (2.6db gain ultimately)

http://iknowu.net/files/public/ffdnorm-selection.flac
http://iknowu.net/files/public/ac3norm-selection.flac

MPC has One-Pass Normalization implemented as well,
under the Audio settings tab, it has a "Regain Volume" check box, which is exactly what I suggest for ffdshow, in order to implement the requested feature ("Regain Volume" unchecked) as well as keeping existing functionality. ("Regain Volume" checked)

clsid, albain, I would love to hear your thoughts about this requested feature.
do you agree that ffdshow has a place for such a feature?
do you think you can spare some time to implement this future? (I would greatly appreciate it)

I must stress again that the current normalization implementation is of low value. (no offence)

Thanks,
Tal Aloni

albain

16th October 2008, 18:35

Here is the last build of the libavformat branch. I have performed a merge from the trunk, so in the future a merge from the branch to the trunk should be easier

Here is the link :

Beta 23 (http://rapidshare.com/files/154639962/ffdshow_rev2222_20081016_dbt_beta23.exe.html)

CruNcher

17th October 2008, 02:32

Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 49,3 MiB
Duration : 1min 20s
Overall bit rate : 5 154 Kbps

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.2
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Duration : 1min 19s
Bit rate mode : Variable
Bit rate : 5 092 Kbps
Maximum bit rate : 9 441 Kbps
Width : 1 280 Pixel
Height : 720 Pixel
Display aspect ratio : 16/9
Frame rate mode : Constant
Frame rate : 59,952 FPS
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.092
Stream size : 48,6 MiB (99%)

CoreAVC = 163.7 fps
DivX = 148 fps
ffdshow = 65.6 (1 thread), 75.8 fps (3 threads), 74.4 (4 threads)

is it using ffmpeg-mt ? changelog says ffmpeg-mt was updated with 2119 this is your newest 2222 build

albain for what do you need a sample just add WMVA to the allowed fourcc for VC-1 :)

_xxl

17th October 2008, 06:12

is it using ffmpeg-mt ?
Soon I''ll release a test build for ffmpeg-mt trunk.

CiNcH

17th October 2008, 06:45

changelog says ffmpeg-mt was updated with 2119 this is your newest 2222 build
Later revision number but different branch ;) .

albain

17th October 2008, 09:33

[CODE]
albain for what do you need a sample just add WMVA to the allowed fourcc for VC-1 :)

Which is ?

CruNcher

17th October 2008, 09:34

Later revision number but different branch ;) .

oops :)

CoreAVC = 163.7 fps
DivX = 148 fps
ffdshow(2219 ffmpeg-mt) = 105.1 fps (3 threads)

not that bad :D

@albain
its the same as WVC1 just a pre release name for it WMVA = Winodws Media Video Advanced Profile

Q: But wait! Didn't WMP10 ship with a WMV Advanced Profile codec years ago?
A: Indeed it did. Microsoft began working on its implementation of WMV AP before VC-1 spec was finalized. That codec (FourCC: WMVA) shipped with WMP10 (Format SDK 9.5), but as final changes to the VC-1 spec were made, WMVA got out of sync with the official spec. Today WMVA is no longer VC-1 compliant and is generally considered deprecated.

_xxl

17th October 2008, 09:41

ffdshow(2219 ffmpeg-mt) = 105.1 fps (3 threads)
Try 8 threads.

Mercury_22

17th October 2008, 09:41

CruNcher

17th October 2008, 09:52

Try 8 threads.

with a Dual Core CPU ? anyway i tried it doesn't gets faster anymore :)

STaRGaZeR

17th October 2008, 10:06

That sounds good, _xxl a test version please :D

albain, with beta23 everything is working fine on my side, except that high pitch sound playing DVDs, which nobody seems to reproduce...

albain

17th October 2008, 10:19

Now can we have a 64-bit version too ? Please ! :thanks: :helpful:

Sorry, still the old same problem : I can't get my actual version of mingw cross compiler or binutils (x86_64-pc-mingw32-gcc) does not work.
I also can't get my hand on a previous version (the same as 32 bits version which works)

EDIT : I have built a new 64 bit version anyway. With some luck it will work, else I will try to compile ffmpeg with Visual studio but the performances will suffer.

FFDShow new audio codecs 64 bits beta (http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta.exe)

Inventive Software

17th October 2008, 11:26

Note on the WMVA/VC-1 issue: The bitstreams between WMVA and WVC1 are different. However if it is feasibly possible, allowing Microsoft decoders only to decode it, instead of libavcodec, would IMHO ensure full compatibility at this stage. I will raise the issue with libavcodec/ffmpeg developers to see what the score really is. Expect an update probably this weekend. :)

CruNcher

17th October 2008, 12:07

If i remember correct the issue was only with Interlaced content ? so Progressive should be absolutely flawless Decoding with libavcodec :)

STaRGaZeR

17th October 2008, 12:53

FFDShow new audio codecs 64 bits beta (http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta.exe)

libav AC3, EAC3, DTS, Vorbis crash. liba52 and libdts working.

libav MP3, MP2, MLP, FLAC, TTA working too.

Video libav working too.

Mercury_22

17th October 2008, 13:26

libav AC3, EAC3, DTS, Vorbis crash. liba52 and libdts working.

libav MP3, MP2, MLP, FLAC, TTA working too.

Video libav working too.

I can confirm that :(

haruhiko_yamagata

17th October 2008, 13:49

with a Dual Core CPU ? anyway i tried it doesn't gets faster anymore :)
Because ffmpeg-mt is frame based multithreading.

Frame A, B and C are decoded in thread A, B and C. Frame B is dependent on frame A, in other words frame B references frame A.
The first steps are CABAC/CAVLC and IDCT for both A and B. These steps can be done independently thus thread A and B can work parallelly. Next step is prediction which requires reference frames. If the picture A is not available in thread B and being decoded in thread A, thread B has to wait for thread A.
Here one core is free, thus you can decode frame C in thread C.
(If I understand correctly.)

If you use more threads, %CPU usage would rise. Too many threads will mess up the memory cache.

bbc-japan_1080p.mov (http://images.apple.com/movies/us/hd_gallery/gl1800/1080p/bbc-japan_1080p.mov).
ffdshow + ffmpeg-mt
(number of decoding threads)User: ...
(1)User: 185s, kernel: 0s, total: 185s, real: 186s, fps: 41.1, dfps: 40.8
(2)User: 13s, kernel: 0s, total: 13s, real: 106s, fps: 548.4, dfps: 71.5
(2)User: 13s, kernel: 0s, total: 13s, real: 106s, fps: 555.2, dfps: 71.6
(2)User: 14s, kernel: 0s, total: 14s, real: 106s, fps: 537.5, dfps: 71.6

(3)User: 14s, kernel: 0s, total: 14s, real: 104s, fps: 511.0, dfps: 72.6
(4)User: 14s, kernel: 0s, total: 14s, real: 106s, fps: 535.7, dfps: 71.8
(5)User: 13s, kernel: 0s, total: 13s, real: 104s, fps: 547.1, dfps: 73.0
(6)User: 14s, kernel: 0s, total: 14s, real: 104s, fps: 515.3, dfps: 72.6

(7)User: 15s, kernel: 0s, total: 15s, real: 104s, fps: 495.4, dfps: 73.1
(8)User: 13s, kernel: 0s, total: 13s, real: 104s, fps: 554.6, dfps: 72.8

ffdshow_rev2210_20081012_clsid.exe
(2)User: 171s, kernel: 0s, total: 171s, real: 175s, fps: 44.3, dfps: 43.4
I didn't have time to see if these results are statistically significant :p .
Probably 3 or 4 is good for use in real application.
Please note that I have chosen the sample file which show the maximum effect of ffmpeg-mt. Not all files are accelerated like this.

//EDIT
Core2duo E6700 2.66GHz

_xxl

17th October 2008, 14:52

Test build from ffmpeg-mt trunk:
http://rapidshare.com/files/154890409/ffdshow_rev2227_20081017_mt.exe.html

CiNcH

17th October 2008, 15:45

Test build from ffmpeg-mt trunk
Nice!! Check here (http://www.dvbviewer.info/forum/index.php?showtopic=29657&st=0#entry217361). 720p live streams (ORF 1 HD, arte HD) somehow crash ffdshow. Recorded streams from the same channels work fine.

CruNcher

17th October 2008, 18:02

@_xxl

CoreAVC = 163.7 fps
DivX = 148 fps
ffdshow(2227 ffmpeg-mt) = 112.2 fps (3 threads)

:)

albain

17th October 2008, 18:26

@_xxl

CoreAVC = 163.7 fps
DivX = 148 fps
ffdshow(2227 ffmpeg-mt) = 112.2 fps (3 threads)

:)

Very nice

Good job !

CiNcH

17th October 2008, 19:04

Nice!! Check here. 720p live streams (ORF 1 HD, arte HD) somehow crash ffdshow. Recorded streams from the same channels work fine.
Now it works for live with 720p. I am doing an in-depth video format detection now when switching channels. So the correct information (resolution a.s.o.) is now propagated through the video pin which ffdshow seems to need in case of 720p (think that if video detection is disabled some standard default values are propagated which work for 1080i). Think it worked with pre ffmpeg-mt builds. Maybe ffdshow previously used SPS/PPS to configure the decoder library?

Congrats and thanks again to Haruhiko who is doing a lot for the ffdshow video decoder nowadays! And also to those who worked out multithreading for ffmpeg!

tal.aloni

17th October 2008, 20:16

haruhiko_yamagata, clsid, albain,

I have some experience with C#, and after some struggle, I was able to add "One pass Normalization" to the project successfully. I tested it as well, and it's adding the necessary functionality, without hurting existing one.
you can see the new combo box at:
http://iknowu.net/files/public/ffdshow/ffdshow-OnePassNorm.png

1. I want to merge my changes to the SVN (quite a few, actually), how do you prefer me to do it?

2. When I inspected the current code, I realized why the "Regain Volume" normalization (the current one) result in distortion:
the normalization coefficient is calculated based on average volume instead of maximum volume, this must be a mistake, and I highly recommend changing that.

3. I got explanation to another wierd phenomenon:
current normalization is not enforced on the first samples, and that's what causing the volume to drop sharply in the beginning of videos.
again, I did not modify this for the "Regain Volume" normalization, but I suggest doing so.

p.s. I was missing dinput.lib when I compiled the project for the first time. it is not supplied with the latest DirectX SDK / Platform SDK, but I was able to get from the internet, I hope this is the right version, here is a copy:
http://iknowu.net/files/public/dinput.lib

Thanks,
Tal Aloni

clsid

17th October 2008, 21:12

Create .patch files. Preferably one for each functional change. Upload them somewhere so they can be reviewed. And may be upload a build for the hardcore testers here.

haruhiko_yamagata

17th October 2008, 23:31

Maybe ffdshow previously used SPS/PPS to configure the decoder library?No, ffdshow just send width and height that are given from the splitter in media type. libavcodec did not crash if ffdshow set wrong value.

For 1980x1088 samples, Haali's Media Splitter says 1980x1080. ffdshow crashed without the custom code that I added at rev 2226.
I sent the patch to author and he sent back better patch. So the fix will be soon :) .

tal.aloni

18th October 2008, 00:29

clsid, thanks.

I've created a patch for each file using WinMerge,
I've included the complete files as well,
changes are based on revision 2228.
the only change is the addition of One-Pass Normalization,
which activates when a new checkbox in the volume tab, labeled "Regain Volume", is unchecked.

http://iknowu.net/files/public/ffdshow/ffdshow-2228-OnePassNorm-RC3.zip

I've tested this build thoroughly, the improvement in sound quality over the existing "DRC"-like method ("Regain Volume" checked), is very noticeable.

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-OnePassNorm-RC3.exe

I'm very proud of the result :D
Thanks,
Tal Aloni

Leak

18th October 2008, 11:35

http://iknowu.net/files/public/ffdshow/ffdshow-2228-OnePassNorm-RC3.zip

I'm afraid that style of patch is not very helpful unless you apply it to the exact same version of the code you made it from, because there's no context information in case the line numbers have changed... :(

I'd suggest redoing your patch with the style set to "unified" and a context of at least 5. And, unless I'm reading your patch files wrong, some of them were reversed... (not much of a problem with unified diffs as you can always reverse-apply them, but I'm not sure if that's possible with plain diffs...)

Also - you can create a single patch file for all changed files with WinMerge if you compare two directories, select the files in the list and then hit "Generate patch"... there's no need to create a diff for every file.

Just my 0.02 EYPO... :)

np: Sigur Rós - Glósóli (Takk...)

tal.aloni

18th October 2008, 12:00

Thanks for helping out, I made a new patch based on the above suggestions. (one file, correct order)

http://iknowu.net/files/public/ffdshow/ffdshow-OnePassNorm-RC3-Patch.zip

Tal Aloni

haruhiko_yamagata

18th October 2008, 13:50

tal.aloni

18th October 2008, 14:06

Thanks,
It was easier to implement than I expected,
the project is well maintained and well documented, kudos.

p.s.
ffdshow's "normalization" is not normalization at all, it would be more correct to change the checkbox title to "auto volume control", but that's just semantics, and totally up to you.

Tal Aloni

albain

18th October 2008, 16:08

Here is another 64 bits build of the new audio codecs branch, I disabled MMX optimizations that make libavcodec crash with some codecs (AC3, DTS....).

It should doing fine now :

FFDShow 64 bits beta (new audio codecs) (http://rapidshare.com/files/155223158/ffdshow_rev2222_20081016_x64_dbt_beta.exe.html)

STaRGaZeR

18th October 2008, 17:09

No luck, it doesn't crash but no sound/distorted sound with libav.

albain

18th October 2008, 17:21

No luck, it doesn't crash but no sound/distorted sound with libav.

Sound problem occurs with TrueHD only or with AC3/EAC3/DTS/TrueHD decoders ?

This is weird, I don't know anything I could do about it, this is likely a ffmpeg bug with 64 bits.

I will try to dig this around and eventually post a new version with libavcodec compiled with MSVC

albain

18th October 2008, 17:46

I managed to make it work on my vista 64 environment.

Here are 2 builds:

http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta_MINGW.exe

http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta_MSVC.exe

First build, libavcodec has been compiled under MINGW, so it has better performances

Second build, libacodec compiled under MSVC.

Second build is working for me (AC3 output enabled, resampling always to 48Khz, channels remapped to 3/0/2). I guess it should work with other modes.

Please report which builds are (not) working

tal.aloni

18th October 2008, 18:32

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), when checked, the current functionality is remained, when unchecked, only videos marked as interlaced are being interlaced. very convenient.
(http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1.PNG)

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

Source(Patch & Complete Files): (EDIT: Fixed Link)
http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1-Patch.zip

p.s. perhaps there is a better way to implement it, I just added an "if" section to each deinterlacer.

Tal Aloni

Mercury_22

18th October 2008, 18:40

DigitalDeviant

18th October 2008, 18:46

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), when checked, the current functionality is remained, when unchecked, only videos marked as interlaced are being interlaced. very convenient.
(http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1.PNG)

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

Source(Patch & Complete Files):
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

p.s. perhaps there is a better way to implement it, I just added an "if" section to each deinterlacer.

Tal Aloni

Does this affect hardware deinterlacing (setting the flag in the outboud stream) or is it only for internal ffdshow deinterlacing?

albain

18th October 2008, 18:47

Thanks for your effort :thanks: Tested E-AC3;AC3;DTS
1.DTS not working in both
2.MING it's not working just noise (sounds like very boosted sound ?!:scared:)
3.MSVC it's working just for EAC3 and AC3

I did not test DTS, but what about TrueHD decoding (it works on my side with the last build of MPC Home Cinema and m2ts samples on this forum) ?

STaRGaZeR

18th October 2008, 18:48

libav MP3, MP2, MLP(TrueHD), FLAC, TTA work in all betas.

In your very first beta there were problems with: libav AC3, EAC3, DTS and Vorbis. Let's see:

MSVC beta: everything works except DTS (distorted sound). libdts working. Don't know about EAC3 (no samples).

MINGW beta: AC3 distorted sound, DTS no sound, Vorbis crashes. liba52, libdts and tremor working instead. Can't test EAC3.

Maybe is a fault of the splitter, only MPC available in x64 for both Matroska and (m2)ts. They are really bad in x64, we need Haali :(

The difference in perfomance is big, Blu-ray is unplayable with the MSVC beta and a E8400@4GHz.

tal.aloni

18th October 2008, 18:53

Does this affect hardware deinterlacing (setting the flag in the outboud stream) or is it only for internal ffdshow deinterlacing?

it is only for internal ffdshow deinterlacing.
if you deinterlace using ffdshow, then you shouldn't set the flag in the outboud stream.
if you deinterlace using your hardware, then the flag should be set, and ffdshow's deinterlacing should be disabled.

DigitalDeviant

18th October 2008, 19:01

it is only for internal ffdshow deinterlacing.
if you deinterlace using ffdshow, then you shouldn't set the flag in the outboud stream.
if you deinterlace using your hardware, then the flag should be set, and ffdshow's deinterlacing should be disabled.

Yes, that's how I do it but I have issues with hardware deinterlacing (Ati HD3650). If there is progressive material mixed in with the interlaced I get really bad jerkiness.

tal.aloni

18th October 2008, 19:03

Yes, that's how I do it but I have issues with hardware deinterlacing (Ati HD3650). If there is progressive material mixed in with the interlaced I get really bad jerkiness.

Me too (Radeon x700), That's why I use software deinterlacing, and that's why I developed this feature, so deinterlacing will be active only when really needed.

DigitalDeviant

18th October 2008, 19:10

Me too (Radeon x700), That's why I use Software deinterlacing, and that's why I developed this feature, so deinterlacing will be active only when really needed.

Can't the output stream flag be set up to change automatically change if the interlace flag is set in the input stream?

Also, what software deinterlacer do you use? I haven't found one that even comes close to the vector adaptive deinterlacer of my Ati card.

tal.aloni

18th October 2008, 19:25

Can't the output stream flag be set up to change automatically change if the interlace flag is set in the input stream?

it does.
the reason that's you've got that jerkiness, is because hardware deinterlace does not always work well. (I think that sometimes it tries 3:2 pulldown, when the content is actually 29.97fps)

Also, what software deinterlacer do you use? I haven't found one that even comes close to the vector adaptive deinterlacer of my Ati card.

Linear blending, but I haven't experimented enough.
EDIT:
Linear interpolation seems to do a better job at some clips, but I guess every deinterlacer has it's strong territory.

DigitalDeviant

18th October 2008, 19:43

it does.
the reason that's you've got that jerkiness, is because hardware deinterlace does not always work well. (I think that sometimes it tries 3:2 pulldown, when the content is actually 29.97fps)

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?

Edit: It kinda looks like it could be the wrong field order is set. Could this happen?

Linear blending, but I haven't experimented enough.

Linear blending is too blurry for me, not that I would expect it not to be. However, it is the one that I get the least amount of artifacts from. I've tried the descaler filters and a few avisynth deinterlace filters but I couldn't get good results and realtime playback.

_xxl

18th October 2008, 19:44

First build, libavcodec has been compiled under MINGW, so it has better performances
Could that asm from ffmpeg is "broken" when compiling MinGW GCC 64 builds? No Win64 support?

MatMaul

18th October 2008, 19:52

Can't the output stream flag be set up to change automatically change if the interlace flag is set in the input stream?
+1 it would be good to have an "auto" option in the output tab which use weave (no deinterlacing) or bob according to the interlaced flag given by libavcodec.

tal.aloni

18th October 2008, 20:29

+1 it would be good to have an "auto" option in the output tab which use weave (no deinterlacing) or bob according to the interlaced flag given by libavcodec.

Guys, That's what already happen!

littleD

18th October 2008, 20:37

Finally.. Big :thanks: for implementing that feature Tal oni. Just call it simplier:p
Anyway, i didnt found useful any of deinterlacing method that ffdhow provide. I there any chance to implement yadif deinterlacing? Is it even possible?

BTW, many new features into ffdshow are coming, keep doing nice work guys.

Inventive Software

18th October 2008, 20:39

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), when checked, the current functionality is remained, when unchecked, only videos marked as interlaced are being interlaced. very convenient.
(http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1.PNG)

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

Source(Patch & Complete Files):
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

p.s. perhaps there is a better way to implement it, I just added an "if" section to each deinterlacer.

Tal Aloni

I have been waiting for this for a long time. I will test it later on. :)

MatMaul

18th October 2008, 20:54

Guys, That's what already happen!
no when I mean in the output tab I speak about the "set interlace flag in output media type" (aka hardware deinterlacing)

Reimar

18th October 2008, 21:27

Could that asm from ffmpeg is "broken" when compiling MinGW GCC 64 builds? No Win64 support?

I don't think any of the developers have a MinGW64 setup, so it certainly was never tested.
If there is a simple "just run the installer" way to get MinGW64 I might try, most likely there are issues if MinGW gcc64 considers "long" as only 32 bit, FFmpeg assumes "long" is native pointer size (though if that is the issue I wonder how it could compile at all, it should fail...).

clsid

18th October 2008, 21:55

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

Just unzip the file and you are pretty much done. Of course you would need to add the bin dir to your path environment variable. And set 'CC' to 'gcc'.

DigitalDeviant

18th October 2008, 23:04

no when I mean in the output tab I speak about the "set interlace flag in output media type" (aka hardware deinterlacing)

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.

albain

18th October 2008, 23:04

I don't think any of the developers have a MinGW64 setup, so it certainly was never tested.
If there is a simple "just run the installer" way to get MinGW64 I might try, most likely there are issues if MinGW gcc64 considers "long" as only 32 bit, FFmpeg assumes "long" is native pointer size (though if that is the issue I wonder how it could compile at all, it should fail...).

Yes I do, I set up a Vista 64 on my 2nd HDD only for testing FFDShow 64, otherwise I don't use it.

Disabling the MMX methods made the crash disappeared, but for an unknown reason now we don't get the same results under mingw and msvc

This problem (crashing) has been met with 32 bits version of FFDShow. xxl and clsid figured out that it came from the version of binutils (plus the version of GCC that counts). But there are not the same versions for 64 bits (all are newer).

This is by using gdb under my Vista 64 set up that I figured out the origin of the problem : mmx functions of libavcodec.

However, if this does not crash anymore, this is another problem.

You guys should also try the same samples with mplayer (compiled under 64 bits), if you get the same results then the problem does not come from FFDShow (I doubt it is) : either the 64 bits splitter of ffmpeg.

tal.aloni

19th October 2008, 00:08

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

19th October 2008, 00:49

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

19th October 2008, 00:53

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

19th October 2008, 01:26

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

19th October 2008, 01:42

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

19th October 2008, 01:44

DigitalDeviant

19th October 2008, 03:23

_xxl

19th October 2008, 07:51

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

_xxl

19th October 2008, 07:57

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

19th October 2008, 10:57

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

19th October 2008, 12:33

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

19th October 2008, 12:58

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

19th October 2008, 13:05

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

19th October 2008, 13:20

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

19th October 2008, 13:39

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

19th October 2008, 14:02

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

19th October 2008, 14:37

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

19th October 2008, 14:39

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

19th October 2008, 14:59

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

19th October 2008, 15:09

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

19th October 2008, 15:33

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

19th October 2008, 16:16

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

19th October 2008, 16:49

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

19th October 2008, 16:51

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

19th October 2008, 19:23

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

19th October 2008, 20:27

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

19th October 2008, 20:44

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

19th October 2008, 21:23

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

19th October 2008, 21:35

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

19th October 2008, 21:49

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

19th October 2008, 22:01

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

19th October 2008, 22:33

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

19th October 2008, 22:55

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

19th October 2008, 23:03

* 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

19th October 2008, 23:08

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

19th October 2008, 23:15

(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

19th October 2008, 23:26

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

19th October 2008, 23:27

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

19th October 2008, 23:34

tal.aloni

19th October 2008, 23:40

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

20th October 2008, 08:08

tal.aloni

20th October 2008, 08:43

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

20th October 2008, 08:59

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

20th October 2008, 11:58

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

20th October 2008, 12:15

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

20th October 2008, 12:17

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

MatMaul

20th October 2008, 12:35

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

20th October 2008, 12:45

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

20th October 2008, 12:52

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

20th October 2008, 16:18

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.

albain

20th October 2008, 16:28

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.

The problem comes from the libavcodec AC3 parser, which is buggy, and not useful because I already parse AC3 frames internally. Disabling it resolves this issue.

Here is an updated build (different from the official build on sourceforge) :
http://damienbt.free.fr/ffdshow_rev2239_20081020_dbt_new_audio_codecs.exe

tal.aloni

20th October 2008, 16:49

Here is an updated build (different from the official build on sourceforge) :
http://damienbt.free.fr/ffdshow_rev2239_20081020_dbt_new_audio_codecs.exe

Awesome!
Thanks for taking the time for an updated merge,
I can now enjoy my mixed playlist without changing codecs / deinterlace settings / volume all the time! peace, at last! :thanks:

madshi

20th October 2008, 17:01

The problem comes from the libavcodec AC3 parser, which is buggy, and not useful because I already parse AC3 frames internally. Disabling it resolves this issue.
Do you have any libav parsers left? Getting rid of all of them would of course allow you to also get rid of the complete libavformat package... :)

Amour

20th October 2008, 17:10

Little joke for Albain:
I've tested your new build, but it can't play any sound! I've done a sample with TechSmith ...

STaRGaZeR

20th October 2008, 17:25

tal.aloni

20th October 2008, 18:39

@tal.aloni
I've one question regarding some R1 DVDs I've here and ffdshow+libmpeg2+hardware deinterlacing. There are two possible scenarios:

- The video is 29,97 interlaced --> ffdshow flags it has interlaced and the video gets deinterlaced correctly, 59.96fps.

I guess you use bob deinterlacing and making a frame out of each field. if you have the CPU power, that's the way to go for this type of content.

- The video is 23,976 progressive with a 3:2 soft pulldown --> ffdshow flags it has interlaced, and the resulting fps are 47,96fps. The video is wrong, it get's deinterlaced when there is nothing to deinterlace. Some artifacts and bliking lines can be seen in letters for example. It's possible to do the IVCT process inside ffdshow and feed the renderer with pure progressive frames?

It's not ITCV if the source is progressive, it's just a matter of ignoring the flags.
Since you directed the question to me, I went out of my way and encoded a 23.976 video, and added pulldown flags.

I'm using the latest build, and it seems that haruhiku yamagata had already done something in regard:

Author: h_yamagata
Date: Mon Oct 20 13:04:50 2008 UTC (4 hours, 14 minutes ago)
Log Message: Import code from guliverkli by gabest.
libmpeg2: flag "progressive" if telecined film is detected.

I noticed something strange:
while the video reported as "progressive", and does not need deinterlacing, it's framerate reported incorrectly as 29.976. (playback time / speed is correct, but number of frames is not. strangely).

Edit:
by going frame by frame, I figured out the mystery, it just plays back the end of the video another time when it reaches the actual end.
Haruhiko, since you already familiar with the subject, can you look it up?

MatMaul

20th October 2008, 18:43

tal.aloni

20th October 2008, 21:04

I improved the normalization algorithm (Regain volume checked) a little bit:

+ now it does not tied to sampling rate or samples per call, (so it should act pretty much the same on files with different sampling / format / container)

+ I figured changing the Normalization checkbox title would be too radical for some, so I've stuck with "Normalization".

+ "Buffer Size" combo box was Removed. (the new algorithm doesn't use the buffer)

This Build is based on Albain's latest revision:
http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdshow_rev2239_20081020-NewAudioCodecsAndBetterNormalization-RC4.exe

Patch:
http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdshow-BetterNormalizationAlgorithm-RC4-Patch.zip

I think it's ready for prime time, maybe the coefficients will be modified slightly if requested,
but its already much better then the existing code.
http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdshow-BetterNormalizationAlgorithm-RC4-Patch.zip

p.s. if, unimaginably, we'll prefer to keep the existing mechanism,
I have a patch that fix an old bug: ffdshow does not crush anymore when buffer size decreased during playback.

STaRGaZeR

20th October 2008, 21:11

I guess you use bob deinterlacing and making a frame out of each field. if you have the CPU power, that's the way to go for this type of content.

Yes, CPU power is not a problem (is it in any modern computer? :p). The ATI cad does an excellent job here.

It's not ITCV if the source is progressive, it's just a matter of ignoring the flags.
Since you directed the question to me, I went out of my way and encoded a 23.976 video, and added pulldown flags.

I'm using the latest build, and it seems that haruhiku yamagata had already done something in regard:

I noticed something strange:
while the video reported as "progressive", and does not need deinterlacing, it's framerate reported incorrectly as 29.976. (playback time / speed is correct, but number of frames is not. strangely).

I'm using the last build posted by albain here (seems to be 2239) and it's still flagging film DVD material as interlaced, resulting in 47.96fps. So it ignores the pulldown flags, but the output flag is still interlaced and the videocard is still deinterlacing, clearly visible. Looks like MatMaul has figured it out.

BTW, when no deinterlacing is done playing the file results in this, the video goes in small jumps:

http://i33.tinypic.com/1p9ro0.png

If I use Avisynth - Smooth timestamps (in the 3:2 pulldown option) the line looks flat and the video plays with no jerks like it should be. Also if I strip the pulldown marks, perfect playback(obvious).

madshi

20th October 2008, 22:17

@ haruhiko_yamagata : thank you for the libmpeg2 interlaced code detection :)

but it seems to me that the SEQ_FLAG_PROGRESSIVE_SEQUENCE is not reliable : it is set to 0 in my lord of the ring DVD.
I take the specs and it seems that we should consider a frame as progressive if the PIC_FLAG_PROGRESSIVE_FRAME is set, even if the SEQ_FLAG_PROGRESSIVE_SEQUENCE isn't.
Here's what I figured out for MPEG2:

// progressive_sequence = 1 -> all frames are progressive; 0 -> can be everything
// picture_structure = 3 -> progressive or interlaced frame; 1-2 -> interlaced field; 0 -> reserved
// progressive_frame = 1 -> only allowed with "picture_structure = 3"; progressive; 0 -> interlaced
The problem is that with both broadcasting and DVD sources you can not rely on things staying constant. E.g. some parts of the movie can be encoded as progressive frames while other parts are encoded as interlaced frames or even fields. Furthermore some parts of the movie may contain pulldown flags while in other parts the pulldown may be hard coded into the stream (as double encoded fields/frames). Finally, even if a frame is flagged as progressive, it can actually be interlaced - and it's possible that the wrong interlaced fields were mixed together into this frame. Such bad stuff happens only rarely, but some DVDs are known to be incorrectly authored. So the safest bet is always to assume that the source is interlaced and to use a proper IVTC algorithm to match the separate fields. The only situation where you can rely on stability is if "progressive_sequence" is set (usually only the case for Blu-Ray sources) or for 1080i60 sources where you know their origin is HD DVD (those all have a regular and constant pulldown pattern).

fleon

21st October 2008, 04:55

Hi i have two problems with the x64 version of ffdshow this one ffdshow_rev2202_20081010_clsid_x64.exe, I have windows xp x64 and eventhought I have selected the tray icons to be displayed that doesnt happen with any video, and the second problem is that the xvid decoder doesnt work and maybe other decoders also doesnt work,

I know this because I tried to convert an xvid avi video and I got this error "render the file the filter graph won't talk to me" I searched for some answeres and installed graphedit and opened the video and it said that it could not find the decoder so I installed the xvid decoder fromn the koepi site and it worked,

So is there a workaround or something?

Thanks

_xxl

21st October 2008, 08:11

x64 is experimental so don't expect too much...

albain

21st October 2008, 08:16

haruhiko_yamagata

21st October 2008, 11:19

I'm using the last build posted by albain here (seems to be 2239) and it's still flagging film DVD material as interlaced,It's from different branch. Please try another build by tal.aloni.

Timestamps issue is another problem.

haruhiko_yamagata

21st October 2008, 11:42

tal.aloni

21st October 2008, 14:46

It's from different branch. Please try another build by tal.aloni.

In 2239, Albain merged the changed from the trunk up to 2238, so you're modification should be already implemented there.

I wouldn't understand what "Regain volume" is, if I was not reading this thread.
"Night mode" would be easier to understand, if it is not wrong.
What about this tooltip:

"Unchecked: one-pass normalization will be performed
(this mode is used to reach the highest possible loudness
with minimum of possible artifacts)

Checked: dynamic range compression will be performed, quieter parts will be
amplified more then louder parts (also known as night mode)."

Thanks,
Tal

MatMaul

21st October 2008, 14:52

here is a patch which allows to force bob and to force the field order in the output tab for hardware deinterlacing.
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.01.diff

haruhiko_yamagata

21st October 2008, 15:23

In 2239, Albain merged the changed from the trunk up to 2238, so you're modification should be already implemented there.No. In 2239, he merged up to 2235.

What about this tooltip:

"Unchecked: one-pass normalization will be performed
(this mode is used to reach the highest possible loudness
with minimum of possible artifacts)

Checked: dynamic range compression will be performed, quieter parts will be
amplified more then louder parts (also known as night mode)."

Thanks,
TalTool tip is good, but I still prefer to label it night mode.

Eragon4ever

21st October 2008, 15:48

I don't like the idea of "night mode". IMHO features should be named after what they do, not what they can be used for. That can be written down in the documentation (if there were any). With no documentation (or this thread in this case) I surely would not understand what "night mode" means.

tal.aloni

21st October 2008, 16:02

here is a patch which allows to force bob and to force the field order in the output tab for hardware deinterlacing.
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.01.diff

Bad choise of names, "AUTO" is very confusing.
IMO, it should be
"BOB",
"Weave",
"Forced BOB",
"Forced Weave".

tal.aloni

21st October 2008, 16:05

features should be named after what they do, not what they can be used for.

I agree, "Regain volume" is friendlier to the average user.
it's also used on Media player classic, so it would be more familiar.

albain

21st October 2008, 16:08

Why not adding a description in the tool tip ?

tal.aloni

21st October 2008, 16:09

Why not adding a description in the tool tip ?

I will do that anyway.

MatMaul

21st October 2008, 17:22

Bad choise of names, "AUTO" is very confusing.
IMO, it should be
"BOB",
"Weave",
"Forced BOB",
"Forced Weave".
force weave doesn't exist, if you choose weave you force to do not deinterlace anyway.
auto choose between bob (deinterlace) and weave according to the flags reported by the decoder so I think it is a good name.

fleon

21st October 2008, 17:52

Maybe you tried to play those with the 32 bits version of media player (the default icon of WMP points to 32 bits version) ?

I played it with Media player classic home cinema x64 edition, but there I can be sure if ffdshow is running since as I said I activated the tray icons are they dont appear, but I also activated the osd and that did appear so it seems that it is running , but why the tray icons are not displaying?

Also the error happened when I was going to convert a xvid avi video with megui I got the render file wont talk to me, then as I said I installed the xvid decoder from koepi's site and it worked, so I dont know maybe it is an error from megui.. but still the tray icons are not showing(look above)

tal.aloni

21st October 2008, 17:56

force weave doesn't exist

that's what I figured, what is this then: (your code) :)

+ // Force weave

auto choose between bob (deinterlace) and weave according to the flags reported by the decoder so I think it is a good name.

I'm sorry, but I'm confused, is Auto = what was "Bob" up until today?

STaRGaZeR

21st October 2008, 19:00

I'm sorry, but I'm confused, is Auto = what was "Bob" up until today?

Yes. BOB today checks if the source is progressive or interlaced and put the flags in consequence, you're not using only BOB. So AUTO is a good name for the actual BOB, because that's what it's doing.

Can anybody compile a test version with the lastest changes of haruhiko?

tal.aloni

21st October 2008, 19:29

Yes. BOB today checks if the source is progressive or interlaced and put the flags in consequence, you're not using only BOB. So AUTO is a good name for the actual BOB, because that's what it's doing.

OK, Thanks.
I think this 3 are more clear:
"AUTO BOB"
"ALWAYS BOB"
"WEAVE"

MatMaul

21st October 2008, 21:04

OK, Thanks.
I think this 3 are more clear:
"AUTO BOB"
"ALWAYS BOB"
"WEAVE"
I agree, here is the updated patch :
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.02.diff

tal.aloni

21st October 2008, 22:09

tal.aloni

22nd October 2008, 00:34

Can anybody compile a test version with the lastest changes of haruhiko?

xvidvideo.ru has posted build based on rev. 2240, (no russian needed).

STaRGaZeR

22nd October 2008, 02:31

xvidvideo.ru has posted build based on rev. 2240, (no russian needed).

Tested and it indeed puts the progressive flag, but now there is another problem: titles with film+video in the same stream. ffdshow detects the first, progressive, and when the second is reached (has to be deinterlaced) the flags are still progressive. I bet the same will happen when there is video first and then film, film will get deinterlaced. Below I've uploaded a funny MPEG-2 clip, extracted from a DVD. It has film content at the beginning, video at the end and most probably bad pulldown flags. Check the scene changes, specially when the pink haired girl appears.

http://www.megaupload.com/?d=MPMULDNV (21MB)

adam777

22nd October 2008, 09:23

Hello all,
First things first, I must say I've already posted the following in the feature request and open discussion forum sections of the sourceforge page, but it seems way more active in here.
I was wondering if it's possible to add revision number (e.g. 2228), for ffdshow.ax, under "Product Version", so one can track installed version, using software like SUMo (http://www.kcsoftwares.com/?sumo).
I know the information is presented in the registry, but I figured it might be possible to automate the compiling process (or something of that sort) and include the information in there also.
Thanks in advance, Adam.

haruhiko_yamagata

22nd October 2008, 09:52

I agree, here is the updated patch :
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.02.diffI can't accept your patch about TvideoCodecLibmpeg2.cpp.
Please read madshi's post (http://forum.doom9.org/showthread.php?p=1205181#post1205181) again.

As for deinterlacing methods, what about "Auto", "Force Bob", "Force Weave"?

tal.aloni

22nd October 2008, 10:12

I was wondering if it's possible to add revision number (e.g. 2228), for ffdshow.ax, under "Product Version"

1. ffdshow.ax contains version number already, Windows XP will show it only if you rename the extension to "dll".
(not sure it's properly maintained though)

2. you can always see the revision number in the "About screen". (decoder configuration)

madshi

22nd October 2008, 10:20

I know that this is a tall order, but do you video deinterlacing guys think that it would be possible to extract the IVTC deinterlacing solution implemented in the DScaler IVTC mod and make it work in ffdshow as a separate deinterlacer? That would be more than awesome cause this deinterlacing solution works extremely well for all my MPEG2 sources. But I guess it would be too much work because the IVTC deinterlacing code is interweaved with the DScaler decoder? So it's probably hard to extract? I have to admit that I don't know neither the ffdshow sources nor the DScaler sources...

haruhiko_yamagata

22nd October 2008, 11:01

Tested and it indeed puts the progressive flag, but now there is another problem: titles with film+video in the same stream. ffdshow detects the first, progressive, and when the second is reached (has to be deinterlaced) the flags are still progressive. I bet the same will happen when there is video first and then film, film will get deinterlaced. Below I've uploaded a funny MPEG-2 clip, extracted from a DVD. It has film content at the beginning, video at the end and most probably bad pulldown flags. Check the scene changes, specially when the pink haired girl appears.

http://www.megaupload.com/?d=MPMULDNV (21MB)
Helpful post but please read forum rule #6. Please use PM.
Rev 2242 is hopefully the solution.

haruhiko_yamagata

22nd October 2008, 11:05

adam777

22nd October 2008, 11:12

1. ffdshow.ax contains version number already, Windows XP will show it only if you rename the extension to "dll".
(not sure it's properly maintained though)

2. you can always see the revision number in the "About screen". (decoder configuration)

Hi Tal,
The file indeed contains version number, I'm aware of that fact, but as you've said, it isn't maintained properly (at the moment, rev. 2240 shows version no. 1.0.5.2184, as did all the revisions I can think of).
That is why I asked if an automated process might be possible when compiling the binaries from source.

Inventive Software

22nd October 2008, 11:23

Helpful post but please read forum rule #6. Please use PM.
Rev 2242 is hopefully the solution.

It is a sample for diagnosing playback problems and fixing them. It is not in contravention of Rule 6. ;)

STaRGaZeR

22nd October 2008, 11:23

Helpful post but please read forum rule #6. Please use PM.
Rev 2242 is hopefully the solution.

I own the DVDs, English edition ;)

I'll report any problems.

MatMaul

22nd October 2008, 11:55

I can't accept your patch about TvideoCodecLibmpeg2.cpp.
Please read madshi's post (http://forum.doom9.org/showthread.php?p=1205181#post1205181) again.
ok I read it again and you are right but there is still a problem :
if seq_progressive = 0 (so we can't assume anything) the actual code don't take in account the value of pict_progressive and it ends by flagging with TFF or BFF even if pict_progressive is set (it is what happens on my lord of the ring DVD).

here is (I hope :p) a correct patch :
Index: TvideoCodecLibmpeg2.cpp
===================================================================
--- TvideoCodecLibmpeg2.cpp (revision 2242)
+++ TvideoCodecLibmpeg2.cpp (working copy)
@@ -254,6 +254,8 @@

if(seqflags & SEQ_FLAG_PROGRESSIVE_SEQUENCE)
di_method = FIELD_TYPE::PROGRESSIVE_FRAME; // hurray!
+ else if(newflags & PIC_FLAG_PROGRESSIVE_FRAME)
+ di_method = FIELD_TYPE::PROGRESSIVE_FRAME;
else if(m_fFilm)
di_method = FIELD_TYPE::PROGRESSIVE_FRAME; // we are lucky
#if 1 // ffdshow custom code

As for deinterlacing methods, what about "Auto", "Force Bob", "Force Weave"?
I agree

clsid

22nd October 2008, 12:24

don't get mad, and forgive the noob, but I must say again, it's time to merge Albain's changes into the SVN.

The whole reason I started getting into ffdshow audio decoder, and ultimately into ffdshow's development, was our "next generation" format support, and for anybody else that has gotten into HD Audio, there is no other free (real time) alternative. I know that many High-Def enthusiastic use his builds exclusively, including me,
and the current split makes both developing and testing a bit harder for all parties involved.
besides, if there are still bugs in his latest beta, which I use thoroughly, they are hiding pretty well.

Tal
I disagree. The whole process of getting these new audio decoders to function properly took much longer than everyone expected. In hindsight I am therefore very glad we decided to open up a branch for it during development. It seems to be working OK now thanks to Albain's hard work, but it has only been tested by a small group of users. Albain has released a public build a few days ago. Like I have said before, if no bugs are reported for about a week, then it can be considered stable enough for merging. So if all goes well, I will update the trunk this weekend/beginning of next week.

haruhiko_yamagata

22nd October 2008, 12:39

ok I read it again and you are right but there is still a problem :
if seq_progressive = 0 (so we can't assume anything) the actual code don't take in account the value of pict_progressive and it ends by flagging with TFF or BFF even if pict_progressive is set (it is what happens on my lord of the ring DVD).
If I understand correctly,
PIC_FLAG_PROGRESSIVE_FRAME set: progressive or interlaced
PIC_FLAG_PROGRESSIVE_FRAME not set: interlaced

MatMaul

22nd October 2008, 12:49

haruhiko_yamagata

22nd October 2008, 13:30

Then why on earth gabest had to write that complicated code?
He had to have good reason.

Mercury_22

22nd October 2008, 14:29

I disagree. The whole process of getting these new audio decoders to function properly took much longer than everyone expected. In hindsight I am therefore very glad we decided to open up a branch for it during development. It seems to be working OK now thanks to Albain's hard work, but it has only been tested by a small group of users. Albain has released a public build a few days ago. Like I have said before, if no bugs are reported for about a week, then it can be considered stable enough for merging. So if all goes well, I will update the trunk this weekend/beginning of next week.

Can you PLEASE compile a WORKING 64-bit build of that branch for testing, (since Albain can't compile 64-bit successfully) ? :thanks: :helpful:

littleD

22nd October 2008, 15:40

I'm trying to import yadif from mplayer. It's a complicated work.
IVTC is also an wanted feature. I guess it's more complicated though.

Well, maybe its not necessary. :) I managed to use avisynth plugin directly in ffdshow. I didn't know until now, thats even possible. Its nice workaround and i dont know if it is proper way of using avs filters, but it'll save ur time :) Just paste this code:
Load_Stdcall_Plugin("Path to Yadif\yadif.dll")
Yadif(order=-1)
into ffdshow's avisynth configuration section. Anyway I cant test it further, cause all my interleaced HD samples choke my poor Sempron :devil: and cant say about quality of output. Of course any avs plugin can be used, just be aware of cpu utilization.

STaRGaZeR

22nd October 2008, 15:52

Rev 2242 is hopefully the solution.

It works :)

Can you say anything about what happens in scene changes? DGIndex reports interlaced frames in those locations, but they don't get deinterlaced? libav mpeg2 seems to do something to them, if that helps you. There is a small jump, but... Also, smooth timestamps without Avisynth would be really nice.

alexins

22nd October 2008, 16:51

Can you PLEASE compile a WORKING 64-bit build of that branch for testing, (since Albain can't compile 64-bit successfully) ? :thanks: :helpful:

Try this version of the assembly ffdshow 2239 x64 (http://www.xvidvideo.ru/component/option,com_docman/task,doc_details/gid,564/Itemid,11/) (libavformat branch (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,564/Itemid,11/))

madshi

22nd October 2008, 17:22

from the specs :
If progressive_frame is set to 0 it indicates that the two fields of the frame are interlaced fields in which an interval of time of the field period exists between (corresponding spatial samples) of the two fields.
If progressive_frame is set to 1 it indicates that the two fields (of the frame) are actually from the same time instant as one another.

I interpret like that :
progressive_flag==1 => progressive (same timestamp for both field => frame)
progressive_flag==0 => interlaced (two timestamps, one for each field)
Yes, that's what the spec says. And that's how it's supposed to be. If all DVDs were authored correctly, we could rely on "progressive_flag". No DVD player would then need an expensive video processing chip for deinterlacing because it could simply read out the flags and everything would be fine. The problem is that not all DVDs are authored correctly. You can not fully trust these flags because some DVD encodes are plain broken. That's why every good standalone DVD player converts all DVDs to 480i60 first and only afterwards uses expensive video processing chips (e.g. HQV Reon) to perform IVTC.

Having a deinterlacing mode which strictly makes use of the MPEG2 bitstream flags is not a bad idea. It will probably work well with many DVDs - but not with all. So it must still be possible to output any MPEG2 stream (except those with progressive_sequence set to 1) to 50i/60i.

Mercury_22

22nd October 2008, 17:33

Try this version of the assembly ffdshow 2239 x64 (http://www.xvidvideo.ru/component/option,com_docman/task,doc_details/gid,564/Itemid,11/) (libavformat branch (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,564/Itemid,11/))

NO SOUND ! :helpful: ON AC3; E-AC3; or DTS with libav ! Tested with MPC-HC & WMP 64-bit
Also your MPC 845 x64 Without installer 2008-10-22 18:28:39 2.64 Mb (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,559/) it's still 1.1.844.0 x64 (maybe just in about box):thanks:

SeeMoreDigital

22nd October 2008, 18:12

Yes, that's what the spec says. And that's how it's supposed to be. If all DVDs were authored correctly, we could rely on "progressive_flag"...

Having a deinterlacing mode which strictly makes use of the MPEG2 bitstream flags is not a bad idea. It will probably work well with many DVDs - but not with all. So it must still be possible to output any MPEG2 stream (except those with progressive_sequence set to 1) to 50i/60i.For those of us who back-up and store our DVD's on hard-drives, having an application that could check and correct the flags within the .IFO files and the MPEG-2 bitstream (without having to de-mux, re-mux/re-author), would be really handy indeed.

Cheers

madshi

22nd October 2008, 18:20

For those of us who back-up and store our DVD's on hard-drives, having an application that could check and correct the flags within the .IFO files and the MPEG-2 bitstream (without having to de-mux, re-mux/re-author), would be really handy indeed.
That would be very hard to do. If the bitstream is interlaced and just the TFF/BFF flags are wrong, that would be possible to correct (but still very difficult). But if the wrong fields are actually encoded incorrectly as frames then there's no way to fix that without reencoding.

tal.aloni

23rd October 2008, 00:13

Hi Tal,
The file indeed contains version number, I'm aware of that fact, but as you've said, it isn't maintained properly (at the moment, rev. 2240 shows version no. 1.0.5.2184, as did all the revisions I can think of).
That is why I asked if an automated process might be possible when compiling the binaries from source.

I'm not aware of an automatic process that will allow us to do that, and it would be too hard to this manually (by modifying the source each time).

please note that you could always use

rundll32.exe ffdshow.ax,configure

to see the revision number. (which is stored at the registry, under HKLM\Software\GNU\ffdshow\revision)

I hope that's good enough,
Tal

Anima123

23rd October 2008, 09:13

I'm trying to import yadif from mplayer. It's a complicated work.
IVTC is also an wanted feature. I guess it's more complicated though.

Wow, that's really a very nice news to hear. Though yadif can be accessed via AviSynth, a domestic support by ffdshow, which should save a log of cpu load, has been expected by me and others for a long time. Really nice to see there's someone who is working on it.

tal.aloni

23rd October 2008, 11:48

Offtopic:
is there any software deinterlacing filter in ffdshow that can perform simple BOB, with no additional processing applied?
if so, what are the required settings?

if not, do you think it will be useful? Should I try to implement one?

Thanks,
Tal

albain

23rd October 2008, 13:49

Hi,

@haruhiko, clsid, xxl
I have created a patch to fix the following bugs on SSA subtitles.

SSA position tags {\pos(x,y)} not applied correctly
SSA subtitles : the horizontal and vertical position sliders settings (in subtitle section config) are now applied when there are no positions defined (no margins and no position tags). Until now the subtitles were displayed at the bottom of the screen
SSA subtitles positionning : until now the positions were applied basing on the input resolution of the subtitles filter, which is wrong when the resizing filter is enabled before the subtitles filter. Now a ratio is applied basing on (input movie res / input filter res). Actually the code was already written but the input dimensions of the movie were always zero
SSA subtitles positionning : fixed vertical & horizontal positionning when some parts of the subtitles came out of the screen

Here is the link of the patch :
http://damienbt.free.fr/SSAFix.diff

Please report if this works fine before I commit the files.

tal.aloni

23rd October 2008, 13:58

as far as regaining volume is concerned - what's the current speed it regains volume at?

it's 6% per second to be exact (defined in the code as 'MUL_STEP'), and I think it will be a very good choice to the vast majority of the users of this function, so I didn't bother with confusing them with a list of options.
If there's a strong demand, I may change my mind.

Tal

Inventive Software

23rd October 2008, 14:37

Anima123

23rd October 2008, 14:39

tetsuo55

23rd October 2008, 14:44

I have been wondering this for a very long time.
Now with all the sound-related changes i'm going to ask:

Is it possible to create a universal Replaygain (target overall volume 89DB). It should work like the mp3 version that finds an overall volume level based on the entire file.

Requirements would be:
-Should be able to handle all audio codecs supported by FFDshow
-The replaygain data can not be embeded(altoug we should be able to get it into MKV eventually)
-Because we have a lot of read only media FFdshow should be able to locally store a list of replaygain data, like the system to remember last position on DVD's.(The has should be strong enough to prevent collisions, powerdvd has a very bad system and resumes different disks(like seasons tv shows) from the last play position of the last disk)

haruhiko_yamagata

23rd October 2008, 14:54

haruhiko_yamagata

23rd October 2008, 15:04

Wow, that's really a very nice news to hear. Though yadif can be accessed via AviSynth, a domestic support by ffdshow, which should save a log of cpu load, has been expected by me and others for a long time. Really nice to see there's someone who is working on it.
Thank you for motivating me more. But don't expect too much about the performance boost.
I required ffmpeg-mt + Core2 Quad to play premiere-paff.ts (http://x264.nl/h.264.samples/force.php?file=././premiere-paff.ts) using ffdshow-yadif(0,-1).
And yes, it's working if you don't care a few bugs.
The picture is beautiful.

tal.aloni

23rd October 2008, 15:12

I have been wondering this for a very long time.
Now with all the sound-related changes i'm going to ask:

Is it possible to create a universal Replaygain?

I was wondering about it too,
I think that the one-pass norm recently implemented is your safest bet, after 10 min. of movie watching, you'll be in the comform zone.
(the only other way I would have it is storing the gain in the file name, but it's really not worth the extra effort, one-pass norm is definitely good enough)

Tal

tetsuo55

23rd October 2008, 15:32

I was wondering about it too,
I think that the one-pass norm recently implemented is your safest bet, after 10 min. of movie watching, you'll be in the comform zone.
(the only other way I would have it is storing the gain in the file name, but it's really not worth the extra effort, one-pass norm is definitely good enough)

Tal

The way i understand it is:

Normalization Limits sounds to 89DB, making sure the sound never goes over this limit, it does a similar thing for low sounds, The dynamic range is partially lost in the process

Replaygain Lowers or Heightens the complete file's DB level based on the percieved loudeness of the entire file, the target is usually 89DB, dynamic range is fully retained.
More info: http://en.wikipedia.org/wiki/Replay_Gain
Imho its definately worth the extra file (i store everything on HDD anyway), Once it's working it could be added to MKV.

adam777

23rd October 2008, 15:48

I'm not aware of an automatic process that will allow us to do that, and it would be too hard to this manually (by modifying the source each time).

please note that you could always use

rundll32.exe ffdshow.ax,configure

to see the revision number. (which is stored at the registry, under HKLM\Software\GNU\ffdshow\revision)

I hope that's good enough,
Tal

I think the registry key you supplied should be sufficient.
Thanks again, Tal :)

tal.aloni

23rd October 2008, 16:46

The way i understand it is:

Normalization Limits sounds to 89DB, making sure the sound never goes over this limit, it does a similar thing for low sounds, The dynamic range is partially lost in the process

Replaygain Lowers or Heightens the complete file's DB level based on the percieved loudeness of the entire file, the target is usually 89DB, dynamic range is fully retained.

You got it wrong:
Normalization applies a constant amplification to the entire track, usually, the highest value that will never cause the track to go over the limit (1/max), The dynamic range is fully retained.

Replaygain add a predefined gain to the entire track, which can be equal to or lower than (1/max). in that case The dynamic range is fully retained, otherwise, The dynamic range is partially lost in the process, and clipping will occur.

Tal

albain

23rd October 2008, 19:56

Please send me samples which you use for testing.

Sorry, I have discovered a bug.

I am fixing it and will PM you the patch + the sample files

tetsuo55

23rd October 2008, 19:59

You got it wrong:
Normalization applies a constant amplification to the entire track, usually, the highest value that will never cause the track to go over the limit (1/max), The dynamic range is fully retained.

Replaygain add a predefined gain to the entire track, which can be equal to or lower than (1/max). in that case The dynamic range is fully retained, otherwise, The dynamic range is partially lost in the process, and clipping will occur.

Tal

You're right, i was confusing normalization with DRC.

does the normalization scan the entire audio track to find the correct value or does it decide it on the fly for every XX frames? (To be clear, i want to use this in real-time during playback)

SCRATCHY

23rd October 2008, 20:30

would be great if you could add more potent headphones psychoacoustic algorithms :)

I find the Sonic Audio Decoder 4.2 very impressive when set to "headphones", it gives a terrific 3D sound.

also, is it possible to have less AA on the subs ? I find them a tad blurry..

tal.aloni

23rd October 2008, 22:09

does the normalization scan the entire audio track to find the correct value or does it decide it on the fly for every XX frames? (To be clear, i want to use this in real-time during playback)

it would be time consuming and annoying if a complete audio track scan will be performd before the playback begins,
the idea behind one-pass normalization, it to start with some level of amplification, and decrease it when needed. with each decrease, the probability and intensity of the next overflow will be smaller, and usually after a few minutes of playback, you'll get very close to the right value for the track.

if you care about staying as close as possible to the source, but still want to be able to switch to music playback after the movie without being forced to turn the volume dial all the way down on the amp, this is the method to use. (you also get less static noise from the amp as well).
this is the method I'm using.

Tal

tal.aloni

23rd October 2008, 22:40

I think Kernel Bob does what you're after, yesno?
Yes, Kernel Bob will do just simple bob if the threshold parameter is set to 0.

Thanks,
Tal

tetsuo55

24th October 2008, 13:49

it would be time consuming and annoying if a complete audio track scan will be performd before the playback begins,
the idea behind one-pass normalization, it to start with some level of amplification, and decrease it when needed. with each decrease, the probability and intensity of the next overflow will be smaller, and usually after a few minutes of playback, you'll get very close to the right value for the track.

if you care about staying as close as possible to the source, but still want to be able to switch to music playback after the movie without being forced to turn the volume dial all the way down on the amp, this is the method to use. (you also get less static noise from the amp as well).
this is the method I'm using.

Tal

thanks for the info, i will use the normalization until we can get real replaygain (i would just take some time to scan all the files in my folder and be done with it)
I have not used the normalization yet, is it possible to limit it to 89DB (my audio setup is configured for this limit)?

tal.aloni

24th October 2008, 14:17

I have not used the normalization yet, is it possible to limit it to 89DB (my audio setup is configured for this limit)?

I'm not familiar with the scale you mentioned (89db),
we're talking about PCM here, and the limit is 1.0f, or 0db.

Edit: if you're so meticulous about the correct amplification level,
just find the peak for each movie, and make a batch file that will update the registry before executing playback.
(HKCU\Software\GNU\ffdshow_audio\default\volume)

tetsuo55

24th October 2008, 15:32

audio is measured in frequencies and decibels(DB)

Please check this link, it explains how to calculate the replay gain value and even has lgpl sourcecode for a working replaygain scanner.

The DB part should become clear and hopefully you can use the information to update ffdshow normalization to DB instead of % (even if you don't add the replaygain functionality)

tal.aloni

24th October 2008, 17:50

hopefully you can use the information to update ffdshow normalization to DB instead of % (even if you don't add the replaygain functionality)
1. already happening, see "decible scales" checkbox on volume configuration page.

2. you're link is missing, but I did some more reading on replay-gain. I also tested mp3gain.
it might be useful for mp3 listening, (if used correctly to decrease volume and not to amplify it, especially over 1.0f / max).
but if used to amplify the track, above (1.0f / max), clipping will occur and/or Dynamic range will be decreased.

as far as adjusting an entire movie, I'd definitely prefer normalization, and one-pass norm is good enough.

3. I suggest you'll take the time to examine the existing functionality.

audio is measured in frequencies and decibels

true, but you can't extrapolate the recording volume in db or the playback volume in db from a PCM sound file.

p.s. considering the fact that 0.2f sine wave @ 440hz is measured by mp3gain as 89.4db, I'd say you're probably using the wrong value.

tetsuo55

24th October 2008, 18:09

1. I see it now, the value is 12DB by default(400%), what should i change it to have the max value be 89DB?

2.Oops, here is the link:
http://replaygain.hydrogenaudio.org/calculating_rg.html

Replaygain is usually used for decreasing values, as most recordings are way too loud and clip like crazy.
Replaygain aims at the following: Physoaccoustically same loudeness for all files while retaining dynamic range and preventing clipping (although settings can be changed that will destroy dynamic range and cause clipping)

the problem with regular normalization remains that it's not based on phyochoaccoustic loudness.

3. I want to but i am unsure of the db scale used, how can i make the db values represent a maximum limit of 89DB

at your PS. That sine wave could be phychoaccoustically softer sounding. DB values could then indeed be slightly higher. Replaygain also checks for clipping so if that value was to result in clipping it would lower it to the highest possible value that doesn't clip.

----------

Okay i tried the following using rev 2242
-Volume checked
-Master Volume 100%/0DB
-All channels 89%/-1DB
-Normalize and lower unchecked (to disable DRC)

---------

Okay i extracter the audio and let foobar scan the mp3gain value. it took about 1 minute for the full movie(1hr51min).
The values are:
Track Gain (dB): -12.550000
Track Peak(dB): 1.517128

I did a non-abx test, and i was unable to geusstimate a value that matched the replaygains output. ffdshow was always louder.

tal.aloni

24th October 2008, 18:51

I want to but i am unsure of the db scale used, how can i make the db values represent a maximum limit of 89DB

What the standard actually states is that a single channel pink noise signal, with an RMS energy level of -20 dB relative to a full scale sinusoid should be reproduced at 83 dB SPL

confirming mp3gain's report, you're precious 89db actually means maximum sound level of 0.2f (or -14db).
so the idea is to maximaize the signal to 100%, and attenuate 14db simultaneously:
set your master volume to -14db (20%),
and your "max amplification" to 12db (400%),
uncheck "Regain volume".

but this is not very wise, before you do that, I'd recommend leaving the master volume at 100%. I'm pretty sure this will work for you far better. there is no sense in limiting the computer volume output to 20%, especially over analog conection.

tetsuo55

24th October 2008, 20:49

Okay lets see if i understand this correctly

Set master volume to 20% (this limits the internal ffdshow processing to 89DB, no sound will every cross this boundry and no clipping will occur, at the same time dynamic range is maintained)

Normalize up to 400%, this will change the volume dynamically to make all scenes sound equally as loud, it will re-evaluate the loudness every few seconds to see if the amplifictation needs to be changed. Some dynamic range could be lost as quiet scenes are amplified more than loud ones.

Limit testing shows that this setup actually sounds somewhat ok

Setting the master volume back to 100% makes everything way too loud again.

I will try to explain how my audio is set up.

Music files are replaygained to 89DB(which is basically a(static for the whole file) + or - DB value, the value can never be higher than any value that would cause clipping in that particular file. Quiet files get amplified the same way so the loudest sound sounds like 89DB without clipping)
Foobar 2000 is the player with the following settings>
-Secret Rabit code resampler resamples to 96000 (to avoid crappy windows and hardware resamplers)
-Noise Sharpener DSP at 100% (this is a very good DSP)
-Advanced Limiter (prevents clipping dynamically, acts as a backup)
-Pad bitdepth to 32bit(this is the bitdepth my soundcard works with, dithering is enabled but i doubt it does anything)
-ASIO directly to soundcard(bypassing the crappy windows kmixer)
-Soundcard to speakers, speaker volume set to 25%
-Windows master volume is set to 100%
-Foobar master volume is set to 100%

The speakers are used for other devices too, the 25% is accurate for everything i use except movies on the pc.

Although replaygain is very nice because it calculates the phychoaccoustic best value, any other method will be fine for me as long as:

-The maximum loudest sounds do not get any louder than what replaygain is currently doing with music
-dynamic range is fully retained (quiet scenes to not get amplified to the point where they are almost as loud as explosions)

(i'm basically trying to simulate the entire foobar2000 chain in ffdshow for movies)

tal.aloni

24th October 2008, 21:14

Normalize up to 400%, this will change the volume dynamically to make all scenes sound equally as loud, it will re-evaluate the loudness every few seconds to see if the amplifictation needs to be changed. Some dynamic range could be lost as quiet scenes are amplified more than explosions.
this is true if you check "Regain volume".
when "Regain volume" is unchecked, the dynamic range is ultimately fully retained.

Mr VacBob

24th October 2008, 21:36

Thank you, I have sent your sample to the author.

I finally got a chance to check this sample and it looks fine to me with mplayer+mt. Is there a timestamp problem or is it something you can screenshot? If it's a timestamp problem, are you using reordered_opaque?

ikarad

24th October 2008, 21:51

I have one question about FFDSHOW H264 codec.
This codec is only dual core multithread codec and not quad core multithread core (only two cores and not quad core are used when I play a H264 movis).
I would like to know if a new version of H264 codec used by ffdshow will bring the use of quad core.

thanks

tetsuo55

24th October 2008, 21:51

this is true if you check "Regain volume".
when "Regain volume" is unchecked, the dynamic range is ultimately fully retained.

Allright,

Next question

Normalize > Maxamplification.

Do i understand correctly that:
-You set the maximum value here, but this value i also the target, everything gets played back at this amp level
-the value is lowered to prevent loudness based on the history of the file, after a while it find an almost perfect value and stays there
-the value will be lowered even further if clipping is detected

Leak

24th October 2008, 22:40

Music files are replaygained to 89DB(which is basically a(static for the whole file) + or - DB value, the value can never be higher than any value that would cause clipping in that particular file. Quiet files get amplified the same way so the loudest sound sounds like 89DB without clipping)
Those "89dB" actually are a level the *average* volume of the whole file is adjusted to.

That doesn't mean there won't be any parts that exceed it (it's not the same as normalization), only that the whole file on average will have a pre-set level, and usually you take a handful of files (like separate songs or full albums) and use replaygain to adjust them to a similar volume so you won't get your ears blown out by that one album that's compressed to hell and back.

Replaygain itself does not do sound compression or anything similarly drastic - it just calculates an amplification factor for a whole file by attenuating several frequency bands (just for analysis, mind you) differently to kinda simulate the human hearing system. The average volume will then be calculated based on the filtered result, and the amplification factor will usually be clipped at the highest possible value that doesn't cause clipping if need be.

It does wonders for my MP3 files, but it's usually applied once directly to the files, not done on the fly.

np: T.Raumschmiere - Brenner (ft. Deichkind & The Crack Whore Society) (I Tank U)

tetsuo55

24th October 2008, 23:23

Those "89dB" actually are a level the *average* volume of the whole file is adjusted to.

That doesn't mean there won't be any parts that exceed it (it's not the same as normalization), only that the whole file on average will have a pre-set level, and usually you take a handful of files (like separate songs or full albums) and use replaygain to adjust them to a similar volume so you won't get your ears blown out by that one album that's compressed to hell and back.

Replaygain itself does not do sound compression or anything similarly drastic - it just calculates an amplification factor for a whole file by attenuating several frequency bands (just for analysis, mind you) differently to kinda simulate the human hearing system. The average volume will then be calculated based on the filtered result, and the amplification factor will usually be clipped at the highest possible value that doesn't cause clipping if need be.

It does wonders for my MP3 files, but it's usually applied once directly to the files, not done on the fly.

np: T.Raumschmiere - Brenner (ft. Deichkind & The Crack Whore Society) (I Tank U)

thanks for explaining it in more detail, thats exactly what i want in movies

SCRATCHY

24th October 2008, 23:54

sorry to bother, does anyone know if it's possible to have less blurry SRT subs ?

there's no option to check like in vobsub ? :(

is it possible to have less AA on the subs ? I find them a tad blurry..

tal.aloni

25th October 2008, 00:59

Here are some screens taken with Avisynth,
as you can see, something bizarre is happening:
http://iknowu.net/files/public/ffdshow/MT/Frame31-MT.PNG
http://iknowu.net/files/public/ffdshow/MT/Frame46-MT.PNG
http://iknowu.net/files/public/ffdshow/MT/Frame62-MT.PNG

here is frame 62 with CoreAVC for a comparision
http://iknowu.net/files/public/ffdshow/MT/Frame62.PNG

I've got phenom x3 8450 and Abit A-N78HD mobo.

p.s. ignore the wrong colorspace

tal.aloni

25th October 2008, 01:03

thanks for explaining it in more detail, thats exactly what i want in movies

you'd want the peak at 100%, above then that, you'll get clipping, below that, you'll get unnecessary static noise from the amplifier.

what you really want is one-pass norm, luckily, now you have it. :)

Tal

p.s. yes, you understood correctly.

cc979

25th October 2008, 10:42

@tal.aloni

i have a question about the normalizer in previous posts you mentioned the buffer was not used anymore, does it use another form of look-ahead or does it have headroom to prevent some clipping ?

cheers

MatMaul

25th October 2008, 11:31

Then why on earth gabest had to write that complicated code?
He had to have good reason.
don't know...
but misinterpreting progressive DVD as TFF to correctly detect some broken non compliant files is not very good I think.

what about the other part of the patch for hw deinterlacing ?

haruhiko_yamagata

25th October 2008, 11:38

don't know...
but misinterpreting progressive DVD as TFF to correctly detect some broken non compliant files is not very good I think.
Correct, but it has long history. We have to do it in a careful way. Open test is a good idea.

what about the other part of the patch for hw deinterlacing ?
I think it's good. I have just finished porting yadif, so I may have time to test.

MatMaul

25th October 2008, 11:41

one thing I forgot : with that patch libmpeg2 detection matchs libavcodec detection.

I can make a build and post it.

EDIT : here is a build (http://www.etud.insa-toulouse.fr/~mvelten/bordel/ffdshow_rev2247_libmpeg2_test.zip)
please first install a recent trunk version from sourceforge (not the albain test builds) and copy ffdshow.ax into your ffdshow directory

tal.aloni

25th October 2008, 13:16

in previous posts you mentioned the buffer was not used anymore, does it use another form of look-ahead or does it have headroom to prevent some clipping?

1. the buffer was not used to look ahead, it was used to look back.
2. yes, it does have some headroom. we only regain 6% in each second, and only when the latest sample maximum (last 0.2 seconds usually) is amplified to less then 0.75f.

Tal

tetsuo55

25th October 2008, 16:24

you'd want the peak at 100%, above then that, you'll get clipping, below that, you'll get unnecessary static noise from the amplifier.

what you really want is one-pass norm, luckily, now you have it. :)

Tal

p.s. yes, you understood correctly.

So master volume 100% or 20%?

tal.aloni

25th October 2008, 16:59

So master volume 100% or 20%?

100% is much preferred.
that is, if you're willing to forget about you're precious 89db.

p.s.
don't you have audible white noise coming from your speakers with your correct config?

KoD

25th October 2008, 17:01

Some interface bugs in albain's ffdshow build 2239 (and any other ffdshow build as well, but considering he's the one in charge of audio development right now...)
1. ffdsow audio decoder -> codecs as follows:
MP3 = libavcoded
MP1, MP2 = libavcodec
AC3 = libavcodec
DTS = libavcodec
AAC = libfaad2
Vorbis = libavcodec
2. trying to play the file [CCCP]_Mega_Audio_Test.mkv file from here (http://www.cccp-project.net/beta/index.php?dir=test_files/)
3. any mpeg 1/2/2.5 (those that are not AAC) audio track shows mp3 in the 'Info & CPU' info
4. the vorbis tracks have wrong bitrate shown in the 'Info & CPU' info
5. if instead of libfaad2, one uses realaac to decode AAC, then for those AAC profiles not supported by realaac, ffdshow throws an exception and takes the player down with it as well6
6. libavcodec is still not good enough to decode mp3. It still causes random 'clicks' on some mp3 tracks, which don't happen in the same spot when one tries to reproduce them (don't ask me for samples though)

tetsuo55

25th October 2008, 17:11

100% is much preferred.
that is, if you're willing to forget about you're precious 89db.

p.s.
don't you have audible white noise coming from your speakers with your correct config?

I'm going to use 80% for now (100% too loud), with normalize at 400%.

Well i don't really care about the 89dB i just mentioned it because replaygain says it uses it for something. My goal is purely to have everything sound equaly as loud without having to change the volume settings of my speakers

if you mean windows sounds/foobar2000 and external sources then no, the first sign of white/pink noise starts at about 70% speaker loudness and thats from the fans and harddisks in the system.

If you mean with ffdshow i did notice some settings caused white noise but with my current settings i don't hear it.

tal.aloni

25th October 2008, 19:10

haruhiko_yamagata

26th October 2008, 13:38

I just checked the video on a different computer (Athlon X2),
the same distortion is there as well when using ffdshow-MT.

Tal
Thanks, I have sent the sample to the author of ffmpeg-mt.
There's not much that I can do about this.

clsid

26th October 2008, 18:30

The trunk has been updated with the new audio decoders from the branch. Builds will be online in a few moments.

tal.aloni

26th October 2008, 18:44

The trunk has been updated with the new audio decoders from the branch.

Perfect! Thanks a lot! :)

burfadel

26th October 2008, 19:00

Apparently under Windows you cannot create an AVI file bigger than 512GB or playback a file that is greater than 800GB (yes you read correctly). Microsoft has released a fix for this:
http://support.microsoft.com/kb/927544/

Now for all those that were upset about not being able to play those 800Gb+ AVI files need not to worry any more :)

ikarad

26th October 2008, 20:34

I just checked the video on a different computer (Athlon X2),
the same distortion is there as well when using ffdshow-MT.

Tal

What is ffdshow-MT?

Mercury_22

26th October 2008, 20:52

The trunk has been updated with the new audio decoders from the branch. Builds will be online in a few moments.

Thanks ! but 64-bit it's crashing both MPC-HC and WMP
Problem signature:
Problem Event Name: APPCRASH
Application Name: mplayerc64.exe
Application Version: 1.1.844.0
Application Timestamp: 48fef5af
Fault Module Name: libavcodec.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4904a883
Exception Code: c0000005
Exception Offset: 00000000003636c8
OS Version: 6.0.6002.2.2.0.256.1
Locale ID: 1033
Additional Information 1: 7db1
Additional Information 2: 36e4b54319f72e78877517160cd25528
Additional Information 3: 572d
Additional Information 4: 39ab74aef9b5970400e138224b1a0740

when using libav for E-AC3, AC3, DTS It's working for mp3, mp1,mp2 and not tested for MLP / DTHD ! :helpful: :confused:

clsid

26th October 2008, 21:12

Forgot to disable some ASM code for 64bit. Try next build.

Mercury_22

26th October 2008, 21:25

Forgot to disable some ASM code for 64bit. Try next build.

Can't find it ! Not yet up ? :confused:

Edit: Now it's UP ! and E-AC3 & DTS are still crashing but AC3 it's NOT crashing just NOISE no AUDIO and TrueHD/MLP = no audio !

Also ffdshow tryouts project, svn 2253 (x64) from http://xvidvideo.ru/ it's crashing for all !

alexins

26th October 2008, 21:55

Can't find it ! Not yet up ? :confused:

Edit: Now it's UP ! and E-AC3 & DTS are still crashing but AC3 it's NOT crashing just NOISE no AUDIO !

Also ffdshow tryouts project, svn 2253 (x64) from http://xvidvideo.ru/ it's crashing for all !

I have faults occur when ac3 and dts decoded through libavcodec. In normal mode output through liba52 and libdts no disruptions.
Draft x86 works without error!

Mercury_22

26th October 2008, 22:01

I have faults occur when ac3 and dts decoded through libavcodec. In normal mode output through liba52 and libdts no disruptions.
Draft x86 works without error!

Yes I was referring just to x64 libav for E-AC3, AC3 and DTS from ffdshow tryouts project, svn 2253 (x64) http://xvidvideo.ru/ !

albain

26th October 2008, 22:30

I don't know why, but I had the best results under 64 bits when compiling libavcodec under MSVC (I mean working sound).

There, I had MLP/TrueHD/AC3/EAC3 decoding Okay. I did not test DTS/DTS-HD though

clsid

26th October 2008, 22:41

Using MSVC will result in bad decoding performance for all a/v formats because it does not include the assembly stuff. It would be better to just disable only the audio related optimizations, assuming of course that MinGW64 compiles the plain c code correctly.

albain

26th October 2008, 22:48

I totally agree, I was just saying that to point out the fact that I "heard" it work partially under 64 bits.

I confirm the followings with MSVC : AC3/EAC3/TrueHD OK, DTS/DTSHD has garbled sound.

Mercury_22

26th October 2008, 22:53

I totally agree, I was just saying that to point out the fact that I "heard" it work partially under 64 bits.

I confirm the followings with MSVC : AC3/EAC3/TrueHD OK, DTS/DTSHD has garbled sound.

So maybe for the moment we should have the 64-bit compiled with MSVC since for DTS we can use libdts ?:helpful::thanks:

STaRGaZeR

26th October 2008, 23:04

So maybe for the moment we should have the 64-bit compiled with MSVC since for DTS we can use libdts ?:helpful::thanks:

You don't want that, H.264 Blu-ray playback is impossible with the perfomance MSVC buids provide.

clsid

26th October 2008, 23:30

I will make another x64 test build of libavcodec with more assembly stuff disabled.

Edit: download (http://www.zshare.net/download/504655106d9db58d/)

alexins

26th October 2008, 23:57

I will make another x64 test build of libavcodec with more assembly stuff disabled.

Edit: download (http://www.zshare.net/download/504655106d9db58d/)
When the withdrawal ac3 and dts, the player does not close the error.
During the reproduction of ac3 there is no sound. During the reproduction of dts is very strongly overstated the maximum level of sounding.
http://s60.radikal.ru/i169/0810/4f/71a0deefcde9t.jpg (http://radikal.ru/F/s60.radikal.ru/i169/0810/4f/71a0deefcde9.png.html)

Mercury_22

27th October 2008, 08:08

I will make another x64 test build of libavcodec with more assembly stuff disabled.

Edit: download (http://www.zshare.net/download/504655106d9db58d/)

DTS just noise and E-AC3, AC3, MLP no sound

ikarad

27th October 2008, 08:12

What is ffdshow-MT?

up!
thanks

albain

27th October 2008, 09:17

up!
thanks

FFDShow with libavcodec multithreaded, so better performances on multicore processors

clsid

27th October 2008, 13:04

Unless someone has an idea how to fix this, I think we'll just have to disable the libavcodec DTS/AC3/E-AC3/MLP decoders in the 64-bit builds. Does libavcodec MP2/MP3 work? Does vorbis work?

alexins

27th October 2008, 13:19

Mercury_22

27th October 2008, 13:31

MP3 -> libavcodec - works.
Vorbis -> libavcodec - no sound.

I can confirm that plus mp2 works too ! :)
EDIT also sometimes FFD 32-bit (too) reports MLP as E-AC3 and I have no sound !

STaRGaZeR

27th October 2008, 14:08

MLP works too.

Mercury_22

27th October 2008, 14:41

MLP works too.
Strange MLP with 64-bit FFD it's not working for me :confused: What SVN are you using ?

MLP it's failing even on 32-bit on seek / skip and sometimes on normal play

STaRGaZeR

27th October 2008, 15:27

Strange MLP with 64-bit FFD it's not working for me :confused: What SVN are you using ?

MLP it's failing even on 32-bit on seek / skip and sometimes on normal play

2254. The seeking bug is not related, splitter problem. Also, if you have problems with MLP as secondary audio track (you have to change between tracks to reach it) your problem is probably splitter related too. m2ts files with only one TrueHD track play fine until you seek of course.

Where is that 64bit version of Haali's grrrr.

albain

27th October 2008, 15:45

Unless someone has an idea how to fix this, I think we'll just have to disable the libavcodec DTS/AC3/E-AC3/MLP decoders in the 64-bit builds. Does libavcodec MP2/MP3 work? Does vorbis work?

I agree

The internal parser will always work though : so 64 bits users will be able to have DTS core from DTS-HD decoded with libdts (or sent to SPDIF), as well as TrueHD/MLP streams with AC3 frames interweaved will be decoded by liba52 (or sent to SPDIF).

For now, I don't have much time to work on my 64 bits environment to digg this around, this is the reason why I switched to ASS/SSA subtitles management.

In the meantime, a few leads can be followed :
Does mplayer works under 64 bits with libavcodec with DTS, AC3, EAC3 and TrueHD ?
Where can we find an older version of mingw64 ?
Which parts of codes (asm or not) are not entered into by MSVC unlike gcc ?

STaRGaZeR

27th October 2008, 16:00

Where can we find mplayer64?

Also albain, this has been requested a few times already, in both this and MPC-HC's thread. The current subtitle engine outputs perfectly round and anti-aliased subtitles, which gives sensation of blurring, compared to VSFilter which is totally aliased. Is it possible to add some control to the amount of antialiasing applied to the subs?

Mercury_22

27th October 2008, 16:13

2254. The seeking bug is not related, splitter problem. Also, if you have problems with MLP as secondary audio track (you have to change between tracks to reach it) your problem is probably splitter related too. m2ts files with only one TrueHD track play fine until you seek of course.

Where is that 64bit version of Haali's grrrr.

Yes I'm using a m2ts with 3 audio tracks and MLP it's the third one and i've succeed to make it work for MLP :

if a let the file to play for 1 minute when I'm changing to MLP track it's playing OK if I change earlier I have no sound !

All this with MPC-HC on 64-bit and SVN 2254

P.S. On 32 bit if I use Haali's splitter I don't have the MLP track just the first two ! :confused:

clsid

27th October 2008, 18:21

Where can we find an older version of mingw64 ?
Found an older one here (http://dfn.dl.sourceforge.net/sourceforge/mingw-w64/mingw-w64-bin_x86-64-mingw_20080528.zip).
Which parts of codes (asm or not) are not entered into by MSVC unlike gcc?
The test build of libavcodec that I posted a couple posts above had all audio related ASM disabled. But it still gives sound issues according to the reports from those who tested it.

STaRGaZeR

27th October 2008, 23:35

Thanks to this (http://forum.doom9.org/showthread.php?p=1207231#post1207231) comment of nm the problem of ffdshow assuming a fixed field order for MBAFF interlaced streams (because it can't detect what's the correct one) may be solved. The problem was discussed in this thread (http://forum.doom9.org/showthread.php?t=104277&page=206).

nm says pict_struct is the key for detecting if the video is TFF or BFF, being 3 for TFF and 4 for BFF. Can you guys take a look at this?

albain

28th October 2008, 11:03

Hi,

I have recompiled libavcodec with mingw64 and FFDShow with MSVC on my 64 bits environment and I am quite happy with the results :

MLP/TrueHD/AC3/EAC work
DTS/DTS-HD work

I use gcc 4.4, and the difference is that I compiled it under 64 bits.

I will try to post a new build soon

albain

28th October 2008, 11:46

haruhiko_yamagata

28th October 2008, 12:32

STaRGaZeR

28th October 2008, 12:49

@albain

Some DTS samples are wrong with bad noise as always, tested with the Black Hawk Down sample. Also if when decoding EAC3 you open Info & CPU the audio stops. For those DTS samples that work, open Info & CPU results in a change to noise again. Vorbis still doesn't work. But definitely an improvement over the previous builds.

@haruhiko

Nice :)

Mercury_22

28th October 2008, 12:52

Actually, everything work except one format :
TrueHD with 8 channels at 96khz (whereas 5.1 at 48khz work)

Here is the build :
http://rapidshare.com/files/158302616/ffdshow_rev2253_20081026_dbt_x64.exe.html

mp1/2/3 works DTS just noise AC3/ E-AC3/Vorbis/MLP no sound tested with MPC-HC 849 x64 and avi , ts and m2ts files

alexins

28th October 2008, 17:18

mp1/2/3 works DTS just noise AC3/ E-AC3/Vorbis/MLP no sound tested with MPC-HC 849 x64 and avi , ts and m2ts files
I confirm, takes place similarly for me.
__________________________________

In assembling of ffdshow 2262 x86 (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,575/), if we select conclusion AC3 - libavcodec appears error.
__________________________________

I made two versions of assembling ffdshow of x64, libavcodec.dll - GCC of 4.4.0 x86_64 and libavcodec.dll - VS2008sp1. The version of libavcodec.dll - VS2008sp1 reproduces AC3, DTS, e-ac3, Vorbis, MLP… without the errors, but there is a problem with performance when playing format H264.
ffdshow tryouts project, svn 2262 (x64) (libavcodec.dll - GCC 4.4.0 x86_64) (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,574/)
ffdshow tryouts project, svn 2262 (x64) (libavcodec.dll - VS2008sp1) (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,573/)

Mercury_22

28th October 2008, 17:25

I confirm, takes place similarly for me.
__________________________________

In assembling of ffdshow 2262 x86 (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,575/), if we select conclusion AC3 - libavcodec appears error.
__________________________________

I made two versions of assembling ffdshow of x64, libavcodec.dll - GCC of 4.4.0 x86_64 and libavcodec.dll - VS2008sp1. The version of libavcodec.dll - VS2008sp1 reproduces AC3, DTS, e-ac3, Vorbis, MLP… without the errors, but there is a problem with performance when playing format H264.
ffdshow tryouts project, svn 2262 (x64) (libavcodec.dll - GCC 4.4.0 x86_64) (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,574/)
ffdshow tryouts project, svn 2262 (x64) (libavcodec.dll - VS2008sp1) (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,573/)

FINALLY WE HAVE A 64-bit WINNER !

The svn 2262 (x64) VS2008sp1 version from http://www.xvidvideo.ru/content/view/335/1/ it's working with ALL :thanks: :thanks: :thanks:
Tested with MPC-HC and avi, ts and m2ts files with vorbis MLP DTS E-AC3 AC3 MP1/2/3

P.S. the svn 2262 (x86) 32-bit from http://www.xvidvideo.ru/content/view/334/1/ it's CRASHING with libav !!!!!! :mad: :confused: :helpful: :devil:

Maybe this is the answer Revision 2263 - Directory Listing
Modified Tue Oct 28 15:22:22 2008 UTC (75 minutes, 50 seconds ago) by h_yamagata
oops, (triggered a compiler's??) bug at rev 2261. ? :helpful:

STaRGaZeR

28th October 2008, 18:43

MSVC builds are perfect for everything except H.264 :(

@haruhiko

With the recent changes it seems that all MBAFF samples I have play with the correct field order, great work http://www.xtremesystems.org/forums/images/smilies/thumbsup.gif

Regarding the sample you posted here (http://forum.doom9.org/showpost.php?p=1206065&postcount=4715), it seems ffdshow flags different parts of the video as progressive and others as interlaced. CoreAVC and Cyberlink both flag the whole video as interlaced.

nautilus7

28th October 2008, 19:03

Actually, everything work except one format :
TrueHD with 8 channels at 96khz (whereas 5.1 at 48khz work)Actually, TrueHD 7.1 is broken in 32bit builds also. With all 7.1 (regardless samplerate) samples i get no sound, while 5.1 play fine.

albain

28th October 2008, 20:17

Ok, it should not be difficult to figure out what's wrong with 8 channels TrueHD.

ikarad

28th October 2008, 22:03

Octo-puss

28th October 2008, 22:03

I got a little problem I can't seem to solve.
Whenever I got a movie playing or paused - doesn't matter - just as long as any is loaded, and I open another instance of player (MPC in my case, but it's not important), there is no audio on the 2nd movie. What am I doing wrong, or what should I look for in FFD audio decoder settings?

clsid

28th October 2008, 22:14

That is a bug in your sound drivers.

Octo-puss

28th October 2008, 22:18

So much for onboard soundcards I guess, then :(

clsid

28th October 2008, 22:37

Then update your drivers. Or if there are no updates, report your problem to the manufacturer.

LoRd_MuldeR

28th October 2008, 22:45

littleD

28th October 2008, 22:51

fastplayer

28th October 2008, 22:54

What am I doing wrong, or what should I look for in FFD audio decoder settings?
Uninstall, delete ffdshow's registry key (HKEY_CURRENT_USER\Software\GNU) and reinstall.
Could be that something in the "DirectShow control" part of ffdshow's audio decoder is messed up... and make sure you're media players are outputting audio via DirectSound and not waveOut or something else.

STaRGaZeR

28th October 2008, 23:14

When I enable deinterlace then the deinterlacing filter seem to switch on and off randomly!

The older build r2202 works good. This is with live MPEG-2 broadcast in DVBViewer...

Can you post a sample? Older revisions incorrectly marked progressive frames as interlaced, the newer ones don't.

LoRd_MuldeR

28th October 2008, 23:18

tal.aloni

28th October 2008, 23:20

I noticed that deinterlacing is broken in ffdshow r2253 and r2265 :(

When I enable deinterlace then the deinterlacing filter seem to switch on and off randomly!
Happens at least with the KernelBob and the KernelDeint. You can clearly see it with the "Map" option checked.
Looks like sometimes the frames simply by-pass the deinterlace filter.

The older build r2202 works good. This is with live MPEG-2 broadcast in DVBViewer...

Dear lord,
latest ffdshow revisions can deinterlace only interlaced content.
it's possible that some of the frames in the broadcast are not flagged as interlaced. in that case, you can check "process frames flagged as progressive" in the deinterlacing filter tab.

Tal

albain

28th October 2008, 23:26

Actually, TrueHD 7.1 is broken in 32bit builds also. With all 7.1 (regardless samplerate) samples i get no sound, while 5.1 play fine.

I found some differences with the version I have from the branch, that should explain the broken 7.1 on TrueHD

nautilus7

28th October 2008, 23:33

So we have a saboteur? :D

STaRGaZeR

28th October 2008, 23:37

The problem is that is seems to happen randomly and with live broadcast. I will try to capture a clip that exhibits the problem...

EDIT: I got a video capture that can be used to reproduce the problem with MPC + ffdshow r2265. Uploading it now.

Like tal.aloni says now ffdshow only deinterlaces those frames flagged as interlaced. If your stream has random frames flagged as progressive (I have DVDs like that, but reversed: film with random interlaced frames) they will not get deinterlaced. Well they will get the flag, but the "change" from interlace to progressive and vice versa seems to be so fast that there is no time for the deinterlacer filter to properly do its job. You can try the "process frames flagged as progressive" option.

haruhiko_yamagata

28th October 2008, 23:46

With the recent changes it seems that all MBAFF samples I have play with the correct field order, great work http://www.xtremesystems.org/forums/images/smilies/thumbsup.gif

Regarding the sample you posted here (http://forum.doom9.org/showpost.php?p=1206065&postcount=4715), it seems ffdshow flags different parts of the video as progressive and others as interlaced. CoreAVC and Cyberlink both flag the whole video as interlaced.Thanks for testing. Yes, I know. I'll look into it.

TheShadowRunner

28th October 2008, 23:46

Hey all, I was just wondering if multithreading for SVQ3 was planned at some point?
Those Nasa HD videos are encoded in SVQ3 and I wonder what kind of crazy processor one needs to watch them with ffdshow:
http://anon.nasa-global.edgesuite.net/qt.nasa-global/ksc/ksc_061108_glast_launch_1080i.mov
See you,

TSR

haruhiko_yamagata

28th October 2008, 23:52

I use ffdshow-mT (2250) (it's the only version where I don't have any dropped image with mpc homecinema and mt2s file (blu-ray)) but this version doesn't support HD audio codec (E-AC3,MLP,DTS-HD) because it's not the same build.
Do you expect to make a version with ffdshow-mt and HD audio codec support?Sorry, but it's not easy.
ffmpeg-mt is based on old (around 200805) libavcodec and it is hard to update to the latest.
Even if we can, it will make maintenance difficult.
Please wait until ffmpeg-mt is updated by Alexander Strange.

Octo-puss

29th October 2008, 00:10

Try to set DefaultDirectSoundDevice on Options>>Playback>>Output>>Directshow audio

Oh! It works! I used to have it set to Realtek HD Audio just like I do everywhere. Weird, but works. Thank you!

Also when we are the filters and stuff, shall I disable all internal ones in MPC/MPC-HC? I mean, I assume FFD is better?

STaRGaZeR

29th October 2008, 00:16

TheShadowRunner

29th October 2008, 00:19

Thanks for testing STaR, can you confirm it only uses 1 core? My dual core @ 2.6ghz just can't cope with it :/
Time to grab a new CPU I guess ^^;

LoRd_MuldeR

29th October 2008, 00:23

Okay, here is the sample:
http://www.mediafire.com/file/jznjmmzmz3i/Sample.7z

Please watch it with "KernelBob" deinterlacer enabled and with the "Map" option checked.
Starting at 00:59 ffdshow r2265 will occasionally stop deinterlacing!

[EDIT]

Doah! :mad: :scared: :o

Sorry, I just noticed tal.aloni's and STaRGaZeR's posts. How could I be so stupid and miss the new option?!
With that option checked everything is fine again, of course ...

fastplayer

29th October 2008, 00:26

Hey all, I was just wondering if multithreading for SVQ3 was planned at some point?
1. Wrong forum to ask. Ask here instead:
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user/
2. The video plays fine without one single frame drop on my single-core Athlon64 2.2GHz.

BatKnight

29th October 2008, 00:33

TheShadowRunner

29th October 2008, 00:51

Ok, actually nope, contrary to what i just wrote, it's not a matter of hw deinterlacing being enabled or not, it's a matter of splitter!?
With Gabest MP4 Splitter, it plays just fine.
With Haali Media Splitter, it lags like crazy!
Odd..

STaRGaZeR

29th October 2008, 01:08

Thanks for testing STaR, can you confirm it only uses 1 core? My dual core @ 2.6ghz just can't cope with it :/
Time to grab a new CPU I guess ^^;

Yes, the decoder only uses 1 core. And I can confirm Haali's needs a lot more CPU power. Also with Haali's the field order is wrong ...

@Lord

I've been watching your sample and I've found 0 problems with it, every single frame is flagged as interlaced and it gets deinterlaced properly. Tested with kernelbob, hardware deinterlacing and various renderers. BTW the Map option produces white garbage on screen? I can't see anything with it enabled :p

LoRd_MuldeR

29th October 2008, 01:19

@Lord

I've been watching your sample and I've found 0 problems with it, every single frame is flagged as interlaced and it gets deinterlaced properly. Tested with kernelbob, hardware deinterlacing and various renderers. BTW the Map option produces white garbage on screen? I can't see anything with it enabled :p

The "Map" shows you where KernelBob detects motion. The "white" pixels indicate the pixels that will be interpolated by KernelBob.
Of course you wouldn't activate the "Map" option for playback. You simply use it to adjust the "Threshold" parameter and then turn it off.

With "Map" on you can clearly notice that KernelBob suddenly stops to interpolate. Hence the deinterlacer is toggled off for certain frames.
It starts at 0:59 and happens occasionally. The ranges where it happens are identical for each run. It's 100% reproducible for me!

However if I check the "process frames flagged as progressive" option all works fine again :)

STaRGaZeR

29th October 2008, 01:47

Oh I see now, thanks. However I can't notice any interpolate stop in the entire video.

And I was wrong! Open the sample with DGIndex. It will report progressive frames all over the place! :confused:...

LoRd_MuldeR

29th October 2008, 02:03

And I was wrong! Open the sample with DGIndex. It will report progressive frames all over the place! :confused:...

I can confirm this, so it's not ffdshow's fault for sure:

http://img183.imageshack.us/img183/3671/progressivehd1.th.png (http://img183.imageshack.us/my.php?image=progressivehd1.png)http://img183.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

I don't know why that is. That's how the stream came from the broadcast station.
Maybe their MPEG-2 encoder is borked or they don't know how to configure it properly.

But as long as I know how to fix it, there is no problem for me :)

ikarad

29th October 2008, 08:39

Sorry, but it's not easy.
ffmpeg-mt is based on old (around 200805) libavcodec and it is hard to update to the latest.
Even if we can, it will make maintenance difficult.
Please wait until ffmpeg-mt is updated by Alexander Strange.

thanks.

Do you know if alexander strange works on a new version of multithreading libavcodec?

With ffdshow-mt it lacks only the support of HD-audio codec and the support of .PG subtitles (HD subtitles) and with these supports ffdshow-mt would be perfect for myself.

albain

29th October 2008, 08:56

Hi,

I am using ffdshow SVN 2265 (x86) over Windows Vista with SPDIF enabled in DTS and AC3. I am using an external decoder that can only process up to DTS ES and DD EX.
My question is: Why can I hear sound via SPDIF when playing a TrueHD 7.1 96Khz m2ts file?

Does this mean that ffdshow strips the AC3 part of the TrueHD (if there is one in the first place) and SPDIFs only the AC3? Is it SPDIFing the full TrueHD and then the external decoder only plays the AC3 part?

This also happens on DTS Master Audio files.

Can someon please explain the details of the process? :helpful:

Thanks
Bat

That's right, I made an internal parser that strips off AC3 frames from TrueHD streams (if there are), but only if AC3 codec is set to SPDIF. In that case the truehd part is not decoded at all

Concerning DTS-HD, it is slightly different : ffmpeg does not handle DTS-HD decoding, so for now FFDShow parser strips off the DTS core and sends it to the DTS decoder (or SPDIF if selected)

tal.aloni

29th October 2008, 09:47

Albain,
did you figure why we have 2 places to select spdif-passthrough instead of one?

Tal

STaRGaZeR

29th October 2008, 10:05

I can confirm this, so it's not ffdshow's fault for sure:

http://img183.imageshack.us/img183/3671/progressivehd1.th.png (http://img183.imageshack.us/my.php?image=progressivehd1.png)http://img183.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

I don't know why that is. That's how the stream came from the broadcast station.
Maybe their MPEG-2 encoder is borked or they don't know how to configure it properly.

But as long as I know how to fix it, there is no problem for me :)

DVB streams are almost always bad flagged, dunno why. But again, I don't have any problems with ffdshow and that sample, it deinterlaces all frames using xvidvideo.ru's rev2265 x86. So who's right?

albain

29th October 2008, 10:40

Albain,
did you figure why we have 2 places to select spdif-passthrough instead of one?

Tal

Well, if I understand you correctly, there are 2 places (and maybe more tomorrow with "HDMI passtrough") because if your receiver knows how to handle Dolby Digital decoding and not DTS, it is better to have the choice to select SPDIF for AC3 and libdts or libavcodec for DTS.

tal.aloni

29th October 2008, 11:36

Well, if I understand you correctly, there are 2 places (and maybe more tomorrow with "HDMI passtrough") because if your receiver knows how to handle Dolby Digital decoding and not DTS, it is better to have the choice to select SPDIF for AC3 and libdts or libavcodec for DTS.

Edit:
I was referring to both the checkbox and the drop down each format have.
why do I need to "Use SPDIF when AC3 output set" if I can just select "SPDIF" for this audio format?
any good reason to keep it?

Edit:
I checked the code, the checkbox does exactly what it says.

1. it seems that albain didn't implement that "functionality" for libavcodec.
2. this "functionality" is totally unnecessary in my opinion (and confusing).

TffdshowDecAudio.cpp:

// use SPDIF pass through when AC3 output and 'Use SPDIF when AC3 output set' are checked.
if ( codecId == CODEC_ID_LIBA52
&& inpin && inpin->audio
&& (inpin->audio->codecId == CODEC_ID_LIBA52 || inpin->audio->codecId == CODEC_ID_SPDIF_AC3)
&& globalSettings->ac3SPDIF
&& presetSettings && presetSettings->output
&& (presetSettings->output->outsfs & TsampleFormat::SF_AC3)
)
inpin->audio->codecId = codecId = CODEC_ID_SPDIF_AC3;
if ( codecId == CODEC_ID_LIBDTS
&& inpin && inpin->audio
&& (inpin->audio->codecId == CODEC_ID_LIBDTS || inpin->audio->codecId == CODEC_ID_SPDIF_DTS)
&& globalSettings->ac3SPDIF
&& presetSettings && presetSettings->output
&& (presetSettings->output->outsfs & TsampleFormat::SF_AC3)
)
inpin->audio->codecId = codecId = CODEC_ID_SPDIF_DTS;

albain

29th October 2008, 14:38

I implemented this checkbox for the following purpose : if you output sound to 2 rooms, one over SPDIF (living room) and one over analog output (bedroom for ex), if you set AC3 to SPDIF, you will never get sound to your bedroom with AC3 streams.

So the solution is
1/ To define 2 audio presets :
1a/one with AC3 output checked for the living room preset (and resampling to 5.1 48khz or 96khz),
1b/one with AC3 output unchecked for the bedroom preset (and resampling to stereo 44khz).
2/ Set AC3 codec to libavcodec or liba52

As a result, SPDIF will be used for living room preset and not for bedroom preset

This is not ideal I agree : SPDIF should not be a global setting but a preset setting, one for DTS, one for AC3, and maybe others for HD audio formats

However, I indeed forgot to update this code for the new audio codecs with libavcodec

haruhiko_yamagata

29th October 2008, 14:39

Yes, that's what the spec says. And that's how it's supposed to be. If all DVDs were authored correctly, we could rely on "progressive_flag". No DVD player would then need an expensive video processing chip for deinterlacing because it could simply read out the flags and everything would be fine. The problem is that not all DVDs are authored correctly. You can not fully trust these flags because some DVD encodes are plain broken. That's why every good standalone DVD player converts all DVDs to 480i60 first and only afterwards uses expensive video processing chips (e.g. HQV Reon) to perform IVTC.

Having a deinterlacing mode which strictly makes use of the MPEG2 bitstream flags is not a bad idea. It will probably work well with many DVDs - but not with all. So it must still be possible to output any MPEG2 stream (except those with progressive_sequence set to 1) to 50i/60i.
I've just updated H.264 interlacing detection and now, I think those flags are used to define decoding processes.
Forgive me randomly guessing, in my opinion, after decoding processes such as deinterlacing and color space conversion are not defined by those flags.

PAFF is of course picture adaptive, some pictures are encoded using fields, some pictures frames. And the frame pictures are not necessarily still pictures, they have severe combing.
If it is MPEG-2 such pictures are judged progressive. And H.264 decoded by ffdshow before rev 2268 as well.

Fortunately H.264 has supplemental information for after decoding processes. In MPEG-2 we have no choice but to derive after decoding processes information from decoding information.

I mean interlacing/progressive mode of after decoding processes is not always same as decoding processes. I guess that's one of the reasons why flags are not reliable in MPEG-2.

Of course MPEG-2 is not H.264. Just a random guess.

haruhiko_yamagata

29th October 2008, 15:14

tal.aloni

29th October 2008, 15:22

This is not ideal I agree : SPDIF should not be a global setting but a preset setting, one for DTS, one for AC3, and maybe others for HD audio formats

I understand.
there are two solutions I can think of, both are better and easier to understand:
1. we can make the entire codec selection based on presets.
2. we can add another two checkboxes to the "output" tab, so it would look like that:
[x] AC3
__ [x] Encode mode
_____ [x] encode only 5.1ch streams ...
_____ Bit Rate: [640]
[x] DTS (passthrough)

I think 2 will be much easier to implement, what do you say?

cc979

29th October 2008, 16:11

i just tried to compile svn-2266 and i get this error

windres ffdshow.rc -o ffdshow.res.o -D_WIN32_IE=0x0500 -DIDCLOSE=8
dllwrap -mno-cygwin --target=i686-pc-mingw32 \
-o ../bin/ffdshow.ax -def ffdshow.def.gcc \
-Wl,--strip-all,--enable-stdcall-fixup \
ffdshow_all.o TffDecoder_reg.o Tconfig.o ffdebug.o cpuid.o memcpy.o subtitles/fontRenderer.o convert/colorspace_rgb_mmx.o acm/Tacm.o audioFilters/ffdshow_audiofilters_all.o codecs/ffdshow_codecs_all.o codecs/TaudioCodecTremor.o codecs/TvideoCodecTheora.o codecs/TaudioCodecLibavcodec.o codecs/TaudioCodec.o codecs/TvideoCodecLibavcodec.o convert/ffdshow_convert_all.o dialog/ffdshow_dialog_all.o dialog/TSpecifyPropertyPagesVE.o filters/ffdshow_filters_all.o imgFilters/ffdshow_imgfilters_all.o muxers/ffdshow_muxers_all.o xiph/ogg/bitwise.o xiph/ogg/framing.o settings/ffdshow_settings_all.o settings/lzo/minilzo.o subtitles/ffdshow_subtitles_all.o baseclasses/baseclasses_all.o ffmpeg/libavcodec/golomb.o audioFilters/TaudioFilterConvert.o audioFilters/dotproduct.o imgFilters/simple_idct_mmx.o imgFilters/Skal/skl_dct_sse.o imgFilters/Skal/skl_fdct_mmx.o ffdshow.res.o \
-lmsvcrt -lstdc++ -lsupc++ \
-lgdi32 -lcomdlg32 -lwinmm -lcomctl32 -luuid -lole32 -loleaut32 \
-ldinput -ldxguid -lshlwapi
ffdshow_all.o:ffdshow_all.cpp:(.text+0x442dd): undefined reference to `TaudioParser::TaudioParser(IffdshowBaseA*, IdecAudioSink*)'
d:\mingw\bin\dllwrap.exe: d:\mingw\bin\gcc exited with status 1
make: *** [../bin/ffdshow.ax] Error 1

anyone else got problems ?

cheers

tal.aloni

29th October 2008, 16:15

I think "Process frame flagged as progressive" should be checked by default. Any opinions?

I thought about it thoroughly before I submitted the patch,
I know the upgrade path is imperfect, but I'm convinced I made the right call:
only DVB viewers would want that checked, and those are a small group of savvy users that would notice that something is "different" after the upgrade. LoRd_MuldeR just proved that the advanced users will know how to handle.

I know this is far from perfect, but it allows us to to good with a much larger crowd:
for a short period of time, I assumed that "deinterlacing" is only applied to "interlaced content", like done in many other decoders (like coreavc). I soon found out that something is wrong, but perhaps many others, who casually watch interlaced content, haven't had such luck.

in addition, let's not forget that this function is only useful if you happen to have a badly authored stream. I don't want to "suggest" using that function to the average user who wish to deinterlace when coming across interlaced stream.

Tal

clsid

29th October 2008, 16:34

I understand.
there are two solutions I can think of, both are better and easier to understand:
1. we can make the entire codec selection based on presets.
2. we can add another two checkboxes to the "output" tab, so it would look like that:
[x] AC3
__ [x] Encode mode
_____ [x] encode only 5.1ch streams ...
_____ Bit Rate: [640]
[x] DTS (passthrough)

I think 2 will be much easier to implement, what do you say?
I would suggest these options. Makes it a bit more clear that encoding applies to other audio formats.
==== SPDIF ====
[ ] Pass through AC3
[ ] Pass through DTS
[ ] Encode other formats to AC3
[x] 5.1ch only
Bitrate: [640]

tal.aloni

29th October 2008, 16:43

I would suggest these options. Makes it a bit more clear that encoding applies to other audio formats.
==== SPDIF ====
[ ] Pass through AC3
[ ] Pass through DTS
[ ] Encode other formats to AC3
[x] 5.1ch only
Bitrate: [640]

even better, I assume "Pass through AC3" has the priority.

p.s. it should be "Encode to AC3", since some would want to apply filters for AC3 stream and re-encode.

clsid

29th October 2008, 17:08

Yes, unchecking AC3 passthrough should allow encoding the decoded/processed audio to AC3 again.

STaRGaZeR

29th October 2008, 17:14

I think "Process frame flagged as progressive" should be checked by default. Any opinions?

Yes and no. There is a problem with streams with mixed content, and specially those with only a few frames in between the dominant flag like in my last sample posted here (the Gundam one): the change from one to another produces 1 or 2 frames in where interlaced video is showed as progressive and progressive is still deinterlaced. I don't know if that is a fault of the deinterlacer, that has some latency, or because the flags themselves have some latency (this seems unlikely). For the average user that might be an issue, so here I vote for yes. On the other hand, deinterlace a pure progressive stream can cause artifacts, with also might be an issue. Here I vote for no. For those special, bad flagged streams the option is there, no need to deinterlace all videos played by ffdshow, another no here.

If those first frames after interlaced->progressive or progressive->interlaced changes can be fixed by modifying the code or something, another no.

tal.aloni

29th October 2008, 17:15

In that case, we don't even need the "SPDIF" option in the AC3/DTS combo box, right?

clsid

29th October 2008, 17:30

In that case, we don't even need the "SPDIF" option in the AC3/DTS combo box, right?
If SPDIF passthrough is enabled in the Output section, then the decoder setting in the Codecs section is effectively ignored. No need to have a spdif option in the dropdown there anymore.

SeeMoreDigital

29th October 2008, 17:35

clsid

29th October 2008, 17:36

tal.aloni

29th October 2008, 17:44

If SPDIF passthrough is enabled in the Output section, then the decoder setting in the Codecs section is effectively ignored. No need to have a spdif option in the dropdown there anymore.

Great, the result will be much more friendly.
I have all that I need to implement this. Albain, I would still be glad to hear your opinion.

Tal

tal.aloni

29th October 2008, 18:04

How about having these two options for the deinterlacing issue:

[ ] Deinterlace frames flagged as progressive (in mixed streams)
[ ] Deinterlace frames flagged as progressive (always)

1. There could be interlaced streams which have no single interlaced frame, like old HuffYUV streams, which are lossless, but don't contain interlaced information.

2. This should be easy to implement, but I don't like it. end users do not get incorrectly flagged mixed streams, except for a handful of badly authored DVDs, and the DVB crowd.

Tal

LoRd_MuldeR

29th October 2008, 19:24

end users do not get incorrectly flagged mixed streams, except for a handful of badly authored DVDs, and the DVB crowd.

...which includes a great part of the ffdshow users. Analog TV is dieing, DVB will become more and more important ;)

STaRGaZeR

29th October 2008, 19:49

How about having these two options for the deinterlacing issue:

[ ] Deinterlace frames flagged as progressive (in mixed streams)
[ ] Deinterlace frames flagged as progressive (always)

A stream classifies as 'mixed' if an interlaced frame has been encountered at least once.

If no streams exist that have interlaced parts, but have all frames flagged as progressive, then option #2 is not needed.

Bad workaround for mixed, imagine 10000 frames of progressive content. Only frame 50 is interlaced. Are you going to deinterlace from 50 to 10000?

With the current implementation in that same example you'll get progressive output until frame 49. Then you reach a interlaced frame, 50, but the deinterlacer is slow and can't properly do its job in time. Frame 50 is displayed with combing. Then frame 51 comes as progressive again, and it's showed as progressive. Result: no visible deinterlacing for frame 50, and a little jump. Now imagine a stream where the interlaced frames are 50, 100, 150..., or in groups of 3 frames 50-53, 100-103, 150-153... the rest is progressive (I have lots DVDs like that, even with 50-50% of progressive and interlaced in the main movie). It's a very bad situation, with combing and jumpy video caused every time a change between progressive and interlacing is reached. You can clearly see the effect with this sample (http://www.megaupload.com/?d=MPMULDNV). Check at scene changes, and if possible use MPC-HC's display stats to see the framerate changes and the jumps. The question is: is this fixable?

About the bad flagged streams the only proper solution is to force it always, I agree. ffdshow can't know if a certain stream is bad or not. Is in the hands of the user.

EDIT: it seems the jump only happens when hardware deinterlacing is used. With normal DI there is only combing.

tal.aloni

29th October 2008, 20:37

http://iknowu.net/files/public/ffdshow/Output.png

How about that?

Eragon4ever

29th October 2008, 21:11

Not good, the encode option has to be in the passthrough border, too. You could place the sample formats next to instead of on top of each other to gain some more room and then move the encode stuff in the correct border. Is LPCM an other format that can be send over SPDIF? If so it should be up there as well.

BTW, what do you plan to display in codecs tab if e.g. AC3 passthrough is selected? You can't display "libavcodec" or "liba52" because that would be wrong, same goes for "disabled".

tal.aloni

29th October 2008, 21:33

Not good, the encode option has to be in the passthrough border, too. You could place the sample formats next to instead of on top of each other to gain some more room and then move the encode stuff in the correct border. Is LPCM an other format that can be send over SPDIF? If so it should be up there as well.

Well, it seems that I have to revert to my original plan anyway, since I don't want to add two different output formats ("AC3 Passthrough" and "AC3 Encode") to the sample format enum / registry.

BTW, what do you plan to display in codecs tab if e.g. AC3 passthrough is selected? You can't display "libavcodec" or "liba52" because that would be wrong, same goes for "disabled".
"spdif".

Eragon4ever

29th October 2008, 21:36

"spdif"
Ah, ok. I thought you were going to remove that.

tal.aloni

29th October 2008, 22:04

OK, after I examined the code, I'm pretty sure that is the right way of doing it:
(the fact that I suggested it that way is just a coincidence, really!)

http://iknowu.net/files/public/ffdshow/Output2.png

Snowknight26

29th October 2008, 23:27

Too much blank space on the left.

tal.aloni

29th October 2008, 23:30

Too much blank space on the left.
True, I can relocate the LPCM to the left.

Eragon4ever

29th October 2008, 23:37

Can't get it to compile right now so here is a screenshot out of VS:

http://s2d1.turboimagehost.com/t/890867_snap0019.png (http://www.turboimagehost.com/p/890867/snap0019.png.html)

mrcorbo

30th October 2008, 05:02

@ Eragon4ever

I like that layout, though I'd move the output sample formats section to the top above the S/PDIF options. Seems very clear and intuitive.

tal.aloni

30th October 2008, 08:42

Eragon4ever,
I appreciate the time, but It's not very accurate:
LPCM has nothing to do with SPDIF,
DTS is pass-through only, while AC3 can have post processing done on it.
I think the seperation should be based on pass-through.

but like I said, the original design stores the supported formats in the same reg key. it would be unwise to store AC3 twice, so it's either my latest design, or creating a new pass-though key.

Tal

Edit:
I just figured The only way to pass through AC3, and encode everything else to AC3, is adding a seperate pass-through checkbox, so we'll go back to clsid's design.

SeeMoreDigital

30th October 2008, 10:00

Eragon4ever,
I appreciate the time, but It's not very accurate:
LPCM has nothing to do with SPDIF,LPCM bitstream audio can be passed via SPDIF. As can AAC and WMA Pro bitstreams. There are even amplifiers with WMA Pro decoding chip-sets...

tal.aloni

30th October 2008, 10:26

LPCM bitstream audio can be passed via SPDIF. As can AAC and WMA Pro bitstreams. There are even amplifiers with WMA Pro decoding chip-sets...

True, but the LPCM checkbox in ffdshow cannot be outputted to spdif. (you can output LPCM to spdif if you select every other PCM format).

albain

30th October 2008, 10:26

I'd rather see the SPDIF options in a separate box (not the same as the output sample format), because it is clearer and also in the future there will be more : bitstream TrueHD, bitstream DTS-HD

tal.aloni

30th October 2008, 12:17

I'd rather see the SPDIF options in a separate box (not the same as the output sample format), because it is clearer and also in the future there will be more : bitstream TrueHD, bitstream DTS-HD

like this, right?
(I'm positive this is the way to go, pass-through should be seperated from the output sample format like you said, especially if we consider future formats (both pass-trough and encoding))

http://iknowu.net/files/public/ffdshow/Output.png

tal.aloni

30th October 2008, 12:25

Not good, the encode option has to be in the passthrough border, too. You could place the sample formats next to instead of on top of each other to gain some more room and then move the encode stuff in the correct border.

Well, the new plan is to sepeate between formats that will be post-processed, and formats that won't (pass-through).
pass-through formats will have priority if selected, and that's why they are on top.

Edit:
please note that the suggested modifications should give us some new functionality, for example:
+ the ability to have a preset that have DTS Pass-through only, and a preset that have AC3 pass-through only. (it was double or nothing up until today)
+ the ability to encode DTS to AC3 and pass-through AC3 in one preset and pass-through both in another.

albain

30th October 2008, 12:48

like this, right?
(I'm positive this is the way to go, pass-through should be seperated from the output sample format like you said, especially if we consider future formats (both pass-trough and encoding))

http://iknowu.net/files/public/ffdshow/Output.png

I think this is the best layout

Also, SPDIF will disappear from the AC3/DTS codec section.

Lastly, if AC3/DTS codec are set to disabled, no decoding and no passthrough will be applied (FFDShow won't be used).

Do we all agree on this layout and new rules ?

@tal.aloni : are you ready to implement this or you'd rather let one of us code ?

tal.aloni

30th October 2008, 13:06

SPDIF will disappear from the AC3/DTS codec section.

exactly, the checkbox as well.

Lastly, if AC3/DTS codec are set to disabled, no decoding and no passthrough will be applied (FFDShow won't be used).

of course.

Do we all agree on this layout and new rules ?

I do.

@tal.aloni : are you ready to implement this or you'd rather let one of us code ?
I'm already on it.

haruhiko_yamagata

30th October 2008, 13:58

The new dialog looks good.
@tal.aloni : please remember to support upgrade install from global settings to preset settings.

tal.aloni

30th October 2008, 15:20

The new dialog looks good.
@tal.aloni : please remember to support upgrade install from global settings to preset settings.

Is there a specific place in which I can transform the registry settings after the upgrade?
(I presume the "AC3 > spdif" setting will be replaced with other value, like "AC3 > liba52")

Edit:
I should do it in ffdshow_installer.iss, right?

albain

30th October 2008, 17:32

Is there a specific place in which I can transform the registry settings after the upgrade?
(I presume the "AC3 > spdif" setting will be replaced with other value, like "AC3 > liba52")

Edit:
I should do it in ffdshow_installer.iss, right?

Yes, you have to update ffdshow_installer.iss, but also the global settings : I see only one global setting to migrate to a preset setting, i.e the checkbox under in codec section "Use SPDIF when AC3 selected".

Also, all the code that accesses to CODEC_ID_SPDIF_AC3 and CODEC_ID_SPDIF_DTS (a global grep should do it) must be reviewed to take in account the preset settings + the codecId, unless you change the codecId before these tests occur.

For example, replace all the "if codecId==CODEC_ID_SPDIF_AC3"
by
if ((codecId==CODEC_ID_LIBA52 || codecId==CODEC_ID_AC3) && is_ac3_spdif_passthrough())

Last thing, that is tricky : in TaudioParser.cpp, I test if codecId for AC3 is set to SPDIF. However, this test is not based on the current codecId (which can be MLP/TrueHD), but according to the codecId assigned to the AC3 waveformat (WAVE_FORMAT_AC3_W)

So the test must be replaced by :
if (globalSettings->getCodecId(WAVE_FORMAT_AC3_W,NULL) != CODEC_ID_NONE && is_ac3_spdif_passthrough())...

Same thing for DTS.

Don't hesitate to tell me if you need some help

STaRGaZeR

30th October 2008, 18:29

I can confirm libav glitches with MP3. This (http://unigine.com/download/video/Unigine_Tropics_1024x576.avi) sample is full of them. No problems with libmad.

albain

30th October 2008, 19:25

I can confirm libav glitches with MP3. This (http://unigine.com/download/video/Unigine_Tropics_1024x576.avi) sample is full of them. No problems with libmad.

Do you have the same gildtches with mplayer using libavcodec ?

STaRGaZeR

30th October 2008, 20:11

Nope, MPlayer plays it fine. Also, If I demux it libav decodes it with no problems.

tal.aloni

30th October 2008, 20:40

How can I access current preset information from TaudioParser.cpp?
(everything else is working already)

Thanks,
Tal

albain

30th October 2008, 21:32

How can I access current preset information from TaudioParser.cpp?
(everything else is working already)

Thanks,
Tal

With deci you have access to all the parameters :

Example :
deci->getParam2(IDFF_ac3SPDIF) for an int value
deci->getParamStr(...) for a string value

tal.aloni

30th October 2008, 22:05

Thanks,
deci->getParam2(IDFF_aoutpassthroughsfs) return always 0, but the registry value associated is not 0. any idea what am I doing wrong? (inside the "init" method)

even existing values, like deci->getParam2(IDFF_outsfs) returns 0.

Edit: it's working inside "getCodecIdFromStream" method, can anyone explain?

Thanks,
Tal

haruhiko_yamagata

30th October 2008, 23:41

tal.aloni

31st October 2008, 00:22

I don't know where you have inserted the code, but probably before preset settings are loaded.
Preset settings are loaded later (at the end of connecting) and we can't move this to earlier stage.
And that's why codec settings cannot belong to preset settings.

Thanks, I managed to do it another way.
I have finished with the changes, and it's working flawlessly.
the only task left is the registry update during the setup,
the idea is to turn on AC3 passthrough if one has selected
AC3 > spdif, or has selected 'Use SPDIF when AC3 output set'.
(possibly, only in presets where AC3 output is set)
after that, we need to set AC3 > liba52 and delete the 'Use SPDIF when AC3 output set' reg key. same for DTS.

passthroughsfs (the preset reg key for pass-through sample formats supported) equals 1 when AC3 is set, 2 when DTS is set and 3 when both are set.

can somebody write / assist in making the necessary modifications to the install script?

Thanks,
Tal

p.s. along the way, I found an old bug:
DTS extracted from DTS-Waves are played back too fast when using DTS pass-through (48 instead of 44.1).

DigitalDeviant

31st October 2008, 02:01

I'm trying to use TIVTC on a few mixed film/hard telecine discs with r2265 and it seems that "apply pulldown" in the avisynth section doesn't work anymore. Is it really broken or am I doing something wrong?

albain

31st October 2008, 09:34

Thanks, I managed to do it another way.
I have finished with the changes, and it's working flawlessly.
the only task left is the registry update during the setup,
the idea is to turn on AC3 passthrough if one has selected
AC3 > spdif, or has selected 'Use SPDIF when AC3 output set'.
(possibly, only in presets where AC3 output is set)
after that, we need to set AC3 > liba52 and delete the 'Use SPDIF when AC3 output set' reg key. same for DTS.

passthroughsfs (the preset reg key for pass-through sample formats supported) equals 1 when AC3 is set, 2 when DTS is set and 3 when both are set.

can somebody write / assist in making the necessary modifications to the install script?

Thanks,
Tal

p.s. along the way, I found an old bug:
DTS extracted from DTS-Waves are played back too fast when using DTS pass-through (48 instead of 44.1).

Otherwise you can update it later (i.e the first time the parser receives a buffer).

Concerning DTS, I was not aware of this, I thought that I had fixed this : DTS in wav can have 96,48 or 44khz (even if 44 is the most common)

Concerning the installer, you can PM the patch and I will make the necessary modifications and send back an updated patch

SeeMoreDigital

31st October 2008, 09:40

Would something like this be practical/make sense to users: -

http://i33.tinypic.com/2vd01lu.png

Cheers

tal.aloni

31st October 2008, 10:16

Would something like this be practical/make sense to users:

No. the whole point is to move the output options (spdif included) to the output tab, and make them based on presets.

albain

31st October 2008, 10:55

Yes, the goal is to be able to switch the configuration with different presets, which is not possible inside codec section because these settings are static

DigitalDeviant

31st October 2008, 13:21

Leak

31st October 2008, 14:18

I narrowed it down to something changing in between r2228 and r2253.
I'm pretty sure that's caused by r2236 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2236) - flagging soft telecined material as progressive is nice when the flags were set properly in the first place so that removing them will correctly yield progressive video, but it absolutely breaks "Apply pulldown" which relies (obviously) on the frames being flagged as interlaced and will of course produce artifacts if the flags are set wrong... :(

What would be needed here would be TvideoCodecLibmpeg2's SetDeinterlaceMethod flagging a frame as progressive and still setting the TFF/BFF flags - which should be possible, since they're separate bits in an enum.

So in most places the INT_TFF/INT_BFF bits should be just ignored when PROGRESSIVE_FRAME bit is set, but in the AviSynth filter "Apply Pulldown" would instead ignore PROGRESSIVE_FRAME in favour of the interlacing bits...

What do you think, Haruhiko?

EDIT: Come to think of it - shouldn't there be an option on the output page what to do with telecined video? I.e. an option to choose which flags to discard when both PROGRESSIVE_FRAME and TFF_?FF are set, as I'm sure some people (like those using TV out) would like telecined material to be flagged interlaced all the way to the renderer...

lucassp

31st October 2008, 15:21

Does FFDShow flag DV content as interlaced so that the VMR deinterlacer can do the deinterlacing?

tal.aloni

31st October 2008, 23:17

It took much more than expected, mostly because of the setup part, but here it is:

+ AC3 / DTS pass-through is now based on presets.

the new settings will be applied automatically during the setup (this was the most practical place)for the 'default' preset based on the old settings. (I'm guessing 99.9% of the users have a single preset).
if other presets exist, the pass-through settings will be disabled by default. that's unfortunate, but that's the best I can do. (again, we are talking about a group of sophisticated users, who use both 2 presets and SPDIF, they are the ones who will appreciate the new flexibility the most).

patch:
http://iknowu.net/files/public/ffdshow/2273-Passthrough-RC2-Patch.zip

here is a build as well, but it's built using MSVS-2005 , so the performance is not so good:

http://iknowu.net/files/public/ffdshow/ffdshow_rev2273_20081031-Pass-Through-RC2.exe

Note:
during testing, I found two bugs that were inherited from previous versions:
* 44,100hz DTS files are played back too fast when passed-through.
* DTS-WAV files playback result in "clicks" when passed-through.

I lack the knowledge needed to solve those issues.

Thanks to those who helped (the usual suspects),
Tal

haruhiko_yamagata

1st November 2008, 10:07

I'm pretty sure that's caused by r2236 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2236) - flagging soft telecined material as progressive is nice when the flags were set properly in the first place so that removing them will correctly yield progressive video, but it absolutely breaks "Apply pulldown" which relies (obviously) on the frames being flagged as interlaced and will of course produce artifacts if the flags are set wrong... :(

What would be needed here would be TvideoCodecLibmpeg2's SetDeinterlaceMethod flagging a frame as progressive and still setting the TFF/BFF flags - which should be possible, since they're separate bits in an enum.

So in most places the INT_TFF/INT_BFF bits should be just ignored when PROGRESSIVE_FRAME bit is set, but in the AviSynth filter "Apply Pulldown" would instead ignore PROGRESSIVE_FRAME in favour of the interlacing bits...

What do you think, Haruhiko?OK, I'll flag PROGRESSIVE_FRAME | INT_TFF/INTBFF there and ignore INT_TFF/INT_BFF when sending them to downstream.

EDIT: Come to think of it - shouldn't there be an option on the output page what to do with telecined video? I.e. an option to choose which flags to discard when both PROGRESSIVE_FRAME and TFF_?FF are set, as I'm sure some people (like those using TV out) would like telecined material to be flagged interlaced all the way to the renderer...
Oh, yes that was me who connected 1080i projector and forgot about it.
Could you implement this?
And even better average timestamps without requiring the help of AviSynth filter.

I have to finish yadif. It works for most files, but does not work for DVDs. I have understood why you have suffered that much on implementing the new AviSynth filter. I'll need your help.

tal.aloni

1st November 2008, 10:47

Leak

1st November 2008, 11:04

OK, I'll flag PROGRESSIVE_FRAME | INT_TFF/INTBFF there and ignore INT_TFF/INT_BFF when sending them to downstream.
Sounds good - and I think you've got more experience where those flags are checked than me... :)

Oh, yes that was me who connected 1080i projector and forgot about it.
Could you implement this?
How about adding a checkbox "Flag soft telecined video as progressive" to the output page? If it's checked, the INT_?FF flags will be discarded, and if it isn't checked the PROGRESSIVE_FRAME flag will be discarded instead - but of course only in case both are set.

I'll do that tomorrow if nobody objects...

And even better average timestamps without requiring the help of AviSynth filter.
I've always been thinking about turning the 3:2 pulldown part of the AviSynth filter into it's own "3:2 pulldown" filter - how about that?

The config page would have a checkbox to (de-)activate the filter and two radio buttons for "Apply pulldown" and "Smooth timestamps".

All it needs is to buffer the last frame, so it shouldn't be hard to do..

I have to finish yadif. It works for most files, but does not work for DVDs. I have understood why you have suffered that much on implementing the new AviSynth filter. I'll need your help.
Just ask away... :)

np: Uusitalo - Karhunainen (Karhunainen)

haruhiko_yamagata

1st November 2008, 12:43

It took much more than expected, mostly because of the setup part, but here it is:
I knew it would be much harder than just implementing the feature. All the more I asked you.

+ AC3 / DTS pass-through is now based on presets.

the new settings will be applied automatically during the setup (this was the most practical place)for the 'default' preset based on the old settings. (I'm guessing 99.9% of the users have a single preset).
if other presets exist, the pass-through settings will be disabled by default. that's unfortunate, but that's the best I can do. (again, we are talking about a group of sophisticated users, who use both 2 presets and SPDIF, they are the ones who will appreciate the new flexibility the most).
I think we should not come to a compromise. It's just very hard, not impossible. Was it really impossible for you?

albain

1st November 2008, 12:51

I was thinking of renaming the "Dolby Decoder" tab to "Extended Decoding" and move the decoder DRC setting there (so it will be preset based, and also slider based)
[with an appropriate label, like "Enable decoder dynamic range compression if available"]
I think that one slider for both AC3 and DTS is sufficient.

what do you say?

I agree it would be great.

Concerning the DTS in wav problem, I will dig this around when I will have the equipment to test it (by the end of the week-end). In the meantime, we can apply your patch (if other admins agree).
I have tested it on my side and it works.

tal.aloni

1st November 2008, 13:04

I think we should not come to a compromise. It's just very hard, not impossible. Was it really impossible for you?

I have dug more into the Inno setup documentation, and I found a way,
now the upgrade is entirely automatic.

Here is the updated patch:
http://iknowu.net/files/public/ffdshow/2273-Passthrough-RC4-patch.zip

build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2273_20081031-Pass-Through-RC4.exe

clsid

1st November 2008, 13:23

nautilus7

1st November 2008, 13:31

albain, 7.1 TrueHD work now. Thanks.

rickardk

1st November 2008, 14:08

ACrowley

1st November 2008, 14:16

albain, 7.1 TrueHD work now. Thanks.

which build do you mean ? i cant see a new build from albain on the last pages ?

i think i mised some updates ? TrueHD into m2ts is working now when i seek forward in bigger Steps. It wasnt working with older builds, because the Audio stops with some distortions etc
Now its fine :)

nautilus7

1st November 2008, 14:24

It's not by albain. It's from here: http://xvidvideo.ru

Eragon4ever

1st November 2008, 14:30

The audio branch has been imported to trunk so any rev2253+ trunk builds contain the new codecs. The 7.1 TrueHD fix was at rev2266.

ACrowley

1st November 2008, 15:06

The audio branch has been imported to trunk so any rev2253+ trunk builds contain the new codecs. The 7.1 TrueHD fix was at rev2266.

thx 4 info, i use ffdshow_rev2275_20081101_clsid.

DrKnowLittle

1st November 2008, 16:58

I have a small subtitle request that I think would benefit most users. When having a movie with embedded subs it always takes priority over any external subtitle file nomatter what order one set in the "Extensions Priority" list. I would like to see a "Use Internal subs only if no external is found" checkbox or even better "fix" the priority list to include a "internal" tag so one could choose whatever is best.

Other than that I can't see how ffdshow_tryouts can get any better :thanks::thanks:

LotharZ

1st November 2008, 22:17

I have an small sugestion, now that there are some improves over embedded subtitles.
What about to add an option to override the font that comes with some movies and change their size?
That could be useful when they have some unreadable or extremely ugly font.

thx

avivahl

1st November 2008, 23:31

haruhiko_yamagata

1st November 2008, 23:34

I don't think it is really needed to support an upgrade path for non-default profiles. Sure it is possible, with InnoSetup pascal code you can do pretty much everything, but imho it is a waste of time. Power users should be able to figure out what to do themselves. Many users re-install ffdshow instead of updating anyway. Too much non-essential backwards compatibility just creates a mess.
I'm against your opinion. Less than 0.1% of users are reading here. If they suddenly loose output from SPDIF, they will waste their time a lot. If they are unlucky, they will loose more than one hour until they find it. And naturally stop using ffdshow.

His code isn't messy at all. It's quite readable.

LoRd_MuldeR

2nd November 2008, 00:08

I saw that Yadif is available as a "built-in" deinterlacer in MT-branch builds. Since I use Yadif a lot, I'd like to see that feature in "regular" builds. Are there any plans?

Yes, I know that I can use Yadif via Avisynth. But it takes quite some time to load up the Avisynth environment. So I'd prefer the internal version...

Anima123

2nd November 2008, 04:08

I was thinking of renaming the "Dolby Decoder" tab to "Extended Decoding" and move the decoder DRC setting there (so it will be preset based, and also slider based)

"Dolby Decoder" will be activated even the in stream is just plain stereo. How about add an option to bypass "Dolby Decoder" when there's no rear channel within the in stream no matter it's been chosen or not?

haruhiko_yamagata

2nd November 2008, 04:32

I have dug more into the Inno setup documentation, and I found a way,
now the upgrade is entirely automatic.

Here is the updated patch:
http://iknowu.net/files/public/ffdshow/2273-Passthrough-RC4-patch.zip

build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2273_20081031-Pass-Through-RC4.exe
Thanks for the fix.
if (presetList[index] <> 'default') thenActive preset should be gotten from ffdshow_audio/activePreset in the registry. If it fails default to 'default'.

The installer still list "SPDIF" below AC3 and DTS, but does nothing if I change it to "SPDIF".

haruhiko_yamagata

2nd November 2008, 04:33

I saw that Yadif is available as a "built-in" deinterlacer in MT-branch builds. Since I use Yadif a lot, I'd like to see that feature in "regular" builds. Are there any plans?
Yes, of course. Please read a few posts above (http://forum.doom9.org/showthread.php?p=1208719#post1208719).

LoRd_MuldeR

2nd November 2008, 05:17

Yes, of course. Please read a few posts above (http://forum.doom9.org/showthread.php?p=1208719#post1208719).

Allright :)

I think the remaining problem may be the cause of the problems discussed here:
http://forum.doom9.org/showthread.php?p=1208165#post1208165

Post #16 and following...

Snowknight26

2nd November 2008, 07:10

I've had these two related problems for a while now, both with my Tiesto Blu-ray (AVC, 1080i, 25fps):

When ffdshow is set to decode H.264, the Movie FPS reports 108.660fps, decodes very poorly (decoder fps is ~17) and is very much out of sync.
When MPC-HC's decoder is used, its played at 25fps.
When MPC-HC's decoder is used with ffdshow set to decode raw video, Movie FPS says 25fps, but yet again, decodes very poorly (decoder fps is ~17) and is very much out of sync.

Sample: http://www.stfcc.org/misc/00000.cut.m2ts

shambles

2nd November 2008, 13:51

That's right, I made an internal parser that strips off AC3 frames from TrueHD streams (if there are), but only if AC3 codec is set to SPDIF. In that case the truehd part is not decoded at all

i tried/want to set up ffdshow so that with truehd+ac3, truehd is decoded, but with vanilla ac3, spdif is used

would be awesome if an option to do that was included in a future build :)

haruhiko_yamagata

2nd November 2008, 14:36

STaRGaZeR

2nd November 2008, 15:19

i tried/want to set up ffdshow so that with truehd+ac3, truehd is decoded, but with vanilla ac3, spdif is used

would be awesome if an option to do that was included in a future build :)

Have you tried with TrueHD decoder enabled and AC3 enabled but with SPDIF output?

Mercury_22

2nd November 2008, 15:38

I really, really like the new ffmpeg-mt branch but can someone update it with the new audio codecs / trunk ? :thanks: :helpful:

shambles

2nd November 2008, 16:53

Have you tried with TrueHD decoder enabled and AC3 enabled but with SPDIF output?

yes but that just strips off the truehd blocks and passes the interleaved ac3 through

STaRGaZeR

2nd November 2008, 17:10

yes but that just strips off the truehd blocks and passes the interleaved ac3 through

It shouldn't, if TrueHD is selected ThueHD blocks will be decoded. What splitter are you using? Currently only MPC-HC's MPEG PS/TS/PVA supports it, if you use Haali's for example it will only send the interleaved AC3 to the decoder.

shambles

2nd November 2008, 17:35

haali doesn't send any audio on this box when playing back truehd+ac3 m2ts, so yes i'm using the mpc-hc splitter.

it does decode truehd when setting both mlp and ac3 to libavcodec, but not when ac3 is set to spdif

albain

2nd November 2008, 20:23

It shouldn't, if TrueHD is selected ThueHD blocks will be decoded. What splitter are you using? Currently only MPC-HC's MPEG PS/TS/PVA supports it, if you use Haali's for example it will only send the interleaved AC3 to the decoder.

Actually no, if AC3 is set to SPDIF, then AC3 blocks are stripped off and sent to SPDIF.

I realize that it would be better to have an option

STaRGaZeR

2nd November 2008, 21:15

Oh so the SPDIF option has priority over the enabled/disabled of TrueHD. Yes, and option would be nice.

tal.aloni

2nd November 2008, 21:17

ffdshow_audio/activePreset in the registry. If it fails default to 'default'.

Didn't know that. is passing on all the subkeys has some consequences I'm unaware of?

The installer still list "SPDIF" below AC3 and DTS, but does nothing if I change it to "SPDIF".
I didn't remember that menu, I'll take care of it. (remove spdif from there, pass-through is listed below)

Thanks,
Tal

tal.aloni

2nd November 2008, 21:28

Actually no, if AC3 is set to SPDIF, then AC3 blocks are stripped off and sent to SPDIF.

I realize that it would be better to have an option

It should be the other way around,
if MLP decoding will be enabled, AC3 pass-through will not be used on TrueHD.
only if MLP is disabled, you'll have AC3 pass-through (if selected).

Agreed?

Mercury_22

2nd November 2008, 22:38

Can ffmpeg-mt branch be compiled to 64-bit with MinGW64 ? :helpful:

haruhiko_yamagata

3rd November 2008, 02:32

Didn't know that. is passing on all the subkeys has some consequences I'm unaware of?
"default" is hard coded all around the setup script. This is not your fault.

I didn't remember that menu, I'll take care of it. (remove spdif from there, pass-through is listed below):thanks:

haruhiko_yamagata

3rd November 2008, 02:36

Can ffmpeg-mt branch be compiled to 64-bit with MinGW64 ? :helpful:Yes I can, if I disable multithreading :p .
pthread library is available from MinGW64 (https://sourceforge.net/projects/mingw-w64), so it shouldn't be too hard. I don't have time now though.

STaRGaZeR

3rd November 2008, 02:58

How about adding a checkbox "Flag soft telecined video as progressive" to the output page? If it's checked, the INT_?FF flags will be discarded, and if it isn't checked the PROGRESSIVE_FRAME flag will be discarded instead - but of course only in case both are set.

I'll do that tomorrow if nobody objects...

I've always been thinking about turning the 3:2 pulldown part of the AviSynth filter into it's own "3:2 pulldown" filter - how about that?

The config page would have a checkbox to (de-)activate the filter and two radio buttons for "Apply pulldown" and "Smooth timestamps".

All it needs is to buffer the last frame, so it shouldn't be hard to do...

How about this Leak? VERY useful.

CraziFuzzy

3rd November 2008, 05:02

Here's a crazy idea I'm mulling about. I've got a Samsung DLP television, that uses TI's 'wobulation' display method. Basically, it's kind of the 'new' interlacing, in that the 1920x1080x60Hz picture received from the source (in this case, my HTPC) is actually displayed one half-checkerboard at a time, at 120Hz. (So of the 1920x1080 image, every other pixel is drawn, then 1/120th of a second later, the other pixels are drawn). My idea here is that this might allow a well designed filter to take a 24fps film source, and sort of 'checker-telecine' it, so that what is viewed is smooth 24Hz, without the stutter problems of going to 60Hz. Does anyone think this is a possibility?

The TV does do this internally if it is given a 1080p/24 source, but I have had problems getting my HTPC to switch between 24p and 60p output reliably, and based on source.

Leak

3rd November 2008, 09:46

How about this Leak? VERY useful.
Well, I meant to do that yesterday, but after spending half the day setting up MinGW and getting it to compile the parts of ffdshow that need to be compiled with GCC I just couldn't do it anymore... so please give me another day or two... :)

STaRGaZeR

3rd November 2008, 11:06

All you need like always :D

tal.aloni

3rd November 2008, 13:05

avivahl

3rd November 2008, 13:12

Did you guys know that ffdshow has a dolby pro-logic II decoder?
it was hidden so well under the "Dolby decoder" title,
I though in the past that this was AC3 related,
I had to dig into the source to find out what it is.

It seems to me that when activating this options,
it works on every source, not just stereo.
this seems odd, since there are only stereo "Dolby surround" tracks, and the algorithm is quite useless on every other type of track anyway. (It will sound very odd on mono sources, and will ignore every other channel except the FR & FR when source > 2-channels)

I intend to modify this so it will only be applied to 2-channel sources only, does anyone object?

also, I intend to rename it to "Dolby pro-logic II decoder".

TalHeh, I always wondered what that filter is. :)
"Dolby Pro Logic II Decoder" (capitalized) is nicer.
Would be nice if that filter would also have a small explanation regarding what it actually does (like here (http://www.dolby.com/consumer/technology/prologic_II.html)).

clsid

3rd November 2008, 13:31

Well, I meant to do that yesterday, but after spending half the day setting up MinGW and getting it to compile the parts of ffdshow that need to be compiled with GCC I just couldn't do it anymore... so please give me another day or two... :)I have a custom installer for MinGW that allows you to setup a working environment in a few seconds. I'll upload it for you.

Edit: see opening post.

nautilus7

3rd November 2008, 13:34

I intend to modify this so it will only be applied to 2-channel sources, does anyone object?
From what i know, DPL II can upmix any source to 5.1 and DPL IIx to 7.1. If you restrict this to 2.0 (2/0/0) only, then 2/0/1, 3/0/0, 3/0/1, 3/1/0 and 3/1/1 wont work.

_xxl

3rd November 2008, 13:39

I have a custom installer for MinGW that allows you to setup a working environment in a few seconds.
Please post a link to first post.

tal.aloni

3rd November 2008, 13:59

From what i know, DPL II can upmix any source to 5.1

Wrong, here is a quote from the dolby web-site:

Dolby® Pro Logic® II technology processes any high quality stereo (two-channel) movie and music audio into five playback channels of full-bandwidth surround sound.

DPL IIx can only be applied to 2.0 and 5.1 (dolby web-site again), but we don't have DPL IIx decoder.

Tal

nautilus7

3rd November 2008, 14:10

Ok then, go on!

DrKnowLittle

3rd November 2008, 15:03

haruhiko_yamagata

3rd November 2008, 15:30

Thunderbolt8

3rd November 2008, 15:40

got some questions regarding multi core support:

-interlaced AVC files arent multi core supported yet I guess? I have an interlaced H264 skyHD cap, which stutters because the cpu usage is 100% on the one and ~15% on the other core (got a c2d @2,8ghz), without even having deinterlacing activated. with coreavc its both around 50%.

-in which other cases is dual/multi core usage support not yet established?

-I guess there are no differences between 2 and 4 cores, e.g. when something is multicore supported then its (somewhat) evenly distributed among the number of cores, no matter if 2 or 4?

_xxl

3rd November 2008, 15:44

You could test ffdshow compiled from ffmpeg-mt trunk.
From trunk ffdshow's h.264 decoder isn't mt for interlaced files.

DrKnowLittle

3rd November 2008, 15:47

@DrKnowLittle
You can use external subtitles if you uncheck "Accept embedded subtitles".
It's not difficult to implement. Main problem is that the dialog is too crowded.
Little space to add one more check box "Prioritize external subtitles".
Even if we can, it makes the dialog more messy.
ffdshow already has too many options without proper documentation.
I don't want to lead users to more confusion.

I can understand the confusion part :)
I know I can use external subtitles but I wan't to be able to use both w/o having to change my config everytime I start a movie.

If I have a movie with let say embedded"English" subtitles and a .srt subtitle file in my native tounge (swedish) ffdshow will always display the embedded one , in my opinion it would be more logic to first use external if exists and then internal, it doesen't even have to be a setting just a change in the current behavior.

Or adding "embeeded" to the priority list like this
"embedded;utf;idx;sub;srt;smi;rt;txt;ass;ssa;aqt;mpl;usf"
would not change the layout of the dialog.

Br
DrKnowLittle

clsid

3rd November 2008, 15:56

A wiki for ffdshow was setup some time ago. It is pretty much empty right now. Everyone that wants to write some documentation, feel free to do so.

http://ffdshow-tryout.wiki.sourceforge.net/

CraziFuzzy

3rd November 2008, 16:01

Did you guys know that ffdshow has a dolby pro-logic II decoder?
it was hidden so well under the "Dolby decoder" title,
I though in the past that this was AC3 related,
I had to dig into the source to find out what it is.
(I intend to rename it to "Dolby pro-logic II decoder")

also, when activating this option, it works on every source, not just stereo.
this seems odd, since there are only stereo "Dolby surround" tracks, and the algorithm is quite useless on every other type of channel number anyway. (It will sound very odd on mono sources, and will ignore every other channel except the FR & FR when source > 2-channels)

I intend to modify this so it will only be applied to 2-channel sources, does anyone object?

Tal

Perhaps the best solution would be to add a "Only Process 2-Channel Sources" checkbox to the Dolby Decoder filter, so those that still want the processing on higher channel streams could still use it. (It's not like adding a checkbox to that filter would be too cluttered).

I would definitely like this feature though, as I currently just have it always on, and I know it does degrade the separation on the already 5.1 tracks. Basically using this would allow you to get the closest to the intended surround image, as those streams that are Dolby encoded on stereo would be decoded properly, and those that are 5.1 would still be correct. This behavior would be much closer to that of a typical surround receiver.

Leak

3rd November 2008, 16:31

I have a custom installer for MinGW that allows you to setup a working environment in a few seconds. I'll upload it for you.
Thanks, but it's too late already - I figured it out yesterday...

Stable MSYS + TDM's 4.2.4 GCC packages + assorted stuff = compile win :)

(It wasn't just MinGW, actually - I also had to clean up my local SVN repository and import a fresh copy of ffdshow's trunk...)

But I guess there'll always be others that will have use for your installer. :)

tal.aloni

3rd November 2008, 16:45

Perhaps the best solution would be to add a "Only Process 2-Channel Sources" checkbox to the Dolby Decoder filter, so those that still want the processing on higher channel streams could still use it. (It's not like adding a checkbox to that filter would be too cluttered).

I don't believe that streams that require such checkbox exist. (5.1 with silent 3.1 and 2.0 encoded as dolby surround). If someone will prove me wrong, I would add such checkbox.
IMO, the probability of a user twisting the decoding process because of an unneeded checkbox is too high to justify it.

Tal

tal.aloni

3rd November 2008, 18:13

DigitalDeviant

3rd November 2008, 18:17

But I guess there'll always be others that will have use for your installer. :)

I'd like to have that please.

Eragon4ever

3rd November 2008, 18:19

The link has been edited into the first post.

Thunderbolt8

3rd November 2008, 23:32

You could test ffdshow compiled from ffmpeg-mt trunk.
From trunk ffdshow's h.264 decoder isn't mt for interlaced files.
what does mt mean here? :)

Snowknight26

4th November 2008, 00:24

Multithreaded.

haruhiko_yamagata

4th November 2008, 11:31

OK, Fifth Time's the Charm.

Here is the updated patch:
http://iknowu.net/files/public/ffdshow/2273-Passthrough-RC5.patch

Build (MSVC-2005):
http://iknowu.net/files/public/ffdshow/ffdshow_rev2273_20081031-Pass-Through-RC5.exe

+ AC3 / DTS pass-through is now based on presets.

+ When MLP decoding is enabled, AC3 pass-through will not be used on TrueHD sources.
(if you want to pass-through the AC3 core of TrueHD, disable MLP decoding)

Tal
After installing your build, if I check AC3 and DTS in "Pass-through (SPIDF,HDMI), and re-install your build, the tasks are not checked.
Also they are unchecked in the configuration dialog. :thanks:

tal.aloni

4th November 2008, 12:17

haruhiko_yamagata

4th November 2008, 13:40

Sorry, my bad,
Here is an updated patch:
http://iknowu.net/files/public/ffdshow/2273-Passthrough-RC6.zip

build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2273_20081031-Pass-Through-RC6.exe

Thanks,
Tal
Installer is OK :) .
static const int spdifs[]={IDC_CHB_PASSTHROUGH_AC3, IDC_CHB_PASSTHROUGH_DTS, IDC_CHB_OUT_AC3,IDC_LBL_OUT_AC3,IDC_CBX_OUT_AC3,IDC_CHB_AOUT_AC3ENCODE_MODE,0};
enable(lavc && lavc->ok && !lavc->dec_only,spdifs);
Not a big thing, but SPDIF pass through should be possible even if libavcodec.dll is not found.
S/PDIF encode mode depends on libavcodec.

By the way, which do we user SPDIF or S/PIDF?

clsid

4th November 2008, 13:59

S/PDIF is the correct name. But people commonly write it as SPDIF. Both are currently used throughout ffdshow. That should at least be made consistent.

tal.aloni

4th November 2008, 15:22

Not a big thing, but SPDIF pass through should be possible even if libavcodec.dll is not found.
S/PDIF encode mode depends on libavcodec.
my mistake, thanks. (fixed now)

By the way, which do we use SPDIF or S/PDIF?
you both are right, I have replaced it with S/PDIF.

Here is an updated patch (lucky number 7):
http://iknowu.net/files/public/ffdshow/2281-Passthrough-RC7.zip

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2281_20081031-Pass-Through-RC7.exe

Tal

Inventive Software

4th November 2008, 19:36

Seems ffdshow-tryouts is going through a good phase at the moment!

Congrats haruhiko on getting a commit into libavcodec too! :)

haruhiko_yamagata

5th November 2008, 10:47

Congrats haruhiko on getting a commit into libavcodec too! :)Yes, I did it. :thanks:

haruhiko_yamagata

5th November 2008, 11:15

my mistake, thanks. (fixed now)

you both are right, I have replaced it with S/PDIF.

Here is an updated patch (lucky number 7):
http://iknowu.net/files/public/ffdshow/2281-Passthrough-RC7.zip

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2281_20081031-Pass-Through-RC7.exe

Tal
The patch is OK for me.
@albain
Could you review and commit?

albain

5th November 2008, 15:27

I have tested it successfully on my setup.

EDIT : files committed to revision 2298.
Thank you Tal Aloni !

tal.aloni

5th November 2008, 16:16

Thank you Tal Aloni !
No, Thank you!
(gone are the days when I have to switch codecs / remux with eac3to to play my files :))

Tal

EDIT:
Albain, it appears like you have commited an earlier version of the patch,
the 2 latest changes aren't there (SPDIF -> S/PDIF and the ommited check to see if libav is present when passing-through).
here is a complementary patch:
http://iknowu.net/files/public/ffdshow/2298-Passthrough-Complementary.zip

Thanks, and sorry for the trouble.
Tal

albain

5th November 2008, 21:44

Okay, this is done now

Thunderbolt8

6th November 2008, 21:59

can someone please tell me the exact path where I can upload files on the ffmpeg sample server? I posted a problematic file sample, but it was hosted on a public fileserver and is gone now. I'm not really familiar with the locations on ffmpeg, so can anyone please show me a direct upload path? thanks!

clsid

6th November 2008, 22:42

http://ffmpeg.org/bugreports.html

tal.aloni

6th November 2008, 23:39

Thunderbolt8

7th November 2008, 00:24

http://ffmpeg.org/bugreports.html
that didnt help me, because I already posted the issue there, its here: https://roundup.mplayerhq.hu/roundup/ffmpeg/issue378

my problem was that someone uploaded it to issue378/incoming, but I couldnt find such directory to upload, as im not familiar with the server structure there.
however, I just checked the video again and the issue is solved by now (which is a bit strange, because it still wasnt like 1 month after that message had been posted). thanks to those who helped with it!

haruhiko_yamagata

7th November 2008, 12:24

I've modified some labels to improve user friendliness:
"Dolby decoder" -> "Apply Dolby Pro Logic II decoding to all stereo sources" (was already limited to stereo, I haven't noticed)

Mixer:
"Voice control" -> "Expand stereo to center"
"Expand stereo" -> "Expand stereo to surround"
"Voice" -> "Center"

Video output:
added tooltip to explain about the new "forced weave / bob".

http://iknowu.net/files/public/ffdshow/2302-BetterLabels.zip

Tal
The patch is OK for me except a minor fix.
addHint(IDC_CBX_OUT_HWDEINT_METHOD,_l("Auto: according to source flags, bob for interlaced frames, weave for progressive frames.\n")
_l("Force weave: weave for each frame, regardless of source flags.\n")
_l("Force bob: bob for each frame, regardless of source flags.\n\n")
_l("Note: In most cases, Weave is the same as unchecked \"Set interlace flag in output media type\"."));

I'll commit tomorrow, if there is no objection.

clsid

7th November 2008, 13:33

that didnt help me, because I already posted the issue there, its here: https://roundup.mplayerhq.hu/roundup/ffmpeg/issue378

my problem was that someone uploaded it to issue378/incoming, but I couldnt find such directory to upload, as im not familiar with the server structure there.
however, I just checked the video again and the issue is solved by now (which is a bit strange, because it still wasnt like 1 month after that message had been posted). thanks to those who helped with it!
You don't have access to that directory. You must upload your file to the regular incoming directory. Post the filename in your issue report and a moderator will usually move the file into a new location.

tal.aloni

7th November 2008, 15:21

I really, really like the new ffmpeg-mt branch but can someone update it with the new audio codecs / trunk ? :thanks: :helpful:

@haruhiku, clsid, _xxl
It's now possible to include the new audio codecs (and other improvements) in the ffdshow-mt branch. can one of you merge them into ffdshow-mt?

Thanks,
Tal

CraziFuzzy

7th November 2008, 18:33

I don't believe that streams that require such checkbox exist. (5.1 with silent 3.1 and 2.0 encoded as dolby surround). If someone will prove me wrong, I would add such checkbox.
IMO, the probability of a user twisting the decoding process because of an unneeded checkbox is too high to justify it.

Tal

I'm not sure. I'd be willing to bet there are a few television broadcasts that are Dolby Pro-Logic encoded on stereo tracks, but are still broadcast as a 5.1 stream.

Also, I believe Dolby Digital EX uses the same matrix technique to get the extra 'center surround' information from the Left Surround and Right Surround channels. Would be a nice feature added to do this decoding if the input is 5.1 and the output is 3/2/1 or 3/2/2

EDIT: As a second thought, there could definitely be the capability in Outputs to encode into DD-EX if the mixer is 3/2/1 or 3/2/2, so if feeding to a DD-EX capable receiver via AC3, you can utilize that extra 1/2 channels.

tal.aloni

7th November 2008, 19:14

CraziFuzzy,

1. I got confised, the Pro Logic II decoder is already limited to stereo only. that's how it was all along, and that's how it should be.

2. Dolby Digital EX decoder / encoder belongs to the list of far-fetched feature requests.
(buy me an extra center speaker and I'll think about it :))
(don't get me wrong, I would love to have PLIIx as well, but it's just not going to happen anytime soon)

Tal

Snowknight26

8th November 2008, 06:05

ffdshow seems to have some screenshot issues.

Source taken with ffdshow:
http://www.stfcc.org/misc/shaun.source.png

AVS taken with ffdshow:
http://www.stfcc.org/misc/shaun.crop.png

AVS (well, the important parts at least):
spline36resize(1876,822,21,128,-23,-130)

When im playing the AVS in whatever player, whenever I hit Grab, I can see the border instantly being added to the right side, then 1 frame later, its removed and continues to play with the proper cropping. Its at that very moment that the border is added that ffdshow takes the screenshot.

tal.aloni

8th November 2008, 09:48

ffdshow seems to have some screenshot issues.

1. I'm pretty sure it has nothing to do with ffdshow.

2. use virtual dub to take screen shots from AVS.

Tal

Snowknight26

8th November 2008, 16:39

I'm pretty sure it does actually. ffdshow is whats decoding both the source and the avs, and ffdshow is being used to take the screenshot (you know, the Grab now button under Grab?). Doesn't happen when I take screenshots any other way (MPC's built in function, etc).

tal.aloni

8th November 2008, 17:04

(you know, the Grab now button under Grab?).

My apologies, I thought you were referring to a 3rd party tool.

does the border "overwrite" existing vertical line, or is the picture being resized and then a border is added?
it would be helpful if you post the same frame after cropping with MPC / virtual dub.
it would also be helpful if you could narrow it down, does it happen with the external AviSynth?
does is happen if the source is uncompressed?

Tal

DigitalDeviant

8th November 2008, 17:10

I have a sample here with a few interlaced frames that don't seem to be getting flagged as interlaced. They appear to be flagged correctly in DGIndex.

sample (http://www.mediafire.com/?2mycmgyzmym)

ikarad

8th November 2008, 17:14

when i read a dvd, subtitles with ffdshow don't work. Subtitles with ffdshow only work with .mkv or .xvid.
Is it normal or not?

Snowknight26

8th November 2008, 18:17

does the border "overwrite" existing vertical line, or is the picture being resized and then a border is added?

I think I had the screenshots backwards, anyway, here goes again:

Source
http://www.stfcc.org/misc/shaun.source.png

ffdshow:
http://www.stfcc.org/misc/shaun.crop.png

MPC (how it's supposed to be)
http://www.stfcc.org/misc/shaun.propercrop.png

It removes 4 pixels on from the right side of the frame and adds a 4 pixel thick black border. So yes, it 'overwrites.'

tal.aloni

8th November 2008, 19:17

Snowknight26,
I was able to recreate this, it seems that it only happens when all of this conditions are met:
1. outputting png
2. source is yuv
3. input resolution is not multiplication of 8.

(it has little to do with avisynth is seems)
also, the right border color is not always black, see here:
http://iknowu.net/files/public/ffdshow/Grab/grab02059.png

Snowknight26

8th November 2008, 19:23

Hmm, never seen it be something other than black. Good to know that you could reproduce it though.

tal.aloni

8th November 2008, 19:49

I've looked at the code, I'm pretty sure it's a bug in libavcodec (ffmpeg).

Tal

Snowknight26

8th November 2008, 20:27

Wouldn't it be a bug in the way ffdshow takes screenshots? If I do anything but take a screenshot, the stream is shown properly, be it after encoding or during playback.

CiNcH

8th November 2008, 20:35

tal.aloni

8th November 2008, 21:44

I reported earlier that 44,100 dts files in wav cannot be passed through, and now I see that it's one symptom of a broader phenomenon:
I cant get 44100hz AC3 / DTS to my receiver at all using ffdshow. (I get clicks when passing through or encoding to AC3 to 44100), I got no problem with other programs.
(or when resampling to 48000 before encoding)

please report if you have a similar problem.
unlikely, but this could be only at my end.

Tal

tal.aloni

8th November 2008, 21:48

Can somebody have a look at the following sample?

Sounds like trasformers communication with ffdshow.
It's not playable at all with sonic audio decoder 4.3.

Tal

CraziFuzzy

8th November 2008, 22:41

CraziFuzzy,

1. I got confised, the Pro Logic II decoder is already limited to stereo only. that's how it was all along, and that's how it should be.

2. Dolby Digital EX decoder / encoder belongs to the list of far-fetched feature requests.

I was just pointing out that the decoding work is already coded (for the DD-EX decoding), in that it is exactly the same decoding that is used for Dolby Surround/Pro Logic. The only thing that needs changing would be that the input to the Dolby decoder needs to be the Surround Left and Surround Right, and the output being the Rear Surround channel.

As for the encoder, I do know that it is a far off feature, but still something that could certainly be added to the list. Would be nice for the HTPC ffdshow users out here (myself included).
(buy me an extra center speaker and I'll think about it :))
(don't get me wrong, I would love to have PLIIx as well, but it's just not going to happen anytime soon)

Funny you mention it, I happen to have a Rear Surround speaker in my setup, WITHOUT a 6.1 receiver..

nautilus7

8th November 2008, 23:01

Can somebody have a look at the following sample?

http://kvcd.net/downloads/Terrestrial%20(France)%20538167%2011-08%2017-37-08.zip

It is EAC3 within TS (with PAT/PMT) from a French DVB-T network. MPC MpegSplitter -> ffdshow chain only produces noise...It's a libav limitation. Using eac3to i found out that:

Spectral extension is not implemented. If you want to help, update your FFmpeg version to the newest one from SVN.
If the problem still occurs, it means that your file has extension which has not been tested due to a lack of samples exhibiting this feature.
Upload a sample of the audio from this file to ftp://upload.mplayerhq.hu/incoming and contact the ffmpeg-devel mailing list.

I 'll tell madshi to forward the sample to the libav developer as he usually does in these cases.

Thunderbolt8

9th November 2008, 00:59

I created a wish thread on ffmpeg if they were able to improve multi core efficiency for ffdshow for VC-1 and also AVC. someone there posted that ffdshow might use its own multithreading code though, is this correct? meaning, making requests there regarding this is rather meaningless in that aspect?

I have quite some problems with playback of VC-1 and AVC HD remuxes with a c2q 6700 @2750 mhz. when using sharpening and postprocessing delay increases rapidly, while everything I tested plays fluenty on my c2d @2800 mhz. the 2 additional cores obviously cannnot make a positive difference, because the load is still distributed to a big extend on 1 core and less so on the other 3 (more problematic with VC-1, bit less with AVC).

STaRGaZeR

9th November 2008, 03:00

BatKnight

9th November 2008, 04:38

Hi,

I am using ffdshow svn 2309 and I've just discovered that if I select libavcodec on the AC3 drop-down and then check the AC3 SPDIF at the output, then it will ignore the SPDIF and will decode internally.
But if I select liba52 then the SPDIF isn't ignored and the sound is passed-through.

When it comes to DTS, it works both ways. No matter whether it's libdts or libavcodec selected, if the SPDIF is checked then the DTS is always passed-through.

Is this a bug or is it on purpose? :thanks:

Thanks
Bat

haruhiko_yamagata

9th November 2008, 07:05

Dumb question.

Using hardware deinterlacing, I want to resize. If I do so, typical artifacts and garbage caused by resizing before deinterlacing will be seen. Any trick to avoid this or it's impossible using HW deinterlacing?Of course deinterlacing before resize gives the best result.
If you want to resize before deinterlacing anyway, go to "Settings" page of resize and check "Interlaced".

tal.aloni

9th November 2008, 09:08

if I select libavcodec on the AC3 drop-down and then check the AC3 SPDIF at the output, then it will ignore the SPDIF and will decode internally.
But if I select liba52 then the SPDIF isn't ignored and the sound is passed-through.

Edit:
thanks for the report, it will be fixed soon.

Tal

CiNcH

9th November 2008, 10:07

It's not playable at all with sonic audio decoder 4.3.
Sonic HD Demuxer -> Sonic CineMaster Audio Decoder 4.3.0 played the sample without any problems here :) .

I 'll tell madshi to forward the sample to the libav developer as he usually does in these cases.
Thanks!

CiNcH

9th November 2008, 14:16

Now also our DVBSource plays the sample (http://forum.doom9.org/showthread.php?p=1211156#post1211156) with Sonic Audio Decoder. But since this decoder is hardly available...

STaRGaZeR

9th November 2008, 15:56

Of course deinterlacing before resize gives the best result.
If you want to resize before deinterlacing anyway, go to "Settings" page of resize and check "Interlaced".

That doesn't work, try it to see it by yourself. Horizontal lines are misplaced. I've already tried everything, and the "problem" is that HW deinterlacing is always done in the renderer, thus ffdshow can't do any image processing after it. Resizing has to be done prior to deinterlacing always, otherwise you'll get garbage. But there is any trick to do resizing after HW DI? I guess not :(

BTW I'd suggest another option in the output section regarding deinterlacing. CoreAVC has an option called "Agressive deinterlacing". What it does is put interlaced flags on everything that is not explicity flagged as progressive. That means that every PAFF and MBAFF video will get flagged as interlaced, regardless if each independent frame is interlaced or progressive. This option would correct the bad flagged streams and eliminate the jumps in the transitions between interlaced and progressive while not affecting pure progressive streams. Take this sample as an example: http://x264.nl/h.264.samples/force.php?file=./anixe.hd.ts. It's a 100% interlaced source, but flagged as progressive at the beginning and interlaced at the end (typical HDTV situation). This detection could also be implemented in the "Auto" method.

TheShadowRunner

9th November 2008, 16:33

hmm I can't manage to have ffdshow connect to the nvidia audio decoder.
Even though i checked LPCM, and it does allow ffdshow to connect to the cyberlink decoder, it's a no go for the nvidia decoder.
The nvidia audio decoder accepts the following on its input pin, so it should work shouldn't it?
Major Type: DVD_ENCRYPTED_PACK - Sub Type: DOLBY_AC3 - Format: GUID_NULL
Major Type: DVD_ENCRYPTED_PACK - Sub Type: {E06D8033-DB46-11CF-B4D1-00805F6CBBEA} - Format: GUID_NULL
Major Type: DVD_ENCRYPTED_PACK - Sub Type: MPEG2_AUDIO - Format: GUID_NULL
Major Type: DVD_ENCRYPTED_PACK - Sub Type: DVD_LPCM_AUDIO - Format: GUID_NULL
Major Type: MPEG2_PES - Sub Type: MPEG2_AUDIO - Format: GUID_NULL
Major Type: MPEG2_PES - Sub Type: DOLBY_AC3 - Format: GUID_NULL
Major Type: MPEG2_PES - Sub Type: DVD_LPCM_AUDIO - Format: GUID_NULL
Major Type: MPEG2_PES - Sub Type: MPEG1Packet - Format: GUID_NULL
Major Type: Audio - Sub Type: DOLBY_AC3 - Format: GUID_NULL
Major Type: Audio - Sub Type: MPEG2_AUDIO - Format: GUID_NULL
Major Type: Audio - Sub Type: MPEG1Packet - Format: GUID_NULL
Major Type: Audio - Sub Type: MPEG1AudioPayload - Format: GUID_NULL
Major Type: Audio - Sub Type: MPEG1Payload - Format: GUID_NULL
Major Type: Audio - Sub Type: PCMAudio - Format: GUID_NULL
Thanks for any info.
See you,

TSR

Inventive Software

9th November 2008, 16:39

That doesn't work, try it to see it by yourself. Horizontal lines are misplaced. I've already tried everything, and the "problem" is that HW deinterlacing is always done in the renderer, thus ffdshow can't do any image processing after it. Resizing has to be done prior to deinterlacing always, otherwise you'll get garbage. But there is any trick to do resizing after HW DI? I guess not :(

BTW I'd suggest another option in the output section regarding deinterlacing. CoreAVC has an option called "Agressive deinterlacing". What it does is put interlaced flags on everything that is not explicity flagged as progressive. That means that every PAFF and MBAFF video will get flagged as interlaced, regardless if each independent frame is interlaced or progressive. This option would correct the bad flagged streams and eliminate the jumps in the transitions between interlaced and progressive while not affecting pure progressive streams. Take this sample as an example: http://x264.nl/h.264.samples/force.php?file=./anixe.hd.ts. It's a 100% interlaced source, but flagged as progressive at the beginning and interlaced at the end (typical HDTV situation). This detection could also be implemented in the "Auto" method.

In the "Deinterlacing" tab, there's an option called "Process frames flagged as progressive". Enable that.

LoRd_MuldeR

9th November 2008, 17:14

In the "Deinterlacing" tab, there's an option called "Process frames flagged as progressive". Enable that.

I fell into that trap too :p

STaRGaZeR

9th November 2008, 18:14

In the "Deinterlacing" tab, there's an option called "Process frames flagged as progressive". Enable that.

That option flags everything. The same goes to "Force bob". The whole point of this option is to flag everything that is not pure progressive material, everything that is suspicious to have any interlaced parts. It's in CoreAVC for a reason: you don't want 1080p Blu-ray movies or your x264 encodes flagged as interlaced, but you do want that HDTV channel flagged, right? This single option would solve all those problems at the same time. And if you don't want it, you can always disable it :)

Inventive Software

9th November 2008, 22:29

That option flags everything. The same goes to "Force bob". The whole point of this option is to flag everything that is not pure progressive material, everything that is suspicious to have any interlaced parts. It's in CoreAVC for a reason: you don't want 1080p Blu-ray movies or your x264 encodes flagged as interlaced, but you do want that HDTV channel flagged, right? This single option would solve all those problems at the same time. And if you don't want it, you can always disable it :)

Like I see keep mentioned on a few projects: patches welcome! :D

STaRGaZeR

9th November 2008, 22:40

Like I see keep mentioned on a few projects: patches welcome! :D

I'd do it, but I'm no programmer. So all I can do is to tell this suggestions to the people that can :p

Thunderbolt8

10th November 2008, 01:50

got a minor playback problem with a baraka blu-ray (VC-1) -> .mkv remux I play with ffdshow (+haali renderer): theres a thin white line at the top of the visible frame (AR 2.20). unfortunately its not on the screenshots I took, but its gone when I switch ffdshow for the WMVideo Decoder DMO for example. is there any way to get rid of it, using ffdshow?

tal.aloni

10th November 2008, 17:29

Wouldn't it be a bug in the way ffdshow takes screenshots? If I do anything but take a screenshot, the stream is shown properly, be it after encoding or during playback.

1. yes, another bug is that the frame that used for color space conversion, is also displayed immediately afterwards in ffdshow, this is an easy fix.

2. I invested some time in tracking this issue, and after an intensive debugging session I found the culprit: swscaler (from the mplayer / ffmpeg project). when I finally reached the suspicious method, I found the following comment:

/* height should be a multiple of 2 and width should be a multiple of 16 (if this is a
* problem for anyone then tell me, and ill fix it)
*/

EDIT:
I was able to add YV12 to BGR24 conversion (and BGR24 to YV12) to the internal conversion routines (image.cpp). swscaler won't be used for this function anymore.
(it would be nice to improve the swscaler instead / as well, but I'm not too good with assembler. if you are, the problematic file is rgb2rgb_template.c, I also submitted a bug report to the ffmpeg team)

+ Bugfix: Now the grab filter won't perform the needed color space conversion for the outputted file on the displayed frame (monitor) as well.

+ Added internal BGR24 <==> YV12 conversion routines, libswscaler routines aren't suitable for frames with width which is not a multiplication of 16.

+ Bugfix: Grab filter will no longer produce right black border when saving png frames with width which is not a multiplication of 16.

patch:
http://iknowu.net/files/public/ffdshow/Grab/2309-BGR24.zip

build:
http://iknowu.net/files/public/ffdshow/Grab/ffdshow_rev2309_20081105-BGR24.exe

Tal

Snowknight26

11th November 2008, 02:15

Why the conversion in the first place?

On a different note, I encoded a 24fps H.264 file but ffdshow says its 23.999fps.

lych_necross

11th November 2008, 07:24

In the "Deinterlacing" tab, there's an option called "Process frames flagged as progressive". Enable that.

Am I correct in assuming that if I leave that option unchecked, deinterlacing will only be used on frames flagged as interlaced?

Snowknight26

11th November 2008, 07:52

r2301 doesn't want to take screenshots of the OSD when its turned on.

tal.aloni

11th November 2008, 08:57

Why the conversion in the first place?
because PNG can only contain the RGB colorspace, it cannot contain yv12 or any other color space.

r2301 doesn't want to take screenshots of the OSD when its turned on.

That's how it was at rev. 2222 too (the oldest one I have), and this is how it should work as far as I know, I think it's better this way.

Am I correct in assuming that if I leave that option unchecked, deinterlacing will only be used on frames flagged as interlaced?

Yes, this is the recommended usage.

Tal

haruhiko_yamagata

11th November 2008, 11:36

Am I correct in assuming that if I leave that option unchecked, deinterlacing will only be used on frames flagged as interlaced?Yes, this is the recommended usage.
More MPEG-2 files than I have expected have wrong flags. In my opinion, the flags are not reliable "at all".
In H.264 flags are much more reliable, but still there are some files that have wrong flags (rare, ignorable).
It's just my opinion, discussion is welcome.

tal.aloni

11th November 2008, 11:45

Well, maybe that's because you're used to getting the rarest samples on a weekly basis :)
I live in a PAL country, and 99% of the content I get is progressive. the other 1% is usually flagged as it should.
I can only remember one DVD which was flagged incorrectly.

Tal

haruhiko_yamagata

11th November 2008, 12:37

EDIT:
I was able to add YV12 to BGR24 conversion (and BGR24 to YV12) to the internal conversion routines (image.cpp). swscaler won't be used for this function anymore.
(it would be nice to improve the swscaler instead / as well, but I'm not too good with assembler. if you are, the problematic file is rgb2rgb_template.c, I also submitted a bug report to the ffmpeg team)

+ Bugfix: Now the grab filter won't perform the needed color space conversion for the outputted file on the displayed frame (monitor) as well.

+ Added internal BGR24 <==> YV12 conversion routines, libswscaler routines aren't suitable for frames with width which is not a multiplication of 16.

+ Bugfix: Grab filter will no longer produce right black border when saving png frames with width which is not a multiplication of 16.

patch:
http://iknowu.net/files/public/ffdshow/Grab/2309-BGR24.zip

build:
http://iknowu.net/files/public/ffdshow/Grab/ffdshow_rev2309_20081105-BGR24.exe

TalGood work :).
case FF_CSP_BGR24:
safe_packed_conv(
dst[0], dst_stride[0], image->y, image->u, image->v,
edged_width[0], edged_width[1], width, height,
interlacing?(jpeg?TpackedFuncPtrRGB<JPEG>::yv12_to_rgbi:TpackedFuncPtrRGB<CCIR>::yv12_to_rgbi) :(jpeg?TpackedFuncPtrRGB<JPEG>::yv12_to_rgb:TpackedFuncPtrRGB<CCIR>::yv12_to_rgb),
interlacing?(jpeg?TpackedFuncPtrRGB<JPEG>::yv12_to_rgbi_c:TpackedFuncPtrRGB<CCIR>::yv12_to_rgbi_c):(jpeg?TpackedFuncPtrRGB<JPEG>::yv12_to_rgb_c:TpackedFuncPtrRGB<CCIR>::yv12_to_rgb_c), 4);
Shouldn't the last 4 be 3?