Personal View site logo
Truthfulness of short GOP superiority claims
  • 100 Replies sorted by
  • 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.
  • @stefanos

    It was only the "motion" of short-GOP footage that was being compared to Red, Alexa, and film. To me, when I watch digital cinema footage or film, I get the sense that I'm seeing 24 individual whole-pictures per second. With long-GOP cameras, even if the footage is shot at the typical 24fps 1/48 shutter, it looks like only parts of the image are changing... some parts look they become a freeze frame, or the motion "disconnects" with the movement of the rest of the frame. That's really the only way I can explain it...

    Another example: Let's say that your doing a dolly push-in on a subject... with film, Red, Alexa, ect, the subject looks more like it's "blinking" forward. If you repeat the shot with a long-GOP camera, it'll look more like the subject is "sliding" forward.
  • @bwhitz

    And explained well.
  • @jamesgh2 From original post "I have encoded three of the recordings with an intra-frame codec (cineform i frame only) to remove original h264 GOP [...] and uploaded to Vimeo.
    [...]
    Originals (not re-encoded by Vimeo) are available for download on Vimeo"

    In simple terms, hit "download" and you can view a file which is essentially a movie composed of frame-grabs from the original file. I really don't see what problem you're referring to.

    Why does no-one ever read the original post? This is getting almost as bad as slashdot :oS
  • @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.
  • My apologies to @jamesgh2 and @dkitsov - it seems I misread.

    That said, I have to agree with the assessment of high bit-rate h264. It's an awesome codec.
  • @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.
  • Hang on, I was under the impression the samples WERE re-encoded 'offline'.

    @dkitsov, @LPowell my (present) understanding is that the pipeline looks like this:

    Camera:
    AVCHD encoder (different GOP settings for different samples. Bitrate? Shutter speed? ISO?)
    PC:
    => I-frames (non-GOP encoding)
    => Edit clip length
    => Denoise
    => h264 encoder on PC (50Mb/s)
    Vimeo
    => Direct copy for "download:
    => Vimeo re-encoding for web streaming

    Have I missed something?
  • @madcat You did not miss anything, you are correct regarding the pipeline. People either do not understand or trying purposefully misrepresent the test.
  • @jamesgh2 & @madact: The encoder performance issues I explained above are not relevant to how dkitsov's video test may have been processed for uploading to Vimeo. What counts in the case of the GH2 is how the video was originally recorded to the SD card by the camera's AVCHD encoder. The image quality of the video is set at the time it was captured by the camera, not by any additional post-processing steps, such as the ones madact outlined above. As long as post-processing and transcoding are done with high enough technical quality, the original properties of the video will be preserved.
  • @dkitsov So what are YOUR settings for 24p? What would you recommend as the best settings for a great picture?
  • 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
  • first is 42 mb/sec
  • @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.
  • @LPowell
    B frame is fully used in realtime encoder and future P frame is already in buffer during B frame encoding.
    If you change GOP, frame-to-frame difference do not change (it changes only of you change fps, so 60fps can be better for motion estimation).
  • 1st is 42 2nd is 32 .You def see the difference in the darker spot on the chair on the rx side.
  • @Alex_K and @chef

    No actually the first picture(4113c817ca179ebce89610e6202bcd.png) is 32 mb/sec and the second picture(efd44efc8f352acda7a96165e76572.png) is 42 mb/sec. You can see the pictures and the key in the first post on the link below. Now this doesn't mean that in every scenario you will get the same results. However, my testing has shown that the differences between 32 mb/sec and 42 mb/sec are not as great as some people have lead us to believe.

    http://www.personal-view.com/talks/discussion/541/the-zero-adverse-affects-hack-thread#Item_19

  • @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.
  • @LPowell

    I agree with your statements. That is all accurate. However, I question whether going to GOP = 3 is worth it because it eliminates the P frames. If the quantization tables are setup based on the presence of P-frames you could theoretically throw the whole thing out of whack. That is what I am seeing at 32 mb/sec and below.

    Your point about needing much higher bit rates in order to lower the GOP is absolutely correct. However, we can’t really determine whether getting rid of P frames is detrimental without 1 to 1 comparisons.

    I didn’t have time to test all of the different scenarios so I just tested the ones that are 100% stable. I hope someone else has the time to do a proper test with the extreme bit rates and lower GOPs. I hope that those settings do produce a beneficial and visual improvement. However, I am not going to blindly accept that they are better until I see a scientific test that shows how they are better.

  • >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?
  • @LPowell

    The testing I did was at a fixed ISO = 3200. The previous testing that I did showed me that the bit rate the camera chooses to encode at is directly related to the amount of noise that is present. Noise was actually just as bit rate intensive as fast motion was.

    I also saw that the amount of noise and hence the bit rate increased linearly with the multiples of the in camera ISO settings. It appeared that each 2x increment of the ISO value would increase the bit rate proportionally. I was also able to determine that ISO 160 and its multiples were in fact the base ISO values.

    The file size and noise for the multiples of 160 were always less than their equivalents in multiples of 200 or 250. For example the file size of ISO 1250 was less than or equal to the file sizes of ISO 1000 and ISO 800.
  • @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.


  • >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.

    You understand what is "Quantization table"?
    This strange theory do not have any foundation, zero.
    Shortening GOP and (removal of P frames is not very important ere) result only in "wrong" (larger) bitrate estimation.
  • @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.

    Extremely high motion scene.jpg
    1280 x 683 - 231K
    Test00001.png
    1280 x 720 - 2M