Announcing Project Rémoulade [DivX H.264 codec] - Page 14

soresu · 24th July 2008, 16:04

If I am to understand DivX business practise, then the encoder and decoder are not so much targeted at us enthusiasts but at the regular consumers to dont know ffdshow from squat, and would recognise and trust the DivX brand for using with their work.
This would play in with deals for DivX playback on XBOX 360 and Playstation 3, not to mention future STB standalone joint ventures.
Of course, that's not to say it wont still be interesting to compare them to the open source competitors!

IgorC · 25th July 2008, 22:29

Quote:

Originally Posted by Shinigami-Sama

its not like ffmpeg is threaded yet...

Threading isn't everything. For example ffdshow ASP decoder is faster on single core than Divx's. Threding doesn't matter here.
While for multiple cores Divx's ASP decoder is very optimized. But it doesn't matter that much. Where is practical approach if ASP 1080p is easy decodable on enough fast 1 core?

Shinigami-Sama · 25th July 2008, 22:30

Quote:

Originally Posted by IgorC

Threading isn't everything. For example ffdshow ASP decoder is faster on single core than Divx's. Threding doesn't matter here.
While for multiple cores Divx's ASP decoder is very optimized. But it doesn't matter that much. Where is practical approach if ASP 1080p is easy decodable on 1 core?

to bad we're not talking about ASP here
we're talking about AVC
where threading matters a bit more

IgorC · 25th July 2008, 22:40

The point is Divx AVC decoder has higher timecodec fps numbers because it can load cores at 100% while ffdshow can't. But during the real playback there is no need for 100% load always. That's why Divx isn't that faster for real playback than ffdshow if you check real cpu load.

Shinigami-Sama · 25th July 2008, 22:46

FFdshow can't keep up on my P4 at 720p, divx decoder can
and if ffmpeg can speed up their decoder it will make divx pretty moot, especially with core already established as the fastest for a while now

IgorC · 25th July 2008, 22:51

Why do you disagree with thing I haven't told?
I said: Threading isn't everything.
I don't said: Threading is useless.

Some kind of not understading simple logic operators AND, OR, IF....

Schrade · 26th July 2008, 01:43

Quote:

Originally Posted by IgorC

For example ffdshow ASP decoder is faster on single core than Divx's.

You might want to try testing that again with a lower end CPU and a 720p XviD encoded video. DivX easily beats XviD and ffdshow with lower end CPUs.

Sophocles · 27th July 2008, 05:27

Quote:

If I am to understand DivX business practise, then the encoder and decoder are not so much targeted at us enthusiasts but at the regular consumers to dont know ffdshow

Sometimes an enthusiast has to drop a buck or two to get the most enthusiastic product. I paid $19.95 years ago for DiVx and then upgraded a few years later with an even smaller sum. That might seem a lot to those who rely on free products most of the time. Yet I've given perhaps three times that much to donations towards Imgburn.

Quote:

Threading isn't everything. For example ffdshow ASP decoder is faster on single core than Divx's.

My experience doesn't support that although it is limited to just two single core processors. The 2.8 GHz P4 Northwood clocked to 3.1 GHz and the Athlon XP 2500 Plus. Any way I tried to toss this salad the fastest decodes have been consistently coreavc, Main concept, and DivX. On really high resolution videos above (1920 X 1080) coreavc wouldn't load but DiVx and Main concept ran the course like a champs.

Quote:

so they've got some basic threading now

divx you better hurry up or you'll be totally obsolete before you even release

It would be nice if there was a beta 3 decoder release, and a beta anything for H.264 DiVx encoder.

Dark Shikari · 27th July 2008, 05:33

Quote:

Originally Posted by Sophocles

My experience doesn't support that although it is limited to just two single core processors. The 2.8 GHz P4 Northwood clocked to 3.1 GHz and the Athlon XP 2500 Plus. Any way I tried to toss this salad the fastest decodes have been consistently coreavc, Main concept, and DivX. On really high resolution videos above (1920 X 1080) coreavc wouldn't load but DiVx and Main concept ran the course like a champs.

Note: he said ASP decoder, which CoreAVC isn't.

Shinigami-Sama · 27th July 2008, 05:36

Quote:

Originally Posted by Dark Shikari

Note: he said ASP decoder, which CoreAVC isn't.

which is why he got ignored

Sophocles · 27th July 2008, 16:11

Quote:

Note: he said ASP decoder, which CoreAVC isn't.

Sorry I should have read the post a little closer.

Quote:

which is why he got ignored

Unfortunately not entirely ignored.

pitch.fr · 29th July 2008, 00:21

very impressive decoder!

