ffdshow tryouts project: Discussion & Development - Page 522

tal.aloni · 21st January 2010, 22:24

mark0077
thanks for letting me know!
let me know if it's fixed with rev. 3215

dann23
we still did not implement subtitle input pin, so only external subtitles are working now (movie.srt).
we will implement the subtitle input pin in the future.

tetsuo55
I've spoken with casimir,
in m2ts: MPC assign the PTS timestamp to each frame,
haali does not.
in mkv: we're not even sure that there is a container timestamp, so neither you or haali assign the chronological value.

the only thing we can do is to ask haali to assign the PTS timestamp to vc-1 in m2ts like you do, but we would still need some check based on the container, so not much will change.

Tal

Jeremy Duncan · 21st January 2010, 22:31

Quote:

Originally Posted by leeperry

any chance for a reply please concerning the avisynth "fix"? Leak didn't see anything to fix last time he checked I think if we're talking about the same thing

My diff file. I made a ffdshow installer and ffdshow avisynth and resizing works with this diff file.

IanB said to ignore this part of the diff file though: src/imgFilters/avisynth/TimgFilterAvisynth.h @@ -99,7 +99,12 @@, but it works for me.

leeperry · 21st January 2010, 22:44

ok ok...well, please allow me to come whine if the patch is no workee...and I might very well not be the only one if it's as broken as the previous version I tried

and you guys hoping Haali to help you w/ anything...

tetsuo55 · 21st January 2010, 23:04

Quote:

Originally Posted by tal.aloni

tetsuo55
I've spoken with casimir,
in m2ts: MPC assign the PTS timestamp to each frame,
haali does not.
in mkv: we're not even sure that there is a container timestamp, so neither you or haali assign the chronological value.

the only thing we can do is to ask haali to assign the PTS timestamp to vc-1 in m2ts like you do, but we would still need some check based on the container, so not much will change.

Tal

ok, but that still doesnt adres the problem of mixed up frames.

tal.aloni · 21st January 2010, 23:10

leeperry,
I was referring to a regression with rev. 3205 that I fixed regarding avisynth not delivering additional frames being created.

Jeremy Duncan refers to another issue regarding x64 compatibility (if I understood correctly).

Jeremy Duncan · 21st January 2010, 23:14

Quote:

Originally Posted by tal.aloni

leeperry,
I was referring to a regression with rev. 3205 that I fixed regarding avisynth not delivering additional frames being created.

Jeremy Duncan refers to another issue regarding x64 compatibility (if I understood correctly).

No no, it's for accurate frame seeking: Patch fixes incorrect timestamps, redice crashes on stop, reduce memory usage a bit.
The x64 part enables the patch to work in windows 7 64 bit.

Maybe include the diff file patch in the svn and LeePerry can try it out?

With these newer ffdshow trunk builds you also need to do this to get the benefit of the patch though:
Decoder options tab
Uncheck "Detect soft telecine and average frame durations"

tal.aloni · 21st January 2010, 23:23

Quote:

Originally Posted by Jeremy Duncan

Maybe include the diff file patch in the svn and LeePerry can try it out?

I suggest you update the patch to the latest revision,
post a beta build so people can test,
also, if the patch include multiple functions (like x64 support), it's best to test and commit them one by one.

leeperry · 22nd January 2010, 01:01

Quote:

Originally Posted by tal.aloni

leeperry,
I was referring to a regression with rev. 3205 that I fixed regarding avisynth not delivering additional frames being created.

Jeremy Duncan refers to another issue regarding x64 compatibility (if I understood correctly).

ok, thanks for the clarification!

currently w/ CoreAVC CUDA 2.0/ffdshow/avisynth, it currently jumps two frames ahead when I do frame step by step in KMP(it used to be only one frame) the first time(the following frames are OK)...but I didn't try to find the culprit, as it's really no biggy for me.

Quote:

Originally Posted by tal.aloni

I suggest you update the patch to the latest revision,
post a beta build so people can test,
also, if the patch include multiple functions (like x64 support), it's best to test and commit them one by one.

please noone take it bad, but Jeremy's bruteforce approach to compiling software scares me a bit

deets · 22nd January 2010, 15:06

I hope i haven't missed a post, tried to keep up

would any of the devs mind commenting either way if they have any plans to make DXVA compatible with live streams. Cinch had some stuff in a post about it but i havent (unless i missed it) seen any reply.

