Project Rémoulade Update: DivX H.264 Encoder Alpha 1 & Tutorial now available

[DigitAl56K]

Today we have released as part of Project Rémoulade (http://labs.divx.com/ProjectRemoulade) an alpha version of the DivX H.264 command line encoder (http://labs.divx.com/node/6992) at DivX Labs (http://labs.divx.com):

The second package to be released from Project Rémoulade is an alpha version of the DivX H.264 Encoder. Complementing the DivX H.264 Decoder, this multithreaded encoder produces high definition H.264 video bitstreams that are compatible with the draft profile for DivX 7 H.264 HD video. The encoder is a command line utility and accepts input from raw AVI files as well as the AVISynth frame server.

A comprehensive tutorial is provided for anyone who lacks experience with command line tools or certain aspects of AVISynth.

The alpha serves as a starting point for us to discuss the encoder as it stands in this early version and how we can develop it to better serve the needs of the community. A list of known issues (http://labs.divx.com/node/6992#Section_KnownIssues) and contact information (http://labs.divx.com/node/6992#Section_HowToHelp) is available at DivX Labs.

The encoder also serves to introduce elements of the draft DivX 7 profile for H.264 HD video and this is something we aim to elaborate on further over the next week to get your feedback.

[Dark Shikari]

This space reserved for a technical review of the encoder:

1. No adaptive quantization at all.
2. Uses 8x8dct, P-frame weighted prediction (at least the flag is set), and 4 refs in each list (according to the flags).
3. Chroma QP offset of +1.
4. --deblock -1:-1 used.
5. Appears to use spatial B-frame prediction only.
6. Uses Level 4.0, which sounds like a reasonable thing to standardize upon.
7. Uses an I-frame QP offset of -3 and a B-frame QP offset of +1.
8. Its B-frame decision seems to overly bias in favor of 2 B-frames.

This is just a preliminary glance at it, but overall the profile decided upon seems to be quite reasonable: enough bitrate for most sources without being too demanding of hardware, and not making any stupid restrictions like "no 8x8dct".

Actually quality comparisons (and speed) will come later.

Is there documentation on exactly what features are required in the DivX H.264 profile, by the way? I.e. which decisions here (such as spatial B-frames) are encoder decisions, and which are technical decisions in the spec itself. And what about the max of 4 seconds per gop--is that just an encoder limitation, or is there something in the spec about that?

[DigitAl56K]

Is it really necessary to reserve space to ensure your comments appear immediately under the announcement? ;) That's not really how single-threaded discussion works. Should I reserve space to reply to you? ;) Also, although technical commentary is fine if it's constructive and of course comparisons will be made, a general request I'd make to all contributing is to please avoid turning this thread into DivX vs x264, that is not the goal (start a new thread if you so desire).

Thanks, and eager to hear your thoughts :)

[Dark Shikari]

Is it really necessary to reserve space to ensure your comments appear immediately under the announcement? ;) That's not really how single-threaded discussion works. Should I reserve space to reply to you? ;) Also, although technical commentary is fine if it's constructive and of course comparisons will be made, a general request I'd make to all contributing is to please avoid turning this thread into DivX vs x264, that is not the goal (start a new thread if you so desire).

Thanks, and eager to hear your thoughts :)I don't intend to do such a thing; the post will not be comparison (that will come later).

[DigitAl56K]

This space reserved for a technical review of the encoder:

6. Uses Level 4.0, which sounds like a reasonable thing to standardize upon.


Yes, the draft profile is limited to levels 3, 3.1, 3.2, or 4.0.

This is just a preliminary glance at it, but overall the profile decided upon seems to be quite reasonable: enough bitrate for most sources without being too demanding of hardware, and not making any stupid restrictions like "no 8x8dct".

There are very few restrictions in the profile that I think will be contentious.

Is there documentation on exactly what features are required in the DivX H.264 profile, by the way?


Yes, I plan to cover them next week.

And what about the max of 4 seconds per gop--is that just an encoder limitation, or is there something in the spec about that?

The draft profile has a limitation of 4 seconds for the IDR interval. The goal is to enable a nice trick-play experience on lower powered decoders. We had requests for even shorter intervals but after some rounds of testing where we measured the effects of various maximum periods on quality and bitrate we settled upon this as a good trade off. If you would also like to do some testing of your own that would be welcome :)

[neuron2]

The draft profile has a limitation of 4 seconds for the IDR interval. The goal is to enable a nice trick-play experience on lower powered decoders. Amen, Bro'. And it's not just lower-end decoders. Having to decode 300 HD frames just for a frame seek is really silly.

I would have made it one second, although I can see that would be too short if targeting a small bitrate.

[Dark Shikari]

