Nikon 1 1080i: PSF or true interlaced? Double Deinterlacing?

[Overcrancky]

Hi,

I've recently started shooting 1080i with a Nikon V1 to take advantage of simultaneous full res stills capture. Can anyone confirm if N1 actually captures true 60 fields (as specifications and visual inspection of footage seem to imply) or if this is progressive segmented? Assuming it's true interlaced, can someone suggest a good way to double deinterlace it to 60p (i.e. interpolating both fields to 1080p). I'm on a Mac and have had good results with JES Deinterlacer with other cameras, but it doesn't even recognize N1's 1080i as interlaced (MediaInfo also reports it as progressive 59.94). iMovie appears to be confused with it as well (not that I would want to import interlaced into iMovie with its single field processing). Does it mean the camera doesn't flag the stream properly? I'm able to get good results with MPEG Streamclip or Handbreak but these tools only deinterlace to 30p.

Thanks

[poisondeathray]

The only way to confirm is to look at a sample with motion (e.g. a pan) . If you post a small sample, someone will look at it

If it is interlaced, I think the nightly builds of handbrake allow bob deinterlacing now (double rate)

[poisondeathray]

If this sample is representative of a production model, there are serious issues with duplicate fields.

http://www.imaging-resource.com/PRODS/NIKONV1/NIKONV1VIDEO.HTM
http://216.18.212.226/PRODS/NIKONV1/FULLRES/yvid_nikonv1_day_1080_60i_DSC_0425.MOV

The actual content is only 30p , but there are field swaps and duplicates, causing the combing when viewed in a player. Usually the proper thing to do is to realign the fields (as this is progressive content) with something like TFM() in avisynth. Usually deinterlacing is the wrong thing to do, as it will only serve to degrade the image, reducing the effective resolution. But the quality is poor , and it's riddled with aliasing , so deinterlacing (along with decimation) might actually help to fix the aliasing in this case

[jagabo]

I wish marketing droids hadn't started calling 30i video 60i. All they've done is create confusion.

I believe the clip truly delivers 30 interlaced frames per second with 60 separate fields per second. The problem is most decoders don't know how to deal with the PSF source. ffdshow decodes it as interlaced but then calls it 60 fps, not 30 fps. And then it thinks there are twice as many frames as there really are. You can deal with that in AviSynth but many other programs will not know what to do.

DirectshowSource("yvid_nikonv1_day_1080_60i_DSC_0425.MOV") # ffdshow is decoding
AssumeFPS(30000, 1001) # correct the frame rate
AssumeTFF() # field order
QTGMC(preset="fast") # smart bob to 60p
Trim(0,731) # truncate to the correct number of frames.

The result is a 60 fps progressive video with all unique frames and the correct run time:

[poisondeathray]

jagabo you edited your message, but I think you're right, there is a problem with decoding with some decoders and splitters. The tests I did were with quicktimes own decoder, and ffvideosource, they had problems with field repeats . FFdshow seems to be mostly ok, so it is possible to get 60p out of it

Often these review sites do tests on pre production models, so I'm uncertain if this sample is representative of the real thing

[jagabo]

jagabo you edited your message

Yes, I edited it once again once I figured out exactly what was going on.

[Overcrancky]

PDR, thanks for a quick reply. Nikon's marketing states that the sensor is running at 60fps during 1080i capture. If the stream only contains [poorly captured] 30p, I guess the camera throws away alternate frames... or uses them for stills. Which means there's no more temporal resolution at 1080i (which is what I was hoping for as a side benefit to stills capture) compared to 1080p30. I'll try to post a video sample for confrmation.

[poisondeathray]

These MOV files from DSLR's and similar cameras use full range, and many decoders automatically clamp to legal range 16-235

ffdshow and libav based decoders don't clamp the levels like QT, so usually some levels adjustment has to be applied

[poisondeathray]

PDR, thanks for a quick reply. Nikon's marketing states that the sensor is running at 60fps during 1080i capture. If the stream only contains [poorly captured] 30p, I guess the camera throws away alternate frames... or uses them for stills. Which means there's no more temporal resolution at 1080i (which is what I was hoping for as a side benefit to stills capture) compared to 1080p30. I'll try to post a video sample for confrmation.

