DivX H.264 Encoder Beta 2

[DigitAl56K]

http://labs.divx.com/files/icon_tk_h264.pngIn response to your feedback after our Beta 1 release we've been working on the DivX command-line H.264 encoder, and in the first of several updates we are introducing several popularly requested features. These include a target quality mode, support for flagging sample aspect ratio, and support for input via stdin.

Visit DivX Labs (http://labs.divx.com/node/11681) to get the download and find more information about Beta 2.

Complementing this encoder, we're also jointly releasing a beta AAC encoder today, check out the thread in the Audio Encoding (http://forum.doom9.org/showthread.php?p=1313721#post1313721) forum.

[Dark Shikari]

I'll try this encoder and add it to this test (http://x264dev.multimedia.cx/?p=102). Thanks!

Edit: or I would, if it didn't give me "access denied" when going to your link...

[DigitAl56K]

No access for you!

Okay okay, try again :)

[Dark Shikari]

No access for you!

Okay okay, try again :)Works great now! Thanks. Unfortunately now I realize I can't really do a fair test, because the keyframe interval range is only 1-4 seconds, while the test requires 10 seconds, and given the low motion, that'd probably hurt the results pretty badly.

(any plans to allow longer keyframe intervals?)

Edit: Nevermind, by changing the framerate to 60fps and encoding at 625kbps instead of 250kbps, I can cheat the keyframe interval up to 10 seconds ;)

[Dark Shikari]

Potential bug (in commandline parsing?). Output file is all I-frames:

Summary information:
Number of coded frames 5000
Total encoding time 159531 ms
Average time per frame 31.906 ms
Average speed achieved 31.3 fps
Average bitrate 1819514.21 kbit/sec @ 60.000 Hz

Commandline:

$ /c/Program\ Files/DivX/DivX\ H.264\ Codec\ CLI/bin/DivX264.exe -i maikaze.avs -aqo 2 -I -pyramid -bf 3 -br 625 -npass 1 -o divx.mp4

I notice that I messed up the commandline ("-I" with no arguments), but instead of erroring out, it chose a keyframe interval of zero?

[DigitAl56K]

Dark Shikari,

I was just thinking the same thing. The maximum IDR interval is limited to 4 seconds because we wanted to improve seeking for consumer electronics devices and through experimental testing our team found that this was a reasonable trade-off to make in terms of the impact on overall efficiency and navigation experience, so our encoder adheres to this recommendation.

P.S. Excellent! New bugs to log already ;)

[Dark Shikari]

And another bug (matches the previous report as well):

818365.54 kbit/sec @ 60.000 Hz

the output bitrate is off by exactly a factor of 1000, apparently. The output file itself is correct, of course.

[Dark Shikari]

And another bug: even at 60fps, -I 4 sets the keyframe interval to 96, which is actually 1.5 seconds, not 4 seconds.

[Chengbin]

Also, 60.000 Hz?? Shouldn't it be fps?

[DigitAl56K]

Thanks Dark Shikari, these all sound like issues with the parser, I'll file issues on all of them.

Chengbin: I think hz and fps are reasonably interchangeable in this context.

[Dark Shikari]

Also, remind your asm coders that pshuflw/punpcklqdq is faster than pshuflw/pshufd when splatting a value across a register ;)

[shon3i]

What encoder is behind AAC? or you made from scratch?

[DigitAl56K]

shon3i: The core comes from MainConcept who are now also part of DivX. The command-line version was jointly developed.

Let's try to keep the AAC encoder questions on the AAC encoder thread, otherwise the conversation gets hard to follow ;)

[LoRd_MuldeR]

x264 r1206 -vs- DivX264 Beta-2:
* Part 1: http://www.mediafire.com/file/gldmmqgznzm/x264-r1206-vs-DivX264-Beta2.7z
* Part 2: http://www.mediafire.com/file/zj2wjcmmid2/x264-r1206-vs-DivX264-Beta2.Part2.7z

HD and CIF samples. Anime and Film included. Both encoders configures for maximum quality (but no "placebo" settings).

[nakTT]

x264 r1206 -vs- DivX264 Beta-2:
http://www.mediafire.com/file/gldmmqgznzm/x264-r1206-vs-DivX264-Beta2.7z

HD and CIF samples. Both encoders maxed out.
Great. Downloading as we speak. Can't wait to see how far ahead of the curve x264 is compared to DivX Beta 2. Or should I say how close the DivX Beta 2 to x264.

[bob0r]

LOL @ DiVX:
x264 r1206 -vs- DivX264 Beta-2

cif_samples.divx.mkv, the red wall = one big brick, LOL!

[stax76]

@DigitAl56K

StaxRip is now destributed as big package including all used software. Applications with license that don't permit this will simply not be supported at all! Does your new encoders permit this and how big is the compressed file size of your cmdl tools?

[DigitAl56K]

LoRd_MuldeR: x264 with settings maxed out is using very different settings than divx264 with settings maxed out. I would expect to see differences, it's not a very fair comparison.

For example, as Dark Shikari pointed out divx264 is using max IDR interval of 4 seconds to improve navigation on CE devices, whereas you have 20 seconds. You haven't set any vbv parameters, we also limit refs by level 4 requirements and consecutive b-frames to 3 for broad device compatibility whereas you have used 8 (this version of the encoder is expecting to work mainly with HD btw, not CIF material). If you test x264 without similar constraints then of course you are likely to get a better result, potentially at the expense of some device interoperability later. Keep in mind that we always look to find an balance between efficiency and interoperability.

stax76: Interesting. I'll grab the latest StaxRip and take a look today. I'll see what I can work out :) The size of our tools compressed of course varies by compressor. 7-Zip will compress the AAC and H.264 encoders to about 528kb total using zip-compatible deflate.

[LoRd_MuldeR]

Added more samples:
http://forum.doom9.org/showpost.php?p=1313912&postcount=15

[LoRd_MuldeR]

LoRd_MuldeR: x264 with settings maxed out is using very different settings than divx264 with settings maxed out. I would expect to see differences, it's not a very fair comparison.

For example, as Dark Shikari pointed out divx264 is using max IDR interval of 4 seconds to improve navigation on CE devices, whereas you have 20 seconds. You haven't set any vbv parameters, we also limit refs by level 4 requirements and consecutive b-frames to 3 for broad device compatibility whereas you have used 8 (this version of the encoder is expecting to work mainly with HD btw, not CIF material). If you test x264 without similar constraints then of course you are likely to get a better result, potentially at the expense of some device interoperability later. Keep in mind that we always look to find an balance between efficiency and interoperability.

stax76: Interesting. I'll grab the latest StaxRip and take a look today. I'll see what I can work out :) The size of our tools compressed of course varies by compressor. 7-Zip will compress the AAC and H.264 encoders to about 528kb total using zip-compatible deflate.

Well, this was a test with "high quality" (but not "placebo") settings. That's what I actually use every day ;)

If your encoder has hardcoded limitations that can't be bypassed, there is nothing I can do. But it's certainly not "unfair", because you could offer more (and less restrictive) options.

IMO it would be unfair to force restrictions on other encoders - restrictions I don't have normally - just because yours does have these restrictions...

[DigitAl56K]

Let's at least recognize these differences when we do comparisons, otherwise we're comparing apples to oranges and declaring oranges as the clear winner ;)

[Dark Shikari]

Let's at least recognize these differences when we do comparisons, otherwise we're comparing apples to oranges and declaring oranges as the clear winner ;)But everyone does know that oranges beat the hell out of apples. No contest.


(And an encoder without adaptive quantization at all is unlikely to hold much water in any comparison.)

[DigitAl56K]

(And an encoder without adaptive quantization at all is unlikely to hold much water in any comparison.)

Don't worry, we hear you ;)

[nakTT]

IMO it would be unfair to force restrictions on other encoders, just because yours does have these restrictions...
Can't agree more. For end user like me, we only care about the quality of the output file. We don't really care which encoder has what limitation.

Perhaps DivX could provide a nonrestrictive version of their encoder for a retest.

x264 r1206 -vs- DivX264 Beta-2:
* Part 1: http://www.mediafire.com/file/gldmmqgznzm/x264-r1206-vs-DivX264-Beta2.7z
* Part 2: http://www.mediafire.com/file/zj2wjcmmid2/x264-r1206-vs-DivX264-Beta2.Part2.7z