I've finished a preliminary evaluation of the encoder; overall I'd say its roughly on par with the Mainconcept encoder (the cynic inside me says its a modified Mainconcept due to DivX's acquisition, but I'll trust you if you say it isn't...). This isn't competitive at all with x264, but a pretty damn good accomplishment for the first alpha release.

[DigitAl56K]

Thanks Dark Shikari,

The encoder is based around the MC engine, but I'd like to stress again that we should really stop thinking about which pieces of code come from where because over time this becomes irrelevant - both teams work together now and the best of any previously separate works will become fused together in future software. In fact this is already happening as part of this project :)

In my opinion the main difference you'll see is that DivX will be more focused on working directly with the video community to create a high quality media experience and bridge the consumer electronics gap - which is why I'm working on Project Rémoulade!

[DigitAl56K]

Just to add to the IDR interval discussion it is worth considering the value of a given maximum IDR to the trick-play experience. If you have a max. IDR of 4 seconds and during trick play you display each IDR for 0.5 seconds you have time scaling of 8:1. If you display each IDR for 0.25 seconds you have timeline compression for 16:1. But if your max IDR is every 1 second then even if you're displaying each trick frame for only 0.25 seconds that's only timeline compression of 4:1.

You would get max 30:1 compression with max IDR = 1 second due to the frame rate if you did not skip IDR's, and max 120:1 compression with max IDR = 4, but I'm not exactly sure how easy that would be to navigate! ;)

Just posing an alternative way to look at it. Nothing in the draft profile prevents shorter IDR interval btw.

If anyone is interested, it's possible to simulate the experience using AVISynth's SelectEvery() filter as an IDR skip and using AssumeFPS() to set the rate that the display is updated.

IDRInterval = 4 # IDR max period
UpdateRate = 4 # IDR's shown per second during trickplay
MySource=AVISource("SomeFile.avi")
Return SelectEvery(MySource, int(MySource.FrameRate() * IDRInterval), 0).AssumeFPS(UpdateRate, 1)

[ChronoCross]

Anyway I think 1 second is too little and would be detrimental to quality. It's just like making it too big might give the encoder more freedom quality wise but at the cost of seeking time. 4 is a decent compromise.

The Cli is easy to use and isn't as complex as Ateme's beta was when i did testing with that. Granted this encoder has few quality control options and is definitely an alpha but appears to be a good start. I can't really say much about the multithreading as I have a single core processor but the inclusion of direct AVISYNTH support is welcome.

Do you plan on including anything else in terms of input support? I see AVI is on the list but the known bugs state it's not currently working.

I don't have any interlaced sources but I wanted to ask if anyone had tried it out yet?

[bob0r]

@DigitAl56K

May i ask what your goals are with this encoder?
(Besides the obvious: Money)
- Are you planning to make DivX encoder package for H.264 devices, like market it for that?
- Are you planning to make DivX encoder the main H.264 for Windows? (and thus indeed have to battle x264)
- Are you planning to make DivX (AVC) as divx-asp versus xvid is now: Funny it exists, but those who want speed, quality and freedom all choose XviD.

I am asking this because i see DiVX as a "big(ger)" company.
Sony, Apple and Microsoft all have disappointed me hugely, by the fact they all lack the insight of making proper Support for what people REALLY WANT!

I am sure if they spent only 0.01% of the budget, they can make any Device support all H.264 options satellite and x264 can output. And .mkv support i think would BOOST sales a lot aswell. Maybe i am too narrow minded, but fact remains:

99.9% of ALL xvid and x264 releases contain the contents that would get you warned on this forum!

(in no way is any flaming intented, but thats just the nature of these topics, besides the technical stuff)

Just to point out i would always use the better product:
CoreAVC (many hour of testings and payed for)
ioftpd (many hour of testing and donated, not freeware)
FlashFXP (some hours of testing and payed for)
DvbViewer (mostly decoder testing, and payed for)
AnyDVD (never used, but payed for, just for what they stand for, i dont need their tool, others can code better and faster, but thats private :))

The reason i mention the above is: These people have IRC channels or great Forum support. They LISTEN to what people have to report.... same goes for many opensource projects.

So if you listen to what people report here, and actually try to make or fix what they have to report.... you might go a long way.
CoreAVC has/had? no competition, so their feedback to users was a 2/10, and it took them some time to regain respect.

Good luck with _not_ competing with x264 and i truely hope DivX AVC can be great quality aswell.... i am real tired of blocky and blurry video!

[dukey]

high profile @ level 4.0 seems like a good standard to go for

[bob0r]

high profile @ level 4.0 seems like a good standard to go for

Why limit yourself?
Soon even a $10 telephone can play 10 blu-ray movies simultaneous.

No really, no reason not to use all H.264 has to offer.

[Ranguvar]

Please do let use know when you have a finalized or near-finalized spec for max encode settings (number of refs, b-frames, level, b-pyramid, etc.).

