Official: HDMI 1080 IS INTERLACED ONLY

Pyriphlegethon said:
Problem is, I can't get it to add a normal pulldown in 1080i mode. This is an issue if your recording device doesn't support 24p input via HDMI (like AJA's IOHD) and you want to reverse pulldown later. (Tried with cards in and out of camera--no difference).
Click to expand...

The frame sequence you describe: "weird 4 interlaced 1 progressive field cadence" is totally wacked (i.e. bad, or not good). I cannot see how any device might tolerate such a video signal. Alternating between interlaced and progressive on a frame-by-frame basis?

If this can be demonstrated to Nikon, this sounds like a firmware update or erratum (or both) should be expected.

What were your results using 30p and 25p movie modes?
Would you try "uncompressed HDMI" to an LCD display, to see if it can understand the 1080p or 1080i output from the D800?

-- Bob Elkind
 
Haven't tested 30p and 25p modes as they haven't interested me as much, but will test if get time. Tried uncompressed to a display and yes it recognized both 1080p 24 and 1080i output from the camera. This weird cadence is strange. Could be user error for all I know as it's so unorthodox. Anybody else seeing this?
 
Pyriphlegethon said:
Haven't tested 30p and 25p modes as they haven't interested me as much, but will test if get time. Tried uncompressed to a display and yes it recognized both 1080p 24 and 1080i output from the camera. This weird cadence is strange.
Click to expand...

Well, there is but one course of action left open to us (actually, you). You must record this wack 1080i video, and inspect a short sequence of frames manually for evidence of either

  • mongrel frames (a single interlaced frame constructed from two different frames)
  • repeated frames

Do not sleep until you can verify the possiblity of

4-frame input ___ 5-frame output
sequence _________sequence___________
frame1 ___________frame1 (interlaced)
frame2 ___________frame2 (interlaced)
frame3 __________ frame3 (interlaced)
frame4 __________ frame4 (interlaced)
__________________frame4 (repeated, progressive)

This might be a novel alternative to 3:2 pulldown. Far-fetched? yes. Possible? yes.

Possible telltales:
repeated frame___________ => stuttered motion, two consecutive absolutely identical frames
mongrel interlaced frame _=> obvious odd/even line interlace pattern when panning horizontally

Hmmm.... What led you to the conclusion that the HDMI output contained a 4I, 1P frame sequence?

Thank you for volounteering your time and talents to shedding some light on this mystery.

-- Bob Elkind
 
Last edited:
I just scanned through the posts in this thread and much of it delves deeper than I can quickly digest. I have a basic grasp on this issues at hand and thought I would quickly post my findings from my last 2 hours in my studio. I am testing a Nikon D4 with various recording options on a PIX240. The PIX240 tells me what type of signal is coming through HDMI and I am able to choose various recording options. The auto output on the D4 causes the PIX240 to display that the incoming HDMI signal is 1080p/23.976. Until I saw someone post the use of "auto" I was trying to negotiate the 1080i60 signal with the PIX240s automatic pull-down removal (2:2:2:4) for the D4 shooting in 1080p24 over HDMI. This seemed far from ideal and introduced judder into otherwise acceptable footage. Leaving the cards in did not prevent a 1080p output, however once I pressed record on the D4 in liveview, the HDMI output turned into 720p60. Obviously there is much going on between the 2 devices to enable recording. I don't know the technical details of the outputted signals, but I have seemed to successfully record the 1080p/23.98 signal of the D4 over HDMI with my PIX240. From the Nikon information, the 8-bit signal would not benefit from 10 bit codecs that are possible with the PIX240. ProResLT seems like the format I will use. If I get time I will post a clip up on vimeo.

- Rick Smith
 
Last edited:
Pyri: Downloading the file now. Thank you.

Results:
Steady sequence of P, I, I, I, I (1 progressive frame followed by 4 interlaced frames) detected, using basic Quicktime 'single-frame-advance'.
But note that I cannot tell the difference between a progressive frame and an interlaced frame developed from a single progressive frame.

If Quicktime is stepping on half-frame boundaries, then shifting each step by a half-frame might very well result in 5 interlaced frames all built from a single progressive frame, each. This is a much more plausible explanation than mixing both progressive and interlaced frames in a single HDMI output stream.

The motion is too rapid and too brief for me to detect motion stutter with certainty. If anyone else has more sophiticated forensic video tools, don't be shy about giving this a spin.

-- Bob Elkind
 
Last edited:
not to be presumptuous but .MOV = Quicktime so unless there's a version issue in your current copy of quicktime, it should be able to open that file. Photoshop has always used Quicktime for it's preview displays (icons, picons etc) so I heard that PS CS6 beta now processes movies. Y not download PS CS6 and try to open in that. I'd use Apple Compressor as it's a key transcoding tool, but you may now own it.
 
D800--->25P--->Pix240

D800--->25P--->Pix240

Thanx for confirming that the Pix240 works in 24P with the D800. That's actually one of the questions I asked on ths SD fora a couple of days ago. Did you get a chance to confirm it works in 25P also? Thanx.

rfxs said:
I just scanned through the posts in this thread and much of it delves deeper than I can quickly digest. I have a basic grasp on this issues at hand and thought I would quickly post my findings from my last 2 hours in my studio. I am testing a Nikon D4 with various recording options on a PIX240. The PIX240 tells me what type of signal is coming through HDMI and I am able to choose various recording options. The auto output on the D4 causes the PIX240 to display that the incoming HDMI signal is 1080p/23.976. Until I saw someone post the use of "auto" I was trying to negotiate the 1080i60 signal with the PIX240s automatic pull-down removal (2:2:2:4) for the D4 shooting in 1080p24 over HDMI. This seemed far from ideal and introduced judder into otherwise acceptable footage. Leaving the cards in did not prevent a 1080p output, however once I pressed record on the D4 in liveview, the HDMI output turned into 720p60. Obviously there is much going on between the 2 devices to enable recording. I don't know the technical details of the outputted signals, but I have seemed to successfully record the 1080p/23.98 signal of the D4 over HDMI with my PIX240. From the Nikon information, the 8-bit signal would not benefit from 10 bit codecs that are possible with the PIX240. ProResLT seems like the format I will use. If I get time I will post a clip up on vimeo.

- Rick Smith
Click to expand...
 
The video captured by Pyriphlegethon appears to be frames incorrectly merged, possibly by the video recorder he is using.

Here are the steps I followed, please check and verify for me:

  • Open the .MOV file in freeware Quicktime player, NORMAL size view. The file is not 1920x1080, it is 1888x1062 (and this is what Quicktime Movie Inspector reports)
  • Currently stopped at the first frame (frame 1)
  • Snap a screen grab into the clipboard
  • In Photoshop, paste the clipboard into an image - TWICE. The clipboard contents are pasted into a new, separate layer -- TWICE (two new, identical layers per frame)
  • In Quicktime, advance the video a single frame
  • Repeat the last 3 steps 11 times.
  • Crop the entire image to 1888x1062, leaving the entire video frame and nothing more. The image has 24 layers, numbered 1-24
  • Using Photoshop nerding, create a selection pattern which corresponds to every other horizontal line in the image, starting with the top line
  • Using this selection, I cut (delete/remove) lines 0,2,4,6...1060 from layers 2,4,6,8, ... 22,24
  • Inverting the selection mask, I repeat the process, deleting lines 1,3,5...1061 from layers 1,3,5,7 ... 23.

By selectively displaying and hiding each of the image layers, it is readily apparent that the odd lines of Frame 1 (layer 2) mesh smoothly with the even lines of Frame 2 (layer 3).

If anyone cares to inspect the photoshop file, I uploaded a cropped (11MB) section, with all image layers intact. You will need either Photoshop or Photoshop Elements to open this file. File download page is here. This link will expire in a week.

Here is the inferred mapping of fields and frames from D4 (internal) to Quicktime displayed on my PC. I am drawing no conclusions where and how the frames and fields were mangled. This is a warning what can happen when you resort to pulldown.

D4 1080p24 source _____QuickTime player
video frame sequence __video frame_sequence___________
D4Frame1 ______________QTframe01 <= D4Frame1.odd + D4Frame2.even (even lines begin with 0)
D4Frame2 ______________QTframe02 <= D4Frame2.odd + D4Frame3.even
D4Frame3 ______________QTframe03 <= D4Frame3.odd + D4Frame4.even
D4Frame4 ______________QTframe04 <= D4Frame4.odd + D4Frame4.even (repeated D4/24p frame)
_______________________QTframe05 <= D4Frame4.odd + D4Frame5.even
D4Frame5 ______________QTframe06 <= D4Frame5.odd + D4Frame6.even
D4Frame6 ______________QTframe07 <= D4Frame6.odd + D4Frame7.even
D4Frame7 ______________QTframe08 <= D4Frame7.odd + D4Frame8.even
D4Frame8 ______________QTframe09 <= D4Frame8.odd + D4Frame8.even (repeated D4/24p frame)
_______________________QTframe10 <= D4Frame8.odd + D4Frame9.even

So this is 2:2:2:4 pulldown, rather than standard 3:2 pulldown. All is good if it is done correctly and reversed correctly. In this case, either the pulldown was implemented incorrectly or it was distorted, and was not reversed. If not reversed, the temporal artifacts will be twice as bad (and 4 times as noticeable) as 3:2 pulldown. Either pulldown is problematic compared to avoiding pulldown entirely. I would caution anyone inclined to jump to conclusions where the 'blame' lies for the botched pulldown.

To sort out precisely what appears on the D4 HDMI output port will require an HDMI sniffer of some sort. I would not trust a recorder 'report' to be accurate and truthful, especially with the half-frame offset in the output video frames.

-- Bob Elkind
 
Last edited:
eteam said:
The secondary question, which must then be asked, is: Which devices are presently suitable for avoiding P => I conversion (and the dreaded pulldown) in use with the D4/D800 camera(s)?

Note that the questions primarily at hand are made in the pursuit of keeping the 'pristine' HDMI output signal pristine. For the casual weekend videographer, this is not worth a second thought. For the most meticulous and demanding users, I don't think either you or I have exaggerated the potential problems which attend pulldown (especially 3:2 pulldown) and P => I => [???] => P processing. If anything, we have neglected to mention the editing and switching hazards and restrictions whilst in interlaced format.

Grecner, your post started with a declaration that the alarmist warning of 3:2 pulldown artifacts is irrelevant, but you finished with a strong case for ignoring such warnings at your own peril.

-- Bob Elkind
Click to expand...

Yes, you are right, but the question I have asked at the end was purely academic, since the D800, as it seems, outputs 1080p24 video over HDMI.
I believe that any recording device capable of 1080p24 input should be OK and will not introduce any artifacts, unless there is some specific incompatibility between D800 and such recording device which would prevent 1080p24 from being negotiated as supported over HDMI.

Martin
 
Grecner,

"unless there is some specific incompatibility between D800 and such recording device"

That is precisely the problem. I can get the 24p signal out of the D800 with no problem through a Blackmagic card, but devices like AJA's IOHD which do not support 24p input through their HDMI in will leave the user to resort to recording a 29.97 signal (much more common on older hardware) and reversing the pulldown. If the pulldown is irreversible, or even technically demanding for a proper reversal, there may be mayhem among the masses trying to use this method to record at 24 fps. I recorded from the D800 at 1080i to both an AJA IOHD and Blackmagic Decklink internal card with the same pulldown results, so (user error aside) this seems to be the camera's way of spitting out 1080. This is a big deal because I'm assuming that devices like Atomos's 'Connect' will only remove a standard pulldown and not a 2:2:2:4 cadence. Hopefully not an issue if you're already using other Atomos hardware (like Ninja or Samurai which I'd assume are new enough to support 1080p 24 quite nicely with no firmware, EDID updates or anything else--total assumption, haven't tested) but problematic if you need 29.97 for your recording device. Hope that makes sense.

Thanks for your grunt work Bob.
 
Note!

Ninja's 2.1 firmware update includes the following:

Nikon D4/D800 support - added custom handling for Nikon 1080p24 pulldown mode.

NOTE: When connected to a Ninja, the Nikon D4/D800 HDMI output must be set to 1080i when the movie setting is 1080p30, 1080p25 or 1080p24. The Nikon D4/D800 HDMI output must be set to 720p when the movie setting is 720p60 or 720p50 (See page 281 in the Nikon manual: "HDMI Options". Also note on manual page 74: "Movie Settings" – the *actual* frame rates used by the camera, for example, the actual frame rate of the camera when set to 1080p24 is 1080p23.976.)
 
OK, now I understand the point

OK, now I understand the point

I now finally understand what your point is. ;-)

