CoreCodec/H.264 Codec "CoreAVC"

[madshi]

Some clarification for those from DVinfo....

TV = ITU-R BT.601
and
PC = ITU-R BT.709

This is now in our KB and will be added to the next update (within the help tab).
I believe this is flat out wrong. Both BT.601 and BT.709 are usually encoded to video levels.

[G_M_C]

I believe this is flat out wrong. Both BT.601 and BT.709 are usually encoded to video levels.

Aside from the fact that they can both be in either TV or PC levels. So 601 doesnt automatically mean TV levels.

[madshi]

Aside from the fact that they can both be in either TV or PC levels. So 601 doesnt automatically mean TV levels.
Yes, both can be either PC levels or video levels, but both are *usually* video levels.

So it's wrong to tie either of these norms to PC or TV levels.

[G_M_C]

Yes, both can be either PC levels or video levels, but both are *usually* video levels.

So it's wrong to tie either of these norms to PC or TV levels.

Yep that's wrong too. But i was referring to this post: http://forum.doom9.org/showthread.php?p=1257453#post1257453

Where Betaboy linked the TV or PC levels to one colormetry; When you encounter PC levels, it automatically would mean 709 where TV levels automatically means 601.

This is what he wrote;


Input Levels
- TV (16-235): (ITU-R BT.601) always assume the stream uses TV levels.
- PC (0-255): (ITU-R BT.709) always assume the stream uses PC levels.
- Auto detect: use the full range flag in the stream to determine Luminance range.
Note: The input levels setting allows the overriding of the stream's colorspace setting and affects the conversion to RGB color space when it is done by the decoder.


From where he deduced;


TV = ITU-R BT.601
and
PC = ITU-R BT.709


So both assumptions he made were wrong :p :cool:

[BetaBoy]

So based on everyone's input here.... We went back and started to test some of the diffs with 601 vs. 709... and found that it's different to the input levels. The filter 'does' always assume bt.601, even when the stream indicates otherwise. We are going to fix that, and add an option to override it.

[carlo_0000]

@ carlo
Sorry I wasn't clear enough, I asked for your numbers with the Athlon 64 @ 2.5GHz, not with the X2. That 1080p works on the X2 is pretty much established.
By the way, your links don't work.


ok

i see the server is down, so i put this one to an other

http://perso.latribu.com/tribu/mkv/journal.txt

http://perso.latribu.com/tribu/mkv/athlon64coreavc.JPG

[madshi]

So based on everyone's input here.... We went back and started to test some of the diffs with 601 vs. 709... and found that it's different to the input levels. The filter 'does' always assume bt.601, even when the stream indicates otherwise. We are going to fix that, and add an option to override it.
Thanks!

[DJ Bobo]

@ carlo
Thank you very much.
So it did hit the 100% mark a few times and dropped a lot of frames after all.
I knew there was something fishy :devil:

So, I would say, regular 1080p is definitely too much for a single core CPU (unless someone has one of those newer LE-1660 models and can share his results with us)

So BetaBoy, I would say the preliminary results for CoreAVC's recommended hardware requirements to play usual H.264 content would be:
Athlon XP 3200+ or P4 @3.2GHz for 720p
Athlon X2 3800+ or Pentium D @3.2GHz for 1080p
I'll leave the verification and further testing up to you, I guess I've done a great deal already :D

[leeperry]

The filter 'does' always assume bt.601, even when the stream indicates otherwise.
are you sure the stream has a colorimetry flag :confused:
apparently some Samsung projectors(such as the SP-A800B) can auto-detect whether it's 601/709....but is it in the container or sumthing?

while you're fixing RGB conversion problems, maybe you could also implement progressively upsampled chroma.
I believe some ppl complained that your were doing it interlaced(like the ATi drivers).
here's a test pattern :
http://forum.doom9.org/showpost.php?p=1137196&postcount=1868

[HowlerX]

So BetaBoy, I would say the preliminary results for CoreAVC's recommended hardware requirements to play usual H.264 content would be:
Athlon XP 3200+ or P4 @3.2GHz for 720p
Athlon X2 3800+ or Pentium D @3.2GHz for 1080p
I'll leave the verification and further testing up to you, I guess I've done a great deal already :D

