DiAVC decoder, yet another fast H.264 high profile decoder

[turbojet]

Originally Posted by schweinsz

Ok, I download some samples at http://www.cccp-project.net/beta/test_files/ and get the crash, I will fix it recently.

Thanks, maybe whatever is causing it is causing the seek delays too.

Originally Posted by adam777

First of all, great work, schweinsz, I've used DiAVC for the last 2 weeks or so, and am very happy with it.
One problem, that was already mentioned, I believe, is the decoder doesn't seem to work with EVR custom.
Trying the above combination results in a black screen with only audio playing.
As I normally use madVR, it's not such a big problem, but would probably need to be fixed in future releases.
Thank again for your work, Adam.

It works for me with EVR CP on Windows 7 x64. Are you using Vista or 7 and have the latest directx runtime installed?


I'm having problems setting DiAVC as preferred decoder on XP x86. It's a Q6600 with ffdshow the only other avc decoder installed and haali. If I disable ffdshow and open an avc m2ts/ts/mkv file in graphstudio a video decoder can't be found. However if I make a graph with haali+diavc it works for avisynth but it refuses to connect to video renderer, I can also set it to prefer in MPC-HC and it works. I've tried setting as preferred decoder in diavcsettings and changing to highest merit with graphstudio. Is anyone else experiencing this with XP or Vista? Any idea on how to set it to preferred?

With windows 7 its working fine.

[schweinsz]

Originally Posted by turbojet

Thanks, maybe whatever is causing it is causing the seek delays too.



It works for me with EVR CP on Windows 7 x64. Are you using Vista or 7 and have the latest directx runtime installed?


I'm having problems setting DiAVC as preferred decoder on XP x86. It's a Q6600 with ffdshow the only other avc decoder installed and haali. If I disable ffdshow and open an avc m2ts/ts/mkv file in graphstudio a video decoder can't be found. However if I make a graph with haali+diavc it works for avisynth but it refuses to connect to video renderer, I can also set it to prefer in MPC-HC and it works. I've tried setting as preferred decoder in diavcsettings and changing to highest merit with graphstudio. Is anyone else experiencing this with XP or Vista? Any idea on how to set it to preferred?

With windows 7 its working fine.

The current DiAVCSetting.exe works as follows: If the current default decoder is DiAVC, the DiAVCSetting.exe set a highest merit for DiAVC that is greater than 0xff800000.

[adam777]

Originally Posted by turbojet

It works for me with EVR CP on Windows 7 x64. Are you using Vista or 7 and have the latest directx runtime installed?

Weird, now it seems to be working part of the time.
At times I get black screen, at times the picture freeze and at times everything is normal (all of the above usually alternates when seeking).
I'm on Windows 7 x64 with everything up to date.

[mandarinka]

I recently reported a problem with video corruption using coreavc and attached two samples in this post: http://forum.doom9.org/showpost.php?...postcount=5265
I decided I should check your decoder too, as it clearly shows some promise.

The good news is, DiAVC doesn't show the described video corruption and links the mkv segments fine if video width changes...

