Official Low GOP topic, series 2

driftwood

Thats why I am evaluating Sandisk, Transcend, Kingston, and Delkin Devices who all boast top whack SHDC UHS-I cards that should in theory work best. I think by Tuesday I will have all cards at my disposal. Thank heck Im not buying them all!

griplimited

@driftwood
Thanks. I already have 3 32gb Transcend and don't really want to buy more cards.

pedro

Hey driftwood,

I have to warn you the kingson SD card even though it should be able to do 40 MB writing speed=320 mbps for some reason I couldn't get it to run as fast the sandisk extreme pro sd card which I think is rated at 35 MB=280 mbps writing. I could get the sandisk extreme pro card and hte HD video card to write a clip with an average bitrate of 147 and a max of 240 but the kingston card crashed instantly. I got it to work at 130 mbps average but that was it and it cost a lot more. Someone else on the net tested the supposedly fast delkin sd card and it was no faster than an older model sandisk card 20mb=160 mbps.

Anyway I look forward to see what results you get.

Ralph_B

driftwood

Check this review at Tom's Hardware before you run your card tests.

http://www.tomshardware.com/reviews/sdxc-sdhc-uhs-i,2940-12.html

In particular, examine the "Write Throughput : hsbenchw 3.13" chart. The minimum values are most important.

driftwood

Hi @Ralph_B Yeah I saw that before... its probably a tad out of date now... that's what got me thinking about Kingston's new cards, and then Delkin announced some new cards which they press released as beating everyone, since the others have responded with a few new cards.... Ive asked each company to send the best SDHC compatible cards they do and to have a technician on hand so that I can talk to them.
Incidentally, I spoke with David Gleeson from Delkin and he said that they believe theirs is king at the moment after their own tests but he did suggest that some of the newer cards from their rivals were very close/coming out...
One of their SDHC designs released in April is press released here: http://www.dcviews.com/press/delkin-633x.htm
Delkin's cards werent sent to Toms Hardware for review.

Stray

@driftwood "What did you want to know?" Cool. The Elecard buffer analyser tells you how well the decoder buffer peforms with the set decoder buffer parameters, not the encoders buffer (the one in camera). So what I wanted to know is how it could indicate anything about in camera stability. Or are the decoder buffer parameters written into the stream by the camera ? If they are, as we edit/reencode the footage we shoot anyway (thereby changing the decoder parameters if they are physically written into the stream somewhere) isn't its results a non issue? So as long as the stream remains consistent, as in no cadence pulsing, flatlining, or drop off, then everything is good. However I guess if the decoder we use is reading the decoder parameters (including the decoder buffer parameters) from the header of the video stream, which does make a lot of sense to me, and there is a problem then we may have an issue on playing back or working with the stream in an NLE (which has to decode). I could be wrong, I don't know that much about the innards of H.264. I mean if the decoder parameters in the stream negatively effect the streams decoding in what way can they effect its manipulation/playback ? Won't the problem always be visible when we watch/edit the stream anyway ? I mean a decoding buffer underflow or overflow would be seriously bad, I'd expect very visible effects. From what I can gather its hardly rare for data to bounce about a bit in the decoders buffer, as long as there is no actual over/under flow its fine.

The camera must write the settings for the decoder based on how it encoded the stream, aha!, right, got it now. So if thats true then they must be good enough or the encoder couldn't have created a good stream in the first place. Maybe. @cbrandin, @lpowell or @vitaliy is this true ?

Can you set the decoder buffer parameters within elecard ? I'm guessing not as they must be in the header of the stream file.

bkmcwd

@proaudio4
Then, although I did the extreme test variously repeatedly, the recording of the set of Top&Bottomx6.6 stopped once.
Then, when lowering T&B multiple how far, it did not stop by any means or I investigated, and lowering to under 6.4, it turned out that it does not stop by any means.
Since I NEVER use SS1/800 usually, I will use 6.6 as it is, but I report just to make sure.
About T4=T1, the time of removing feels a little like good results with my view at the time of lowlight.

Just to make sure, I also stick the patch which set the multiple of T&B to 6.4.

paglez

@Driftwood
Do you know if Delkin 64 GB SDXC version works correctly in GH2?

bkmcwd

@Stray
@proaudio4
Please allow what I write continuously. ;-)
I set 24H and 24L both to 154M and confirmed the use of T4=T1 using 24p80% mode.
Since the difference from ON and OFF of T4=T1 was as the chart, I decided to turn OFF.
And I think that this setting will be able to use 24L as the safe mode, and may be convenient.

NOTE:
The size of the test chart in display of Streamparser is different because a field angle is changed and it is adding various stress in 2 minutes.

Stray

@bkmcwd Looking great. T4=T1 OFF is definitely the right decision. I've never seen T4=T1 do anything positive, I did believe at high bitrates that it didn't cause the drop off but what you've proved here is that it definitely can. The only difference is that instead of the drop off occuring later in the stream it happens right at the start, which is more consistent, but not good.

