From DV (and its issues) to Film

[Dogway]

I would like to know how to make a film-look out of 29.976. My first idea was to decimate 1 out of 5 frames, although this causes stutter. The other was slowing down up to 24fps, but that's hard in this case because Im talking about a music videoclip.

My friends recorded it with a HDcam, the first thing that annoys me is the codec HDV1, I cant seem to play it normally in MPC, I have to load it in MPC through ffvideosource.

The other thing is something I find in all DV recordings, some kind of pixelation, microblocking, etc. How can I fix this?

I cannot show much (I guess)


http://img707.imageshack.us/img707/15/fird.png

[Mug Funky]

HDV1 = MPEG-2 @ 25mbps CBR + mp2 audio at 384kbps

you should be able to remux this (i presume it's a mov or similar?) using several tools. i tend to use mp4box though i'm sure something more convenient exists (try mpeg streamclip maybe).

as far as film look goes... it depends on the nature of your source.

if it's interlaced, you can get good results by motion-compensation down to 23.976. search should find a good method for that.

if it's progressive, motion compensation will give you artefacts that may or may not be acceptible. there's plenty of threads in many forums where people have shot with the canon 5D mk 2 at 30fps and needed to convert down to 25fps for PAL. there'll no doubt be some good methods out there.

the macroblocking can be addressed with one of the deblocking scripts around here. please not it wont fix the really bad stuff, and will probably reduce some noise (which can improve perceived quality, especially for "film look").

please bear in mind however that unless it's very carefully shot on a decent camera, possibly with adaptors and cine lenses, it'll never look like film.

[Dogway]

Forgot to say, yes, its .mov, audio is pcm. and this video runs at 17.8Mbps. 29.970fps progressive.
I meant microblocking, or FIR, pixelation, I dont know how to call it. Here's a zoom-in to illustrate the artifact from the above image.

Yes Im aware of film-look starts by recording in a real film. But my friends never asked me, so Im just going to tell them Im going to do my best, but next time if they want it nicer, they should record 24fps from start, and be aware of the motion blur (to imitate those from films). I'll do grading in an external program, that step is not very different from real blockbuster films.

http://img651.imageshack.us/img651/4793/fir2.th.png (http://img651.imageshack.us/img651/4793/fir2.png)

[Mug Funky]

grading tip with HDV (and most traditional video cameras):

raise the gamma so it sits about 1.1 - 1.2, then lower the blacks to compensate.

this will take the plastic edge off the flesh-tones, and helps a bit with the film look deal.

also, move the top end slightly toward magenta - for whatever reason, video tends to make flesh tones a bit too green/yellow. adding magenta/blue tends to improve matters, but YMMV depending on the average colour of people in your locality.

then if necessary, de-saturate the highlights (and the lows only if they get a bit out of control) a little if specular spots are looking too "digitally clipped".

k, that's all the grading advice i'm giving.

oh, and Apple Color sucks balls. just sayin'... you can still get it done in it though, but the interface is crap.

[henryho_hk]

DV should be 30i. Perhaps u can use TGMC() to produce a 60p and then use MFlowFps() to make it 24p.

Edit: Oops... ur HDV should be progressive

[Dogway]

I use Nuke's colorcorrect, Im on windows that's why I can't play the HDV1 codec normally. I would like to load it as FFV1 codec (that's what I use for lossless format) but Nuke doesn't read it as it bases its compatibility on ffmpeg.
For FIR Im using mt_convolution(horizontal= " -0.0616 0.2950 0.5829 0.2950 -0.0616 ", vertical= "1", u=3, v=3) which is what I saw on another forum, thinking it might be a standard for DV fir.

Thanks for the grading tips

EDIT: I see that Nuke works with image sequences, well thats better for performance, but a HDD killer, Ill have to deal with that, in the meantime Ill search for saving image sequences through avisynth.

[Dogway]

I just wanted to let you know about the FIR artifact, so Im posting a direct zoom-in showing the problem. The fact is that this is only a reduced version in 720p of the original 1080p, so I guess that whatever FIR filtering working for this wouldnt to the 1080p version(?)

http://img821.imageshack.us/img821/6039/94377359.png

The camera used was the "Canon EOS 5D MarkII". Any insight on this would be appreciated.

[poisondeathray]

^ this looks like it might be a poor decoding job, as if you decoded the 5D h264 footage through quicktime

see this post
http://forum.doom9.org/showthread.php?p=1432085#post1432085


The camera used was the "Canon EOS 5D MarkII".

Also, if this is from a 5D, why are you talking about DV ?

What is this about HDV1 ?


yes, its .mov, audio is pcm. and this video runs at 17.8Mbps. 29.970fps progressive.


5D shoots ~45Mb/s h.264 ; I'm confused if you are talking about 2 different things or the same source ? Please clarify

[NerdWithNoLife]

this video runs at 17.8Mbps. 29.970fps progressive.
So you have 30 progressive frames per second. What's the difference between that and 24 fps? 6 frames a second, which doesn't amount to much. 24p would have slightly jerkier motion, with slightly more compressible frames, while 30p would have slightly smoother motion and be slightly less compressible (since there are slightly more).

