i don't see why this is a huge surprise that at the edge of a high contrast object moving across frame at 24p you can see "strobing". if the edge is going from light to dark or vice versa on alternating successive frames, there is a 12hz flashing cycle happening. this is the literal definition of a strobe light, according to wikipedia "Most strobe lights on sale to the public are factory-limited to about 10-12 flashes per second". the clearer and sharper you are capturing and playing back this "strobing" area of the image, the more you are going to notice it.
and even in a cinema with film, the projection is actually double or triple flashed up to 48hz or 72hz to eliminate the flickering effect of the black gap between each frame
Here's my unscientific test. Don't laugh when u see it. Download them and see the difference... if you can find. I think the one with the filter has less motion jitter or motion aliasing or whatever.
Did I kill the interest in this thread? Or are we all in agreement that aliasing was the culprit? As some said, it's nothing new. Images from Panny m43 lenses give more aliasing. Those good old beat up lenses like FD gives good details and less aliasing. The high bitrate patch amplifies the effects. Using diffusion filter mitigates the issue, but this is another reason to get mechanical MF old style lenses. Some people use high shutter speed on fast action like 1/1000. If a subject moves fast enough, there is less motion freeze, and it looks ok. 1/60 or 1/50 shutter speed for 24p for non-fast action. Often I use 1/125 and 1/250. There seems no hard written rules.
Jitterbug love: The conformance of a hypothetical reference decoder (HRD) is addressed for H.264 when there is jitter among the transmission of packets via a channel without packet loss but variation among transmission delay. The sending rate is decoupled from the coding one. Both the jitter and the total size of coded bitstream are taken into consideration such that the values of buffer size and initial buffer delay are minimized, especially when the sending rate is greater than the coding one. Sufficient conditions are derived for the conformance of a coded bitstream to a HRD at the constant delay. These conditions are then used to design iterative algorithms to determine a minimal buffer size and a minimal initial buffer delay for the decoder. A novel interpolation method is also presented such that it is suitable for a wide range of sending rates. [The International Society for Optical Engineering]
This is a different issue. It has to do with buffering frames avoiding overflowing or underflowing them. It should have no bearing on how motion is encoded. In networked systems it can have an effect on how streams are decoded (if packets come in late, out of order, etc...), but that's a non-issue with the GH2.
For what it's worth, if you want to analyze some real world motion footage i shot last weekend, 720p 50fps, 14 - 140kit, shutter 1/100 then after 6:41 the video switches to 1080 1/50.
I don't see anything objectionable other than aliasing on sharp detailed background and some of the high motion stuff has "ant crawling artifacts" around paddles etc. Not something the client or viewers notice.
My opinion is that you can't use 24p mode for professional use (not yet) with camera motion, even if I would like to!! But try the following:
Use cbrandin´s 44m setting (thanks for it) Set Auto Quantize 1080/24p to "All to motion" Play with noise-reduction and sharpening
The most important thing is stabilize your whole system!!! Optical stabilizer and/or SteadyCam or similar!!!
That works for experimental use at least.
The codec seems to become confused if the incomming pictures are not "steady" in 24p And do not forget, there are just 24 pictures for motion resolution not 30 or 50!
I posted this in another thread. I am not sure exactly how to describe this glitch but I get it fairly often no matter which hack I use. I am using a sandisk extreme class 10 30MB/s 8GB card.
My problem is that I don't see the issue during playback but once it is on the computer I see it. That is unacceptable for me because I don't want to go home from a shoot and see that all of my footage has these glitches in it.
■Intel Sandy Bridge 3.4ghz octo core ■16GB RAM ■64Gb Samsung SSD Bootdrive ■4TB Raid 5 ■evga nvidia geforce 570 graphics ■2 x 23″ 1920×1080 LED Displays
@peterosinski, from what you said that looks like a USB transfer glitch to me. Try connecting your card reader directly to a motherboard USB port, not a hub. Failing that try a different USB cable, if it's still no good disconnect any other USB devices. If all else fails look for USB driver or BIOS updates.
@peterosinski, if you transfer the same file several times from the reader, and the glitches are always in the same place, you can rule out a USB issue. Which version of Premiere? If CS5 with GPU acceleration it could also be a graphics driver issue, try updating that. Or it could be overheating if anything is overclocked (GPU, CPU, memory).
Also check if the glitch is always in the same place when you play the source file. And compare with a playback outside Premiere (eg. Windows Media Player).
sd card -> new card reader -> my computer = glitches sd card -> new card reader - > my mothers shitty computer -> usb drive -> my computer = no glitches sd card - > new card reader - > usb drive via my computer = glitches
so how is it I am getting glitches on my computer which is so fast it shits lightning, but my mothers piece of crap HP handles this fine. The only variable appears tp be my computer
card - > card reader ->usb drive via my moms computer -> my computer = no glitches card - > built in card reader on moms computer -> usbdrive -> my computer = 1 glitch
Can you run this MD5 checksum generator against the file on your mums and your PC. http://www.winmd5.com/ If they are the same this will rule out file transfer issues.
I haven't yet been able to think of a cause that covers all your symptoms. The Linux VM will have different codecs to the windows machines obviously. And graphics card issues - I would expect the PPro render mechanism, the VM interface and Windows Media Player to be exercising different code paths/techniques.
However, try disabling CUDA in PPro and see if that makes a difference.
In that case run the MD5 checksum generator on a file on your machine and your moms. It generates a fingerprint of the file. If there are any differences at all in the copying process the two files will have different checksums/fingerprints.
i did the checksums. the files that dont match are the ones that are glitch free, while the files with glitches are the ones that match the checksum on the SD card
Can you explain that again in more detail, including which machine you ran the checksum on and where the file was at the time. If I'm understanding you correctly that's the opposite of what I'd expect!