the beta2 is so tight jitter-wise in MPC HC compared to ffdshow, and not blocky like CoreAVC(I use LSF in ffdshow and I don't like how CoreAVC looks).

MPC HC(in custom EVR mode) doesn't like how ffdshow doesn't make a smooth decoding(dirty MT) it creates too much jitter, this one is simply perfect.

except that all my 23.976/24 fps files(quicktime HD trailers, MKV, ts) are recognized as 25.000 fps in Reclock with the latest version of Haali's Media Splitter

and w/o ffdshow(doing LSF and RGB32 conversion), MPC says "0 FPS", so it seems that there's some major hiccup in providing the other DS filters with the frame rate info..

these 23.976/24 fps files are properly recognized with CoreAVC/ffdshow.......it was too good to be true I guess

OTOH 25/29.97fps are properly recognized with Remoulade beta 2, on XP SP3

EDIT : ran more tests.

Remoulade alone, MPC sees 23.976fps
Remoulade + ffdshow post-processing, still 23.976
Remoulade + Reclock 1.7b4, it says "cannot detect video frame rate"
Remoulade + ffdshow + Reclock, it says "25 fps"

it works perfectly fine with CoreAVC and the ffdshow h264 decoder..

PS : same problem occurs to several friends of mine also using Reclock, but for them sometimes it works for 23.976, sometimes it doesn't ?!

Dark Shikari · 7th August 2008, 03:16

Apparently DivX doesn't work with the "new" lossless either (High 4:4:4 Predictive profile, profile_idc 244). I implemented this in x264 and confirmed that it works through JM. Neither CoreAVC nor libavcodec support this mode currently (or Elecard or Mainconcept), and while DivX stated earlier that they intended to, Beta 2 doesn't work at all (it shows a black screen of the wrong resolution... maybe you forgot to include proper handling of profile_idc 244?).

For testing purposes, a clip can be found here. This video is the canonical "soccer.yuv" CIF video, and should decode as such. Note that I am not entirely sure that JM implements this correctly--while this video decodes correctly with JM 13.1, the standard says the prediction should be done on chroma and luma, while JM seems to only implement it on luma. I don't have any non-JM decoder to test this on though... if DivX knows of one that can be considered "reliable," I'd love to know what it is.

BetaBoy · 7th August 2008, 11:05

Dark Shikari... thx for the sample. Support for this will be added in the next CoreAVC release.

Dark Shikari · 7th August 2008, 14:56

Quote:

Originally Posted by BetaBoy

Dark Shikari... thx for the sample. Support for this will be added in the next CoreAVC release.

I would suggest you be careful and stick to the standard more than you stick to JM; the only thing worse than nobody supporting a profile is if everyone supports it slightly differently

BetaBoy · 7th August 2008, 14:59

We both know more about that for sure ;-)

Dark Shikari · 7th August 2008, 17:45

Updated info for implementing this (courtesy of jvt-experts ML): the chroma prediction (not used in the above sample clip) is required by the standard, but JM 14.1, which displays a grayscale image as output, doesn't work because it only supports 4:4:4 lossless, not 4:2:0 lossless.

I have been unable to get i16x16 H and V blocks to decode correctly with the JM.

Edit: it seems the JM forgot to implement i16x16 pixel prediction completely! So I was right to begin with, and the JM was wrong.

Here is a sample that appears to be correct, according to the standard, and should be able to serve as a reference for making this work in DivX and CoreAVC. It uses both i16x16 and i4x4 blocks, and implements pixel prediction for both types. It doesn't have i8x8, but if you can do i4x4, i8x8 should be equally trivial.

BlackSharkfr · 8th August 2008, 19:40

All this 4:4:4 stuff interests me a lot since i'm about to start making some stereoscopic 3D videos, and anaglyph videos would really benefit a lot from 4:4:4.

Dark Shikari,
does your patch make x264 fully support 4:4:4 or is it only for lossless mode ?

Dark Shikari · 8th August 2008, 20:08

Quote:

Originally Posted by BlackSharkfr

All this 4:4:4 stuff interests me a lot since i'm about to start making some stereoscopic 3D videos, and anaglyph videos would really benefit a lot from 4:4:4.

Dark Shikari,
does your patch make x264 fully support 4:4:4 or is it only for lossless mode ?

No, 4:2:0 is still the only colorspace supported; High 4:4:4 Predictive is just the profile that allows predictive lossless coding (it supports 4:4:4 or lower).

Blue_MiSfit · 8th August 2008, 21:16

i.c. - so x264 still only accepts 4:2:0 input, even though the lossless profile allows anything up to 4:4:4. We aren't there yet

It will be a fine day indeed with x264 and AviSynth can do high bit depth 4:2:2 and 4:4:4!

~MISfit

25th July 2008, 22:51	#266 \| Link
IgorC Registered User Join Date: Apr 2004 Posts: 1,315	Why do you disagree with thing I haven't told? I said: Threading isn't everything. I don't said: Threading is useless. Some kind of not understading simple logic operators AND, OR, IF.... Last edited by IgorC; 25th July 2008 at 22:53.