It is not D800 not being able to output 24p, but some recorders not being able to record 24p.
In that case, you are limited to 1080i output from D800, which, however, uses a proprietary frame cadence for pulldown, so the recorders are unable to revert it back.

So that is clear.

But as far as Ninja is concearned, I do not understand why it is unable to record 24p from D800.
In their tech specs the clearly list:

Supported Input Formats HD 1080i60, 1080i59.94, 1080i50, 1080p30*, 1080p25*, 1080p24, 1080p23.98, 720p60, 720p59.94, 720p50, SD 480i, 576i
* from firmware v1.1

So, why must D800 be set to 1080i when connected to Ninja ? This is something I do not understand and that sounds very strange. Some esoteric handshake problems ?

Has anyone explained that yet ?

Thanks a lot
Martin

Pyriphlegethon said:
Note!

Ninja's 2.1 firmware update includes the following:

Nikon D4/D800 support - added custom handling for Nikon 1080p24 pulldown mode.

NOTE: When connected to a Ninja, the Nikon D4/D800 HDMI output must be set to 1080i when the movie setting is 1080p30, 1080p25 or 1080p24. The Nikon D4/D800 HDMI output must be set to 720p when the movie setting is 720p60 or 720p50 (See page 281 in the Nikon manual: "HDMI Options". Also note on manual page 74: "Movie Settings" – the *actual* frame rates used by the camera, for example, the actual frame rate of the camera when set to 1080p24 is 1080p23.976.)
Click to expand...
 
