I have been doing some testing with footage from a Canon 7D and libavcodec. For those who are unaware, the 7D captures to H.264 format wrapped in a QuickTime container. I have successfully converted footage with my own app using functions from the various FFmpeg libraries, but have noticed in doing so that the decompression result from libavcodec is of lesser quality than the result from QuickTime enabled applications.
For example, if I open and convert 7D clips with any QuickTime-based application (that is, one that employs the QuickTime API for decompression), the pictures from these apps are all basically the same. I verified this by exporting uncompressed pictures from the following applications: MPEG Streamclip Final Cut Pro Adobe After Effects QuickTime Player (using the Pro "Export" function) In all cases, the compression artifacts are all, for the most part, identical -- that means that QuickTime's decompression lib is feeding more-or-less the same pixel values to all of the aforementioned apps. There are slight variations in gamma, but this is to be expected as QuickTime is notorious for arbitrarily "fixing" gamma throughout the post process. I say "arbitrarily," because although this correction is ostensibly to promote gamma consistency between RGB and YUV sources, in reality it's all over the place as the apps themselves will attempt gamma or other types of adjustment as well. Regardless of the gamma meddling, the pixel values are the same, which is reflected in the H.264 compression artifacts. I confirmed this by layering each uncompressed image I exported on top of one another in After Effects (usually TIFF or BMP), and turning on or off layers to immediately see the one underneath. In the case of the 4 QuickTime apps mentioned, the artifacts were exactly the same. Now, to the point of all this: When my application, compiled with libavcodec, etc. exports an image, the compression artifacts look much different -- and lower quality. There is much less detail in the image, visible by zooming in 800 percent or so and examining the image. I performed the same procedure as before in After Effects (layering the pictures on top of each other), and when viewing the output from my libavcodec-enabled app, less detail is apparent. Much of the camera's CMOS "noise" is gone, perhaps averaged out during decompression. QuickTime decompression retains much more of this noise, which is truer to the original data coming off the CMOS. I have tried several variations of conversion from 4:2:0 format (which is the 7D's native color space). I have tried converting to RGB24 (actually BGR24, but you get the point). I have tried converting to 4:2:2, which gives the same results as to RGB. Now I say "same" because I applied my own chroma averaging code to the 4:2:2 source to convert it to RGB, bypassing libavcodec's. In either case, the result is the same. Much less detail in the H.264 output. I tried with and without calling sws_setColorspaceDetails(). The former case is what I stuck with, since my output was getting clamped (to SMPTE levels?). By setting the fullrange flags to 1 within sws_setColorspaceDetails(), I was getting the full 0-255 8 bit range, which is what I want. Invariably, less detail was apparent when compared to the QuickTime apps. My hypothesis is that the H.264 decompression result from libavcodec is a speed compromise. Somebody decided that those results are "good enough" considering it will play back in real time on modest CPUs. However, this is inappropriate for post production use, since the quality of the result is paramount and not decompression speed. Unfortunately, I don't know much about the mathematics involved in video compression. If someone could help me identify some values that could be tweaked in the H.264 decompression code to produce a higher-quality result, that would be great. In fact, this should be done anyway as CPUs are getting faster, and more emphasis can be placed on quality than speedy playback. Any ideas would be greatly appreciated! Thomas _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
