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

[check]

compiled for specific x86 Linux distrosIn a related compatibility question, does this imply there won't be 64-bit builds?

[mdoubledragon]

We can't release the source, so it would have to be binary-only, compiled for specific x86 Linux distros. Our internal API is not compatible with existing apps.

What I had in mind was a Divx Player for Linux that comes with the decoder. It doesn't have to be open-source. Just something like RealPlayer for Linux (not HelixPlayer which is open source). That Divx Player could do audio built-in as well or look for libmp3 and libfaad during installation.

[the_corona]

Uhmm, soooooo........yeah..............what's going on?

Dare we ask for any status update?

[CruNcher]

@the_corona
you can't stomp out a H.264 based Encoder out of air in some months and also if the development is going on since say maybe a Year from here the quality wont be as far as X264 currently is wich has alot of research and improvements based on that behind it (in all directions includeing alot of psychovisual improvement very important for H.264) even if the base is Mainconcepts Encoder it wont be so advanced then X264 tough, and for sure it won't beat Atemes Encoder :)
So don't expect a wonder here, tough i expect it will be pretty good when it comes to HRD conformance and compliancy, and ofcourse not to forget DivX perfect usability work :)

[the_corona]

I'm not talking about the encoder.....don't know where you get that impression.

[CruNcher]

DivX isnt going to release the Decoder without it's going to Decode streams out of their Encoder it makes no sense to release the Decoder standalone DivX is not like CoreCodec they also won't sell it alone :D
Just look on DivX Labs for new Beta anouncements for the Decoder and im sure they gonna post info here about new Betas when they think the time is right, if you want daily status updates you could email them directly, but don't expect to get an answer, the same here just wait for the candy to arrive before eating it ;).

[Shinigami-Sama]

candy
'you get the candy after you get in the van'

also if they're really not going to release a standalone decoder then they're just going to let core soak up all that market rather than milking it themselves!

its not like ffmpeg is threaded yet...

[Dark Shikari]

its not like ffmpeg is threaded yet...O RLY (http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt/commits/092dd406b19fe33f1601c80bd428575e360ad5c6)? :devil:

[Shinigami-Sama]

O RLY (http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt/commits/092dd406b19fe33f1601c80bd428575e360ad5c6)? :devil:

so they've got some basic threading now

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

[the_corona]

DivX isnt going to release the Decoder without it's going to Decode streams out of their Encoder it makes no sense to release the Decoder standalone DivX is not like CoreCodec they also won't sell it alone :D
Just look on DivX Labs for new Beta anouncements for the Decoder and im sure they gonna post info here about new Betas when they think the time is right, if you want daily status updates you could email them directly, but don't expect to get an answer, the same here just wait for the candy to arrive before eating it ;).

Why this hostility Cruncher?

I am strongly under the impression that their decoder will be a standalone product (or I wouldn't have any interest at all.....the little encoding I do is perfectly covered with x264). I doubt I am alone.

So you're "answer" is don't ask any questions, wait for when they feed you. I'm sorry I thought I would show my interest by posting in a forum thread about a beta-product they started.

[soresu]

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]

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]

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]

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]

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]

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]

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]

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.


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.


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.:D

[Dark Shikari]

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]

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

which is why he got ignored ;)

[Sophocles]

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

Sorry I should have read the post a little closer.

which is why he got ignored

Unfortunately not entirely ignored.:D

[pitch.fr]

very impressive decoder! :eek:

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]

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 (http://www.mediafire.com/?ljycfqzkivc). 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]

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

[Dark Shikari]

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 :scared:

[BetaBoy]

We both know more about that for sure ;-)

[Dark Shikari]

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 (http://www.mediafire.com/?hk33eyvxc22) 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]

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]

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]

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

[Ajax_Undone]

My question is a simple one! I was wondering if the next version of the Divx codec will have both x64 and x86bit architecture...

[delacroixp]

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 .
I'm also a major enthusiast of stereoscopic 3D .

Do you use shutter-glasses or some kind of 'strap-on display' ?
A ferw links would be usefull !


It's all good.

:):devil::D
Pascal

[delacroixp]

A while ago I needed to do a test comparing, among other things, x.264 and DivX MPEG-4 encoder. Obviously, x.264 beat DivX in terms of overall PSNR.
Less obviously, x.264 beat DivX in terms of PSNR at fixed encoding frame rate. One area where DivX was far superior was maximum encoding speed.
With a 640x352 source, DivX exceeded 200 fps in two fastest modes, and the fastest combination of features I could find for x.264 could only reach ~42 fps (albeit with higher PSNR).
My conclusion was that x.264 was never targeted at high-speed encoding.