grecner said:
It is not D800 not being able to output 24p, but some recorders not being able to record 24p.
Click to expand...
Not exactly...
But as far as Ninja is concerned, I do not understand why it is unable to record 24p from D800.
In their tech specs the clearly list:

Supported Input Formats HD 1080i60, 1080i59.94, 1080i50, 1080p30*, 1080p25*, 1080p24, 1080p23.98, 720p60, 720p59.94, 720p50, SD 480i, 576i
* from firmware v1.1

So, why must D800 be set to 1080i when connected to Ninja ? This is something I do not understand and that sounds very strange. Some esoteric handshake problems ?

Has anyone explained that yet ?
Click to expand...

I'll give it a try.

Per the HDMI and CEA-861 specifications, 1080p24 means any of the following:

Using 1x pixel clock
  • 1920x1080 4:4:4 RGB 24-bit colour (8-bit per R/G/B)
  • 1920x1080 4:4:4 YCbCr 24-bit colour (8-bit per Y/Cb/Cr)
  • 1920x1080 4:2:2 YCbCr 24-bit colour (12-bit per Y/Cb/Cr) (yes, 12-bits per Y, Cb, Cr is called "24-bit colour" in the HDMI spec)
Using 1.25x pixel clock
  • 1920x1080 4:4:4 RGB 30-bit colour (10-bit per R/G/B)
  • 1920x1080 4:4:4 YCbCr 30-bit colour (10-bit per Y/Cb/Cr)
