ffdshow tryouts project: Discussion & Development

[albain]

Originally Posted by Blight

Possible API Bug Report:
I believe that "IDFF_subCurrentFlnm" value determines whether ffdshow has found a suitable subtitle stream for rendering.
The problem is, this value is not set when an embedded sub stream is displayed, so there's no way of knowing whether ffdshow had found a valid subtitle stream and is ready to display it.
Is it possible to enable this flag when the embedded subtitle pin is connected?

No, this value has been disabled a while ago

To get the current subtitles, instead of calling the sendmessage method with WPRM_GETPARAM and "IDFF_subCurrentFlnm",
call it with MSG_GET_CURRENT_SUBTITLES and 0

[MatMaul]

Originally Posted by Mercury_22

It's my understanding that libdts has been upgrade / replace with libdca, am I wrong ? If I'm not shouldn't libdts be update ?

libdts = libdca
and it has not been updated since 2006 or so.

[tetsuo55]

isn't libdca deader than a doornail?

I unberstood it the other way around, libdca got dropped in favor of libavcodec.

[clsid]

Not all software requires endless development. Certainly not small projects like libdca that have a fixed specification.

[leeperry]

Originally Posted by MatMaul

libdts = libdca
and it has not been updated since 2006 or so.

yep, there's no DTS96/24 GPL decoder

[tetsuo55]

Originally Posted by clsid

Not all software requires endless development. Certainly not small projects like libdca that have a fixed specification.

True for a lot of applications, DTS has however evolved and libdca never catched up.

[clsid]

Those should be considered new formats, not plain old DTS. And those are also not yet supported by libavcodec or any other open source library.

[Mercury_22]

Originally Posted by albain

I fixed the channels order for Dolby TrueHD.

For LPCM, I will need Haruhiko's hand : channels order is wrong
Side left is sent to side right
Side left is sent to LFE
LFE is sent to side left.

Problem is located in TaudioUncompressed.cpp, line 100