My opinion: having progressive vs. interlaced frames is a much bigger distinction than the 6fps difference. And you already have progressive frames almost at 24p, so there's not a good reason to create more problems with motion compensation. (Motion compensation that has less to go on than with interlaced video.) The only big win I see with 24p is if you're planning on releasing this thing in film festivals with the intent to print the thing on film and distribute it. (In which case, you should invest in a camera that shoots 24p in the first place.)

I used to see the appeal of "film-like" 24p, but after learning more I've ruled it out as THE thing that distinguishes it from a cheap video camera. You're welcome to make up your own mind, but there are many people smarter than I who advise against what you are trying to do.

[poisondeathray]

If this is a 5D, you can shoot native 24p with the new firmware

But I'm still confused about what you have; You mention DV and HDV which definitely isn't shot by 5D , unless the 5D footage was converted to HDV for some stupid reason. Or you're talking about 3 different sources ?

[Dogway]

@poisondeathray: I dont own that camera, so I didnt know the native specifications in which it was captured. I assumed it was HDV1, that's why the confussion. But now I have just been a few hours reading about this camera and the thread you gave me, and I can see everything. Anyways as I said in my post this is an edited reduced version of the original 1080p h.264 50mbps as you noted down, which makes everything much more understandable. Now I can know what to request from them (h.264?), or is there any intermediate file standard to work with, not compromising disk storage?

Great news for the new firmware, I was a bit dissapointed a few minutes ago about that. Maybe for the next videoclip.

Related to 30->24 I also wanted to know what is this (http://vimeo.com/4920433) process based on (frame interpolation?). What I did was simply decimation, can't imagine other way without screwing quality or sync with music.

[poisondeathray]

@poisondeathray: I dont own that camera, so I didnt know the native specifications in which it was captured. I assumed it was HDV1, that's why the confussion. But now I have just been a few hours reading about this camera and the thread you gave me, and I can see everything. Anyways as I said in my post this is an edited reduced version of the original 1080p h.264 50mbps as you noted down, which makes everything much more understandable. Now I can know what to request from them (h.264?), or is there any intermediate file standard to work with, not compromising disk storage?



Request the native footage always, especially if you are grading. This allows you to control the YUV=>RGB conversion in full range (and avoid clipping of shadow/highlights) . But if it's edited, you might not have any control or say for choice of format that the editor exports.

Nuke likes image files (png, tiff) , so you're not going to get any hdd space savings . I think you can use huffyuv (the ffmpeg variant) , but I would still use image files

If it's the native foorage, avoid using QT to decode it (as illustrated in the other thread)

Tell them to shoot 24pN if that is their goal for film out



Related to 30->24 I also wanted to know what is this (http://vimeo.com/4920433) process based on (frame interpolation?). What I did was simply decimation, can't imagine other way without screwing quality or sync with music.

Not sure, I don't use mac very often .

You will never get a good 30p=>24p conversion. There is no good way to do it

[Dogway]

The other thread was a bit hard to follow without having the tools, but you mean that QT decode which produces this artifact was produced on the editing stage? (when he imported the file to the project or something?).
Actually this little clip wasn't more than a test video given to me to check "where-to-go" and set the ground, for color correction and artistic decisions. I will request them some float-point image seq. files, or if they just work with 8bit, png files, for the real thing when edition is finished.

[poisondeathray]

The other thread was a bit hard to follow without having the tools, but you mean that QT decode which produces this artifact was produced on the editing stage? (when he imported the file to the project or something?).
Actually this little clip wasn't more than a test video given to me to check "where-to-go" and set the ground, for color correction and artistic decisions. I will request them some float-point image seq. files, or if they just work with 8bit, png files, for the real thing when edition is finished.

The QT artifacts are from decoding h.264 through quicktime decoder.

Yes it's decoded like that, and any program that uses QT API to import will have those artifacts. (Basically any program when you use native 5D files will default to useing quicktime to decode, because they are mov wrapped)

You don't need any special tools, you can do it all through avisynth and free tools to avoid decoding through QT. e.g. ffmpegsource2 in avisynth

The screnshots illustrate that if you use ffdshow or avisynth ffvideosource they are not there. You can convert to RGB PC.709 (0-255) in avisynth, and use imagewriter for RGB png files.

I would still request native footage or instruct whoever is handing the footage to you to avoid QT to decode, and use full range , because most NLE's will convert to YUV 0-255 to RGB 16-235 (BT.601) and clip the data (less data for your grading) . If they don't decode & encode the image files correctly, you will get the artifacts when handing them over

[Dogway]

Yep, I read your post about 5DtoRGB (http://rarevision.com/5dtorgb/) tool for Mac, which is where it is being edited, I just gave it a glance but I could recommend it to the editor in case its freeware, and ask him for exporting to .dxp file which works quite well with Nuke.

EDIT: Just read everything, thanks a lot for the help.

[poisondeathray]

Yep, I read your post about 5DtoRGB (http://rarevision.com/5dtorgb/) tool for Mac, which is where it is being edited, I just gave it a glance but I could recommend it to the editor in case its freeware, and ask him for exporting to .dxp file which works quite well with Nuke. Does this tool also fixes the clipping issue you talk about?

yes, I think that would be the best way on a mac

it has various matrices you can use for the RGB conversion, and I think you can do full range as well


PD: Just out of curiosity, what bit depth is natively recorded in 5D?

8-bit per channel