Using 1.5x pixel clock
  • 1920x1080 4:4:4 RGB 36-bit colour (12-bit per R/G/B)
  • 1920x1080 4:4:4 YCbCr 36-bit colour (12-bit per Y/Cb/Cr)
Using 2x pixel clock
  • 1920x1080 4:4:4 RGB 48-bit colour (16-bit per R/G/B)
  • 1920x1080 4:4:4 YCbCr 48-bit colour (16-bit per Y/Cb/Cr)

The difference between 4:4:4 RGB and 4:4:4 YCbCr is the encoding of the three "channels". Colour-difference (YCbCr) is not the same as RGB (this may not be important for recorders, but it is a critical difference for displays). The receiver must interpret the pixel values differently. But the data words are in the same place and similar order for each of these encodings.

The difference between 4:4:4 RGB (or YCbCr) and 4:2:2 YCbCr is the arrangement and ordering of the channel data. The corresponding bits are in different places, and are organised differently. The receiver logic for RGB vs. 4:2:2 YCbCr is similar, but different.

For the 30/36/48 bit colour encodings, the data bits are arranged differently and the bit clock (not the pixel clock) must be generated differently than for any of the 24-bit colour encodings. As a logic designer specialising in flexible programmable instrument design, the data formatting permutations are quite simple to accommodate, although it's a bit tedious to account for all the permutations (and test them all). The clock differences are more difficult to accommodate, however. The clock multiplier circuits in the logic devices commonly used for such designs are not very flexible. Supporting all the colour modes generally requires adding a dedicated HDMI IC to the board design.