HD and CIF samples. Anime and Film included. Both encoders maxed out.
I have one noob curiosity here. I can see that for parkrun under DivX, we have "original framerate" 50 and "framerate" 25? I also can see that this has reduced its bitrate by about half?

[LoRd_MuldeR]

I have one noob curiosity here. I can see that for parkrun under DivX, we have "original framerate" 50 and "framerate" 25? I also can see that this has reduced its bitrate by about half?

DivX produces a "raw" H.264 stream. When I muxed it into MKV then MKVToolnix assumed 25 fps (and I didn't care), instead of the original 50 fps.

But that's just a meta information on the container level, the content itself isn't effected at all. Both were encoded from identical AVS file...

Let's at least recognize these differences when we do comparisons, otherwise we're comparing apples to oranges and declaring oranges as the clear winner ;)

Yeah, this explains why the DivX encoder currently may have "problems" in this scenario. But it doesn't make the entire test unfair.

(I used the highest quality settings of DivX encoder I could find. If you have any tips on how to tune the DivX encoder better for this scenario, I'd be happy to use them :))

[DigitAl56K]

For end user like me, we only care about the quality of the output file.

Stop to think that many more people who end up with your content probably also (maybe even primarily) care about being able to move it around all of their media devices reliably. If you are unwilling to make any sacrifice then others are destined to experience frustration getting your content to play on device xyz.

We've tried to make reasonable sacrifices based on all of the devices we expect to see while also enabling high quality encoding. A simple solution to improving quality is to raise the bitrate a little. Now you get high quality, good efficiency, and less frustration downstream.

Dark Shikari is correct that AQ will also help when it becomes available :)

[smok3]

random thoughts/questions;
a. can i use weird sar values? 345:122 (extended sar)
b. is there a list of standalones that will support interlaced encodes? wdtv tested? (just courious)
c. for bluray i would type? (just a quick example please)
d. nice page about piping from ffmpeg
http://labs.divx.com/node/11681
e. who will get the next cake?

[Atak_Snajpera]

can I ask somebody to send me this encoder. I have no patience for registration! Why do i have to register? Wouldn't be simpler to just make it available for everyone?

[DigitAl56K]

It is available to everyone, maybe this is a misunderstanding. The registration is not moderated and is instantaneous. As soon as you register and click the link in the article to join the apps group you will land on the download page. It takes 60 seconds tops.

[juGGaKNot]

why no support for custom fps ? 35/40 fps

[Atak_Snajpera]

Football 1280x720@50fps
x264
--pass 2 --bitrate 1024 --stats "job1.stats" --min-keyint 50 --keyint 500 --ref 3 --bframes 3
--b-adapt 1 --direct auto --subme 7 --aq-mode 1 --trellis 1 --partitions all --me umh
http://www.mediafire.com/file/mjodjho2nmz/x264.mkv

DivX264
-br 1024 -aqo 2 -npass 2 -sf "Sample.dat"
http://www.mediafire.com/file/dfhmmon4ziy/divx264.mkv
Encoding time on Q6600@3Ghz
x264 - 2min (fast first pass)
DivX264 - 3min (slow first pass)

Highly optimized x264 with AQ+PsyRD+MBtree is light years ahead of rest :)

[Dark Shikari]

Why not just use presets instead of spamming some enormously long commandline?

[Atak_Snajpera]

Why not just use presets instead of spamming some enormously long commandline?
presets do not tell anything about settings used during encoding. Besides I don't use presets. Is this my fault that this forum cannot automatically warp text in CODE?

[Dark Shikari]

presets do not tell anything about settings used during encoding. Besides I don't use presets. Is this my fault that this forum cannot automatically warp text in CODE?I don't think it's fair for x264 to use bizarre commandlines that don't make sense from a speed-quality perspective, and I don't think it's fair for DivX to use long custom commandlines for x264 while DivX only has a single option to adjust speed-vs-quality.

[Atak_Snajpera]

happy now ? :)

[Yoshiyuki Blade]

A lot of those options are redundant since they're x264's defaults anyway :) I think a cleaner command line would look something like:

--pass 2 --bitrate 1024 --stats "job1.stats" --min-keyint 50 --keyint 500 --direct auto --partitions all --me umh

[DigitAl56K]

@Atak_Snajpera But still you are encoding with a much larger max IDR interval when you use x264. Can you link me to the source file?

[DigitAl56K]

random thoughts/questions;
a. can i use weird sar values? 345:122 (extended sar)
b. is there a list of standalones that will support interlaced encodes? wdtv tested? (just courious)
c. for bluray i would type? (just a quick example please)
d. nice page about piping from ffmpeg
http://labs.divx.com/node/11681
e. who will get the next cake?

Hey smok3, good questions.

a. For progressive content you can use any non-extended SAR, extended SAR is restricted because we want to ensure that all devices are able to scale reliably. This ought to cover most use cases, or introduce only a very small error/pre-adjustment. I'll update the DivX Labs article to include that information.

b. Any device that is certified DivX Plus HD will support the interlaced resolutions listed in the DivX Labs article.

c. The idea is not to encode for Blu-Ray, the idea is to encode for any device which will in future have a DivX Plus HD logo on it. That will include Blu-Ray devices, set-top boxes, digital TVs, consoles, PMPs, etc. This is why some of the encoder features are constrained, because we want content to be portable and work reliably everywhere.

d. Thanks :)

e. And who is bringing the beer?

[Atak_Snajpera]

@Atak_Snajpera But still you are encoding with a much larger max IDR interval when you use x264. Can you link me to the source file?
If your encoder does not allow larger values so that is your problem. I have simple rule. min keyint = fps , max keyint = fps*10.
http://x264.nl/h.264.samples/force.php?file=./premiere-paff.ts

[Brother John]

x264: »Here’s some rope to hang yourself with.«
DivX: »Get away from that rope!«
Myself, I’m feeling suicidal. ;)

DigitAl56K, could you shed some light on why DivX decided device-safe defaults wouldn’t be enough and hard restrictions are required? I mean, this is the CLI encoder that’s aimed at expert users anyway, isn’t ist? It seems to me those people will just not use DivX AVC at all if the rope is too short.

[Dark Shikari]

You are all being unfair to DivX; it is reasonable for them to place some restrictions on their encoder, given that they do intend to play these on standalone devices.

So, I did a real, fair test with both encoders under the same restrictions. Hopefully this ends this pointless, stupid debate over whether it's fair to compare codecs with two different keyframe intervals or whatever other BS.

