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.
PTool 3.61d topic
  • 352 Replies sorted by
  • @Vitaliy_Kiselev Stop this cry? What does that mean?
  • @pwc That excel file is great and I sure appreciate it and would appreciate your continued updating... Al
    Edit: Any reason you did not add lpowell and EOSHD mjpeg settings?
  • Ok, so ... it's normal .. ok but .. it's possible to not recording this first second in SDHC Card and allow only "FAKE" first second ? :) ( black screen for exemple ... ) ?
  • @RSW
    >but when I start recording, the first and secondly second are 'broken' ... Have You a solution for this problem ?<<br />
    http://personal-view.com/talks/discussion/486/what-is-going-on-with-the-blip#Item_32
  • @pwc
    Good initiative! It hepls when doing your own tests. Your recommendation to include info around tests and result in the comments is essential.
  • As James Ritson found:"However, when using the recommended values of 42000000 and 35000000, which will produce the "blip", both the max and average values are reported at 4269.3Mbps (decimal point is correct) - this value is consistent with every clip. Edius really struggles with these clips."
    Here we go:
    bit_rate_value_minus1[0] = -28904 [4265370624 bits/s]
    Lots of applications that have to read HRD info
    containing [bit_rate_value_minus1] will choke.
    Other apps that ignore this value, only decode, will deliver the picture.

    Playing further around to look for correlations I found the values described as
    "Bitrate Settings" to be encoded directly into HRD info.
    (Of course these should correspond to the real bitrate.)

    "Top Setting" becomes [bit_rate_value_minus1],
    "Bottom Setting" becomes [cpb_size_value_minus1].

    For now I went back to re-flash V10E almost unpatched,
    just to get rid of the 30min limit and add NTSC+PAL.

    When I have more time I will have to study the VBV thingy within H.264 a bit deeper.

    Another finding, (although I may be wrong): Video buffer and Video buffer 24p seem to be reported in expected decimal values, but divided by 10, and on the Hex side.
  • I have created an Excel file with all the settings that have been published these last weeks in the different forums. I only kept the settings provided in the form of ini files. The Excel file contains also, embedded, the ini files themselves so that everything is self contained.
    Tell me if this is of any use to you and I will regularly update it.
    In order for a settings file to be as self contained as possible I suggest that before posting to prepare a new version of the file only changing its comment field summarizing what works and what doesn't, the film modes tested etc...

    Finally an issue that has not been raised before (maybe because it is a non issue) : does the firmware GH2__V10 that is used to hack the GH2 in anyway modify the ability of the GH2 to accept third party batteries? And can a third party battery somehow influence the reported contradictory results of the tests?
    GH2 Hack Published Settings v1.zip
    21K
  • What is the possibility of 24p in MJPEG?
    Is there anything I can do to help without knowing much?
    I have a GH2 and can do tests if someone tells me specifically what to do
  • @RSW:

    This is normal, we can´t change it. Try lower bitrates below 30 Mbit and the "blips" are history.
  • I am either, 34, 32 or 34 28, stupidly I forgot to note them down, just the four boxes, no gop adj or anything else, pal>ntsc checked and time lim checked. Thats it and they are consistantly around 28-30mb low detailed and 32-34 high detail in all settings 24p/1080i and 720p. They have no blip, perfect frame structure, work in the highest detailed situation, trees, grass, in all modes and to all intent are the same as the stock gh2 but with these fabulous bit rates(almost double ie 28mb+). Low light indoor delivers circa 30mb too always. I dont know why but these settings are absolutley brilliant. Thankyou VK.

    If people want the bin file to check for themselves, will upload, sorry I didnt create a preset, my mistake, didnt think I'd hit whats perfect for me after only 2 iterations.
  • Hi, sorry for my english...
    I've install the @kae settings ( seta.zip ), but when I start recording, the first and secondly second are 'broken' ... Have You a solution for this problem ? :)
    Thx for your answers..
  • @APXmusic: absolutely agree with you! Even I opened a similar topic about such a matter.
    The most of the users here are deeply lost in conquesting the best and highest possible bitrate, I think. But this utopian aim will give nothing at the end, be sure!
    It seems like the most of the users here have spent their money not to shoot and create something valuable, but just to play with bitrate hacks. 4K?!? Hehehe, and why?...
    The settings! The settings are the most important matter that needs to be worked on in the firmware!!! And it's a big pity that in comparison with Canon hackers, our general PTool hacker is very far from this purpose... Nothing personal, otherwise respecting his huge work anyway...
  • I have a suggestion for people trying to find optimal bitrates. I know that a lot of you want to try to find the highest bitrate possible. For us casual users who want to get a little more out of our camera I have an idea. I would like to find the most optimal settings that double the bitrate for each resolution and framerate. This way we are getting a better image but we are not going "overboard" with the settings. I think a lot of people might appreciate this. Anyone agree with me?
  • @sdbest
    @arvidtp
    Shutter speed at 50, no vibrations, no usb cable (taken directly from the sd as usual). The frames around the second i posted looks the same (with different kind of macroblocking), the bitrate is the same of the good ones.
    My opinion is that the encoder, with a still scene, degenerates with time, accumulating progressively some errors until it refresh. Vitalyi, what do you think?
  • I read on a post (somewhere on here) about using the low settings (H, 2L, FH) set at the unhacked high settings to test against new hack settings. Would this make the low settings be the same as unhacked high settings or is there more involved then just bit rate and GOP in the ptools basic adjustments? This seems a good way to test new against existing if it would work.
  • Beautiful work !
    Many thanks, Vitaly, I will soon donate when I'm back.

    While testing and all features seem to be working,
    I spent a little more time on compatibility issues.

    1280x720x50p, I chose 27,5Mbps to have something SONY DVD-A compatible and 35Mbps bitrate to have something Blu-ray muxable. Audio bitrate set to 256kbps.
    Previously after indexing and demuxing with DGAVCIndexDI 2038 I was able to use the GH2 streams directly in DVD-Architect 5.2 without transcoding. Now after applying 3.61d both elementary streams are scheduled for transcoding in DVD-A 5.2.

    I used DG VBV Checker 1.8 on the new video stream and found a wrong entry:

    bit_rate_value_minus1[0] = -28904 [4265370624 bits/s]
    cpb_size_value_minus1[0] = 25650 [26266624 bits]
    cbr_flag[0] = 0

    Previous setting read from stream:
    bit_rate_value_minus1[0] = 15659 [16035840 bits/s]
    cpb_size_value_minus1[0] = 10961 [11225088 bits]
    cbr_flag[0] = 0

    Looks as if the patch breaks at least the value
    bit_rate_value_minus1[0]

    Maybe only the minus sign ?

    Futhermore the coded picture buffer size seems to have changed with the bitrate setting.
    Overflows / underflows may occur now. Comparing previous/new bitrate patterns seems to give the impression that more values have to be tweaked to have a valid stream.
    Max/min bitrates are not respected anymore by the encoder, the more user min/max.bitrate are set apart, the more over/undershoot is to be seen.
    I guess a buffer setting has to be tweaked, but no time now to dig deeper..

    Even the 256kbps AC-3 audio is no longer accepted for muxing without transcoding.
  • I'm still new to this forum and to the GH2, but have a couple of questions.
    1. Is there some way to create a sticky so that the relevant thread is always at the top? This would help post instructions for us newbies as a first step instead of posting, like this. ;)
    2. Is the hack stable to use? By reading I can't really tell.
    3. Really just looking for simple up-to-date instructions.
    4. Also, not sure what settings I should be checking and unchecking. Is there any suggestions here?

    thanks
  • @sdbest huh - I'll test some long videos myself as that is really important to me. Don't see how the macroblocking could have been a USB problem. I'm pretty sure that if the USB messes up during a data transfer it doesn't usually 'degrade' your video or data or whatever in any "logical" way (logical to a human, that is) - the data transfer is rather totally stopped and unusable. There is no "bad connection" like in analog - it's either connected or it ain't :) The unreadable clips - now THAT could have been a USB problem. I'm just in the throes of developing a USB MIDI device at work, so I've become somewhat familiar with USB lately.

    @Elenion I can see that the 2nd frame is compressed worse. What's weird about them is the 2nd frame looks interlaced (1/2 verical resolution) while the 1st looks progressive - was your shutter speed on auto and changing so that sometimes the fields were from different exposures, sometimes not? (i actually forget if you go above 1/50 sec on the GH2 when shooting 50i - ?) Or maybe there were vibrations in the room due to some appliance or pump or activity outside going on and off randomly and if the GH2 on the tripod was vibrating, the picture could be moving slightly, making the interlaced frames different from each other, rather than exactly contiguous as they would be in complete stillness, and therefore making compression less efficient. Just a silly hypothesis and probably not at all reasonable.
  • @ Elenion, FWIW, recently I too had some macroblocking issues (or so I thought) with the GH2. I had difficulty transferring files to FCP. Some were even unreadable. Some with the macroblocking. Very concerning as this was a shoot for a client. It turned out to be a USB problem. Using the front USB port on my Mac Pro is, it seems, unreliable. While using USB ports on the rear of the tower worked fine. No problems at all. I'm not suggesting that this is your issue. But it may be worth checking. Just sayin'
  • I found a terrible issue while testing the 1080i50:
    With just 32mbit checked i recorded a 2 hours and 20 minutes video, a shot with no movements, quite poor in details amount and with slow variable light that comes from outside.

    After few minutes (apparently same light) strong macro blocking appears in the mid-shadows and they stop after other few minutes. Then it appears again after few minutes and disappears after others.
    The video is splitted by the cam in three files: the first contains 59 minutes, the second 1.11 hours and the third 12.28 minutes.
    The gop structure in streamparser is perfectly regular even in the footage where i can see macroblocking.
    The average bitrate is 10mbit, very low because i'm using a 2.8 80mm and the scene is poor in details with no movements.
    The first image is a snapshot of the correct image, the second one is the image with macroblocking (not much evident because the effect is visible with movement).
    The effect is terrible and pervasive.
    streamparser50i.jpg
    1292 x 680 - 178K
    vlcsnap-2011-07-26-13h08m54s67.png
    1920 x 1080 - 2M
    vlcsnap-2011-07-26-13h09m21s79.png
    1920 x 1080 - 2M
  • @vitaliy:

    that would be fantastic! Run and Gun with 30p:-)

  • Very exciting. Using the true frame rate makes perfect sense for correct audio playback. Do you think this audio discovery will have a connection to enabling audio through the HDMI?
  • aha - posts crossed in the inter-tubes. stuttering sound with digital noise is better than silence - I'd be very happy to investigate if it is at least predictable enough to be used for syncing.
  • also, i don't know what the problems are with the sound, but even if it was at the wrong speed or sampling rate, etc --- as long as that was predictable --- it would at least offer another way to sync 2nd system sound after a bit of time-streatching or resampling and would be more useful than silence :)
This topic is closed.
← All Discussions