[HELP]DivX265 Encoding

[Mephesto]

1) if those were the only options you needed to worry about then the developers wouldn't have included another dozen or so fully configurable options, like trellis (3 options), subme (12 options),

Who the hell uses anything below subme11 or trellis2 unless they have a welfare computer? Even a crappy computer today can encode in real time with all the options set to max, except unreasonable ones like TESA ME or 64 merange.

You only have to configure everything once if you're using a GUI encoder frontend and then never again. Those 4 options are the only ones I have to change every now and then. I don't know anybody that has to change the subme or trellis all the time. Only time I had to care about that was when I was still using a Pentium4 and even then I realized patience is a virtue if I want quality encodes. Now I don't even need patience now that I have this i7 so all the better.

now the x264 faithful will tell you there's no need to worry about them because you should just stick with the presets, but if that was the case why write the code for these options in the first place?

For the few that have a specific reason to use them. There are other reasons such as compliance with some hardware that doesn't support certain settings.

the reality is that x264's presets are compromises meant make it easier to get decent results with a simple configuration but if you spend any amount of time doing encodes you quickly realize that one size does not fit all and what results in good encodes with one source file results in garbage with another source file.

I've been a Blu-ray ripper for exactly 7 years now. My configuration outputs amazing results with everything, I only need to tune 4 settings while everything else is tuned to max by default.

can we be honest with ourselves for a minute? x264 achieved it's level of adoption within the video community primarily because the developers targeted the anime crowd as representative users and tuned their encoder for really low bit rate anime and porn that could be shared on peer2peer networks.

That might be the reason x264 got its INITIAL adoption and the momentum it needed to become what it is. That's irrelevant if you're challenging its quality and claiming ******* MAINCONCEPT is better.

but if you read DS' blog posts, in it he admits that the h264 encoder that came with ffmpeg (it's based on the reference encoder, also open source) is almost as good as x264, he actually said it surprised him how good it was and that one is nowhere near as over-engineered and the reference h264 encoder is still better than x264.

MainConcept achieves close efficiency to x264 but it doesn't outclass it on any video sample. x264 remains #1.

and here's the funniest thing about x264, most people would agree with the statement that x264 sucked prior to getting all the psy optimizations that DS added, like AQ, psy-rd, psy-trellis and mb-tree.

WRONG, psychovisuals **** the quality up and I don't use them ever. The quality is flawless without them. mb-tree certainly improved the quality but not on all samples. mb-tree is great with low-complexity content like cartoons and 2D video games, its benefits are marginal with others.

so logically that would mean that if you disabled all of the above, no matter what other parameters you configured, the resulting encode would suck, which means that all the other encoding options were a complete waste of time coding them and using them.

You started with a false premise and ended with a false conclusion, go figure.

[Gravitator]

Hybrid - author recommends creating DivX HEVC in the container ".mp4", which can not be played on the native player DivX!
(this mockery?) why does not implement adapted for this case > http://download.divx.com/hevc/mkvtoolnix6.2.0-promised_land_rovi_v1.0.4.zip

[El Heggunte]

...

why does not implement adapted for this case > http://download.divx.com/hevc/mkvtoolnix6.2.0-promised_land_rovi_v1.0.4.zip

Short answer:

