ffdshow tryouts project: Discussion & Development

[MatMaul]

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]

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

It isn't finished, when done I''ll post a test build.

[haruhiko_yamagata]

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]

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]

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]

It still fails with my previous sample.

[albain]

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]

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]

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]

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]

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]

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]

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

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]

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]

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)

[albain]

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]

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]

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?

[ACrowley]

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]

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)

[nautilus7]

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]

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]

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]

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]

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]

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).

yeah , i understand...TrueHD Problem must be splitter related.
Perhaps somebody should talk with Gabest/MPC-HC Coders

[nautilus7]

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?

[SeeMoreDigital]

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]

m2ts with 7.1 truehd from dolby demo disc. I compare channel mapping with eac3to output.

[STaRGaZeR]

An observation: when playing PCM tracks, bitrate is always reported as 0. This should be very easy to fix/add.

[albain]

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]

Still no change with 7.1 truehd channel order. Same thing always. :(

[STaRGaZeR]

This problem has always existed

Yes, that's why it'd be nice to fix it :p

[lych_necross]

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).

Isn't thread=8 a little high? For a dual core processor shouldn't threads be set to 2?

[albain]

It would be great to have a 8 channels TrueHD sample with a voice saying each channel separately.

Is it possible ?

[tal.aloni]

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]

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]

Is there another link for beta 23 as rapidshare keeps saying my session has expired even though it hasn't!?!

[albain]

Here it is, no limit on this one :

http://damienbt.free.fr/ffdshow_rev2220_20081015_dbt_beta23.exe

[dom_b]

great, thanks for that!

[tal.aloni]

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]

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]

I have such sample (from the Dolby Demo disc),
I can upload it by evening.May I have this sample too please?

[tal.aloni]

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]

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]

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]

is it using ffmpeg-mt ?
Soon I''ll release a test build for ffmpeg-mt trunk.

[CiNcH]

changelog says ffmpeg-mt was updated with 2119 this is your newest 2222 build
Later revision number but different branch ;) .