Personal View site logo
PTool v3.63d topic
  • 348 Replies sorted by
  • Ah. thanks @driftwood as I have actually changed the bitrate quite a bit so maybe I need to see what other GOP1 patches there are that would suit a lower bitrate. But it does look great. I ran it for ages earlier and it didn't seem to fall over, but for tomorrow night's gig it's likely to be used as an additional camera for safety as I have two HD cams already covering it. Thanks though!! From what I've seen of this, the low GOP definitely looks better (and noise-reduces better too) even though it's probably not using the bit-rate quite as efficiently as a long GOP.
  • Have to say, though - I nearly did something VERY silly with my camera. Having hacked it with the file on the card, I did some shooting, looked at it in the computer, and put the card back in the camera to do some more. It's only when I went to check what was on the card (by pressing the green play) and got the warning about "do you want to apply the patch" that I realised I had left the patch on there with the other media, and I came very close to reapplying the patch while fiddling with the buttons. So now I understand why people put patches on separate cards.
  • @Mark_the_Harp, you probably already know, but applying a patch a 2nd time is fine. But if course you don't want to do it accidentally and then press buttons during the upgrade - or worse panic and turn the cam off : ).

    I've left my patches on my main cards, and like you I almost triggered them a few times, but the extra confirmation is usually enough to avoid it (but on a bad day... )
  • Usually I format the card immediately after installing a custom firmware.
  • So, today I have noticed few things with the new hack. I'm using Driftwood GOP1 AQ3 166M 'SeAQuake' (http://www.personal-view.com/talks/uploads/FileUpload/28/612757cecb17ccb95cc570bdd97711.zip)

    First one is the Auto ISO that shows on the lcd instead of the actual one.

    The second one that worries me is that when I started moving the camera a recording was stopped due to "Insufficient ....card error". I've tried to reproduce the problem by moving around camera while recording in 24P with out much success. I'm using SanDisk 32GB Extreme Pro - SDHC - UHS Speed Class 1 45mb/s.
  • @Tommyboy

    Auto ISO is known issue, this doe NOT effect recording in any way.
    "Card Error" is due to slow card... 45MB/s are USH-1 which is not running at UHS-1 speed in GH2. Get either 30MB/s Extreme Pro 32 GIG (It works- don't ask me why). Also 95MB/s 64GIG Sandisk Extreme Pro is reported to even span.
  • so what is with that auto-iso thing anyhow? does it just show that while actually being set to the specific iso?
  • Thankyou. I've spent an interesting evening.

    First I found that one of my three class 10 cards is not up to the job.

    Secondly I found that by using SeaQuake I can virtually eliminate the 'jello' effect when FCPx does image stabilisation. Even for slightly arty you-tubers such as myself this is a major contribution! Speaking of which, off to paypal for me.
  • Is this leaked firmware NTSC or PAL?
  • @Athiril, you mean the hacked firmware with various patches? You have the option of NTSC, PAL or switching between both. Note that PAL isn't 25P (yet anyway).
  • I found that old patch from @cbrandin does not work ok with this version of the tool.
    If i add high iso on ...
    the card error message ...
    card is SanDisk class10 HD video, 30mb/s ...
    anyone experienced this ?
  • @Mark_the_Harp or others ?

    please can you make available your 44/66 settings, does these work on 50i too ?
    can these be played on camera ?
    I need something stable and playable on camera also non-wrapped 1080 50i that spans.
    Any help ?
  • @Hallvalla
    yes, but i need non-wrapped 1080 50i , also files have high bit-rate can't play on camera.
  • Ok i have a question not exactly related to this topic but i see everyone talking about the SD card and the fact that it works or doesn't with some patches...So here is my question.

    1) Is Sandisk Extreme Pro 45mbits 8G good enough to use SeaQuake?

    2) Do we have somewhere here a topic with the best working SD cards so that we could almost all use the same stable/working tools? Lenses excepted off course...
  • @alcomposer @FGCU thanks for your fast reply
  • @AlexMantra 30MB/s Sandisk Extreme HD VIDEO 32gig are currnetly the P-V standard though- the 95MB/s are only just becomming available and are 'experimental'. However its looking good.
  • @driftwood You mentioned a while back, when I talked about modifying your Spanmybitchup patch, "Be careful modifying the patches - too much and you WILL get buffer underruns/overflows." I'm not sure how to ensure I get neither of these situations except by trial and error. I guess overruns crash the camera, and underruns waste bitrate / storage? Is that right?

    However, this patch is very stable, and spans and looks amazing - even at high ISOs - so I guess it's roughly right. All I did was alter the bitrate to 66 / 44 (H/L) - nothing else.

    Of course, if it ain't broke....but remembering your comment, I thought I'd put a few clips into Elecard buffer analyser. This is the one that's nearest the "red line" which I guess means buffer overrun. Does this graph look like I'm OK with my settings and need not worry about anything? After generating the graph, I get this - the opening below is followed by loads of lines (first three quoted, but there are zillions of them). Is that a problem or just some quirk of elecard / GH2 that I can ignore?

    I appreciate any enlightenment from you on this aspect of playing with patches, and about the role of the buffer in general. Thanks!

    =======================================

    Stream info:
    file name : H:\PRIVATE\AVCHD\BDMV\STREAM\00013.MTS
    file size : 56 395 776 bytes

    video format : AVC/H.264
    initial CBP removal relay : 0.53 sec
    buffer size : 45 620 224 bits
    declared bitrate : 65 158 144 bps
    declared frame rate : 23.98 fps
    bitrate type : VBR
    padding : 0 bits


    Errors:
    invalid value at 1.948 sec. (initial_cpb_removal_delay_offset 4 294 967 283)
    invalid value at 1.990 sec. (initial_cpb_removal_delay_offset 4 294 967 283)
    invalid value at 2.031 sec. (initial_cpb_removal_delay_offset 4 294 967 283)
    elecard_example.jpg
    794 x 401 - 96K
  • @Mark_the_Harp That graph looks respectable enough to me as SpanMyBitchUp is pretty low on the frame limits but its close - what conditions did you film under? FTW Always check H/L on elecard. And run the tests for at least 1-2 minutes on a death chart to check it doesnt begin to slide in quality or develop underruns/overflows.
  • @driftwood It was handheld, ISO 800, late at night indoors with fairly dim illumination at 66mbps. Thank you for looking at it for me. I did one much longer take of about 2.5 mins with me playing the piano, so it had a lot more movement, and it did come up with an error, which was

    "Can't continue the analysis. HRD parameters are not presented (frame 3999)"

    Don't know what that's about, unless it's commenting on my piano playing. But the graph itself looks like it's not heading anywhere bad, and the quality seemed to hold up absolutely fine - actually, it looked amazing!

    However, I'll find a death chart and do a longer take and have a play in general so I get my head around the settings. Thanks again!!
    elecard.jpg
    794 x 401 - 95K
  • HRD parameters error happens sometime probably due to a hiccup in the write - try at least 2 or 3 recordings at that level and duration and see if the others also produce a HRD error. It shouldnt.
    PS as to your 'invalid value' errors, they happen even in the stock settings, so don't over worry about them, still trying to get an answer from elecard about why these happen. Probably due to a failed frame/field arrival/discard so a previous frame has had to be duplicated.
  • @driftwood

    2 more questions:

    1) So if the HRD error happens - what causes it? Anything I can control?

    2) You suggested looking at L settings. Here is the analysis of my 24L setting from the same modified patch, at 44mbps. The actual video looks fine (not quite as good as the 66mbps, but certainly OK). It was a locked-off camera of a stage performance with lighting changes, using the 14-140 at ISO 320. I forgot to do the downward ISO trick, and this was quite a noisy picture, but ran (and spanned) for 45 mins before the card filled up. This was taken from one of the middle "spans". I'm guessing this doesn't look at all right to you. Does this basically mean I've got the buffer size too high for the bitrate? And therefore wasting card space? Or is it not as simple as that?

    Hope you don't mind my asking all these questions. If there's a topic already here that explains all this, then by all means point me to it!!

    Cheers
    buffer_44mbps.jpg
    794 x 403 - 111K
  • @Mark_the_Harp What you have to remember is that 24p settings in ptools apart from the bitrate settings are shared between H/L - hence why for best quality you set it all up accordinglyto H, then hope the L setting bitrate (which is of course v low and which will much lower in quality) after 1 second will work.
    (click the buttons in elecard buffer analysis and see how big the i frames are)
    Also the spike in your last graph, did you make a drastic movement or not?
This topic is closed.
← All Discussions