Suppose that we come out with an encoder that can do reasonable-quality H.264 at the maximum speed that is five times what x.264 can achieve
(equivalently, an encoder that can encode in real time in 5 times the resolution) .
Is there any market for encoding at those kinds of resolution, ie over 1 megapixel (640x352 = 225 kp) ?
720p HD is only 0.9 megapixels.

Most HD material is already released in H264 (perhaps a little TV-broadcasting and semi-professional camcorders in HD Mpeg2).
I can't see much use in transcoding (downsizing) to anything more than 576p which is less-than 0.6 megapixels.

It's all good.


:):devil::D
Pascal

[Dark Shikari]

With a 640x352 source, DivX exceeded 200 fps in two fastest modes, and the fastest combination of features I could find for x.264 could only reach ~42 fps (albeit with higher PSNR).
My conclusion was that x.264 was never targeted at high-speed encoding.I know this is a bit of an old post, but current x264 exceeds 200fps by a wide margin on fastest settings at 640x352 on a single-core Core 2 system ;)

I'd say that x264 is the only encoder in existence targeted at high-speed encoding (http://i37.tinypic.com/dzv244.png); maybe you can lay claim to the title when yours is fast enough to transcode three or four 1080p streams in realtime on a Core 2 Quad.

[BlackSharkfr]

I'm also a major enthusiast of stereoscopic 3D .
Do you use shutter-glasses or some kind of 'strap-on display' ?
A ferw links would be usefull !
It's all good.
:):devil::D
Pascal

i used to have shutter glasses but since i abandonned my crt display i'm now stuck with anaglyph.
I consider buying a passive polarised 3D display next winter. Either iz3d or zalmann not sure yet.
There is a s-3d advocacy group gathering many 3d enthusiast at www.mtbs3d.com you'll find almost all interesting s-3d stuff there.

The thing with anaglyph is that it's the cheapest and most broadly used way to display stereo-3d images, and colour subsampling causes a lot of crosstalk artifacts (aka ghosting) so that's why i asked about 4:4:4.
I guess we'll have to wait ultil stereo-3D is much more popular. There are very few cases for 4:4:4 H264 to be really interesting, x264 authors probably have some much more important features to add for everbody at the moment (like psy rd0, speed improvements, the big x264 GUI)

[DigitAl56K]

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.

...

Of course, that's not to say it wont still be interesting to compare them to the open source competitors!

We're striving to create a high quality encoder and decoder. On the encode side as with the ASP encoder it won't be open-season on every possible parameter - we do have to limit the bitstream properties to be compatible across a wide range of CE implementations. Hopefully we can find a solution that "just works" for the typical user and also provides the performance to satisfy enthusiast users. It's a tough job, but that's the goal.

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?

This is a bit off-topic, so I won't delve into it too much but do please try the latest build vs FFDShow with no post-processing.

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.

That depends of course on the properties of the stream (e.g. rate and features), and the power of the CPU. Because the DivX H.264 decoder has more comprehensive multithreading you should be able to play clips on multi-core systems in cases where FFDShow struggles.

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.

Thanks for supporting us :) We try to provide good software at pretty low price points and we've also had many giveaways. Unfortunately we do have licenses to pay, our developers enjoy a meal occasionally, and these days there are even shareholders to think about so we can't always get the prices down to zero but we do try ;) For about $30 someone starting out on DivX 5 could have had every Pro codec through 6.8, which is not bad for 7 years of updates IMO.

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

Almost there :) Bug fixing and testing has taken a little longer than we'd have liked. We regularly have to make the call on "do we just put this out to get some eyeballs, or do we hold it and fix these half-a-dozen things that might make it painful to use?". Make sure you've applied to be a Project Remoulade group member if you want to be notified and have access to downloads as soon as they're available.

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.

Thanks, I've downloaded the clip(s) and filed a bug/RFE.

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.

I personally am not aware of one. If we find one I'll let you know.

@pitch.fr WRT Reclock: I'll log it, I think the renderer is just not being passed information about the frame rate, similar to the ASP decoder which could also be improved.

My question is a simple one! I was wondering if the next version of the DivX codec will have both x64 and x86bit architecture...

I wish that was a simple one! DivX 7.0 is currently planned to deliver 32-bit native binaries. Beyond the .0 release I can't say when 64-bit native binaries fall into the roadmap but I will personally push to prioritize them.

I'm also a major enthusiast of stereoscopic 3D

I started looking at some 3D-dedicated sites last month. Oh if only I had more money in my bank account and some time to pick up OpenGL again!

[Ajax_Undone]

Awesome Great to hear

[Disabled]

