PDA

View Full Version : AVCHD encoder research



Vitaliy Kiselev
06-16-2010, 12:21 AM
Reserved.

jobless
06-17-2010, 04:26 AM
Hi Vitaliy,
I posted two days ago a question:

To TEster13:

Is it possible to have two different settings for FHD and SH?

Because as I understand we have SH: 17Mbps, H: 13Mbps, L: 9Mbps all 720 60p

It seems that settings for AVCHD in Ptool do not affecting H and L.

I did quick a test with H and I got 12Mbps with hidetail scene. I used C settings...
My Idea was that we can use C settings for FHD and SH( in low detailed scenes) and for H we could use other settings to get 30Mbps stable ( for hidetail)....
THx

abasfly
06-17-2010, 04:56 PM
Hi, I've been testing the AVCHD setting on the GF1 and in great detail scene I can get more than 40mbit/s. that is good.
However the compression is of the codec in detail shadows is really bad (really muddy and low bitrate). I do not now if it is happening too with the GH1 or if it is the algorithm of the GF1, would be nice to have both to compare but I don't.

here is an example of what I am talking about: http://dl.dropbox.com/u/199525/00019.MTS
The problem I see is that at certain point of exposure the bitrate drops massively.
Is it possible to put a limiter so that the bitrate doesn't go under 12mbit/s or something.

PS: I don't know if I can post here, you can move it or erase it.

Vitaliy Kiselev
06-17-2010, 09:16 PM
As for limiter - of course it is not possible.
AVCHD I frame compression works like JPEG. So, it is kind of dumb. It have similar to jpeg Q tables things and they describe how DCT results will be processed.
If you have simple or dark scene it'll result in dropped bitrate as DCT coefficients are much simpler and after same processing can be compressed much better.
Best thing I can think of is to have something like I/P ration setting to set ration between I frame and P frame sizes in whole GOP.
We'lls see if it is possible.

jobless
06-18-2010, 03:02 AM
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

FHD- 37 Mbps--- No Mud, No problems with heavy pans, No problem with zooming with Kit lens, No problem on tripod

SH-- 38 Mbps - stops recording after 10 sec on heavy pans

H -- 32 Mbps - No MUD, No problem with pans ( 1 min 15 sec), Stops recoding after 12 sec with zooms

L -- 28 Mbps- I can see a MUD ( but no as before) , No problems with pans and zooms

At LOW LEVEL seme as before....

I've tried also:

Video bitrate adjustment L 34000000--- No MUD, No problems with pans (1min 20 sec), Stops recoding on Zooms after 20 sec

svecher
06-18-2010, 10:28 AM
Here is a summary of some tests I did last night with PTool 3.37d.
Lens 7 mm, at F4.
Shutter Speed 1/50 s
ISO: 800
Card: Sandisk Extreme 30MB/s

1) Check Off:
* Version Compare patch
* Video Bitrate Adjustment FHD/SH Simplified -> 60000000
* Overall Bitrate Adjustment -> 62000000
* Limiting Bitrate Adjustment -> 70000000
Producing nice clean footage in a wrapper. Looks good at low level too (see attachment).

2) Add the following to 1):
* Native 24p/25p patch
As soon as I hit record button camera becomes unresponsive, but live view is still operating.

3) Add the following to 1)
1080p25 GOP Size -> 15
Same result.

When bitrates are lowered to P-Tool "C" settings camera records with native patch successfully.

Asiertxu
06-18-2010, 11:34 PM
1) Check Off:
* Version Compare patch
* Video Bitrate Adjustment FHD/SH Simplified -> 60000000
* Overall Bitrate Adjustment -> 62000000
* Limiting Bitrate Adjustment -> 70000000
Producing nice clean footage in a wrapper. Looks good at low level too (see attachment).

2) Add the following to 1):
* Native 24p/25p patch
As soon as I hit record button camera becomes unresponsive, but live view is still operating.

Hi there!
Sorry if this report sould go to other thread, so if this is the case don´t doubt in delete if!

This exact thing happened to me also (24/25p patch ticket on...), when trying to shoot in FHD mode two days ago (had to remove battery too.....), but with the same settings was able to record in SH mode without any problems...

I was using a Sandisk Ultra 16GB Class 4 with 15MB/s of writting speed.
Hope this helps....
Cheers!
Asier.

cbrandin
06-19-2010, 10:16 AM
I can get the GH1 to pulse when Native 24p is selected no matter how other patches are set - it's just a matter of shooting a sufficient mixture of detailed and flat subjects.

Attached is what happens if the only patch selected is Native 24p and everything else is left alone (factory AVCHD/FHD settings except for Native 24p).

I've tried A, B, C, and a plethora of other settings with GOP lengths of 8, 12, and 15. I can always get pulses.

My conclusion is that pulsing is a product of Native 24p and that alone, although the frequency of pulses may vary.

Chris

Vitaliy Kiselev
06-19-2010, 10:20 AM
Thanks.
This seems reasonable.
As 24p and 25p modes are completely untested by developers of actual video encoder.
So, we see spikes in last P-frame in GOP.

cbrandin
06-19-2010, 10:22 AM
Yes, I've checked and it is always the last frame.

chris

Vitaliy Kiselev
06-19-2010, 10:26 AM
Yes, I've checked and it is always the last frame.

chris

This is long known quirk of GH1 video encoder.
Seems to be some bug or wrong parameters set used.
All GH1 encoder style breaks basic rules, as it depends on special settings for predefined modes instead of making general and scalable solution.
Plus error processing is non-existent.

cbrandin
06-19-2010, 10:31 AM
Is much known about the CODEC code? This looks like the product of a bad conditional statement that is causing a subroutine to be called before it should be. Perhaps a combination of P and I frame subroutines being called when only one should be called. This should be patchable if the error is something like a more-than-or-equal instead of a more-than conditional. The instructions for both should be the same length.

Chris

Vitaliy Kiselev
06-19-2010, 10:37 AM
No, it is just seems like proper P frame with some garbage in it.
We need better analazying tools to understand it.
And if you think that codec disassembly is similar to C code with comments you are badly wrong :-)

cbrandin
06-19-2010, 10:45 AM
I know. I do patent forensics work for a living, so I'm well aware how cryptic disassembled code is. Still... if the code location that is executed at the transition between frame types is known it might not be so hard to find the problem. If it's unknown, however, that's another thing altogether.

Chris

cbrandin
06-19-2010, 11:04 AM
Somebody - I think it was Barry - determined that the color sampling was better in native 24p mode. Was this test done with pulldown processed wrapped video? If not, I can run some tests with wrapped video that has had the pulldown removed with NeoScene compared to native 24p video also processed with NeoScene.

Chris

Barry_Green
06-19-2010, 11:22 AM
I did test and verify that the native 24p mode uses the proper progressive color encoding system, whereas using the 60i wrapper causes it to use the interlaced 4:2:0 color system, yes.

cbrandin
06-19-2010, 11:24 AM
OK, thanks.

Chris

cbrandin
06-19-2010, 03:58 PM
I ran some tests with the "C" settings (50, 52, 60) with Native 24p not checked on a Transcend 16 GB class 10 card (this is totally reliable for me producing no pulses and no failures) and here are some results:

As I suspected higher shutter speed and lower Noise reduction both have an effect because they create more fine detail. Here are some numbers:

All clips were the same subject (bushes and flowers in a breeze - lots of detail)and ran 30 seconds producing a file size of 168-171 Megabytes.

At 1/500 and NR -2 the peak frame size was 649536
At 1/125 and NR 0 the peak frame size was 566400
At 1/50 and NR -2 the peak frame size was 515328
At 1/50 and NR 0 the peak frame size was 488832

I assume, because the average data rate was always virtually identical, that these numbers mean that the increased peak frame sizes is at the expense of detail in other frames. Obviously it would be foolish to sharpen in camera (I assume that would raise the peak frame size too) because that's better done in post anyway. There is a case for letting the camera do noise reduction - which is somewhat contrary to current thinking.

Chris

cbrandin
06-21-2010, 11:20 PM
Vitaliy,

You may want to have a look at this thread (starting half way down the page): http://www.dvxuser.com/V6/showthread.php?t=213908&page=19


Someone has managed to get two I frames in a row in AVCHD mode:

http://i40.photobucket.com/albums/e244/justafluff/StreamEye/RogueIframe.jpg

Chris

cbrandin
06-21-2010, 11:28 PM
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

Vitaliy Kiselev
06-22-2010, 05:26 AM
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
06-22-2010, 07:55 AM
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
06-22-2010, 02:24 PM
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
06-22-2010, 03:21 PM
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
06-23-2010, 10:37 AM
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
06-24-2010, 02:19 PM
More AVCHD Native 24p strangeness.

Chris

svecher
06-24-2010, 02:44 PM
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
06-24-2010, 04:33 PM
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
06-28-2010, 03:49 PM
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
07-07-2010, 09:02 PM
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.

cbrandin
07-08-2010, 08:38 AM
Vitaliy,

Has anything changed with the Native 24p/25p option? If so, I'll run all my tests again.

Chris

svecher
07-08-2010, 10:11 PM
Vitaliy,
Has anything changed with the Native 24p/25p option? If so, I'll run all my tests again.
Chris
Well, I ran two tests for the new Preset Bitrate patches at "A" AVCHD Settings. Static death chart shot looks clean as a bell at low level; no rogue frames in sight. High Five! Can't do anymore testing tonight, so if anyone wants to continue pushing these (slightly up) feel free. I'm mildly excited :bath:

P.S. For some reason, can't attach .ini files, so remove the dummy .txt extension at the end.
P.S.2. After reviewing several clips shot outdoors I can confirm that rogue P-frames are still there, although they haven't crashed or generated the "Slow card error." But I've only been shooting at "A" Settings.

richtrav
07-09-2010, 11:40 AM
I tried the A settings this morning with the recommended preset bitrate. Good news is that I haven't been able to crash ordinary scenes that used to cause freezing. Bad news is that the pulsing (muddy) I frame bug is still present, and is still always preceded by a duplicate P frame (though it doesn't look to be quite as severe, but these are casual outdoor tests). Funny though, there now seems to be a rare GOP that are all the same - a group of 15 identical frames - I'm wondering if that's what would have crashed the camera with the old settings. I'm gonna try and crank up the bitrates some today

modulr
07-09-2010, 08:54 PM
FHS/SH Bitrate 33 34 35 36 37 37 50 50 60 60 53 53 50 50
H Bitrate 33 34 35 36 37 37 50 50 60 60 90 90 36 36
L Bitrate 33 34 35 36 37 37 50 50 60 60 36 36 26 26
Overall Bitrate 33 34 35 36 37 37 50 50 60 60 53 53 50 50
Limiting Bitrate 33 34 35 36 37 37 50 50 60 60 53 53 50 50

Preset Bitrate 1 330 340 350 360 370 370 500 500 600 600 530 530 500 500
Preset Bitrate 2 330 340 350 360 370 370 500 500 600 600 530 530 500 500

Measured FHD Bitrate 30.9 31.6 32.5 33.3 34.5 34.5 46.4 46.4 FAIL FAIL 48.6 48.7 46.1 46.8
Measured SH Bitrate 31 31.8 31.5 33.4 2.5 34.8 13 46.8 22.1 56 49.8 49.7 13 46.8
Measured H Bitrate 31 31.8 32.8 33.4 2.6 34.8 12.9 46.9 22.1 56.1 FAIL FAIL 33.8 33.9
Measured L Bitrate 30.9 31.7 32.9 33.7 2.6 34.8 13 46.8 22.1 55.9 34 33.9 24.3 24.5

Shutter Speed 1/50th 1/50th 1/50th 1/50th 1/50th 1/60th 1/50th 1/60th 1/50th 1/60th 1/50th 1/60th 1/50th 1/60th


Testing was done using the star chart.

Observations:
When the 720p SH/H/L options exceed a value of 36 AND the shutter speed is slower than 1/60th, the resulting bitrate gets cut drastically.. usually by a third or more.

These are the first setting where I've been able to predict everything that would happen on outcome. As a matter of fact, the last 2 sets of are such that I can get the highest bitrate possible with shutter speeds sloer than 1/60th (H Mode) and if needed achieve the high bitrates with shutter speeds faster than 1/60th as well (SH mode).

I would like to go back and retest the last set of values with both preset bitrates off, but I ran out of full battery. In the past, the resulting bitrate numbers have always been somewhat mysterious depending on what's input.

Hope this is helpful.

JackBayer
07-13-2010, 09:09 AM
FHS/SH Bitrate 33 34 35 36 37 37 50 50 60 60 53 53 50 50
H Bitrate 33 34 35 36 37 37 50 50 60 60 90 90 36 36
L Bitrate 33 34 35 36 37 37 50 50 60 60 36 36 26 26
Overall Bitrate 33 34 35 36 37 37 50 50 60 60 53 53 50 50
Limiting Bitrate 33 34 35 36 37 37 50 50 60 60 53 53 50 50

Preset Bitrate 1 330 340 350 360 370 370 500 500 600 600 530 530 500 500
Preset Bitrate 2 330 340 350 360 370 370 500 500 600 600 530 530 500 500

Measured FHD Bitrate 30.9 31.6 32.5 33.3 34.5 34.5 46.4 46.4 FAIL FAIL 48.6 48.7 46.1 46.8
Measured SH Bitrate 31 31.8 31.5 33.4 2.5 34.8 13 46.8 22.1 56 49.8 49.7 13 46.8
Measured H Bitrate 31 31.8 32.8 33.4 2.6 34.8 12.9 46.9 22.1 56.1 FAIL FAIL 33.8 33.9
Measured L Bitrate 30.9 31.7 32.9 33.7 2.6 34.8 13 46.8 22.1 55.9 34 33.9 24.3 24.5

Shutter Speed 1/50th 1/50th 1/50th 1/50th 1/50th 1/60th 1/50th 1/60th 1/50th 1/60th 1/50th 1/60th 1/50th 1/60th
Testing was done using the star chart.

