Best way to Re-encode Canon 5D .mov file after Deshake?

[PhotoCat]

Oic, thanks agn posiondeathray! U r such a good teacher! Highly appreciated!
I think I got it now... The missing link for me was the ffmpeg GUI and I really need to play with it
to see what command line options to use and then tag on your 709 conversion & flagging switches!

Let me try the new workflow out... I think I would prefer workflow#2. Thank you once again posiondeathray, jagabo & racer-x!

[jagabo]

3) In avisynth, convert from YUY to RGB with rec709 matrix (ConvertToRGB32(matrix="Rec.709" ))

I thought your source had 601 colors with full range YUV. In which case you want matrix="PC.601". Otherwise darks and brights will get crushed.

[poisondeathray]

He's using QTInput(). So decoded YUV will be clamped to Y' 16-235 before the RGB conversion

2) Use Avisynth as a frame server to read in the .mov file (via QTsource/QTinput input plugin)

But if he were to FFMS2, then most versions obey the full range flag and output Y' 0-255, then the PC matrix would be a good idea (or another method to clamp)

[PhotoCat]

So is clamping ok? I know it is not clipping. Would clamping reduce the dynamic range of the video somehow? Is clamping some sort of compression at the very dark and very bright ends? I don't have to use QTinput/QTsource, if some other input methods give higher quality video import. Thanks!

[PhotoCat]

For virtualdub, I have FFinputdriver.vdplugin and QuickTime.vdplugin. So I don't have to go the avisynth route for import.

[poisondeathray]

The danger that jagabo is alluding to , is the RGB conversion. If you use "Rec" matrices, Y' 16-235 get "mapped" to R,G,B 0,0,0-255,255,255 . This means 0-15, and 236-255 get clipped or discarded. Clipping does reduce the dynamic range because data is thrown away

If you ensure the Y' data is within 16-235 before that RGB conversion (such as by clamping, or any method such as levels adjustmetns), then you won't clip the "superdarks" and "superbrights". Thus with QTInput , you are never in that danger zone, because the Y' data is already within that legal range

Alternatively, you can work in full range, using a PC matrix to convert to RGB. This will stretch the contrast if you use QTInput, but make it look "normal" if you use FFMS2 . A PC matrix will "map" Y' 0-255 to RGB 0,0,0-255,255,255 . Since FFMS2 decodes at full range to begin with, a PC matrix is the proper way to do it when using FFMS2

SUMMARY: So when using avisynth, if you use QTInput, use a Rec matrix when converting to RGB . If you use FFMS2, use a PC matrix (or other method to "legalize" Y' values before the RGB conversion if using a Rec matrix), otherwise you will clip the ends . To be clear: this only applies to the QT MOV files with the full range flag such as the 7D, 5D MKII, T2i etc....





The other part of the discussion is Rec709 vs. Rec601. The metadata suggests Rec601, and my tests show for the 5D MK II, 7D, T2i/T3i , all should be using Rec601 for the 1st trip into RGB. You will notice the skin tones shifted if you use 709. Some people think otherwise - Like I said there is some debate over that topic. But the 5D MK III (not II) uses 709 I think most agree on that. And regardless of what you choose, I think using Rec709 (and flagging) when converting back to YV12 is a smart thing to do because that's the standard for HD, and everything expects Rec709 for HD. You have the highest chance that it will look as you intended it everywhere

[jagabo]

Sorry, I didn't realize he was using a source filter that reduceYUV 0-255 to 16-235.

[PhotoCat]

mm... I am a little confused... so should I use FFMS2 with PC matrix for a higher quality import?

Can FFMpegSource2 work with 5D2 .mov file? Thanks!


Just found the download link for FFMS2.DLL

https://code.google.com/p/ffmpegsource/downloads/list

[poisondeathray]

"highest quality" isn't so clear cut... because there can be differing opinions. Conversely, things like clipping data = bad ; those types of things are clear cut and everyone agrees on

Personally, I don't like the quicktime decoder, personally I use FFMS2 if I am using avisynth with these. In theory, a decoder is supposed to be produce bit for bit identical output. But this is one case that shows that's not true. Basically , the QT decoder adds a bit of noise (Apple would probably "market" it as "dithering" ... and charge you extra for it - </ end joke>), and the output isn't as clean as other decoders (like through libav/ffms2). If you upsample and convert to RGB with Apple/QT (the upsample part doesn't affect you when using QTInput in avisynth , because the output is YUY2) , it uses a poor algorithm resulting in blocky color edges. Have you heard of "5DtoRGB" by Rarevision? One of the main benefits is higher quality chroma upsampling compared to Apple or FCP , and one of the main reasons for using that (especially for Mac users, who don't have easy access to other workflows like avisynth) was to get away from the QT decoder. I posted some comparisons/screenshots a few years ago about various decoders, and many other comparisons were posted from other people as well on various sites . I think I posted some here and at Doom9. My comparison was with the 7D, but it applies to the 5D as well. You can search (you have to go back a few years, because that's when these models were in their "heyday" )or do some of your own comparisons. Again, you have to go frame by frame to see the differences (you won't see it under normal viewing conditions), but they are definitely there.

But FFMS2 isn't perfect either - it indexes the file the 1st time, so takes longer to open that first time, leaves additional "index" files (clutter) , but at least it doesn't have the QT image quality issues

[PhotoCat]

Thank you poisondeathray once again for your expert advice. I will try ffms2, as quality is important to me as I am re-encoding deshaked 5D2 .mov files as master copies for future editing. (will probably convert to huffyuv or Lagarith for editing in the future)

[poisondeathray]

Don't just take my word for it you should also examine it yourself with your own eyes and read up on it on the various 5D forums. As I said - some topics are clear cut , other topics are more subjective with different opinions




RE: decoder differences, QT

Here is one of those old posts, look at post #7
http://forum.doom9.org/showthread.php?t=156574

The labels are a bit misleading because they are both imported as v210 into AE. To explain that in more context, those images are converted to RGB in AE, the left decoded with QT, imported as v210 (uncompressed 10bit 422) into AE. Those are nearest neighbor enlarged - so we're "pixel peeping". The right was the same, except decoded with ffms2 (Coincedentally, the slight differences in color are from 709 vs 601)

The 3rd biggest gripe about the video image quality with the 5D (besides the aliasing and softness), is "noisy blacks". That's in a large part from the crappy QT h264 hardware compression module (I know you said you liked it, but yes it's crappy compression, almost the worst hardware recording module for AVC in existence for cameras, the exception being security cameras /rant over) . Well you can see how the QT decoder accentuates the noise, especially in the black areas, and esp. the blue channel

