driftwood, Proaudio4 and RRRR. Thanks for the info guys. Just got out today and shots with the seaquake in day light. It is incredible. Image is sharp and so clean! Also, I change the L setting to 100mbs just so I can record longer like "Zaven13" said above. Everything work flawlessly. Thank you all for the hard work!
@gh2hacked to add to @proaudio4 and underline what @RRRR says, INTRA will always look better for motion, and don't forget with pure i frames you dont get so many artefacts; if you do fast zooms, pans, or anything where the pixels rapidly change (ie sudden bright lights or drastic change in highlights) any predictive LONG GOP will have problems predicting what the fuck happened/ will happen in the p and b frames until the next i frame.
@gh2hacked, You wrote: "I'm curious because I tested both last night and they are very identical in IQ, color grading, and green screen. Except, Driftwood's is a little brighter."
True > 66Mb/s AQ2 looks good overall. I've used Chris's 8/29 version. It's probably one of the most solid all around . It produces decent size static i-frames but Ralph_B's tests did show it gives up a bit on the motion vector frames.
Not to long ago I posted here (can't remember the name of the thread) a low light test that showed the difference in low light detail quality. I compared driftwood's reAQuainted against stock and another 176Mb/s GOP3, You can clearly see the difference in macroblocks as the image disappears into the absence of light. The higher bitrate settings are less smeared and render finer detail.
This is the reason why some felt there was more noise with these high datarate settings. Ralph_B did a great comparison between several settings compared to HDMI raw RGB. You could clearly see the differences, especially in motion frames. Also you could also see differences in how they handle and reproduce noise. Noise is seen as motion. So using driftwood's SeaQuake GOP1 setting and working with post noise reduction, this setting allows your NR software to make a better model for a more accurate noise reduction.
In the end, it really depends on how much you're into the final output quality. If 66Mb/s is good enough, so be it!
@gh2hacked - I have a hard time believing that Brandin's 66mb preserves the same amount of detail when there is movement and plenty of extremes (when long gop usually drops information) in the spectrum. For many uses, however, there is probably no difference.
I'm using Driftwood latest seaquake. To clarify to those that hasn't use the patch, the audio only jumpy on slow computer. So it has nothing to do with the recording datas. All audio work perfectly. Does anyone know if per frame size, which codec has more data Driftwood or Chris's 66mb? I'm curious because I tested both last night and they are very identical in IQ, color grading, and green screen. Except, Driftwood's is a little brighter. I can't really prefer one over the other. But the intra stuff is nice to know but does it really worth the extra disc space it takes up over Chris 66mb? I'm not noticing any different with the intra patch.
@vokwee still testing mjpeg, my first port of call is trying to get a decent screen size setting in mjpeg720 to work with Panny's 3D lens - I refuse to give in till Ive exhausted all attempts!!!! Despite everyone saying forget it! Im still learning the other settings which are quite different to AVCHD.
@driftwood Quantum patch seems to shoot 1080 24p fine onto Sandisk Extreme 30Mb/s cards. Sweet! I was wondering how AQ4 would affect write reliability. I don't have streamparser (on mac), but... So far so good. Thanks Nick!
*** BETA *** Driftwood 'Quantum' patch A beta patch trying out a few things. AQ4 on 1080p24, 720p60 limits raised slightly for improved i frame size plus AQ3. 1080p24L lowered to 64M - After one second the frame sizes will drop to around' SpanMyBitchUp' size requested by @balazer; to try out spanning with good quality on the L setting whilst keeping the H setting top quality. More encoder adjustments for even better QP. 1080i theory change (1080i encoders formula = 1080p + 720p encoder values (like stock). Does it improve things?
Let me know how you get on with it. In particular want people who have bought the 95Mb/s sd cards to try 24p out.
@JDN I don't have Streamparser but I remember Vitaly mentioning in one of the discussions that you could set one at lower rate. I have done some test shots and it worked great with great resolution. It's easy to test and you should try it for the shoots that you would be interested in. You may be surprised.
@Zaven13@driftwood Zaven, do you have streamparser info from this and/or sample vids. Pretty sure driftwood had looked at this already and there were some fundamental problems with putting one high bit rate patch on H and the other spanning patch on L (That said, if it really does work, I'm curious forsure).
For those of you who want to have the high bitrates of SeaQuake and the 80% slo mo capability of Aquamotion 2, I created a new patch that gives me both. I used Driftwood's Seaquake patch for 24p. I left the 24H value at 166mbs and changed the value of 24L to 100mbs and left everything else the same. I loaded the patch and tested. I get my high bitrates at 24H and I can do slo mo in 24L with no problems.
About in camera playback... if a recording won't play, you can try turning the camera off and on then play the clip. This seems to work for me, 720p in seaquake often has this problem.
No idea. These patches push the camera well beyond what the engineers had in mind, so unexplained things happen. Most of us are happy to capture good video, and we don't care if it plays back in the camera.
@balazer as far as not playing back in camera, ok, but why would the higher quality aquamotion not have issues playing back but the lower quality spanmybitchup does?
I use Aquamotion v1, and it spans and fills my 16 GB SanDisk Extreme HD Video cards every time. I can only suggest trying a different card or trying Aquamotion v1 instead of v2.
As for your playback problem: stop trying to play back in the camera.
Ok so some testing was done by me regarding spanmybitchup vs. auQAmotion and I have a few issues/questions:
(All testing done with a Class 10 16GB Transcend SDHC card)
With auQAmotion, it will span, but it stops every time at 19:08 seconds, leaving 3:51s left on the card. Looking at the AVCHD folder I see 3 4.67gb spanned files and one ~25mb 4 spanned file. Happens every time. So I'm wondering what's causing the video to stop recording at 19:08 when there is still space left.
Secondly, I decided to try out spanmybitchup for longer recording times, but I'm having issues with it, issues I don't have with the higher quality auQAmotion hack. The issues I get are as I shoot a few clips, I'll be able to review them, but once I've shot about 3-5 clips total, I'll get an unable to read file warning. When I leave playback and shoot again, sometimes I can, and sometimes I hit the record button and nothing happens. Once I get to this point I have to power off the camera. Once the camera has be turned off/on I can resume shooting again, but with the same issues happening eventually.
So long story short, auQAmotion works great, expect the 19:08s span limit, and spanmybitchup has read/lockup issues.