Butt

@driftwood
>If you are right, you are suggesting we all pack it in now and stick to 44m and go home.< yes ;)

No - continues, I hope at the better Patch in the Future
even for LowGOP

bkmcwd

@Stray
Thanks for your opinion! I agree with you.
I will record many things now for a while.

driftwood

@paglez re: delkin cards - no, doubtful, but we're getting one in anyway to test. Im more interested in their 633X UHS-I SDHC version than the SDXC version. But who knows! They ae supposed to be backwards compatible. However, a lot of people in various threads report probs with SDXC 'downwards compatible' cards.

driftwood

@Stray when you set your video buffer elecard 'recognises' the change in the stream according to the bitrate/video buffer ratio. ie change the video buffer from default to say 36000000, the buffer graph changes. In my earlier posts - I listed how it was working alongside different bitrate/buffer ratios for 36000000. You can then see how much headroom/how much fullness your setttings are, and how its performing - ie if its underflowing or overflowing and where it does this. You can then adjust.

I wrote about earlier somewhere also how it is good to maximise the buffer fullness.
Download the demo at elecard.

you asked 'can you set your buffer within elecard?'
no, of course not, it reads it from the recorded file's h264 nal hrd parameters file, found in the h264 sequence parameter set. You should read up on the h264 standard ver 10 for a good understanding.

Stray

@driftwood Yep, I get it, the buffer becomes the same setting as the decoders buffer. The buffer analysis tool basically is showing the efficency of the decoders buffer.

It still is only showing how it behaves during decoding, so as long as there is no buffer under/overflow then its all fine, the data rates bouncing about a bit in the buffer is okay. If it does run under or over we'd see that in the stream, and the buffer analysis would then confirm that was the cause. So I think its really a post-mortem debugging tool, as it could prove the cause of the problem was in the buffer setting.

To me a buffer that is constantly full, right at the edge, while decoding would be more of a concern than one where its data level was bouncing around (like any other buffer really). But I dunno really, the vagaries of the decoder as in what is actually best for it is beyond my ken. Still, the stream graph is still a good enough way of judinging stability I think. As I said, if their was a problem with the buffer during decoding we'd visibly notice it during playback. If someone knows more about this, and I'm completely off in my assumptions, then please correct me.

driftwood

@Butt when you make sweeping statements rather than writing off all current efforts it would be nice if you were able to demonstrate where things are not working for you with images/videos, proper discussion etc.... if you truely want to help. :-)

driftwood

@Stray No. it wont be a constant in a normal recording, it never will be, but when testing a test chart youre looking for a stable flow of data as one frame comes in and is parsed, the previous one at some delay will be removed, etc... Its better that you read up h264 standard learn what things are doing and then analyse them with the neccesary tools. Sounds like you're on it now. Which is good :-)

Stray

@driftwood Sorry, you've got the wrong end of the stick of what I'm saying again, it doesn't matter though. I'm happy now. It is the decoder buffer your looking at. I have been reading a lot, always do.

driftwood

@Stray All the tools are post mortem!!!!

Stray

@driftwood I know, can we drop this now. I get it, I've researched it and explained it. I'm all good.

driftwood

@Stray youre now doing what I had to do when I first started. Read read read. Thats brilliant, because your input is invaluable. You have a good way with words and I think you'll be able to explain things better to people the more you understand. Mate, we're all learning still. Even Vitaliy and Chris, no one knows everything about every setting yet thats why we test test test.

bkmcwd

@Stray
Since the cadence problem occurred today when I tried on outdoor the patch which I stuck the other day, I improved this again. :-)
The 1st and the 2nd screen shot are tested moving a camera by each field angle.
The 3rd screen shot is the result of sliding out from a screen, or returning and testing, also operating zoom moving a camera.
It seems that the zooming with moving can give an extreme stress.
The 4th screen shot is a thing when a cadence problem occurs with former patch.
Of course, I am going to verify this new setting outdoor.

NOTE:All settings are ignored except 24p.

Stray

@bkmcwd Looking good, I should be free tomorrow so I'm looking forward to giving this a test in town. I saw raitank's video on vimeo today that he shot with an earlier version of this setting of yours, good stuff.

bkmcwd

@Stray
Thank you always!
He is my friend. And, he also loves the film-look grain from low GOP.
If I am also possible, I am going to test outside today.

PerryWilson · 00007 (0.00.06.19).png

some new RAW frame grabs from a shoot... this was shot on @Driftwood QuantMeBaby GOP1.. with a LOMO 50mm f/1.8(The Brown Bomber) sharpest piece of glass I have ever had, and not 1mm of breathing... All shot in the rain...

Howdy, Stranger!

Categories

Tags in Topic

Top Posters