Observations:
When the 720p SH/H/L options exceed a value of 36 AND the shutter speed is slower than 1/60th, the resulting bitrate gets cut drastically.. usually by a third or more.

These are the first setting where I've been able to predict everything that would happen on outcome. As a matter of fact, the last 2 sets of are such that I can get the highest bitrate possible with shutter speeds sloer than 1/60th (H Mode) and if needed achieve the high bitrates with shutter speeds faster than 1/60th as well (SH mode).

I would like to go back and retest the last set of values with both preset bitrates off, but I ran out of full battery. In the past, the resulting bitrate numbers have always been somewhat mysterious depending on what's input.

Hope this is helpful.

Hey,

I just start to test for myself and Ive got a question about your tests:

In your settings, what does preset bitrate mean or where do I input these values?

Thanks!

cbrandin
07-16-2010, 01:44 PM
I have been researching the relationship between various bitrate settings. The following ini files were used for the tests:

[Information]
Comment=Settings A
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Overall Bitrate=52000000
Limiting Bitrate=60000000

[Information]
Comment=Settings B
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Overall Bitrate=52000000
Limiting Bitrate=60000000
Preset bitrate=500
Preset bitrate 2=500

[Information]
Comment=Settings C
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Video Bitrate H=32000000
Video Bitrate L=22000000
Overall Bitrate=52000000
Limiting Bitrate=60000000

[Information]
Comment=Settings D
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Video Bitrate H=32000000
Video Bitrate L=22000000
Overall Bitrate=52000000
Limiting Bitrate=60000000
Preset bitrate=500
Preset bitrate 2=500

Basically, these are all the suggested "C" settings. The differences are that A only has the basic settings set, B has the preset bitrates set to 500 added, C has H and L set to 32 and 22 respectively, and D has those set as well as the preset bitrates set to 500. Each configuration was tested in all modes for 1 minute each. The numbers in the table below indicate the resulting file sizes. If a failure occurred the number of seconds captured are indicated as well.

Here are the results:

...........A............B............C............ D
FHD...339........340.......FAIL-1.....FAIL-1
SH.....329.....FAIL-1/2....333........FAIL-0
H........93..........93.........218........FAIL-8
L........63..........63..........151........LOCKUP


I ran these tests several times and always got virtually identical results.

Examination of clips with StreamEye produced what one would expect. The interesting thing is that the failed clips (when any data was captured at all) looked the same as the successful ones - which is surprising.

Conclusion: H and L settings do affect the behavior of the CODEC when the camera is operating in FHD and SH mode. However, the outcome is not affected whatsoever - only stability is. The preset bitrate settings also affect behavior - but not outcome. Note that when H, L, and both preset bitrate options were set the CODEC failed all the time in all modes.

These tests were done by focusing the camera on a highly detailed scene and then pressing record. By accident I forgot to focus first once and the test came out better. Autofocus was turned on so within a couple of seconds the scene was brought into focus, but there was no failure. This peaked my curiosity so I ran all the tests again; but this time I made sure the camera was out of focus at the beginning. The tests came out much better, although a couple of modes still failed. FHD mode, however, never failed - and I tried all the tests several times.

Chris

cbrandin
07-16-2010, 02:03 PM
Here are the StreamEye captures. There are several interesting conclusions to be drawn - especially since the results were repeatable. Note, for example, that FHD mode always failed after 1.5 seconds in the C and D tests. The only difference between C and D tests versus A and B tests is that the H and L values were set in the C and D tests.

Chris

rambooc1
07-16-2010, 02:14 PM
Good work Chris, are these with or without 24/25p checked?

Thanks

cbrandin
07-16-2010, 02:18 PM
Native 24p not checked. I tested that too - and it still exhibits the strange behavior I've already documented.

I wonder if there are just a bunch of buffer overrun failures occurring. That would explain the lack of differences in the StreamEye data for successful versus failed captures. I think the GH1 firmware doesn't have much error detection in it.

Chris

svecher
07-16-2010, 04:06 PM
Conclusion: H and L settings do affect the behavior of the CODEC when the camera is operating in FHD and SH mode. However, the outcome is not affected whatsoever - only stability is. The preset bitrate settings also affect behavior - but not outcome. Note that when H, L, and both preset bitrate options were set the CODEC failed all the time in all modes.


Very interesting findings, Chris. I have been conversing with Richtrav, who has been testing your set stable B settings + Native 24p/25p and finding that setup very unstable. The settings you found most problematic I have found problem-free with a simple addition of Native 24p/25p patch (http://www.dvxuser.com/V6/showpost.php?p=2047668&postcount=265). Very interesting indeed ...


I wonder if there are just a bunch of buffer overrun failures occurring. That would explain the lack of differences in the StreamEye data for successful versus failed captures. I think the GH1 firmware doesn't have much error detection in it.

Speaking without knowledge of architectural specifics here, but the big difference between 24P and 24PsF modes seems to be that within a span of 1 GOP cycle:
1) in the former case (12) - 1 full size (1900x1080) I frames must be written + 11 smaller P frames.
2) In the latter case (15) - 2 half size (1900x504) I frames + 28 smaller half-size P frames.
Both cycles are completed within 1/2 second, so in the latter case we can see that data is chopped into smaller chunks in a faster cycle, which probably helps clearing the buffer faster.

I'm still trying to understand the exact mechanism of how 24 frames that become 48 fields are then "conformed" to 60 field per second "timeline" [so to speak]. Found this article (http://smpte-pda.org/resources/Technical+Aspects+Thorpe$2C+Sept.+2000xx.pdf) that needs to be read and understood in detail.

cbrandin
07-16-2010, 04:12 PM
Are you saying that if I check Native 24p I might get results that are in some cases the opposite of what I am seeing? That's very interesting - I'll have to try that out. Actually, I may have misunderstood, or put the answer to the question badly. My tests were with Native 24p NOT checked.

Chris

svecher
07-16-2010, 06:34 PM
Are you saying that if I check Native 24p I might get results that are in some cases the opposite of what I am seeing? That's very interesting - I'll have to try that out. Actually, I may have misunderstood, or put the answer to the question badly. My tests were with Native 24p NOT checked.

Yes, exactly. I just tested your B set settings + 24p/25p patch and got two card speed errors with one of them resulting in empty file (but no crash) out of 10 test shots of full frame Death chart. I then added H/L bitrate settings (50M/40M) and haven't gotten any errors in FHD mode.

720P modes are a different matter. I get card speed errors after 5-10 seconds of shooting footage in SH mode (50M). Switching to H mode (40M) resolved the problem.

cbrandin
07-16-2010, 07:50 PM
Actually the 720p mode is not 2 I frames followed by 28 P frames, it's 1 I frame followed by 29 P frames - at least according to StreamEye.

Chris

Oops! I got the wrapped 1080 mode mixed up with the 720p mode - sorry.

cbrandin
07-17-2010, 11:50 AM
I ran some tests using the same configurations as before (they are shown again below). This time I wanted to see what happens when there is no scene detail - so I ran the tests with the body cap on. The results are interesting, to say the least.

Here are the settings:

[Information]
Comment=Settings A
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Overall Bitrate=52000000
Limiting Bitrate=60000000

[Information]
Comment=Settings B
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Overall Bitrate=52000000
Limiting Bitrate=60000000
Preset bitrate=500
Preset bitrate 2=500

[Information]
Comment=Settings C
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Video Bitrate H=32000000
Video Bitrate L=22000000
Overall Bitrate=52000000
Limiting Bitrate=60000000

[Information]
Comment=Settings D
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Video Bitrate FHD/SH=50000000
Video Bitrate H=32000000
Video Bitrate L=22000000
Overall Bitrate=52000000
Limiting Bitrate=60000000
Preset bitrate=500
Preset bitrate 2=500

Basically, these are all the suggested "C" settings. The differences are that A only has the basic settings set, B has the preset bitrates set to 500 added, C has H and L set to 32 and 22 respectively, and D has those set as well as the preset bitrates set to 500. Each configuration was tested in all modes for 1 minute each. The numbers in the table below indicate the resulting file sizes. If a failure occurred the number of seconds captured are indicated as well.

Here are the results:

...........A............B............C............ D
FHD...21..........16..........17...........16
SH.....15..........15..........15...........15
H.......15..........15..........15...........15
L........15..........15..........15...........15

Things to note:

Native 24p NOT checked.

There were no failures.

SH, H, and L settings produced identical results in each mode, except for one detail which I will show below.

H & L settings made no difference, so A results were the same as C and B results were the same as D.

I have attached two images. "FHD Compare" shows FHD mode comparing Preset Bitrates unchecked (Settings A) with both Preset Bitrates set to 500 (Settings B). There appears to be no significant difference except the pattern on the P frames.

"SH Compare" is similar to "FHD Compare" except it shows SH mode and a detail showing the first few frames. There are two interesting things about these captures:

When Preset bitrates are set to 500 the first few I frames contain more data than when Preset Bitrates are unchecked. This pattern was utterly consistent in all tests and across SH, H, and L modes.

Every second GOP has a big spike in the last I frame. This was also utterly consistent.

Chris

cbrandin
07-17-2010, 01:13 PM
Three more "dark" no data tests. The first test uses Settings F, which only have Native 24p checked and the Limiting Bitrate set to 60M. The second test (Settings H) is similar except the Video and Overall bitrates are set as well.

The following settings were used:

[Information]
Comment=Settings F
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Native 24p/25p=Checked
Limiting Bitrate=60000000

[Information]
Comment=Settings H
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Native 24p/25p=Checked
Video Bitrate FHD/SH=50000000
Overall Bitrate=52000000
Limiting Bitrate=60000000

The results for FHD mode are attached below. Note that the rogue frames only appear if Video and Overall Bitrates are set in addition to the Limiting Bitrate. Limiting Bitrate alone does not cause rogue frames. Also, the rogue frames are smaller than they are in detailed scene tests - but they are there nevertheless.

The last test uses the Panasonic factory firmware. The third capture below shows that the spikes for SH mode occur even with factory firmware.

Conclusions? Well, I'm not sure what to make of all this yet but I think I know this much: Rogue frames are a bug in the factory firmware and they appear with progressive footage - whether it's the factory 720p or the "hacked" 1080p. The strange thing is that 720p always shows it, but hacked 1080p requires that the Video Bitrates are set to higher values.

Chris

cbrandin
07-17-2010, 01:36 PM
I think I know what is causing the rogue frames! The Panasocic firmware has two routines that do the final stream processing prior to writing to flash. One processes true progressive modes (i.e. SH, H, and L modes) and it has a bug that can produce a rogue frame at every second GOP. The second processes the "wrapped" 1080 mode (i.e. FHD mode) and does not have this bug. Fix the 720p mode output routine and I'll bet the rogue frame problem with Native 24p/25p goes away.

Still, one mystery remains: Why does the Native 24p/25p mode only manifest this problem when Video Bitrates are increased while 720p modes show it all the time?

Chris

noirist
07-17-2010, 01:43 PM
Go Chris!

cbrandin
07-17-2010, 01:59 PM
Having given all this "dark" test data some thought I think I can come to the following conclusions:

1) The reason that AVCHD FHD "wrapped" mode is more stable than all others (Native 24p/25p, SH, H, and L) is that all these other modes are failing for the same reason - a bug in the final progressive mode output routine in the Panasonic firmware that produces rogue frames.

2) The Preset Bitrate settings affect how the CODEC starts up and have little effect once a clip progresses past the first few frames. It's probably better to leave these values low to increase stability. This might also explain why things go better when you start out of focus. If these are set to high values the camera fails immediately if you start the capture in focus, but no failure occurs if you start out of focus.

3) SH, H, and L modes all produce rogue frames with Panasonic factory firmware.

4) Wrapped FHD mode never produces rogue frames.

5) The Panasonic AVCHD CODEC does the "variable" processing quite well. When there was no image to process all SH, H, and L modes produced almost exactly the same file sizes no matter how bitrates were set and which mode was selected.

Chris

rambooc1
07-17-2010, 02:47 PM
Fantastic work Chris and confirms my gut feeling was right moving back to Wrapped settings for 1080.

Funny i never noticed the rogue frames in original FW, but then i wasn't particularly looking for them.

crunchy
07-17-2010, 02:56 PM
Congratulations on your research, Chris. I asked myself why nobody approached to the problem systematically.


Still, one mystery remains: Why does the Native 24p/25p mode only manifest this problem when Video Bitrates are increased while 720p modes show it all the time?

As far as I understood from your posts, 24p/25p mode does not produce rogue frames when bitrates are low? What did you mean by low? Low-complex picture and/or lower bitrate settings? Have you found a limit when rogue frames appear?

cbrandin
07-17-2010, 03:13 PM
Thanks!

These tests were made with no lens - just the body cap on, so there was no image detail whatsoever. My theory was to isolate CODEC artifacts unobscured by image data.

By "low" bitrates I mean the Video Bitrates and the Overall Bitrate unchecked (factory defaults). It didn't matter how the Limiting Bitrate was set.

Good question about when the rogue frames appear, I'll have to test that. I wonder if they appear suddenly or gradually. Hmmmm....

Chris

crunchy
07-17-2010, 03:28 PM
Good question about when the rogue frames appear, I'll have to test that. I wonder if they appear suddenly or gradually.

Yes, it would be interesting to see. I suppose that you'll probably do it in "controlled environment". If my "failing chart" can help you, it's attached. The positive property of the chart is that it has repeatable pattern. So, at first you can apply higher zooms in order to reduce the acquired data. Later on wider shots can be applied.

cbrandin
07-17-2010, 03:33 PM
Thanks for the chart.

What I want to test now is when rogue frames appear with no image data. In other words, when they start to appear just based on bitrate settings. I've noticed that rogue frame size can vary according to image data, but whether they appear at all seems to depend on the CODEC irrespective of image data.