[PhotoCat]

Wow... QT created so much more "blocking" artifacts!
Thanks for sharing your invaluable experience and knowledge!

[PhotoCat]

So I got FFMS2 working as the source filter in the avisynth script:

LoadPlugin("C:\Virtualdub32\FFMS2\ffms2.dll")
FFmpegSource2("MVI_8695.mov")
ConvertToRGB32(matrix="PC.601" )

The levels seem correct.

Unfortunately this FFMS2 source is creating some pixelization glitch
on a few frames.

Switching back to QTinput eliminated the pixelization problem: (levels are ok too)

QTInput("MVI_8695.mov", audio=2)
ConvertToRGB32(matrix="Rec601" )

Perhaps I should try an older version of FFMS2? 2.17 is the version I have.

Any clues? Thanks!

[poisondeathray]

It's 2.20 now, I would try newer, not older

https://github.com/FFMS/ffms2/releases

Make sure you delete the index files

[PhotoCat]

oic. pls provide the download link, if possible. Thanks agn poisondeathray!

[poisondeathray]

You probably posted about the same time as my edit, see link above

[PhotoCat]

oh wow! Tks agn poisondeathray! U r the best! 2.17 was the newest I could find...
Tks for showing me the latest link!

[PhotoCat]

FFMS2 2.2 works better but it still has a little "dot" of pixelization here and there. This pixelization glitch is very repeatable
and it is viewable from avspmod and virtualdub on a frame by frame basis.
2.2 is a definite improvement over 2.17 but it is still not perfect.

Observation of levels is as follows: (with both FFMS2 2.2 & QTinput)

1) preview inside AVSPMod - good (no crushed black or blown white)
2) preview inside Virtualdub64 via avisynth & AVSF - good (no crushed black or blown white, same as 1)
3) exported .avi using x264vfw when played on windows media player - good (no crushed black or blown white, same as 1)
4) exported .mp4 using FFMpeg external encoder - good (no crushed black or blown white, same as 1)
-f rawvideo -s %(width)x%(height) -r %(fpsnum)/%(fpsden) -i - -vcodec libx264 -level 51 -preset ultrafast -intra -crf 8 -qmin 1 "%(tempvideofile)"
(I have not added the Rec709 flag yet. BTW skin tone on Rec709 looks more orange than Rec601 so I prefer the look of Rec601)

5) preview of the original .mov 5Dmk2 file in windows media player - bad (crushed black and blown white!)
6) preview of the original .mov 5Dmk2 file in Quicktime player - bad in another way (more shadow details but with blown white!)