{ http://forum.doom9.org/showthread.php?p=1651084#post1651084 }

so, at Divx Labs they have a new MKV tool

where is it?

EDIT:

mkvmerge v6.2.0 ('Promised Land Rovi v1.0.4') built on Aug 29 2013 13:59:38

That's not a new tool at all, and it can only produce INvalid Matroska files.

LONG answer:

{ http://forum.doom9.org/showthread.php?p=1649544#post1649544 }

14496-15 3rd ed and Annex B extradata are both supported with libavcodec, and most matroska demuxers will just throw the extradata and blocks' contents at the decoder. Pretty much same as with AVC/H.264. So yes, the current version of how to mux should be supported.

Because now, LAV Filters "understand" the file
"TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_G PSNR_42.29_HM11_AC3_7Subs (1)-003.mkv"
(post #37 in http://dev.mpc-next.ru/index.php/topic,1787.30.html),

Meanwhile, this file you linked... Ugh... Open up that matroska file in a hex editor and ctrl+F for 0x63 0xA2 (CodecPrivate structure). One should pop up just after the CodecID. The next byte minus its most significant bit will be the length of this element (as specified per this page, since the most significant bit is set to 1). Now take the CodecPrivate listing I've noted and start going through the data. You should notice that something isn't exactly right quite soon. Although as far as I can see, if you don't really parse the structure and instead just check for the first byte(s) and then jump to the stuff you actually "need" for decoding, it actually ends up looking like nothing is wrong...

configurationVersion is set to 1, which is according to 14496-15 3rd ed (although against the "until 14496-15 3rd ed is released, please set to zero" recommendation), and then if you jump to lengthSizeMinusOne that seems to be 3, which means 4 byte lengths for data in the blocks. This happens to be exactly what DivX's code tended to do at all points.

Then you read the next byte for numOfArrays and you get a zero. Which means that there should be no further data in this structure (you would generally have VPS, SPS and PPS in the extradata). But it's quite obvious there still is data in there, so I'd say this is actually muxed according to the old Rovi/DivX patch, but just happens to work (there are VPS/SPS/PPS in the actual in-band data? Otherwise the stream would actually be impossible to decode). This is an invalid file, unfortunately.

This is what ends up happening when /EXPERIMENTAL isn't used, and different types of muxing not versioned (/EXPERIMENTAL1|2|3 or whatever).

[Selur]

as a side note:
a. H.265 is still nothing more than experimental
b. Mosu (mkvtoolnix author) is working on H.265 support in mkvmerge&co:

I've actually started work on that before the 6.7.0 release. The commits by DivX/Rovi have been merged and updated to compile with the latest code. The next steps are actually testing that it (still) works, creating tests, documentation and source code cleanups. My current plan is to have this in for the next minor release, 6.8.0.

source: http://forum.doom9.org/showthread.php?p=1661376#post1661376
-> with a bit of luck mkvmerge will support H.265 content starting with 6.8.0

[Gravitator]

-> with a bit of luck mkvmerge will support H.265 content starting with 6.8.0

but not for long

[Selur]

Why not for long? Why should the support be removed?

[El Heggunte]

Selur, I'm afraid Google Translator sucks too much in Kazakhstan

[Selur]

probably,...

[Gravitator]

but not for long

- not to delay the release 6.8.0
(Google Translator/Yandex translator)

[deadrats]

Who the hell uses anything below subme11 or trellis2 unless they have a welfare computer? Even a crappy computer today can encode in real time with all the options set to max, except unreasonable ones like TESA ME or 64 merange.

lay off whatever it is that you're smoking. subme 11 slows my i7 3770k to a crawl; i assume you realize that the only preset that uses subme 11 is placebo, very slow uses sub me 10, slower uses sub me 9 and so on. in fact, DS has said that using anything higher than subme 5 is only meaningful if you're using psy-rd.

I've been a Blu-ray ripper for exactly 7 years now. My configuration outputs amazing results with everything, I only need to tune 4 settings while everything else is tuned to max by default.

first of all "ripping" a blu-ray is different than re-encoding a blu-ray, "ripping" a blu-ray is the same as "ripping" a dvd, all you're doing is decrypting the movie and copying it to another media, be it hard drive or optical storage.

if you mean re-encoding, you're anecdotal story means exactly jack squat. if you're starting with a really high quality source, like a properly done pristine blu-ray, it's very hard to find any encoder that will screw it up, even an average mpeg-2 encoder will give satisfactory results.

MainConcept achieves close efficiency to x264 but it doesn't outclass it on any video sample. x264 remains #1.

main concept was not the encoder i was talking about, i was talking about the plain vanilla h264 encoder built into ffmpeg.

WRONG, psychovisuals **** the quality up and I don't use them ever. The quality is flawless without them. mb-tree certainly improved the quality but not on all samples. mb-tree is great with low-complexity content like cartoons and 2D video games, its benefits are marginal with others.

i tend to agree, i don't like psychovisual enhancements, i don't think it's the job of the encoder to enhance anything, its job is to reproduce the input as accurately as possible.

but, you used to be a huge proponent of mb-tree, which is a psychovisual enhancement according to DS himself, and most people with encoding using x264 will tell you that prior to the introduction of AQ x264 has a tendency to screw the picture up and AQ, again according to DS, is a psychovisual enhancement.

so if you're claiming that you don't use psy-rd, psy-trellis, AQ, mb-tree and that you disable all psy optimizations (no-psy also disables some internal non configurable optimizations) and you use subme11 and you claim that your encodes are fantastic, then most people would say that you have no idea what you're doing.

and i'm inclined to agree.

[Gravitator]

developer Tom should return to the project X264 and improve the -10,12bit with height of blocks fans support him

[deadrats]

developer Tom should return to the project X264 and improve the -10,12bit with height of blocks fans support him

i don't know what the hell you're smoking either, i'm guessing some hash or heroin based on where your profile claims you're from.

"Tom" can't return to x264 because he was never part of x264, the two main developers of x264 are Jason and Lauren I i think that's the penguin's name).

"Tom" is the public spokesperson for multicoreware, the company trying to bring x265 to the masses.

and x264 already supports 10bit.

[Mephesto]

lay off whatever it is that you're smoking. subme 11 slows my i7 3770k to a crawl; i assume you realize that the only preset that uses subme 11 is placebo, very slow uses sub me 10, slower uses sub me 9 and so on. in fact, DS has said that using anything higher than subme 5 is only meaningful if you're using psy-rd.

I don't use presets, I use my own settings. There is no reason to use less than subme11 unless you're concerned about speed. subme11 brings about a lot more quality than shitty subme5. subme7 existed way before psy-RD did and the benefits are there with or without psyRD. All psyRD does is selectively add noise to regions to mask compression smearing by texturizing them a bit. This makes the video look worse IMO hence I don't use it. I welcome a before-after example of psyRD, at the same bitrate showing better quality.

first of all "ripping" a blu-ray is different than re-encoding a blu-ray, "ripping" a blu-ray is the same as "ripping" a dvd, all you're doing is decrypting the movie and copying it to another media, be it hard drive or optical storage.

Terms are used interchangably. I actually leave the encoding half the time to my friend who's a member of our release group since he's a lot more intuitive with it than I. When you're trying to cram as much quality as possible into 700 megs, you have to know exactly what resolution to resize to and he can quickly browse thru a film and know exactly the size x264 needs to make it look perfect. When I do it, I have to re-encode 3-4 times before I get it right. Nonetheless, I know my shit.

if you mean re-encoding, you're anecdotal story means exactly jack squat. if you're starting with a really high quality source, like a properly done pristine blu-ray, it's very hard to find any encoder that will screw it up, even an average mpeg-2 encoder will give satisfactory results.

You'll be surprised how many Blu-rays are not mastered properly. Many are actually lower quality than their DVD release counterparts. Nearly every single Blu-ray release we did we had to post-process it.

main concept was not the encoder i was talking about, i was talking about the plain vanilla h264 encoder built into ffmpeg.

Huh?

but, you used to be a huge proponent of mb-tree, which is a psychovisual enhancement according to DS himself, and most people with encoding using x264 will tell you that prior to the introduction of AQ x264 has a tendency to screw the picture up and AQ, again according to DS, is a psychovisual enhancement.

I still am, mb-tree is not a psychovisual enhancement but it works wonders, just not on everything. For 2D video game replays it cut the bitrate in half with the same quality, huge gains for cartoons as well. For movies, theres maybe a 10-15% gain which is still good but not a silver bullet.

It's an awesome step in the right direction though. mb-tree is simply allocating bits selectively to parts of the frame that need it the most. In the very beginning the only way was a constant bitrate for the entire video, then we moved on to selective bitrate for different frames (VBR) but still a constant compression to the entire frame. mb-tree is the third step with variable compression to different parts of the same frame. This is the precursor for intelligent object-based codecs.

I won't discuss AQ because I'm about to start a thread asking for some clarification about it. In the past before I used AQ, I didn't have banding artifacts that need pre-processing to fix, now I do on the same source with the same bitrate as 7 years ago. Until I figure this out, I won't mention AQ.

so if you're claiming that you don't use psy-rd, psy-trellis, AQ, mb-tree and that you disable all psy optimizations (no-psy also disables some internal non configurable optimizations) and you use subme11 and you claim that your encodes are fantastic, then most people would say that you have no idea what you're doing.

subme11 in the tests I've done showed a visible increase in quality so why shouldn't I use it? The last time I used subme5 was 7 years ago on my Pentium 4 if I didn't wanna wait 24 hours for an entire DVD to encode.

[Gravitator]

"Tom" is the public spokesperson for multicoreware, the company trying to bring x265 to the masses.

PR-Manager (I am new on the site)

and x264 already supports 10bit.

10bit-not optimised for use with macroblock (remain phantoms from the previous frame)
-----------
who of you on development DivX?

[El Heggunte]

........

who of you on development DivX?

Nobody ---

--- thus you really should give a try to http://forums.divx.com/divx

[Gravitator]

I asked a question on http://forum.videohelp.com to say hello
(get out of the shadows)