I believe a lot of us here, including me, are mostly just interested in creating DivX 7-compatible encodes with x264 :) Not dissing DivX, just a fact :)

[bobololo]

Just to add to the IDR interval discussion it is worth considering the value of a given maximum IDR to the trick-play experience. If you have a max.

[...]

Speaking of IDR in your profile specification, please do me a favor and try to avoid the common mistake that assumes that a random access point is an IDR access unit. Indeed, while an IDR has actually the properties of an random access point, it also has many other charateristics like flushing the DPB which prevents the use of open GOP for instance (that can hurt encoder efficiency).

H.264 standard provides a syntax to signal random access point. It relies on the recovery_point SEI message that tell from which point in the bitstream you can start decoding and after how many frames, you're guaranteed to have recovered a proper video.

[DigitAl56K]

The Cli is easy to use and isn't as complex as Ateme's beta was when i did testing with that. Granted this encoder has few quality control options and is definitely an alpha but appears to be a good start.

In terms of options for quality control we'd like to hear what kind of options you think are most important. Of course, it is possible to provide options for everything under the sun if we wanted to, but it would be good to know what your top 3 requests are, for example.

Do you plan on including anything else in terms of input support? I see AVI is on the list but the known bugs state it's not currently working.

What additional input support would you like us to include and why? ;) stdin support is one of the suggestions we've seen already over at DivX Labs.

@DigitAl56K

May i ask what your goals are with this encoder?

No. Oh, alright then! go ahead.. ;)


- Are you planning to make DivX encoder package for H.264 devices, like market it for that?

Our goal will rather be to create a spec that enables widespread interoperability of content across CE devices, ensuring that media created on certified encoder devices is guaranteed to play well on any certified decoder device. We develop tools and certification programs to make sure everything works seamlessly end-to-end. This way, for example, a consumer can know without question that the video shot by their DivX Certified cell phone will look good and play flawlessly on their connected device, DVD player, and so forth. To your specific point, manufacturers may have their own encoders that will be tested to be compliant or they may use ours as a reference. This is similar to what DivX does today.

- Are you planning to make DivX encoder the main H.264 for Windows? (and thus indeed have to battle x264)

Not necessarily. Of course we hope to develop the encoder into a successful product, but our primary goal for the encoder is to ensure everyone has access to easy to use tools that will enable them to create high quality video with an excellent experience guaranteed on any device.

I personally could not be happier than if x264 and/or the front-ends that use it create compatible settings. The goal is not to become the dominant encoder, it is to ensure the experience.

Are you planning to make DivX (AVC) as divx-asp versus xvid is now: Funny it exists, but those who want speed, quality and freedom all choose XviD.

I think which particular encoder people choose comes down to their own personal needs. What's important is that when people spend their time creating videos they're not locked down to the desktop and can watch them in a wide selection of devices.


I am asking this because i see DiVX as a "big(ger)" company.
Sony, Apple and Microsoft all have disappointed me hugely, by the fact they all lack the insight of making proper Support for what people REALLY WANT!

I am sure if they spent only 0.01% of the budget, they can make any Device support all H.264 options satellite and x264 can output. And .mkv support i think would BOOST sales a lot aswell.

But some of these companies aren't interested in doing that :) Take Apple, for example. They have quite some stranglehold over the way the content they sell is consumed with a DRM system that only Apple devices can use. They and only they make the hardware. They created AppleTV and they dictated what you could do with it.

We can have a world where our experience is very silo'd - you buy into a particular format and you're at the mercy of a single company, or very open, which is what DivX tries to be. We work with hundreds of manufacturers to offer a massive variety of choice, but at the same time make sure that your media is going to work well on any end-product.

So if you listen to what people report here, and actually try to make or fix what they have to report.... you might go a long way.

I hope so :)

Please do let use know when you have a finalized or near-finalized spec for max encode settings (number of refs, b-frames, level, b-pyramid, etc.).

I believe a lot of us here, including me, are mostly just interested in creating DivX 7-compatible encodes with x264 :) Not dissing DivX, just a fact :)

Will do - we'll be discussing it here soon! Again, if you prefer to use x264 no worries ;)

[komarovsky]

Our goal will rather be to create a spec that enables widespread interoperability of content across CE devices, ensuring that media created on certified encoder devices is guaranteed to play well on any certified decoder device.

very worthy goal :) many users are fine with knowing what settings to use to get compatibility with something, like the apple tv. They know about all of the options in the encoder and what they are compatible with... But then there are other people who just want to know "if I encode my video with this, it will be able to play on this. good."

[squid_80]

Is interlaced encoding (via -tff or -bff) meant to be working? I always get an error stating "Width, height or frame rate outside profile (interlace) specification" followed by the width x height@framerate of my input clip (which is kind of pointless; I already know what they are, but I don't what profile specifications I've supposedly exceeded). I've tried various resolution and framerate combos right down to 320x240x23.975fps.