The only reason I bought CoreAVC was so I could play 720p content on my P4 2.53GHz. I've been happily using CoreAVC for over 2 years now. This has been one of those best-bang-for-my-buck pieces of software.

CPU usage varies from 40-90% depending on complexity of video.

Now that Flash video sites are starting to feature more and more 720p H.264 content you would think they would improve the efficiency of their decoder. I've tried playing the 720p content on Hulu.com and even on a 2.4GHz Core2Duo the thing plays choppily. It's ridiculous. Maybe they should license the CoreAVC decoder. :rolleyes:

[DJ Bobo]

@ HowlerX
I invite you to test the 720p Apple trailer (http://www.apple.com/quicktime/guide/hd/bbc-nhk.html) I posted earlier (Use QT Lite to be able to download it and play it in any player you want so that CoreAVC can be used).
I don't think your P4 will cope with it, at least not at the end where a lot of people come together, since as said, not even a 3GHz P4 was able to play it flawlessly.
You could post the same results I asked carlo for if you want.

[HowlerX]

@ HowlerX
I invite you to test the 720p Apple trailer (http://www.apple.com/quicktime/guide/hd/bbc-nhk.html) I posted earlier (Use QT Lite to be able to download it and play it in any player you want so that CoreAVC can be used).
I don't think your P4 will cope with it, at least not at the end where a lot of people come together, since as said, not even a 3GHz P4 was able to play it flawlessly.
You could post the same results I asked carlo for if you want.

Played flawlessly. I used MPC configured to use CoreAVC 1.8.5 and Haali Renderer (my preferred renderer). Even the DivX H.264 decoder plays this trailer flawlessly. Again using Haali Renderer (or even regular plain Overlay.)

Now if I change the renderer to VMR7 or VMR9, I definitely see skipped frames all over the place. But I haven't used those renderers in over 3 years, so why bother. My video card is an NVidia 6600GT on an obselete AGP bus.

Also, should note that I don't plan on upgrading to the latest CoreAVC decoder 'cause ver. 1.8.5 hasn't given me problems and I don't have a CUDA-enabled vidcard.

[Shinigami-Sama]

I played back that trailer fine a 3ghz P4 using MPC-HC rev 854 internal decoder...
I guess I should update mpc to see how much faster it is now with updated ffmpegs...

[G_M_C]

So based on everyone's input here.... We went back and started to test some of the diffs with 601 vs. 709... and found that it's different to the input levels. The filter 'does' always assume bt.601, even when the stream indicates otherwise. We are going to fix that, and add an option to override it.

You can make your live easier by using 709 for High definition. Rec709 is the (mandatory ?) standard for HD, so everything >= 720p is always Rec709. And then make TV levels the default for that, and PC levels optional (like the "BtB / WtW" switches on the Blu-ray players)

I would not know how to automate it so that a programm can scan the stream and deduce for itself what is applicable 601 or 709, TV-levels / PC-levels. There are differences between all thhose options, but a programm that "sees" what is apllicable, like a human can do by watching the clip closely and comparing between the options, does not yet exist ...

[madshi]

You can make your live easier by using 709 for High definition. Rec709 is the (mandatory ?) standard for HD, so everything >= 720p is always Rec709. And then make TV levels the default for that, and PC levels optional (like the "BtB / WtW" switches on the Blu-ray players)
Actually the h264 bitstream itself contains information about whether BT.709 or BT.601 is used, IIRC. So there's no need at all to tie the color norm to the resolution. It's true that 709 is usually used for HD content, but that doesn't mean that some reencoding couldn't be using BT.601 for HD content instead. So it's better to do what BetaBoy suggested, namely making use of the h264 color norm information fields. I don't even know if it's necessary to offer a switch to overwrite that, but it won't harm (except making the user interface more complicated).

About TV/PC levels: There's a "full range" flag in the h264 stream which indicates to which levels the stream was encoded. Unfortunately, this flag is set wrong for many European HDTV broadcasts. So it is necessary to offer an overwrite for this.

[DJ Bobo]

@ Howler / Shinigami
Numbers or graphs, and screenshots to check for dropped frames please.
PS: I don't know why but Haali doesn't seem to report dropped frames to MPC even if frames are dropped...

[hellrasinbrasom]

The program I used with my 2nd set of encodes was XVID4PSP
+ DVD Decryptor/Shrink

PLATFORM
------------------------------
OS: Microsoft Windows NT 6.0.6000.0
OEMCodePage: 437
Language: ENU
DecimalSeparator: .
Framework: 2.0.50727.312
Processors: 2
Machine: THEPC
UserName: Big Boss
SystemDrive: C:

XVID4PSP
------------------------------
Version: 5.036
Created: 10/18/2008 11:36:32 AM
TempPath: C:\Temp
AppPath: C:\Program Files\Winnydows\XviD4PSP5

FILES
------------------------------
VTS_01_1.VOB >
VTS_01_2.VOB >
VTS_01_3.VOB >
VTS_01_4.VOB >
VTS_01_5.VOB >
Documents_T01.mp4

TASK
------------------------------
Format: MP4
Duration: 02:18:17:598 (248679)
VideoDecoder: MPEG2Source
Resolution: 720x480 > 1280x720
VCodecPreset: x264 Q21 Ultra
VEncodingMode: Quality
VideoCodec: MPEG2 > x264
VideoBitrate: 3446 > Q21.0
Framerate: 29.970
SourceType: INTERLACED
FieldOrder: UNKNOWN
Deinterlacer: TomsMoComp
AudioDecoder: NicAC3Source
AEncodingPreset: AAC-LC ABR 128k
AudioCodec: AC3 > AAC
AudioBitrate: 448 > 128
Samplerate: 48000
Channels: 6
Normalize: 100%
Accurate: 3%
Gain: 1.846
Delay: 83 > 83

VIDEO ENCODING
------------------------------
Encoding video to: C:\Temp\0003.264
x264 Q21.0 1280x720 29.970fps (248679 frames)
x264 [info]: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=6 psy_rd=1.0:0.0 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-2 threads=2 thread_queue=2 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=1 b_adapt=1 b_bias=0 direct=1 wpredb=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=crf crf=21.0000 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00

AUDIO ENCODING
------------------------------
Encoding audio to: C:\Temp\0003.m4a
AAC 128kbps 6ch 16bit 48000khz

MUXING
------------------------------
Video file: C:\Temp\0003.264
Audio file: C:\Temp\0003.m4a
Muxing to: C:\Users\Big Boss\Documents\Documents_T01.mp4

TIME
------------------------------
Total encoding time: 23 hour 1 min 36 sec
Out file size is: 4985.91 mb

:helpful:

[carlo_0000]

@ carlo
Thank you very much.
So it did hit the 100% mark a few times and dropped a lot of frames after all.
I knew there was something fishy :devil:

So, I would say, regular 1080p is definitely too much for a single core CPU (unless someone has one of those newer LE-1660 models and can share his results with us)

So BetaBoy, I would say the preliminary results for CoreAVC's recommended hardware requirements to play usual H.264 content would be:
Athlon XP 3200+ or P4 @3.2GHz for 720p
Athlon X2 3800+ or Pentium D @3.2GHz for 1080p
I'll leave the verification and further testing up to you, I guess I've done a great deal already :D


i m not agree with you for the 720p recommended requirements
you a litle high athlon 2700+ must play it very good (because cpu frenquecy is close to the 3200+)

the 2400+ is to slow (drop frames in some scene)

i had a 3100+ barton soket A (2.2ghz) it played 720p easy but i can't test it anymore (cpu is dead), it was not able to play 1080p (slower than the athlon 64 2800+)


i olso deagree for the 1080p because there are single core with higer frequency like athlon 64 6000+ 6400+ ? i m sure that thay can play 1080p, no nesesary needed a dual core

[DJ Bobo]

@carlo
i m not agree with you for the 720p recommended requirements
you a litle high athlon 2700+ must play it very good (because cpu frenquecy is close to the 3200+)
Good point. Athlon XP @ 2.2GHz would be better then I guess.
i olso deagree for the 1080p because there are single core with higer frequency like athlon 64 6000+ 6400+ ?
There is no such thing as Athlon 64 6000+. You're probably confusing this with Athlon 64 X2 6000+, which is a dual core CPU.
Anyway, I already said
unless someone has one of those newer LE-1660 models and can share his results with us
The Athlon 64 LE-1660 is a 2.8GHz single core unit.

[carlo_0000]

i did some test today

with sempron 2200 (1.5ghz) soket A

i m surpised because i olso tested a barton mobile 2400+ (1.8ghz) on the same computer and

the sempron plays 2% beter the 720p video's than the barton

i can't understand that (sempron is like a duron no ? it must be slower than a barton)

i olso oc the barton to max 2130mhz but did only 4% beter
and the duron to 1650mhz and did litle beter than the barton 2.1ghz

i found that the barton 2400 is pretty bad

is to slow for 720p 50fps (but x264 rip in 720p 25fps is playable (3-5mbits videobitrate)

[DJ Bobo]

@ carlo
It may have something to do with the chipset and memory performance.

[Ryokurin]

Sometimes a faster frontside bus can win out over cache when it came to Athlon processors.

[lucassp]

i can't understand that (sempron is like a duron no ? it must be slower than a barton)

The Socket A Sempron is based on the TBred B or Thornton (half cache Barton) cores.

[Ice =A=]

I just wanted to mention thath I've been using CoreAVC for quite some time now to watch 720p content on an Atom N270 1,6GHz Netbook!
Of course I can't guarantee that it will work with any material (and most likely it won't), but so far I've NEVER had any problems!

[clsid]

I have an 8 year old 1.33 Ghz processor that can play 720p content. That is nothing special. 1080p is about twice as hard to decode. Also, the encoding settings can have a big impact on decoding performance.

[Sagekilla]

Some encoding settings can have an impact on decoding performance. In fact, only two: Deblock and CABAC. Nothing else makes a significant difference.

[BetaBoy]

Just got the new MacBook Pro here... gonna setup a dual boot tonight and see how well CoreAVC w/CUDA works.

[Betsy25]

Just got the new MacBook Pro here... gonna setup a dual boot tonight and see how well CoreAVC w/CUDA works.

Have fun ! :)

[DJ Bobo]

@ Ice/clsid
Your PCs won't be able to play "normal" 720p videos, not the Apple trailer I posted above, and not the 720p trailers available in the DivX showcase (http://www.divx.com/en/downloads/divx-7-showcase)

@ BetaBoy
Hopefully you didn't receive one of those defective units. It seems like the new MacBook Pro have a lot of problems with the graphics (http://www.computerbase.de/bildstrecke/24736/2/).

[clsid]

Well, you are wrong. My old PC plays them fine. Sure, it will hit 100% CPU with certain files like your BBC sample, but the video is watchable without any annoying stuttering.

[Kurtnoise]

back on topic...I'm wondering if CoreAVC w/ CUDA enabled is able to decode MBAFF contents properly ? Does anybody succeeded ?

I ask this because it seems that CUDA is disabled with such files (tray icon is blue instead of green for me). Any clue ?

I'm using the last release...

[DJ Bobo]

@ clsid
Please provide us with a link to a 720p trailer that would work on your old PC without torturing your CPU. May be you're using the Haali Renderer too and are not aware of it slowing down your video?

[clsid]

The Overlay Mixer is most CPU efficient, so that is what I use.
TerminatorSalvationTrailer[DivX7].mkv plays fine with an average CPU usage of about 85-90%.

[ChronoCross]

back on topic...I'm wondering if CoreAVC w/ CUDA enabled is able to decode MBAFF contents properly ? Does anybody succeeded ?

I ask this because it seems that CUDA is disabled with such files (tray icon is blue instead of green for me). Any clue ?

I'm using the last release...

If I remember correctly interlacing support for CoreAVC CUDA is not currently available.

[BetaBoy]

If I remember correctly interlacing support for CoreAVC CUDA is not currently available.

Correct, We are doing regression testing on CUDA interlaced support atm and we are only down to a handful of files that need to be supported, so we are closer for an internal QA release for a potential 1.9.x.

[DJ Bobo]

@ clsid
I couldn't download the Terminator trailer since download speed was too slow, but I did a test on the Star Trek trailer I downloaded before, while giving MPC only one core, logging from 00:10 to 01:45 average was ~56% and max was ~82% on that core with the overlay mixer. I don't see your 1.33GHz CPU not hitting 100% if mine came over 80%, and I'm ready to bet that it hit 100% too often and lost a lot of frames in the way (even though MPC shows 0, since Overlay Mixer doesn't report anything to MPC)
Please post a graph or numbers showing CPU usage.