if (lpcm24) {
            if (highDef) 
                    *dst++ = (src[i]<<24) + (src[i+ 1]<<16) + (src[i+ 2]<<8);
                    *dst++ = (src[i+3]<<24) + (src[i+ 4]<<16) + (src[i+ 5]<<8);
                    *dst++ = (src[i+6]<<24) + (src[i+ 7]<<16) + (src[i+ 8]<<8);
                    *dst++ = (src[i+9]<<24) + (src[i+10]<<16) + (src[i+11]<<8);
{

I've just tested your fix for TrueHD with clsid's ffdshow_rev3040_20090724_clsid and there is NO change

Originally Posted by Mercury_22

E-AC3 (Dolby Digital Plus) channels are wrong mapped :

1 - SIDE RIGHT wrong mapped to REAR RIGHT
2 - SIDE LEFT wrong mapped to REAR LEFT

= No Side Channels

Test 7.1 E-AC3 (Dolby Digital Plus)

Dolby TrueHD channels are wrong mapped :

1 - SIDE RIGHT wrong mapped to REAR RIGHT
2 - REAR RIGHT wrong mapped to SIDE RIGHT
3 - SIDE LEFT wrong mapped to REAR LEFT
4 - REAR LEFT wrong mapped to SIDE LEFT

Test 7.1 Dolby TrueHD

[tetsuo55]

Originally Posted by clsid

Those should be considered new formats, not plain old DTS. And those are also not yet supported by libavcodec or any other open source library.

What i read about DTS states that all formats are plain DTS with extra data. This would mean that it's not a new format but an extention of a existing one. DTS even states that any version of DTS is fully backwards compatible with older players, the extra data of the newer format is simply discarded.

[clsid]

Logic dictates that it should decode DTS, not some extensions that were made up long after it was developed.

But it all does not matter. It does not support those extensions, neither do any other open source decoders. I can't change that. You can't change that. So we are all wasting our time here.

[tetsuo55]

Originally Posted by clsid

LBut it all does not matter. It does not support those extensions, neither do any other open source decoders. I can't change that. You can't change that. So we are all wasting our time here.

It's the sad truth

PS i rewrote my post...

EDIT:

I just checked the history, all the extensions already existed while it was being written, even DTS-HD was released before the last SVN commit. I guess no-one cared or people are afraid of DTS laywers.
It should be pretty easy to reverse engineer all these formats from a hardware decoder chip (easy for people who know how to read a chip)

PS if that last sentence is against the rules let me know and i will remove it.

[clsid]

Two quotes from the VideoLAN website that could explain why the project has not progressed further:

None of the extensions (extra channels, 96/192kHz sample rates) have been implemented (and unfortunately the public standard provides only minimal information on them).

Provisional Warning: DTS Inc. claims that use of libdca software, to decode DTS compressed sound data on a DVD could violate DTS's patent rights. If you are unsure about the legality of using and distributing this code in your country, in particular in the USA, please consult your lawyer before downloading it

It is also possible (and perhaps easier) to reverse engineer a commercial decoder. That is what the FFmpeg devs usually do.

[lych_necross]

Originally Posted by tetsuo55

I guess no-one cared or people are afraid of DTS laywers.
It should be pretty easy to reverse engineer all these formats from a hardware decoder chip (easy for people who know how to read a chip)

Lets not forget the law of supply and demand. I believe the main reason the DTS stuff hasn't been updated is because there is not a lot of demand for it (it requires special equipment...).

[albain]

Originally Posted by Mercury_22

I've just tested your fix for TrueHD with clsid's ffdshow_rev3040_20090724_clsid and there is NO change

The fixes requires mplayer and ffdshow to be recompiled.

Maybe mplayer was not recompiled in this build ?

However I didn't fixed EAC3 (yet), only TrueHD

[albain]

Concerning DTS, patents are dated from 1991, and AFAIK patents are limited in duration (20 years) so there should be any problems to use and extend the decoding of this format next year.

Not the same thing for DTS-HD, more recent.
But can't you post some reversed engineer code in source form only ? (binary form would be prohibited for sure)

[travolter]

"Postprocessing tab"

I have found a bug with "SPP deblocking" when I check the "soft threshold" checkbox.

The bug only happend when (IMPORTANT):
you play an AVI file (XVID codec or similar) + you place postprocessing after "resize" in the effect chain


notice the square at top left. Processing not affect that screen area "592x320".. thats the original screen resolution of my movie.. and I have rescaled to 1280x720

(I know that many people will save me saying.. "place postprocessing before resize".. but sometimes is better for CPU saving use postprocessing after resize.. like when using a 1080 original rescaled to 720)

[Mercury_22]

Originally Posted by albain

The fixes requires mplayer and ffdshow to be recompiled.

Maybe mplayer was not recompiled in this build ?

However I didn't fixed EAC3 (yet), only TrueHD

Can you post one ( x64 ) compiled by you then ?

I was refering only to TrueHD too but I quote the entire post because it was quicker

EDIT :
I've tested with ffdshow_rev3040_20090725_clsid_icl10 too and still no change. I don't know if this helps but MPC-HC had the correct mapping for TrueHD until rev 1180 !

[leeperry]

BTW, ages ago I asked Harihuko if he could add 1.78/1.85/2.35/2.40 presets in the resize filter...well it's actually 2.39 :
http://www.arrimedia.com/2-Perforation.php


http://en.wikipedia.org/wiki/Aspect_...e)#Why_16:9.3F

2.39:1 (the ratio of anamorphic widescreen films).

I think you can leave it as "CinemaScope" as this is what is :

Anamorphic widescreen was not used again for cinematography until Twentieth Century-Fox bought the rights to the technique in 1952 to create its CinemaScope widescreen technique.

but 1.85 should be called "US widescreen", 1.67 "EU widescreen" and 2.35 "anamorphic widescreen"...as it's not really CinemaScope :
http://en.wikipedia.org/wiki/Anamorp....2C_or_2.40.3F

Anamorphic prints are still often called Scope or 2.35 by projectionists, cinematographers, and others working in the field, if only by force of habit. 2.39 is in fact what they generally are referring to

[Mr VacBob]

Originally Posted by travolter

notice the square at top left. Processing not affect that screen area "592x320".. thats the original screen resolution of my movie.. and I have rescaled to 1280x720

(I know that many people will save me saying.. "place postprocessing before resize".. but sometimes is better for CPU saving use postprocessing after resize.. like when using a 1080 original rescaled to 720)

Yes, the reason they say that is because it won't work. postproc and spp depend on the compression qscales of the video and they aren't resized with it (it wouldn't work very well if you tried to, either). Instead you have to use some generic avisynth filter or a faster postproc.

[albain]

Originally Posted by Mercury_22

Can you post one ( x64 ) compiled by you then ?

I was refering only to TrueHD too but I quote the entire post because it was quicker

EDIT :
I've tested with ffdshow_rev3040_20090725_clsid_icl10 too and still no change. I don't know if this helps but MPC-HC had the correct mapping for TrueHD until rev 1180 !

I don't have any 64 bits compiler (anymore).

Here is a 32 bits link if you can test it