CoreCodec/H.264 Codec "CoreAVC" [Archive] - Page 67

Yufi

5th November 2007, 00:24

CoreAVC dshow filter can be used on Linux by patching MPlayer, Xine or MythTV: http://code.google.com/p/coreavc-for-linux/

Of course, it would be nicer if an official library was released.

Those patches don't work with the latest versions of mythtv or mplayer, unfortunately; nor do they work with the latest versions of CoreAVC. Plus, I'd really prefer having an "official" linux version then having to hack together patches each time software was updated.

red5goahead

5th November 2007, 14:02

edit: Red5, check ReClock, it works fine with CoreAVC

I know ReClock but under Vista or related to multichannel audio spdif stream Reclock do not work. Should be the decoder (CoreAvc) or the renderer (?) to build the progressive telecining. is it weird think that features in CoreAvc?

BetaBoy

9th November 2007, 15:19

All.... prior to CoreAVC v1.6.1 we have two goals. One is here:
http://www.coreavc.com/retrieve

You can now retrieve your CoreAVC Serial number at anytime in case you have forgotten or lost it (this information has also been added into our CoreAVC KB at http://support.corecodec.com ).

The second goal we are working on now is the 14 day Trial version which we hope to have out shortly.

Eretria-chan

9th November 2007, 16:37

14 days? Isn't that a bit cheap? Most give 30 days.

GmorG McRoth

9th November 2007, 17:13

14 days? Isn't that a bit cheap? Most give 30 days.

Maybe that means 336 Hours of playback :)

BetaBoy

9th November 2007, 18:24

That debate is still going on internally 14 vs 30, but its 14 as of this moment... but as demographic studies are concerned.... a user has made his decision way before the 14 days is over with.

bkman

11th November 2007, 05:22

ACrowley

11th November 2007, 09:19

Betaboy,

I have a clip where CoreAVC displays motion errors but ffmpeg does not, so I think it may be a bug in CoreAVC. Though it could also be a bug in x264, or a bug in my ram.

Can you look into it? Here's the clip:

http://www.mediafire.com/?djcnyc0wzto

Its the "Motion Vector Bug"
It was discussed in this Thread before
The Problem was caused by older 264 Builds (under rev663) because the encoded Motion Vector Value was to high/wrong (so far i can remember)

CoreAVC produce ugly Blocking in this Sceens with fast movement and/or Water,Rain etc. Where libavcodec,Cyberlink,Sonic have no Problem

So encode only with new x264 Builds and youve no Problem
When you ask me, i hope Corecodec can fix it :)

bkman

11th November 2007, 11:09

But I used a newish x264 build for that encode. Cef's 680. :confused:

ACrowley

11th November 2007, 11:37

But I used a newish x264 build for that encode. Cef's 680. :confused:

i use 682 (AQ) and i have no Problems with new Builds .
No more Blocking..it was with Builds - rev 663, are you sure it was a new Build ?

What Source ?
What Decoder for Source Decoding
etc...

bkman

12th November 2007, 07:16

The source is DVD. The decoder is DGDecode. You know, the usual.

That part of this movie was the only instance of this problem I've seen out of multiple encodes.

ACrowley

12th November 2007, 09:59

Ok..so its caused by Decoding

Try to use another Mpeg2 Decoder

HowlerX

12th November 2007, 10:11

Ok..so its caused by Decoding

Try to use another Mpeg2 Decoder

Dude, did you download the sample? The sample plays and looks fine with ffdshow decoder. Looks like shit with CoreAVC.

Either bkman has an older build of x264 and doesn't know it. Or the bug is still present. Who can tell?

Someone posted that this would be a simple fix for the CoreAVC team to implement, maybe they should just listen and fix it.

I've seen this "video corruption" on many of my older encodes and seems like a waste to re-encode all over again.

Shinigami-Sama

12th November 2007, 21:20

it doesn't seem like it'd be that hard to make it handle it, even if it was a checkbox in the advanced section to do it...

ACrowley

12th November 2007, 22:38

Dude, did you download the sample? The sample plays and looks fine with ffdshow decoder. Looks like shit with CoreAVC.

Either bkman has an older build of x264 and doesn't know it. Or the bug is still present. Who can tell?

Someone posted that this would be a simple fix for the CoreAVC team to implement, maybe they should just listen and fix it.

I've seen this "video corruption" on many of my older encodes and seems like a waste to re-encode all over again.

Ah yes...didnt spend much Time on it.
Ofcourse youre Right, when its Ok with other Decoders it shouldnt be a Source Decoding Problem

