Yes. I did almost as much testing in 720p as in 1080i recording modes. I'm very interested to hear how well it works in both modes.
40Mbps AVCHD High Reliability Patch
- Thread starter Lpowell
- Start date
rambooc1
Well-known member
Don't get me wrong, very happy with the 7 - 38Mbps data rate of the hack and these settings, but is the variable codec able to relied upon to throw enough bits at the lower detail stuff. Would a minimum of 17Mbps make the low detail images better, or are they optimal as is??
To evaluate low-detail bitrates, I took two fascinating series of FHD videos of my sidewalk, at 1/50, 1/100, 1/200, and 1/400 second shutter speeds. For the first series, I focused my Nikon lens sharply on the flat concrete details. Then I defocused the lens just enough to blur the details, and shot the series again. Here are thumbnails and GH13 Stream Parser screenshots of the resulting bitrates:
Sharp Focus Series
1/50 second shutter
1/100 second shutter
1/200 second shutter
1/400 second shutter
Soft Focus Series
1/50 second shutter
1/100 second shutter
1/200 second shutter
1/400 second shutter
With sharply focused details, bitrates stayed up around 35Mbps for the top three shutter speed brackets. But with an underexposed 1/400 second shutter, the bitrate dropped down to 19Mbps.
With the soft focus image at well-exposed shutter speeds, bitrates were also around 19Mbps, and dropped down to 15Mbps with an underexposed 1/400 second shutter.
On virtually featureless images, I'd expect the bitrate to drop even lower. But for most low-detail subjects, it looks like we can count on at least a 15Mbps bitrate.
Last edited:
rambooc1
Well-known member
Thanks for doing these tests ipowell
With all due respect, I wouldn't call concrete texture low detail, obviously it is high detail as evident in the 35Mbps result. However, are you happy with the low detail video of "real world" images at low bitrates, ie a talking head in front of a flat blank wall or talking head in shallow DOF situations?
I'm happier now i've unticked native (to get rid of pulsing), but still think we could benefit from more BR at low detail. Just seems to be something not quite there, maybe i need a kit lens rather than CanonFD's.
R
With all due respect, I wouldn't call concrete texture low detail, obviously it is high detail as evident in the 35Mbps result. However, are you happy with the low detail video of "real world" images at low bitrates, ie a talking head in front of a flat blank wall or talking head in shallow DOF situations?
I'm happier now i've unticked native (to get rid of pulsing), but still think we could benefit from more BR at low detail. Just seems to be something not quite there, maybe i need a kit lens rather than CanonFD's.
R
Yes, I do consider the sharp-focus concrete to be a moderately high-detail subject. By defocusing it and bracketing down the illumination, I was using controlled conditions to examine how the encoder's bitrate drops off as image detail is reduced.
I think my blue sky shot of the Lux Mausoleum is a good example of an interesting real-world subject against a low-detail background. It produced a 20Mbps bitrate, and looks very good to me.
http://dvxuser.com/V6/showpost.php?p=2069399&postcount=33
I think my blue sky shot of the Lux Mausoleum is a good example of an interesting real-world subject against a low-detail background. It produced a 20Mbps bitrate, and looks very good to me.
http://dvxuser.com/V6/showpost.php?p=2069399&postcount=33
Last edited:
Uncle GroOve
Active member
Thankyou! I too had installed your patch and was getting The Big Freeze :-/
will post a 1080/720/MJPEG comparison of your patch later today.
First indication of the stable MJPEG patch is an astounding 40MBS (QUicktime inspector).... Wow...
Thx for your great efforts!
Paul
Last edited:
I don't understand. What's the point of those charts?
Chris Light
Veteran
what's not to understand? the chart shows what the bitrate is throughout the footage and how it's much higher when the shots are more detailed. seemed pretty straightforward to me.
Well, I think bit-rate like 17-38Mbps would be much better!..
17Mbps in low detail scenes will be much better .. like you said - 17Mbps would make low detail images better.. i think...
Last edited:
sweetdollar
New member
Ok, did some testing with lpowell´s settings. :thumbsup:
I have a PAL camera (50i), Sandisk class 10, kit lens and 20 1.7.
Using the Starchart,tripod, autofokus and iA (it is hard for me to push the camera like that in real life).
I got an average of 35,7 using my PS3.
Long story short. Changed Video Bitrate and Overall Bitrate.
Video Bitrate FHD/SH=52000000 (41000000)
Overall Bitrate=54000000 (43000000)
Preset bitrate=180
Preset bitrate 2=180
Now my average is 44,9. It can fail on grass on these settings. Camera stops but video is ok. Photo cropped
http://dl.dropbox.com/u/9863865/Tree52%2C54.MTS
http://dl.dropbox.com/u/9863865/Grass52%2C54Stopped%20.MTS
I have a PAL camera (50i), Sandisk class 10, kit lens and 20 1.7.
Using the Starchart,tripod, autofokus and iA (it is hard for me to push the camera like that in real life).
I got an average of 35,7 using my PS3.
Long story short. Changed Video Bitrate and Overall Bitrate.
Video Bitrate FHD/SH=52000000 (41000000)
Overall Bitrate=54000000 (43000000)
Preset bitrate=180
Preset bitrate 2=180
Now my average is 44,9. It can fail on grass on these settings. Camera stops but video is ok. Photo cropped
http://dl.dropbox.com/u/9863865/Tree52%2C54.MTS
http://dl.dropbox.com/u/9863865/Grass52%2C54Stopped%20.MTS
Last edited:
Increasing Video Bitrate and/or Overall Bitrate as you have done will push the AVCHD codec into the range of the PTool "C" settings. While you will see higher average bitrates, the peak bitrate will also range significantly higher, and can provoke the type of recording failures you describe. I suspect these failures are not due to SD card write speed limitations, but are instead caused by internal buffer overflow errors within the AVCHD encoder.
Yes, the 41M + 43M settings are optimized to produce the highest average bitrate while limiting the peak bitrate to 44Mbps. According to the GH13 Stream Parser, this also provides an adequate safety margin to avoid internal buffer overflows. When you push the encoder higher than this, you're exploring the lower range of sub-optimal "C" settings.
sweetdollar
New member
My data (average 44,9Mbps) is coming from my Playstaion 3.
I have never used the GH13 Stream Parser, and I am going on a vacation tomorrow.
Feel free to analyse my clips.
Pal (50i) settings should be higher than NTSC (60i), and ok maybe I am the edge of failure..........But unless you are a iA (Auto) and grass and tripod lover........You are safe..:beer:
I have never used the GH13 Stream Parser, and I am going on a vacation tomorrow.
Feel free to analyse my clips.
Pal (50i) settings should be higher than NTSC (60i), and ok maybe I am the edge of failure..........But unless you are a iA (Auto) and grass and tripod lover........You are safe..:beer:
Thanks for sending me a copy of your original MTS file, zigizigi. The recording plays back correctly and the GH13 Stream Parser reports no errors in the file. However, when I analyzed the video stream in detail, here's what I found:
This FHD video was recorded in Native 25p progressive mode. I've found that this can cause sporatic recording failures, regardless of the video bitrate. In the Stream Parser Frame Data panel, the selected packet shows the first and only video packet recorded in the last frame of the movie, followed by a number of Null packets. In the Packet Data panel, the selected video packet is shown to be empty of video data.
I suspect that what happened was the encoder abruptly choked for some reason related to the Native 25p setting. The interruption in the stream of encoded video data was detected after a number of Null video packets were written, and the recording was terminated.
Last edited:
Are you sure? I just looked at the settings I saved before flashing - the Native 24/25p box is unchecked.