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

thuan

3rd February 2010, 10:37

Late report about Intel G45, Vista 64bit SP2, with latest Intel G45 driver with Full Processing DXVA Post Processing mode:
- Beta1: Crash.
- Beta2: Sub does not work, wrong chroma rendering.

Speed is the same as normal DXVA and this computer has a Xeon X3220 (Core 2 Quad Q6600 equivalent) so no SSE 4.1, ergo that might be the problem, who knows.

Back to current version svn3254, I still have the blocky sub problem with this version. Otherwise, my computer at home uses a 9800GT with Windows7 64bit now has the same result as kado's computer.

tal.aloni

3rd February 2010, 11:44

thuan,
Thanks for the update about G45.
with rev. 3254, how blocky are the subs, all the time? or occasionally?

are there times when you have smooth playback with subs?

my computer at home uses a 9800GT with Windows7 64bit now has the same result as kado's computer.
please elaborate.

rpm7200

3rd February 2010, 12:35

dxva filter may cause blocking problem with my 8800gt. mpc's dxva is really good. please fix it.

thuan

3rd February 2010, 13:36

@tal.aloni:
1. The sub is exploded and broken up all the time. I have only tested karaoke sub so I don't know if the problem is lying with only animated sub or any type. I will test it tomorrow at work.

2. No, I haven't got smooth playback, but I will test more with normal sub as stated above.

3. As in rough outline because of overlaying instead of alpha blending.

If you need me to test more feel free to ask, I might not answer right away but surely I will :D. BTW, please look into the blocking problem when seeking as you have the time, thanks.

tal.aloni

3rd February 2010, 13:50

please look into the blocking problem when seeking as you have the time, thanks.

this mostly happen when using DXVA 2.0, but our code is almost the same as MPC-HC, I couldn't figure it out yet. albain or me will probably do eventually.

ikarad

3rd February 2010, 16:35

Sorry guys, i've been lost; what are we discussing?
I watch subtitles with MPC-HC, that's what i do care.
Live watching of any BD with its subtitles is much more important to me. -which MPC-HC makes-

The problem is that support of blu-ray subtitle from mpc-hc is only partial and bugged like in beta versions of vlc 1.1. It's not a full support and for now the correction of bugs seems to be abandonned by developpers of mpc-hc (lack of time or other priorities I think). It would be interesting if ffdshow could offer the full support of blu-ray subtitles.

cbemoore

3rd February 2010, 18:42

HeadlessCow

3rd February 2010, 21:44

What happens if you use WMP or MPC instead of Windows Media Center?

rica

3rd February 2010, 22:07

The problem is that support of blu-ray subtitle from mpc-hc is only partial and bugged like in beta versions of vlc 1.1. It's not a full support and for now the correction of bugs seems to be abandonned by developpers of mpc-hc (lack of time or other priorities I think). It would be interesting if ffdshow could offer the full support of blu-ray subtitles.

I wonder why i haven't met any bug?

rsd78

4th February 2010, 00:22

Finally testing rev3254, and I have found only 2 issues for me:

1. After skip/ff/rew blockiness in picture (already reported above)
2. The subtitle font size is much smaller than regular ffdshow. Playing the same movie with fonts on revealed a rather large difference in font size with all the obvious settings to me the same. I don't think anyone has reported this but I apologize.

This is all in Win 7 x32, WMC using ATI 2600xt and e8400.

thuan

4th February 2010, 04:18

@tal.aloni:
1. The sub is exploded and broken up all the time. I have only tested karaoke sub so I don't know if the problem is lying with only animated sub or any type. I will test it tomorrow at work.

2. No, I haven't got smooth playback, but I will test more with normal sub as stated above.
With normal sub, the problem is not as severe, but sometimes the timing is wrong when there's animated sub close by, and sometimes old sub does not get cleared and cause overlapping with newer sub. (On G45).

ikarad

4th February 2010, 12:52

I wonder why i haven't met any bug?
See here
http://sourceforge.net/apps/trac/mpc-hc/ticket/16
http://sourceforge.net/apps/trac/mpc-hc/ticket/48
http://sourceforge.net/apps/trac/mpc-hc/ticket/162