[neuron2]

I've moved the IDR versus editing discussion here:

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

I'm interested in further discussion of it over there. Thank you.

[stax76]

Are there plans for a PAR option?

[crypto]

Yes, a PAR option would be great, although the same can be accomplished with a MP4 transformation matrix. I would also be happy to target the Main Profile. All other options are a well done, not to much, but powerful enough.

[ChronoCross]

What additional input support would you like us to include and why? ;) stdin support is one of the suggestions we've seen already over at DivX Labs.




MKV Input, MP4 Input

Both of these would be helpful for direct encoding from previously encoded files to a mobile platform/profiles. Rather than having to demux them first.

[DigitAl56K]

Crypto & Stax, I'm hoping to have SAR added to Alpha 2.

ChronoCross: I assume you mean specifically for the video track, the audio would still be demuxed, yes? Or do you suggest all other compliant tracks are automatically copied?

[ChronoCross]

Crypto & Stax, I'm hoping to have SAR added to Alpha 2.

ChronoCross: I assume you mean specifically for the video track, the audio would still be demuxed, yes? Or do you suggest all other compliant tracks are automatically copied?

Whichever you are willing to do. Just would be nice to be able to lower the number of steps needed to process those files for movement between devices.

[linyx]

Awesome encoder:eek:

Our goal will rather be to create a spec that enables widespread interoperability of content across CE devices, ensuring that media created on certified encoder devices is guaranteed to play well on any certified decoder device.

Just a thought.

Maybe you could add more settings but have the encoder display a message saying that if you use "whatever setting" it will break compatibility with some certified decoders.:)

[hajj_3]

could i ask what is happening regarding divx certification on games consoles, is it mandatory for them to update to each new version? As i'm hoping that the ps3 and 360 add divx 7 so that they will be able to play .mkv files as we currently have to demux them and put them in a .mp4 container which is a choir. Will the 360 and ps3 HAVE to allow divx7 file playback and therefore x264 .mkv files as there are loads of x264 videos on the internet, would be great to play them on consoles.

[DigitAl56K]

hajj_3: It's not mandatory, but we also hope to see these consoles playing the new format.

[hajj_3]

doh:( Are you able to tell us if MS or Sony have discussed adding divx7 support to next update or if they are already adding .mkv support for h264? They added xvid surely .mkv would make sense too, they'd sell quite alot more consoles i reckon.

[DigitAl56K]

hajj_3: I don't know about that, but even if I did it would be illegal for me to tell you for multiple reasons ;) I do agree that it would probably help them sell consoles and make their customers happy. Let's cross our fingers ;)

[juGGaKNot]

Just got it now, will install and test.

[LigH]

Here a little GUI for the CLI encoder. Quite as "Pre-Release" as the encoder...

http://labs.divx.com/node/6992#comment-6651

[DigitAl56K]

LigH: That's awesome! :)

There's currently a small bug in the way you pass the file names in the batch script. You need to quote the file names in case they contain spaces, otherwise they are not interpreted as a single argument and you'll get an error.

Are you also considering tying in MKVMerge?

[LigH]

If I selected the encoder via file-open dialog, it got automatically quoted, so I assumed that for the video filename too... I'll put a little bit more brain into it tomorrow. Now I have to head to my pillow (23:00).

[LoRd_MuldeR]

DivX H.264 Encoder Alpha-1 vs. x264 r951+PsyRDO. 2-Pass encode at 300 kbps. Frame-wise comparison -- step through the video frame-by-frame!
http://www.mediafire.com/?z1ubvmbnp5y

[ChronoCross]

DivX H.264 Encoder Alpha-1 vs. x264 r951+PsyRDO. 2-Pass encode at 300 kbps. Frame-wise comparison -- step through the video frame-by-frame!
http://www.mediafire.com/?z1ubvmbnp5y

not even sure what that was supposed to be.

[LoRd_MuldeR]

not even sure what that was supposed to be.

Visual quality comparison of DivX H.264 Encoder vs. latest x264 revision. Encoded at 300 kbps in 2-Pass.
If you watch the video frame-by-frame (e.g. in VirtualDub) it should be quite clear...

[ChronoCross]

by this test divx is pretty horrible. (by my eyes)

what was your full command lines?

[LoRd_MuldeR]

by this test divx is pretty horrible. (by my eyes)

what was your full command lines?

I used Ligh's GUI for DivX H.264 and Avidemux for x264. So I can't give you the exact commandlines, but I pretty much maxed out all settings available :D