Source: Premiere HD football, 1280x720 (I'll upload the lossless source if anyone asks).
Output files: Mediafire download (http://www.mediafire.com/?0t4ako0jyd5)
Methodology for frame chosen: I picked a random frame which was a P-frame in both encodes, in order to avoid comparing P to B or something equally unfair. Both P-frames were a significant distance from the previous I-frame, to avoid bias from higher quality propagating from the previous I-frame.

DivX settings:

for pass in 1 2;do -aqo 2 -npass $pass -pyramid -bf 3 -br 2000 -i input.avs -o DivX.h264;done
Total time: 7 minutes, 36 seconds.

x264 settings:

for pass in 1 2;do time x264 --preset veryslow input.avs -o x264.h264 --bitrate 2000 --keyint 100 --level 4.0 --pass $pass --bframes 3;done
Total time: 6 minutes, 55 seconds.

DivX:

http://img198.imageshack.us/img198/40/divx.png

x264:

http://img14.imageshack.us/img14/7379/x264.png

Same test at 1 megabit instead of 2 (output files (http://www.mediafire.com/?rfyzcyzgdjf)):

DivX:

http://img34.imageshack.us/img34/2233/divx2.png

x264:

http://img14.imageshack.us/img14/711/x2642.png

Game, set, match, DivX. The 1 megabit x264 beats the 2 megabit Divx.

[froggy1]

x264 one looks a lot better to me :D it seems the DivX one blurred too much

[neuron2]

Levels and/or colors are different!

[Dark Shikari]

Levels and/or colors are different!How is that even possible? I inputted from the same Avisynth script and took both of the output images using Elecard Streameye. If there's a level difference, it's a bug in DivX, not in my test.

Edit: I just checked, both output files have the exact same levels, what are you talking about?

(or are you saying that the levels are different from the source, but the same between the two output files?)

[neuron2]

Oops, never mind. It was caused by different positioning and thus viewing angle on my large LCD display.

[DigitAl56K]

I'd like to focus the conversation for a moment on what we're really trying to achieve with the DivX Plus HD encoder. To begin, I'll start by saying that we love the x264 project and the dedication of the community in developing solutions that improve the future of digital media. We're not trying to replace x264 or even to compete against it. I've said that many times over but it bears repeating since this always seems to be the immediate reaction whenever we release an encoder ;)

What we're trying to do is support content creation in a way in which media isn't just accessible to the person who encoded it on a desktop computer but also to hundreds or even thousands of non-technical end users who are ultimately likely to want to move the content off to their TV or mobile device in some way or another. This means that we have to recognize two goals: Good efficiency, but also very high compatibility.

It's easy to take the view that the best possible way to encode a video is to enable all of the best settings to achieve the greatest efficiency possible but sometimes there are other considerations to make. For example, Dark Shikari is familiar with tuning x264 for real-time encoding: You want to use the best possible settings but you also need to guarantee that the encoder will not fall behind while encoding multiple channels simultaneously. In short, you have to make some trade-offs and find the right balance to meet your goals. Our biggest goal is to help drive interoperability - to ask people to stop and consider the bigger picture. For example, "Do I want this file to push a PS3 to its limit, or do I want everyone to be able to watch this on any device without worry?" If your file looks looks perfect on the desktop but you take it to your friends place and it stutters periodically because you haven't used a VBV their player can handle are they going to be impressed with your work? If you have to advise some of your friends to spend 2 hours re-encoding for their specific device won't they find that frustrating? ;)

The DivX Plus HD H.264 encoder is designed to focus on making the trade-offs that we believe to be necessary to ensure a good experience on a very wide range of devices. For example, elsewhere in this forum there is discussion on how Blu-Ray devices are tested to support up to 3 bframes, and how files marked as level 4.1 may not be compatible with all Blu-Ray devices due to x264's current slicing implementation. We've even seen content marked as level 4.1 because people believe it will play better on a PS3 even though the PS3 plays level 4.0 content and the data rates in these files rarely tread into 4.1 territory. In reality, all that has happened is that compatibility with 4.0-capable devices has been reduced.

It's worth remembering that the encoder is in beta and its feature set, performance and quality are improving over time. For example, this encoder does not yet use the latest available core (although it was updated from the last beta), we're still tuning the -aqo modes, and features like adaptive quantization aren't included yet. But we're making it freely available to support creating content compatible with all future DivX Plus HD devices, and if you prefer you can already do the same with x264, so although it's interesting to compare encoders that's somewhat of a side-issue.

@Brother John: Some restrictions in the CLI encoder, like IDR interval, could potentially be relaxed to recommended defaults.

@neuron2: What is the viewing angle when you're nose-to-screen? ;)

[InsulinJunkie]

Oops, never mind. It was caused by different positioning and thus viewing angle on my large LCD display.

A TN screen strikes again! :)

[I should confess that I was reading this on my Samsung 26" monitor that's a TN screen, and I thought the same thing about colors on first glance as you did, until I scrolled and realized the cause]

[Zachs]

But why reinvent the wheel when you could take x264 and contribute to it such that it will have a mode (or modes) that is DivX Plus HD device compatible?

[DigitAl56K]

But why reinvent the wheel when you could take x264 and contribute to it such that it will have a mode (or modes) that is DivX Plus HD device compatible?

I would love to see modes in x264! :) I saw that performance presets are being added, if device presets/modes will also be supported this would be fantastic.

[Dark Shikari]

I would love to see modes in x264! :) I saw that performance presets are being added, if device presets/modes will also be supported this would be fantastic.Support in x264 already exists for DivX modes; you could trivially write a 10-line patch to add it as an option and release x264 instead of wasting time on an encoder that's under half the efficiency of x264.

But no, you have to validate your purchase of Mainconcept ;)

[DigitAl56K]

Previously you said you didn't want to have device targets in x264, is this changing?

I've discussed some of the reasons why we have an encoder here before, let's not go through this again unnecessarily.

But why the unfriendly tone? There is an odd phenomenon in this forum. Elsewhere it seems that new tools are fostered in a generally positive way, but when it comes to video encoders the opposite seems to happen, which is a shame.

[Dark Shikari]

Previously you said you didn't want to have device targets in x264, is this changing?I'm saying that you could have included x264 with the DivX pack and saved yourself a few dozen million dollars buying Mainconcept ;)

I'm not being unfriendly, but the unfriendly aura here is likely because people don't like those who peddle proprietary technology which is inferior to the open source version. If someone announced an MPEG-4 ASP encoder that was much worse than Xvid, I suspect the same results would occur

Additionally, I suspect people also dislike those who peddle inferior technology and don't admit it: for example, the person who recently announced the new H.264 decoder was not reacted to in the same way because they admitted it was very early in development and not very good yet. But DivX won't admit that their own product is weak, so people aren't willing to give it the benefit of the doubt for the future.

[R3Z]

Previously you said you didn't want to have device targets in x264, is this changing?

I've discussed some of the reasons why we have an encoder here before, let's not go through this again unnecessarily.

But why the unfriendly tone? There is an odd phenomenon in this forum. Elsewhere it seems that new tools are fostered in a generally positive way, but when it comes to video encoders the opposite seems to happen, which is a shame.

Not sure he is being unfriendly mate. Being a developer he knows the nitty gritty behind what it takes for good AVC implementation. I read it as Dark being thoroughly unimpressed with DivX's efforts.

To be honest there is no excuse for an encoder to give up quality just to make it idiot proof. With mainconcepts codebase (is that true?) it makes it even more hard to believe.

[DigitAl56K]

I'm saying that you could have included x264 with the DivX pack and saved yourself a few dozen million dollars buying Mainconcept ;)

This is a ridiculous discussion, I'm not going down that path :)

[Dark Shikari]

This is a ridiculous discussion, I'm not going down that path :)Come back when your encoder sucks less, and people will treat you better ;). This is a technical forum; we reward technical merit, not marketing ability.

Or, equally, admit that it's not very good and that you plan to improve it, and we'll accept that as well. Just don't try to make up for lack of technical merit with marketing.

[Zachs]

Exactly. Reinventing the wheel has always been frowned upon by the software community unless it's for educational purposes.

I'm just wondering what would be the logic for DivX not to use the money to hire Dark (or simply use your coders) to improve x264 but instead choosing to create another H264 encoder. I can't say for others, but I won't even be bothered to use DivX's H264 encoder even after reading your 'reason' behind creating yet another inferior H264 encoder.

To be honest, even until today, I find the DivX decoder for MPEG4 ASP to be completely buggy when playing back multiple video (some partially corrupted) streams in the same app. ffdshow on the other hand didn't exhibit the same problem. But that's another story for another day...

[benwaggoner]

The only ridiculous thing is the way that you've duped your own shareholders by paying their money for an inferior product and then lying about it to your own customers.
Well, I'm certainly happy Main Concept exists and licenses out their SDK. It's MUCH better than the QuickTime H.264 encoder, and can be easily included in commercial encoding tools without any GPL issues.

For products that would otherwise just wrap the QuickTime exporter, Main Concept is a big upgrade. I've gotten get darn good results out of it for the scenarios I've needed to use it for, some of which x264 and toolchains that implement it don't have as good workflow support.

Now, if I could use x264 in Carbon Coder with the Rhozet muxers...

[Dark Shikari]

Well, I'm certainly happy Main Concept exists and licenses out their SDK. It's MUCH better than the QuickTime H.264 encoder, and can be easily included in commercial encoding tools without any GPL issues.How would you like it if x264 was available for inclusion in commercial encoding tools without any GPL issues?

Because it's happening. More on this later.

[DigitAl56K]

Dark Shikari,

x264's AQ is helping at lower data rates. Our beta decoder does not include this feature yet - a fact I've acknowledge several times already.

We added various functionality that was asked of us during our last beta release. Instead of discussing these new features this thread has turned into x264 vs DivX, where usurping x264 is, as I continually point out, not our goal, and which is not helpful to progress at all. Now there are also accusations flying around.

Your encoder chart shows x264 ahead of all encoders, is everyone else equally unwelcome? Come on, this is not necessary.

[benwaggoner]

Because it's happening. More on this later.
I am intrigued.

Perhaps it's time for zambelli and I to finally do that "how to make a great Smooth Streaming H.264 encoder" white paper...

[TheResonator]

Agreed there is a serious problem with canonical profiles in H.264. How many to date?

There's the satellite TV profile with no slices, highly hierarchical B frames, 1 second IDR, extra large VBV, plus odd restrictions to modes that are known to break deployed first generation semiconductors.