if you don't have any plans to address this, we can let it go

appreciate your work and im not pushing it, just wondering if its been noted or not

THX-UltraII · 22nd January 2010, 15:58

Quote:

Originally Posted by Jeremy Duncan

beta ffdshow: link

Is there also a x64 version link?

tal.aloni · 22nd January 2010, 23:14

some updates:
1. I can't get DXVA hardware alpha blending to work yet, I'll keep trying. (getting E_FAIL from the driver)

2. software overlay mode: it seems that most of the cpu consumption is dedicated to the high quality drawing method I implemented.
I'll try to write a faster method for overlay, I might leave the current method as "Overlay - High Quality".

p.s.
since hardware alpha blending requires conversion to AYUV 32, (and calculating an alpha mask), it would be a safe to assume software overlay would (after optimizations) be faster then hardware alpha blending.

HeadlessCow · 22nd January 2010, 23:22

Is it something that's only supported on certain cards?

tal.aloni · 23rd January 2010, 00:30

I don't really know, it's part of the specs, so it should be supported on every modern DXVA 1.0 device.

I have an nvidia GPU as well, so I can test it as well later.

DigitalDeviant · 23rd January 2010, 03:30

Starting sometime after rev. 3204, IVTC via avisynth make the video stutter extremely bad. I've tried severl versions through to the latest, 3217, and the last working version seems to be 3204.

CruNcher · 23rd January 2010, 08:20

there are still artifacts tal.aloni (Nvidia) compared to MPC-HCs decoder

also if i try to close the video now libavcodec.dll crashes im using xhmikosr current 3219 build

tal.aloni · 23rd January 2010, 11:00

Quote:

Originally Posted by CruNcher

there are still artifacts tal.aloni (Nvidia) compared to MPC-HCs decoder

you mean when seeking, right?

Quote:

Originally Posted by CruNcher

also if i try to close the video now libavcodec.dll crashes im using xhmikosr current 3219 build

since which revision? this might be related to ffmpeg. (please provide more details, I've tested this build and I don't any any issue)

XhmikosR · 23rd January 2010, 14:05

Everything seems to work as usual for me too. I've also updated my GCC to v4.4.3.

dann23 · 23rd January 2010, 14:20

I made some test using dxva and haali splitter, divx mkv splitter and matroska splitter from mpc-hc website.
With haali I can play all the movies. No artifacts.
With divx all the movies play but many artifacts.
And with matroska splitter some of the movies don't play. Just black screen. And some artifacts. Also I found that if using matroska splitter and the movie has mpeg2 video in it, it won't play.
The test was on windows xp with ati 3850. Also I want to mention that using beta2 from albain has no problem with matroska splitter. The problem appeared after that build.

Edit.
Some artifacts also appear with haali but very rarely.

CruNcher · 23rd January 2010, 18:02

Quote:

you mean when seeking, right?

Nope after a while of playback with this 60 FPS stream most other streams are ok no problem with MPC-HC DXVA and this 60 fps stream you can find it some pages back WipeOut 1080p 60 FPS PS3 Main L 4.1 Gameplay trailer

Quote:

since which revision? this might be related to ffmpeg. (please provide more details, I've tested this build and I don't any any issue)

i didn't tried different revisons yet one moment

i find it out but it was happening very recently maybe the 2 last builds i give you the exact build when it appeared mom

the crash problem appeared between 3212-3217

3212 = ok (file close in MPC-HC)
3217 = libvcodec.dll crash on exit (file close in MPC-HC)
3219 = libavcodec.dll crash on exit (file close in MPC-HC)

sorry i don't have any other builds to test

tal.aloni · 23rd January 2010, 18:51

Quote:

Originally Posted by CruNcher

sorry i don't have any other builds to test

http://www.mediafire.com/?sharekey=3...e79d7d0540e1e1

old builds > generic > page 2

let's narrow it down to a build, ok?

21st January 2010, 22:44	#10423 \| Link
leeperry Kid for Today Join Date: Aug 2004 Posts: 3,477	ok ok...well, please allow me to come whine if the patch is no workee...and I might very well not be the only one if it's as broken as the previous version I tried and you guys hoping Haali to help you w/ anything... Last edited by leeperry; 21st January 2010 at 22:59.