EDIT: Here are my x264 settings (http://pastebin.com/f1c2149d1), extracted from the encoded sample video. And here (http://img291.imageshack.us/my.php?image=divxsettingsql9.png) are my DivX H.264 settings.

[IgorC]

I'm not sure if watch the video frame by frame is a good idea. I don't know how interpret a smoothness of Divx if don't see a video in playback. Same for x264. I can't say if it's more detailed or it's quantization noise without correlation between frames.

And do we watch the video frame by frame in real life?

[LoRd_MuldeR]

And do we watch the video frame by frame in real life?

We don't. But do you know a better way for visual comparison than showing the frames alternating?
Side-by-side view isn't perfect either. In fact I think it makes the comparison harder...

If you want to see it in motion, you can simply watch it in a player -> use SelectEven/SelectOdd in Avisynth.

[Dark Shikari]

There's a reason DigitAl said he didn't want comparisons... you can tell where this thread is going to head if you keep using them.

The DivX encoder isn't competitive yet--that's why its an alpha ;)

[LoRd_MuldeR]

There's a reason DigitAl said he didn't want comparisons... you can tell where this thread is going to head if you keep using them.

The DivX encoder isn't competitive yet--that's why its an alpha ;)

I just sent my sample to a fried and he liked the "DivX" version more, because it looks softer :p

[LigH]

I used Ligh's GUI for DivX H.264 ... So I can't give you the exact commandlines...

Liar! :p

WhisX.exe generates a WhisX.bat and executes it. Open the generated WhisX.bat, quote the content. ;)

[Dark Shikari]

I just sent my sample to a fried and he liked the "DivX" version more, because it looks softer :pWe have Avisynth filters for people like him.

Deen().Deen().Deen().Deen.Deen().Deen()! :)

[ChronoCross]

We have Avisynth filters for people like him.

Deen().Deen().Deen().Deen.Deen().Deen()! :)

/me kills Dark Shikari


mftoon() ftw.....and ftseyweh (for the slowest encoding you will ever have)

[LigH]

Update:

WhisX now quotes filenames (hopefully) as necessary; and a few cosmetics (command line copyable; pyramide checkbox with optical feedback to B-reference checkbox).

No version tracking. Just download (again).

[LigH]

Update:

Settings management via INI files; an INI file with the same name as the application (e.g. "WhisX.ini") in the application folder is used as default settings during startup.

[LoRd_MuldeR]

Liar! :p

WhisX.exe generates a WhisX.bat and executes it. Open the generated WhisX.bat, quote the content. ;)

Why you don't run the encoder directly and redirect the console output to the GUI application? Is that planned?

[LigH]

I create the batch file on purpose: On one hand, both CLI and GUI are expected to be buggy; on the other, it is not yet worth the efforts, the next encoder may have a remarkably different set of options; and finally, you don't really need a GUI, do you? ;)

Also it is not easy anymore to find out how to redirect console outputs to Delphi... most Delphi websites are already dead...

[LoRd_MuldeR]

Also it is not easy anymore to find out how to redirect console outputs to Delphi... most Delphi websites are already dead...

I can send you my code, in case you are interested :)

Basically I ported the code from this article to Delphi and added a few things I needed for LameXP:
http://support.microsoft.com/kb/190351/de

[LoRd_MuldeR]

LigH, here is a simple Demo application I just hacked together:
http://www.mediafire.com/?mamwiyubawt

(Sources included, the EXE was compiled with Delphi 7.0 Professional)


EDIT: Re-uploaded an improved version. Link has been updated!

EDIT2: Re-uploaded an improved version - again. Link has been updated!

[LigH]

Great.

Not sure if I will use it already for DivX264 CLI alpha 1, but maybe some day...

[buzzqw]

btw i added support in AutoMKV, i just wait approval from DivX!

BHH

[LoRd_MuldeR]

Not sure if I will use it already for DivX264 CLI alpha 1, but maybe some day...

It already works with my simplistic Demo application and this commandline:
cmd.exe /c "C:\Program Files (x86)\DivX\DivX H.264 Codec CLI\bin\WhisX.bat"

(But the log filter would need some adjustment for divx264.exe -- done, see post above)


@ DivX developers:

It seems the DivX CLI encoder is missing to call fflush() after writing the progress line to STDOUT/STDERR.
This will cause a nasty delay when redirecting the console output...

x264 does do it the following way:
if( i_frame_total )
{
int eta = i_elapsed * (i_frame_total - i_frame) / ((int64_t)i_frame * 1000000);
i_progress = i_frame * 1000 / i_frame_total;
fprintf( stderr, "encoded frames: %d/%d (%.1f%%), %.2f fps, eta %d:%02d:%02d \r",
i_frame, i_frame_total, (float)i_progress / 10, fps,
eta/3600, (eta/60)%60, eta%60 );
}
else
fprintf( stderr, "encoded frames: %d, %.2f fps \r", i_frame, fps );
fflush( stderr ); // needed in windows

[DigitAl56K]

LoRd_MuldeR & LigH: Wow, you guys are on fire today!

LoRd_MuldeR: I'll log the fflush() issue. Side: I already have an issue logged where some of the -help is written to stderr instead of stdout.

