AVCHD high bitrate tests- MUD FREE footage

be careful with D settings. I had my camera stop recording multiple times with the "stopped recording because of write speed limitations". I have a 32GB SanDisk extreme III class 10 30MB/s card so that's not the issue. I think the issue is the max bitrate number is larger than the buffer number in the D settings. if you look at the dialog in tester13's ptool recommendations there are guidelines for the numbers. I'm sticking with B for now. also, I noticed that changing the audio bitrate to any other setting besides the default causes the movies to not be playable in camera. I shoot only 720p60 and am getting about 28mbs max. definitely an improvement.
 
be careful with D settings. I had my camera stop recording multiple times with the "stopped recording because of write speed limitations". I think the issue is the max bitrate number is larger than the buffer number in the D settings. if you look at the dialog in tester13's ptool recommendations there are guidelines for the numbers.
I was going to ask this as well. Are the warnings in the tool correct and so far people are just being lucky?
 
The high-speed garden tour is indeed impressive, seen frame by frame (nice garden!). It suggests an interesting photo technique - just "hose" all over a scene and you'll have the whole thing in moments.

Looking at the file size, you'd get about 22 minutes on a 8GB card at that kind of bit rate, yes?
 
yes, I think people are just getting lucky with the D settings. I first noticed the failure when I was trying to really stress the codec. very detailed scene with lots of camera movement. once I noticed the failure I tried to repeat the record shutoff and was able to cause the same problem everytime. that's when I went back to the B settings. it makes sense, you can't have a max bitrate that's bigger than the buffer.
 
yes, I think people are just getting lucky with the D settings. I first noticed the failure when I was trying to really stress the codec. very detailed scene with lots of camera movement. once I noticed the failure I tried to repeat the record shutoff and was able to cause the same problem everytime. that's when I went back to the B settings. it makes sense, you can't have a max bitrate that's bigger than the buffer.

I must be getting pretty darn lucky, then! I'm using a Sandisk 8 GB Extreme III Class 6 card, just shot with the D setting + native 24p + 448 bps audio for 10 minutes - all handheld, quick pans on high detail at 1/500, f/11, 800 ISO with a Canon FD 50mm lens.

No write error, I just got bored and cut after 10 minutes. Didn't break the codec and didn't stress the card.
 
I've been seeing what happens when rendering the 'garden whipping' footage to 'standard' AVCHD 15mbps. There's very little degradation but half the file size. In other words, to get the high bitrate quality you don't actually have to use a high bitrate. So aren't we throwing a high bitrate at some other problem in the GH1 AVCHD codec which should be resolvable without resorting to that solution? Or is this the only practical means now to do so? Or is this not a fair comparison (encoding in an NLE vs encoding in the camera)?

It's interesting to look frame by frame from the start of that clip what happens to the tall ornamental grasses at the base of the large tree which is in the centre of the shot at the outset (it has a double trunk). They start off with clearly defined blades of foliage, but as the pan begins, they "splodge" in a way that looks more like 'mud' to me than motion blur. Maybe I'm being too picky.
 
I've been seeing what happens when rendering the 'garden whipping' footage to 'standard' AVCHD 15mbps. There's very little degradation but half the file size. In other words, to get the high bitrate quality you don't actually have to use a high bitrate. So aren't we throwing a high bitrate at some other problem in the GH1 AVCHD codec which should be resolvable without resorting to that solution? Or is this the only practical means now to do so? Or is this not a fair comparison (encoding in an NLE vs encoding in the camera)?

It's interesting to look frame by frame from the start of that clip what happens to the tall ornamental grasses at the base of the large tree which is in the centre of the shot at the outset (it has a double trunk). They start off with clearly defined blades of foliage, but as the pan begins, they "splodge" in a way that looks more like 'mud' to me than motion blur. Maybe I'm being too picky.

Correct, you cannot compare a software encode to an onboard hardware encode. They use very different algorithms and encoding strategies.

To make it more efficient with better compression (i.e. better quality at lower filesize), you would have to implement better features like using b-frames, more reference frames, CABAC, stronger search and motion vector prediction. This is not something firmware mods can do very easily. You need new hardware for these types of changes because the CPU just can't handle it.
 
I've been seeing what happens when rendering the 'garden whipping' footage to 'standard' AVCHD 15mbps. There's very little degradation but half the file size. In other words, to get the high bitrate quality you don't actually have to use a high bitrate. So aren't we throwing a high bitrate at some other problem in the GH1 AVCHD codec which should be resolvable without resorting to that solution? Or is this the only practical means now to do so? Or is this not a fair comparison (encoding in an NLE vs encoding in the camera)?