I was wrong. The analysis was faulty , because some decoders have problems with that sample.

But if you post a video sample from your retail model, that will confirm for sure

[smrpix]

30p, I guess the camera throws away alternate frames... or uses them for stills. Which means there's no more temporal resolution at 1080i

It is shooting 30i which gives you twice the temporal resolution of 30p. It is not being discarded by the camera.

[jagabo]

These MOV files from DSLR's and similar cameras use full range, and many decoders automatically clamp to legal range 16-235

Yes, I didn't adjust for that. I was just checking the frame/field rate.

[jagabo]

30p, I guess the camera throws away alternate frames... or uses them for stills. Which means there's no more temporal resolution at 1080i

It is shooting 30i which gives you twice the temporal resolution of 30p. It is not being discarded by the camera.

Yes, it's throwing away half the spacial resolution, not half the temporal resolution.

[Stears555]

jagabo you edited your message, but I think you're right, there is a problem with decoding with some decoders and splitters. The tests I did were with quicktimes own decoder, and ffvideosource, they had problems with field repeats . FFdshow seems to be mostly ok, so it is possible to get 60p out of it

Often these review sites do tests on pre production models, so I'm uncertain if this sample is representative of the real thing

In the case of PSF the combo of MPCHC player with Lav filters or Coreavc can help.
I dowloaded your video, but it seems simple interlaced video for me.

[smrpix]

Assuming it's true interlaced, can someone suggest a good way to double deinterlace it to 60p (i.e. interpolating both fields to 1080p). I'm on a Mac

One opinion:

Parallels and Avisynth are your best bets. jagabo's script is great. You can probably get away with a faster bobber and assumefps isn't strictly necessary but assumeTFF absolutely is.

[Overcrancky]

Thanks everyone for your help. I'm attaching a sample video. I guess I will try Avisynth given there don't appear to be any Mac tools that can bob deinterlace this. Thanks again.

[poisondeathray]

mac tools - no, there are problems on the mac same as pc with decoding. Only some specific decoders and splitters get the fields correct

Although this linked post below is about the Nikon D7100, post #4 basically has the same observations about messed up fields in FCP, Quicktime (and that was the mac version of QT, I tested on the PC version of QT). It doesn't bode well for any mac tools

http://www.dvinfo.net/forum/nikon-photo-hd-video/514473-guys-i-have-tell-you-d7100-com...ml#post1785363

I don't have a mac at home , but I can play with it and see if there are any other mac tools that will decode it correctly tomorrow

[Overcrancky]

Although this linked post below is about the Nikon D7100, post #4 basically has the same observations about messed up fields in FCP, Quicktime (and that was the mac version of QT, I tested on the PC version of QT). It doesn't bode well for any mac tools

http://www.dvinfo.net/forum/nikon-photo-hd-video/514473-guys-i-have-tell-you-d7100-com...ml#post1785363


It's quite likely Nikon is doing the same thing on V1 as on D7100. What kills me most is that the sensor/CPU/buffer on V1 appear to be perfectly capable of writing 1080p60. Why interlace then, especially so ass backwards? Knowing Nikon, there also no chance this will ever get fixed in firmware.

[poisondeathray]

Did you read the other replies in that thread ? Doesn't look like nikon is too enthusiastic about "fixing" anything

If it's not compatible with FCP , kind of makes you wonder what software you're supposed to use on a mac .... Didn't know Nikon made any editors LOL

As for the reason for not offering 1080p60 - it's more likely a licensing issue. The recording module can't do it . 1080p60 requires a lot more bitrate and more CPU power to encode and decode . Small format cameras tend to overheat

[Overcrancky]

As for the reason for not offering 1080p60 - it's more likely a licensing issue. The recording module can't do it . 1080p60 requires a lot more bitrate and more CPU power to encode and decode . 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). Also, my Sony HX9V happily shoots very nice 1080p60 w/o any heat issues. With Nikon it appears to be more of a firmware/software issue (or rather incompetence). What a shame with such a powerful hardware.

