THE SEXY, RELIABLE "NATIVE 25p" THREAD

Lucas Adamson

Well-known member
OK, so those 24pN guys have got their own issues, what with pulldown and NTSC weird frame-rates.

I thought we PAL fellows needed to discuss attaining a rock solid 25pN hack setting without those issues obfuscating our own.

So far I have tried a few hacks, with varying degrees of success:

1. LPowell's Reliable In camera Playback - 25p in a 50i wrapper. It is genuinely reliable! But not native.

2. LPowell's Reliable In camera Playback - 25pN - I just ticked the native box. It is not entirely reliable - but it is native!

3. The new LPowell/ Blackout Native 24p Hack - works well for 24pN, we hear, but not 25pN.

So now I want to build on this to get the 25pN reliable hack we all deserve...

Questions:

1. What is the ideal GOP for 25pN? 12, 12.5, 13, 15, or what?
2. We need one extra frame per second. What's the effect of that?
3. We don't need pulldown - surely this should make things easier for us?
 
Thanks for the props, Lucas. I'm currently working on improving the reliability of the Native 25p mode in the Blackout-Powell Native 24p Patch, and it will really help if PAL dvxusers can assist with the testing. While it's always been my goal to provide full support for both NTSC and PAL modes in my patches, I've frankly not been able to put in as much testing time as I would've liked on the PAL side. With this patch, stabilizing Native 24p was especially difficult and that made it necessary to prioritize it over the corresponding Native 25p mode.

One of the major challenges in optimizing a patch for both NTSC and PAL use is that almost all of the AVCHD patch settings apply to both 24p and 25p modes (and likewise with the patches that apply to both 50p and 60p modes). It's often been difficult to find settings that work well for both 24p and 25p. The following patch settings are shared by both 24p and 25p modes (with current Blackout-Powell settings):

Native 24p/25p - on
Video Bitrate FHD/SH - 50M
Overall Bitrate - 54M
Overall Bitrate 2- not used
Preset Bitrate - 180
Preset Bitrate 2 - 180
Constant for 1080p - 4860000

Here are my current thoughts on further optimization of Native 25p mode:

Recording lockups are sporatic and will typically occur at around 5-8 seconds. I suspect aliased, fine-detail edge-artifacts may provoke bitrate spikes that overrun an internal data buffer and abort the recording. The fault does not appear to be dependent on SD card write-speed or Class rating.

Video Bitrate FHD/SH - This sets target bitrate for all video modes. Reducing it will lower average bitrates, but I have not found any setting that will eliminate recording lockups.

Overall Bitrate - This sets the peak bitrate of the encoder at 55Mbps and indirectly determines the size of internal data buffers. Increasing this beyond the current setting will boost the peak bitrate to nearly 75Mbps and will most likely reduce stability at high bitrates.

Overall Bitrate 2 - This doesn't appear to affect the Native 24p mode, so it's possible it could be used to improve Native 25p behavior. However, any changes would need to be regression tested on 50p and 60p modes as well.

Constant for 1080p - The Native 24p patch works reliably with a broad range of settings from around 1M to over 10M. I settled on the current setting by using a coarse binary search pattern to test. There's a broad room for adjustment here, though the optimization curve looks to be pretty flat.

1080p25 GOP size - This is the one patch that applies solely to the 25p mode. It defaults to 13 in the stock firmware and I suspect that increasing it may help improve stability. The GOP size I'm currently testing is 15, but it takes many trials to verify consistent results.
 
thanks guys! haven't done a lot of testing yet, but from what I noticed, chnaging GOP size to 15 helps a lot.
 
well, honestly, all I did was changed GOP to 15:) everything else is the original 'native patch'. before the change I'd hit the error in about 15 seconds shooting indoors fairly complex objects with a lot of texture. now it's not the case. haven't done any outdoors test yet (will do during the weekend)
 
One question about 25 progressive fps Native that I feel worth nailing down the answer to is - is it necessary?

I have read on these forum pages that the 25p out of the GH1 is "progressive in an interlaced wrapper" (i.e. it is not interlaced footage), and that it simply needs dropping onto a 25p timeline in a video editor, a process which occurs without quality penalty (unlike de-interlacing and pulldown, etc).

I do not know if this is the case or not as I don't yet have any video editing software (still trying to figure out which to get and why). If someone familiar with such things could film the same scene with the native hack activated and not activated, then compare quality results on the same timeline, the answer should be available.

If it turns out that the quality is equal, 25p PAL users can work with the completely safe, high bit-rate settings already established. Achieving native out of the camera would then remain an enticing technical challenge but not one as important as 24pN.
 