For example, one of bugs that i discovered is that when two subtitles from blu-rays are displayed in the same time, under mpc-hc, only one is displayed.
But if you see this links, you will see that support isn't perfect.

Momber

4th February 2010, 18:14

Sorry if this question has been asked before...
Are there any plans for ffdshow to decode DTS-HD MA completely in the future, as opposed to only the core?
ETA?

SamuriHL

4th February 2010, 18:20

Sorry if this question has been asked before...
Are there any plans for ffdshow to decode DTS-HD MA completely in the future, as opposed to only the core?
ETA?

Extremely unlikely. The DTS-HD MA spec is closed and there's no public information on how to decode it. There's literally NO OSS DTS-HD MA decoder out there.

rsd78

4th February 2010, 21:47

this mostly happen when using DXVA 2.0, but our code is almost the same as MPC-HC, I couldn't figure it out yet. albain or me will probably do eventually.

I don't know if this was explicitly stated or clear, but I wanted to add the blockiness after seeking appeared to only happen when Overlay was enabled vs just ffdshow dxva. This was only from my brief testing, so I could be wrong if it happens all the time with dxva.

SeeMoreDigital

4th February 2010, 22:40

Extremely unlikely. The DTS-HD MA spec is closed and there's no public information on how to decode it. There's literally NO OSS DTS-HD MA decoder out there.Is that for passing it as a bit-stream to an external decoder via HDMI or transcoding it to a multi-channel PCM stream via HDMI, or both?

SamuriHL

4th February 2010, 22:56

Is that for passing it as a bit-stream to an external decoder via HDMI or transcoding it to a multi-channel PCM stream via HDMI, or both?

There's no information on the spec period. Albain worked out how to bitstream it, so, that's already supported by ffdshow and has been working for a while now. However, decoding to LPCM is not an option. You can do the DTS core, but, the DTS-HD MA extensions can't be decoded.

BatKnight

4th February 2010, 23:31

Extremely unlikely. The DTS-HD MA spec is closed and there's no public information on how to decode it. There's literally NO OSS DTS-HD MA decoder out there.
If one plans to save the movie for future presentations, then the best way to keep the audio at its fullest is to decode the DTS-HD MA track with eac3to and Arcsoft Decoder (comercial) to FLAC, then mux the Flac into the MKV and remove the DTS-HD MA track from it. This way you will be able to play the lossless track with ffdshow.

This is what I do for movies I remux from Bluray and want to save. Of course this is not worth the trouble and time if you plan on watching the movie once and then delete it.
In the end, even if you're up to it, it's very hard to hear differences from DTS-HD MA and the internal core. I am not saying there aren't, because obviously there are, but you must have a very good Home Cinema set and even better ears.

Bat

SamuriHL

4th February 2010, 23:56

If one plans to save the movie for future presentations, then the best way to keep the audio at its fullest is to decode the DTS-HD MA track with eac3to and Arcsoft Decoder (comercial) to FLAC, then mux the Flac into the MKV and remove the DTS-HD MA track from it. This way you will be able to play the lossless track with ffdshow.

This is what I do for movies I remux from Bluray and want to save. Of course this is not worth the trouble and time if you plan on watching the movie once and then delete it.
In the end, even if you're up to it, it's very hard to hear differences from DTS-HD MA and the internal core. I am not saying there aren't, because obviously there are, but you must have a very good Home Cinema set and even better ears.

Bat

I'd rather keep the original track unmolested and bitstream it to my receiver. I know my receiver decodes things correctly (no downsampling, channel mapping issues, etc). Since bitstreaming bypasses all windows audio nonsense, then I am assured a nice, pristine sound experience the way it was intended. Yes, FLAC is great and is lossless, but, then you have to worry about making sure you're sending the resulting LPCM track (what FLAC is decoded to when playing it in ffdshow) is sent to the receiver using exclusive mode, else you're again at the mercy of windows audio. Bitstreaming allows me to avoid all these problems altogether. That's just my personal opinion. There is no one right way for everyone.

Caroliano

5th February 2010, 23:21

