BobbyMurcerFan

The smartphone industry had about $420 billion in sales late year. If Red captures 1/1000th of that, it means $420,000,000 in sales. Jim is no idiot. With Samsung and Apple duking it out in the mid to high end of the market, there is still space at the very top for Red.

This could make Jim quite a bit richer.

I like Resolve, but I have to say that anyone who is going to use it for editing on any type of a complicated project with a lot of footage is out of their mind.

As an NLE, it is so buggy, slow and sorely lacking some of the most basic of features, that it is a total non-starter.

And these feature limitations still exist in the 14 betas. I have high hopes for Resolve becoming a magic box, but it's certainly not there yet.

I don't see any way that Sony introduces RAW in their consumer cameras. One of the ways they protect their high end cameras is by limiting recording formats. That's why they won't put XAVC into their a/A lines of cameras. They will only put XAVC-S in them because they consider that their consumer format. And they refuse to write an XAVC-S plugin for professional NLE's, so each NLE has to develop their own. They simply aren't going to jump from 8bit 4:2:0 XAVC-S to RAW.

But it's "FULL THROTTLE." Gotta love marketing, LOL!

Sam,

The original 1024 box will have more colors. Combining four boxes of 256 colors isn't going to give you any new or in between colors, it's just going to give you four times as many of the same 256 colors.

I have to believe that David is talking about "in practice," b/c the math is not perfect.

Here's a simple example that illustrates what I'm saying:

Have an image with a perfectly uniform shade of grey that falls between two 8-bit values but closer to the higher value. Lets say between 100 and 101 but closer to 101. Well it's going to be encoded as 101.

But let's say you take the same perfectly uniform shade of grey and sample it with 10-bit precision. So it falls between 400 and 404, but lines up perfectly with 403.

There is no way that four 8-bit values of 101 are going to mathematically sum to 403. They are going to sum to 404. And 404 <> 403.

While I'm sure the downrezing helps the bit depth considerably, the math is not perfectly reversible.

You're not really talking about image quality, you've mentioned one thing - low light. Yes the 5D Mark III's rather lacklustre video mode (pre-raw revolution) and the 12 month old D5200 were pretty close in that respect.

 

The D5300's improvement in low light is mostly in the fixed pattern noise, cleaner sensor readout, rather than any big noise reduction at high ISOs.

 

It's not a big deal to me.

Andrew,

With all due respect, it's a huge deal for the low budget filmmaker. The FPN in the 5200 is a major PITA. I've had to use a combination of a luma key, asymmetrical blur (vertical only, not horizontal) and NeatVideo just to get it kind of acceptable. Also, FPN eats into codec efficiency.

If the 5300 actually removes FPN, it is a total winner and definitely worth the hassle and dealing with stupid UI elements like Baby Mode.

Honestly, I really suggest that you update your review of this camera if FPN is indeed gone.

Keep in mind that Sony and Toshiba have joint developed chips and have sold fab plants to each other, so it's entirely possible that only the name has changed.

http://www.theregister.co.uk/2011/02/28/sony_toshiba_ps3_chip_plant_sale/

Andrew,

I appreciate your reviews very much.  But I do feel that your (understandable) frustration with Nikon was the tail wagging the dog a bit in this one.

There are two main issues with the D5200's video image quality. First is fixed pattern noise that accentuates itself when shooting low light and bringing up the shadows in post and/or using a FLAAT profile. The other is greenish color bias that Canon doesn't seem to exhibit, esp. in portraits.

I've read from 5300 owners that these two issues become non-issues in the 5300. If that is the case, then the video of this camera is not essentially the same as that of the 5200; it would be significantly better.

I own a 5200 and I have to say that the banding issue can be a real pain the ass. And many times there is no good fix in post, even when applying tools like NeatVideo.

I don't know if you still have access to a 5300, but if you can do a fixed pattern noise test, that would be much appreciated. If I can help in any way with my 5200, I'm of course willing to shoot some test video for you, etc. (I'm in the States.)

Thanks much for all your work!

P.S. BTW, you can use non-AI lenses on the 5300's body style, but you won't get metering. However, this is NOT the case with all Nikon bodies. http://www.aiconversions.com/compatibilitytable.htm

LOL! That's awesome!

I will do some more testing, but a movie is being shot where my editing machine is, LOL, so I'll have to wait a day or two.

So, IIUC, H.264 does explicitly state under what conditions the video_full_range_flag should be equal to 1.

But H.264 does *not* explicitly state what the decoder should do when it encounters the flag set to 1. General wisdom is to remap, but that's really more of a "common practice." (Would you say that's the correct way to look at it?)

