Personal View site logo
What is going on with the "blip"
  • cbrandincbrandin
    I have been doing a deep dive into the GH2 quantization process. While investigating that I think I figured out what the "blip" that happens in the beginning of streams is. First of all, it happens with an unhacked GH2 as well - it's just not as visible. When a stream starts the codec starts with default quantization values - which are never optimal. As the first GOP progresses the codec is making adjustments to optimize the quantization process. Of course, not much optimization happens in the first GOP because the first I frame (which is used as a reference for the following P and B frames) is not very good. By the time the second I frame has passed things are much better, but still not optimal. By the time the third I frame passes things are better still. From my measurements things are typically optimal by the 34th (in 24H mode) frame. The 34th frame uses the 36th frame (the third I frame) as a reference, so that makes sense.

    At the beginning quantization values for frames vary widely, from a minimum (best quality) of 18 up to 51 (worst quality). By the time the 34th frame has passed the codec settles into a pattern where all P and B frames use a quantization value of around 20 (an entire P or B frame uses a single quantization value). I frames typically use a range of 5 quantization values; it is usually in the range of 18-22. The absolute values can vary one or two values, but the pattern is consistent. For example, for highly detailed scenes I frames range from 18-22 and P and B frames are at 20. For lower detailed scenes those values may go to 19-23 for I frames and 21 or 22 for P and B frames.

    Dark scenes seem to cause the quantization values to be low. Currently, the lowest quantization value I've seen is 18 in I frames and 20 in P and B frames. This is true with both hacked and unhacked cameras. Currently, Vitaliy and I are working on trying to lower that. It's not as simple as we had hoped so it may take a while.

    The conclusion I have come to is that it might not be possible to eliminate the "blip" because that is when the codec in configuring itself. Note that the blip exists in an unhacked GH2 as well, though not as visible. I think Panasonic made the choice to at least record something, even though the codec isn't really ready yet. I think it was a good decision.

    Chris
  • 31 Replies sorted by
  • LPowellLPowell
    @cbrandin Thanks for the tip on Streameye Slim's price. I'll download it tonight.
  • cbrandincbrandin
    @LPowell

    Have you looked at StreamEye Slim? It's only $50. I've been using it to investigate the quantization stuff. It's cheap enough and it can tell you all kinds of things about the coding process - quantizations, motion vectors, macroblocks - everything. Aside from having pop-ups that will tell you everything about a particular macroblock, it also has an info box that will tell you what the min and max Q values are for a frame, etc... It has a couple of quirks, though. It doesn't recognize Panasonic file extensions (you have to select "All"), and the tool-tips (pop-ups) for each macroblock don't show up unless the video display window is selected (when you advance a frame, for example, it deselects the video window and the tool tips don't work until you click on the video window).

    Chris
  • LPowellLPowell
    On the GH1, the AVCHD encoder had a tendency to over-estimate the bitrate needed for the second I-frame. This was the culprit that caused patches to fail immediately after the start of recording. To guard against this hazard, I attempted to suppress the initial bitrate in order to keep the second I-frame under control. While it wasn't as noticeable on the GH1 as in the GH2, the image quality of the first GOP in the AVCHD stream has always been suboptimal.
  • cbrandincbrandin
    @bdegazio

    Yeah, I posted in an earlier thread that when it comes to start-up, the GH2 actually outperforms an IMAX camera. Actually, I left out the part about "when it comes to" (saying instead "in some ways") and just posted that the GH2 outperforms the IMAX - but nobody fell for it:)

    Chris
  • cbrandincbrandin
    Vitaliy,

    That seems like such a good and simple idea. AVC codecs that do 2 passes do 2 full passes (i.e. they take twice as long). One could pre-process every frame, come to think of it, doing the bare minimum processing to determine detail, dunamic range, etc... roughly and probably improve encoding considerably. For example, just doing FFTs in several small sampled regions in a frame could be very useful before actually encoding a frame. You wouldn't even have to go so far as MJPEG encoding.

    Chris
  • bdegaziobdegazio
    The blip at the beginning doesn't bother me at all, you just cut it off in post. Others may have different priorities and working methods though.

    When I worked in 35mm features the beginning second or so and about the same length at the END of most takes were unusable due to flash frames or poor sound sync as the camera got up to speed. And with IMAX it takes about 7-10 seconds for the film speed to stabilize when the camera starts rolling, so the first part of every shot has terrible varying frame rate and exposure. The film stock and processing that gets wasted because of that costs a fortune when added up over a complete film shoot!

    I agree with Chris - fixing the blip seems to me to be a low priority detail. I'd much rather see 1080p60 (or even 1080p120 !)

  • cbrandincbrandin
    @Angry_C

    There are blips at all bitrates - that is, the first GOP is always lower quality. It's just not as visible. Also, below 32M the initial estimates (or, default values, to be more precise) may be more appropriate.

    @driftwood

    When you start a capture the camera has to do all sorts of things. Even things like file allocations, buffer allocations, focusing startup, metering, etc...
  • Vitaliy_KiselevVitaliy_Kiselev
    >MJPEG because it is easier? Or, because that way you wouldn't have to mess with the AVCHD encoder? Or, both?

    Because it is easy to do and it'll be faster.
  • cbrandincbrandin
    MJPEG because it is easier? Or, because that way you wouldn't have to mess with the AVCHD encoder? Or, both?
  • Angry_CAngry_C
    @cbrandin:

    Why are there no blips at bitrates lower than 32 mbit?
  • Vitaliy_KiselevVitaliy_Kiselev
    @cbrandin
    I am suggesting to make periodic MJPEG encoding of live view feed and use compression result for estimation.
  • cbrandincbrandin
    So, are you suggesting something like doing a first-pass encoding of just the first frame to create initial estimates, and then starting over using those estimates?

    Chris
  • driftwooddriftwood
    Is this blip part of why the gh2 takes so long to get into recording? (ie the delay after hitting record?) That is that the codec is just getting up to speed?
  • Vitaliy_KiselevVitaliy_Kiselev
    >Interesting idea - as long as there is enough RAM to buffer enough frames.

    No buffering is necessary, just one value - compression ratio will give you good estimate fopr required Q values for first I frame.
  • cbrandincbrandin
    Interesting idea - as long as there is enough RAM to buffer enough frames.
  • cbrandincbrandin
    Speaking of initial values. Vitaliy, that patch that defaults to 20 appears to be a starting Q value used just in the first frame. The section of code it appears in might be where the initial estimated values are set. What do you think?

    Chris
  • Vitaliy_KiselevVitaliy_Kiselev
    @cbrandin
    I even could propose a solution for Panasonic.
    They need to compress each 60th frame in low resolution(screen res) MJPEG before recording starts and get initial estimation for Q values from results.
  • cbrandincbrandin
    I think it looks worse with the hack because the default values that are used for the first frame a too far off. In time I would expect that Vitaliy could find better starting parameters.

    Frankly, though, this seems like a lower priority than other things to me. Also, I'm quite convinced that the blip can never be totally eliminated, just made shorter and less extreme. Every GH camera I've looked at - hacked or unhacked - has some sort of blip. No first few frames I've ever seen are as good as subsequent ones. In fact, no first GOP is as good as the rest.

    Chris
  • Vitaliy_KiselevVitaliy_Kiselev
    @cbrandin
    It looks more like speculation.
    It have initial values anyway, and if we understand them we could adjust them according to bitrate.
  • Vitaliy_KiselevVitaliy_Kiselev
    @cbrandin

    This is why I do not like this as separate topic. :-)

    @svart
    I don't know for now.

    @EOSHD
    No, it is impossible.
  • cbrandincbrandin
    Looking at it theoretically, it seems that the blip in 24H mode would have to be a minimum of 9 frames. All GH cameras have a first I frame that is much smaller (or, at least less detailed) than the rest. That means that with only P frames things can't get better until the second I frame with the GH1; or the first B frame that can use the second I frame as a reference - which in the case of the GH2 in 24p mode would be the 9th frame. I guess that's better than waiting for the 34th frame. To reach that goal, the initial default estimates would have to be very close. Also, I wonder if the camera uses default coefficient tables at the start and builds new ones based on the scene - which would inevitably require some time. Even if it could do that instantaneously, it would have to wait until the first frame was captured to do so. The obvious solution would be to re-code the first frame and just write it to memory after a delay. I'm not sure the CPU could handle that, though. Also, I think Panasonic would have to do that - I'm not sure it could be something you could do with a hack.

    Chris
  • Ralph_BRalph_B
    That's a good idea.
  • EOSHDEOSHD
    The GH2 has a function called video divide in playback mode. Could it be possible to either trim the first 2 seconds from the AVCHD file once recording ends using existing firmware code related to crude inbuilt clip editing, or at least hack it to generate the thumbnail in playback mode from 2 seconds into the clip?
  • svartsvart
    Do you have an idea why the "blip" on high bitrates is comparatively worse than that which we see with normal firmware? With normal firmware, the "blip" does not result in strong macroblocking, just slight artifacts, while high bitrate firmware results in very strong macroblocking for the first couple seconds.
  • cbrandincbrandin
    Maybe. I suspect we may be able to shorten it, or make it better, but I doubt there is any way to make it go away altogether.

    Chris
This topic is closed.
← All Discussions