FFDShow's quantizer visualization and maybe also the "Frame mean quantizer" OSD info seems to be broken with H.264. Acording to Darkshikari:

I think that the correct behaviour would be to say that it is a empty block, maybe with an "/" instead of the number, for example. Any plans to correct this? FFDShow's OSD and visualizations is one of the main features of ffdshow for me (besides decoding, of course). It is really unfortunate that it is not displaying correct information, making it misleading and thus partially useless....

Original discussion and pictures: http://forum.doom9.org/showthread.php?t=152399
No-one interested in fix it? :confused:

Momber

6th February 2010, 11:47

decode the DTS-HD MA track with eac3to and Arcsoft Decoder (comercial) to FLAC
Sure, that's what I do.
But it would be nice to be able to skip this processing, not to the least in order to save time.
Maybe someone needs to reverse-engineer the Arcsoft Audio Decoder... hint, hint ;)

albain

6th February 2010, 20:37

Hi,

I didn't find out (yet) why seeking doesnt work with dxva2

Otherwise I am working on Bluray subs implementation using ffmpeg
Simultaneous subs will be handled

tal.aloni

6th February 2010, 22:30

rica

6th February 2010, 22:56

We can not compare with nVidia's but i'm almost sure it's an Ati driver issue.

tal.aloni

6th February 2010, 23:49

rica,
I have both Radeon and Geforce, The skip issue is occuring on both. (DXVA 2.0)

rica

7th February 2010, 00:07

tal,
i maent a bitstream capable Geforce, dunno what nVidia card you meant? Or any bitstream capable nvidia card exists i don't know?

tal.aloni

7th February 2010, 00:39

rica, I thought you refer to the garbled-video-when-seeking issue with DXVA 2.0.
nevermind.

rica

7th February 2010, 00:57

Sorry tal, but i can't say i understood what you meant?

rsd78

7th February 2010, 01:09

I decided to have a quick look on the seeking issue related to DXVA 2.0,
unfortunately, after 6 hours, I still did not figure it out.

I suspect it has something to do with the Flush method.
it seems that MPC-HC does it differently [calls it from NewSegment()],
while we do it in BeginFlush() without locking the csReceive first.

when locking csReceive, I'm getting the famous deadlock, I tried to figure out why without success.
I don't even understand in which part those samples are being released.

Regards,
Tal

Sorry to hear that.

I don't know if it helps but I'm also seeing almost like a repeat of some frames after seeking, besides the blockiness. Would love it if this bugger could get figured out, but thanks again for all the hard work.

Snowknight26

7th February 2010, 03:39

This panel could look better. Too many overlapping labels, lots white space and inconsistent spacing.

http://i48.tinypic.com/1zf0qco.jpg

With regards to corruption when seeking, I've noticed that Blu-ray remuxes of mine don't show any corruption at all when seeking, only encodes I've done. Could it possibly be related to slices?

tal.aloni

7th February 2010, 10:47

I don't know if it helps but I'm also seeing almost like a repeat of some frames after seeking, besides the blockiness.

I see that too.

I've noticed that Blu-ray remuxes of mine don't show any corruption at all when seeking, only encodes I've done.

I have curroption on both encodes and Blu-Rays (both H.264 and VC-1).

Thanks

albain

7th February 2010, 12:08

I decided to have a quick look on the seeking issue related to DXVA 2.0,
unfortunately, after 6 hours, I still did not figure it out.

I suspect it has something to do with the Flush method.
it seems that MPC-HC does it differently [calls it from NewSegment()],
while we do it in BeginFlush() without locking the csReceive first.

when locking csReceive, I'm getting the famous deadlock, I tried to figure out why without success.
I don't even understand in which part those samples are being released.

Regards,
Tal

Interesting, I came on the exact same problem at the beginning (first DXVA import) : so I disabled the lock
"CAutoLock lock(&m_csCodecs_and_imgFilters);" inside STDMETHODIMP TffdshowVideoInputPin::BeginFlush() for DXVA mode otherwise I got deadlocks

But maybe this lock should be replaced by another used only in DXVA methods

albain

7th February 2010, 12:55

Hi Tal,