Actually, this testing is something anybody can do - just take off the lens and put on the body cap (make sure to set the "without lens" option). This is an easily controlled environment - all black.

Chris

crunchy
07-17-2010, 03:45 PM
I've noticed that rogue frame size can vary according to image data, but whether they appear at all seems to depend on the CODEC irrespective of image data.

You are absolutely right.


Actually, this testing is something anybody can do - just take off the lens and put on the body cap (make sure to set the "without lens" option). This is an easily controlled environment - all black.

The only problem I see is that it is limited-time research per person (I mean 30-days limiting evaluation period). If everybody starts using the software at the same time, we might be in a trouble in one-month time. :embarasse

PappasArts
07-17-2010, 05:54 PM
2) The Preset Bitrate settings affect how the CODEC starts up and have little effect once a clip progresses past the first few frames. It's probably better to leave these values low to increase stability. This might also explain why things go better when you start out of focus. If these are set to high values the camera fails immediately if you start the capture in focus, but no failure occurs if you start out of focus.


Chris

Great testing Chris- Do the patches help 24PN at all- Either 1 & 2 0r both ticked?

Pappas

rambooc1
07-17-2010, 06:12 PM
Here are the StreamEye captures. There are several interesting conclusions to be drawn - especially since the results were repeatable. Note, for example, that FHD mode always failed after 1.5 seconds in the C and D tests. The only difference between C and D tests versus A and B tests is that the H and L values were set in the C and D tests.

Chris

Chris sorry to back up a bit to this post, but how do you think H and L is affecting FHD? It is the only one with the wrapper when Native is unticked.

If it is affecting stability and we don't really have a need for H and L then maybe should leave them stock and just change FHD/SH settings.

Ditto on Pappas question above as well.

modulr
07-18-2010, 12:57 AM
Interesting finds.

I have been exploring the AVCHD 24PN a bit, and I question the need for exceedingly higher overall and limiting bitrate settings. For the past week, I've been using the following settings (w/ Sandisk 8GB Extreme Class 10).

NATIVE 24P = CHECKED
FHD/SH = 50000000
H = 36000000
L = 26000000
OVERALL = 50000000
LIMITING = 50000000
PRESET BITRATE1 = 500
PRESET BITRATE2 = 500

After endless firmware reflashes, it seemed to me that AVCHD clearly begins choking at roughly 53mpbs or so. I began to think about the logic of using overall and limiting bitrates that could exceed 53mbps.. and of what use could higher values really be? So I opted to set FHD/SH, overall, and limiting to the same value. I could be mistaken in this approach, but liken the idea of it being a brick wall of sorts where no value exceeds the AVCHD processing limits of the camera.

So far, I have not noticed rogue p frames.

Black test (FHD/24PN)...
http://creativepeoples.com/GH13/modulr_24PN_black.png

Star chart (FHD/24PN)...
http://creativepeoples.com/GH13/modulr_24PN_star.png


Would be interesting if anyone else could confirm, as I've had zero issues shooting 24PN over the past week.

Adventsam
07-18-2010, 01:13 AM
Yesterday I went for really high bits and was actually missing frames, this was 60,62,70. Going to give these a try today, nice and clean at low level.

PappasArts
07-18-2010, 02:02 AM
Interesting finds.

I have been exploring the AVCHD 24PN a bit, and I question the need for exceedingly higher overall and limiting bitrate settings. For the past week, I've been using the following settings (w/ Sandisk 8GB Extreme Class 10).

NATIVE 24P = CHECKED
FHD/SH = 50000000
H = 36000000
L = 26000000
OVERALL = 50000000
LIMITING = 50000000
PRESET BITRATE1 = 500
PRESET BITRATE2 = 500

After endless firmware reflashes, it seemed to me that AVCHD clearly begins choking at roughly 53mpbs or so. I began to think about the logic of using overall and limiting bitrates that could exceed 53mbps.. and of what use could higher values really be? So I opted to set FHD/SH, overall, and limiting to the same value. I could be mistaken in this approach, but liken the idea of it being a brick wall of sorts where no value exceeds the AVCHD processing limits of the camera.

So far, I have not noticed rogue p frames.


Would be interesting if anyone else could confirm, as I've had zero issues shooting 24PN over the past week.

modulr,

Very interesting find- I wonder if you even need the H and L settings- So the star chart didn't give you a write error? What was the data rate on the star chart test shot?

Pappas

crunchy
07-18-2010, 02:33 AM
What was the data rate on the star chart test shot?

According to the attached results (I frames of about 442kB and P frames of about 60kB) it shouldn't be much higher than 17Mb/s. It's surprising. :huh:

On the other side, black test is similar to Chris's results, except that there are no rogue frames.

PappasArts
07-18-2010, 02:45 AM
According to the attached results (I frames of about 442kB and P frames of about 60kB) it shouldn't be much higher than 17Mb/s. It's surprising. :huh:

On the other side, black test is similar to Chris's results, except that there are no rogue frames.

17mbits would be very bad if that is true. When filming the star chart or the codec chart I've posted- you usually push the codec to record at it's highest bi-rate. My start charts whether Mjpeg or AVCHD always pushed the top end mbits. So if it only recorded 17mbs with all that detail in the chart, that's bad- it should have excited the codecs VBR to rise to it's ceiling.. Now I'm assuming that your interpretation is correct though.


Pappas

modulr
07-18-2010, 09:04 AM
Indeed, something strange is going on here... as these settings have given me bitrates of 46mbps (as described earlier in this thread). I'm backtracking my steps.

svecher
07-18-2010, 09:18 AM
According to the attached results (I frames of about 442kB and P frames of about 60kB) it shouldn't be much higher than 17Mb/s. It's surprising. :huh:

Numbers on Y axis in StreamEye are bytes, so to calculate bitrate in bits multiply that by 8. Also, size in bits is shown when additional picture tab is checked (see screenshot).


On the other side, black test is similar to Chris's results, except that there are no rogue frames.FWIW, I have not been able to produce rogue frames in high-detail static shots anymore. I have only seen them with "real-life" footage.

cbrandin
07-18-2010, 09:31 AM
Pappas,

In the black tests the Preset Bitrates didn't appear to have any effect on 24p. With the other tests I did using the high detailed scene the Preset Settings didn't seem to make the streams look any different, but stability was significantly affected - it was worse with the settings set to 500. If i started the capture out of focus, it didn't fail often, if I started in focus there was usually a failure very quickly (less than 1 second, usually within 1/3 of a second). As far as instant failures were concerned the Native 24p setting didn't seem to make much difference; it seemed more of an issue later in streams.

Rambooc1,

I have no idea why H and L settings affect FHD and SH modes - I just know that they do. I tried al sorts of tests to try and determine if those settings had any effect on image stream data when capturing in FHD or SH modes - and they do not. I thought that maybe there was a layered approach to the encoding where H an L settings would come into play under certain circumstances but I could find no evidence of that. The only thing I can think of is that somehow buffer allocation is being affected or some other mechanical aspect of the CODEC not affecting the final output (except that it causes failures).

Modulr,

Those are very interesting results! I'll have to try out some of your ideas in my tests. I've never quite understood what Video bitrate does because the AVCHD CODEC seems to go as low as it can (which is much lower than the Video Bitrate setting), and then as high as it can (up to the Limiting Bitrate). I haven't seen any evidence that the average is particularly close to the Video or Overall bitrates.

Chris

cbrandin
07-18-2010, 09:56 AM
Svecher,

According to the EyeStream manual the bars' Y value is frame size in bytes, and that agrees with the info panels. I think the other settings show the size of certain parts of the frame data like coeffecients and vectors, etc... Frames do contain data other than picture data so I would expect picture data to always be somewhat smaller than frame data.

Chris

svecher
07-18-2010, 10:10 AM
According to the EyeStream manual the bars' Y value is frame size in bytes, and that agrees with the info panels. I think the other settings show the size of certain parts of the frame data like coeffecients and vectors, etc...

Chris, you are right; those numbers are bytes. From example I listed frame size is 249,444 bytes x 8 = 1,995,552 bits. I visually picked the most average looking frame, so 1,995,552 x 24 = 47,893,248 bps (which is in the ballpark with that StreamEye is reporting in Stream Info session.

I'll amend my note, so an not to contribute to confusion.

modulr
07-18-2010, 10:55 AM
While I still don't understand why my posted settings are yielding entirely different bitrate results than when originally tested... I went back thru the real life footage shot this past week, and it's in line with Svecher's observations. Static testing type shots, no rogues.. but real life, yes.

cbrandin
07-18-2010, 10:59 AM
I should amend what I said before. I have seen that Video Bitrates approach settings when high detailed scenes are captured. I have also seen that setting Limiting Bitrate too high causes failures. Looking at data from modulr it seems that the difference between Limiting and Video Bitrates is what is creating the opportunity for rogue frames to appear.

Does this mean that the effect of having a higher Limiting Bitrate than a Video Bitrate does nothing except offer the opportunity to have big ending P frames containing garbage? I know that sounds strange, but what other inference can we draw?

There is audio data and metadata, so there is an argument for having Overall Bitrate a little higher than Video Bitrate. Maybe a good theory to test would be to try settings where Video Bitrate is X, Overall Bitrate is X+2000000, and Limiting Bitrate is equal to Overall Bitrate. Or maybe try leaving Limiting Bitrate unchecked.

I'm going to test this out with the black test and see if I can make the SH mode rogue frames go away. Obviously, if this works it won't fix H and L modes unless they are set to the same value as SH mode - which is useless. Besides, I already know that there is an interaction problem anyway. There is obviously still a rogue frame problem with progressive modes, we'll just be masking it. Eventually, hopefully, that bug is found and eliminated.

I wonder if the Limiting Bitrate is used by the card writing routine to determine how frequently to empty buffers based on flash memory burst capabilities. If so, that might degrade IQ somewhat because the CODEC can't spend as much time processing if buffers need to be emptied sooner. Or, maybe IQ will be the same but compression will be less effecient - that would be OK. Or maybe it just won't matter - which would be cool.

What happens if Limiting Bitrate is lower than Video Bitrate? Does it fail? If not that would imply that Video Bitrate controls the maximum average bitrate for detailed scenes and that Limiting Bitrate controls how much data can be buffered before a memory card write. That would mean that Limiting Bitrate controls how often flash memory is written - not a maximum stream bitrate. Does anybody have any data that tested this out (modulr - hint... hint... nudge... nudge...)?

Chris

modulr
07-18-2010, 11:25 AM
What happens if Limiting Bitrate is lower than Video Bitrate? Does it fail? If not that would imply that Video Bitrate controls the maximum average bitrate for detailed scenes and that Limiting Bitrate controls how much data can be buffered before a memory card write. That would mean that Limiting Bitrate controls how often flash memory is written - not a maximum stream bitrate. Does anybody have any data that tested this out (modulr - hint... hint... nudge... nudge...)?

Hehe.. Video bitrates > Limiting bitrate lock up the camera. It won't even begin to record... (tho I was testing more extreme numbers at that point in time). Might be worth a revist.

cbrandin
07-18-2010, 12:48 PM
Nah, I tested Limiting < Video and it always crashes. I guess that theory was crap.

One interesting thing though - leaving Overall Bitrate unchecked even with Video Bitrate set to 50000000 didn't. So what does Overall Bitrate do? Either it doesn't do what we think or the Panasonic firmware is so devoid of error checking that it just lets the buffer overrun.

Oh well... Back to the drawing board. Sorry to have wasted your time.

Chris

cbrandin
07-18-2010, 12:54 PM
One would think that using a parameter driven codec would have buffers allocated according to those parameters. Do you suppose Panasonic may have allocated buffers statically and they don't change when parameters are changed? That would explain some of the random stuff we are seeing. Come to think of it, how would they do that without re-compiling unless buffers are allocated at runtime?

Chris

Grunf
07-18-2010, 01:26 PM
Come to think of it, how would they do that without re-compiling unless buffers are allocated at runtime?

Chris

It's quite common to use dynamic memory allocation. In C you usually use malloc (); and free ();

noirist
07-18-2010, 01:59 PM
It's quite common to use dynamic memory allocation. In C you usually use malloc (); and free ();
Yes but dynamic memory allocation is much much slower than static memory allocation. With such limited computational resources as are available on the GH1, I would be very surprised if the programmers used malloc() unless they absolutely had to. They might use calloc() for dynamic memory allocation on the stack but again I would be surprised since calloc() is slower than static memory and its hard to see that they wouldn't know the size of all their buffers in advance. So I agree with cbrandin, with high probability all the buffers are allocated at compile time.

cbrandin
07-18-2010, 05:06 PM
A little more information about rogue frames... I tore apart streams with rogue frames (both 24p FHD and SH files) to see if I could identify what is in the rogue frames. They appear to contain some valid image data - about the same amount as normal P frames - plus hundreds of packets of null data.

Stream data basically consists of fairly small packets of data (most are 192 bytes long). These packets start with headers that contain sequence counters, packet type, etc.... This non-image metadata is 8 bytes long - the rest of the packet is actual image data (or audio, but not in this case). The first image I have attached is what a normal packet of image data should look like (the highlighted part is one packet). The second image is what one of these "rogue" packets looks like. As you can see, aside from the header data they are empty. Rogue frames contain hundreds of these null packets and they don't appear anywhere else.

Not sure if this is useful to anybody, but I thought it was interesting.

Chris

svecher
07-18-2010, 09:16 PM
After endless firmware reflashes, it seemed to me that AVCHD clearly begins choking at roughly 53mpbs or so. I began to think about the logic of using overall and limiting bitrates that could exceed 53mbps.. and of what use could higher values really be? So I opted to set FHD/SH, overall, and limiting to the same value. I could be mistaken in this approach, but liken the idea of it being a brick wall of sorts where no value exceeds the AVCHD processing limits of the camera.

So far, I have not noticed rogue p frames.

Would be interesting if anyone else could confirm, as I've had zero issues shooting 24PN over the past week.
Unfortunately, I cannot confirm. Shooting the Death Chart with the following settings:


[Information]
Comment=modulr's ALL 50Mbit and graduated H/L settings
SD_Card=Sandisk Extreme Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Native 24p/25p=Checked
Video Bitrate FHD/SH=50000000
Video Bitrate H=40000000
Video Bitrate L=32000000
Overall Bitrate=50000000
Limiting Bitrate=50000000
Preset bitrate=500
Preset bitrate 2=500
I produced a rogue frame on the first try (see screenshot). It was quite a large one too - 3MB is 24 Mbit -- full second bitrate allotment under standard spec consumed in only 1/24th!

Rogue frames or not, Preset Bitrate patches seem to have increased the stability of 24p/25p patch remarkably. We used to think that rogue frames were the cause of freezing, but I'm not so sure anymore.

crunchy
07-18-2010, 11:57 PM
Video bitrates > Limiting bitrate lock up the camera. It won't even begin to record...


Nah, I tested Limiting < Video and it always crashes. I guess that theory was crap.

What is the difference between both quotes?!?

crunchy
07-19-2010, 12:34 AM
I produced a rogue frame on the first try (see screenshot).

Was it shot hand-held or by using a tripod?

svecher
07-19-2010, 06:51 AM
What is the difference between both quotes?!?
There is none. Video bitrate setting higher than Limiting bitrate will cause instability.


Was it shot hand-held or by using a tripod?
I always shoot Star chart on a tripod unless otherwise noted. I'm not sure this test can be classified as completely static, as scanning lines appear to add some "motion" to the frame.

crunchy
07-19-2010, 07:31 AM
I always shoot Star chart on a tripod unless otherwise noted. I'm not sure this test can be classified as completely static, as scanning lines appear to add some "motion" to the frame.

And it survived with Native 24p/25p settings? Very good, indeed! I'll have to try with SanDisk Extreme 30MB version. However, it would be much more helpful if we would clearly understand what bitrate numbers in PTools really mean and what are inner camera speed restrictions.

svecher
07-19-2010, 07:53 AM
However, it would be much more helpful if we would clearly understand what bitrate numbers in PTools really mean and what are inner camera speed restrictions.
"You just ask the impossible." (c)

Clear understanding will come from either internal Panasonic specifications/documentation/software (still waiting for volunteers to try that route) or by attempting to establish and analyse patterns produced by repeated shots in the dark (no pun intended) with what really amounts to as a tweak here and there.

modulr
07-19-2010, 08:09 AM
@Crunchy.. seems that AVCHD can't really handle sustained bitrates of much more than 53mbps (and that rate will usually cause an error pretty fast). It's evidently much more processesor intensive (which makes sense), as mjpegs can be written at significantly higher speeds.

more strangeness...

Panned on some trees and other foliage.
http://creativepeoples.com/GH13/fooliage_not_static_24PN.png

Note the rogue p-frame, followed by three i-frames.

Each i-frame in that cluster has a different GOP#, even tho there is no actual group (no p-frames) for two of them.

cbrandin
07-19-2010, 09:22 AM
crunchy,

There isn't any logical difference between the quotes. I was agreeing with him and just meant that there was no need to confirm the findings. It was my theory that was crap, not his.

Chris

cbrandin
07-19-2010, 09:27 AM
modulr,

Yeah, I've captured several 1080 rogue frames that show multiple I frames in a row, empty frames, non-key I frames (I don't even know what that is), etc... I guess whatever breaks every now and then really breaks hard sometimes.