On top of that, there's cable profile that adds horizontal resolution switching on the fly. Thank goodness intra slice refresh died.
.
Bluray wants 4 slices per frame.

There's the odd iPod baseline-minus.

Now we pushed through constrained baseline profile as an official profile.

Though I am happy to see Divx promoting H.264 and the MKV container, I hope the canonical profile they are pushing is at least a common set.
I understand what you are trying to do.

We simply failed with H.264 big time in reigning in the profiles.

There was just Main Profile in MPEG-2. (yes, plus extra-large VBV, intra slices, integer DCT, and repeated sequence headers :-)

[neuron2]

I've deleted two inflammatory posts and struck one of them.

Keep it civil and technical, guys.

[Dark Shikari]

I am intrigued.Contact me on IRC on Freenode if you're interested in more information. Let's get this thread back on topic.

[DigitAl56K]

@TheResonator: There certainly is a wide variety of quirky encoding profiles, we are trying to build on a common ground.

@stax76: How is -qf working for you?

[iwod]

How would you like it if x264 was available for inclusion in commercial encoding tools without any GPL issues?

Because it's happening. More on this later.

Care to share anything more?

[froggy1]

Care to share anything more?

Double-license ;)

[stax76]

@DigitAl56K

How is -qf working for you?

So far I didn't start coding on it, any news on the installer?

[popper]

...
There is an odd phenomenon in this forum. Elsewhere it seems that new tools are fostered in a generally positive way, but when it comes to video encoders the opposite seems to happen, which is a shame.

Agreed there is a serious problem with canonical profiles in H.264. How many to date?

There's the satellite TV profile with no slices, highly hierarchical B frames, 1 second IDR, extra large VBV, plus odd restrictions to modes that are known to break deployed first generation semiconductors.

On top of that, there's cable profile that adds horizontal resolution switching on the fly. Thank goodness intra slice refresh died.
.
Bluray wants 4 slices per frame.

There's the odd iPod baseline-minus.

Now we pushed through constrained baseline profile as an official profile.

Though I am happy to see Divx promoting H.264 and the MKV container, I hope the canonical profile they are pushing is at least a common set.
I understand what you are trying to do.

We simply failed with H.264 big time in reigning in the profiles.

There was just Main Profile in MPEG-2. (yes, plus extra-large VBV, intra slices, integer DCT, and repeated sequence headers :-)

@TheResonator: There certainly is a wide variety of quirky encoding profiles, we are trying to build on a common ground.



this will go OT but it is related:
from our consumer, long term POV looking at you as DivX Inc this is way more than a mere divx AVC Encoder.

DigitAl56K, i dont think there is a real problem from the mere AVC Encoder POV, we and virtually everyone that gets to hear about it in the future will continue to use x264, or an app that puts a wrapper around its libx264, as it Always does the right choice by always putting picture quality first, above speed (and yet it still manages to be speedy ) and you will sell your "common ground Profile" to the HW vendors.

the problem is
as you finally make your inevitable move to the the worlds universal AVC/H.264 codec, your setting your sights far to low in trying to push your already underpowered "common ground Profile" mkv as a generic option to these 3rd party video player hardware ASIC/FPGA PCB vendors....

yes we understand you seem to think you need to set it so low as there are already underpowered SOC chipsets inside some of these HW vendors obsolete kit,
but you have a real one time chance here..., to ask these vendors to take onboard a real sea change in all their generic hardware from the moment you sell them your "common ground Profile" this year?, forget about the existing lower BOM inspired obsolete kit and make them ALL use something werthwhile.

your currently outlined "common ground Profile" dosnt inspire confidence, and neather do your basic goals to only try and get the HW vendors to take mkv onboard without any real HW innovation thats sat on the ASIC/FPGA shelf already ,waiting to go inside a new low power PDA and above

give them incentives and make them all rally around a real current/near future upto a real H@L4.1 Fully capable SOC, build from that core, a micro PCB thats got as its base a 1 gig Ethernet,11n wireless and onboard 1 gig ram, and a fully fledged IPv6 Multicast firmware ready for any SD/HD streaming apps and codecs you care to use, and make long term profits from later, nows the time for a clear brake from the past, no more PR innovation, we want REAL mass produced Innovation and a good base H@L4.1 SOC and generic inter connected IP network streaming at the heart of it....

the BOM is always an issue for these HW vendors OC, but once in a while they need convincing to start again, and take the one time hit to introduce something really werthwhile and good for long term profits, thats were you and Divx Inc can help, set your "common ground" far higher this one time and really push the H@L4.1,AAC 5.1,gigE,11n,HDMI and GOOD 2 way interactive middeware (see Carl Sassenrath, CTO REBOL Technologies and lead programmer of Amiga OS rebol http://musiclessonz.com/rebol.html http://www.rebol.net/cgi-bin/r3blog.r )

"we are trying to build on a common ground."

we, or at least i, ask that you build your 'common ground' from and for todays far better (and tomorrows) potential SOC/FPGA/ASIC capabilitys, not from yesturdays antiquated first try offerings, already in the world bargain basement End of Life bins the PR sales teams are getting big bonuses for actually managing to shift them onto the unsuspecting OEMs and consumers, rather than be binned were they belong, they are NO retro Amiga Hardware or AAA class ex Amiga HW/OS or even ex Amiga "MainActor" micro app coders after all.

regarding your "Elsewhere it seems that new tools are fostered in a generally positive way"
that is true here too,as will become clear as you finally start to settle in to Doom9, it takes a while though, perhaps you could also look into making these "new tools" for the likes of the newest DVB pdf's online here,
http://www.dvb.org/technology/fact_sheets/index.xml

we could do with some innovative DVB GEM, DVB GSE, IPDC,PCF handling, manipulation and re/Muxing related tools etc in the End user and semi pro market place ASAP for instance.

and id still like to actually see a simple tool with a way to put AVC CIF sized PIP 'Picture In Picture' inside and over layed ontop of an existing encoded HD AVC/AAC TS transport stream/file, so we can one day use VLC or other upgraded streaming AVC/AAC server tool to stream these two data streams, and watch eather with a simple button press on your "common ground" 3rd party streaming hardware.

ohh but these vendors wont be including that capability in their up and coming 'common ground' PDA's, STBs and the like will they...

or even something as simple as be able to put a modifyed URL in to our STB's generic browsers, current BBC Iplayer style, and be taken directly to whatever section of the video timeline we have been given the URL to.

[Chengbin]

I have to agree with popper.

Look at what happened to the iPod's video decoding capabilities. It has maintained at the baseline H.264 level for YEARS, not to mention their absurdly low maximum bitrate of 1500Kbps.

I really hate it when the bar to something is set so low, once adopted, people are just unwilling to change.

[Sulik]

There are usually good reasons for some of these restrictions - would you be willing to pay 2x for your iPod, or have half the battery life as tradeoffs for being able to support some slightly more advanced feature that gets you 10% better quality at the same bitrate or a 3Mbps bitrate support ?

[popper]

There are usually good reasons for some of these restrictions - would you be willing to pay 2x for your iPod, or have half the battery life as tradeoffs for being able to support some slightly more advanced feature that gets you 10% better quality at the same bitrate or a 3Mbps bitrate support ?

Yes.
and it's realisticly FAR more than 10% better quality at a real H@L4.1 than what you have now in the ipod.

the reasons simple enough, if the likes of the Ipod or the other newest Atom 330 dual core processor or even the ARM NEON SOC devices , netbooks, STB's and above actually are made capable of Decoding UPTO this H@L4.1 with a generic ASIC SOC then all the other vendors following will have no choice but to do exactly the same or better (not werse), they have no real choice if they want to keep to the BOM (bill of materials, and the reason for your not really good restrictions, hence my sea change remark above).

as these OEM and other 3rd partys realisicly only use the same or near copys of the generic reference board the Ipod and its like have made in the far east foundries initially, and rebrand and repackage it to look different anyway, the core PCBs and SOC are nearly always the same basic ref board at heart.

make that initial reference SOC/PCB actually have the limited H@L4.1,gigE,11n,hdmi spec outlined above and you eventually get to the mass scale and all the prices fall as a natural result of refactoring for the scale...

on top of that, you get the battery vendors re-packaging for a higher rated power package in a smaller size,and process shinkage to get more in less, plus higher intigration of the SOC around this base 'common ground' package, everyone wins in the long term IF you set the New 'common ground' high enough to begin with.

lets NOT forget there already exists at least one low power AVC ASIC SOC thats got a full H@L4.1 upto 1080p decoder capability AND it also Encodes in realtime too so you cant say it cant be done, it is being done.... im trying to find the exact url again i posted a long while ago now, with its spec, it was made for the mass mobile phones markets i seem to remember.

and all this is before you even consider the ISP, STB vendors etc putting up 12 month tie-in contracts and supplimenting the real price of the HW to get it lower for you, so the 'pay 2x for your iPod/whatever' isnt really valid after the initial 3 months into release in todays world market place anyway.

[CruNcher]

There are usually good reasons for some of these restrictions - would you be willing to pay 2x for your iPod, or have half the battery life as tradeoffs for being able to support some slightly more advanced feature that gets you 10% better quality at the same bitrate or a 3Mbps bitrate support ?

For Devices like the Ipod and all small display mobile Devices it is true, but we are now coming in the AVC Device Generation where we have mobile HD available via HDMI output to a HD Ready Device and there having only Main Profile available is something to think about, especially if you see that Micrsoft is pushing forward with it's Advanced Profile on those Devices and we gonna see how that endsup in the Zune HD vs the AVC Main Profile part on the big Screen :(

[benwaggoner]

There are usually good reasons for some of these restrictions - would you be willing to pay 2x for your iPod, or have half the battery life as tradeoffs for being able to support some slightly more advanced feature that gets you 10% better quality at the same bitrate or a 3Mbps bitrate support ?
Better than that would be useless for the iPod itself, as the highest resolution one is 480x320 with a not-that-great LCD display, and a pretty lousy analog video output.

On a good 640x480 display, 640x480 can look better than an iPod encoded file, but that's not on the iPod.

Also, note that 1500 is only the max when using multiref. You can go up to 2500 Kbps with 1 ref IIRC.

[popper]

its a shame these Sanyo 1920x1080 7.1 inches LCDs/TFT designed and optimized for mobile devices didnt take off way back in Oct 17 2006 :)
http://gizmodo.com/gadgets/gadgets/sanyo-develops-smallest-hd-display-71-inches-208080.php

