DiAVC decoder, yet another fast H.264 high profile decoder - Page 28

audyovydeo · 28th January 2010, 09:47

Quote:

Originally Posted by neuron2

I had started working on it ... I hope to come back to it soon, maybe as early as this evening!

Applause !
I for one am still bleeding from the loss of DGAVCDec ... especially since I bought an AVCHD camera the day it was killed !

cheers
audyovydeo

tommy_vercetti · 28th January 2010, 09:54

Quote:

Originally Posted by audyovydeo

Applause !
I for one am still bleeding from the loss of DGAVCDec ... especially since I bought an AVCHD camera the day it was killed !

cheers
audyovydeo

You could look into DGNV Tools I think they perform a similar role

audyovydeo · 28th January 2010, 11:32

Quote:

Originally Posted by tommy_vercetti

You could look into DGNV Tools I think they perform a similar role

I CUDA looked into it had my card allowed it ...

(sorry it was an irresistible impulse ! ;-)

cheers
a/v

schweinsz · 28th January 2010, 16:04

I have finished all colorspace-related works yesterday including nv12, yuy2, uyvy, rgb32, rgb24 and level scaling. I will work on a property page.
I finished a function about cavlc just now. All works about improved cavlc is more time-consuming than I estimated. Perhaps the DiAVC 1.0 will not include the improved cavlc and it will be available in one week after the release of DiAVC 1.0.

Stephen R. Savage · 28th January 2010, 18:18

I don't mean to second-guess you, but I just hope you would reassure us on some issues that seem endemic to colorspace conversion implementations:

1) What method will you use for interpolation of chroma when converting to YUY2 or to RGB? Will you implement a linear or cubic chroma interpolation instead of nearest-neighbor?

2) Have you implemented correct reading of colormatrix (and fullrange) flag from AVC stream and the appropriate Rec601 and Rec709 coefficients?

schweinsz · 28th January 2010, 18:31

Quote:

Originally Posted by Stephen R. Savage

1) What method will you use for interpolation of chroma when converting to YUY2 or to RGB? Will you implement a linear or cubic chroma interpolation instead of nearest-neighbor?

The current inplementation uses nearest-neighbor. If peoples like more accurate one, I can implement it.

Quote:

Originally Posted by Stephen R. Savage

2) Have you implemented correct reading of colormatrix (and fullrange) flag from AVC stream and the appropriate Rec601 and Rec709 coefficients?

Yes, the DiAVC read the vui for colormatrix and fullrange information.

Asmodian · 28th January 2010, 20:11

Quote:

Originally Posted by schweinsz

The current inplementation uses nearest-neighbor. If peoples like more accurate one, I can implement it.

Yes, the DiAVC read the vui for colormatrix and fullrange information.

Here at doom9 there are people that always like a more accurate one, spline64 should be sufficient though.

Thanks for the great work.

Keiyakusha · 28th January 2010, 20:38

Quote:

Originally Posted by Asmodian

spline64 should be sufficient though.

meh... thats too slow. after bicubic you won't notice any improvements unless you making screenshots and comparing them under 400% NN zoom. And even then its hard to see something.

Asmodian · 28th January 2010, 21:44

Quote:

Originally Posted by Keiyakusha

meh... thats too slow. after bicubic you won't notice any improvements unless you making screenshots and comparing them under 400% NN zoom. And even then its hard to see something.

hehe yes, sorry I was joking - bicubic would be great. I was just pointing out that if you ask the doom9 community if we want a more accurate resize we will say yes, and lots of options too please.

Stephen R. Savage · 29th January 2010, 00:16

Imo, nearest-neighbor interpolation for chroma is unacceptable, as it creates heavy aliasing near red/blue transitions. I think linear or cubic interpolation would be the best compromise between speed and quality for chroma.

schweinsz · 29th January 2010, 09:22

Quote:

Originally Posted by Stephen R. Savage

Imo, nearest-neighbor interpolation for chroma is unacceptable, as it creates heavy aliasing near red/blue transitions. I think linear or cubic interpolation would be the best compromise between speed and quality for chroma.

Ok, I will consider it just after 1.0 release.

Keiyakusha · 31st January 2010, 01:09

Hi. I'm using win7 32bit. I have mkv file with 2 AVC streams. One is 1280x720 and another is 720x480(16x9 DAR). I'm using latest haali splitter to split it and MPC-HC (EVR-CP) for playback.
Depending on which stream is set to be default in container, If I'll switch from 720p to 480p I'm getting this kind of screen.
If 480p is set to be default, and i'll go to 720p, I'm getting some emergency shutdown which is probably some equivalent to BSOD on win7.

