Log in

View Full Version : ffdshow tryouts project: Discussion & Development


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

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

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

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

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