Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Please, support PV!
It allows to keep PV going, with more focus towards AI, but keeping be one of the few truly independent places.
AVCHD maximum image quality, series 2
  • 111 Replies sorted by
  • I've used Stray's 88M quite a bit and have never seen an issue.
    Don't know what to say why that occured.

    Have you been able to recreate this again?
  • @proaudio4 I have using the ETC mode with a lot of motion. I dunno what to do to fix it though.
  • So Stray, with your 88M AQ2 max var setting, you're saying you've never seen this issue, right?
  • I hadn't tested ETC mode before, I forget the camera has it as I never use it, which is crap of me really. It seems to be fine with relatively static shots using ETC, but it isn't with detail and motion with the quick test I did this morning when I saw the post. I'd have to look at replicating it more reliably though, but yeah, there does seem to be a problem with the ETC mode under some conditions. I'll look at it again tomorrow to make sure that ETC is the cause of what happened with the grass cutter shot.

    No, I have never ever seen it before today as I don't use ETC. I only used ETC today to try and replicate the result. I'm not convinced I did replicate it exactly, but as I wrote at the end of part one of this thread it did create an issue whereby frames were basically dropping out (< 8,000 bytes size).
  • @Stray and @proaudio4

    The 88m patch always fails for me in ETC mode. I had to give it up for that reason. 720p was pretty funky too, I seem to recall. But my best SD card is a Lexar 200x, whereas I believe you guys are using the SanDIsk Extreme Pro.

    Just FYI, the 88m (and the other recent high bitrate patches) also immediately fails when I use the 80% setting in "Creative Mode." Too bad, because that's one of my favourite modes to use - it gives a gentle slow-motion effect when conformed to 24 fps and is also the only option we have on the GH2 for 30 fps progressive.
  • Thanks Stray and bdegazio.

    I had not tried the 80% or ETC mode with the 88M setting.
    I can understand why the 80% would fail, I'm not sure why cropping the sensor which ETC does would though?
  • @proaudio4

    I'm guessing that performing the crop in ETC mode is (somehow) more demanding of processing power and slows things down just enough to cause a timing fault, which then presents itself to the user as the general "Your card is too slow" error.


  • You don't get a card is too slow error though, it seems to record perfectly fine. Its just the file itself isn't right, it has excessive blocking accross the whole frame. Also it doesn't happen everytime either, I'm trying to work out the conditions whereby the ETC mode causes it to get really blocky. Mostly the ETC mode works perfectly well.
  • Hmm, maybe we're talking about two different problems. Or maybe the same problem that manifests itself in different ways depending on the card?

    I'll re-flash my camera with your 88m settings and try again shortly to confirm the behaviour I described above.

    EDIT:

    @Stray, Just to double check, are these the settings we're referring to?

    [Information]
    Comment=24H 88M 24L 66M AQ2 GOP 12
    SD_Card=Any
    Camera=GH2 v1.0E
    [Settings]
    Version increment=1
    Video Bitrate 24H=88000000
    Video Bitrate 24L=64000000
    Video Bitrate FSH/SH=32000000
    Video Bitrate FH/H=24000000
    Auto Quantizer for 1080 modes=2 - More to details
    Auto Quantizer for 720 modes=2 - More to details
    Video buffer=0x1800000
    Video buffer 24p=0x3600000
    1080p24 FB1=783360
    1080p24 FB2=3936092
    1080i60 FB1=391680
    60fps FB2=1180829
    1080i50 FB1=391680
    50fps FB2=1416995
    720p60 FB1=345600
    720p50 FB1=345600
    1080p24 Frame Limit=9043968
    60fps Frame Limit=3621204
    50fps Frame Limit=4341104
    1080p24 High Top Setting=101803
    1080p24 High Bottom Setting=71261
    1080p24 Low Top Setting=74827
    1080p24 Low Bottom Setting=52378
    Other Modes Top Setting=38254
    Other Modes Bottom Setting=26776
  • Yep there the ones, thanks.
  • Okay, I took some shots this morning with both ETC on and 80% variable mode on at the same time (also at ISO640 and a SS of 1/125) of high detail and I didn't have any issues at all. Shaking the camera about does cause problems, but nothing like the example posted. Can anyone else replicate the issue consistently ? Incidentally, running at 80% it takes the camera a bit longer to get up to speed in terms of I-Frame size I've noticed (like it has a longer blip).
    ETC on 80 percent on panning ISO640.png
    1297 x 683 - 459K
  • @Stray
    Just to be sure that it's not an issue with my Sandisk Extreme Pro 45MB/s, I'll borrow a 'approved' Sandisk 30MB/s extreme to test your 88M again.
  • @Stray
    Testing your 88m with a 32G Dane-Elec 200x SD card, I get the following results:

    24H - ETC on, works OK; 80% mode fails with card speed error every time
    24L - ETC on works OK; 80% mode occasionaly fails with card speed error, but 2nd attempt always works.
    720p - ETC on works OK; 80% mode occasionaly fails with card speed error, but 2nd attempt always works.

    Sorry, no streamparser graphs (won't run under Crossover on the Mac)

    The Dane-Elec card worked flawlessly for me when I first got it 2 months ago, but the datarates for your settings (and Driftwood's) are much higher than I was using then. Or perhaps the card needs a low-level format, as has been discussed here recently.
  • @Stray
    I get the same result like @bdegazio.
    I am using Sandisk Extreme Pro 32GB UHS.
    24H - ETC on, works OK; 80% mode fails with card speed error about 50% probability.
  • Thanks guys. I've though of a couple of things to try, so I'll post results in a day or two. Will hopefully find a way to replicate these problems consistently, but that may take a while to setup.
  • Clarification. I'm not going to try and fix card speed errors as they are probably card speed errors. It's when you don't get the speed error, but the shot video is still faulty that I'm going to try and sort out. Thats the only real problem, as you think that the shot is fine until you play it back. I still think this is only ETC related, as adding 80% variable speed doesn't create any problem except speed errors with some cards. As I've said I can't replicate it consistently, the patch on the whole is solid with fast cards and also with cards that aren't so fast without 80%.
  • Thanks stray. I'm going to keep your 88m loaded on my camera despite the occasional card speed error. It seems to be the best compromise between motion quality, image quality, and file size.
  • @ Stray
    Today I experimented with Driftwood 176 GOP1 v3. I was expecting write error with the Sandisk Extreme Pro 45m/s, but instead it recorded and playback fine. It's the same card that gave me problem with your 88M setting the day before.

    As a test, I shot Driftwood 176M with ETC and without ETC. I shot the same scene again, the scene that failed me yesterday with the 88M setting. The 176M recorded fine without error and I can playback the recorded clips perfectly in camera. I then took out the SD card, insert it into a second hacked GH2 with your 88M setting and record the same scene. The recording went well but I couldn't play it back on the camera. So I brought it into my computer and upon playback, I found glitches in the recorded image.

    Now Im wondering why, I'm not having problem with the higher bitrate Driftwood 176M setting but rather a lower bitrate setting like your 88M. Given a choice, I really would like to stick to your 88M setting instead because of the good balance between quality and file size.

    As for Driftwood 176 GOP1 v3, I must say the image quality is breathtaking. My GH2 suddenly look like a camera that is worth 10 to 20 times the price I paid for.
  • @PixCanFly I really cannot recreate the problem with ETC mode that you get, and with the same card too. The image quality of the 176M isn't actually that different. If you look at stills in post of the same scene and push the image a lot, the size of the blocks are actually the same as the 66M AQ2 GOP12 settings. The I-frames themselves are quite a bit smaller with the 176M. However, the motion of GOP1 is breathakingly good, but when it comes to post work it's actually no better. http://personal-view.com/talks/discussion/comment/18767#Comment_18767 the motion does make it look amazing, but it doesn't actually mean the image quality is better in terms that relate to post work (grading, compositing, colour correction etc).

    But if you are doing a lot of heavy post work, and you aren't transcoding your footage first to another intra format then the GOP1 will be better everytime as it won't suffer the generational loss as badly as a long GOP stream. If you love the look of the 176M GOP1 though I'd say stick with it, you'll only be constantly hankering after it's look now you've experienced it shooting everytime that you use other settings. ;) Actually the codec is doing more work arguably with a longer GOP than GOP1 really (creating spatially based I-Frames alone is probably a lot easier than creating B and P temporally based frames), maybe thats the problem/difference with the 88M settings.
  • My camera is going to be on the shelf for a bit as I have some music I have to work on for somebody, but if I get a chance I'll get back to this issue. One thing you can try @PixCanFly as it seems you can recreate the problem consistently is to change the video buffer 24p back to 0x2400000, which is under Patchers for testers>AVCHD movie mode>AVCHD Research. It was stable at that setting anyway, I changed it up to 3600000 based on what I think now was incorrect information (a belt and braces decision).
  • More HDMI Testing - BATTLE OF THE TITANS

    It's come time to test the high end contenders against the absolute reference - lossless HDMI output. This was a punishing nighttime test at ISO 6400. HDMI capture was done simultaneously with in-camera recording. The lineup:

    Driftwood's 176M GOP1
    bkmcwd's 154M GOP3
    Stray's 88M GOP12

    These are Photoshop TIFs with layers. HDMI is on the bottom, AVCHD on top. Toggle the top layer on and off and compare the two.

    [url]http://www.sendspace.com/file/spv5b4[/url]
    [url]http://www.sendspace.com/file/ithhfj[/url]
    [url]http://www.sendspace.com/file/jdsfrp[/url]

    IMPRESSIONS:

    It's a tie between bkmcwd's 154M GOP3 and Driftwood's 176M GOP1. Both are perfection. I don't believe you can get any closer to the the HDMI than these two patches. Stray's 88M comes close, very close. And at half the data rate, it's a viable option for high end recording.

    EDIT:

    I have since run these clips through stream parser.
    Night Test Diftwood 176M.jpg
    1283 x 648 - 199K
    Night Test bkmcwd 154M.jpg
    1283 x 648 - 199K
    Night Test Stray 88M.jpg
    1283 x 648 - 193K
  • Bkmcwd's (1)
    Drifwood's (2)
  • @Stray 88M can become unstable (in controlled testing). I have made a motion deathchart in After Effects and I get occasional drop-outs with Stray's 88M patch. It only happens once in a while but it indicates a buffer overrun. I see it in other patches too, where you get one or 2 frames that are like 10k in size.
  • @Ralph_B
    Which specific @bkmcwd 154M patch did you test?