proof that x264 HD is a poor benchmark.

[deadrats]

I was asking about distributing the frame types and GOP composition for the following encode, not the source . (You're trying to plan the optimal way to encode the file , for most efficient compression)

When you encode, the source video is decoded to uncompressed frames before encoding (so the notion of frame types, GOP doesn't really apply)

i understand, the question was how to split up the file, you would split it up by source gop, you launch a thread to analyses gop structure, at gop boundaries you would cut the file, decode that portion, set that segment to encode on it's own thread and then concatenate the result. clearly you wouldn't try to cut the file based on the destination file's (which doesn't exist yet) gop structure.

I only look at end results, mostly quality , but also speed, customizabilty, and maybe ease of use . I don't care if the code sucks if encoder delivers. Unlike you I don't care if the authors are jackasses or saints

it's not so much that i care what they are in their personal lives but the truth is that what they are ultimately influences the direction their software takes.

in the case of the x264 developers, in addition to everything i have ever said about them perhaps the most galling is the fact that they are sell outs, they present themselves as these hippie, "Kumbaya My Lord", coding for the good of humanity types but the truth is that they would sell their asses if the price was right. DS has admitted on numerous occasions that there are features included in x264 because some company paid them a fee to add the features and more importantly paid them extra not to reveal the name of the company. jason has admitted to me during one of the gpu acceleration discussion over at that suck ass forum that the x264 developers were offered 100 grand to add gpu accelerated either motion search or motion estimation (don't remember exactl what he said) and it was turn down because it was deemed "grossly inadequate", so one can only imagine how much they charge to add a given feature.

thus nothing they say is to be believed, they will sit and say anything is impossible to do until someone waves enough cash in front of their face and then suddenly it because incredible viable.

so the next time you are setting up an encode and configuring sux264, as you're going through the options ask yourself if it in there because they believed that was the best way to do it or because some company paid them to add it in there.

[poisondeathray]

I was asking about distributing the frame types and GOP composition for the following encode, not the source . (You're trying to plan the optimal way to encode the file , for most efficient compression)

When you encode, the source video is decoded to uncompressed frames before encoding (so the notion of frame types, GOP doesn't really apply)

i understand, the question was how to split up the file, you would split it up by source gop, you launch a thread to analyses gop structure, at gop boundaries you would cut the file, decode that portion, set that segment to encode on it's own thread and then concatenate the result. clearly you wouldn't try to cut the file based on the destination file's (which doesn't exist yet) gop structure.

This approach doesn't necessarily work very well for many files . It assumes that the source file has already been organized and optimally compressed.

For example, many editors, NLEs, etc... deal with uncompressed files; compositors, motion graphics artists often work with image sequences . Avisynth frameserves uncompressed. So you have a GOP size of 1.

Source files often won't have optimal GOP structure for compression e.g. DVD's might be 12-15 . Film based BD's might be 24. Those are max limits, not variable. The reason those are there is for hardware chip decoding compatiblity purposes, not necessarily the optimal boundaries in all situations (in fact , they are limiting in most situations, until you get into higher bitrate ranges)

High end Pro aquisition codecs are usually I-frame only or image formats, (Incl. RAW, ProRes, DNxHD, AVC-Intra), and consumer aquisition codecs usually are around 12-15 for AVCHD . (Max 30 for 60p consumer models) . So even a quick direct compression of a shooting session won't work very well with that approach

Moreover, ^ most of those examples above are non adaptive GOP's. They are constant and fixed . That' s a terrible way to encode for efficiency purposes

so the next time you are setting up an encode and configuring sux264, as you're going through the options ask yourself if it in there because they believed that was the best way to do it or because some company paid them to add it in there.

Yes, many features are sponsored. It's quite common. Same with other "open source" software like ffmpeg / ffmbc. Some company like BBC , Google, sponsors development of codecs or features and people like you and me get to benefit for free

[deadrats]

Yes, many features are sponsored. It's quite common. Same with other "open source" software like ffmpeg / ffmbc. Some company like BBC , Google, sponsors development of codecs or features and people like you and me get to benefit for free

you seem to be missing the point, these companies don't sponsor a specific feature for the good of the world or so that we end users can get the benefit for free, they sponsor that feature because it's something they wanted. there's no such thing as a free lunch, no one ever decides to do anything unless there is some net benefit to themselves.

with regards to short gop's, i fail to see why that would be a hindrance, if anything that would benefit more from the threading model i propose. take a AVC-Intra source file as an example, since every frame is a stand alone frame that doesn't depend on any other, you could simply assign one frame per thread, you could easily load up a gpu's array of processors so that each "core" was processing one frame and then concatenate the results together. as a matter of fact, this threading model scales better the shorter the gop thus it would be ideally suited for blu-ray or dvd encoding, where gop structure is constant.

adaptive gop's are horrible for quality, way too many b frames; "compression efficiency" is the enemy of visual quality, it's a term promoted and championed by those that get off on bit rate starving their encodes.

[poisondeathray]

Yes, many features are sponsored. It's quite common. Same with other "open source" software like ffmpeg / ffmbc. Some company like BBC , Google, sponsors development of codecs or features and people like you and me get to benefit for free

you seem to be missing the point, these companies don't sponsor a specific feature for the good of the world or so that we end users can get the benefit for free, they sponsor that feature because it's something they wanted. there's no such thing as a free lunch, no one ever decides to do anything unless there is some net benefit to themselves.

That's right. That's why it's unfathomable that x264 was so good in it's time - it wiped the floor against competing encoders . How is that possible for open source freeware? Well the one biggest strength was probably thousands of beta testers

with regards to short gop's, i fail to see why that would be a hindrance, if anything that would benefit more from the threading model i propose. take a AVC-Intra source file as an example, since every frame is a stand alone frame that doesn't depend on any other, you could simply assign one frame per thread, you could easily load up a gpu's array of processors so that each "core" was processing one frame and then concatenate the results together. as a matter of fact, this threading model scales better the shorter the gop thus it would be ideally suited for blu-ray or dvd encoding, where gop structure is constant.

Yes, I agree for threading. That's the entire point ! - The GOP issues I've been talking about entirely deals with quality - that's the point I'm bringing up.

Threading is useless if the quality sucks. Look at the current crop of GPU encoders. Analyze how they do their GOPs - that's a large contributing part as to why they suck.

adaptive gop's are horrible for quality, way too many b frames; "compression efficiency" is the enemy of visual quality, it's a term promoted and championed by those that get off on bit rate starving their encodes.

Wow.... If you don't understand these basic compression issues, you should stop discussing this topic right now.

Seriously

So you're basically saying HEVC is doing it all wrong too then ? Because that's what it sounds like....

Wow. I hope you're only joking

[Mephesto]

You're as bad as those crazy people on Doom9 who adopt some minor part of the whole video field as their personal issue and spend their time ranting and raving about any posts that disagree with them. It's just sad that this is so important and all consuming to you.

In my early ripping and encoding career, I've learned that the multitudes of trolls and lamers in my torrents comments section came not from Doom9 but Animesuki where a flock of permavirgins round up to attack anybody who releases anything encoded by H264 in AVI format.

Yes, a three-letter extension got some people's panties in such a twist.
Thought you were a loser? Visit any anime fanboy site and prepare to get the best therapy of your life.