I don't know if it has been mentioned, so I do. I found a file with a resolution of 1024x563 that does not play correct with divx, but does with core and ffdshow (vlc). I always thought mod2 was needed, but what do I know. It was in .mov but as I don't know how to cut that, I made a sample in mkv here (http://www.zshare.net/download/17023925b942e925/). The original was from IBM devs, but I can't find the download link anymore.

[SeeMoreDigital]

Hi Disabled,

Actually, it looks like the .MKV samples video properties are incorrect.

The elementary AVC video stream has a resolution of 1024x564 pixels. But for some reason the .MKV container has been set to 1024x563 pixels!

I would suggest it's not good practice to select "odd" pixel values for the vertical resolution anyway.

[Disabled]

Its not a file i created. I just had it lying around and tried to play it with DivX and it didn't work out as it should, so I reported it. I guess it was produced with quicktime, as that was the original container. I just ran it through mmg to cut a sample from it.
I don't know if its spec compliant, but if it is it should be supported.

[delacroixp]

i used to have shutter glasses but since i abandonned my crt display i'm now stuck with anaglyph.

The thing with anaglyph is that it's the cheapest and most broadly used way to display stereo-3d images
[colour subsampling causes a lot of crosstalk artifacts (aka ghosting)]

Pity about shutter glasses needing CRT displays ... awesome technology (also used by IMAX 3D).


I started looking at some 3D-dedicated sites last month. Oh if only I had more money in my bank account and some time to pick up OpenGL again!
Well... I guess DivX Inc. will get their act together again soon and all the shareholders can go out and buy a Farrari !
I hope you have at least a few shares (good time to buy) ?


It's all good.

:):devil::D
Pascal

[IgorC]

This is a bit off-topic, so I won't delve into it too much but do please try the latest build vs FFDShow with no post-processing.

???
I did
Ffdshow was faster than the last 6.8 on single core (without postprocessing)
Right now I have no time to install system on my old Celeron 2 Ghz (sse2)

I thought that you as developer knew about difference in performance on different hardware. Or it is widely constant on every PC as Divx AVC is faster than Coreavc because of your tests on your PCs?

[Sophocles]

Does anyone use single core processors anymore? I have a problem when the debate is about how a decoder is faster on single core but can't keep up with multicore somehow makes it better? For all you single core owners use what works! I've been hoping that I will be able to use X264 with quad core, because dual core and transcoding from HD DVD to or compressing BD is a very long process even with dual core. With a single core it would be unthinkable.

[Ajax_Undone]

Does anyone use single core processors anymore? I have a problem when the debate is about how a decoder is faster on single core but can't keep up with multicore somehow makes it better? For all you single core owners use what works! I've been hoping that I will be able to use X264 with quad core, because dual core and transcoding from HD DVD to or compressing BD is a very long process even with dual core. With a single core it would be unthinkable.

Well x264 does use quad processors...

[Sophocles]

Well x264 does use quad processors.

I'll look into it. The last time that I checked I seem to recall that quad core support was still a work in progress, but I am quite happy to be wrong on that account.

[Dark Shikari]

I'll look into it. The last time that I checked I seem to recall that quad core support was still a work in progress, but I am quite happy to be wrong on that account.x264 supports basically an unlimited number; when using B-adapt and very fast encoding settings it can bottleneck at around 4 though.

[Sophocles]

x264 supports basically an unlimited number; when using B-adapt and very fast encoding settings it can bottleneck at around 4 though.


Thanks for the info, I'm looking at picking up a quad core for high definition encoding. I'd been waiting for Nehalem to hit the market which should bring current processor prices down a little.

[komarovsky]

Does anyone use single core processors anymore?

Of course plenty of people do! not everyone upgrades their computer every few months and has 6GB of RAM. i don't encode high definition, but ripping my dvds works fine on this few year old computer with fairly high settings. i can also decode 720p video fine (1080p, not so much) with just VLC. I should check out 1080p decoding on some of these faster decoders though.

[Ranguvar]

Yeah; libavcodec (ffdshow is good), MPC-HC if you have a good videocard, otherwise the DivX beta or CoreAVC.

[IgorC]

VLC and mplayer should perform better than ffdshow.

[Ranguvar]

That's odd. I can see how it would preform better, from a theoretical aspect, but MPC-HC with ffdshow seems to decode faster for me... :/

[IgorC]

Maybe you have video acceleration enabled in MPC HC (built-in decoder) and your video card supports it. If it's true you don't need to care about performance at all.

[LoRd_MuldeR]

VLC and mplayer should perform better than ffdshow.

That's odd. I can see how it would preform better, from a theoretical aspect, but MPC-HC with ffdshow seems to decode faster for me... :/

On the one hand MPlayer or VLC should perform better than a DirectShow-based player with ffdshow, because they don't have any DirectShow overhead.
On the other hand I don't know whether MPlayer or VLC use frame queuing - DirectShow renderers (e.g Haali's Renderer) use queuing, which helps to assure smooth playback.