So previews in 1)-4) looks promising and useful but 5) and 6) are puzzling. It would be interesting to know why 5) & 6) happened but
I guess in the grand scheme of things, I don't need them to be correct since I am not distributing the original .mov file

So for now, seems like QTinput works best for me despite the clamping.

Anything else I can try? Thanks!

[poisondeathray]

What dot pixellation ? Can you post a sample ? Post a screenshot or better yet, post a video sample (e.g. cut with qtpro, or mpegstreamclip)

(I have not added the Rec709 flag yet. BTW skin tone on Rec709 looks more orange than Rec601 so I prefer the look of Rec601)

I use 609 for converting TO RGB , 709 (and flag) to convert back to YUV . Remember the flag does nothing in most circumstances. Only certain players read it. It's the actual RGB=>YUV conversion (or colormatrix filter in YUV) that changes the actual data

5+6 are weird - something isn't calibrated on your system (monitor, graphics card / driver, renderer, player)

[PhotoCat]

There are a few dots of pixelation here and there... only lasts for 1-3 frames. Much like weak signal reception on digital TV.

[PhotoCat]

It is completely gone when I switch back to QTinput.

[poisondeathray]

Is it reproducible (does defect always occur on same frame), even when you seek & go back? Or are defects random?


Can you post a native MOV video sample (cut a segment around that defect)

[PhotoCat]

Not sure how to attach a video file. I don't have a .mov encoder so I uploaded a .avi file but I can't see the attachment.

[poisondeathray]

That doesn't help, I need to look at the native MOV video, not re-encoded .

Answer the other questions about the defects, reproducible ?

Best for cutting is quicktime pro. If you don't have QT pro,

Or open it up in avidemux , video=>copy, audio (doesn't matter, pick aac because uncompressed doesn't mux well with it's muxer), format =>MP4 . Mark in/out a section on keyframes, push save, enter name with extension eg. "cut.mp4"

[PhotoCat]

It looks like it is reproducible because it happens only on certain frames. Would Virtualdub direct stream copy work for u?

[poisondeathray]

Would Virtualdub direct stream copy work for u?

Not if you use an avs script. Avisynth frameserves uncompressed video

I think you can with the vdub quicktime import plugin, just use video=>direct stream copy, audio=>no audio

Verify , with the cut .avi sample that your FFMS2 opens it with reproducible artifacts before uploading. If it doesn't, then I need a MOV sample

[PhotoCat]

So I tried direct stream copy in virtualdub for the previous clip (no avisynth) and produced a .avi file. Then read that .avi file in avisynth using FFMS2 source in avisynth. The artifact went away!! It appears FFMS2 likes .avi more than .mov!

So I found another short raw .mov clip directly out of 5Dmkii and the problem is again happening on frame 82-85 or so. It is about 80% reproducible in Avspmod using FFMS2 V2.2 source in avisynth. It is now attached. (QTsource doesn't have this problem) Thanks!

[poisondeathray]

I can't reproduce any errors , but I'm using avisynth 2.6 with FFMS2 r931
http://forum.doom9.org/showthread.php?p=1688624#post1688624

First try this
Delete the index and try
FFVideoSource("MVI_6235.MOV", threads=1)

If that doesn't work , you can try avisynth 2.6 , with the FFMS2 C Plugin

[PhotoCat]

Thanks poisondeathray! Once again u did it!

I used:

LoadPlugin("C:\Virtualdub32\FFMS2\ffms2.dll")
FFmpegSource2("MVI_6235.mov")
ConvertToRGB32(matrix="PC.601" )

and that had problems.

Now u suggested:

LoadPlugin("C:\Virtualdub32\FFMS2\ffms2.dll")
FFvideoSource("MVI_6235.mov")
ConvertToRGB32(matrix="PC.601" )

That worked without any problems!! Yay!

I had no idea. I just copied an example from the web using FFmpegSource2. Now I know I should use FFvideoSource! Wow... big difference!

Thanks again for your expert help poisondeathray!

[poisondeathray]

It doesn't make sense, because they are both using the same thing, FFVideoSource(). Something else is going on

FFMpegSource2 is just a wrapper function that includes audio with FFAudioSource if you use atrack=-1

ie.

FFMpegSource2("video.mov", atrack=-1)

is the same thing as

aud=FFAudioSource("video.mov")
vid=FFVideoSource("video.mov")
AudioDub(vid,aud)


What I suggested was use threads=1, because sometimes seeking can be problematic with mulithreads under some situations (shouldn't be with these files, other files like AVC transport streams with B-frames)