I'm impressed that your card actually recorded all that data instead of simply producing a write error. I suspect the reason we rarely see these kind of captures is because they usually result in a lockup or write error.

Have you got a hex editor? It might be interesting to confirm that the rogue I frames contain a bunch of null data. You can do that by looking at data between the offset value (shown in a popup when you place the cursor over one of the frame bars) and the next frame's offset value. I believe you can get a free version of "Winhex" (a very good hex editor) to look at the file.

Chris

Vitaliy Kiselev
07-19-2010, 09:28 AM
Guys, anyone able to write simple utility to look for this zero blocks and finding showing all information we have about them.
I need to know location of this bug, as we can have bug in TS muxer and not related to video encoder at all.

cbrandin
07-19-2010, 09:43 AM
I'll take a crack at it for you. The files look pretty easy to parse into these little blocks. Does C# work for you?

Chris

modulr
07-19-2010, 09:59 AM
Have you got a hex editor? It might be interesting to confirm that the rogue I frames contain a bunch of null data. You can do that by looking at data between the offset value (shown in a popup when you place the cursor over one of the frame bars) and the next frame's offset value. I believe you can get a free version of "Winhex" (a very good hex editor) to look at the file.

Chris

Loaded up the hex editor. Unfortunately it seems this particular scene is not loaded with nulls on any of the rogue frames.

cbrandin
07-19-2010, 10:08 AM
They can be a little hard to find. Search for "47 10 11 1x 00 00 00 00" (where x can be any value). If you want to avoid wildcards, just use 1 for x. With big files Winhex's scroll bars can zip right past the data and you'll never see it.

I'm going to write a little utility that finds them automatically.

Chris

Vitaliy Kiselev
07-19-2010, 10:29 AM
Problem is not only to find them.
But understand that this constant header mean.

As for C# - it is not important as it is one time utility.
Useful thing could be to make simple TS file parsing to just see different blocks and their types and indicate this rogue blocks.
As we can see StreamEye bug on top of GH1 bug here.

DaLiV
07-19-2010, 10:38 AM
give sample file with 0x00 blocks - i'll decode that headers.

svecher
07-19-2010, 10:45 AM
They can be a little hard to find. Search for "47 10 11 1x 00 00 00 00" (where x can be any value). If you want to avoid wildcards, just use 1 for x. With big files Winhex's scroll bars can zip right past the data and you'll never see it.

Chris, non-null rogue frame here as well. Also, header is 47 50 11.

DaLiV
07-19-2010, 10:50 AM
that is subframe information ... need analyze full frame between previous 000001 and next 000001 pattern, as it is packet header, and there will be info about that subheaders is auduo/video/system information or anythyng else ...

cbrandin
07-19-2010, 10:51 AM
The rogue frames do contain some valid data - it's just that there are null frames appended to them - so they appear a little bit before the next frame starts.

Chris

cbrandin
07-19-2010, 10:58 AM
Vitaliy,

I've started on the utility. The blocks are all 192 bytes from beginning to end. The headers look to be fairly easy to decode as well, I just have to figure out what they all mean and at what level they are operating. Shouldn't take me more than a day or two.

If you let me know which version of the MS C# compiler you use I'll make sure to produce a source code project that is compatible.

Chris

Vitaliy Kiselev
07-19-2010, 11:05 AM
Vitaliy,

I've started on the utility. The blocks are all 192 bytes from beginning to end. The headers look to be fairly easy to decode as well, I just have to figure out what they all mean and at what level they are operating. Shouldn't take me more than a day or two.
If you let me know which version of the MS C# compiler you use I'll make sure to produce a source code project that is compatible.
Chris

You can look at Elecard utility for block info.
Also look at TS specifications.

As for C#, I don't use it at all, so any MS compiler will do :-)
You can finely make this utility yourself without looking at me.

cbrandin
07-19-2010, 11:16 AM
DaLIV,

You can produce your own files.

Using Native 24p/25p will pretty much always produce rogue frames, even if nothing else has been changed in the firmware.

For the "black" test use these settings and shoot with the body cap on instead of using a lens. The first will produce 1080 24pN rogue frames in FHD mode on every second GOP. SH, H, and L modes will too. In fact as far as I can tell, all 720p modes produce rogue frames with the "black" test, even with the factory firmware.

[Information]
Comment=Settings H
SD_Card=Transcend Class 10
Camera=GH1 v1.32
[Settings]
Prevent version compare=Checked
Native 24p/25p=Checked
Video Bitrate FHD/SH=50000000
Overall Bitrate=52000000
Limiting Bitrate=60000000

Chris

cbrandin
07-19-2010, 11:18 AM
Vitaliy,

Yup, that's what I'm doing. OK, I'll just use the latest version of C#. You can get a free version of C# anyway, if you want to.

Chris

Vitaliy Kiselev
07-19-2010, 11:25 AM
Yes, it seems that bug had been present in firmware for long time.
As all that 24p patch does is to switch progressive flag (and this is on for 720p by default).
Generally Panasonic firmware style break countless rules on module based programming.
As each module have clear assumption of input data parameters and uses inside constants directly related to this, instead of asking parent module or calculate constants from known input parameters.
But Panasonic is quite good, as I know other company who uses up to 7 layers of abstraction even for simplest things in their products. I don't even know how they made it work. And this products sell in millions :-)