[clsid]

It hits 100% just a few times. Point is that the video is watchable without loss of audio sync or stuttering. I don't care about a few skipped frames. The BBC sample is more difficult to decode though.

[DJ Bobo]

It hits 100% just a few times. Point is that the video is watchable without loss of audio sync or stuttering. I don't care about a few skipped frames
I don't believe this is coming from your mouth. You're sure you're THE clsid???
Anyway, 1.33GHz CPUs do NOT play 720p "just fine" as you say, since, obviously, 100% automatically means stuttering and loss of audio sync.
CoreAVC is fast, but it doesn't do miracles.
Case closed.

[Cyber-Mav]

anyone got a sample video of the most difficult content to decode? would love to use it for cpu testing purposes.

[littleD]

You guys simply overestimate needs for decoding 702p material. With deblocking off terminator trailer is playable even by divx decoder with just small two audio desynchronizations. Coreavc is slightly better on old one core machines. So i believe clsid. I changed fsb by speedfan to reach 1.33gh. Only if coreavc team could add sse optimizations...:sly:

[DJ Bobo]

With deblocking off
OK, let's set something straight. The recommended requirements that I posted are with Deblocking ON. Because the requirements posted on the website already imply that deblocking is off! And as you may know, a P4@2.2GHz is roughly equivalent to a Pentium-M@1.5GHz.
So please stop this non-sense. You want to prove me wrong with CPUs that hit 100% with deblocking off? come on guys.
OK, here's the deal: please no further contributions unless you comply with the following:
1) Deblocking in set on "Standard"
2) CPU usage doesn't exceed 95% and you can document that with a graph or numbers
3) No skipped frames (screenshot with statistics if possible).