I know...i cant understand why CoreCodec wont fix this MotionVector Thing!
I pers wont reencode my whole x264 encodes from "older" x264 encodes (-rev 663) only because CoreAVC cant handle them :)
Cyberlink/ffdshow etc works perfect.

I think its Easy : Corecodec ( and some Posting here) say it not a CoreAVC Problem, its a x264 Problem :rolleyes:
But in Fact, when CoreAVC is the only Decoder with Problems on those encodes...its a CoreAVC Problem too, so or so.

However, his Sample looks exactly like the MotionVector Bug so i assume its was really a older x264 rev.
You cant see extended H264 User Data Infos in this short Sample with Avinaptic Tool, so i cant see the "real" x264 rev from encoding

@bkman
Even when you know it was a new x264 rev, please check your full Encode with AVInaptic Tool
You can see the x264 rev in "About H264 encoding / User Data "

Inventive Software

12th November 2007, 22:59

akupenguin

12th November 2007, 23:12

it doesn't seem like it'd be that hard to make it handle it, even if it was a checkbox in the advanced section to do it...
Not necessarily. I can only guess why CoreAVC depends on the exact mv length restriction, but some reasons could depend on optimizations that would be impossible to handle (even optionally) without costing speed. e.g. if they pack mvs into a 12bit data data structure, mvs > 12bits will be borked, and you can't exactly re-layout your data structures at runtime.

Disabled

12th November 2007, 23:20

Their problem is that they've created a spec-compliant decoder. x264 didn't create spec-compliant files until 663, so why should they adapt the code for it? A simple check mark that allows relaxed restrictions would probably allow decoding for it...
Yeah right, why should Xvid support DivX 3.11 files? They are not standart compliant, so why bother? Just redo every encode and it doesn't matter, if you perhaps don't have the source anymore (DVB capture for instance).
A lot of ppl have a lot of files encoded with the older x264 builds. Sure Core doesn't need to deliver a working decoder for these files, but it would be pretty nice!
Did we hear an official word from them yet? Or do they think the thugs telling us there is no need for a proper decoder is enough?
*edit*
Not necessarily. I can only guess why CoreAVC depends on the exact mv length restriction, but some reasons could depend on optimizations that would be impossible to handle (even optionally) without costing speed. e.g. if they pack mvs into a 12bit data data structure, mvs > 12bits will be borked, and you can't exactly re-layout your data structures at runtime.
Thats my assumption too, but it would be great to have an official explanation.

Shinigami-Sama

12th November 2007, 23:49

Not necessarily. I can only guess why CoreAVC depends on the exact mv length restriction, but some reasons could depend on optimizations that would be impossible to handle (even optionally) without costing speed. e.g. if they pack mvs into a 12bit data data structure, mvs > 12bits will be borked, and you can't exactly re-layout your data structures at runtime.

they had it working before
so I know it can be done
thought they might have to wrap a whole chunk of code into a giant if/switch/terny to do it

lexor

13th November 2007, 04:47

Yeah right, why should Xvid support DivX 3.11 files?
Why should it? What do you even mean? Xvid is an encoder, divx3 has an encoder (albiet antiquated), and a standard compliant mpeg4asp decoder decodes both, thus making each a codec. The decoder that ships with Xvid doesn't specifically decode Xvid, it decodes an mpeg4asp compliant stream. Xvid itself is an encoder, and what does one encoder has to do with the other?

And yes, non-compliant streams should be left broken, since they are... broken (assuming they are broken and not some esoteric restriction of a specific implementation, like HD-DVD or Blu-ray).

All.... prior to CoreAVC v1.6.1 we have two goals. <...>
The second goal we are working on now is the 14 day Trial version which we hope to have out shortly.
You want to release an evaluation copy before you fix the bugs? ... right, solid logic.

akupenguin

13th November 2007, 05:20

Why should it? What do you even mean? Xvid is an encoder, divx3 has an encoder (albiet antiquated), and a standard compliant mpeg4asp decoder decodes both, thus making each a codec.
But divx3 isn't mpeg4asp. It's msmpeg4v3, i.e. Microsoft's implementation of a draft of mpeg4. Significant changes were made between the draft and the final version. I don't know about xvid, but libavcodec needs about 4000 lines of code dedicated to msmpeg4, in addition to some code it shares with standards compliant mpeg4 decoding.

bkman

13th November 2007, 09:24

Guys, I'm certain it was a recent revision of x264.

