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.

I'm using Chris patch 44/32 for production.
Patched with previous ptool, but latest ptool did not patch it right i got card write errors ...

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.

@driftwood
Is this the latest Quantum V2 beta?
http://www.personal-view.com/talks/discussion/comment/28583#Comment_28583
I saw that L settings should be used for span & long recording.
Wouldn't be better using directly the aquamotion or spanmyb for longer recording times?

Hummm seems like all the GOP3 patches were discontinued

Thank you Nick for your great work

LJS

Nice finding piotre, so as I understand you have the new 64Gb card, turn off iso limit, and you have no probs with Quantum/seaquake?

@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 Oh, I didn't find any mention of it anywhere.. I think it should be spelt out for those who have write problems with cbrandin patch.

I have a question about @cbranidin 44M

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.

@paglez

No way I'll be able to finish porting this weekend.

@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 ; )