svecher
07-19-2010, 11:29 AM
give sample file with 0x00 blocks - i'll decode that headers.
DaLiV, screenshots I posted earlier are for this (http://www.sendspace.com/file/kzlmlh) file. I searched for long null sequences but couldn't find them. Maybe you'll have better luck. Thanks.

modulr
07-19-2010, 11:41 AM
Maybe null data in the rogues is associated with the black test? Like svecher, I'm not finding any.

Original file (right click save as) (http://creativepeoples.com/GH13/00075.MTS)

DaLiV
07-19-2010, 12:51 PM
checked. simple gui not correctly parse and display content.
on 00075.mts (modur) :
frame# @ GUI @ frame POSITION identified by "picture parameter set" field (search for 0000000168) which persist before each frame I or P ... in file @ frame type
106 @ 17a8704 @ 17a872e @ P
107 @ 17d75c4 @ 17d75ee @ P
108 @ 1a7eac4 @ 18061dd @ I
109 @ 1d3a184 @ 186bd2e @ P
110 @ 2005ec4 @ 18a0fae @ P
in gui #110 slice is in fact #144

anomalies found :
slice #108 breaked by PAT and PMT fields of stream (PID 0, PID 0x100, PID 0x1001) -< seems that is reason why streameye GUI continue calculation between slices and sum some slices to one (not sure).

same situation on file of svecher. so file contents seems ok.

check frame count in your media player and streameye ... you will see diffirence between frame counts ...

svecher
07-19-2010, 09:18 PM
Ok, so if I understand you correctly there are no rogue frames in stream, but there are anomalies nevertheless? Could you please explain the nature of these anomalies?

modulr
07-20-2010, 02:57 AM
Started looking into the MTS a bit deeper with http://www.bitstreamtools.com and have come to the conclusion, the rogues do not exist. I'm unsure if the fact that PAT/PMT tables show up in the middle of slice data as DaLiv suggests is the reason StreamEyes can't handle it... but unfortunately this is a bug imho. Frame counts are incorrect in StreamEye when there are "rogue" frames, meanwhile nearly any application that can playback MTS will give you a correct count. Rogues are StreamEyes combining frames for a GOP into a single P/I frame. It could be as simple a DaLiV suggests. If you look at my MTS file, you'll see the GOP # change with each rogue I Frame. If you multiply the number of rogues by 12 (size of the GOP for 24P), you will account for the number missing frames. Beyond that, the actual data in the MTS files are valid, and the link for TSPacket Editor above demonstrates that I frames and P frames are properly layed out according to GOP.

(I hope I made sense.. lol, need sleep)

Vitaliy Kiselev
07-20-2010, 03:31 AM
This is main reason why I wanted to use something beside StreamEye, as it is generally very buggy thing.

DaLiV
07-20-2010, 05:36 AM
Vitaliy Kiselev : take a look to product near streameye ...
http://www.elecard.com/products/products-pc/professional/stream-analyzer/
seems that tool more adequate then streameye (screen show packet analyzing inclusive of internal structures of each frame of transport stream) .


have tested on previous files = H.264 supported, structure shown correctly (each packet structure, address in stream and size may be easyly got, not more need manual searches :) )

svecher
07-20-2010, 07:16 AM
That's too bad ... I was just beginning to like StreamEye; it's nice to see a graphical representation of the stream. Stream Info panel is generally spot on as well (well max bitrate is incorrect as we know now).

FWIW, their StreamEye Pro product (http://www.elecard.com/products/products-pc/professional/streameye-studio/)is afflicted with the same bug (see attached screenshot). Perhaps someone with sufficient knowledge of the problem can report it to them. Who knows, maybe they'll be willing to beta test their development stuff with this project ;)

Vitaliy Kiselev
07-20-2010, 08:56 AM
Can we move back to writing our own small analyser?

cbrandin
07-20-2010, 09:09 AM
I've been working on a utility that parses streams. All I've done so far is look at the TS headers, which can be used to identify frames. The streams are broken up into 192 byte packets with a 8 byte header where the first 4 bytes are a sequence counter, the next 3.5 bytes identify packet type, and the remaining nibble is simply a counter. For example, you might see an 8 byte value at the beginning that is 07 F5 54 20 47 10 11 1A. The first 4 bytes (07F55420) are simply a counter that increments by 2F0 with each frame (in this example). The second 4 bytes (4710111x ) appear to indicate packet type, except that the "x" simply cycles with each packet. Frame starts have a value of 47 50 11 1x This is where StreamEye starts each frame (offset). The length they report is simply the distance to the next starting packet, which is the next packet that has 47 50 11 1x in bytes 4-7 of the header.

This means a couple of things: The frames are not just video, they can also contain audio. If there is some kind of other data in these packets Streameye is not differentiating it, it just considers everything a video frame. The rogue frames could be anything.

There are several kinds of packets I've seen with different values in bytes 4-7 of the headers, but I haven't figured them all out yet.

The empty frames I've found seem to appear in the "black" tests, but not otherwise. When they do appear they have a code of 47 10 11 1x, which is also the most common type of packet for legitimate video data.

In order to differentiate frame type a deeper drill-down is necessary. I'm working on this. Pretty soon we should have a little utility that does what the StreamEye chart does, except that it will differentiate audio, video, empty frames, etc... I don't plan to do any of the fancy video stuff, though - that would take too long. Hopefully, I'll have a rough version available in a couple of days.

Chris

cbrandin
07-20-2010, 09:17 AM
I'm also putting a feature in that dumps analysis metadata and other stuff into a CSV file for use with a spreadsheet.

Chris

Vitaliy Kiselev
07-20-2010, 09:21 AM
We don't want any video stuff, in fact.
All we want is understand that this is in low level.
You can look at any available TS demuxer sources.

P.S. I suggest you to look for Hex viewer components for C#, They must be easy to integrate.
Something like simple grid and HexView upon click on the row.

cbrandin
07-20-2010, 09:45 AM
Yeah, I'm looking for widgets now. The hex stuff is easy, I've already done that. Now I'm looking for a simple, free, barchart widget. I want one that can do stacked bars so I can show headers, video, audio, other, and empty packets in a bar that represents one frame.

Using the simple parsing method I described above I've already gotten the results shown in the first attachment below. Obviously, I haven't put the other data in yet. The offsets and frame sizes are exactly the same as what StreamEye reports (see second attachment). Note the big frame at frame 24 - it is a rogue as it contains null data packets (this was a 24pN black test).

Chris

cbrandin
07-20-2010, 09:49 AM
Oops! I just noticed that StreamEye starts at frame 0 and I start at frame 1 - I'll fix that.

Chris

cbrandin
07-20-2010, 10:40 AM
Just switched over to Visual Studio 10 - looks like it has everything I need!

Chris

cbrandin
07-21-2010, 12:10 AM
I thought I'd give you all a heads up on my stream analyzer utility.

I've got most of it working, but I still need to add the code that differentiates I and P frames - hopefully I get that done tomorrow.

Features:

The left hand panel lists individual frames. It correctly assembles the frames according to selected frame type giving the actual length of the frame and the correct offset (unlike StreamEye).

The middle panel lists the packets that constitute the selected frame. It lists the frame type (including null and empty frames - for rogue analysis).

The right hand panel provides a hex dump of the selected packet.

The chart on the bottom works pretty much like StreamEye's chart. I haven't added coloring to it yet. When I do there will be colors for I & P frames as well as indicators for empty and null packets within frames.

Chris

crunchy
07-21-2010, 12:29 AM
Congratulations! This is fantastic! :thumbsup:

Hardly waiting to test my footage with your stream parser...

svecher
07-21-2010, 06:57 AM
The chart on the bottom works pretty much like StreamEye's chart. I haven't added coloring to it yet. When I do there will be colors for I & P frames as well as indicators for empty and null packets within frames.

Very impressive, Chris. Loving the chart! and looking forward to the first test drive ;)

Vitaliy Kiselev
07-21-2010, 07:29 AM
Impressive.
Righ now we are going the righ way, as good tools are always necessary.
The more tools we have the more stable progress we'll see in our project.

modulr
07-21-2010, 09:43 AM
Talents hard at work. Excellent!

cbrandin
07-21-2010, 03:58 PM
Here's the first cut at the utility. Just Unzip the file somewhere and run Setup.exe. It will install everything you need.

Notes:

I haven't had much time for testing (obviously), so let me know if you have any issues. I've only run it on my Windows 7 x64 machine, so I can't be sure about compatibility with other systems. No reason it shouldn't work though.

It's pretty obvious how to use it. One thing, though, the column headers can be used to sort packets according to what is in those columns. So remember to click on the Frame, or Packet column headers to put the sorting back.

You drill down by clicking on a row in the Frames box to get a list of Packets. Then click on a row in the Packets box to get a hex dump of that packet.

The Packet Type column usually indicates "V" for video, if the Packet is empty it will indicate "VE".

The program requires .NET v4, which it will try to go get if you don't have it installed.

You will notice that the offsets and frame sizes are somewhat different than what StreamEye shows - that's because they got it wrong, not because I did.

The program can't handle more than 1,000,000 frames at this point - so don't look at real long files. Better to stay with clips not longer than several minutes anyway.

The program is a lot faster that StreamEye on my system. Let me know how it performs for you.

The "Stream Type" menu item doesn't do anything yet.

Have fun! Let me know how this works for you.

Chris

rambooc1
07-21-2010, 04:31 PM
Thanks Chris, will try it. Just one question. Will the ""other"" (grey box) show B frames from a HMC 152 AVCCAM version of AVCHD?

R

cbrandin
07-21-2010, 04:33 PM
No, I've only figured out the GH1 stuff. Actually, I have no idea what it will do. Try it and let me know.

Chris

rambooc1
07-21-2010, 04:54 PM
No, I've only figured out the GH1 stuff. Actually, I have no idea what it will do. Try it and let me know.

Chris

Cool, thanks.

Phil Seastrand
07-21-2010, 05:27 PM
Can you support opening both MTS and M2TS files?

cbrandin
07-21-2010, 06:42 PM
No, Just MTS. I wrote this specifically to debug the GH13 AVCHD mode. I haven't tested it on anything else. It relies on a specific PID to identify Video streama, so I doubt it will work with anything else.

Chris

cbrandin
07-21-2010, 07:35 PM
I just installed on a Windows XP x86 machine and everything seems to work fine.

Chris

modulr
07-21-2010, 08:03 PM
Hmm, just attempted to install it via VMWare (running Windows XP) on OS-X, and it failed when trying to install some .NET business. :( I'll give it another go tho.

I'm roughing together something similar for OSX. Question, can you post your black .MTS with rogues for download. So far, in my preliminary analyzer app.. I'm still not seeing rogues in footage that show up as rogues in StreamEyes. I'm also getting accurate frame counts vs. StreamEyes. I'm curious if your black .MTS will show something different.

Keep up the hard work. :)

svecher
07-21-2010, 09:28 PM
Here's the first cut at the utility. Just Unzip the file somewhere and run Setup.exe. It will install everything you need.

I ran setup.exe on Win 7 x64 and .Net 4 got installed automatically. After that I saw a message about corrupt application settings (see attached error log). I just re-ran the install and it worked fine.

What can I say -- this little app is fast! By that I mean iPhone fast. StreamEye takes forever to open certain MTS files (especially the ones it thinks have rogue frames). Yeah, speaking of ... Look, ma, no rogue frames!!! Thanks for putting those bars in, btw.

The only slowdown I saw was when switching from one frame to the next -- it takes about 2 seconds or so. Would love to see Stream Info panel next!!!
Because then we can say good bye to venerable EyeStream :nads:

Lpowell
07-21-2010, 09:55 PM
Thanks for your diligent work, cbrandin. After installing the GH13 Stream Parser, I examined the set of test files I ran on May 20, when I first noticed the rogue frames reported by StreamEye. Result: no rogue frames appeared in any of my test files. I think you may have just laid to rest both StreamEye and its mythical rogue frames.

rambooc1
07-21-2010, 10:09 PM
Thanks for your diligent work, cbrandin. After installing the GH13 Stream Parser, I examined the set of test files I ran on May 20, when I first noticed the rogue frames reported by StreamEye. Result: no rogue frames appeared in any of my test files. I think you may have just laid to rest both StreamEye and its mythical rogue frames.

Yes can confirm the same, no rogue frames where once there were. ( Streamparser works fine = we now have 2 Legends on the GH13 hack forum)

The I frames in NATIVE mode are still much bigger proportionally to those in 50i for the same scene, so nothing has changed there.

The key to stable NATIVE using svercher's settings (but PAL) appears to now be compulsory class 10 30Mbps card ............B and H here i come.

R

cbrandin
07-21-2010, 10:12 PM
I think you found something interesting. On my test files the rogue frames do show up, because they are part of the video stream. My utility differentiates between stream types whereas StreamEye lumps them all together. My rogue frames contain data that is put into the video streams. Your rogue frames are apparently being put into some other stream type - maybe audio.

The next version of the Stream Parser utility will also be able to show audio and other types of streams. It should be done in a few days.

It seems the extra rogue data is just being added to whatever streams are running at the time. Interesting..... This is exactly why I put this program together.

As for the installation problems - the program requires .NET v4 and will fail if it is not installed. The installation program should get it for you if it is not currently installed. Obviously, though, if you can't download from Microsoft it won't work. You can download it from Microsoft separately, install it, and then my installation program will see that it is already installed and go to installing the utility directly. As for Windows emulators running on Macs, for example, I'm not overly hopeful that it will work.

There is a delay when you select a Frame because it has to parse all the packets and look for empty packets (which, by the way, are different than the standard defined null packets) - which takes a little time.

Chris

modulr
07-21-2010, 10:13 PM
*edit*

Now the question is, why are you seeing rogues in your black tests. Knew something was odd, because the frame counts in StreamEyes were just totally off when "rogues" appeared which suggests StreamEyes is still doing something wrong beyond just lumping things together.

cbrandin
07-21-2010, 10:25 PM
Run the black test with the C settings, or SH, H, or L mode and you'll see plenty of rogue frames in the video streams. Of course, this could be normal if Panasonic chose to maintain a minimum data rate. The standard accommodates this normally with null frames, which are different than the empty frames I see. If Panasonic has done this it seems rather wasteful and stupid to me. It's not like this is video data being sent over an ATM switch (which is where these streaming protocols came from).

The rogue frames are still there and causing a problem - they're just often not in the video stream - which would explain why there is no apparent visual change because of them.

StreamEye just measures the distance between video frame starts lumping all frames - video, audio, timing, etc... - together, which is really not a valid measurement. Currently, my utility only looks at video frames. The next version will offer options to filter in or out all frame types. Then we'll be able to see where this extra data is being put.

Chris

cbrandin
07-21-2010, 10:28 PM
Some of you have files that show things like two I frames in a row, etc... Can you see if they still show up that way and let me know?

As for the rogue frames in the black tests. Panasonic may be just be trying to maintain a minimum bitrate (which is really dumb), so they might not really be rogues. If you run the black test in SH, H, or L mode you'll see really HUGE , mostly empty, rogue frames every second GOP right before the next I frame. They are so big that you really can't see the other frames.

Chris

cbrandin
07-21-2010, 10:41 PM
Come to think of it, I haven't really confirmed that there are big blocks of extra data except in the black tests. I'll be very interested to see if there is extra data (irrespective of which stream it is in) in normal tests or not. Our next adventure....

Chris

PS It sure would be nice if the entire rogue thing wasn't really there. Probably too much to hope for.

Lpowell
07-21-2010, 10:50 PM
The rogue frames are still there and causing a problem - they're just often not in the video stream - which would explain why there is no apparent visual change because of them.

StreamEye just measures the distance between video frame starts lumping all frames - video, audio, timing, etc... - together, which is really not a valid measurement. Currently, my utility only looks at video frames. The next version will offer options to filter in or out all frame types. Then we'll be able to see where this extra data is being put.
No wonder StreamEye was producing "rogue" video frames - it was failing to separate the video stream from the rest of the data. I didn't suspect a sophisticated tool could be making such a fundamental mistake.

cbrandin
07-21-2010, 10:56 PM
Yeah, StreamEye doesn't really do a very good job with MTS files (it doesn't even recognize the suffix).

If you're sure you have .NET v4 installed you can run "GH13StreamParser.exe" without installing it (it's buried in the "Application Files > GH13StreamParser_x_x_x_x" folder.

Chris

Lpowell
07-21-2010, 11:10 PM
I haven't really confirmed that there are big blocks of extra data except in the black tests.
I just reproduced your results with a black lens cap video. I'm using a 10-frame GOP and every third GOP is producing a huge P-frame at the end. Each I-frame is 11kB, normal P-frames are 192 bytes, and the huge P-frames are 178KB. This is with a 720p @ 30fps AVCHD file on the GF1.

cbrandin
07-21-2010, 11:20 PM
That means that they are padding the stream every one second, rather than every second GOP. I guess this means that the black test rogues aren't rogues at all, they are padding.

Now, on to finding where the extra data in what was previously thought to be rogue frames is going. I can't imagine why another type of stream would produce so much data. I guess we'll find out.

Chris

Phil Seastrand
07-21-2010, 11:22 PM
No, Just MTS. I wrote this specifically to debug the GH13 AVCHD mode. I haven't tested it on anything else. It relies on a specific PID to identify Video streama, so I doubt it will work with anything else.

Chris
I understand this is only for the GH1. I was asking that the open dialog accept both extensions since the import tool renames the files upon import. Not a biggy as I can still open the file, just not as easily.

Lpowell
07-21-2010, 11:26 PM
Now, on to finding where the extra data in what was previously thought to be rogue frames is going. I can't imagine why another type of stream would produce so much data.
Could it be the audio packets?

cbrandin
07-21-2010, 11:35 PM
Get a load of this!

This is the same file processed by StreamEye and then by GH13StreamParser (see attachments). StreamEye is obviously botched.

Now I'm really questioning the whole rogue thing. I wonder if rogues are really an entire GOP appended to a frame by StreamEye because it doesn't parse the video frame correctly. Note that there is a difference in the number of GOPs reported between the two.

I should be able to confirm this in a day or so.

Chris

modulr
07-21-2010, 11:51 PM
That is what I concluded earlier in the thread. It has nothing to do with lumped data. '47 50 11' is start of the frame... if you lump all the bytes between these, you will not see rogues as StreamEyes reports. I've done this on live footage, and what you'll see is a proper spread of I and P frames. But more importantly, you will see a correct frame count. The frame counts in StreamEye when there are rogues are flat out wrong. If a MTS is displaying a real 287 frames, but StreamEye is only show 251 + rogues, it's doing some seriously wrong... namely it does stuff an entire GOP into a P or I frame at times (and probably other nasties). If you look at the 0075.MTS uploaded a while back, you can see the GOP# jump on the I frame rogues that sit next to each other... suggesting it's placed an entire GOP worth of data into each rogue. When you divide the size of the rogue by GOP, you get a byte size for the frame that's right on par with the rest of the spread. Indeed, Streameye is just flawed.

