in need of a tool to determine gop structure

[deadrats]

does anyone know of a tool that will analyze a video file and display the gop structure? i tried gspot but it doesn't seem to work with avc or vc-1, media info doesn't display that information but there has to be something that does.

for those wondering why i would want to know, something occurred to me a while back; when trancoding from one format to another maximum quality would be achieved if the gop structure of the output file matched that of the input file, i.e. if 1:35 from the source was an I frame than likewise it should be one in the output file. also, when comparing various encoders to determine which produced the best quality it would help if we knew of say the 30 second segment produced by encoder a had a similar gop structure as the 30 second segment produced by encoder b, it doesn't make much sense to compare a 2 encoders to see which produced the best quality of encoder a used more I frames than encoder b.

[El Heggunte]

(semi-)Professional tool: Elecard Stream Eye/Analyzer

poor man's alternative: ffdshow video decoder (OSD, frame type)

[jagabo]

Yes, ffdshow will tell you if the the frame is I, P, or B if it's decoding the video. It can also show lots of other stuff including motion vectors and quantizers.

[Selur]

Sorry, but I think it's a bad move to try to match gop structures,...

maximum quality would be achieved if the gop structure of the output file matched that of the input file

only if you are forced to use the same settings for compression with the same encoder
Normally gop structure is decided by a quite few factors:

• the placing of the key-frames
  
  1. forcing of key-frames due to hitting the max gop size (this can hinder compression quite a bit if 'closed gop' is used)
  2. hindering the setting of key frames due to min gop size (in example when a forced key frame is directly followed by a real scene change)
  3. key frame placement due to scene changes (normally based on cost the coding costs of new frames)
  4. key frame placement forced by vbv restrictions (normally not that often)
  5. key frame placement due to enforcement (in example to have key frames at chapters)
• the inner gop structure, depending on the encoder used and the options and capabilities it has it might be forcing:
  
  1. a static structure
  2. a specific number of p-/b-frames
  3. b-frames which are allowed to reference to other b-frames (b-frame pyramid) or not
  4. ....

so the assumption that "if 1:35 from the source was an I frame than likewise it should be one in the output file" often is totally wrong.

also, when comparing various encoders to determine which produced the best quality it would help if we knew of say the 30 second segment produced by encoder a had a similar gop structure

quote sure, but this might force some encoders to choose a gop structure which is a rather bad for them.

as the 30 second segment produced by encoder b, it doesn't make much sense to compare a 2 encoders to see which produced the best quality of encoder a used more I frames than encoder b.

hmm,...(assuming your two encoders produce the same output size)

1. choosing a good gop structure is one of the strength and weaknesses of encoders
2. choosing encoders by frame-by-frame comparisons often is a bad way, because you will overlook stuff like 'pumping-quality'-effects (picture quality degrading during long gops and refreshing on key-frames) and easily overestimate scene which the human visual system simply would ignore (in example, smoothed high action shots) -> this is one of the reasons why simply PSNR based comparisons are normally not enough

=> all-in-all I think it's a bad call to try to get the same gop structure across different encoders and formats

[deadrats]

that's an interesting argument, let me bounce this off you, with regards to I/P and P/B ratio, for maximum quality, or perhaps more accurately for maximum consistent quality, doesn't it make sense that the ratios be changed from the defaults of 1.40 and 1.30 to 1, so that all frames regardless of type have the same quality.

[poisondeathray]

that's an interesting argument, let me bounce this off you, with regards to I/P and P/B ratio, for maximum quality, or perhaps more accurately for maximum consistent quality, doesn't it make sense that the ratios be changed from the defaults of 1.40 and 1.30 to 1, so that all frames regardless of type have the same quality.

In general,

If you have unlimited bitrate available, or very high bitrates relative to content complexity available, yes .

If you're on the low to middle part of the compression curve (relative to content complexity), no

[deadrats]

i think i may be on to something, i just did a test with a 12mb/s vc-1 1080p source to x264 12mb/s 1080p using xvid4psp 5 with the following settings:

I/P and P/B ratio set to 1, AQ mode 2, AQ strength .1, psy-rd and psy-trellis disabled, weighted p and weight b disabled, qp curve compression .01, lookahead 250, mb-tree disabled, qp min/max/step 0/30/10, 2 b-frames, 5 reference frames, mixed references, gop 60, cabac, no deblocking, b pyramid and adaptive b disabled, trellis 2, umh 24, spatial, no dct, no fast p skip, non deterministic, 2 pass, adaptive dct, I8x8 no other partitions, sub me 11.

i have to say for a half-assed over-rated encoder the results were not half bad, almost respectable.

now if only someone would hurry up and release a h265 encoder so that i can stop trying to get this sorry excuse for an encoder to produce high quality results and start using properly coded software.

now that's trolling.

[Steve(MS)]

Haha, deadrats, what if the new encoder isn't quite as good as promised...where does that leave your hopes?

[poisondeathray]