LigH: I have a suggestion for your app!

You could support a wider range of inputs by doing this:

If the input is AVI or AVS, write an intermediary AVS script that loads the input file via AVISource
If the input is another type, write an intermediary AVS script that loads the input via DirectShowSource
You could use Don's command-line guide (http://neuron2.net/dgmpgdec/DGIndexManual.html#AppendixB) for DGMPGDec to handle MPEG formats if it's available on the system.


After writing these intermediary files you can open them with the windows AVIFile APIs and check the rate/scale of the video stream to make sure it's valid and if not automatically apply something like ConvertFPS with the nearest allowed rate/scale. You could also check the width and height and apply AddBorders and/or a resize if necessary, then finally pass this AVS file to the encoder. If you want to get really fancy you could add ConvertToYV12 to the AVS script and get the picture in a known format through the AVIFile interfaces, then apply a routine to determine a crop window to remove borders, checking various frames throughout the file. I think you can also get PCM samples easily this way so you could write a WAV file then pass it through an audio encoder and hook up mkvmerge to bring everything together.

buzzqw: I sent you an e-mail, I'd love to see AutoMKV support this!

LoRd_MuldeR & Dark Shikari: Thanks for the comparison vid, and for keeping the conversation on track! I haven't had time to thoroughly investigate it yet but x264's new psy does seem impressive :) I did notice that the clip is rather low motion and x264's settings were quite extreme - e.g. 16 refs, 15 consecutive b's, ~20s IDR interval, so I'm wondering if this is somewhat special case. Anyway, I'll look into it further :) I think we also have that clip so I can recreate it with more comparable settings.

[DeathTheSheep]

I'm disappointed that there is no constant quality mode, which is a necessity for my purposes. Did I just miss a commandline option or something?

[DigitAl56K]

DeathTheSheep:

Constant quality is not available because it doesn't allow management of rate spikes. Keep in mind that the encoder is designed to create CE-friendly streams. 1-Pass target-quality on the other hand is one of the most requested features at present.

[LoRd_MuldeR]

Constant quality is not available because it doesn't allow management of rate spikes.

Isn't that the entire point of "constant quality" mode? Use as many bitrate as needed and don't care about the final size or bitrate spikes?

Obviously 1-Pass makes it hard to implement VBV restrictions, but it should be possible to run a simple 1-Pass CQ encode without any VBV restrictions at least...

[DigitAl56K]

Isn't that the entire point of "constant quality" mode? Use as many bitrate as needed and don't care about the final size or bitrate spikes?

Obviously 1-Pass makes it hard to implement VBV restrictions, but it should be possible to run a simple 1-Pass CQ encode without any VBV restrictions at least...

Yes, that is the entire point of it and the entire problem! :) The encoder, at least in this early version, is designed to implement the draft profile. Modes that would typically be part of unconstrained operation aren't available because currently this isn't the intended purpose of the release.

However, we are taking feedback about all requested future options. How important to you is constant quality mode and what are the situation under which you'd want to use it?

[stax76]

Latest StaxRip beta has DivX H.264 support. Compressibility check is missing because there is no constant quality mode. I use crf 22 so not having a constant quality mode is a show stopper for me. Since the encoder is privat + alpha it will only show up if the encoder is installed. GUI looks as follows:

http://planetdvb.net/non_drupal/images/StaxRip_DivX_H.264_Options.png

For those who wonder why I often use the TreeView instead of real controls, reasons are: Every option requires a single line code only so it helps to fight bloat, it's quick and easy to code, easy to maintain, easy to change, easy to extend and automatically clean and polished.

[SeeMoreDigital]

For those who wonder why I often use the TreeView instead of real controls, reasons are: Every option requires a single line code only so it helps to fight bloat, it's quick and easy to code, easy to maintain, easy to change, easy to extend and automatically clean and polished.Yep.... I prefer this way too!

[DigitAl56K]

Latest StaxRip beta has DivX H.264 support. Compressibility check is missing because there is no constant quality mode. I use crf 22 so not having a constant quality mode is a show stopper for me.

Good point! :)

Off to download now!

[LoRd_MuldeR]

How important to you is constant quality mode and what are the situation under which you'd want to use it?

I personally don't have any "mobile" device, nor do I have a "standalone" player. So I don't care about profiles, I use MPlayer or MPC+ffdshow. I want to archive captured video clips on my HDD and hence I need some "constant quality" mode. My clips are usually between 3 and 10 minutes, mostly live music. Some clips have a LOT of motion, some are more static. I want to have the "same" quality (more or less) in all my clips and I don't care if some clips are MUCH bigger than others. At the moment x264 + Psy-RD does a great job with it's "CRF" mode. So I use CRF=22 for most of my encodes, I rarely use 2-Pass. If you ever want me to consider DivX H.264 as an serious alternative to x264, you'll have to provide some mode like CRF...