With FFDShow (not DXVA) works perfect.
If second stream is not AVC, all works fine but the stream I switching to has problems with aspect ratio. Which is also fine with ffdshow.

EDIT: this is with DiAVC RC1

IgorC · 31st January 2010, 04:13

schweinsz,

Do you plan to support ARM? This year there will be a lot of new ARM based mobile devices. Corecodec and x264 have already prepared for this. No need to mention how Corecodec dominates with its CorePlayer in area of smart phones.

What a big deal around of non-SSE2 CPU support?
I mean I have an old PC with Prescott 3.06 GHZ+HT which I don't run anymore but even this dinosaur has SSE3 and plays 1080p 10-12 Mbits videos. And DiAVC is the fastest decoder on it. Ok, some people have an old CPUs but the poll shows with a good estimation that there are enough few of them. ~10-15%. This percentage will shrink quickly in 1-2 years.
While there are a lot of new CPUs especially (ultra) low voltage wich aren't enough fast. (mobile dual core i3/i5 <2 Ghz even w/Turbo).

schweinsz · 31st January 2010, 16:57

Quote:

Originally Posted by Keiyakusha

Hi. I'm using win7 32bit. I have mkv file with 2 AVC streams. One is 1280x720 and another is 720x480(16x9 DAR). I'm using latest haali splitter to split it and MPC-HC (EVR-CP) for playback.
Depending on which stream is set to be default in container, If I'll switch from 720p to 480p I'm getting this kind of screen.
If 480p is set to be default, and i'll go to 720p, I'm getting some emergency shutdown which is probably some equivalent to BSOD on win7.

With FFDShow (not DXVA) works perfect.
If second stream is not AVC, all works fine but the stream I switching to has problems with aspect ratio. Which is also fine with ffdshow.

EDIT: this is with DiAVC RC1

I am sorry that the current DiAVC doesn't support the dynamic format change.

schweinsz · 31st January 2010, 17:02

Quote:

Originally Posted by IgorC

schweinsz,

Do you plan to support ARM? This year there will be a lot of new ARM based mobile devices. Corecodec and x264 have already prepared for this. No need to mention how Corecodec dominates with its CorePlayer in area of smart phones.

What a big deal around of non-SSE2 CPU support?
I mean I have an old PC with Prescott 3.06 GHZ+HT which I don't run anymore but even this dinosaur has SSE3 and plays 1080p 10-12 Mbits videos. And DiAVC is the fastest decoder on it. Ok, some people have an old CPUs but the poll shows with a good estimation that there are enough few of them. ~10-15%. This percentage will shrink quickly in 1-2 years.
While there are a lot of new CPUs especially (ultra) low voltage wich aren't enough fast. (mobile dual core i3/i5 <2 Ghz even w/Turbo).

I will consider the arm platform. Actually I am more skilled with the arm platform even than x86 platform. But I must be sure the main platform that need a fast H.264 decoder.
CPU with wMMX, CPU with NEON or some old arm9 and arm11?
Windows mobile or android?

IgorC · 31st January 2010, 18:53

Quote:

Originally Posted by schweinsz

I will consider the arm platform.
CPU with wMMX, CPU with NEON or some old arm9 and arm11?
Windows mobile or android?

Cortex A8/9 all the way.
And maybe ARM11. There are plenty of the devices which still based on it.
Not sure about OSs.

Some related info.
http://x264dev.multimedia.cx/?p=142

schweinsz · 1st February 2010, 11:46

I uploaded a new DiAVCSetting version and the source code.
Some useless code is deleted.
I am very curious that two never-used functions related characters conversion mislead so many anti-virus to false positive.
Now only the norton reports Suspicious.Insight to the DiAVCSetting. How can I submit a report about the false positive to symantec?

the_corona · 1st February 2010, 13:12

here: https://submit.symantec.com/dispute/false_positive/

Virtual_ManPL · 4th February 2010, 11:16

Quote:

Originally Posted by Virtual_ManPL

...in other hand I find that seeking bug (you need to wait to see actual frames about 2-10s, sometimes even more than 20s) still exist in DiAVC decoder with EVR (C/A) in MPC-HC...

bug not fixed in RC1, will be nice to see it fixed in next release or at least in final

Stephen R. Savage · 6th February 2010, 08:46