crunchy
07-21-2010, 11:55 PM
Here's the first cut at the utility.

This is great!

There is only one problem with initialisation of stream frames slider min value. If you move slider to the right more than it is the length of the next clip loaded, you cannot see graphical representation of Stream Frames. When loading next file, please, re-initialize minimum slider value to 0.

Otherwise it is excellent utility.

Maybe it would be wise to add average data rate and average data rate between two consecutive I frames after selected frame (or average data rate of more selected frames) or something similar.

cbrandin
07-22-2010, 12:08 AM
It didn't take long to confirm. StreamEye is missing entire GOPs and lumping them into one frame. Therefore:

ROGUE FRAMES DO NOT EXIST! It's just a bug in StreamEye.

Black tests simply show that the Panasonic firmware pads low data rate streams. When there is any actual image data they go away. One of the settings, either Video bitrate of Overall bitrate affects the minimum datarate - which is why this padding occurs in FHD mode only when bitrate settings have been raised. It would be interesting to test out setting Video and Overall bitrates separately to see if one of them is actually a minimum bitrate setting, rather than an average bitrate setting. I've always wondered why setting Overall bitrate lower than Video bitrate still worked.

To repeat - ROGUE FRAMES DO NOT EXIST!!!

Any confirmation of this finding would be appreciated. If the number "rogues" shown by StreamEye equals the difference between the GOP count reported by StreamEye and GH13StreamParser then that is proof enough.

Chris

cbrandin
07-22-2010, 12:11 AM
Crunchy,

Thanks for the bug report and suggestions, it's much appreciated.

Chris

modulr
07-22-2010, 12:44 AM
Any confirmation of this finding would be appreciated. If the number "rogues" shown by StreamEye equals the difference between the GOP count reported by StreamEye and GH13StreamParser then that is proof enough.

Chris

http://www.dvxuser.com/V6/showpost.php?p=2052912&postcount=102

cbrandin
07-22-2010, 12:47 AM
Thanks modular. I think this mystery is looking pretty much solved.

chris

Vitaliy Kiselev
07-22-2010, 01:38 AM
Guys, is it possible to move utility development messages and bugs to AVCHD tools thread adn keeping interesting discussion here?

As for Overall bitrate. It is very interesting question indeed.
GH1 uses 90000 base (90000 ticks per second).
18000000 is 200 seconds.
I added patch for other setting in new release (defaults to 9000000).

Generally overall bitrate requires careful extensive testing.

Vitaliy Kiselev
07-22-2010, 01:40 AM
Thanks modular. I think this mystery is looking pretty much solved.

chris

Can you add frame decoding support using ffmpeg or similar library?
Audio information and frames is also very useful.
Especially useful is all information (and placement in binary form) about file (encoding rates, audio bitrate), can be helpful in reversing.

svecher
07-22-2010, 06:52 AM
Indeed, Streameye is just flawed.
Hereby I propose to rename it RogueEye.

cbrandin
07-22-2010, 08:35 AM
Vitaliy,

Ok, we'll move this to the tools section now. Thanks for the suggestions. I was planning to let things settle a little bit before making too many major changes to GH13StreamParser. Right now I'm just going to fix any bugs people find. This weekend I'll probably start with new features. By "placement in binary form" do you mean addresses in the file? That's already there - it's the "Offset" field. I was planning to add filtering so you can filter in or out various stream types and that might give you what you want.

Chris

Vitaliy Kiselev
07-22-2010, 08:46 AM
I mean simple decoder for frames containing main stream parameters (for video and audio).

cbrandin
07-29-2010, 07:53 PM
I think I figured out what the Video, Overall, and Limiting bitrate settings really mean and do. Instead of posting all of this again just go here (http://www.dvxuser.com/V6/showpost.php?p=2062627&postcount=41) to see the original posting (and get the newest GH13 StreamParser version, if you want).

Chris

nikgid
07-30-2010, 02:22 PM
As for Overall bitrate. It is very interesting question indeed.
GH1 uses 90000 base (90000 ticks per second).
18000000 is 200 seconds.
I added patch for other setting in new release (defaults to 9000000).

Generally overall bitrate requires careful extensive testing.

(On Vitaliys request I am reposting something from the "original" research-thread into here.)

Did some testing of "overall bitrate" and "overall bitrate 2" today. It was my
first try at systematic test runs... so I have a bit to learn and much to
improve.

I did shoot gras as that is famous for producing AVCHD bitrate-peaks. The
problem with this is that even on a tripod the filesize sometimes seemed to have
quite a lot to do with how much the wind blew and thus how much the gras moved
:-)
So I will want to do another testrun tomorrow with a more static motiv -
suggestions for suitable motives very welcome!

The two conclusions that I would dare to make right now are:
- using "overall bitrate 2" with a value of "overall bitrate"/2 improves the
files bitrate (sometimes quite dramatically)
- having a "video bitrate" very close to the "overall bitrate" is inferior to
having a "video bitrate" well below "overall bitrate" (most of shots with "H"
are way bigger than with "SH" in my tests)

...hope this helps a bit... suggestions for further tests welcome! (I would play around with values for overlal bitrate2 in configuration G next if nothing else is suggested.)

Here are the test-results:

all tests shot with:
- GF1 (AVCHD 720p)
- 1/100s shutter, f4, ISO 100, on 50mm/1.4 Nikkor manual lens via manual movie mode
- all exactly 60 seconds in duration
- besides AVCHD-bitrate-patches only manual movie mode, 3rd party battery and
language patch checked to rule out any other interferences

(bitrate-patch values in million)


Configuration A)
plain vanilla GF1 AVCHD - no AVCHD codec bitrate patches:
filesize filename
SH 65654784 00035.MTS
H 60948480 00036.MTS
L 56616960 00037.MTS

Configuration B)
Video Bitrate SH:34 H:28 L:22
Overall Bitrate: 36
Overall Bitrate 2: - (not checked)
filesize filename
SH 60936192 00038.MTS
H 63043584 00039.MTS
L 68167680 00040.MTS

Configuration C)
Video Bitrate SH:34 H:28 L:22
Overall Bitrate: 36
Overall Bitrate 2: 18
filesize filename
SH 66840576 00042.MTS
H 57108480 00043.MTS
L 66226176 00044.MTS

Configuration D)
Video Bitrate SH:36 H:32 L:22
Overall Bitrate: 36
Overall Bitrate 2: - (not checked)
filesize filename
SH 72222720 00045.MTS
H 66471936 00046.MTS
L 64862208 00047.MTS

Configuration E)
Video Bitrate SH:36 H:32 L:22
Overall Bitrate: 36
Overall Bitrate 2: 18
filesize filename
SH 78348288 00048.MTS
H 131260416 00049.MTS
L 81887232 00050.MTS

Configuration F)
Video Bitrate SH:50 H:32 L:22
Overall Bitrate: 56
Overall Bitrate 2: - (not checked)
filesize filename
SH 64991232 00051.MTS
H 100675584 00052.MTS
L 83558400 00053.MTS

Configuration G)
Video Bitrate SH:50 H:32 L:22
Overall Bitrate: 56
Overall Bitrate 2: 28
filesize filename
SH 118886400 00054.MTS
H 153169920 00055.MTS
L 128643072 00056.MTS
Edit: The "system" I did here was trying different common value-sets for video bitrates in combination with overall bitrate and then test that whole set once with "overall bitrate 2" left unchecked (and thus staying at default value of 9.000.000) and once the whole set with "overall bitrate 2" set to half of the chosen value of "overall bitrate". - Goal was to get a first feel for what to look at more detailed.

Next (tomorrow) I will run a series of tests with the following setting-combinations - please give me a hint, warn me etc. if they make not much sense (and I would thus waste my time) and you'd rather have me test some slightly different settings. I am new to this so recommendations are definitely welcome!

Here's my plan for tomorrow:

Series A:
- leave "overall bitrate" and "overall bitrate 2" unchecked (and thus at default values) and test configurations for "video bitrate SH/H/L" with 42/32/22, 44/34/24, 46/36/26, 48/38/28, 50/40/30 - mainly to get a contrast for ...
Series B:
- repeat Series A now with "overal bitrate" at 56 and "overal bitrate 2" at 28

Does that make sense?

zhaoyun
07-30-2010, 05:35 PM
Repost thread as Vitaliy request.

based on streamparser 1.0d <buffer required> hints. i did a series of testing on overall bitrate and overall bitrate 2. hope that helpful for other testers.

first of all, the bitrate of FHD/SH is set 50M, native 24/25 clicked
then set the overall bitrate to 72M (buffer required 69.86M) and adjust the overall bitrate 2 from 18, 24, 36,38, 54, 72, 90. as no grasses area nearby, i use pappas's chart for testing.

finding 1, the OB2 must be power of "90,000", settings at 24, 38 make GH13 frozen at FHD and write error at SH.

finding 2, the OB2 >= OB or < half of OB makes GH13 unstable and quick frozen after recording.

finding 3, OB2 at 36 and 54 works better than above, but no stable enough which means quick frozen obtained.


SO, i moved to adjust the OB2 to 54 (buffer required = 52.39M and keep OB higher than FHD/SH for testing)

then adjust the OB2 to 45 (power of "90,000" and > half of OB and < OB).

GH13 seems stable. Next adjusting perset bitrate 1 and 2.

clicked 234 and 234 - write error and frozen.
clicked 540 and 540 - quick write error and frozen.
clicked 540 and unclicked PB2 - quick write error and frozen.
unclicked PB and clicked 540 - stable.

no setting can pass pappas chart under FHD mode with native clicked but it already know a defect of encoder or some area ptools no explore yet.

finally, setttled at 50FHD-36H-27L-54OB-45OB2-540PB2
then shooting to monitor with flickening between shutter and monitor , it generates highest average bitrate( >40M average.) it works well at both PAL and NTSC.

p.s. i can not see the significant change in quality of above setting, concern only the sustainability of GH13 during normal shooting. Achieved over 40M average bitrate, it is already an amazing works.

the setting ini file available here http://www.dvxuser.com/V6/showthread.php?p=2038569#post2038569

rambooc1
07-30-2010, 06:20 PM
p.s. i can not see the significant change in quality of above setting, concern only the sustainability of GH13 during normal shooting. Achieved over 40M average bitrate, it is already an amazing works.



This result is no different from plain original ""C"" settings so no improvement so far with the new patches.

I'm running some more test as i post this, really hoping for something dramatic like higher low detail rates to mimic the 24Mbps AVCHD of the HMC 150 codec. might be asking to much, but here's hoping.

R

nikgid
08-01-2010, 03:16 AM
Here's my plan for tomorrow:


so... here's what I did...

first test-row:
- GF1; "takeMS" Class 6 8GB card
- outside shooting gras in the afternoon (trying to get bitrate-peaks)
- all 60s duration (with a 1/2-second variety because of manual pressing of button)
- all shot with Nikkor 50mm at f11, 1/100, ISO 200, MF
- patches used besides bitrates: prevent version comp.; battery; language; 30min; manual movie
- used Overall Bitrate 2 value of 27 as zhaoyun suggested it should be value of x*9; used Overall Bitrate = 2* Overall Bitrate2


(values sorted by Video Bitrate (VB))
VB OB OB2 filesize
=======================
22 -- -- (L) 139020288
24 -- -- (L) 151099392
26 -- -- (L) 84811776
28 -- -- (L) 119476224
32 -- -- (H) 166453248
34 -- -- (H) 165955584
36 -- -- (H) 103778304
38 -- -- (H) 95729664
42 -- -- (SH) 185892864
44 -- -- (SH) 174569472
46 -- -- (SH) 167485440
48 -- -- (SH) 88805376
22 54 27 (L) 126775296
24 54 27 (L) 93358080
26 54 27 (L) 107188224
28 54 27 (L) 75282432
32 54 27 (H) 108244992
34 54 27 (H) 118923264
36 54 27 (H) 132667392
38 54 27 (H) 99256320
42 54 27 (SH) 101007360
44 54 27 (SH) 118536192
46 54 27 (SH) 146761728
48 54 27 (SH) 116471808... at that point I stopped as it was getting darker and I was frustrated by the
seemingly unmeaning filesize-values...

Conclusions:
- ?!
- very likely shooting gras outside is totally unsuitable for testing bitrate-values because of unpredictable movement and lighting conditions... as sad as this may sound: this might actually be the most valuable conclusion of my test-efforts... well, I guess that's science :-)
- we need to come up with a proper idea for a motiv to shoot for finetuning video-bitrates (for further exploring the AVCHD-codec)

second test-row:
- GF1; "takeMS" Class 6 8GB card
- inside with Pappas chart on floor and camera on tripod above
- all 60s duration (with a 1/2-second variety because of manual pressing of button)
- all shot with pancake 20mm at f8, 1/50, ISO 400, AFS
- patches used besides bitrates: prevent version comp.; battery; language; 30min; manual movie; FHD (curiosity killed the cat :-)
- went back to using values suggested by Vitaliy for OB/OB2 (i.e. 56/28)


(values sorted by Video Bitrate (VB))
VB OB OB2 filesize
=======================
-- -- -- (FH) 105271296
-- -- -- (SH) 66177024
-- -- -- (H) 64567296
-- -- -- (L) 61188096
22 -- -- (L) 69033984
32 -- -- (H) 67510272
36 -- -- (L) 67989504
42 -- -- (FH) 191821824
42 -- -- (SH) 66729984
46 -- -- (H) 67651584
50 -- -- (FH) 195237888
50 -- -- (SH) 67559424
22 56 28 (L) 65826816
24 56 28 (L) 66834432
28 56 28 (H) 67325952
32 56 28 (H) 65943552
34 56 28 (SH) 66557952
36 56 28 (L) 68247552
42 56 28 (FH) 1929216 (fail write speed)
42 56 28 (SH) 66029568
46 56 28 (H) 67289088
50 56 28 (FH) 1972224 (fail write speed)
50 56 28 (SH) 66625536