It's interesting to look frame by frame from the start of that clip what happens to the tall ornamental grasses at the base of the large tree which is in the centre of the shot at the outset (it has a double trunk). They start off with clearly defined blades of foliage, but as the pan begins, they "splodge" in a way that looks more like 'mud' to me than motion blur. Maybe I'm being too picky.

Totally different thing recording at 15mbps and downconverting higher bitrate footage. Even HD downconverted to SD looks better than footage shot at SD.
 
http://www.sendspace.com/file/af64gf [MTS format, 61mb]

Here's a real codec torture test. Stock 14-140 lens @ 14mm, f/11, 1/800 shutter, ISO boosted a bit to 400 or so to compensate. Then just an outrageous whip pan back and forth. No mud spotted :)

Oh and this is using the "D" settings for AVCHD. The first shot I made outdoors with the "D" settings, my camera gave a message saying it stopped recording because of write speed limitations. I had to pull the battery in order to reset. Oddly when I made the same exact shot again, it didn't give any more errors and recorded fine. It only happened on that first shot.

There is some mud but- nothing in comparison to what we would see on out the box GH1! Frame 23 is when it goes kaplooey....but who's countin'.

I'm working on some snowboard footage from this winter- could've def. used this!! The trees are a mess!!!!

However, the rolling shutter has really come to the forefront- more so than I've ever seen on GH-1.

NTL Good work!!
 
I've been seeing what happens when rendering the 'garden whipping' footage to 'standard' AVCHD 15mbps. There's very little degradation but half the file size. In other words, to get the high bitrate quality you don't actually have to use a high bitrate. So aren't we throwing a high bitrate at some other problem in the GH1 AVCHD codec which should be resolvable without resorting to that solution? Or is this the only practical means now to do so? Or is this not a fair comparison (encoding in an NLE vs encoding in the camera)?

It's interesting to look frame by frame from the start of that clip what happens to the tall ornamental grasses at the base of the large tree which is in the centre of the shot at the outset (it has a double trunk). They start off with clearly defined blades of foliage, but as the pan begins, they "splodge" in a way that looks more like 'mud' to me than motion blur. Maybe I'm being too picky.


Yes you are right. right now the only option is to up the bitrate because as Tester13 has uncovered, there is something strange happening with the encoding. Higher bitrate helps get around this issue but does not solve the real issue at hand.
 
So what's the scoop if any as far as 720 60p is concerned? I'm shooting something today with a GH1 and an HVX200A and as much as I want to make the picture quality better in the 1080 24p mode, I really don't trust my Transcend class 6 card. The only real issues I had was on the fist big day shooting with it in which the camera stopped recording several times.

The good news is that it have never happened since then. I mean perhaps the GH1 was playing hard to get and after knowing the Transcend for a while, they don't mind being together now but I fear that may change.

I bought that card because my 16GB Sandisk class 6 got somehow lost on the first day of using it. Why the heck did it have to be that card? I have cheaper cards that I wouldn't have mind loosing like the class 2 ones. I spent a couple of weeks deciding on rather or not putting down the money to get the card was worth it and that had to happen. That card would have been perfect for these tests.

Anyway, I've decided to be a rebel and shoot my project in 720 60p.

After saying all that, another question just popped into my head that I've been wondering. Have anybody got better results using the top Panasonic cards for these high bit rate tests?
 
c or d

c or d

c, works great, I have a class6 peak card and have had no problems with writing, during fast pans etc. at foliage. I think d is working too but maybe its a little more demanding, c are gooood though. Just going to look at my mjpeg footage with these settings.
 
i would also love to know the best settings for the latest tester patches ..if someone can make detailed setting inside the latest ptool (what should be marked or checked and what values should be entered) , thanks !
 
Hey all,
while using the a,b,c, or d setting do you also patch the GOP size? if so at what settings?
what other settings do you patch ptools?
Thanks for your input

Chris
 
I didn't patch the GOP size on mine, just Video Buffer, Video Bitrate, Overall Bitrate & Limiting Bitrate. Aside from those I also did the MJPEG E1-E4 (Quality & Table) and native 24p, 3rd party battery & of course version change.
 
All of you could experiment with settings. If D settings causing crashes try to change values a bit, and then upload to someone who can control check at low level. We need to find optimal values. I'll try with new settings later.
As for C settings, They are not good... It's better to use B that it's good at low level even with smaller bitrate...
 
Back
Top