I may have found a serious bug in DiAVC. When seeking backwards in video, sometimes the stream can degenerate into blocking artifacts. When this happens, these artifacts get progressively worse until an IDR is encountered. After being refreshed at the IDR, the video quickly breaks back down into blocks, and the only way to return to normal operation is to reopen the file. I have encountered this on two different streams now, but have unfortunately not been able to find a deterministic way of replicating it.

28th January 2010, 16:04	#544 \| Link
schweinsz Registered User Join Date: Nov 2005 Posts: 497	I have finished all colorspace-related works yesterday including nv12, yuy2, uyvy, rgb32, rgb24 and level scaling. I will work on a property page. I finished a function about cavlc just now. All works about improved cavlc is more time-consuming than I estimated. Perhaps the DiAVC 1.0 will not include the improved cavlc and it will be available in one week after the release of DiAVC 1.0. __________________ The Next Generation Internet Video Codec project.[/url].

31st January 2010, 01:09	#552 \| Link
Keiyakusha 契約者 Join Date: Jun 2008 Posts: 1,576	Hi. I'm using win7 32bit. I have mkv file with 2 AVC streams. One is 1280x720 and another is 720x480(16x9 DAR). I'm using latest haali splitter to split it and MPC-HC (EVR-CP) for playback. Depending on which stream is set to be default in container, If I'll switch from 720p to 480p I'm getting this kind of screen. If 480p is set to be default, and i'll go to 720p, I'm getting some emergency shutdown which is probably some equivalent to BSOD on win7. With FFDShow (not DXVA) works perfect. If second stream is not AVC, all works fine but the stream I switching to has problems with aspect ratio. Which is also fine with ffdshow. EDIT: this is with DiAVC RC1 Last edited by Keiyakusha; 31st January 2010 at 01:12.

1st February 2010, 11:46	#557 \| Link
schweinsz Registered User Join Date: Nov 2005 Posts: 497	I uploaded a new DiAVCSetting version and the source code. Some useless code is deleted. I am very curious that two never-used functions related characters conversion mislead so many anti-virus to false positive. Now only the norton reports Suspicious.Insight to the DiAVCSetting. How can I submit a report about the false positive to symantec? __________________ The Next Generation Internet Video Codec project.[/url].

28th January 2010, 18:18	#545 \| Link
Stephen R. Savage Registered User Join Date: Nov 2009 Posts: 327	I don't mean to second-guess you, but I just hope you would reassure us on some issues that seem endemic to colorspace conversion implementations: 1) What method will you use for interpolation of chroma when converting to YUY2 or to RGB? Will you implement a linear or cubic chroma interpolation instead of nearest-neighbor? 2) Have you implemented correct reading of colormatrix (and fullrange) flag from AVC stream and the appropriate Rec601 and Rec709 coefficients?

29th January 2010, 00:16	#550 \| Link
Stephen R. Savage Registered User Join Date: Nov 2009 Posts: 327	Imo, nearest-neighbor interpolation for chroma is unacceptable, as it creates heavy aliasing near red/blue transitions. I think linear or cubic interpolation would be the best compromise between speed and quality for chroma.

31st January 2010, 04:13	#553 \| Link
IgorC Registered User Join Date: Apr 2004 Posts: 1,315	schweinsz, Do you plan to support ARM? This year there will be a lot of new ARM based mobile devices. Corecodec and x264 have already prepared for this. No need to mention how Corecodec dominates with its CorePlayer in area of smart phones. What a big deal around of non-SSE2 CPU support? I mean I have an old PC with Prescott 3.06 GHZ+HT which I don't run anymore but even this dinosaur has SSE3 and plays 1080p 10-12 Mbits videos. And DiAVC is the fastest decoder on it. Ok, some people have an old CPUs but the poll shows with a good estimation that there are enough few of them. ~10-15%. This percentage will shrink quickly in 1-2 years. While there are a lot of new CPUs especially (ultra) low voltage wich aren't enough fast. (mobile dual core i3/i5 <2 Ghz even w/Turbo).

1st February 2010, 13:12	#558 \| Link
the_corona Registered User Join Date: Mar 2006 Posts: 55	here: https://submit.symantec.com/dispute/false_positive/

6th February 2010, 08:46	#560 \| Link
Stephen R. Savage Registered User Join Date: Nov 2009 Posts: 327	I may have found a serious bug in DiAVC. When seeking backwards in video, sometimes the stream can degenerate into blocking artifacts. When this happens, these artifacts get progressively worse until an IDR is encountered. After being refreshed at the IDR, the video quickly breaks back down into blocks, and the only way to return to normal operation is to reopen the file. I have encountered this on two different streams now, but have unfortunately not been able to find a deterministic way of replicating it.