OH very happy to see this pop up, on the heels of the wonderful POWELL-Blackout (or "Blackout-Powell" for the alphabetic/tophat fanatics ) 24p settings.

As regards to LPowell's request for testing, I would gladly help... if there is already a systematic plan-of-attack.
Otherwise I will screw around with the values LPowell noted, esp. the last two parameters... and follow this thread religiously.
 
I just looked at some of my shots from last month and analysed them with stream parser. These are non-native 25p files by the way, but i had set the GOP to 5 and i don't have any empty frames. I have a general theory that everything in 25p comes down to multiples of 5

Anyone wanna try these with native settings as i don't have my camera at the moment.

According to my notes these were my settings:

Video Bitrate-50,000,000
Overall Bitrate-55,000,000
1080p25 GOP Size-5
Preset Bitrate-500
Preset Bitrate 2-500
 
I just looked at some of my shots from last month and analysed them with stream parser. These are non-native 25p files by the way, but i had set the GOP to 5 and i don't have any empty frames. I have a general theory that everything in 25p comes down to multiples of 5

Anyone wanna try these with native settings as i don't have my camera at the moment.

According to my notes these were my settings:

Video Bitrate-50,000,000
Overall Bitrate-55,000,000
1080p25 GOP Size-5
Preset Bitrate-500
Preset Bitrate 2-500

Regarding multiples of 5, well, it is the highest denominator, so you may have something there, as 15 has already been said to cause an improvement, and 12 is the highest demominator of 24 and that also works well....

I will test the native hack with GOP15 again tomorrow I think...
 
One question about 25 progressive fps Native that I feel worth nailing down the answer to is - is it necessary?

I have read on these forum pages that the 25p out of the GH1 is "progressive in an interlaced wrapper" (i.e. it is not interlaced footage), and that it simply needs dropping onto a 25p timeline in a video editor, a process which occurs without quality penalty (unlike de-interlacing and pulldown, etc).

I do not know if this is the case or not as I don't yet have any video editing software (still trying to figure out which to get and why). If someone familiar with such things could film the same scene with the native hack activated and not activated, then compare quality results on the same timeline, the answer should be available.

If it turns out that the quality is equal, 25p PAL users can work with the completely safe, high bit-rate settings already established. Achieving native out of the camera would then remain an enticing technical challenge but not one as important as 24pN.

It is a very important question, and here's what I know:

25pN is so much more efficient than 25p in 50i wrapper (like half the bitrate) that it makes a lot of sense to try and crack it. I do think that 25p in 50i is good though, so if we can't get this relaible enough, I will go back to that, or use a combo of the two, whipping out a dedicated 50i wrapper file when I'm in the woods or whatever other location tends to cause crashing. The two seem to mix OK on the timeline...
 
Well, PAL users, what do you think about changing the 25p GOP-size to 15 frames? I've tested this setting several times in the past week, and while it's not immune to failure, it does seem more reliable than the previous 12-frame GOP I used in the Blackout-Powell 24p Patch. If we conclude it's a worthwhile improvement, I'll release an updated INI patch file in that thread.
 
Well, PAL users, what do you think about changing the 25p GOP-size to 15 frames? I've tested this setting several times in the past week, and while it's not immune to failure, it does seem more reliable than the previous 12-frame GOP I used in the Blackout-Powell 24p Patch. If we conclude it's a worthwhile improvement, I'll release an updated INI patch file in that thread.

After a week of trying to get this to work with 15 GOP, i have to conclude that i think BO might be right about hardware differences between Gh1's.

Yes the 15 GOP takes longer to fail compared to the 12 GOP patch (about twice as long), but i now have other issues with the ones that DON'T fail not playing at all .... not being able to be dropped in Vegas (crashes), and the ones that do play have the old pulsing problem reported way back and frame jumping. Weird.

I think the limit of my particular GH1 unit is the LPowell Reliable patch without native ticked. It has never, ever failed me. I have another GH1 on the way, so i'll try that one and see if it copes better. My GH1 was an Original PAL model bought in OZ, so maybe this could explain the difference. ???

Rambo
 
Last edited:
nice!

nice!

Well, PAL users, what do you think about changing the 25p GOP-size to 15 frames? I've tested this setting several times in the past week, and while it's not immune to failure, it does seem more reliable than the previous 12-frame GOP I used in the Blackout-Powell 24p Patch. If we conclude it's a worthwhile improvement, I'll release an updated INI patch file in that thread.

I spent the entire afternoon filming with this patch@ 15 GOP... it did not fail me ONCE (hip-hip!) with approx 45 min. of material. Shooting outdoors/indoors at an abandoned factory, some sunlight, some rather dark interiors. All went very well and to my eye the detail is a very noticable improvement , just playing the material "raw", no editing yet. (I was using "LPowell's reliable" up until now)