im not so sure the 2.6 inch display which supports XGA resolution (1024 x 768) primarily for use in mobile phones was good enough though unless you want some serious eye treatments
http://www.newlaunches.com/archives/sanyo_develops_the_smallest_full_hd_display.php

[CruNcher]

Btw instead of people still comparing DivX Encoder vs X264 which slowly should be clear is still nonsense people should rather compare Nero Recode vs DivX Encoder Beta 2 as that will be their Competition ;) and im sure Nero is going sooner or later to get the new Encoder Core 3 from Ateme to show DivX Mainconcept what Quality means ;)

Nero Ateme (Nero Recode)
DivX Mainconcept (DivX Encoder Beta 2)

DivX of course has better cards currently promoting MKV and actively supporting it though it would be rather easy for Nero to adapt to this strategy within their NeroDigital AVC HD Profiles (which are longer established then DivX Plus HD), lets see what happens :)

Tough for most consumers it makes no difference as virtualy both of these Ecosystems aren't needed anymore :P

[Sagittaire]

Not a big surprise, DivX use Mainconcept encoder without grain optimisation and AQ. DivX use really surprising and limited profil for this good encoder. I don't understand this beta test. I have here really better CLI encoder from mainconcept ... since november 2006 ... ???



You are all being unfair to DivX; it is reasonable for them to place some restrictions on their encoder, given that they do intend to play these on standalone devices.

So, I did a real, fair test with both encoders under the same restrictions. Hopefully this ends this pointless, stupid debate over whether it's fair to compare codecs with two different keyframe intervals or whatever other BS.