[aedipuss]

i can see advertising grunts calling 30p 60p. why not if 30i is now 60i. point and shoot crud is always going to be crap whether it's sony, nikon, samsung or any other. they just need to make it sound new and better. and 60 has to be better than 30 right???

[poisondeathray]

As for the reason for not offering 1080p60 - it's more likely a licensing issue. The recording module can't do it . 1080p60 requires a lot more bitrate and more CPU power to encode and decode . 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). Also, my Sony HX9V happily shoots very nice 1080p60 w/o any heat issues. With Nikon it appears to be more of a firmware/software issue (or rather incompetence). What a shame with such a powerful hardware.

Raw actually takes a lot less CPU, but more I/O (need faster media to record to) . It's the temporal compression algorithms used in video that require more calculations, thus more CPU . (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. 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 . The hardware isn't fast enough to do both a proper scaling to 1920x1080 and recording compressed video at 60p . 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

It's the recording module - the hardware - that is limited. Basically all CMOS sensors are progressive 60Hz and output 60p, even ones from 4-5 years ago (50Hz in PAL regions). The limiting factor is the recording module - they licensed it from quicktime - basically the same one used for many years. 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. Now the HX9V shoots AVCHD2.0 - so it includes 1080p60 . It doesn't use the same quicktime module or recording hardware, it's much newer

[jagabo]

Thanks everyone for your help. I'm attaching a sample video.

Your sample is the same as the earlier sample from imaging-resource.com

[poisondeathray]

If you know how to use terminal (command line) on the mac, ffmbc should work .
http://code.google.com/p/ffmbc/

ffmpeg doesn't work (same misordered field/frame issues as many other decoders), so ffmpegx , iffmpeg or related OSX ffmpeg GUIs probably won't work.

You still might choose to use avisynth, because the deinerlacing quality is much better with QTGMC (much better than jes, or anything available on a mac), and ffmbc only has yadif and w3fdif available . (Deinterlacing is an entirely other huge topic...)

There is a precompiled ffmbc mac binary in this thread , see the dropbox link
https://groups.google.com/forum/?fromgroups=#!topic/ffmbc-discuss/cZw4vXw640A



I scaled the examples below down to SD, just for demonstration purposes that yadif bob deinterlacing works in ffmbc with this camera and that there are no field misordering or decoding problems.

An example of the basic syntax using yadif, scaling to sd, re-encoding to AVC, copying the audio:

ffmbc -i input.mov -vcodec libx264 -crf 20 -preset faster -vf yadif=1,scale=848:480 -acodec copy output.mp4

If you didn't want to scale it, eliminate the scale line, if you want to tweak better quality etc.. just adjust those settings (maybe a slower preset, lower crf). If you wanted to encode these to something else like prores (e.g. for input into your editor), you could do that as well .

I have to re-iterate that levels are passed through as full range with ffmbc/ffmpeg tools, so it will look more contrasty compared to a preview in say, quicktime. The superbrights/darks will also be clipped in any preview, and any standard range conversion to RGB unless you correct for them. AFAIK ffmbc doesn't have any levels filters

[Overcrancky]

PDR, thanks for a great tip - I have compiled fmbc and it works well enough for me. One small issue though is that iMovie forces optimization (i.e. AIC transcoding) when I try to import resulting files. I'd rather not transcode. 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: http://www.divergentmedia.com/blog/fullpost/clipwrap_248_imovie_secrets
Is there something similar that I can do with ffmbc?

Thanks again!

[poisondeathray]

PDR, thanks for a great tip - I have compiled fmbc and it works well enough for me. One small issue though is that iMovie forces optimization (i.e. AIC transcoding) when I try to import resulting files. I'd rather not transcode. 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: http://www.divergentmedia.com/blog/fullpost/clipwrap_248_imovie_secrets
Is there something similar that I can do with ffmbc?

Thanks again!

I don't really use imovie, but I would imagine Prores would pass through . I know quicktime animation codec does for sure, but it's RGB(A) . You don't want to do that before correcting for levels

