![]() Nothing to worry about because prores is 10bit 422 (there are 4444 variants, but LT, HQ, and "regular" are 10bit 422). Is this anything I need to do something about? Here's my command line:įfmbc -i IN.MOV -vcodec prores -profile lt -vf yadif=1 -acodec copy OUT.MOV However, I'm getting the following warning from ffmbc: Incompatible pixel format 'yuvj420p' for codec 'prores', auto-selecting format 'yuv422p10le' ![]() which I tried and it seem to be working OK ( iMovie imports without transcoding). No intention to re-encode back to interlaced.īut if I can't edit directly in h.264 I might as well encode directly to ProRes via ffmbc. I'd rather import and do basic editing directly in h.264 (I do understand the trade offs), just like I'm able to do with my sony 1080p60 footage clipwrapped from MTS to h.264 in Mov container. So what are you planning ? bob deinterlacing to 1080p59.94 then editing that, or trying to re-encoding to 1080i59.94 (also called 1080i29.97, same thing, just different naming conventions), and editing that ?Įither way, I think it's important to decode it correctly, so some stage of re-encoding it through ffmbc is probably required for now, unless someone issues a firmware patch or maybe on the software end something is updated, or maybe some other software I think imovie might have problems with 1080p59.94, not sure You don't want to do that before correcting for levels I know quicktime animation codec does for sure, but it's RGB(A). I don't really use imovie, but I would imagine Prores would pass through. Is there something similar that I can do with ffmbc? Is is there an option in ffmbc that would allow me to avoid AIC transcoding? I'm aware that Clipwrap has an option to produce more Apple friendly (albeit less standard) files: AIC transcoding) when I try to import resulting files. One small issue though is that iMovie forces optimization (i.e. PDR, thanks for a great tip - I have compiled fmbc and it works well enough for me. It doesn't use the same quicktime module or recording hardware, it's much newer Now the HX9V shoots AVCHD2.0 - so it includes 1080p60. 1080p60 wasn't included in any spec until AVCHD2.0 became ratified about 1-2 years ago, so all the older recording modules are limited to 1080i60. The limiting factor is the recording module - they licensed it from quicktime - basically the same one used for many years. Basically all CMOS sensors are progressive 60Hz and output 60p, even ones from 4-5 years ago (50Hz in PAL regions). It's the recording module - the hardware - that is limited. With raw you're usually I/O limited, or memory limited (memory buffer before writing to media), not CPU limited, because there isn't any processing or compression in true raw footage, it's basically a direct sensor feed, nothing else The hardware isn't fast enough to do both a proper scaling to 1920x1080 and recording compressed video at 60p. Also video is subsampled (sensor is too large for 1920x1080, thus every nth pixel is taken) - this causes aliasing (those jaggy edges that Nikon and many large sensor cameras that shoot video are known for), instead of doing a proper downscale. (In video with temporal compression you're looking and referencing differences between multiple frames, not just single frames) JPEG is intra frame compression only, and not as intensive. It's the temporal compression algorithms used in video that require more calculations, thus more CPU. Raw actually takes a lot less CPU, but more I/O (need faster media to record to). What a shame with such a powerful hardware. With Nikon it appears to be more of a firmware/software issue (or rather incompetence). Also, my Sony HX9V happily shoots very nice 1080p60 w/o any heat issues. Small format cameras tend to overheat V1 actually has a very powerful CPU, large buffer and fat pipes: it can do full res (10M) JPG and RAW at 60FPS (for 1/2 sec/30 frames). 1080p60 requires a lot more bitrate and more CPU power to encode and decode. As for the reason for not offering 1080p60 - it's more likely a licensing issue.
0 Comments
Leave a Reply. |