I have made a patch that may fix the DXVA2 seeking

Can you tell me if this works for you ? Thanks

Here is the link (http://damienbt.free.fr/dxva2_seek_possible_fix.patch)

tal.aloni

7th February 2010, 14:30

albain

7th February 2010, 14:59

Hi Albain,
unfortunately, when testing your patch I still got garbled input when seeking (DXVA 2.0), I also encountered a deadlock.

p.s.
both yesterday and today I've encountered this line several time in the debug log:

number of reference frames exceeds max (probably corrupt input), discarding one

Oh, I saw that before when trying the multithreading lead: this means that the DXVA allocator is full of reference frames.
I had this problem when the DXVA H264 decoder messed up with the m_nOutPoc attribute in TDXVADecoderH264::FindOldestFrame()
if (m_pPictureStore[i].nCodecSpecific == m_nOutPOC && m_pPictureStore[i].rtStart < rtPos)

I don't know what this is for but the result is that the oldest frames remain in the allocator and are never processed whereas the new frames are processed.

This is a big problem because there are less slots available in the DXVA allocator (only 1/20 in my tests)

This was the reason why I gave up on multithreading

tal.aloni

7th February 2010, 18:01

I had another look,
the DeliveryBuffer is released when a condition is met upon a call to TDXVA2Sample::Release()

I saw that when decoding starts, about 20 frames are accumulated, and then, as you said, a single frame is removed for every single frame that is added.

tal.aloni

7th February 2010, 20:01

Albain,
see this patch, it doesn't resolve this issue completely, but it may teach us something.
I think one reason for the garbled input is that we're waiting for an I frame, but then not delivering it because rtStart < 0.

EDIT: or because m_pPictureStore[i].nCodecSpecific != m_nOutPOC
maybe this tells you something...

--- codecs/TDXVADecoderH264.cpp Sun Feb 07 20:54:17 2010
+++ codecs/TDXVADecoderH264.cpp Sat Jan 30 20:38:58 2010
@@ -227,7 +227,7 @@
return S_FALSE;

// Wait I frame after a flush
- if (m_bFlushed && !m_DXVAPicParams.IntraPicFlag)
+ if (m_bFlushed && (!m_DXVAPicParams.IntraPicFlag || rtStart < 0))
return S_FALSE;

--- TffdshowVideoInputPin.cpp Sun Feb 07 20:51:59 2010
+++ TffdshowVideoInputPin.cpp Sun Jan 31 19:12:14 2010
@@ -534,7 +534,7 @@
// it will be okay)
if (fv && fv->deci && video && video->useDXVA() != 0)
{
- m_rateAndFlush.m_flushing = true;
+ /*m_rateAndFlush.m_flushing = true;
video->BeginFlush();
comptrQ<IffdshowDecVideo> deciV=fv->deci;
TimgFilters* filters;
@@ -543,7 +543,7 @@
filters->onFlush();

m_rateAndFlush.flushed = true;
- m_rateAndFlush.isDiscontinuity = true;
+ m_rateAndFlush.isDiscontinuity = true;*/
return CTransformInputPin::BeginFlush();
}

albain

7th February 2010, 23:52

Ill test your patch tomorrow (dont have my Htpc accessible right now)

This mPoc variable is a real pain because if for a reason you a picture with a given Poc is not processed, it will never be processed and freed, which happens when you seek AND when seeking takes too much time : which occurs with processing in the loop

This problem also occurred with full postprocessing without seeking at all

I dont know why exactly, maybe because frames are dropped because incorrectly parsed during seeking or maybe because we didn't flushed all the frames in some cases

This is really difficult to understand. Vc1 does not have POCs maybe thé problem only concerns H264

tal.aloni

8th February 2010, 00:11

something is definitely not right in the code, but I can't understand why MPC-HC doesn't have any issue....
seeking problems happen also with VC-1.

cbemoore

8th February 2010, 16:19

For some reason, I can't get any files to play back properly using DXVA. I get about 3 or 4 seconds of garbled playback, and then my display driver resets again and again until I kill the player.

My setup:

Windows 7 x64
ffdshow x64 r3254
Windows Media Center
Win7DSFilter utility set to disable Media Foundation and enable ffdshow in WMC
NVidia 8500GT
Nvidia 196.34 x64 drivers

The normal ffdshow video decoder works perfectly, so I guess it must be something to with the ffdshow DXVA decoder.

This error has occurred ever since DXVA was first checked into SVN. I've tried changing graphics drivers (to the NVidia 196.21 WHQL drivers), but that hasn't helped...

Is there anything I can do to help track down the problem?

I've tried MPC-HC and I get the exact same crashing problem. So it looks like a problem with my card/drivers rather than an FFDShow bug.

I've tried rolling back to various older drivers, but no luck. So I've used it as an excuse to order a shiny new HD 5450 card :). I'll re-test when the card arrives and post any issues here.

