I call BS on the "Cadence Problem"

LPowell

@cbrandin "There is a bug in the GH2 codec where if the bitrate/1024 goes above 32767, the reported bitrate becomes this huge number."

Nice detective work, but the implications sound disturbing. 32767 * 1024 is a max bitrate of only about 33.5Mbps, which most patches will exceed. It's also very close to the max bitrate the GH1/GH2 can handle when playing back MJPEG files. Perhaps the in-camera MJPEG player is checking this erroneous reported bitrate, and refusing to even attempt to play back the MJPEG file? If so, there may be a way to bypass the reported bitrate check...

Vitaliy_Kiselev

@LPowell

This bug is known for quite long (in form of sometimes strange behaviour), and about a week, I think, I posted in stable topic to use < 32Mbps values.

As for MJPEG. It do not have anything common with AVCHD encoder.
And in reality it is not a bug, but specific code that works perfectly fine with default bitrates.

cbrandin

@Lpowell

The CPB value, however, is lower and it would overflow at a higher bitrate. Maybe that's the one causing the problem.

Who knows? All I know is that when an issue like this is discovered fixing it often results in unexpected things getting better as well. Unintended consequences in a positive way...

Chris

mpgxsvcd

@Vitaliy

Do you think this encoder bug is something that can be fixed? Is this what is causing the low bit rate frames at the beginning? It would be great to eliminate that problem. Then bit rates above 32 mb/sec wouldn't have any adverse affects.

cbrandin

Yeah, I guess i shouldn't have called it a bug. It is sloppy coding, however. It happens when you use INT instead of UINT when casting an integer that you know will never be validly negative. I've spent many an hour hunting down this issue in software. Now I always cast integers as unsigned when they will always be non-negative numbers, and I've regained the time I've lost tracking this sort of thing down in the past.

Chris

cbrandin

@mpgxsvcd

I'm pretty sure Vitaliy is working on it. Unfortunately, although the problem is simple, fixing it is rather painful and involved.

Chris

kae

@JDN
"what range would be considered a medium speed pan"

This is kind of off topic but i would consider a slow pan to be one where the audience can actually read something off a sign, etc. A high speed pan would be one with heavy motion/blur or even a whip to another character cu to cu like they do in "24". You usually won't see a strobing with those. So a medium to me is something in between and you should see the strobing in the EVF, I say 'should' because it's complicated on the GH2 by the fact that the EVF is showing interlaced video while shooting 24p. Often times when I'm shooting I'm seeing aliasing that looks like strobing but on playback it won't be there because it was caused by the interlacing in the EVF. I think it really shows up on these vimeo videos as a lot of guys are doing these 'beauty' pans without a subject to follow that aren't really done much in features because you're trying to be economical with screen time and it's much simpler to cut rather than endure a long tedious pan without a subject. If you do a medium speed pan that would normally strobe but you follow something or someone, the background will still strobe/judder whatever you want to call it, but you won't notice. Next time you're in a theater watch any shot like that and focus on the background not the subject and you'll see the strobing.

cbrandin

@kae

Generally, pans that follow a subject can be much quicker than ones that don't, especially if the background isn't in sharp focus. If you look up recommended pan speeds in the ACM they seem very slow, because they are intended for non-moving subjects. Pan speeds following moving subjects follow different rules that consider more factors: sharpness of background, the effect of composition and its ability to keep the viewers eye on the subject - things like that...

But you already know this...

Chris

LPowell

@Vitaliy "As for MJPEG. It do not have anything common with AVCHD encoder.
And in reality it is not a bug, but specific code that works perfectly fine with default bitrates."

Of course, my mistake, MJPEG has a different file structure. However, I'd definitely call it a bug when an unintended overflow result is written as erroneous data to the video file. If the encoder specs called for a cap on reported bitrate at 32k, the code should have contained a check to enforce this limit, rather than assume it would never be reached. In this case, I agree with @mpgxsvcd that fixing it to work properly up to 64k max bitrate would be very desirable for high-bitrate patches.

bdegazio

@cbrandin

Here's the original of that shot with the grass waving at the top of the frame and water stuttering in the lower part of frame:

JDN

@Kae Thanks! Sorry to go a bit off topic all.

stoney

We need a panning pull. Chinese. Make one.

driftwood

