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

tetsuo55

24th July 2009, 17:33

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

24th July 2009, 18:27

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

25th July 2009, 07:37

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

25th July 2009, 10:43

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

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

25th July 2009, 10:52

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

25th July 2009, 13:41

"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

http://img129.imagevenue.com/loc500/th_25930_2_122_500lo.jpg (http://img129.imagevenue.com/img.php?image=25930_2_122_500lo.jpg)
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

25th July 2009, 14:16

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

26th July 2009, 03:32

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://www.arrimedia.com/upload_img/arrimedia.com/image_153.jpg

http://en.wikipedia.org/wiki/Aspect_ratio_(image)#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/Anamorphic_format#2.35.2C_2.39.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

26th July 2009, 07:23

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

27th July 2009, 09:34

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 (http://www.mediafire.com/?sharekey=d2549da476034d8c08f8df73f2072ed6e04e75f6e8ebb871) if you can test it

Mercury_22

27th July 2009, 10:59

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

Here is a 32 bits link (http://www.mediafire.com/?sharekey=d2549da476034d8c08f8df73f2072ed6e04e75f6e8ebb871) if you can test it

Tested but NO change.
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 (http://www.megaupload.com/?d=7P9P81CW)

P.S. maybe you can talk with Casimir cause MPC-HC now has the channels for all format correct mapped but you need to set MPC-HC's internal filters to "3 Front + 2 Rear" even if you have 7.1 speakers

albain

27th July 2009, 11:52

You're right, either I wrongly tested or I messed up with the patch
I am on it

*EDIT* : this is fixed now. I tested it on TrueHD but it should also work on EAC3. Done in revision 3043
For uncompressed formats (LPCM) this is harder to figure out what's wrong. I'll try but we may have to wait for Haruhiko's return

Jeremy Duncan

28th July 2009, 19:13

Please add this patch to the ffdshow svn: link (http://www.mediafire.com/?tmdwym5nnoo)

I got the patch from SEt: link (http://forum.doom9.org/showthread.php?t=148117)

I need a ffdshow generic build made that has this patch available.
The sooner the better. many thanks! :)

To the two fellows who said this patch doesn't work for them. They are using SEt's avisynth and mt dll's.
I suggest they try the patch with the ffdshow version SEt made the patch for, and using my July 23rd avisynth and mt dlls.

Then if it still doesn't work for them then we wait for leak to post his patch, but his two week vacation ends on friday.

I will say the SEt patch works fine for me if I use the ffdshow version SEt made the patch for.

Please add SEt's patch to the ffdshow svn. This is very rough to wait for Leak and how do we know he will add a patch?
Nothing is certain in this life and we have a working patch ready to go. Add the SEt patch and when leak adds his patch remove SEt's version. :)

dlls (http://forum.doom9.org/showthread.php?t=144852)

clsid

28th July 2009, 20:01

Leak is our avisynth guru. He will decide if and when to apply the patch. He already said he will look at it.

Mercury_22

29th July 2009, 10:57

XhmikosR

29th July 2009, 11:30

Can you please, compile ?

Here (http://www.mediafire.com/?uzi104ynzdj) is r3044. I built it yesterday for personal use.

Mercury_22

29th July 2009, 14:37

Here (http://www.mediafire.com/?uzi104ynzdj) is r3044. I built it yesterday for personal use.
:thanks:

Can you please add x64 too ?

You're right, either I wrongly tested or I messed up with the patch
I am on it

*EDIT* : this is fixed now. I tested it on TrueHD but it should also work on EAC3. Done in revision 3043
For uncompressed formats (LPCM) this is harder to figure out what's wrong. I'll try but we may have to wait for Haruhiko's return

The mapping for the TrueHD it's now correct !:)
The mapping for E-AC3 still incorrect :

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

Same as MPC-HC

XhmikosR

29th July 2009, 15:10

leeperry

29th July 2009, 19:47

I will say the SEt patch works fine for me if I use the ffdshow version SEt made the patch for.

Please add SEt's patch to the ffdshow svn.
I'm using the "official" 2.57 MT files, as all my plugins were compiled for this version(that works fine BTW)...even SEt said that this patch was a dirty hack, hence he didn't want to push it into the SVN.

this patch made some of my movies run at half speed..

any "fix"(if required) should work w/ whatever 2.57 or 2.58....Leak is the judge here, anyway you got SEt's fffdshow.ax for the time being....what's wrong w/ that?

albain

31st July 2009, 09:33

:thanks:

Can you please add x64 too ?

The mapping for the TrueHD it's now correct !:)
The mapping for E-AC3 still incorrect :

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

Same as MPC-HC

Unfortunately, the problem does not come from FFDShow but ffmpeg : the EAC3 decoder does not support 7.1 channels yet (6 channels max).
As a result, back and side channels are the same.

Please report the problem to ffmpeg team.

*EDIT* : this fixed for LPCM highdef too now (revision 3050) . Don't have the time to release a build

Mercury_22

1st August 2009, 12:27

Unfortunately, the problem does not come from FFDShow but ffmpeg : the EAC3 decoder does not support 7.1 channels yet (6 channels max).
As a result, back and side channels are the same.

Please report the problem to ffmpeg team.

*EDIT* : this fixed for LPCM highdef too now (revision 3050) . Don't have the time to release a build

Nice can't wait to test it !
Maybe someone can find the time to release a build (x64 too please)

XhmikosR

1st August 2009, 12:38

Mercury_22

1st August 2009, 14:12

Download (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce251686155677bb26855284166a6fc12f6c) ffdshow_rev3050_20090801 and ffdshow_rev3050_20090801_icl11
(the link will always point to a folder)

Note: I include theora in my builds, although most people won't use it and it might be an old version of theora. Maybe it will get updated sometime in the future, but some people might want to use it.

Unfortunately I haven't managed to build the x64 version.

If someone knows how to parse some arguments to the Inno Setup compiler via cmd, that would help me a lot. E.g.I'd like to change a define from true to false in order to build first the normal build and after that the ICL build of the installer. Now I have to do it manually.

:thanks:

P.S. I'm hoping you'll manage to build a x64 too

Unfortunately, the problem does not come from FFDShow but ffmpeg : the EAC3 decoder does not support 7.1 channels yet (6 channels max).
As a result, back and side channels are the same.

Please report the problem to ffmpeg team.

*EDIT* : this fixed for LPCM highdef too now (revision 3050) . Don't have the time to release a build

I can confirm LPCM now has the channels correct mapped

Gleb Egorych

1st August 2009, 16:36

I can confirm LPCM now has the channels correct mapped
Does it mean that channel mapping problems in ffdshow are now fixed? Regardless of the problems causes by decoders themselves (libdts for DTS and libavcodec for E-AC3 which are limited to 6 channels).

Mercury_22

1st August 2009, 17:44

Does it mean that channel mapping problems in ffdshow are now fixed? Regardless of the problems causes by decoders themselves (libdts for DTS and libavcodec for E-AC3 which are limited to 6 channels).
Yes with those exceptions

albain

2nd August 2009, 12:00

What is the problem with libdts ?

This problem also occurs with FFMPeg DCA (=dts) decoder ?

avivahl

2nd August 2009, 12:20

clsid, could you please compile and release rev 3051 for both generic and x64 builds on SourceForge?

ipanema

2nd August 2009, 15:32

In June I mentioned this:

Most of the time ffdshow's H.264 decoder does not seem to decode the 2 B frames that preceed the first I frame (in presentation order) in the stream. It DOES seem to decode the 2 B frames most of the time at the start of a FILE, but if you start streaming data from an I-frame located elsewhere in a file then the 2 preceding B frames are NOT decoded (as if it was an open GOP). But Mainconcept always seems to decode the 2 preceeding B frames no matter which I-frame in the file you start streaming from (as if all GOPs were closed).

Do you know what flags in the stream the ffdshow's H.264 decoder is using to decide not to decode the 2 leading B frames? And is it making a mistake? If Mainconcept can perfectly decode these B frames OK then surely ffdshow should be able to aswell.

and Haruhiko replied:

They are simply dropped without any flags. It's a bug then. I'll re-read the spec and think about the fix.

I was just wondering if there has been any progress with this. The latest version 3048 from Sourceforge seems to be the same.

Gleb Egorych

2nd August 2009, 21:27

What is the problem with libdts ?
I read about that in MPC-HC thread: http://forum.doom9.org/showthread.php?p=1308404&highlight=dts#post1308404

Ginsonic

7th August 2009, 07:31

Maybe a bug ?
Since Version 3040 when resizing SD material to e.g. 720p, picture seems to be zoomed (only a part of the picture is resized to full screen resolution). When unchecking and checking resize checkbox, everything works like a charm. When opening a new video, trouble starts again. Version 3029 works flawlessly.
OSD always shows correct in- and output resolutions.

BTW: Thanks for Your great work !

Gleb Egorych

7th August 2009, 08:13

Since Version 3040 when resizing SD material to e.g. 720p, picture seems to be zoomed (only a part of the picture is resized to full screen resolution). When unchecking and checking resize checkbox, everything works like a charm. When opening a new video, trouble starts again. Version 3029 works flawlessly.

Also checking/unchecking resize breaks recent autocropping feature in FLV. Using ffdshow 3054 and FLV splitter 1.2.908. Same situation when using MPC-HC's r1207 internal FLV splitter.

BTW the feature does work only in EVR and VMR7_without_overlay for me. Overlay mixer and VMR7_with_overlay - no cropping at all. VMR9 - black screen, need to check/uncheck resize to get picture (without cropping). Tested in MPC-HC and ZP7.
WinXP, 8800GT, FW 186.18.

albain

7th August 2009, 10:41

Maybe related with those revisions :
in rev 3039,
"Added workaround for Overlay Mixer that prevent an issue with 'transparent' cropped areas. "

or

in rev 3031,
"copy VIDEOINFOHEADER.rcSource from the input pin to the output pin.
fix a crop problem with FLV videos.
https://sourceforge.net/tracker/index.php?func=detail&aid=2298876&group_id=173941&atid=867360"

clsid

7th August 2009, 11:15

Rev 3039 restores the 'old' behavior when using Overlay. So that one isn't the cause. Rev 3031 may be the cause because it possibly overrides any cropping settings of ffdshow.

leeperry

7th August 2009, 16:09

isn't there something wrong w/ 320x240 MPEG1 files in ffdshow :confused:

here's a sample : http://www.nanoed.org/courses/carbon_nanotube/ballv02.mpg

I upscale them to 1024x768(keep AR), and I get zoomed video :

http://thumbnails14.imagebam.com/4460/dab8b244593448.gif (http://www.imagebam.com/image/dab8b244593448)

if I uncheck then recheck the resize filter, then it's fine :

http://thumbnails7.imagebam.com/4460/c727bf44593450.gif (http://www.imagebam.com/image/c727bf44593450)

both verified w/ the default ffdshow(latest ICL10 build) settings, and in both KMP/MPC.

also these 320x240 MPEG1 videos refuse to play in HR(closes the player instantly), but work fine in EVR(just zoomed up to death)?! maybe because HR doesn't like the bogus data ffdshow sends out?

I've tried every possible MPEG1 decoder/splitter/ffdshow setting.. :thanks:

Ginsonic

7th August 2009, 21:15

I upscale them to 1024x768(keep AR), and I get zoomed video

It seems, You get the same troubles like me as described above, but it also happens with MPEG2 material (DVD in my case).

leeperry

7th August 2009, 21:43

ok, so something's fishy...I really don't think that it comes from my setup.

should one of us create a bug report on sourceforge? last time I did, they were ignored :o

Haruhiko's on vacation anyway, he well deserves it!

dvd_

8th August 2009, 08:03

using ffdshow tryouts revision 2857 with latest mpc.
when playing 720p and 1080p mkv files i witness a strange artifact, like a soft "snow" effect in some areas of the picture in some parts of the movie.
also, the video playback is not "smooth" in some parts and seems like the fps is slow.

when playing full bluray movie in powerdvd i dont witness those problems.

cpu is i7, and maximum load is 20% with mpc and 3% with powerdvd. so no trouble there.

any help or suggestions on how to improve the video playback quality using ffdshow and mpc would be great.
thanks.

clsid

8th August 2009, 13:06

@leeperry
Post a detailed bugreport on sourceforge. Otherwise it will certainly be forgotten.

@dvd_
Try a more recent build first.

leeperry

8th August 2009, 16:39

@leeperry
Post a detailed bugreport on sourceforge. Otherwise it will certainly be forgotten.
ok, just did : https://sourceforge.net/tracker/?func=detail&aid=2834209&group_id=173941&atid=867360

I was afraid my KMP config was wrong, but it's indeed ffdshow...as when using HR I'm getting an error in the windows XP event viewer, stating that ffdshow crashed KMP.

Type of event: DrWatson
Event ID : 4097
Description :
KMPlayer.exe, has generated an application error. The generated exception
was c0000005 at the adress 023F3815 (ffdshow!DllGetClassObject)

travolter

10th August 2009, 13:57

Hey guys.. anyone know how to solve this bug that I have?

I lose frames using current settings in ffdshow..
** that only appear into avi files with divx/xvid... other files like wmv are working ok.

http://usuarios.lycos.es/kakhen/kakhen/loseframes.PNG

Im decoding with ffdshow and haali spliter

Leak

10th August 2009, 14:24

Hey guys.. anyone know how to solve this bug that I have?
Ummm... for SPP deblocking the slider just sets the number of deblocking passes done - the further you move it to the right, the more CPU power you'll need for this to be done in realtime; each step roughly doubles the amount of CPU use.

If you get dropped frames, your CPU simply isn't fast enough to do that amount of SPP deblocking - except for getting a faster CPU there's nothing that can be done.

np: Iwasaki Taku - Love Is Destiny, Destiny Is Paper (R.O.D The TV Original Soundtrack 2)

travolter

10th August 2009, 14:50

If you get dropped frames, your CPU simply isn't fast enough to do that amount of SPP deblocking - except for getting a faster CPU there's nothing that can be done.

Leak.. but.. why it only happend with AVI files that contain (divx/xvid)?

Im using same settings with wmv (wmv3/VC-1), mkv (H264).. and decoding is perfect using these settings at max.

Maybe a bug into the ffdshow divx decoder? or really deblocking divx requires more cpu than movies with other codecs?

EDIT.- Big question!!!! Postprocessing is really working with other kind of videos but AVI? Im testing with WMV and I dont see difference

netwolf

10th August 2009, 15:11

Isn't 'Automatic quality control' (which I see is enabled) supposed to prevent Postprocessing from taking too much CPU time?
(by moving the slider automatically to the left if CPU usage approaches max.)

JarrettH

11th August 2009, 05:45

I propose releasing Beta 7 sometime next month. Of course all regressions since beta 6 should be fixed first.

Known regressions:
- WMV3 decoding crash. This is a bug in FFmpeg code. Will hopefully be fixed soon.
- SPDIF related issues? Can anyone who suffers from this problem summarize the problem, including last known good revision and first known bad revision?

If there is anything I forgot, please let me know.

Improving AutoCrop before releasing beta 7 would be nice. But since it was broken before, not a requirement.

@Haruhiko, do you have any plans for changes that you would like to include in beta 7?

soon soon soon? :) :D

tetsuo55

11th August 2009, 06:50

Microsoft made a page on MSDN explaining the bitstreaming of all supported audio formats over HDMI, Displayport and Spdif(on a different page).

Every bitstreamable format is explained on that this page except for 1, DTS-HD.

http://msdn.microsoft.com/en-us/library/dd316761(VS.85).aspx

Maybe FFdshow could be update to bitstream all those formats instead of only ac3 and dts

EpsilonX

11th August 2009, 09:34

Leak.. but.. why it only happend with AVI files that contain (divx/xvid)?

Im using same settings with wmv (wmv3/VC-1), mkv (H264).. and decoding is perfect using these settings at max.

Maybe a bug into the ffdshow divx decoder? or really deblocking divx requires more cpu than movies with other codecs?

EDIT.- Big question!!!! Postprocessing is really working with other kind of videos but AVI? Im testing with WMV and I dont see difference

In my personal experience...
It seems that H.264 uses its own deblocking routine...
It utilize lower amount of CPU power, way lower than decoding DivX/XviD...
Can't say about WMV...
But in my E5200@4Ghz, I can only use SPP level 2 slider...
That's with resize and sharpening...
CMIIW...

ipanema

11th August 2009, 18:10

Should I raise a bug report for

http://forum.doom9.org/showpost.php?p=1310827&postcount=7780

on SourceForge? In case it gets forgotten.

clsid

11th August 2009, 19:39

Yes. Please do.

jruggle

12th August 2009, 00:17

Unfortunately, the problem does not come from FFDShow but ffmpeg : the EAC3 decoder does not support 7.1 channels yet (6 channels max).
As a result, back and side channels are the same.

Please report the problem to ffmpeg team.

If someone has a 7.1 E-AC-3 file other than the one I have, which is just a channel test stream, please send it my way. I'm not going to use my time trying to implement something that has no practical benefit, so until I get a report of a real-world sample, FFmpeg will only support 6-channel E-AC-3...unless someone other than myself decides to do it.

albain

12th August 2009, 08:58

If someone has a 7.1 E-AC-3 file other than the one I have, which is just a channel test stream, please send it my way. I'm not going to use my time trying to implement something that has no practical benefit, so until I get a report of a real-world sample, FFmpeg will only support 6-channel E-AC-3...unless someone other than myself decides to do it. I agree, I have never seen 7.1 DD Plus movies, TrueHD is the standard for 8 channels for Dolby

Microsoft made a page on MSDN explaining the bitstreaming of all supported audio formats over HDMI, Displayport and Spdif(on a different page).

Every bitstreamable format is explained on that this page except for 1, DTS-HD.

http://msdn.microsoft.com/en-us/library/dd316761(VS.85).aspx

Maybe FFdshow could be update to bitstream all those formats instead of only ac3 and dts

I don't understand the interest of this structure : in vista some players (powerdvd, totalmedia theater) already support bitstreaming of TrueHD/DTS-HD. So what does this bring ?

As far as I understand, the gap to fill is the following : add 2 options in the output section "Dolby TrueHD passthrough" and "DTS-HD passthrough" next to AC3/DTS passthrough.
Next step is to bitstream those 2 HD *compressed* streams as for SPDIF.
The good news is that we have an audio parser that knows everything : sample size, number of channels, bitrate and of course source format.
So correct me if I am wrong, but the thing to do is to parse the HD compressed stream and send samples directly to the renderer as for SPDIF. However maybe the samples need to be reordered into a certain way.

I have taken a look at the current code and for DD and DTS the passthrough is done respectively into liba52 and libdts because the input stream needs to be parsed (for sync frames) but after that it is sent to output.

The other problem is testing : I don't have any radeon HD4xxxx or asus xonar

Any thoughts ?