LCD displays, of course, are normally expecting RGB from computers and YCrCb from BluRay players and set-top boxes (although RGB is generally accepted as a common denominator for all these devices).

The D800 and D4, which outputs (at least) 8-bit 4:2:2 YCbCr in Live Video mode, might just as easily output:

  • p24 RGB (isn't the sensor data fundamentally RGB rather than YCbCr?)
  • p24 4:4:4 8-bit YCbCr (repeating Cb,Cr values to fill out the 4:4:4 pixel channel slots from 4:2:2 data)
  • p24 4:2:2 12-bit YCbCr (using only 8 of the available 12 bits per channel)

Per Jon Thorn's posts, I am assuming (it isn't stated explicitly) that the D4/D800 outputs p24 4:2:2 12-bit YCbCr (using only 8 of the 12 bits per channel).

Similar variations and permutations may be realised for 1080i60, p30, and p25 signaling. In the case of a D4/D800 putting 1080i on the HDMI port, there is the additional uncertainty of pulldown being applied in the camera and interpreted differently by the receiving or recording device. It cannot be presumed or taken for granted that 24p will be output as 60i using 3:2 pulldown, as the results described in post #89 make starkly clear.

Does this help explain the possibilities for incompatibility?

-- Bob Elkind
 
Last edited:
Kenny_G said:
So for a normal being:
Click to expand...
Are you sure you aren't lost and ended in this forum by mistake?

The combination Ninja - D800 won't give you the maximum output quality???????
Click to expand...

First off, I refer you to post #92 which describes a new firmware revision for the Ninja.

Without seeing specific details of the Ninja's operation, the Atomos firm should be providing an authoritative answer to this question. With the normal and reasonable disclaimers ( "I did not have sexual... " oops, I mean: these are educated guesses only, and no warranty is expressed or implied...):


  • the Ninja will not support the 'native' D4/D800 operating modes of 1080p24/25/30
  • the Ninja will, with the new firmware, accept and correctly interpret the D4/D800 1080i50/60 output mode, which includes pulldown (by the D4/D800) in the conversion from p24/25/30 to i50/60