just for a quick comparison... in the end (with the same setup as above) I tested
zhaoyuns suggested values with preset britrate2 set to "540":
50 54 45 (FH) 1849344 (fail write speed)
50 54 45 (SH) 87969792 (!)
36 54 45 (H) 87478272
27 54 45 (L) 44967936 (?)
- but all those four files _without_ playback in camera!
Conclusions:
- either I have made a big mistake somewhere I am not aware of or the (static) chart is close-to useless for testing bitrate-differences (the filesizes achieved after 60s are so close to each other that it could very well depend on me pushing the button half-a-second sooner or later)
- just upping Video Bitrates and leaving Overall Bitrates untouched gave the some of the highest filesizes (but only by a very small margin) during theese tests
- exploring "Preset Bitrate (2)" seems to be very worthwhile as the result using Preset Bitrate of "540" with zhaoyuns value-set was considerably higher than the whole bunch I had tested before

Repeat:
- biggest conclusion for all further tests for finetuning AVCHD-bitrates
is: it is of utmost importance to find a good motiv that gives reproducable results with high bitrates (and thus significant variety in results). (I would have used Pappas chart on a turntable if I had a turntable...)

I will "pass on the ball" of testing now for the next three weeks as I am leaving for holidays tomorrow, yay! All the best to you all and I expect nothing less than the hack enabling the GF1 to make coffee when I am back :-)

PappasArts
08-01-2010, 07:40 PM
(I would have used Pappas chart on a turntable if I had a turntable...)


No need for the turntable- after reading your psot, I created a spinning version at 1920x1080 30fps for six seconds- Just play back full screen and loop it. Hope this helps.

SPINNING TEST CHART FOR MOTION CODEC TESTING .
link: http://www.sendspace.com/file/s4h34e

Pappas
http://www.pbase.com/arrfilms

Lpowell
08-01-2010, 07:53 PM
Thanks Pappas, the downloaded MOV file took a while to finish downloading, but it works great!

PappasArts
08-01-2010, 08:26 PM
Thanks Pappas, the downloaded MOV file took a while to finish downloading, but it works great!

Awesome....

rambooc1
08-01-2010, 09:29 PM
Awesome....

Damn thing Hypnotized me..... thanks Pappas

R

crunchy
08-02-2010, 04:27 AM
Thanks Pappas. This will considerably increase bitrates. There will be some smaller difference between NTSC/PAL cameras due to the video source FPS and 60Hz LCD screens, but the results should not differ too much.

zhaoyun
08-02-2010, 09:47 AM
few tests had been done, post all of them because dont want to waste.

all test carried by GH1 PAL 20/F1.7@F2.8 iso400 shuttle:1/100
the setting can refer to the file name
[FHD bitrate]_[OB/ "u" means unclick]_[OB2]_[PB]_[PB2]_[shooting mode:FHD/SH]_[interlace/progressive]

thanks for vitaliy's ptools, cbrandin's streamparser and pappas's chart for testing.

here you go

zhaoyun
08-02-2010, 09:51 AM
20 seconds as a standard time, but native facing freeze of camera so reduced to 5 seconds

zhaoyun
08-02-2010, 09:53 AM
if adjust the OB2 alone seems not affect of output. and tests stop here. hope that helpful, over !!

cbrandin
08-02-2010, 02:19 PM
Hey zhaoyun,

Can you do me a favor? For the different modes: FHD (no Native 25p), SH, H, L, and FHD pN (with the Native 25p set); could you tell me what the number shown in the attached capture is? It should be in Frame 0, Packet 1 (with a PID of 100) in timing mode (I highlighted it in the capture for you) in the Packet Data window. For example the attached picture is for FHD 25pN (native mode checked) and has the value of 433F. I only need PAL information.

Chris

cbrandin
08-02-2010, 03:25 PM
zahoyun,

By the way, no other settings besides the Native 24p and the 50fps>25fps should matter.

Chris

cbrandin
08-03-2010, 08:54 AM
Vitaliy,

I did much of my testing with an earlier version of PTool. With the newest version, if I set the parameters the same (excluding limiting bitrate, of course) and don't set any of the new parameters, will I get the same result?

Chris

Vitaliy Kiselev
08-03-2010, 08:59 AM
All of this patches must be the same.
As of limiting bitrate - I described my understanding in few threads already.

cbrandin
08-03-2010, 11:55 AM
Got it, thanks. I was just trying to determime whether past tests were still valid.

Chris

fraustosound
08-17-2010, 06:40 AM
Shot some footage in a dimly lit parking structure. Lots of mud and macroblocking but what really caught my eye is the pulsing. Looks like one frame is clean and consequent frames deteriorate. It happens at a steady rhythm of about 1.3 BPM. Take a look at the video to see for yourself. Encoder does not like low light levels.

http://www.youtube.com/watch?v=UPy-2N02s6s
edit - well, you can't see it in the youtube vid so I will upload some stills....

edit 2 - Now this is interesting.....I just opened the video in Windows media player and there is far less mud and the pulsing is not noticeable. I only notice the problem when I open it with VLC player. The screengrab below is from VLC. I cannot seem to do a screengrab from Windows media player....I just get a black screen.

edit 3 - I just downloaded the latest version of VLC and the macroblocking/mud is almost non existent. Goes to show how having the latest version of a program can save many a headache! Look at the the two screenshots below to see the difference.

GF1
PAL 25fps
ISO800
1/50 shutter

Using zhaoyun's AVCHD PTool settings:

Video Bitrate FHD/SH=50000000
Video Bitrate H=36000000
Video Bitrate L=27000000
Overall Bitrate=54000000
Preset bitrate 2=540
Overall Bitrate 2=45000000

svecher
08-17-2010, 07:48 AM
edit 3 - I just downloaded the latest version of VLC and the macroblocking/mud is almost non existent. Goes to show how having the latest version of a program can save many a headache!

Yes, old VLC versions were ugly. BTW, you can take screenshots on Windows using the new playback feature of GH13Parser.

cheul
08-21-2010, 02:40 AM
Is there a risk of bricking the GF1 when checking Preset bitrate 2 (540) and Overall Bitrate 2 (45,000,000) ?
I ask because these are settings publicly shared by zhaoyun (he has a GH1) but they are in the "Patches for testers" section of Ptool, which tells me it could be risky.
Are both (PB2 and OB2) safe ? Can't find the info with the search tool.

With zhaoyun OB2 and PB2 settings, one does get higher birates than say just tweaking "End users" settings ?

cbrandin
08-21-2010, 10:55 AM
I've noticed that there appears to be a fundamental difference between 24p encoding and 60p encoding. I have attached three captures from Stream Parser. They are all "dark" tests; that is, they were shot with the body cap on - so there should be no video data (except for a little I frame data). With the SH clip there is indeed no P frame video data except for the big P frame, which is just full of nulls (presumably to keep the minimum bitrate up). With both the 24p clips (one is Native, the other not) there is actually a fair amount of video data (i.e. not nulls) in each frame. Where is it coming from? Why does it only appear in 24p clips? Interesting, huh?

By the way, the big P frames in the Native 24p clip are also just filled with mostly nulls.

Chris

churasan
08-22-2010, 12:50 AM
Hi, cbrandin.
thanks for your effort.
I try this tool, but my movie files have .m2ts extension, not .MTS.
would you please add the function that read .m2ts files?

best regards,
churasan

cbrandin
08-22-2010, 08:10 AM
Stream Parser can read M2TS files - but only if they come from a GH1 camers. I don't know if it works with GF1 files or not (I don't have a GF1).

Chris

churasan
08-22-2010, 09:17 AM
it's odd... my camera is GH1 and my PC is win7 64bit,
I don't know why it can't read .m2ts in my PC.
but there is only .MTS file type in the lower right corner of the dialog, not .m2ts.

cbrandin
08-22-2010, 09:32 AM
You are using an old version - get the newest one here: http://www.dvxuser.com/V6/showpost.php?p=2076390&postcount=75

Remember to uninstall the old one first.

Chris

cbrandin
08-22-2010, 11:32 AM
Vitaliy,

I’ve been perusing the IDA database. You’re right – it looks like a bunch of table driven stuff, it’s very hard to analyze. I’ve noticed that the AVCHD codec is capable of more than is being used; I suspect it is derived from a library they use for several products. For example, I noticed that they have provisions for actual 24fps encoding (not just the 23.xxx).

I’ve developed a theory about how the native vs. wrapped progressive encoding is handled. I’ve attached two clips that were shot under exactly the same circumstances. One is 25p and the other is 25pN. You’ll notice that the ratio of I frame sizes to P frame sizes is completely different. In fact, the wrapped clip has P frames that are relatively almost twice as big as in the native clip. Which is the better ratio? The native clip looks more like what you get with 60p. However, I think this is not correct. At 24 or 25 fps, versus 50 or 60 fps, P frames basically have to do twice as much “work” because they have to account for changes over at least twice as much time. Therefore, at 24-25 fps one would expect the ratio between I frames and P frames to be lower than with 50-60 fps. Indeed, this is true when examining 50-60p clips compared to the same thing shot at 24-25p when it is wrapped in 50-60i. It is, however, not true when looking at native24/25p mode clips – but I believe it should be.

My theory is that there is a parameter that controls this ratio between P frames and I frames. Moreover, I believe it is applied when the final stream is produced rather than on the initial encoding pass. That would explain why the two 25p clips look so different, when they should look identical. The wrapped clips do encapsulate two interlaced frames in one frame, but I know for certain that AVCHD decoders actually interpret these combined frames as two separate frames (I had to deal with that when I wrote Stream Parser). There is a variable set to 3/8ths the frame size (I’ve attached a screenshot). I think this variable somehow governs the ratio between I and P frame sizes. It appears to be correct for streams that are being delivered at 50-60 fps (which is still true for 24-25p wrapped footage). However, it is incorrect for footage being delivered at a slower rate. I think the 3/8ths number should be changed to 6/8ths of the frame size to yield the same results for native 24/25p as you get with wrapped 24/25p (assuming that it works the way I think rather than the other way around). We’ll know if that is true if clips at native 25p start looking the same as the same subject shot with wrapped 25p. 24p is a little more complicated to analyze because of the pull-down. If my theory holds up, we would want to apply the same logic to all other modes of operation where the frame rate is lowered as well. This would go a long ways toward explaining why native mode seems to make the codec run out of steam with empty frames, pulsing frames, etc... - because the I frames are being allowed to be too big taking too many resources away from P frames.

Anyway, that’s my two cents worth for the day – let me know what you think.

Chris

cbrandin
08-22-2010, 12:03 PM
Thinking about it some more it occured to me that I might have it backwards - the ratio may need to be set to 3/16ths rather than 6/8ths. Shouldn't be too hard to test it out. Hopefully, the codec is arranged so that it can be configured in these general setup routines instead of having to set something else buried in some other routine.

By the way, the average bitrate between native and wrapped clips is nearly identical - it's just the ratio of data devoted to I frames versus P frames that changes.

Chris

Vitaliy Kiselev
08-22-2010, 12:19 PM
Ok. I'll make patch to change both values.
I think that theory is wrong. But you could experiment yourself.
Please, post IDA screens without addresses and HEX (cut all left side).

cbrandin
08-22-2010, 01:03 PM
Thanks. I'll keep the addresses out from now on.

Are you saying that changing these parameters won't help (which I can - unfortunately - believe), or that there is a good reason for wrapped 25p to look completely different than the same subject captured in native mode?

Chris

churasan
08-22-2010, 04:26 PM
Oh,sorry, it was my mistake.
Thank you for your kindness.
I'll download the newest version.

Churasan

cbrandin
08-23-2010, 08:34 AM
crunchy,

Here's the 25pN screenshot, but with the scale in this time. These were shot under controlled conditions with identical subjects (my electronic slate). It's the ratio between average I frame size and average P frame size that interests me. If wrapped 25p is just the native footage wrapped in a 50i container it should look the same - no?

Chris

svecher
08-23-2010, 09:00 AM
One is 25p and the other is 25pN. You’ll notice that the ratio of I frame sizes to P frame sizes is completely different. In fact, the wrapped clip has P frames that are relatively almost twice as big as in the native clip. Which is the better ratio? The native clip looks more like what you get with 60p. However, I think this is not correct. At 24 or 25 fps, versus 50 or 60 fps, P frames basically have to do twice as much “work” because they have to account for changes over at least twice as much time. Therefore, at 24-25 fps one would expect the ratio between I frames and P frames to be lower than with 50-60 fps. Indeed, this is true when examining 50-60p clips compared to the same thing shot at 24-25p when it is wrapped in 50-60i. It is, however, not true when looking at native24/25p mode clips – but I believe it should be.

Chris, what was the scene like in those screenshots?
Also, the apparent I/P frame ratio differences in native and interlaced footage are to be expected I think -- these are two different streams (at frame level) after all. I would be curious to find out if there are differences between native progressive and "processed" progressive (interlace-wrapper removed).

One of these days I need to ask Vitaliy for the key to look at this stuff too :)

cbrandin
08-23-2010, 09:17 AM
Here's a couple of screenshots comparing 24p clips. The difference is somewhat less apparent because of the pull-down, but it's still there.

Chris

cbrandin
08-23-2010, 09:21 AM
The subject was an electronic slate (I was testing timing, skipped frames, etc... for Stream Parser). Not very high detail and somewhat underexposed because I was using a very high shutter speed. I've attached a picture.

Chris

cbrandin
08-23-2010, 09:56 AM
Actually, the difference between interlaced and native streams with 25p data shouldn't be much. Theoretically, the main difference is how data is arranged within frames - the amount of data should be the same. For 24p it's a little more complicated because of the 24 to 30 fps pull-up. With 25p the frame sizes should be essentially identical. My contention is that there is more of a difference than simply containing progressive frames in an interlaced wrapper that we are seeing.

Chris

