ffdshow tryouts project: Discussion & Development

[_xxl]

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

[Inventive Software]

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]

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]

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!

[albain]

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]

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]

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]

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]

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]

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

[nautilus7]

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]

@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]

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]

Having libavformat integrated in MPC-HC would be great.

[Inventive Software]

Contact the MPC-HC devs then. ;)

[clsid]

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]

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

[madshi]

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]

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]

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.We have always already compiled libavcodec as a dll.

[madshi]

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]

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]

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

[albain]

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]

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

[Inventive Software]

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]

I have fixed the problem for incorrect channel mapping too

[_xxl]

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]

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]

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]

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]

Exact same problem with AC3.


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

[clsid]

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]

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]

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]

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]

Where can I find a TrueHD sample ?

Thanks

[nautilus7]

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]

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

[albain]

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]

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]

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]

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

[pitch.fr]

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,

[nautilus7]

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]

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]

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]

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]

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]

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;