Sorry for raising a false alarm!

Snowknight26

8th February 2010, 20:48

I'm glad DXVA support was ported from MPC-HC. Now I can complain about bugs in two threads. :P

http://i49.tinypic.com/3323wop_th.jpg (http://i49.tinypic.com/3323wop.jpg)

Lossless content should NOT be allowed to use DXVA. Maybe if someone fixes this issues in ffdshow they can fix it in MPC-HC as well. ;)

tetsuo55

9th February 2010, 08:42

something is definitely not right in the code, but I can't understand why MPC-HC doesn't have any issue....
seeking problems happen also with VC-1.

Pure luck, you should assume the bug is there in mpc-hc too, we're just lucky that a 2nd bug is making it invisable.

tal.aloni

9th February 2010, 10:09

lol, I didn't mean to offend MPC-HC. maybe I should have chosen my words more carefully. sorry!

tetsuo55

9th February 2010, 14:10

lol, I didn't mean to offend MPC-HC. maybe I should have chosen my words more carefully. sorry!Sorry i was not clear.

Here is what i mean.

Here is what you said:

1. You have found a problem in ffdshow with seeking
2. You wonder why MPC-HC does not have this problem (as you might find a soluton in the MPC-HC code or team)

Here is what i tried to say:

1. I "think" the problem you mention in ffdshow, occurs in MPC-HC in exactly the same way.
2. I "think" that in MPC-HC there is an accidental or purposefull "hack" to hide the problem.

MPC-HC has many wierd seeking bugs, maybe you have found the cause of this long standing issue :)

tal.aloni

9th February 2010, 14:25

tetsuo55,
it's possible that you are right,
I think I already found one possible bug with MPC-HC code,
I sent Casimir666 a PM, he might confirm, or point out that I'm wrong.

anyway, if I'm right, we'll have to make some big changes to DXVA frame store (internal mechanism to order frames before output). luckily, I have some experience in that exact part. (it's not going to be easy though)

JarrettH

9th February 2010, 21:55

are official builds, like the last one from 2008, not being released anymore?

rica

9th February 2010, 23:14

are official builds, like the last one from 2008, not being released anymore?

Yeah?
Why not following MS' method?
Just release fake alpha and put SP patches over it :)

PetitDragon

10th February 2010, 06:19

BUG REPORT!

After ffdshow tryouts project, svn 3247, when using "ffmpeg-mt" decoder, ffdshow refuses to auto load custom profiles (presets). It always loads default profile only.

Other decoders have no such problem.

Will it be fixed?

Thanks for your attention.

hoborg

10th February 2010, 15:17

Some small problems i found: (build 3255)

- if you click "export all settings" no DXVA registry keys are exported
- some DXVA subtitles setting are shared with standard subtitle settings - "Accept SSA..." for example - maybe it is correct, no idea.

tal.aloni

10th February 2010, 21:46

After a week of intensive code review, I've finally nailed the galbled-seeking issue:
it turns out that there is mechanism in ffdshow that drops input samples when decoding of current sample failed.
(in DXVA, we "fail" some input samples on skip)

I've disabled this mechanism for DXVA. (rev. 3258)

Thanks Casimir666 for providing guidance, and xhmikosr for additional assistance.

p.s.
1. for some reason, this affected only (or mostly) Windows Vista / 7.
2. during my long debug sessions I've uncovered some additional places that could use some improvements.