... the bad news: If height changes, the player will crash. That means that it crashes with the two samples I provided in the linked post. Your decoder however works with other linked videos I have (but didn't upload) that have constant height but changing width.

I don't know whether it's a design limitation or not, but in case it's just something simple to fix, I decided to report it. Also, best luck with the decoder



PS: The videos decode fine individualy, the issues only happen when linking is performed - so for testing, haali splitter is required.

[schweinsz]

Originally Posted by mandarinka

I recently reported a problem with video corruption using coreavc and attached two samples in this post: http://forum.doom9.org/showpost.php?...postcount=5265
I decided I should check your decoder too, as it clearly shows some promise.

The good news is, DiAVC doesn't show the described video corruption and links the mkv segments fine if video width changes...

... the bad news: If height changes, the player will crash. That means that it crashes with the two samples I provided in the linked post. Your decoder however works with other linked videos I have (but didn't upload) that have constant height but changing width.

I don't know whether it's a design limitation or not, but in case it's just something simple to fix, I decided to report it. Also, best luck with the decoder



PS: The videos decode fine individualy, the issues only happen when linking is performed - so for testing, haali splitter is required.

I am sorry that I can't connect to the mediafire allrough I noticed your report before. I don't know what is the problem with my network. Could you upload them to http://www.multiupload.com/ or www.megaupload.com?

[Disabled]

Here you are:
http://www.multiupload.com/6O2ESAXATD
http://www.multiupload.com/NOBIIIVN3Z

P.s.: Thanks for mentioning multiupload, it seems pretty good.

*edit* I missed his edit in that thread:

[Edit:] PPS: I tried this version of Diavc; it doesn't show the corruptions I was experiencing with coreavc and links fine if width of video changes, while for some reason crashing on height change (so not a complete pass).

[Stephen R. Savage]

Any news on the beta version? Also, I'm pretty sure I'll be waiting a long time for CoreCodec (zzz) to implement weighted prediction support, so I'd like to use DiAVC for most of my decoding. One of the first problems I encountered was that seeking seems to only succeed half the time. The other half, the audio keeps going, but the video freezes. Repeating the seek attempt multiple times eventually succeeds.

Edit: Another problem. When opening a new video while a video is already playing in MPC-HC, DiAVC starts with a blank frame and a seek must be performed before it shows video.

Edit2: I've already complained about it before, but there is still some noticeable initialisation delay.

Edit3: It also seems to me that, although DiAVC achieves a higher framerate and lower CPU usage, playback is choppier than with CoreAVC. When under load, DiAVC seems to drop frames more often than other Core.

Hopefully these problems can be fixed. Keep up the good work.

(Note: I'm using EVR Custom renderer on Intel GMA 3100.)

[schweinsz]

Originally Posted by Stephen R. Savage

Any news on the beta version? Also, I'm pretty sure I'll be waiting a long time for CoreCodec (zzz) to implement weighted prediction support, so I'd like to use DiAVC for most of my decoding. One of the first problems I encountered was that seeking seems to only succeed half the time. The other half, the audio keeps going, but the video freezes. Repeating the seek attempt multiple times eventually succeeds.

I have fixed the problem and I'll release a bug-gixed alpha version recently.

Originally Posted by Stephen R. Savage

Edit: Another problem. When opening a new video while a video is already playing in MPC-HC, DiAVC starts with a blank frame and a seek must be performed before it shows video.

Edit2: I've already complained about it before, but there is still some noticeable initialisation delay.

Edit3: It also seems to me that, although DiAVC achieves a higher framerate and lower CPU usage, playback is choppier than with CoreAVC. When under load, DiAVC seems to drop frames more often than other Core.

Hopefully these problems can be fixed. Keep up the good work.

(Note: I'm using EVR Custom renderer on Intel GMA 3100.)

Which player do you use? I will try to fix these problems.
I engaged in fixing bugs recently and the beta version is delayed for many days, the beta version will be released about 12 days later. I am not familar with the directshow and fixing bugs in filter is a hard work for me. It took up more times than I expected.

"Playback is choppier" is because that the coreavc can drop un-referenced frames adaptively while the DiAVC hasn't the feature when the bitstream is hard, I will add the feature in future. As the beta version is faster than alpha version, the problem is easier.

[squid_80]

Originally Posted by schweinsz

"Playback is choppier" is because that the coreavc can drop un-referenced frames adaptively

No it doesn't...

[schweinsz]

Originally Posted by squid_80

No it doesn't...

To the best of my knowledge, the renderer chop is due to the late-arrived frames. The current disign of the DiAVC always copy decoded frames to renderers without considering the current time. I believe the problem of chop can be reduced by faster decoder (beta version), dropping non-reference frames and lower playback rate. Is there some other solutions of the problem?

[squid_80]

I don't know about a solution, I'm just pointing out that the CoreAVC filter doesn't ever drop any frames.

[Stephen R. Savage]

@schweinsz: I use MPC-HC v1.3 release. Thank you for looking into these issues.

And I sympathise. From what it looks like, all the bugs so far are in the DirectShow part and not the actual decoder.

[schweinsz]

Originally Posted by squid_80

I don't know about a solution, I'm just pointing out that the CoreAVC filter doesn't ever drop any frames.

The DiAVC achieve 22fps for a certain bitstream of 30mbps, PAFF and 24fps on my laptop while the coreavc achieve 19fps, but I found the DiAVC is choppier, there is no possibility that coreavc never drop frames.

[schweinsz]

Originally Posted by Stephen R. Savage

@schweinsz: I use MPC-HC v1.3 release. Thank you for looking into these issues.

And I sympathise. From what it looks like, all the bugs so far are in the DirectShow part and not the actual decoder.

I have fixed most among them, I will release a new alpha version tomorrow after I fix another bug.

[tmbt]

Great work schweinsz ... im really impressed how good your codec works and actually i didn't notice any tearing or slow reproduction.


Thanks !!!!

[squid_80]

Originally Posted by schweinsz

The DiAVC achieve 22fps for a certain bitstream of 30mbps, PAFF and 24fps on my laptop while the coreavc achieve 19fps, but I found the DiAVC is choppier, there is no possibility that coreavc never drop frames.

So how does DiAVC appear choppy if it can't drop frames? Shouldn't it just play slower than normal?

[Stephen R. Savage]

Some questions about (very) future development of DiAVC:

1) Is support for 4:2:2 or 4:4:4 subsampling, RGB coding, and higher bit depths (10-bit, 14-bit) planned?
2) Will that one bug that causes "maximum variance [-2,2]" in
"bitstream that hardly exist in the world" be fixed?
3) Can conversion to RGB be implemented in the DirectShow decoder? I ask this because only the decoder in DirectShow can know the VUI data and apply the correct color matrices (and color primaries, but that is less important). The same question goes for fullrange content.
4) Does DiAVC set the interlace flag on pictures with field coding? I have no interlaced content so I can not check this.