And like you alluded to, in reality, someone is going to be disappointed. Those who want to keep everything video levels are going to be happy. :) But those who feel that a camera that shoots full range should have its images be full range are going to be upset. And I can understand both perspectives.

See this is exactly the crux of the matter that I'm trying to get perspective on. I primarily use Avid Media Composer. And unlike many other NLE's, MC doesn't use any under the hood trickery to make the image look correct on the computer screen. When editing in MC, 0 appears as true black, 16 as a very dark grey, 235 as almost pure white, and 255 as pure white.

Now people may think this crazy for an application designed with broadcast in mind. But it actually is wonderful, b/c there are no surprises from remappings going on behind the scenes. And if you want to see how your footage will look with 16 being black and 235 being white, you can use an external broadcast monitor or the Full Screen Playback feature w/ the remap luminance for computer screens selected.

But here's where it gets messy in Avid land. When using Avid's file linking feature called AMA to link to a full range flagged H.264 file, Media Composer remaps 0 - 255 to 16 - 235. Now maybe that's what should be done. But Avid's AMA has a setting called "Do not modify levels." At first glance, you would think that with that selected, a full range file would display inside Media Composer as a full range. But it doesn't; it's remapped to broadcast legal.

So if the "accepted" way to handle the video_full_range_flag is to remap, then Avid's probably doing what it should. But After Effects and Premiere, for example, do not seem to remap when the full range flag is on and the source file's color management profile is used. So I'm trying to figure out which behavior is right.

So with your help, I think I understand what MC is doing. What I still don't understand is if it should be considered "correct."

Thanks again!!

I am not at my editing machine right now, but I will certainly check out the files. Thanks so much. ;)

I think there is a larger issue that I'm not sure I've grasped completely. So does the H.264 specification look at the decoding from the perspective that correctly decoded video should be 16 to 235? If so, then it would make sense that full range video should be scaled 16 to 235 when decoded.

Thanks again!

Hi yellow,

Thanks very much for the description. After looking at Annex E of the H.264 specification, it looks like we may have the handling of the video_full_range_flag in reverse, LOL! It seems that if the flag is set to 0, the output is scaled to the video legal range. And if the flag is set to 1, then the output is not scaled. Here's a quote from that section:

video_full_range_flag

indicates the black level and range of the luma and chroma signals as derived from E’Y, E’PB, and E’ PR analogue component signals, as follows.

- If video_full_range_flag is equal to 0,

Y = Round( 219 * E’Y + 16 )

Cb = Round( 224 * E’PB + 128 )

Cr = Round( 224 * E’PR + 128 )

- Otherwise (video_full_range_flag is equal to 1),

Y = Round( 255 * E’Y )

Cb = Round( 255 * E’PB + 128 )

Cr = Round( 255 * E’PR + 128 )

When the video_full_range_flag syntax element is not present, video_full_range_flag value shall be inferred to be equal to 0.

What do you make of this? Thanks so much again! 

I have one more ? about the VUI video_full_range_flag.

This flag is just used for viewing, right, it has no relationship to how the camera records?

I ask this because sometimes I hear it mentioned that a particular camera records H.264 full range, as if recording "full range" is an advantage. But isn't H.264 always going to map the luma between 0 and 1, and the chroma between -.5 and +.5?

FWICT, all the video_full_range_flag does is tell the decoder whether or not to map YCbCr to video levels or 0 to 255. It doesn't actually add any more dynamic range to the camera. Correct?

And cameras that record H.264 "full range" don't have more dynamic range because of it, right?

Thank you so much!

I am wondering if I should be concerned by the Quicktime's color atom flags specified by the D5200.

One value is Rec 709, one value is blank, and another is 601. This makes no sense to me?

The attached image is I'm seeing:

Via a custom build of MP4Box from here: http://komisar.gin.by/tools/  (MS Windows binary)

 

Then use it on the command line like this: ./MP4Box.exe -add my.MOV:fullrange=off -new my.mp4

 

Only takes a few seconds to remux into mp4 container.

Thanks so much. :)

I tried it and it worked. ;)

...

 

It is possible to simply turn off the fullrange flag in the stream, which is something I personally do in order to avoid the scaling of levels into reduced range at import into the NLE, so you have access to super white and black, then work at 32bit float which holds onto RGB values beyond the 0.0 to 1.0 range but this needs care, then scale into strict rec709 for encoding out.

...

May I ask how are stripping/changing the VUI flag? Thank you so much.