That's my initial 2cents and thanks much for this!

p.s. one quirk I did note, was that if I had "old" (with LPowell reliable) FHD files on a card and tried to play them internally on the camera THAT would freeze the camera everytime. So it is advisable that all avchd files recorded before applying this patch should be deleted from the card when using the patch.
 
Last edited:
p.s. one quirk I did note, was that if I had "old" (with LPowell reliable) FHD files on a card and tried to play them internally on the camera THAT would freeze the camera everytime. So it is advisable that all avchd files recorded before applying this patch should be deleted from the card when using the patch.

Ninetto, let me get this right. Are you saying if you had older video files from the reliable patch on the card, your camera would fail every time RECORDING with the new patch or just when playing them back in camera??
 
Ninetto, let me get this right. Are you saying if you had older video files from the reliable patch on the card, your camera would fail every time RECORDING with the new patch or just when playing them back in camera??

I'll try to explain more clearly: I shot for a couple of hours today, creating over 45 min of pure/perfect 25p with NO freezes. After transferring the files to my computer and evaluating the files -they were excellent - I then wrote my glowing post.

THEN I popped in a card that had LPOWELL-RELIABLE files on it because I wanted to play the files "natively" from the camera-hdmi output to my beamer to compare with the new files, and the camera froze trying to playback these files. EVERY time.
This may be a quirk specific to the native HDMI output and have no effect to encoding/recording video, I have not done any tests yet ... instead I quickly re-formated the card with the "old " files to avoid inadvertently freezing the camera on what seemed like a perfect 25p shoot.

Moral of the story: I suppose it pays always to reformat any cards when changing the firmware. This is a well-known step in changing NTSC-PAL but I was surprised to run into this problem.
 
Ninetto, I had the same problem and only discovered it's best to reformat the card ...

so far no crashes 100 %

Big thankyou to all the testers
 
@ninetto , That has nothing to do with recording the 25p good files though, as they were on a different card. My Panasonic HMC 152 won't playback 720p or 1080p if the camera is not in that mode.

I reformatted my Sandisc extreme card, same issues, nothing changed. (I have separate 2Gb cards for each FW patch, never use my main cards)

I still think you guys are shooting mostly in low contrast situations and would have got the same results with the Reliable patch. Every one's talking it up, no one's posting video evidence or details of lens, scene, tripod, etc. (except DrDave and even his tests have 50% sky and low detailed scenes)

It's no good for me if i can't pick up my camera point it at something, expose, focus, shoot and capture images. If i have to evaluate every shot based on restrictive parameters it's not worth it.

Stream Parser is telling the files are corrupt and will only load them after i accept the prompt to allow Parser to trim them. But even the "save as clean option" renders faulty files in Parser.

Have fun, thank God for the lpowell reliable patch.
 
Last edited:
@ninetto , That has nothing to do with recording the 25p good files though,.

@ rambooc, I never claimed this playback bug ever had anything to do with recording... you asked me to clarify with more detail.

Sorry to hear the patch isn't working for you, but if I posted all of my 45min of material that would not help you either... the veiled criticism that we are somehow "cheating" or "talking up" the initial results with this patch is rather unfair/impolite.

As usual there are many parameters at work here. We are just trying to nail them down and see what works. In effect, doing exactly that what you yourself desire when you write you just want to "pick up my camera point it at something, expose, focus, shoot and capture images".

That said, I did not try to "break" the codec with noon-time walks thru some thorny underbush. I will continue using this patch this week and report back if/when the camera freezes.
 
Last edited:
Nice

Nice

OK, I am truly happy with this patch! I have now been using it for 2 weeks and over 2 hrs. of material with no crash.
Here you can see some examples, I especially was looking for difficult situations that LPowell mentioned, which would seem to be the stuff in this footage of the abandoned factory: high-contrast, lots of fine detail with all the wild-grown trees, broken glass and roof contruction. Yet, the BlackoutPowell patch took it all in stride.

all material with stock zoom and 25p full HD, @ 1/50th and ISO 400...
I forgot the sun-shade for the lens, and although there is some "stray lens light" (don't know the english term for this) I was surprised not to see any chroma aberation that I have often had problems with strong backlight and "normal" video...

http://vimeo.com/22800379

The video was all shot hand-held @ 1/50, nevertheless still some fine detail in these stills (from original video, uncorrected):

factory01.jpg


or here hand-held with something like 135 mm and 1/50th, still lots of detail...

factory01_1.jpg
 
Last edited:
Looks great! Have you tried a locked off shot on some foliege. Use a tripod, manual everything and see if that passes the test.
 
Back
Top