[clsid]

We seem to be talking about different things here. I totally agree that the minimum requirement for completely smooth playback is higher as what my old PC has. I also agree that P4's are crap. I was just saying that in some cases playback quality/performance is acceptable on an 8 year old PC (with a high-end CPU at that time). Normally I will simply fire up the Core2 for playing such material.

And on a blind test, I'll bet that 9/10 people won't see the difference between for example 22 and 24 fps.

[littleD]

Allright Dj Bobo. Can u point the "real" 720p video (sample) then, and forget that crappy trailers:) Lets use it as reference and stop that nonsense :)

[Inventive Software]

If it's any help, with the "old" CoreAVC in TCPMP, I can play SD (720x576) content on my Celeron 800 MHz. :)

[hajj_3]

u long away from giving us a new version betaboy?

[DJ Bobo]

@ littleD
The Apple trailer I posted above is just fine for testing 720p.

[_DW_]

@ littleD
The Apple trailer I posted above is just fine for testing 720p.

Will this thing play without quicktime? I refuse to put that abomination on my PC.

[Sagekilla]

BetaBoy, I have a question regarding the latest CoreAVC Pro build (1.9.0).

I'm running CoreAVC on my desktop with hardware acceleration disabled, and I'm using the decoder through DirectShowSource in avisynth to decode my Blu-rays. It seems like when I run x264 with the --psy-rd switch, I get a crash in x264 if getting my video through an avs. A GDB trace leads to a segfault in CoreAVCDecoder.ax. Also, if I decode the video to y4m first, then feed to x264 the crashes stop.

Any thoughts on why CoreAVC would crash when I put --psy-rd on my command line for x264, but run perfectly fine without it? For whatever reason, my identical laptop setup can encode fine.

(Note to mods: I'm not sure if I'm violating the rules by posting this here. If I am, let me know and I'll take down my post immediately)

[squid_80]

Are you sure the name of the module that's crashing is CoreAVC.ax?

[Sagekilla]

Sorry, I meant to say CoreAVCDecoder.ax. Here's the link to the GDB traces:
http://forum.doom9.org/showpost.php?p=1260502&postcount=16
http://forum.doom9.org/showpost.php?p=1260504&postcount=18