BTW: When testing MPlayer performance, I highly recommend "-vo gl:force-pbo:ati-hack" (the sub-options are very important here!) instead of the default "-vo directx".
That's because the OpenGL renderer can be much faster than the DirectX renderer!

[djloewen]

Will there be discussion at some point regarding the non-video options that will be included in the DivX container specs? Audio types/channels/bitrates, subtitle types, chapters, tags, attachments/thumbnails, menus, that sort of thing? Presumably you'll need to impose some limitations, rather than "anything Matroska can handle", in order to maintain compatibility across the board.

[BetaBoy]

We would like to know that as well especially with the Matroska 2.0 work we are doing now to ensure it is backwards compatible with 1.0.

[DigitAl56K]

djloewen & Betaboy: Yes, we'll be covering things outside of the video profile a little down the road. We're trying to be pretty open with you guys about the format while at the same time trying to avoid announcing details that run the risk of significant changes. As we work out remaining spec/feature details I'll keep you in the loop.

[MySchizoBuddy]

Can you guys update this wiki table with what features Divx H.264 will implement.
At the very least update the Mainconcept table, since you guys own them :)

Link to the wiki table http://en.wikipedia.org/wiki/H.264#Software_encoder_feature_comparison

[iwod]

Matroska, a good thing, but it never has wide adoption apart from us video enthusiast circle.
Now with Divx it may be a chance to make some difference to the world. The question is, how do you pronounce Matroska?

One of the thing I HATE MOST is that open source / free software ALWAYS tend to have UNMARKETABLE names.
Think Ogg, Vobris, Matroska.

May be Divx H.264 file will stick to .divx extension?

[MySchizoBuddy]

so videos encoded with divx h.264 won't play on itunes, ipod, iphone, ps3 and won't play online under flash or quicktime, cause it has matroska, and not mp4.
thanks for curbing my choices and having me do yet another conversion from matroska to mp4.

[LoRd_MuldeR]

Now with Divx it may be a chance to make some difference to the world.

If they sell "DivX H.264 Certified" Stand-Alone players with MKV Support plus update the DivX Web-Player to support H.264 from MKV, the rest will follow automatically!
However I doubt Flash Player + MP4 will disappear from the web that fast...

May be Divx H.264 file will stick to .divx extension?

That would be a HUGE mistake! The only correct extensions for Matroska are .mkv (for videos) and .mka (for audio-only files).
Also the new Matroska-based ".divx" files would be completely incompatible to the old AVI-based ".divx" files. This would cause a hell of confusion !!!

The question is, how do you pronounce Matroska?

"Matroska is an English word derived from the Russian word "matryoshka" (Russian: матрёшка, IPA: [mɐˈtrʲoʂkə]), which means "nesting doll" (the common Russian egg-shaped doll within a doll). This is a play on the container (media within a form of media/doll within a doll) aspect of the matryoshka as it is a container for visual and audio data. The transliteration may be confusing for Russian speakers, as the Russian word "matroska" (матроска) actually refers to a sailor suit." - Wiki has spoken.

[pitch.fr]

does anyone in the DivX team care that Remoulade doesn't give the correct frame rate to Reclock ?

at this point it says 25fps in Reclock, and 0.02fps in ffdshow :(

I know it's legacy software, yet many ppl still use it as it is the only way to get stable frame rate on PC.

and CoreAVC/ffdshow work perfectly fine....so why not Remoulade ? :(

it's been tested on many differents computers.

maybe something wrong with IMediaSample ?
http://msdn.microsoft.com/en-us/library/ms785991(VS.85).aspx

I'm a registered beta-tester of Remoulade if that matters(under the same login)

thanks,

very impressive decoder! :eek:

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 ?!

[neuron2]

CoreCodec Matroska 2.0 posts moved here as requested:

http://forum.doom9.org/showthread.php?t=140723

Advise in PM if you need a thread title or forum change.

[BetaBoy]

thx neuron2

[pitch.fr]

so this is what happens.

Remoulade says "25 fps" in the DS graph for 23.976/24 fps movies :

http://pix.nofrag.com/e/3/9/41bf4f9d7265a413eea6573417dcc.png

only if I disable "determine frame rate through directshow" in Reclock and force manual frame rate, THEN I can get 23.976 fps in Reclock.

this MKV is 23.976, and shows as 23.976 with CoreAVC/ffdshow.

any chance for a fix ? :(

[Disabled]

Just came in:
We're pleased to announce the third beta release of the DivX H.264 Decoder! Beta 3 improves performance for older AMD CPUs, introduces preliminary support for DVB applications, adds support for baseline profile, and greatly improves stability of the decoder.

The clip I had problems with (http://forum.doom9.org/showthread.php?p=1170237#post1170237) works flawless now. Thanks for the update.