Source: Premiere HD football, 1280x720 (I'll upload the lossless source if anyone asks).
Output files: Mediafire download (http://www.mediafire.com/?0t4ako0jyd5)
Methodology for frame chosen: I picked a random frame which was a P-frame in both encodes, in order to avoid comparing P to B or something equally unfair. Both P-frames were a significant distance from the previous I-frame, to avoid bias from higher quality propagating from the previous I-frame.

DivX settings:

for pass in 1 2;do -aqo 2 -npass $pass -pyramid -bf 3 -br 2000 -i input.avs -o DivX.h264;done
Total time: 7 minutes, 36 seconds.

x264 settings:

for pass in 1 2;do time x264 --preset veryslow input.avs -o x264.h264 --bitrate 2000 --keyint 100 --level 4.0 --pass $pass --bframes 3;done
Total time: 6 minutes, 55 seconds.

DivX:

http://img198.imageshack.us/img198/40/divx.png

x264:

http://img14.imageshack.us/img14/7379/x264.png

Same test at 1 megabit instead of 2 (output files (http://www.mediafire.com/?rfyzcyzgdjf)):

DivX:

http://img34.imageshack.us/img34/2233/divx2.png

x264:

http://img14.imageshack.us/img14/711/x2642.png

Game, set, match, DivX. The 1 megabit x264 beats the 2 megabit Divx.

[Betsy25]

I agree that DivX should go for quality, If you're going for the commercial viewpoint and keep it "compatible" for low end gadgets like the iPod and stuff, you're doing it wrong.

It are the (cheap) gadget producers that need to keep up with the standards, not the other way around.

[fields_g]

It seems that DivX is more interested in developing a specification for interoperable devices than an encoder. That's fine. The problem is that they are developing for time period still in the future, but are hindering themselves with compatibility with ALREADY developed/dated/crippled devices.

It's a great idea to do have some preexisting device compatibility, but since devices come and go, while this specification should be longer term, please be selective of what you really should hold as a baseline. You build customers and the DivX reputation with wise decisions.

I just hope too many irreversible decisions haven't been made yet.

[CruNcher]

Not a big problem you still can buy a Device without the DivX or Nero logo on them and it will still do great (you just have to know which chip is inside) and this is also no problem these days (search on the net) and most Standalone chips easily support High Profile Level 4.1 we aren't in the ASP times anymore luckily (where you had everywhere on the Device package and Advertising the nice * "Qpel and 3 point GMC not supported" info ;)
We are now @ the 100 € mark for AVC High Profile Level 4.1 Standalones that already support MKV (why should those manufactures pay for DivX Certification only because Hollywood is supporting them now a little and because they try to frighten people with the "Have access to millions of content or not words from our beloved Mr Hell" ?) and soon will hit the 80 € as back then with ASP this time without DivX or Neros Certification stuff needed @ all.
Then soon the first Mobile HD Devices will enter the market (unfortunately first only with 720p H.264 BP + B-frames (which actually means Main Profile without CABAC) L3.1 and VC-1 AP L2 support first will be Microsofts Zune HD http://www.zune.net/en-us/mp3players/zunehd/default.htm thx to Nvidias Tegra and a lot of Quartics Netbooks are also to come)

@Sagittaire
They working on AQ as we speak though im surprised it wasn't ready for beta 2 as that was requested already when Beta 1 hit from most users

PS: Theoretical X264 Baseline + B-frames (no CABAC) should be able to beat VC-1 AP on the Zune HD HDMI out, though i doub't Microsofts Win7 Encoder will be able to beat their VC-1 AP Encoder on the Zune HD HDMI out (which by the way you need to purchase a extra docking station for some extra cash no direct plugin possible) ;) :)

[popper]

Not a big problem you still can buy a Device without the DivX or Nero logo on them and it will still do great (you just have to know which chip is inside) and this is also no problem these days (search on the net) and most Standalone chips easily support High Profile Level 4.1

we aren't in the ASP times anymore luckily (where you had everywhere on the Device package and Advertising the nice * "Qpel and 3 point GMC not supported" info ;)

We are now @ the 100 € mark for AVC High Profile Level 4.1 Standalones that already support MKV (why should those manufactures pay for DivX Certification only because Hollywood is supporting them now a little

and because they try to frighten people with the "Have access to millions of content or not words from our beloved Mr Hell" ?)

and soon will hit the 80 € as back then with ASP this time without DivX or Neros Certification stuff needed @ all.

Then soon the first Mobile HD Devices will enter the market (unfortunately first only with 720p H.264 BP + B-frames (which actually means Main Profile without CABAC) L3.1 and VC-1 AP L2 support first will be Microsofts Zune HD

http://www.zune.net/en-us/mp3players/zunehd/default.htm

thx to Nvidias Tegra and a lot of Quartics Netbooks are also to come)

@Sagittaire
They working on AQ as we speak though im surprised it wasn't ready for beta 2 as that was requested already when Beta 1 hit from most users

PS: Theoretical X264 Baseline + B-frames (no CABAC) should be able to beat VC-1 AP on the Zune HD HDMI out, though i doub't Microsofts Win7 Encoder will be able to beat their VC-1 AP Encoder on the Zune HD HDMI out (which by the way you need to purchase a extra docking station for some extra cash no direct plugin possible) ;) :)

this is part of the problem i outline above with DigitAl56K's/Divx Inc's outlined "common ground Profile" to the HW vendors.

its as though they are at least 2 years+ Behind even the current curve of HW SOC (system On a Chip)already sat on the ASIC/FPGA shelves ready for the OEM's to use Today, weather thats intentionally so, or bad timeing, and miss 'PR Inovation' 'penny pincher' has been put in charge of looking to maximise investor income for the next quarters takings iv no idea.

i do think the people in charge of the MS BOM spec numbers need looking at again though, they would be making a very big long term mistake to not include the HDMI as the generic base today in everything, adding such a vital H@L4.1 digital display output as an add-on will just limit its viability to end users in the mid term, never mind the longer term...and hence lower the long tail profits.

http://en.wikipedia.org/wiki/Zune_HD#Specifications
it doesnt say what Tegra they are using, but again nothing but the Tegra 650
http://en.wikipedia.org/wiki/Nvidia_Tegra#Tegra_650
seems like a long term viable plan as your initial existing base plan today....

apparently they are using a 3.3 inch OLED display capacitive touch screen (480x272 16:9 resolution) why didnt the basic BOM (bill of materials) not include a current 3,3 or the better 4.0+ of a real XGA resolution (1024 x 768) as per #74 Instead today im not sure, especially coming from MS looking to better others offerings PR from the outset you would have thought.

as for the full H@L4.1 SOC i mentioned above, this is Not the one i was talking about, but even this POWERVR VXE360 seems like a far more viable thing to use if your starting your new product line PCB today.

http://www.imgtec.com/news/Release/index.asp?NewsID=440
"...including H.264 High Profile (HP), at SD and HD resolutions respectively. "
"VXE360 support H.264 High Profile encoding, offering improved video quality at lower bitrates. Features such as B-frames and CABAC encoding enable the consumer to record and transmit video at the highest possible quality..."
http://imaginationtec.org/Newsletters/with_imagination/issue3_09.pdf

and it just happens to include the OpenMAX IL compliant API, under Linux.
http://www.khronos.org/openmax/
part of which went to OpenMAX AL 1.0 in july so again a current "common ground Profile" to build From.

when you consider any part of these Existing current options Today, it really makes DigitAl56K's/Divx Inc's currently outlined "common ground Profile" to the HW vendors, look really weak and Outdated Already.

and its not as if these options were even any secret even way back when the first "common ground Profile" or its first iteration of the Divx7 AVC encoder were aired here If you as an end user Bothered to look....so clearly its been known a Lot longer in the circles were Divx and the HW vendors hang out.

[CruNcher]

Zune HD uses the APX 2600

Tegra APX 2600

* Processor and Memory Subsystem
o ARM11 MPCore
o 32-bit LP-DDR
o Enhanced NAND Flash support
* HD AVP (High Definition Audio Video Processor)
o 720p H.264 Baseline Profile Encode or Decode
o 720p VC-1/WMV9 Advanced Profile Decode
o D1 MPEG-4 Simple Profile Encode or Decode
o Supports multi-standard audio formats, including AAC, AMR, WMA, and MP3
o JPEG Encode and Decode acceleration
* ULP NVIDIA GPU
o OpenGL ES 2.0
o Programmable Pixel Shader
o Programmable Vertex and Lighting
o Advanced 2D Graphics
* Imaging
o Up to 12 megapixel camera sensor support
o Integrated ISP
o Advanced imaging features
* Display Subsystem
o True dual-display support
o 720p (1280x720) HDMI 1.3 support
o FWVGA (864x480) LCD and SXGA (1280x1024) CRT support
o Composite and S-Video TV output
* Peripherals
o USB 2.0 OTG, USB 2.0 ULPI, HDMI, MIPI CSI/DSI/HSI, UART, SPI, SDIO, I2C, I2S

Bold are the differences to the APX 2500

And it's easy to say why ;) because it supports VC-1 AP the difference to the 2500 is not only the Enhanced Flash also the 2500 supports only Simple and Main Profile for VC-1 ;) and surely Microsoft want's to play the AP card vs H.264 Baseline here and also show that they Designed into the right direction being less complex but it will be interesting to show the world how x264 Baseline is gonna squash VC-1 AP on their own Product ;)

Fact is that a hell a lot of available VC-1 content will be able to playback on the Zune HD without even the need to transcode it, the big opposite gonna happen for H.264 as users will gonna have to transcode over and over in that regard for the Zune HD (which lowers the user confidence level and experience with H.264 and makes Microsoft very happy and ofcourse they even provide the low quality tools in Win7 to make this easy for the user to see a blurry H.264 result on the HDMI out and then when they try VC-1 AP they gonna "WOW" ;) ), except if they always used Apples Quicktime H.264 way of Encoding (or only want to consume the Apple Trailers) their content and somehow for the majority of people here on doom9 i doubt that ;)

Somehow this shows again that Cabac seems to be the major problem also for Nvidias current Decoder trying to preserve power at all costs as Huang said that was the Design Philosophy from Day 1, though Sony even made CABAC a necessary thing for their PSP Media Engine (480p though, or should we say imagination as that's the Core they licensed at least the 3D part who knows maybe the H.264 Decoder is also from them) in the beginning and it was quiet capable of handling that (can't wait to see Sonys new Media Engine Mobile H.264 HD Decoder (imaginations ?) in action in any PMP Device). For sure the next Tegra Generation is gonna also support it and High Profile, though it is nowhere stated explicitly in their Specs or Roadmap currently.

Lets wait and see what the APX 2600 really supports and eats, of course if Microsoft Engineers try to prevent any out of Spec use via restrictive Firmware checking this wont be possible @ all ;)

[Chengbin]

I know that a couple of Chinese PMPs are capable of decoding very high bitrate 720p H.264 @ main profile. I have a friend (who is also in the business of video creation/compressionist, and very knowledgable in x264/avisynth). He said it was capable of playing the 720p H.264 video @ main profile @ 5Mbps without any lag (he can detect anything wrong with the video as long as it stays on the screen for more than 0.2 seconds). I'm waiting for the bitrate viewer screenshot from him to look at maximum bitrate in his video.

There is another Chinese PMP touting its ability to play high profile H.264 @ 720p in its ads. I'm waiting for that to be verified by another friend when he receives it and plays the sample video I carefully chose and encoded to test decoding capability (bitrate from 3Mbps progressively to 13Mbps at 1Mbps increments). It uses a Rockchip RK2806.

Unforunately the most powerful PMP available in North America is the Archos 5. Which can only decode H.264 at 720x576 @ main profile @ 4Mbps. 1280x720 for XviD, VC1, DivX @ 7Mbps unrestricted settings (main profile for VC1). This uses a DaVinci chipset with ARM Cortex A8.

All I'm saying is, 720p H.264 decoding on a portable device is doable now. I'm sure it will be even better soon. I'm sure it will be available in North American markets soon (Zune HD being a good step forward, hopefully the new Archos announced in September will be another one too) That's why I agree with popper's statement of letting hardware catch up, and why I mentioned the near zero decoding capabilily of the iPod.

[CruNcher]

Chengbin sure it's possible but the main question is the power output needed and so the battery life and how small you can design it by that :) i saw the pictures of the Chinese PMP on engadet or akihabaranews http://www.akihabaranews.com/en/news-tags-PMP.html i think it looked interesting but it seemed more to be a 3d concept and it's rather big compared to the Zune HD China has nice products but what's inside working is the interesting part and mostly no site reports about that it's rather hard to find the good Enginered ones without testing them ;)

Would be nice if you keep us informed about the PMP tests you and your friend are currently conducting and the results of those is it this one ? http://www.teclast.com/zhuanti/c500hd/ :)

[Chengbin]

Chengbin sure it's possible but the main question is the power output needed and so the battery life and how small you can design it by that :) i saw the pictures of the Chinese PMP on engadet i think it looked interesting but it seemed more to be a 3d concept and it's rather big compared to the Zune HD :)