23rd January 2010, 03:30	#10434 \| Link
DigitalDeviant Registered User Join Date: Sep 2003 Posts: 267	Starting sometime after rev. 3204, IVTC via avisynth make the video stutter extremely bad. I've tried severl versions through to the latest, 3217, and the last working version seems to be 3204. __________________ "Do everything by hand, even when using the computer." - Hayao Miyazaki

23rd January 2010, 08:20	#10435 \| Link
CruNcher Registered User Join Date: Apr 2002 Location: Germany Posts: 4,926	there are still artifacts tal.aloni (Nvidia) compared to MPC-HCs decoder also if i try to close the video now libavcodec.dll crashes im using xhmikosr current 3219 build __________________ all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 23rd January 2010 at 08:22.

23rd January 2010, 14:05	#10437 \| Link
XhmikosR Registered User Join Date: Mar 2007 Location: Hellas (Greece) Posts: 543	Everything seems to work as usual for me too. I've also updated my GCC to v4.4.3. __________________ My builds Notepad2-mod My Specs

23rd January 2010, 14:20	#10438 \| Link
dann23 Registered User Join Date: Apr 2009 Posts: 89	I made some test using dxva and haali splitter, divx mkv splitter and matroska splitter from mpc-hc website. With haali I can play all the movies. No artifacts. With divx all the movies play but many artifacts. And with matroska splitter some of the movies don't play. Just black screen. And some artifacts. Also I found that if using matroska splitter and the movie has mpeg2 video in it, it won't play. The test was on windows xp with ati 3850. Also I want to mention that using beta2 from albain has no problem with matroska splitter. The problem appeared after that build. Edit. Some artifacts also appear with haali but very rarely. Last edited by dann23; 23rd January 2010 at 14:48.

21st January 2010, 22:24	#10421 \| Link
tal.aloni Registered User Join Date: Sep 2008 Posts: 496	mark0077 thanks for letting me know! let me know if it's fixed with rev. 3215 dann23 we still did not implement subtitle input pin, so only external subtitles are working now (movie.srt). we will implement the subtitle input pin in the future. tetsuo55 I've spoken with casimir, in m2ts: MPC assign the PTS timestamp to each frame, haali does not. in mkv: we're not even sure that there is a container timestamp, so neither you or haali assign the chronological value. the only thing we can do is to ask haali to assign the PTS timestamp to vc-1 in m2ts like you do, but we would still need some check based on the container, so not much will change. Tal

21st January 2010, 23:10	#10425 \| Link
tal.aloni Registered User Join Date: Sep 2008 Posts: 496	leeperry, I was referring to a regression with rev. 3205 that I fixed regarding avisynth not delivering additional frames being created. Jeremy Duncan refers to another issue regarding x64 compatibility (if I understood correctly).

22nd January 2010, 15:06	#10429 \| Link
deets Registered User Join Date: Jan 2005 Location: london, england Posts: 509	I hope i haven't missed a post, tried to keep up would any of the devs mind commenting either way if they have any plans to make DXVA compatible with live streams. Cinch had some stuff in a post about it but i havent (unless i missed it) seen any reply. if you don't have any plans to address this, we can let it go appreciate your work and im not pushing it, just wondering if its been noted or not

22nd January 2010, 23:14	#10431 \| Link
tal.aloni Registered User Join Date: Sep 2008 Posts: 496	some updates: 1. I can't get DXVA hardware alpha blending to work yet, I'll keep trying. (getting E_FAIL from the driver) 2. software overlay mode: it seems that most of the cpu consumption is dedicated to the high quality drawing method I implemented. I'll try to write a faster method for overlay, I might leave the current method as "Overlay - High Quality". p.s. since hardware alpha blending requires conversion to AYUV 32, (and calculating an alpha mask), it would be a safe to assume software overlay would (after optimizations) be faster then hardware alpha blending.

22nd January 2010, 23:22	#10432 \| Link
HeadlessCow Registered User Join Date: Nov 2002 Posts: 131	Is it something that's only supported on certain cards?

23rd January 2010, 00:30	#10433 \| Link
tal.aloni Registered User Join Date: Sep 2008 Posts: 496	I don't really know, it's part of the specs, so it should be supported on every modern DXVA 1.0 device. I have an nvidia GPU as well, so I can test it as well later.