cbrandin
08-23-2010, 10:00 AM
There is another thing I discovered about the difference between 24p and 60p processing. I posted it here: http://www.dvxuser.com/V6/showpost.php?p=2083289&postcount=173.

It's almost like the 60p and 24/25p encoding routines were written by two different people.

Chris

richtrav
08-23-2010, 12:07 PM
I added requested patches to latest PTool.

Is this the "Constant for 1080p patch"? It's certainly doing something, in early testing the 777,600 number is not high enough though; at that number and below it freezes the camera almost instantly with C settings. Higher numbers (above 1,000,000) and it starts to get interesting, the higher you crank it the less likely you are to see mud, but you can also start locking up the camera even while panning a little (like around 6,000,000), a situation where it would not freeze before. Generally it takes around 6-8 seconds before it starts to think about locking up.

I'll fool around with it some more because this is encouraging, since unlike everything else tried so far it is definitely having an effect on the mud/blank P frames/freezing

crunchy
08-23-2010, 12:12 PM
With 25p the frame sizes should be essentially identical.

Exactly! Encoding just half of the picture two times per frame or encoding entire frame should not result in noticeable differences. I would say that 25pN coding should result in a slightly lower bitrate, but hardly noticeable.

Funny, but electronic slate (if only red numbers are changing) should not result in large P frames. I would expect that P frames are noticeably smaller than I frames.

cbrandin
08-23-2010, 12:26 PM
OK, I did some testing with the new patches Vitaliy put in for me. When I doubled the size of the "Constant for 1080p" nothing much changed. When I halved it, however, it made a huge difference in the ratio between I frame and P frame sizes. I've attached two captures (same subject, etc...). Obviously, I made too big a change - so I'm going to experiment with smaller changes. I'm just posting this now so anybody who might be interested can play too.

Chris

cbrandin
08-23-2010, 01:04 PM
Two more tests. By the way, these are all witl the Lpowell settings and a very highly detailed scene. The first is with the "Constant for 1080p" reduced by 20% (i.e. set to 622080). The second is the same subject shot with no changes to the Lpowell settings (i.e. not Native and Constant for 1080p unchanged). Notice that ratio is now somewhat lower - but not quite enough. The peaks are lower than the previous posted picture (which had native checked, but Constant unchanged), and higher that the one with Constant halved), but still somewhat higher than the pure LPowell settings. Stability also seems pretty good. My guess is that somewhere between a 25-40% reduction in the Constant for 1080p is going to look about right. The overall bitrates are pretty close to each other.

Chris

cbrandin
08-23-2010, 01:52 PM
I was shooting the slate hand-held because I wanted things to change a little more. I was also shooting at 1/500. The issue for me is that the 25p ratio changes so much depending on whether you have native checked - and it's consistent, it does it every time I test.

I've been testing with more Constant for 1080p settings. It's pretty complicated. When I reduced it by 33% the results looked almost as bad as the 50% reduction settings. At 20% it looked fairly good but there were still strange things in the stream like GOPs of 13, followed by 11, and some empty frames. Stability was much better, though. When I try the Lpowell settings with only Native 24p checked the streams end up being corrupted within seconds (i.e. they flunk the file check test routine containing outright garbage). Same thing when I set it to a higher, rather than lower, value.

I think these new settings are interesting, but I'm not sure they will solve the stability issue by themselves - there's more going on.

Chris

Vitaliy Kiselev
08-23-2010, 02:00 PM
Very interesting task is to track parameters passing from settings routines (look at two main ones) to bitrate related procedures.
If you could track it we can make patch to change native on the fly, as 0x7... address stuff is located in RAM and can be safely patched.

cbrandin
08-23-2010, 02:02 PM
There is a difference between the Lpowell settings and the "C" settings that I think is significant. The "C" settings offer a slightly higher bitrate, but the peak transfer rate to flash jumps up by 11Mb, which is much more than the difference in overall bitrate (which is about 4Mb). I suspect that when the camera fails writing to flash it is for two different reasons; either the video data being produced exceeds the fixed theoretical maximum transfer rate calculated by the camera, or the flash memory can't unload the write buffer fast enough. It's sort of a balancing act.

Chris

cbrandin
08-23-2010, 02:06 PM
Vitaliy,

That's exactly what I was planning to do next. Obviously there is something interesting going on there because of how the wrapped vs. uwrapped 25p clips come out.

Can you point me to the tables you were talking about earlier (i.e. the ones with 33 entries)? What labels did you use?

Chris

Vitaliy Kiselev
08-23-2010, 02:18 PM
Vitaliy,

Can you point me to the tables you were talking about earlier (i.e. the ones with 33 entries)? What labels did you use?



Look at names window, sort it by name, and look at
AVCHD_bitrate things.
Look at different tables and looking at references try to get logic how they are used.

cbrandin
08-23-2010, 02:23 PM
I think the AVCHD codec does have some features to choke the output when there is too much data being produced. The camera doesn't lock up but there are strange things about the streams like wrong GOP lengths and empty frames (where nothing changes). The clips do play, though, and they pass the file check function in Stream Parser. The other kind of failure I see is when there appears to be a buffer overrun; which results in lockups and streams that contain complete garbage (they fail the file check).

Chris

cbrandin
08-23-2010, 02:24 PM
Thanks Vitaliy. I'll start analyzing that.

Lpowell
09-08-2010, 01:04 PM
OK, I did some testing with the new patches Vitaliy put in for me. When I doubled the size of the "Constant for 1080p" nothing much changed. When I halved it, however, it made a huge difference in the ratio between I frame and P frame sizes.
I've gotten promising results using both "Constant for 1080p" and "Constant for 720p" at high bitrates in a new patch I've been testing on an NTSC GH1. However, I've run into two roadblocks with similar symptoms in other modes:

1. The "Constant for 720p" patch isn't available when I load the GF1_122 firmware. Without that patch, my SH-mode settings cause the GF1 to fail to start recording in AVCHD mode. There's no error message or file created, it simply does nothing when the movie button is pressed.

2. When I switch the NTSC GH1 into PAL mode, it fails to record in any of the four AVCHD modes, in a manner very similar to the above GF1 symptom. I'm puzzled by this since Chris has apparently been testing the "Constant for 1080p" patch in PAL 25p mode without problems. I can confirm that the GH1 is patched correctly to record on a PAL SD card, since it writes MJPEG files properly in HD mode.

I'm getting impressive results with this patch on the NTSC GH1, and I'm close completing my reliability tests. I'm keen to get it working and tested on GF1 and PAL so I can provide full support for those cameras as well.

DrDave
09-08-2010, 03:41 PM
Can't wait to see it "3L" Thanks for doing the research.

cbrandin
09-08-2010, 03:43 PM
Actually, I think I mislabeled on of my captures to indicate 25p when it should have been 24p on those tests. Sorry about that. You can tell the 25p tests because they have a GOP of 13, not 12.

Chris

cbrandin
09-08-2010, 03:48 PM
Whoa - I just noticed that the capture with the empty frames before each GOP is 24p and somehow ended up with a GOP of 13 - like it added an empty frame at the end of each GOP. I'm going to have to go back and look at those streams again.

Chris

cbrandin
09-08-2010, 03:52 PM
I checked - all my tests were 24p, not 25p. The one with the 13 GOP size appears to only have done that on the first GOP. I've noticed that when Native is checked, one of the issues produced is the occassional wrong GOP size (I've seen them one too long and one too short, and sometimes both).

Chris

cbrandin
09-12-2010, 07:17 PM
I have found a rather odd thing in the firmware. I think these screenshots are from the AVCHD decoder routine (I'm not sure, though). It appears that the decoder supports framerates and resolutions that the encoder does not (i.e. true 24 fps, 480, and 576 resolutions) . For what it's worth....

Chris

cbrandin
09-14-2010, 10:19 AM
Looking at my "dark" test files I discovered a difference between the codec when it encodes 720 vs 1080. With 720 clips it seems to enforce a threshold where if the amount of image data doesn't reach a certain level it simply doesn't encode it and produces emply frames (the big P frames are full of nulls - presumably to keep the minimum data rate up). I've attached an image from Stream Parser showing all empty P frames (except for the big ones they are all 192 bytes and only contain time stamp and header data - no video). Also attached is a magnified Vector Scope display showing simply a black point dot. If I step through the clip nothing ever changes.

The 1080 clip is different - it shows data in each frame. I've also attached screen captures for that. I've also looked at histograms - the 720 clips contain absolutely no image data and the 1080 clips do. I've tried this several times with different settings and it appears to always work this way. I also looked at Native clips, and they also contain data. The data follows a pattern, so it might be some sort of dithering.

If 720 mode is enforcing a threshold, and 1080 mode isn't, it could make a difference in how images appear.

Chris

Vitaliy Kiselev
09-14-2010, 10:43 AM
Seems to be large P frame again. Last in GOP.
Looks like highly bogus implementation.

cbrandin
09-14-2010, 11:16 AM
Seems to be large P frame again. Last in GOP.
Looks like highly bogus implementation.

Boy, you got that right! Plowing through this code is a nightmare. In 1080 mode, the data actually appears in every frame.

Chris

Vitaliy Kiselev
09-14-2010, 12:39 PM
Boy, you got that right! Plowing through this code is a nightmare. In 1080 mode, the data actually appears in every frame.
Chris

Generally code is quite clear (compared to ARM or even x86).
Look at grouping of functions.
It has various plugins (search by this word).
And tables of offsets that reference to related functions.
So, decoder functions are near each other, same for ts muxer, same for video encoder.

cbrandin
09-14-2010, 12:55 PM
Yup, I found all that. The hard thing is that it looks to be mostly table driven and back-tracing pointers to pointers, to addresses in the plug-ins and back to pointers to tables and offsets is rather time consuming.

Chris

Vitaliy Kiselev
09-14-2010, 01:30 PM
Yup, I found all that. The hard thing is that it looks to be mostly table driven and back-tracing pointers to pointers, to addresses in the plug-ins and back to pointers to tables and offsets is rather time consuming.

Chris

Yep. They also like to copy memory parts in other routines (or even tasks).
So, you are looking at references to certain structures but can't find any.
Because they copy large part (including structure) to other place (or instead something to this place).
All firmware is based on tables.
But as soon as we'll start to realise how this works it is to our adventage.
In reality they frequenly use special codes (they are easy to find, as they are quite unique most of the time) to select some function from the table.

xiyiding
09-18-2010, 03:13 AM
This hmc153 PAL 1920 50I avchd stream

http://www.hengyou.com/bbs/UploadFile/2010-9/20109181823541693.jpg


1280 50P's

http://www.hengyou.com/bbs/UploadFile/2010-9/20109181823582040.jpg

cbrandin
09-18-2010, 09:13 AM
Stream Parser is only set up to do GH! clips. Obviously different frame type flagss are being used here so frame types are not being correctly identified. It looks like these streams also contain B frames - is that correct?

This gives me an idea. I could add a feature to stream parser where you can manually enter PID's and frame type flags.

Chris

Lpowell
09-20-2010, 06:45 AM
If do a new rev of Stream Parser, could you calculate two more stats in the info window: peak and average bitrate of the entire stream. I've had to estimate these by eye balling the charts.

cbrandin
09-20-2010, 08:13 AM
If do a new rev of Stream Parser, could you calculate two more stats in the info window: peak and average bitrate of the entire stream. I've had to estimate these by eye balling the charts.

OK, will do.

Chris

Lpowell
09-23-2010, 07:27 PM
I've been researching low-light recording failures in SH 720p30 mode with my Fast Action 3-Frame GOP Patch. From what I've seen, if the illumination is low enough, the bitrate will drop below 5Mbps and the recording will terminate after about 7 seconds, leaving a zero-length file. The camera then displays a write-speed limitation error, with both slow Class 4 and fast Class 10 SD cards alike. Here's a Stream Parser screen grab of a video I saved before the 7-second limit:

http://img707.imageshack.us/img707/8952/lowlightpframes.gif

My guess is that the camera builds up unused bit allocation that it can't find a use for over each one-second interval. It then writes out the surplus as a single huge P-frame which overwhelms the SD card's write-speed limits. Anyone know of a patch that may fix this problem?

Vitaliy Kiselev
09-23-2010, 07:32 PM
No.

But this behaviour is common to GH1 encoder.
It has problem with last P frame in GOP sometimes.
Like on your picture.
But P frame size on your picture seems pretty small to cause any write problems.

Lpowell
09-23-2010, 07:49 PM
Each recording aborts predictably after 7 seconds have elapsed, so it seems there's probably something else building up to an overflow condition behind the scenes...

cbrandin
09-23-2010, 08:20 PM
I've seen this pattern with dark tests in all modes. When you raise bitrates the big P frames get bigger. I assumed that it was just maintaining a minimum bitrate as the big P frames contain mostly nulls in my tests (you might want to check that). The bitrate looks pretty small, so I doubt the write function is being overrun. You might try upping the Overall Bitrate anyway, that speeds up the camera's ability to write. One thing I noticed about 720p mode is that there seems to be some sort of threshold condition that has to be met before it will put anything in a P frame. Oddly, 1080 mode doesn't seem to have that. I posted something about that earlier in this thread: http://www.dvxuser.com/V6/showpost.php?p=2103518&postcount=206.

Chris

noirist
09-23-2010, 08:36 PM
Maybe there's another parameter in the firmware that lower bounds the encoder output bit rate. If the encoder can't satisfy that lower bound, it aborts with a "write speed error"? Not unlike the upper bound that Chris investigated.

Why would Panasonic implement such a parameter? Like Chris's upper bound, programming convenience. It's probably easier to track how much data the encoder is outputting in a window than it is to measure the instantaneous card writing speed or to track card write errors. If the encoder outputs too much data, then the firmware assumes without proof that the card can't keep up and it raises a write speed error. If the encoder outputs too little data in the window, then the firmware assumes without proof that the card writing subroutine must be getting hung up and it raises a write speed error.

Just a thought.