[schweinsz]

Originally Posted by squid_80

So how does DiAVC appear choppy if it can't drop frames? Shouldn't it just play slower than normal?

The DiAVC always try to copy all frames to the renderer. If the currrent bitstream is hard, when a piece of the bitstream contain high bitrate content, there is some frames arrived lately, this results a sudden delay of the renderer which is choppy.
A hard bitstream is not a uniform-hard bitstream, it is only hard on some piece of it.

[schweinsz]

Originally Posted by Stephen R. Savage

Some questions about (very) future development of DiAVC:

1) Is support for 4:2:2 or 4:4:4 subsampling, RGB coding, and higher bit depths (10-bit, 14-bit) planned?

This is not in the current plan, the current plans are beta-version, error concealment, 64-bit, MC-based super-resolution and lossless sequently. If there is a big need of the High422, High444, I will work on it.

Originally Posted by Stephen R. Savage

2) Will that one bug that causes "maximum variance [-2,2]" in
"bitstream that hardly exist in the world" be fixed?

I will fix it after beta version.

Originally Posted by Stephen R. Savage

3) Can conversion to RGB be implemented in the DirectShow decoder? I ask this because only the decoder in DirectShow can know the VUI data and apply the correct color matrices (and color primaries, but that is less important). The same question goes for fullrange content.

I will add the RGB support after the first realease of the beta version.

Originally Posted by Stephen R. Savage

4) Does DiAVC set the interlace flag on pictures with field coding? I have no interlaced content so I can not check this.

The current version always set Deinterlace_Bob for bitstreams that use interlace tools.

[squid_80]

Originally Posted by schweinsz

The DiAVC always try to copy all frames to the renderer. If the currrent bitstream is hard, when a piece of the bitstream contain high bitrate content, there is some frames arrived lately, this results a sudden delay of the renderer which is choppy.

...And this is exactly what CoreAVC does. All frames from the incoming bitstream are delivered to the renderer.