Official Low GOP topic, series 3

TrackZillas

My latest video all shot @ ISO 1200 with @driftwood 176mb/s GOP1 ReAquanted image is soo clean love this camera... Lens Pani 20mm f1.7, Dynamic shutter 50th all available lights.

jdough4421

Thanks for the latest patch, Nick. I'm going to test it out tomorrow.
Is there any way for U.S. users to get 720p/50p? I would like to use the INTRA settings for my 720p recording, alas my camera just does 60p ...

proaudio4

@driftwood...
Woops.. LOL! Yes, I meant to write Q15.
If Vitaliy deletes the png, I will up update it.

pinger007

@bkmcwd

Nice movement! Could you supply a link to your diy steadicam instructions? Thanks.

bkmcwd

Since the last test differed in conditions considerably, we did the test which similarly arranged conditions today with my friend.
I used usual DIY steadicam and my friend used his own ActingCam.
I think that comparison is possible although some motions are different.
However, honestly, with my eyes, I do not understand a difference well. :-)

reAQuainted

GOP3ZILLA-Q14

RRRR

I've found this strange thing, maybe it's just premiere but sometimes the reds go jagged, as if they were interlaced. It happens to strong reds / oranges with sharp edges.
I've had this on many patches, I first noticed it while shooting 720p50 and thought it to be some kind of interlacing going on (as 720p50 and 50i seems to be connected somehow). During yesterdays tests of Driftwoods latest work I encountered the same in 24p!

Any thoughts? This is propably the wrong topic for this, but I didn't know where to put it.

driftwood

@proaudio4 on your test: AQ15?!!!! you mean Q15. ;-)

bkmcwd

@proaudio4
Thank you for testing specially, while you are busy! ;-)

BTW,Although I looked at and remembered these comments, isn't the result of this test compared by the portion of the B frame?
http://www.personal-view.com/talks/discussion/comment/20988#Comment_20988
http://www.personal-view.com/talks/discussion/comment/20999#Comment_20999

As for the portion of the B frame, I also recognize that a noise becomes dirty.
However, since the frequency where a clear noise appears compared with 12GOP since the number of the I frames of 3GOP is 4 times the 12GOP increases 4 times, although 3GOP is not like 1GOP, I think that a noise will be clear seen rather than 12GOP?
Although it is unavoidable that a dirty noise appears at a compressive relation unless it is 1GOP, I consider it that the composition made to balance with other elements is 3GOP.

proaudio4

Yes, thank you Chris for that explanation.

proaudio4

All, sorry for not posting some of my tests I mentioned earlier. I've been freaking busy.
Here's the low level noise test I mentioned earlier. What I am finding with these high bandwidth settings, especially with reAQuainted, the low level data has finer data representing detail as it falls into darkness.
This produces finer more nature noise "like" a CRT raster scan. We are getting "closer" to the raw output from the GH2 sensor and converters.

driftwood

And underrun/overflow the buffer.

Stray

@cbrandin many thanks for your explanation of what can possibly happen in that situation. Its been bugging me for a while as to what actually happens, I thought the whole frame rate dropped. I had some shots I took with the 66M GOP3 that would display the same behaviour of breaking the max speed and saw some strange things in playback. Some of it looked quite beautiful, like some sections of the frame were slower or stuck for brief moments. The fact that it could just drop packets as you describe explains what I saw perfectly to me. I may recreate and use it sometime, as some of the shots had a great and peculiar quality.

bkmcwd

@cbrandin
Thanks a lot!

I think that I will naturally improve my patch since I probably understood your opinion perfectly.

@Stray
Thanks always；)

cbrandin

OK, I think I understand. If the max speed is not exceeded you should be OK. The problem I have with your suggestion is that it means you will rely on being lucky when you shoot. It's better to try to avoid the situation with stress tests - that way no matter what you shoot, you should be OK.

Chris

bkmcwd

@cbrandin
Thank you very much for your reply!

Indeed, I understood that it was not "should not exceeding" but "better not to exceed". :-(
O.K, I think that I will improve this patch as you say.

BTW, "I'm not sure what you are asking"
My question is as follows.
With the patch in which the video bit rate exceeds the maximum video bit rate when an extreme stress test is done, when shooting an ordinary situation, do not exceed, either, but. Do any problems occur by using so that the patch of such character may not be exceeded in an ordinary situation?

Doesn't it get across to you again?

cbrandin

@bkmcwd

I'm not sure what you are asking. Actually, it's the "Average Total Bitrate" that should not exceed the "Max Speed" (sorry for not having been more specific in my previous post). If it does, I think there might be problems - like cadence issues and packets dropped by the decoder.

Chris

bkmcwd

@cbrandin
Thank you for your great work and relevant description always.

In my strange English, it may not get across to you, and I have a question.
For example, if this arrangement of mine does not apply stress forcibly, either, the video bit rate does not almost exceed the maximum video bit rate, but is there any problem still?

driftwood

@All A lot of you have promised some recordings...
(see http://www.personal-view.com/talks/discussion/1268/gh2-intra-demo-its-collaboration-time#Item_59)

yet only 6 of you have so far submitted 10 seconds of video. Deadline cutoff is the 10th November. If you want to be part of it - please send me a link to your upload site together with info on how you recorded it, using which INTRA setting. Thnks! :-)

cbrandin

@Stray

You are right in being concerned about the video bitrate exceeding the max bitrate. The max bitrate is calculated from TS packet timer stamps. When video bitrate exceeds the maximum there are packets that end up with identical time stamps (they are supposed to all be different and ascending). I'm not sure how all codecs deal with this, but I would assume that with many, if not all, packets will end up being dropped. These are 192 byte packets - so when they are dropped only a small portion of a frame will be affected - it might be hard to see.

Chris

bkmcwd

@proaudio4
Thanks for your checking!
I understand about the point which Stray pointed out, of course.

This 88M as well as the time of former 66M is satisfactory at all.
Of course, about framerate.
They are 24fps perfectly.

Does this cause any problems concretely?
I have not met with the problem until now. :-(

proaudio4

@bkmcwd,

Stray is not refering to a cadence issue.
Just load your mts file into your video editing program and check the frame rate.

driftwood

@csync like every new patch, it needs group verifying, but in principle, I'm happy with it.

csync

@driftwood

is this a recommended update to your latest 176 patch? it sounds like it's a bit more stable.

bkmcwd

@Stray
Thanks mate! ;-)
I have shot the tree today, moving a camera in the up-and-down direction.
The camera just stopped at the top and the bottom for a moment the place where the slot is made into the wave of Streamparser.　This is not cadence problem.
Although I think that it is still generous, since it is my purpose to make this patch economical, I think how to adjust.

bkmcwd

@driftwood
I am looking forward to trying your new great patch! :-)
My work fills the niche between your great works, I hope.

@someone
I stick the sample of 24p and 30p with my latest 88M 3GOP.
Since 30p was used satisfactorily, there seems to be no problem also at a little lower Q value.
24p

30p

Howdy, Stranger!

Categories

Tags in Topic

Top Posters