[DigitAl56K]

LoRd_MuldeR: Ah :) Yes! I think there has been some misunderstanding. A CRF-like mode is absolutely something we are considering! I read "constant quality" as fixed qp, although it sounds like Stax still needs a qp mode for compression check.

[stax76]

crf like is fine for comp. check.

[LoRd_MuldeR]

A CRF-like mode is absolutely something we are considering!

Good news :D

[DigitAl56K]

crf like is fine for comp. check.

Better news!

[LigH]

Sorry to disappoint you:

I won't work much further on my GUI as long as there is only an "Alpha version 1". ;)

Means: I may consider more efforts with a next encoder version... Patience. I have less life than ever before.

[Inventive Software]

Nice going with this BTW! It had to come whilst I was at Greenbelt! :D How's speed with the same settings as x264 comparable?

[Ajax_Undone]

Wow oss still kick butt Divx got to work a bit harder on that...

[Dark Shikari]

Nice going with this BTW! It had to come whilst I was at Greenbelt! :D How's speed with the same settings as x264 comparable?Speed can still use a lot of work--in my test DivX goes significantly slower in its fastest mode than x264 goes with psy RD and psy trellis (--subme 6 --trellis 1 --bframes 3 etc). This presents a serious problem, for obvious reasons. DivX has a huge amount of room for improvement here, so one can hope that they'll cover some ground in the next release.

[RickA]

Greets,

Really enjoying testing out the new codec. Quality looks great. Encode times seem reasonable.

@LigH, thanks for the GUI. Very handy.

Cheers,
Rick

[linyx]

You may want to update a shortcut. Under Start Menu > Programs > DivX > DivX H.264 Codec CLI > Learn about DivX H2.64 Codec CLI, I think it should be "Learn about DivX H.264 Codec CLI":)

[siva]

this is beta :devil:

[LigH]

this is beta :devil:

http://www.ligh.de/pics/this_is_beta.jpg

:o Sorry, couldn't resist.

[Kurtnoise]

found a typo at the end of the stdout...

AVI 720x480
AVI frame rate parameters:(30000/1001=29.970030)
DivX H.264/AVC encoder (cli/sdk 0.0.0.5/7.3.0)
Copyright (c) 2008 DivX

[time: 0:00:32] [left: 0:00:00] [speed: 7.4 fps] [frames: 241/241]

Summary information:
Number of coded frames 241
Total encoding time 32496 ms
Average time per frame 134.838 ms
Average speed achieved 7.4 fps
Average bitrate 1987.48 kbit/sec @ 29.970 Hz

[Sagekilla]

Technically that's not completely wrong, Hertz is used as a measure of frequency, in this case frames per second.

[Kurtnoise]

but quite unsual...

video frame != audio frame

[IgorC]

Hz is generic unit of frequency. It doesn't matter what. Frames per second, samples per second, apples per second, bananas per second - Hz.
Something per second.

[Kurtnoise]

hey, I'm not stupid...It was just a notice.

[CruNcher]

It's quiet common for a Video Engineer to use Hz instead of FPS especially if it's one from the Analog days :)

[IgorC]

hey, I'm not stupid...It was just a notice.
Then why do you ask? Is there somethig odd?
Admit that you didn't know that. It's simply to see. That's not shamy. Many people don't know what is Hz, Watt, Volt, Ampère, Faraday, Henry.....
For many people Hz is just for audio measurements.

Imagine situation:
John: Hey, how is your dog?
Paul: My pet is fine.

Is that talk odd for you?


The same way Hertz and fps.


but quite unsual...

video frame != audio frame

It means that if boys are weighted in kg then girls can't be weight in kg. Right?

[Kurtnoise]

wtf...

Then why do you ask? Is there somethig odd?
I wasn't asking (did I posted a question ?)...It was just a notice. I quite *understand* that we can use Hz for this. Period. Damn. :sly:

It means that if boys are weighted in kg then girls can't be weight in kg. Right?
mmh...you like to play, isn't it ? First, it's not weight but mass. And my point is : it's quite unusual to see in video tools fps measure expressed in Hz nowadays. That's all.

So, now back on topic. Did you try this encoder ?

[Sagittaire]

wtf...


I wasn't asking (did I posted a question ?)...It was just a notice. I quite *understand* that we can use Hz for this. Period. Damn. :sly:


mmh...you like to play, isn't it ? First, it's not weight but mass. And my point is : it's quite unusual to see in video tools fps measure expressed in Hz nowadays. That's all.

So, now back on topic. Did you try this encoder ?

1) Mainconcept use Hz since more than 2 years for internal CLI test.