29th July 2008, 00:21	#272 \| Link
pitch.fr Didée 4 President Join Date: Jun 2008 Posts: 239	very impressive decoder! the beta2 is so tight jitter-wise in MPC HC compared to ffdshow, and not blocky like CoreAVC(I use LSF in ffdshow and I don't like how CoreAVC looks). MPC HC(in custom EVR mode) doesn't like how ffdshow doesn't make a smooth decoding(dirty MT) it creates too much jitter, this one is simply perfect. except that all my 23.976/24 fps files(quicktime HD trailers, MKV, ts) are recognized as 25.000 fps in Reclock with the latest version of Haali's Media Splitter and w/o ffdshow(doing LSF and RGB32 conversion), MPC says "0 FPS", so it seems that there's some major hiccup in providing the other DS filters with the frame rate info.. these 23.976/24 fps files are properly recognized with CoreAVC/ffdshow.......it was too good to be true I guess OTOH 25/29.97fps are properly recognized with Remoulade beta 2, on XP SP3 EDIT : ran more tests. Remoulade alone, MPC sees 23.976fps Remoulade + ffdshow post-processing, still 23.976 Remoulade + Reclock 1.7b4, it says "cannot detect video frame rate" Remoulade + ffdshow + Reclock, it says "25 fps" it works perfectly fine with CoreAVC and the ffdshow h264 decoder.. PS : same problem occurs to several friends of mine also using Reclock, but for them sometimes it works for 23.976, sometimes it doesn't ?! Last edited by pitch.fr; 8th August 2008 at 21:08.

7th August 2008, 03:16	#273 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	Apparently DivX doesn't work with the "new" lossless either (High 4:4:4 Predictive profile, profile_idc 244). I implemented this in x264 and confirmed that it works through JM. Neither CoreAVC nor libavcodec support this mode currently (or Elecard or Mainconcept), and while DivX stated earlier that they intended to, Beta 2 doesn't work at all (it shows a black screen of the wrong resolution... maybe you forgot to include proper handling of profile_idc 244?). For testing purposes, a clip can be found here. This video is the canonical "soccer.yuv" CIF video, and should decode as such. Note that I am not entirely sure that JM implements this correctly--while this video decodes correctly with JM 13.1, the standard says the prediction should be done on chroma and luma, while JM seems to only implement it on luma. I don't have any non-JM decoder to test this on though... if DivX knows of one that can be considered "reliable," I'd love to know what it is. __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10

7th August 2008, 11:05	#274 \| Link
BetaBoy CoreCodec Founder Join Date: Oct 2001 Location: San Francisco Posts: 1,421	Dark Shikari... thx for the sample. Support for this will be added in the next CoreAVC release. __________________ Dan "BetaBoy" Marlin Ubiquitous Multimedia Technologies and Developer Tools http://corecodec.com

7th August 2008, 14:59	#276 \| Link
BetaBoy CoreCodec Founder Join Date: Oct 2001 Location: San Francisco Posts: 1,421	We both know more about that for sure ;-) __________________ Dan "BetaBoy" Marlin Ubiquitous Multimedia Technologies and Developer Tools http://corecodec.com

24th July 2008, 16:04	#261 \| Link
soresu Registered User Join Date: May 2005 Location: Swansea, Wales, UK Posts: 196	If I am to understand DivX business practise, then the encoder and decoder are not so much targeted at us enthusiasts but at the regular consumers to dont know ffdshow from squat, and would recognise and trust the DivX brand for using with their work. This would play in with deals for DivX playback on XBOX 360 and Playstation 3, not to mention future STB standalone joint ventures. Of course, that's not to say it wont still be interesting to compare them to the open source competitors!

25th July 2008, 22:40	#264 \| Link
IgorC Registered User Join Date: Apr 2004 Posts: 1,315	The point is Divx AVC decoder has higher timecodec fps numbers because it can load cores at 100% while ffdshow can't. But during the real playback there is no need for 100% load always. That's why Divx isn't that faster for real playback than ffdshow if you check real cpu load.

7th August 2008, 17:45	#277 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	Updated info for implementing this (courtesy of jvt-experts ML): the chroma prediction (not used in the above sample clip) is required by the standard, but JM 14.1, which displays a grayscale image as output, doesn't work because it only supports 4:4:4 lossless, not 4:2:0 lossless. I have been unable to get i16x16 H and V blocks to decode correctly with the JM. Edit: it seems the JM forgot to implement i16x16 pixel prediction completely! So I was right to begin with, and the JM was wrong. Here is a sample that appears to be correct, according to the standard, and should be able to serve as a reference for making this work in DivX and CoreAVC. It uses both i16x16 and i4x4 blocks, and implements pixel prediction for both types. It doesn't have i8x8, but if you can do i4x4, i8x8 should be equally trivial. __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10 Last edited by Dark Shikari; 7th August 2008 at 18:26.

8th August 2008, 19:40	#278 \| Link
BlackSharkfr Registered User Join Date: Dec 2005 Posts: 133	All this 4:4:4 stuff interests me a lot since i'm about to start making some stereoscopic 3D videos, and anaglyph videos would really benefit a lot from 4:4:4. Dark Shikari, does your patch make x264 fully support 4:4:4 or is it only for lossless mode ?

8th August 2008, 21:16	#280 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 5,989	i.c. - so x264 still only accepts 4:2:0 input, even though the lossless profile allows anything up to 4:4:4. We aren't there yet It will be a fine day indeed with x264 and AviSynth can do high bit depth 4:2:2 and 4:4:4! ~MISfit __________________ These are all my personal statements, not those of my employer :)