I think imovie might have problems with 1080p59.94 , not sure

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 ?

Either 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

[Overcrancky]

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. No intention to re-encode back to interlaced.

But if I can't edit directly in h.264 I might as well encode directly to ProRes via ffmbc... which I tried and it seem to be working OK (iMovie imports without transcoding). However, I'm getting the following warning from ffmbc: Incompatible pixel format 'yuvj420p' for codec 'prores', auto-selecting format 'yuv422p10le'
Is this anything I need to do something about? Here's my command line:
ffmbc -i IN.MOV -vcodec prores -profile lt -vf yadif=1 -acodec copy OUT.MOV

[poisondeathray]

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. No intention to re-encode back to interlaced.

But if I can't edit directly in h.264 I might as well encode directly to ProRes via ffmbc... which I tried and it seem to be working OK (iMovie imports without transcoding). However, I'm getting the following warning from ffmbc: Incompatible pixel format 'yuvj420p' for codec 'prores', auto-selecting format 'yuv422p10le'
Is this anything I need to do something about? Here's my command line:
ffmbc -i IN.MOV -vcodec prores -profile lt -vf yadif=1 -acodec copy OUT.MOV

Nothing to worry about because prores is 10bit 422 (there are 4444 variants, but LT, HQ, and "regular" are 10bit 422) . All it's doing is upsampling to 10bit 422



But if you were able to clip wrap the source files from this camera (without the field errors) that would be ideal . Even prores HQ at qscale 1 will yield very slight (pixel peeking) quality loss (and filesize will be several times larger) . The clipwrap guys issue fairly frequent updates, so something might be available for the Nikons in the future

[Stears555]

http://www.camcorderinfo.com/content/nikon-v1-camera-review-with-sample-video.htm


As all still cameras on the market, it has low video sharpness.


The Nikon V1 was able to produce acceptable sharpness in our video test, on par with the Nikon J1. We saw up to 750 LPPH of horizontal sharpness in bright light, with that dropping to right around 600 LPPH in our vertical sharpness test. These are good numbers and are a substantial jump over the low light sharpness results. We found better sharpness results in the 1080/60i mode; both that and the 1080/30p mode were sharp, but the 60i had the added benefit of reducing moire. The interpolation in the 60i mode seemed to function as an extra anti-alias filter, as most of the finer lines on our chart were rendered as flat gray. More on how CamcorderInfo tests video sharpness.
In low light we saw sharpness dip somewhat, with our test coming up with 600 LPPH horizontal sharpness and just 500 LPPH vertical. The moire effect (the ugly discoloration you get along with wavy lines when a camera tries to reproduce a pattern that's slightly too fine) was much worse in low light than in bright light, as well. We found low light sharpness was better in the 1080/60i mode than in 1080/30p. In 1080/30p sharpness dipped to just 500 LPPH horizontal and 450 LPPH vertical.

[smrpix]

A few thoughts and data points to throw into the mix, take them for what they're worth.

One problem may simply be trying to convert the clips for imove. The clips played perfectly in Premiere Pro CS6 and in Avid MC6 (though that's probably overkill.) If FCP X can handle them natively it might be worth the investment. There's a 30 day free trial.

I tried the clips in avisynth and saw the same artifacts PDR described though jagabo's AssumeTFF line straightened it out.

Also, clipwrap basically finds a way to repackage everything into a mov container -- since the Nikon files are mov natively I'm not sure there will be any great rush on that front, but that's speculation. (I'd kill for a windows version of clipwrap, but I don't see that happening soon either.)

It seems some apps interpret the nikon files correctly, many don't. How to deal with it I guess depends on where you want to end up.


As I said, just some thoughts.

[poisondeathray]

A

Also, clipwrap basically finds a way to repackage everything into a mov container -- since the Nikon files are mov natively I'm not sure there will be any great rush on that front, but that's speculation. (I'd kill for a windows version of clipwrap, but I don't see that happening soon either.)

Very true, it won't help since it's already MOV! Sorry I had a brain fart

But I'm curious as to why would you want windows version of clip wrap? Most people try everything to avoid MOV container on PC