There is no question that HEVC is better, even at this early stage - it's just unusable right now (way too slow) . There are many tests results out now, and I've done a handful myself . HEVC will only get faster and better with optimizations, but x264 is pretty much plateaued (it will still get the odd speed improvement with new instruction sets, but that's about it)

[deadrats]

as PDR said there already are samples out comparing hevc encodes against comparable encodes done using x264, with higher bit rates mind you, and hevc wins.

i pointed this out in a certain other filthy piece of shit forum that should be renamed damn9, if the x264 developer's really cared about creating the highest quality encoder they could they would just take the reference h265 encoder, which is coded in pure C and they would optimize it using their admittedly extensive experience writing hand optimized SIMD assembler.

but they won't do that, because it would effectively marginalize the software they have spent 10 years promoting, spreading FUD in support of and license via x264 LLC.

they wouldn't even have to add any new features to the h265 reference encoder, just optimize it so that it's fast enough to be usable for every day use, and maybe add an I/O interface so that it accepts all valid stream types not just YUV streams.

on the bright side the chinese developer behind x265 supposedly has been hard at work optimizing the reference encoder and adding some more features from the h265 spec, and the claim is that by september the chinese university he's working with and him will be releasing a commercial version of the software, so who knows, maybe we're just a few months away from the wicked witch being dead.

[poisondeathray]

as PDR said there already are samples out comparing hevc encodes against comparable encodes done using x264, with higher bit rates mind you, and hevc wins.

No, lowish bitrates only (that's what people usually care about)

The ones I've done are on the lower end as well

You can usually extrapolate with enough data points, an encoder won't suddenly fall off at high bitrates (the curve against other encoders might level out, but it won't suddenly get way worse at higher bitrates)




LOL @ deadrats, you should keep your personal bias out of it and try to be a bit more objective

[poisondeathray]

So I saw you finally got banned at the other place

So I asked you before, and I'll ask again: how is it in the penalty box ? Do you get access to read, or just limited to posting ? or is it an IP ban ?

You should wear it like a badge of honor . You're not a real man until you've been sent on vacation LOL

[vhelp]

i agree, welding the YUV to the x265 encoder drags. scares most, if not all people from trying it. or they try once/twice and leave it. the lastest changes (v11.0) made the encoding process even slower. i fainted several times while trial and error'ing it again and again, and also making a gui for it since there are so many steps to it. its a pita att. at least make it so you can feed avisynth scripts to it so that you don't have to resort to creating an intermediate new .YUV source. and the output (player) or decoder steps is another problem. i mean, what? you have to decode it to make a new video from the encode, and then the final output is containerless. and not everyone can get the codecs working. at least i couldn't. so i have to resort to conversion via avisynth->virtualdub just so i can review the quality aspects.

[Steve(MS)]

Yeah, my reply wasn't IRT quality per se but will it have enough adjustments to be a universal encoder
and playback, will this be a free to use....or will the free portion of it be limited too much?
There are a lot of questions pertaining to usability.....
If one has to pay for full use...forget it...no one wants another main concept price range encoder.

I haven't tried to keep up with its development...I am sure d.r. will keep us informed...

[deadrats]

So I saw you finally got banned at the other place

So I asked you before, and I'll ask again: how is it in the penalty box ? Do you get access to read, or just limited to posting ? or is it an IP ban ?

You should wear it like a badge of honor . You're not a real man until you've been sent on vacation LOL

no, that hard on nueron2 (i can't prove it was him, but i have a gut feeling) banned the account and IP permanently, but like anything else if i really wanted to i could just use a proxy server and re-register. the reality is that i couldn't stand that that massive circle jerk of a forum, so it doesn't really matter.

[deadrats]

No, lowish bitrates only (that's what people usually care about)

The ones I've done are on the lower end as well

You can usually extrapolate with enough data points, an encoder won't suddenly fall off at high bitrates (the curve against other encoders might level out, but it won't suddenly get way worse at higher bitrates)

i guess i didn't phrase it correctly, what i meant to say was that the x264 encodes used more bit rate than the h265 encodes and the h265 still proved to be better overall.

LOL @ deadrats, you should keep your personal bias out of it and try to be a bit more objective

btw, objectivity is my middle name, DeadObjectiveRats.

[El Heggunte]

no, that hard on neuron2 (i can't prove it was him, but i have a gut feeling) banned the account and IP permanently, but like anything else if i really wanted to i could just use a proxy server and re-register. the reality is that i couldn't that that massive circle jerk of a forum, so it doesn't really matter.

IMHO an anti-neuron2 thread should be started in the Off-Topic forum a.s.a.p., at least there is one @ doom10:

http://doom10.org/index.php?topic=553.0

BTW, take a look at THIS: <= click

Being someone who joined Videohelp in 2001, and being a rabid "pirate slayer" at Doom9, one would expect that he reported the post which contained warez links But neuron2 didn't report anything, it was I who warned Baldrick, three days later.