Battery life shouldn't be what you should be worrying about. My Archos 5 can last more than 4 hours playing 1Mbps H.264 videos with a 5'' screen at maximum brightness and that juicy processor with its 2600mAh battery.

I'm worried about the heat. The large hard drive, big screen, and the chipset. My 5 can get warm playing videos for extended times.

EDIT: I just saw the Zune HD's video capabilities, which makes no sense.

WMV - Main and Simple Profile, CBR or VBR, up to 10.0 Mbps peak video bit rate; 720 pixels x 480 pixels up to 30 frames per second (or 720 pixels x 576 pixels up to 25 frames per second). Advanced Profile up to L2, 1280x720 up to 30 frames per second, CBR or VBR, up to 14.0 Mbps peak video bitrate.

MPEG-4 (MP4/M4V) (.mp4) Part 2 video – Simple Profile up to 4.0 Mbps peak video bit rate; 720 pixels x 480 pixels up to 30 frames per second (or 720 pixels x 576 pixels up to 25 frames per second).

H.264 video – Baseline Profile + bframes, up to 10 Mbps peak video bit rate; 720 pixels x 480 pixels up to 30 frames per second (or 720 pixels x 576 pixels up to 25 frames per second). 1280x720 up to 30 frames per second, up to Level 3.1 and 14.0 Mbps peak video bitrate.

How can you support a lower maximum bitrate on a lower resolution video file?????

I'm impressed with the Zune's decoding capabilities. I'm amazed that it can decode H.264 (even though it is baseline) @ 720p with maximum bitrate of 14Mbps.

[CruNcher]

Yep and that @ roughly 200 Mv according to Nvidia :)

here the c500HD in action via HDMI out :) (no expensive extra docking station needed)
http://video.3conline.com/pconline/videocenter/interior/2009/08/10/E582775977E0A5F9.mp4

I wonder why did you buy a Archos 5 it was foreseeable from the beagleboard development that it couldn't deliver the power for becoming a good HD PMP

The C500HD looks not bad but what is inside (price in $ on that picture is heavy compared to the Zune HD) :D

http://img2.zol.com.cn/product/34/67/ceXx1VjGtF5jg.jpg

[popper]

the the "APX 2600" is the "Tegra 600" apparently, dont you just love the 'PR innovators' that cant even use the generic name and have to reinvent it all the time to justify their wage..
http://news.cnet.com/8301-13924_3-10157562-64.html

regarding the power envelope of such devices, it seems my initial thought of the UK based imagination/POWER-VR SOC cores are infact licensed and used everywere in the PMP world markets, and has the best power envelope around, and as for the Tegra "Nvidia's goal is to pack as much processing punch as possible into a few-hundred-milliwatt power envelope"

i cant seem to find any independent power studies regarding 'B-frames and CABAC' V 'not B-frames and CABAC' decoding use on any of these common low power cores, but iv not really looked that hard, so i cant even say if an Encoder vendor might claim a slight 'power envelope' win there for not including it.

its all academic anyway, as i already said,the battery vendors repackage all the time and coin in if theres a power shortage in a given design coming to market or already here and in need of something better than the generic supplyed power cell.

theres always the after market voltaic production lines too that are always looking to sell you an addon to extend the battery life, and their getting better at it as time passes.

its a shame theres still no universal fitting mass market rechargeable 'distilled water' PEM hygrogen cells out there yet, outside the low volume educational markets http://www.h-tec.com/html/web/weiche/index_en.asp

[Chengbin]

I wonder why did you buy a Archos 5 it was foreseeable from the beagleboard development that it couldn't deliver the power for becoming a good HD PMP

I bought the Archos 5 because

1. It had the best screen I've ever seen on a portable device (despite having quite inaccurate reds)

2. It had the biggest hard drive available on any portable device (250GB)

3. It has Wi-Fi, and it is paired with a nice, big, high resolution screen, coupled with the fastest loading page times for a non intel powered device (amazingly scrolling lags ridiculously bad)

4. It had the most advanced video decoding support by a very clear mile.

5. I could buy it in a local store, and it isn't ridiculously expensive ($500) like the Viliv S5.

6. I really needed an upgrade from the Archos 404

I didn't buy it for HD playback, I bought it because I stay in the subway for an hour every weekday, and needed a PMP.

[CruNcher]

I found out more about these Chinese PMP they use a Chip called ehehe RockChip (actually the RK2806 no specs found yet) it seems to have alot of power compared to Texas Instruments Davinci Chip that's also working in the Archos and these PMPs are relatively Cheap for the power they pack inside the $620 is definitely wrong

http://www.youtube.com/watch?v=Go_zQ68CPwo nice hopefully some try to find out how many power this chip consumes :)

[creamyhorror]

I found out more about these Chinese PMP they use a Chip called ehehe RockChip (actually the RK2806 no specs found yet) it seems to have alot of power compared to Texas Instruments Davinci Chip that's also working in the Archos and these PMPs are relatively Cheap for the power they pack inside the $620 is definitely wrong

The online price is about US$68 in China, going by a few websites. Don't know where that picture came from. Rockchips seem commonly used in many Chinese players.

[neuron2]

Let's stay on topic, guys. This thread is about the DivX encoder beta.

[CruNcher]

Sorry Donald gonna gather some more solid information and make a new Hardware thread about these Mobile HD PMPs and their Chipsets :)

[Kurtnoise]