Here's the info:

User data: x264
User data: core 56 svn-680
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2005
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:-2:-1
User data: analyse=0x3:0x133
User data: me=umh
User data: subme=6
User data: brdo=1
User data: mixed_ref=1
User data: me_range=24
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=2
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=1
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: bframes=3
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40
User data: rc=2pass
User data: bitrate=1696
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: zones=137782,143079,q=40
SPS id: 0
Profile: High@L5.1
Num ref frames: 8
PPS id: 0
Entropy coding type: CABAC
Weighted prediction: No

I also used the Prestige CQM.

Someone should have a look at the sample to see if x264 is still producing MV's of illegal length.

Disabled

13th November 2007, 10:52

Why should it? What do you even mean? Xvid is an encoder, divx3 has an encoder (albiet antiquated), and a standard compliant mpeg4asp decoder decodes both, thus making each a codec. The decoder that ships with Xvid doesn't specifically decode Xvid, it decodes an mpeg4asp compliant stream. Xvid itself is an encoder, and what does one encoder has to do with the other?
I always thought Xvid was a coDec and mistakenly they are also stating this on their main page. But if it istn't please excuse me and take the obvious from my post: The decoder shipped with Xvid decodes ASP and non standart 3.11 for no real reason and there is not a single person that needs decoding of non standart spec files.

*note* In my opinion not many care about 3.11 support today, I should have written all this in the past tense.

lexor

13th November 2007, 16:01

I always thought Xvid was a coDec and mistakenly they are also stating this on their main page. But if it istn't please excuse me and take the obvious from my post: The decoder shipped with Xvid decodes ASP and non standart 3.11 for no real reason and there is not a single person that needs decoding of non standart spec files.

*note* In my opinion not many care about 3.11 support today, I should have written all this in the past tense.

ok, now according to aku's reply, 3.11 isn't even a mpeg4asp codec, which xvid is, so I now completely don't understand what one has to do with the other. It's like asking xvid to support wmv... it's meaningless.

Disabled

13th November 2007, 16:09

ok, now according to aku's reply, 3.11 isn't even a mpeg4asp codec, which xvid is, so I now completely don't understand what one has to do with the other. It's like asking xvid to support wmv... it's meaningless.
The thing is, the decoder bundled with Xvid does support 3.11 and for the same reasons why Core should support the non spec h264 files, cause there are a lot of them around and not everyone has the time and sources to redo the encodes. And ppl don't want to switch the decoder everytime. (And that problem didn't exist with 3.11, as they had a different fourcc)

clsid

13th November 2007, 18:35

Implementing a workaround for an encoder bug is a different thing than supporting a whole different format.

ChronoCross

13th November 2007, 19:20

Implementing a workaround for an encoder bug is a different thing than supporting a whole different format.

But the problem is if you make a workaround for 1 encoder bug you gotta do it for all of them.

With the wide variety of encoders out there the possibility for them at some point to be doing something slightly out of specs is higher.

This will increase the number of workarounds which may eventually start to weight the codec down.

pankov

13th November 2007, 19:52

guys,
for me it's all about percentages - I think x264 is one of the most popular encoders at the moment and it's been this way for a while. Since it had a bug in the past and there are so many encodes affected by it and this bug could be worked around in the decoder I think it should be done. I'm not saying to add workarounds for all the bugs in all the encoders in the world but only for the most commonly used. This way the user will not have negative feelings about Core's decoding ability, face it - most of the users don't even know what's an encoder and how it could be the cause for the ugly artifacts in "my favorite movie" and he will not have to look for other decoders that can solve the issue.
I think most of you will agree with me, so let's hope the Core team will too.

Inventive Software

13th November 2007, 20:02

The thing is, the decoder bundled with Xvid does support 3.11 and for the same reasons why Core should support the non spec h264 files, cause there are a lot of them around and not everyone has the time and sources to redo the encodes. And ppl don't want to switch the decoder everytime. (And that problem didn't exist with 3.11, as they had a different fourcc)

It supports 3.11 because it's originally based on that decoder, the project originally coming from OpenDivX.

Disabled

13th November 2007, 20:16

Implementing a workaround for an encoder bug is a different thing than supporting a whole different format.
Thats not actually an argument agains implementing the workaround is it?
But the problem is if you make a workaround for 1 encoder bug you gotta do it for all of them.

I'm with pankov there: Just implement workarounds when there are massive encodes nedding it. Do this on a case by case basis, if enough ppl want it and it's not that much work, do it.
And I hereby apologise for the Xvid comparison, please just forget it.
A question though: Did anyone official state, they are not gonna support the non-spec x264 files?