2) You have exactly the same quality output than Mainconcept SDK without AQ and FGO (exactly same PSNR and same speed). DivX use Mainconcept SDK 7.3.0.4316 core codec. DivX7 CLI or Converter are really poor tools if you compare with Cinevision from Sonic or Reference from Mainconcept.

[Kurtnoise]

sure...it's in alpha stage. Hoping to have new features in the next builds.

[Sagittaire]

sure...it's in alpha stage. Hoping to have new features in the next builds.

No for me it's simply volontary limitation for Mainconcept SDK core from DivX Network. Mainconcept SDK is not in alpha and all the feature are well know since very long time (more than 2 years now). I have here really complete CLI from Mainconcept (2 years old) with all the fonctionality. DivX use internaly exactly the same tools. Here the command line that you can find in the h264vout.001 file from DivX Converter:

PrintProgress CalcQuality Buffering LiveMode NumThreads CpuOpt PicNumOffset FrameMBsMode Log2MaxFrameNum Log2MaxPOC WritePPS WriteSPS WriteSingleSEI WriteTS WriteEOS WriteAUD AnnexB StreamType NumUnitsInTick TimeScale PAR_Height PAR_Width SAR_Height SAR_Width SAR_IDC VUIFlags BlackLevel DenoiseStrengthC DenoiseStrengthY Lambda FGOStrength GrainOptimization QuantOptimization FastSBME FastMRME FastInterDecision FastIntraDecision HadamardTransform InsaneRDO EnableRDO OffsetsMatrixFile UseOffsetsMatrix ScalingMatrixFile UseScalingMatrix BetaOffset AlphaC0Offset DeblockMode EnableInter_PCM EnableInter_4x4 EnableInter_8x8 EnableInter_16x16 EnableIntra_PCM EnableIntra_4x4 EnableIntra_8x8 EnableIntra_16x16 ConstrainedME OutOfPicMVs SearchRange NumRefFrames WeightedBiPred WeightedPred SubBlockMode SubPelMode EnableME Pass StatFile MaskingStrength MaskingType CpbRemovalDelay CpbFullnessUnits CpbFullnessTarget CpbFullness CpbSize HssRate UseVclHRD UseNalHRD AvgBitrate CrOffset CbOffset QuantMax QuantMin QuantB QuantP QuantI RCMode IDRPeriod AdaptiveB EnableSCD PyramidCoding BFramesReference BFramesCount MinIntraPeriod MaxIntraPeriod SliceArgument SliceMode TopFieldFirst InterlaceMode LosslessCompression TransformType EntropyMode ChromaFormat Level Profile ColorSpace Height Width FramesCount StartFrame StatFileName ConfigFileName ReconstFileName TargetFileName SourceFileName


For me at this time DivX Converter is simply really useless and limited gui for Mainconcept SDK. Moreover the gui don't even use the lastest SDK build (7.5.xxxx from reference) or the more interessing build (7.4.xxxx from sonic with independant AQ strength for all mask MaskingStrengthCplx MaskingStrengthContr MaskingStrengthLuma).

Make MeGui support for this tools is at this time really useless because the codec from DivX is really crappy. x264 will always produce by far really better result.

[Sharktooth]

crappy or not, the divx encoder is alpha1 and we all know what alpha1 means...

[Sagittaire]

crappy or not, the divx encoder is alpha1 and we all know what alpha1 means...

Well problem is here ... Mainconcept SDK is not alpha at all ... since more than 2 years. And DivX encoder use the complete Mainconcept SDK binary with exactly the same command line. Really easy for DivX Network to compile executable with complete and native command line. Anyway DivX Network use really limited build ... and it's IMO completely volontary.

h264vout.001 from DivX Converter
7.3.0.4316 ... something like 08/2007 for this build

h264vout.001 from MC Converter
7.5.0.35746 ... 2008/10/02


You can if you want remplace the h264vout.001 file and DivX Converter or DivX Encoder Alpha 5 will work perfertly. DivX Converter or DivX Encoder Alpha 5 are not completely new encoder. It's just simple Mainconcept SDK core codec compilation.

[Sagittaire]

Here little sample with same speed for all AVC encoding.
I use simply insane speed setting for VC1 SDK.

http://jfl1974.free.fr/Sample/ParkRun_Ateme.mp4
http://jfl1974.free.fr/Sample/ParkRun_DivX7.mp4
http://jfl1974.free.fr/Sample/ParkRun_Mainconcept.mp4
http://jfl1974.free.fr/Sample/ParkRun_x264.mp4
http://jfl1974.free.fr/Sample/ParkRun_VC1MS.vc1

DivX7 AVC can potentialy produce exactly the same result than Mainconcept and certainely better with more recent build with more advanced HVS tools.

Little observation: Mainconcept SDK update stat file at each second pass. If you have problem with RC you can make Npass encoding.

[IgorC]

I'm downloading the videos. Can I ask you to upload video to another server in future? free.fr is very slow. Maybe mediafire.com