@DigitAl56K : do all default settings certify DivXHD Plus profile ? If not, do we need to tweak some of them to have it ? (I'm not talking about fps, max/min width & height but more B-Frames # , ref Frames, etc...)

[LigH]

Finally ... sorry for the delay:

WhisX2 - making Rémoulade again! (http://www.ligh.de/software/WhisX2.exe)

Please note a few limitations:

- The DivX H.264 Encoder Beta 2 does not create a Registry entry anymore about where the executable is located. If you updated from Beta 1, this entry may still exist, so WhisX2 may find it if you updated to Beta 2 with the same directory.

- WhisX2 will try to load a default configuration from a *.ini file with the same file name as its own executable. It will look for a section [WhisX2] first, then for a section [WhisX]. So you may copy a previous default configuration and update it by saving and overwriting.

- WhisX2 will not support STDIN source in raw format, and therefore not the manual input dimension option (-y) either.

[WorBry]

Here's a strange thing (or not?).

Just tried out DivX H264 encoder beta 2 using the new WhisX2 GUI. I was interested in comparing the relative efficiencies of MBAFF and PAFF encoding of my interlaced (PAL DV) sources. Weird thing is that the PAFF (i.e. macroblock adaptive off) encodes (muxed to mkv) playback at half normal speed. Had to reset the frame rate to 50fps using MKVMerge to get them to play at normal speed.

Is this a normal feature of PAFF or a bug??

Observed the same result with both the DivX H264 decoder and Core AVC decoder, so I'm inclined to think this is not a decoder specific phenomenon.

Edit: Hmmm....on further testing it appears the raw H.264 encodes actually playback normally (at least with DGAVCIndex), but when muxed to mp4 they also playback at half speed, so I guess this must be some container quirk?

[DigitAl56K]

LigH: Thanks for this update! We've been looking at it today. I'm not sure where we lost the installer code that wrote the registry entry but I'll log an issue so that we fix that.

WorBry: That's interesting, I will check out the frame rate issue tomorrow.

[WorBry]

Another weird thing about the mp4-muxed PAFF encodes is that, with the DivX H264 decoder and DivX player, they also playback with a back-and-to jitter, as if the field order (BFF) is being misread. With Core Media Player and MediaPlayerClassic, there is no jitter, the mp4 files just playback slowly.

BTW - I used YAMB for the mp4 muxing.

[WorBry]

WorBry: That's interesting, I will check out the frame rate issue tomorrow.

So, did you reach any conclusions?

[ricardo.santos]

Hi everyone

been doing some tests with the GUI....it accepts avisynth scripts but im unable to encode with resolutions below 640 or with a framerate of 23.976

I selected a higher resolution and 25FPS and i got a .264 file, can i mux the .264 and the aac with a regular mkv muxer...or do we need a divxMkv muxer?

i wanted to test the divx web player...any advice on the muxing side?

Thanks

[DigitAl56K]

WorBry:

I looked at the output of MKVMerge (2.9.8) and MP4Box (0.4.6 Dev Build 1). In the case of PAFF streams both seem to be interpret field pictures as frames causing them to believe the content is twice as long as it actually is and in the case of MKVMerge giving each field picture a timecode as if it were a frame.

You could double the frame rate to work around (most) of the issues but your best bet is to stick with MBAFF. Maybe Mosu and Kurtnoise could consider user-flagging/detecting PAFF in future builds.

[DigitAl56K]

ricardo.santos,

For DivX Plus Web Player (beta) (http://labs.divx.com/node/14711) mux your file as you normally would, keeping these things in mind:

* The web player is nice in that it lets viewers save the videos they watch and therefore enables them to be played later on DivX Plus devices. To make sure this works smoothly end-to-end you can either use our sample encoder (e.g. with WhisX2) or follow some simple guidelines (http://developer.divx.com/docs/divx_plus_hd/Creation_with_x264) if you want to use x264.

* The web player has out-of-the-box support for AAC audio (up to 5.1 surround) so if you're creating MKV files for it make sure your audio is in this format for the best experience. If you use the AAC HE modes make sure to flag this explicitly on the MKVMerge command line (i.e. --aac-is-sbr 0:1, where "0" is the track ID in the input file identified by MKVMerge -i <infile>).

* Set the frame rate on the MKVMerge command line (e.g. --default-duration 0:24000/1001fps). If at all possible use one of the recommended rates. There's a table on the page linked above.

[WorBry]

I looked at the output of MKVMerge (2.9.8) and MP4Box (0.4.6 Dev Build 1). In the case of PAFF streams both seem to be interpret field pictures as frames causing them to believe the content is twice as long as it actually is and in the case of MKVMerge giving each field picture a timecode as if it were a frame.

OK, thanks for the explanation. Seems logical.

You could double the frame rate to work around (most) of the issues but your best bet is to stick with MBAFF.

Well, PAFF frame-rate quirk aside, I'd pretty much come to that conclusion. This said, from my comparative tests, I'm afraid I dont find any compelling reason, at this time, to change from x264 despite it's sub-optimal MBAFF implementation (i.e. not being truly macroblock adaptive).

[seemees]

To Divx developers
HW MUST go ready to decode high and unrestricted levels of AVC, and all old HW devices without x264 support will be blow out from market. Is the CD-players push VHS?
Is the DVD players push CD and VHS? Is the LCD push ELT? Yes. Old and BAD HW devices don't need us. Please stop support for old and ugly devices. Set high level of
request to NEW devices and HW developers.
All we need - is BEST, QUALITY, FUSY, FAST (may be hardware and realtime or FASTER) encoder for x264 and divx264 (if you want).
But quality, quality and once more quality - MAXIMUM quality we need.
With best regards, seemees

[WorBry]

BTW - It appears that the DivX H264 encoder PAFF is not actually 'adaptive'.

Tested a number of interlaced clips including completely static sequences and some re-encoded reference PAFF samples; in all cases DGAVCIndex reports the Frame Structure as Fields(TFF) for all frames. If truly adaptive, one would expect that the static sequences would be encoded all as Frames, and with mixed content that there would be a mix of Field and Frame encoded frames (as there was in the original reference PAFF samples).

Leads me to wonder whether it is certain that the MBAFF is truly 'macroblock adaptive'?

[Dark Shikari]

BTW - It appears that the DivX H264 encoder PAFF is not actually 'adaptive'.

Tested a number of interlaced clips including completely static sequences and some re-encoded reference PAFF samples; in all cases DGAVCIndex reports the Frame Type as Fields(TFF) for all frames. If truly adaptive, one would expect that the static sequences would be encoded all as Frames, and with mixed content that there would be a mix of Field and Frame encoded frames (as there was in the original reference PAFF samples).

Leads me to wonder whether it is certain that the MBAFF is truly 'macroblock adaptive'?Most "PAFF" encoders I know of don't actually do any significant adaptation, since if they did, they might as well have done MBAFF instead.

[WorBry]

Good point, and by the same token it is reasonable to wonder then whether the MBAFF implementation is also non-adaptive ?

[Dark Shikari]

Good point, and by the same token it is reasonable to wonder then whether the MBAFF implementation is also non-adaptive ?It's rather trivial to test... just grab a copy (trial or whatnot) of Elecard Streameye and open an interlaced file.

[WorBry]

I'll do that, thanks. Had tried another pro analyzer demo - H.264Vista - but it always crashes with my DivX H264 encodes.

[WorBry]

Sorry for my ignorance, but which analysis in StreamEye allows you distinguish frame-encoded and field-encoded macroblock pairs in a given frame?

[Dark Shikari]

Sorry for my ignorance, but which analysis in StreamEye allows you distinguish frame-encoded and field-encoded macroblock pairs in a given frame?Frame MB-pairs don't have a linked icon when MB types are displayed, field MB-pairs do.

[WorBry]

Frame MB-pairs don't have a linked icon when MB types are displayed, field MB-pairs do.

On that basis, it appears that the DivX H264 encoder MBAFF is not adaptive either.

Edit: In fact, I'm pressed to find a reference clip that does actually demonstrate adaptive MBAFF. None of the MBAFF samples here are:

http://x264.nl/h.264.samples/

And surprised to find that this BBC HDTV MBAFF clip is not adaptive either, since the original source was obviously progressive:

http://mirror05.x264.nl/public/force.php?file=./BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts

I thought the BBC uses Grass Valley H.264 encoder which, according to their literature, incorporates truly adaptive MBAFF - "Interlace MB Adaptation", as they refer to it.

Anyone have an MBAFF sample that does demonstrate MB adaptation?

[stax76]

I need to make some changes in StaxRip regarding DivX Plus, does it support AC3? Where can I find the specification?

[kieranrk]

I thought the BBC uses Grass Valley H.264 encoder which, according to their literature, incorporates truly adaptive MBAFF - "Interlace MB Adaptation", as they refer to it.

Anyone have an MBAFF sample that does demonstrate MB adaptation?

The new BBC encoder does. (And I'm sure the old one did at some point)

http://x264.nl/h.264.samples/force.php?file=./aug.2009/08-08_01-29-47_BBC_HD_(AC3,eng)_Michael_McIntyres_Comedy_Roadshow.ts

I'd assume Ateme does too.

[DigitAl56K]

Hi Stax,

The recommended audio format for DivX Plus is AAC - support is built into DivX Plus Web Player, DivX Player, and also in our free DirectShow filters. DivX Plus devices support AC3 by decoding or passing it via SPDIF.

BTW, check your PMs :) We're in the process of consolidating information and building out documentation for developers. I was trying to contact you on this front recently.

[WorBry]

The new BBC encoder does. (And I'm sure the old one did at some point)

http://x264.nl/h.264.samples/force.php?file=./aug.2009/08-08_01-29-47_BBC_HD_(AC3,eng)_Michael_McIntyres_Comedy_Roadshow.ts

I'd assume Ateme does too.

Thanks for the BBC MBAFF clip, but again, according to StreamEye, it looks like it is all 'field MB-pair' encoded i.e. no adaptation.

Sorry to digress, I know this is a DivX H264 encoder thread.

[Dark Shikari]

Thanks for the BBC MBAFF clip, but again, according to StreamEye, it looks like it is all 'field MB-pair' encoded i.e. no adaptation.

Sorry to digress, I know this is a DivX H264 encoder thread.Look around more carefully. That one is MBAFF.

[WorBry]

In fact, it appears to be a mix of MBAFF and PAFF. According DGAVCIndex, starts off MBAFF, changes to PAFF (Fields TFF) at frame #87, back to MBAFF around frame #250, and then PAFF again around frame #290.

According to their literature, the Grass Valley Mustang encoder is capable of PAFF, MBAFF and PAFF + MBAFF (i.e. MBAFF when frame coding selected by PAFF) and " is able to compare, in parallel, all solutions, and check the one that provides the optimum bit rate for the best picture quality, approaching RDO (rate distortion optimization) very closely"

http://www.grassvalley.com/docs/WhitePapers/transmission/encoders/CDT-4015M-3.pdf

[Foofaraw]

Dark Shikari,

I was just thinking the same thing. The maximum IDR interval is limited to 4 seconds because we wanted to improve seeking for consumer electronics devices and through experimental testing our team found that this was a reasonable trade-off to make in terms of the impact on overall efficiency and navigation experience, so our encoder adheres to this recommendation.


Ah, this explains why so many hardware devices appear to seek so badly - its really people encoding with way to large intervals.

[juGGaKNot]

Next year is coming, when will the encoder be updated ?