AVCHD encoder research

[Vitaliy Kiselev]

Note that it really is two I frames in a row, and not a bad display of the stream, there are 11 P frames on either side of the two I frames. The GOP is apparently set to 12.

Chris

Funny.
Anyway, I think that bug is the same as in large P frame.
In it just transfer all available framerate to next rame.

[svecher]

Testing 3.37d:

It works as expected...

Video bitrate adjustment FHD/SH 50000000
Video bitrate adjustment H 38000000
Video bitrate adjustment L 30000000
Overall bitrate adjustment 52000000
Limiting bitrate adjustment 60000000

When experimenting with these settings I had a thought that it would be great to switch SH mode to record in 1080p mode instead of 720p. This way FHD mode can be set to higher bitrate mode and SH to lower, so we can test two sets of bitrates without changes in the scene. This will also be useful in real-world scenario, as FHD mode can be set to "experimental" high-quality settings, while SH the stable ones (say the PTools "C" settings). This way if there are problems encountered with FHD you just change the mode instead of re-flashing firmware.

[cbrandin]

I've been doing some more testing of AVCHD Native 24p mode and have some new results - and they are rather strange showing I frames that are not key frames, empty frames, etc.....

In the pictures attached the red bars are non-key I frames, the brown ones are key I frames, and the blue P frames. The one with mostly brown I frames was captured with 50, 52, 60, 24pN settings. You'll notice that it has a rogue I frame. I've also attached a picture from the same capture that shows a mixture of key and non-key I frames plus a completely empty P frame (it is completely empty, I checked).

Also attached is a capture using the 24pN patch and nothing else. Except for the very first I frame is it composed of only non-key I frames and the rogue frame is a P frame.

I noticed that total GOP's (the I frame plus the 11 following P frames) containing rogue frames add up to almost exactly twice the size of the normal ones around them.

This is all very strange and seems to indicate that whatever is going on with Native 24p mode, it's not going to be easy to explain.

Chris

[cbrandin]

I just noticed that the I frame in the screenshot with the empty frame has the I frame in the wrong place and that it should be where the empty frame is. I wonder if there could be a bug in StreamEye or if this is what is really happening.

Chris

[cbrandin]

Vitaliy,

Are we sure that the old "Video Buffer" setting really doesn't do anything? I've been looking at my test results and it's hard to believe that the CODEC can have so many errors in it. The only thing I can think of that would cause so many different appearing failures is some kind of buffer overrun condition.

If you think it would be helpful I would be willing to run some tests with the various buffer settings, but you'd have to put the Video Buffer setting back into PTool.

Chris

[cbrandin]

More AVCHD Native 24p strangeness.

Chris

[svecher]

More AVCHD Native 24p strangeness.

Chris

Variable GOP length capability would actually be a very useful development, if performed in an intelligent manner. For example, if encoder was capable of "deciding" in the middle of GOP that P frame sizes are hitting a certain upper threshold, in which case it might as well produce an I frame to better allocate available bandwidth.

[cbrandin]

I agree, it could be a nice addition, but it would require processing many frames twice and the CPU might not be able to handle that. Or, at least if it can it will detract from being able to do other things well.

As far as I know the GH1 is intended to operate as a fixed GOP CODEC, so what we are seeing is almost certainly bugs - and that's not good.

Theoretically, from a card bandwidth standpoint the camera should be able to do the equivalent of something like 70,72,80 settings, or better at Native 24p. Imagine how cool that would be! Unfortunately it looks like the rogue frames, although not producing bad looking footage, raise the instantaneous bitrate so high it locks the camera sometimes even though the overall bitrate is well below what the camera can handle.

I don't get any of these problems when I don't check Native 24p/25p.

Chris

[svecher]

Doing a little research regarding the 23.971 frame rate issue reported by Elecard StreamEye on AVCHD files produced with Native patch, here is something I came across on Doom9's forums (http://forum.doom9.org/archive/index.php/t-133070.html)

One more question to the Gods of h264:

For Blu-Ray movies I've getting:

num_units_in_tick: 1001
time_scale: 48000
interlaced: false
Why is that not 24000? How can I get from time_scale/num_units_in_tick to the real framerate? Of course I could hardcode a conversion from 48000 to 24000, but I'd prefer a mathematical way to get the "right" framerate.

'cause this is _field_ rate, not frame rate. it doesn't depend on sequence scan/coding mode - it is so for both progressive and interlaced sequences.

So, using example above, Blue-Ray DVD movies' frame rate is 48000 / 1001 / 2 = 23.976. Sounds about right ...

GH1's 720p files have num_units_in_tick value of '1001' and time_scale of '120000'. 120000 / 1001 / 2 = 59.94. I think this method is working ...

Sony NEX5 test footage: num_units_in_tick value of '4800' and time_scale of '240000'. 240000 / 4800 / 2 = 25. Must have been a PAL version that DPReview got.

Native patch files have num_units_in_tick value of '2503' and time_scale of '120000'. 120000 / 2503 / 2 = 23.971. Interesting ;) Can these values be changed?

[rambooc1]

Fantastic work done on this FW so far but just wondering, Does anyone know if the native 24/25pn patch is still being improved or have we moved on to other things? I couldn't find a conclusion to this other than the spikes contain garbage info, but nothing about removing them or why they are there?

The Official firmware tester thread has this info

1. Native 24p/25p patch modified to prevent freezing on playback.
2. 24p/25p native (done)


Is it generally accepted that this limitation is what we have and the fastest cards we can buy are the only solution.