Scoty

13th November 2007, 23:05

i can download 1.6 but not the 1.6.1 ??

Disabled

13th November 2007, 23:23

i can download 1.6 but not the 1.6.1 ??
Might be because there is no 1.6.1 out yet? At least I didn't get a notice like the last times.
And this:
All.... prior to CoreAVC v1.6.1 we have two goals.

Shinigami-Sama

13th November 2007, 23:43

hey beta boy

any chance a lowly P4 3ghz, pc3200 1.5GB can handle 1080i in the next version or two?
if so you'll get my money sooner

Inventive Software

14th November 2007, 02:38

Bloody hell Shinigami-Sama, you're asking a lot aincha? :D

Shinigami-Sama

14th November 2007, 02:42

Bloody hell Shinigami-Sama, you're asking a lot aincha? :D

nah I was just wondering if I could put that old PC to good use as an HTPC
my laptop plays 720p with FFDshow pretty smoothly, and its about the same speed wise as the PC

ACrowley

14th November 2007, 13:48

Their problem is that they've created a spec-compliant decoder. x264 didn't create spec-compliant files until 663, so why should they adapt the code for it? A simple check mark that allows relaxed restrictions would probably allow decoding for it...

Yes.
Cyberlink/Nero/Sonic are spec Compliant too :)
And they have no Problem with large MV. So CoreAVC shouldnt have too..thats my simple Opinion

Also i cant see any Perfomance loss with Cyberlink Decoder on these x264 encodes with large MV

bob0r

14th November 2007, 14:31

Maybe following mv range specs strictly is the HOLY SECRET of CoreAVC's speed!! :script:

clsid

14th November 2007, 14:32

Being spec compliant means correctly supporting all features described in the specification. If CoreAVC would support large MV, then it would still be spec compliant.

The only arguments against implementing it would be performance. But given the fact that the performance of CoreAVC was already very good in the past when large MV were still supported, I don't think that argument holds much strength. In any case, support for large MV could be made optional and there could be two different code paths.

lucassp

14th November 2007, 14:58

Does anyone have any idea about how much does CoreAVC score in the HQV HD Benchmark?

14th November 2007, 16:00

Probably not very high since CoreAVC is a H.264 decoder, not a scaler, and the only filtering it can do are colorspace conversions and simple deinterlacing (which you'll probably want to avoid in favor of using hardware deinterlacing or better software filters).

hakujin

18th November 2007, 05:27

is coreavc becoming more processor intensive as it's revised? I'm wondering whether 1.6 release is good for a 3.0ghz northwood P4 box. Previous version played 720p x264 rips smooth as butter. But on the newer release, there's no explicit turn off deblocking or deinterlacing so wondering... Also any new bugs introduced (noticed motion vector problem) that would make 1.5 a better choice?

TIA

BetaBoy

18th November 2007, 07:16

You want to release an evaluation copy before you fix the bugs? ... right, solid logic.
I'm sorry... did we release a trial yet?

BetaBoy

18th November 2007, 07:31

I appreciate all the comments in this thread... even the off base ones... as bob0r hinted at.

We are working on 1.6.1.... on several different fronts... On the non-compliant streams... I'd like to make a comment more or less without being too specific.... Rather then create work around, after work around, after work around... we would rather tell/work/inform the ppl who created the encoders about the issue to have them resolve it.

This would make a situation even worse for the future when you start to add the SVC layer on top of that.

Also, this does not by any means, mean that by me stating the above that there are not things wrong with the decoder on our side... thats why we are here, for the community to tell us what's wrong and for us to make those changes to fix it.

Another Devel thing to note.... we are also working again on the CORE optimizations to increase speed. As I had indicated here a few times there is still more %'s to be had. We hope to include some of these enhancements in 1.6.1.

oddball

18th November 2007, 19:18

The fact that ffdshow (Beta) now supports dual core, is better quality, supports non-standard motion vectors and is *FREE* now makes CoreAVC obsolete for everything but low spec systems. Speed is the only thing CoreAVC seems to have over other decoders. Since I am on a decent specced system I am now using the new ffdshow build instead of CoreAVC even though I purchased CoreAVC (More fool me).

I find the total disregard for supporting non-standard motion vectors like EVERY other decoder out there even though it would make NO difference to the decoders fucntionality for standard encodes totally ludicrous. Betaboy I am sorry but your product is now a complete lemon to me.