There is probably a rate control problem which maybe causing stutter/ghosting or even cadence. I can't be sure until further tests. But, for example, even the stock 22M settings from Panny show strange anamolities in the cpb_removal_delay_offset from the initial relay declared. But then again elecard buffer analysis could be bugged for mts.

cbrandin

I've been giving some thought to @driftwood's findings on buffer arrival times, etc... (good testing, by the way). These are big issues when it comes to networked video, where packets of data can arrive out of order, or be missing, etc... The GH2 does use the TS stream format - which was originally designed for unreliable connections, not file systems. H.264 defines a number of fallback strategies when data is unreliable, like skipping decoding parts of frames - which looks like stuttering (at least in parts of frames) if it occurs during P or B frames, and macroblocking if it occurs during I frames. Some decoders may be assuming that data can be missing simply because they see a TS stream, employing these fallback strategies, even though in the case of GH2 files that wouldn't happen.

Theoretically, this should not be a problem when you are dealing with video files - where all data is available for relatively instantaneous access. Drop these files into an editor, and it's unlikely to be a problem. However, I wonder if some players' codecs, especially those designed to accommodate networked based video as well, don't handle this well; or treat it like networked video oblivious to the fact that because the file is local there aren't really any timing issues.

I tested actual cadence - that is, the interval between frames - and I'm pretty sure that's OK. I've also looked at some files that stuttered, etc... with players but were perfectly fine when dropped into an editor. The high bitrates are actually illegal according to the H.264 standard subset the GH2 uses. It doesn't surprise me that some decoders can't handle them.

One test I would suggest would be to take offending files, drop them into an editor, re-render them, and then see if the resulting files play OK. Editors treat streams differently - they are timing agnostic and instead rely strictly on frame sequence. Players, on the other hand, are real-time decoders.

We may be being unrealistic expecting players to be able to handle video streams that are so far outside the AVCHD specification. Besides, if you are interested in playing files straight out of the GH2 without running them through some sort of processing, you probably aren't particularly interested in extreme bitrates and such.

Maybe we don't really have such a big problem here. As long as video files aren't actually missing data, not being able to play them raw with some players isn't so bad. Even the camera can't always play files it produces. I have yet to encounter a video file that Vegas, for example, didn't happily consume without problems.

Chris

driftwood

@cbrandin Brilliantly summarised. I think youve nailed it on the head with Panny using Transport Stream. And youve somewhat reassured me that elecard buffer analysis probably isn't bugged at all. The amazing thing is I'm getting hardly any video buffer overruns / underruns being reported at these high bitrate settings (only highly extreme setttings) - which leads me to suggest that when the decoder is spiking at considerably lower rates (with tuned settings) it may be in other areas - certainly, not enough bitrate to handle constant static high detail in the i frames or maybe write-out speed over the data bus, or something else - of which I'm investigating.

cbrandin

@driftwood

I think Elecard's programs are probably completely correct in their analysis of Transport Streams, which by definition are unreliable data sources. It just isn't particularly applicable in the case of GH2 files. It it is appropriate for Elecard to interpret TS streams as unreliable because much of the time people will be analyzing files that are dumps from network sources. Or, put another way, they way they handle this issue is the most correct and useful way to do it.

Chris

cosimo_bullo

@cbrandin - "Maybe we don't really have such a big problem here. As long as video files aren't actually missing data, not being able to play them raw with some players isn't so bad. Even the camera can't always play files it produces. I have yet to encounter a video file that Vegas, for example, didn't happily consume without problems."

That's exactly correct. For us, playback in camera or out is not a huge deal as long as the files can be transcoded properly to a professional editing codec.

cbrandin

It would be useful for a few people to actually look at some files that don't play well - just to confirm this assumption and be sure nothing else is going on. I've done a little testing - more might be good.

stoney

The Art of shooting progressive. Good article for those 24p shooters.

http://www.dvuser.co.uk/content.php?CID=208

Psyco

@bdegazio

Your video is still the best source of that particular problem, but if you can do that shot again...

...just make a second shot and turn the camera upside-down! That will show if the codec has a problem with the lower part of a highly detailed scene or with the darker less contrasty water.

cbrandin

@bdegazio @Psycho

I would be curious about that too. In my tests I found that this happens mostly in the lower parts of frames, and it happens mostly with low contrast portions of the scene. To what degree the two are traded off, I don't know.

Chris

Howdy, Stranger!

Categories

Tags in Topic

Top Posters