Some questions which are too adventurous for even me (or my ego) to answer:

  • Is the 1080i50/60 video from the D4/800 coded as RGB or YCbCr ?
  • If RGB, is the gamut or colour space identical to that of the "native" 1080p24/25/30 YCbCr output from the D4/D800?
  • Does the Ninja transcode D4/D800 input (either RGB to YcbCr or YCbCr to RGB) before applying ProRes compression and recording to "disk"?
  • Are there any artifacts introduced by transcoding, either in the D4/D800 or in the Ninja?
  • Is reverse pulldown performed by Ninja during either recording or retrieval? If yes, which? If not, does Ninja output include pulldown?
  • If Ninja output of recorded D4/D800 source material includes pulldown, how is a downstream device able to correctly -- and with rock-solid certainty -- perform reverse pulldown?
  • Does Ninja distinguish between 1080i input encoded with 3:2 pulldown and input encoded with 2:2:2:4 (e.g. D4/D800) pulldown?

I am sure there are yet more questions which elude me for the moment.

Here's the bottom line: Most -- if not all -- of the questions listed above would be brushed away if the recorder (and we're not just talking about Ninja, agreed?) supported and accepted the 'native' 1080p24/25/30 HDMI output from the D4/D800.

-- Bob Elkind
 
Last edited:
Great explanations, Bob. I'm a semi-retired science teacher, so I'm clearly not "normal," and I think I understood.

I can say that Sound Devices has been reading this thread and is intrigued by the possibility that Nikon has developed a non-standard pulldown cadence. They have not tested a D800 or D4 yet, but I would guess your work has given them some interesting leads.

Given Nikon's history, I would not expect them to share the pulldown formula or the reasons why. I just hope that buried in that data is the possibility of building a Pro-Res or DNX file with more bit depth. In other words - that it would be worth recording in one of the 10-bit Pro-Res formats rather than the 8-bit Pro-ResLT. Combined with a custom flat (s-log) picture profile in camera, that might be a way to maximize grading possibilities.
 
bufo55 said:
so I'm clearly not "normal"
Click to expand...
Yes, you do look familiar...

Given Nikon's history, I would not expect them to share the pulldown formula or the reasons why. I just hope that buried in that data is the possibility of building a Pro-Res or DNX file with more bit depth. In other words - that it would be worth recording in one of the 10-bit Pro-Res formats rather than the 8-bit Pro-ResLT. Combined with a custom flat (s-log) picture profile in camera, that might be a way to maximize grading possibilities.
Click to expand...

All good points.

Nikon made themselves to be the villain a few years back when they refused to disclose white balance attribute tags embedded in the RAW files generated by their dSLRs. The terms they demanded for disclosure were unacceptable to a number of good-sized companies in the raw-conversion business. I hope that, since then, they have relaxed their fierce death-grip on similar details which affect interoperability.

The problem for Sound Devices, AJA, Atomos, and others is not limited to deciphering Nikon's pulldown scheme. There aren't that many variables to decode (e.g. 3:2 vs. 2:2:2:4, begin interlaced frames with ODD or EVEN lines). The critical part is having Nikon make a commitment to never changing their output format or process, once you have shipped products which support the existing and established Nikon output signals. The only thing worse than having a partner who won't disclose needed information is having a partner who switches things around too often, with or without warning. (example victims: any SW application developer using Microsoft Foundation/Frameworks toolsets from XP days to now).

Ask the good folks at Sound Devices if they could use a another clever designer!

I hope this helps...

-- Bob Elkind
 
Last edited:
Yes, that helps ;-)

Yes, that helps ;-)

eteam said:
Does this help explain the possibilities for incompatibility?

-- Bob Elkind
Click to expand...

Yes, you are right.
I did not think of all those color depth and color representation options.
From all the chaotic web information it seems that the D800 output is 4:2:2 8-bit YCbCr,
but it is not 100% clear yet.

In the meantime, I have posted a question to atomos technical support asking why they say it is required to go 1080i for the D800 - Ninja connection when they both support 24p.

We will see if they respond and what they say.

Martin
 
All versions of ProRes except 4444 are 10 bit, even Proxy. Of course if the recorder is being sent only 8-bit from the camera, it's a "fake" 10 bit.
 
You must log in or register to reply here.
Back
Top