What is the possibility that this test is meaningless since Vimeo is using a Long GOP codec for display?

As in it encodes its own GOP format on it destroying the original source and making them almost the same or indistinguishable.

@bwhitz

And explained well.

@madact You are not entirely correct. If they hit the download they will get an equivalent of a bluray level h264 (@ 50mbps). As one of the 3GOP preset developers have admitted they do not see motion issues with bluray reproduced movies (which do use long GOPs) so I have deemed it to be a good option that is also accepted by vimeo.

@dkitsov Long-GOP Blu-ray encoders do work very well for encoding movies. However, there's a crucial difference between delivering prepared HD content via disc or download, versus capturing HD video on an SD card in real time.

A professional Blu-ray encoder has the option of making multiple passes through the source video files, allowing it to determine in advance the bitrate needs of each GOP before it encodes the rendered video file. This enables it to literally predict the future and take as much time as it needs to fully optimize its results.

The consumer AVCHD encoder in the GH2 operates under constrained hardware resources and a strict time limit in which to record each GOP. Consequently, it must restrict itself to use only the most efficient encoding techniques that are guaranteed to produce correctly encoded video frames within the bitrate budget and time available. As a result, video files captured by a real-time AVCHD encoder cannot be expected to match the degree of compression and image quality produced by professional Blu-ray encoders.

@madcat You did not miss anything, you are correct regarding the pipeline. People either do not understand or trying purposefully misrepresent the test.

@LPowell indeed

Have you guys ever considered that all the low GOP setting could be doing is making the codec less efficient? You could just be recording the exact same thing at a higher bit rate and with much less reliability.

There is a good reason why they created I,P, and B frames. They each help to efficiently encode the video in different situations. You are totally eliminating one of those components without regard to what that actually does to the video. Who knows it may help. It may not. We won’t know that until you really test it against the same settings with a higher GOP.

Here is a good example of what I mean.

This first picture is the standard 1080p @ 24 FPS LOW bit rate of 18 mb/sec.
http://www.personal-view.com/talks/uploads/FileUpload/0f/d68a022d696229b350d32909d5d982.png

The second picture is with the default low 18 mb/sec patch and a GOP of 3.

http://www.personal-view.com/talks/uploads/FileUpload/42/afa9d60637cfd70efdb89e51539e10.png

The low GOP 18 mb/sec picture is clearly worse than the higher GOP video. Now neither of these are really that great. However something like the pictures below looks much better. Can you tell which one of the pictures below is 32 mb/sec and which one is 42 mb/sec?

http://www.personal-view.com/talks/uploads/FileUpload/01/4113c817ca179ebce89610e6202bcd.png

http://www.personal-view.com/talks/uploads/FileUpload/92/efd44efc8f352acda7a96165e76572.png

@mpgxsvcd Short-GOP encoding is definitely less efficient than long-GOP. That's why professional Blu-ray encoders use GOP-lengths over one second long. However, the challenges that a resource limited, in-camera AVCHD encoder may face can be far more demanding.

The fundamental dilemma is that B-frames use both forward and backward motion vectors, and no real-time encoder can predict the future. Blu-ray encoders side-step this problem by making multiple passes through the prerecorded video stream, enabling them to accurately predict the bitrate needed to encode each GOP. This allows them to expertly juggle I, P, and B frame sizes to maximize both image quality and coding efficiency within the specified bitrate limits.

A real-time AVCHD encoder is severely constrained by the limited amount of time in which it must write each GOP sequentially to the SD card. This forces it to use only the most efficient coding techniques that are guaranteed to produce correctly-encoded frames within its strictly-enforced deadlines. To do so, it must use estimated I-frame macroblock quantization factors that have a good chance of efficiently handling all object motion for the duration of each GOP. The longer the GOP-length, the more likely it is that these estimates will fall short of accurately predicting the movements that will actually occur in the video.

Where this encoding problem can become visible is not in the type of scenes pictured in your examples. Static shots with few moving objects contain large amounts of stable image detail that are easily compressed into either P or B frames. What really challenges the encoder are scenes that contain myriads of independently moving details, for example, panning across a sunlit, churning stream of water shot in sharp focus with minimal motion blur at a high shutter speed.

The advantage of short-GOP recording in that situation is easy to understand: the amount of motion that can occur within each GOP is restricted to the limited time duration of the GOP. With a 3-frame GOP at 24fps, each GOP is only 1/8th second long, compared to the half-second GOP-length of the unhacked AVCHD encoder. A 3-frame GOP reduces the amount of frame-to-frame discrepancies that must be encoded into each B-frame and thus greatly simplifies the encoding challenges. However, in order to maintain excellent image quality, the high rate of I-frames demands a significant increase in bitrate requirements, which explains why your 18Mbps 3-frame GOP example does not look very good.

1st is 42 2nd is 32 .You def see the difference in the darker spot on the chair on the rx side.

@Vitaliy_Kiselev
Yes, on the GH2, I suspect a 6-frame GOP (IBBPBB) would work just as well as a 3-frame GOP, and produce more efficiently encoded files. Where the encoder hits the wall is when P or B-frame size starts to exceed the size of I-frames. I've seen this occur during quick panning at fast shutter speeds.

>If the quantization tables are setup based on the presence of P-frames you could theoretically throw the whole thing out of whack.

What this strange sentence mean?

@Vitaliy

If Panasonic has optimized the Quantization tables based on the assumption that the video file has P frames then removing P frames from the video could undo that optimization.

@LPowell

Do you have a stream parser example where the B or P frames approached the I frames? The hardest to encode scene that I have encountered was a rotating imbalance fan. Even in that scene the P frames were only a little more than half of the I frames.

Here are the files from that scene. The was shot at 1/800 shutter speed and ISO 3200 wide open with the 14-140mm on ETC mode.