I think @driftwood and others have done a super job on GOP1 settings, and the area of GOP1 patches seem to be the most worked on patches to date.
It would now be great if we could go back to some of the stuff that @cbrandin was doing: trying to get a non-GOP1 maximum image quality to bitrate effeciency ratio. Chris's patch is great, but it doesn't span yet--so that would be good to do. This line of patch-making is still important I think since for many applications people will not need or want to use GOP1.
I've yet to embark on trying out my own patches / experimenting. So I present this simply as a humble suggestion to testers out there.
Chris's patches are excellent already, that's probably why we haven't heard much from him lately - he felt comfortable with his extremely hard endeavours (No one has worked harder than Chris apart from Vitaliy). I don't think at that size bitrate they can be beaten, but yes, newcomers should give it a go and not be afraid to. Most of the settings now have been explored enough not to brick the camera. There's room for improvement everywhere, even the GOP1 stuff, and don't forget Vitaliy hasn't finished with the GH2 yet, the new 1.1 firmware from Panny should prove an insight into where we can go next. Quite intrigued by this mp4 version of 1080p25 at 20mb/s which looks like could happen - and how it will affect the current system & encoder.
Hello everyone! Like LongJohnSilver I would like to ask the same: what is the de facto patch with highest quality vs stability at the moment? I am looking for an equivalent of cbranding 66m updated to the latest hack. I love Driftwood's patches but they require some fine refining I think. Don't get me wrong! They look really amazing but some of them still misbehave for me. I hope your programming efforts will continue rather than waiting for the new firmware 1.1 hack from Vitaliy.
Are there any reliable GOP6 or 12 patches working with the latest ptool guys? Please, everything I tried so far gives me reliability issues. Chris's 66M GOP12 was what I needed for now for the long shots but it hasn't been updated with the latest ptool and gives me card write errors. UPDATE! I've just realised what caused the problem with cbranding 66M- I was ticking the max iso limit in ptools. Since I left it untouched everything spans and the write errors are gone. Now, since I covered that for myself, it's the quest for the Driftwood's best stable GOP1 :o) Seems I am talking to myself here since everyone is so excited about the FW 1.1 now :o)
@driftwood The iso tick problem with the latest ptool applies to Chris's patch. Without it ticked it spans, goes on for over half an hour and doesn't give any card errors. I haven't experimented with yours in this way yet but it's a good hint, thanks. Unfortunately the current weather is not permitting the "moon test" where I had the problems.
@driftwood Your patches behave well, it seems to be something I am screwing up on Macbook Pro. The vid decoders on Mac struggle with very dark footage, so do the YouTube ones it seems when uploading the original clips, however Sony Vegas on PC deals with the footage with ease. So much more for me to experiment with... So, to summarise, your patches ARE reliable. I felt I should have clarified this.
I used it with Pretec 32GB class 10 cards, actually more like class 6 cards. I shoot everything 24p. I did some tests and everything looked as it should (first screen)
I went on a vacation and my oh my, real life footage doesn't seem so perfect in stream parser. Where is the bitrate, where is the consistency?
Some of it was cut in camera, but I did some tests for in camera cutting and it looked in stremparser exactly the same as before cutting.
Is it the compression adapting itself to different conditions, or is there something wrong?
Help will be very much appreciated.
It's my first post here so if there's a better place to post this question please tell me.
@piotremanuel Thanks for the report mate. Yeah seaquake Quantum, etc... all should be good. These are highly measured settings and shouldn't ever go wrong.
@Driftwood If Vitaliy is able to finish the new firmware portation this weekend, do you think that Quantum new firm based would be available this weekend also?
@driftwood I'll assume “the encoder goes skewifth” means It's not working properly ; ) Any idea why?
Is it time to hack my GH2 with some other settings? Would you recommend some rock solid ones that would work on a class 6 card and keep the file size within reason? Of course „maximum quality” ; )
@driftwood A friend recommended the @cbrandin 44M settings and they are the only ones I have tried. I am not a tester type, finding all the necessary information and understanding how to hack my gh2 was difficult enough for me. The initial test went well so I didn't feel a need to change anything else ...until I checked the real life footage out.
I have to say I admire you guys for the immense work it takes for perfecting the settings.
I got V frames on 27 out of 123 files, almost all of those 123 have been cut in camera, and I think all of the 27 files have been cut in camera. @cbrandin said „StreamParser identifies frames as V frames when there is something wrong with a header and what type of video frame it is can't be identified by looking at transport stream header data.„ Using any software that allows .mts cutting results in stream parser almost always showing V frames. I thought it was bad so i decided to cut in camera since when testing I got no V frames on in camera cut footage.
So is there really anything to be worried about? The footage looks nice and the chart full of V frames looks just as any other chart only without colors ; )