VirtualDub2

[Tehnicni]

Attached you have 2 crops, 1st is from 1920 x 1080 picture (which I first resize from 12M pixels origin in VirtualDub) and 2nd from Print Screen how is these picture look opened in VirtualDub. Because of these I get ugly banding in time lapse video. https://youtu.be/IFP4W7nd9VM If I open (in VirtualDub) origin 12M pixels picture and downsize it to 1920 x 1080 with the same resize plugin, there is no banding. https://youtu.be/_zdAa1RwUvM
Without youtube reencoding banding in upper left corner is much uglier.
I also tried with VirtualDub 1.10.4 and it's the same.
I tried the quality of jpeg coding (in exporting downsized image in VirtualDub) 95 and 100 and it's the same.

Added later: Video make with VirtualDub with h264 8bit codec CQP 20 on my Dropbox
https://www.dropbox.com/s/9wzgh4wld5pm6iu/FromResizedImage550Q20.mp4?dl=0

Quite unusual, but for a sunset time lapse very serious mistake. In fact virtualdub it's for me, for time lapse, unusable.

[shekh]

I'm not sure if this is a VirtualDub2 problem, but the following Avisynth script:

colorbars(pixel_type="rgbap8")

comes out all messed up. I was surprised it worked at all, given that VirtualDub2 doesn't understand pixel_type="rgbp8" (no alpha). Is it mistaking RGBAP8 for some other colour space?

rgbap8 and rgbp8 work for me but I have installed intermediate build of avs+ Pinterf gave me.
Which version of avs+ you have?

[shekh]

Tehnicni

It's all unclear. Do you mean
1. you have jpeg image (created in which program?)
2. vdub opens it with loss of quality?

If this is correct please share the image as is so I can examine it.

[Tehnicni]

Tehnicni

It's all unclear. Do you mean
1. you have jpeg image (created in which program?)
2. vdub opens it with loss of quality?

If this is correct please share the image as is so I can examine it.
I'm sorry, as usually the main thing I forget. Here's the original picture https://www.dropbox.com/s/g9t47up1e5u2kwb/Im0630.jpg?dl=0 . Open it in VirtualDub, aplay crop (bottom 400, top 356), resize it to 1920 x 1080 with Precise Bilinear and export it as .jpg. Then import the same (downsizes) picture into VirtualDub and you will get streaks (band) around the colored cloud above slightly left on the picture.
Downsized image if you would need it: https://www.dropbox.com/s/65ibgcuxb4jai68/ImHD0630.jpeg?dl=0
It seems to me that the Precise bilinear resize already changes the (round) cloud, perhaps because the downsizeing removes the noise.

PS: I'm working Time Lapse through the exported images, because I process them before re inported it into VirtualDub for making video.

[wonkey_monkey]

rgbap8 and rgbp8 work for me but I have installed intermediate build of avs+ Pinterf gave me.
Which version of avs+ you have?

r2768.

RGBP8 results in "Couldn't locate decompressor for format '8BPS' (unknown)", while RGBAP8 looks like this:

https://i.imgur.com/xXmXTkH.png

[shekh]

wonkey_monkey

avs+ needs a new build, there were changes. 8BPS output is deprecated (the fourcc is actually reserved by compressed format). Cant explain rgba picture but it is related for sure.

[shekh]

Tehnicni

I think there is subtle difference in decoding jpeg. Luckily there is an option: in the file open dialog change "input driver/open using" dropdown to "Caching input driver". The result looks smoother to me this way, but the difference is so subtle it is hard to tell what is ground truth.

Note: Caching input driver (using ffmpeg decoder) emits picture in YCbCr 4:2:2 format which I think is good because you do resize (this way should preserve details better).

[pinterf]

I'm not sure if this is a VirtualDub2 problem, but the following Avisynth script:

colorbars(pixel_type="rgbap8")

comes out all messed up. I was surprised it worked at all, given that VirtualDub2 doesn't understand pixel_type="rgbp8" (no alpha). Is it mistaking RGBAP8 for some other colour space?
VDub2 works fine with 8 bit planar RGB formats when using with the latest (not yet released) Avisynth+.

[Tehnicni]

Thanks shekh, Cashing driver is right solution.
I attached a series of pictures, the name says it all.
Let say 1st: File "Im0630" in 4K format Open with Cashing driver, Precise bicubic Resize and Crop, Exported, ReOpen with Cashing driver, Level (black 30, White 140) and finaly export single image.
The last two was exported and reloaded 3 times, so the error has multiplied 3 times.
A lot of distortion I think.

[Tehnicni]

I forgot a picture wich was 2 times opened with Cashing driver without level correction.
Without bands.
:thanks:

Added later: Too much joy leads to problems:(. Cashing driver rejects pictures from my ID. I'm trying to change Cashing driver settings, but no go. Here is picture from my IDE https://www.dropbox.com/s/rkwcbp16yyhm5x2/Im0860.jpeg?dl=0

[shekh]

I don't see your pictures, please use dropbox instead of forum attachments.
And I can't follow your description. "The last two was exported and reloaded 3 times" what this really means?
It seems you are doing something pointless. Using jpeg as intermediate is bad idea, this is not lossless format. Look at this: https://en.wikipedia.org/wiki/Generation_loss
Use tiff, tga, png.

"Cashing driver rejects pictures https://www.dropbox.com/s/rkwcbp16yy...0860.jpeg?dl=0"
I can open this file without issues.

[Tehnicni]

Strange, I can see all 4 attached picture after clicking link.

Yes, I open and export .jpg 3 times to enhance error that you can maybe see where is a problem and to decide to change internal jpg codec :) With Cashing driver there is no noteable difference.

My IDE support only jpg and png :(

Problem with picture Im0860 is in different color subsampling then previous 859. So if you open Im0859 https://www.dropbox.com/s/svr3cjw4l63r1mk/Im0859.jpeg?dl=0 as a picture sequence with Im0860 in the same folder, Im0860 produce error. With internal jpg codec there is no error.

[shekh]

Right, sequence of mixed formats is not supported.
I agree, jpeg support could be updated. It is also very inefficient at encoding.

[nji]

I would like to ask if the audio copy issue
(as discussed in https://forum.doom9.org/showthread.php?p=1867019#post1867019)
will be fixed at some time.
I ask because I paused working on WMV files with VD2
because I would have to accept unnescessary audio degradation
(re-encode the audio, although I don't change it at all).
(I tried by myself to workaround the issue...
extract audio stream (ffmpeg, asfbin, ...) and re-add,
but the out-of-sync/ delay effect always occurs.
And haven't found any hint why and by what amount).
Have you been successful on this shekh?
And if - will there by an improved VD2 sometimes (soon)?

[shekh]

Honestly since that message I made no progress on audio. It is still on priority but it will be done when its done.

[nji]

OK then. :thanks:

[wonkey_monkey]

VirtualDub2 has been taking a long time to open for the last couple of weeks - just the first time after a reboot, it seems. Is there anything I can do - command line switches or anything - that might give a clue as to why it's so slow to start?

[Tehnicni]

Does anyone know how to convert hundreds of raw (eg Panasonic rw2) images into 16 bit tiff without gamma correction, that I can opened in VirtualDub2 for Time lapse.
I've tried different SW, but I always get a gamma corrected images, which is far from raw data.

[Groucho2004]

Does anyone know how to convert hundreds of raw (eg Panasonic rw2) images into 16 bit tiff without gamma correction, that I can opened in VirtualDub2 for Time lapse.
I've tried different SW, but I always get a gamma corrected images, which is far from raw data.I presume you have tried RawTherapee, SilkyPix and the likes?

[lansing]

Does anyone know how to convert hundreds of raw (eg Panasonic rw2) images into 16 bit tiff without gamma correction, that I can opened in VirtualDub2 for Time lapse.
I've tried different SW, but I always get a gamma corrected images, which is far from raw data.

Do you mean curve not gamma?

[Tehnicni]

I presume you have tried RawTherapee, SilkyPix and the likes?

Of course. I would like RAW data before gamma and tone curve correction. Only lens and chromatic aberration correction.

[shekh]

Of course. I would like RAW data before gamma and tone curve correction. Only lens and chromatic aberration correction.

I have tried to make input driver based on libraw. I can share it but the problem is per-image metadata which I have nothing to do about.
If you can deal with just pixels it will do the job.

Btw I think dcraw command line has options to turn off any unnecessary processing, the input driver I mentioned above is merely a handy way to read bayer pixels without external tools.

[Tehnicni]

I'm afraid I do not have enough knowledge for anything like that. The problem is that it would need partially processed RAW data, lens and chromatic aberation.

I'm looking for a holy grail, perfect sunset time lapse.:)
My idea is to (on the basis of shutter information and the tendency of darkening) multiply raw pixels with a changing factor, to get a smooth transition from day to night. Lightroom & LRTimelapse is not good enough for me. I have IDE for basic picture manipulation to do some functions. Not enought for let say perfect resize. VirtualDub precise bilinear resize (~4K to 2K) do realy great job, they greatly reduce noise.

[shekh]

This is something else. At first I thought you want the 'rawest' bayer picture.
I'm too no raw expert, afaik the processing is something like this:
1. debayer (demosaic)
2. normalization (using various curve/matrix stuff embedded in picture)
3. lens/aberration (or it can be before #2, idk)
4. user adjustments
5. tonemapping (shrinking to 8 bits and limited dynamic range)

So do you mean you want to mathematically control #4 to apply transition? And without it, the sequence is perfectly smooth, without any jumps?
In that case sounds like you want to export to some hdr format.

[Tehnicni]

Sequence is not perfectly smooth, because in Auto Exposure mode shutter time jump in ~2% steps, so you get fast micro flickering (5 flicker/s) which is mainly seen as fast moving pixelation and banding. Deflickering is not a solution because if pixel binary value is let say 50, changing value for +-1% produce no change (50.4999 = 50).

My idea is to use a fixed exposure and manually changing it as needed, let say 1/2 EV every few minutes douring darkening. Or to use external intervalometer with standard auto shutter mode (with fixed ISO and apperture) and hope, that you get much bigger shutter jump, so pixelation and banding change in slow step. Then simultaneous deflickering and ramping.

My video with fast moving pixelation and banding, especially in fadeout portion. Best seen on high contrast OLED display like Samsung Galaxy S7
https://www.dropbox.com/s/lne9vsg1sa6ap24/YUV444Q18_7%2C4Mb.mp4?dl=0

[shekh]

Nice view. But I see prominent jumps in overall brightness, much bigger than "moving pixelation".
Some silly idea: what if you apply deflickering to initial bayer image (which is closest to exposure math), and store it back to raw format, to trick LightRoom that shutter steps were much finer than 2%. :)
Also maybe possible to do deflickering on 16-bit tiff export (do you process jpegs)?

[Tehnicni]

I'm working with jpeg, because I can't inport dng in VD. All dng SW with tiff export option export gamma corrected pictures. I'm working with Panasonic raw and found, that in 16 bit tiff all useable data is in upper 8 bits, so there is almost no difference versus jpg.
After half a year of bumping, today I find banding and pixelation (which I talking about in previous post) to cause OLED display - horible. On LCD there is almost no banding and pixelation.

I remembered MSUdeflicker 1.3 and got quite decent and well compressed Time lapse. A small secret, the images were captured with the Samsung Galaxy S7 :)
It's OK for LCD displays, but there is no hope for OLED :) :(
https://www.dropbox.com/s/a7e03xfq9zpohrt/YUV444Q22DeflickerMSUwithPeriodDef_defaultSet.mp4?dl=0

[SeeMoreDigital]

I'm working with jpeg, because I can't inport dng in VD. All dng SW with tiff export option export gamma corrected pictures. I'm working with Panasonic raw and found, that in 16 bit tiff all useable data is in upper 8 bits, so there is almost no difference versus jpg.Personally I don't create JPEG still image sequences, I convert to PNG, which work well with VirtualDub...

[Tehnicni]

Nice view. But I see prominent jumps in overall brightness, much bigger than "moving pixelation".
Some silly idea: what if you apply deflickering to initial bayer image (which is closest to exposure math), and store it back to raw format, to trick LightRoom that shutter steps were much finer than 2%. :)
Also maybe possible to do deflickering on 16-bit tiff export (do you process jpegs)?
I have tried MSU deflicker v1.3 and in normal mode works fine. If I set 1st and 3rd setting on max, the result is perfect, no flicker.
With 10% jumps in brightnes MSU deflicker does not work.

[Tehnicni]

From SilkyPix I exported 16 bit tiff (from Panasonic rw2 RAW), imported it into RAWTherapee, raised exposure compensation on 8, and exported part of the picture in jpg, to see the bit depth of the tif image. For comparison, I added also a picture made from 8 bit tiff.
The same 16 bit tif images imported into VirtualDub2 with the level filter input white level 31 gives the image with less bits, posterization is seen in the dark parts of the image.

I can upload the original RW2 (22MB) or 16bit tif (117MB) to my Dropbox.

[ChaosKing]

@Tehnicni "Attachments Pending Approval" it can take very long on this board. Better use an external service, like dropbox.

[shekh]

I can upload the original RW2 (22MB) or 16bit tif (117MB) to my Dropbox.

Not sure what I could do with rw2 but it is good to have just in case.
16bit tif: if it is too big you can crop some smaller piece (vd2 should not spoil it if you just use open, crop, save image).
Do you think the 8-bit and 16-bit tiiffs from SilkyPix are otherwise identical? 16-bit may be in linear light or something.

A thing to keep in mind is pixel formats conversion.
Few filters can work with 16 bits, for the rest the image is downconverted (to rgb32 for most 3rd party filters like MSU).
If in doubt look at the filters gui, it shows formats before/after.
https://i.postimg.cc/3xKNTv4N/filters.png
So if you want to tweak 16-bit don't use "levels"; try "rgb levels" or "6-axis color".

[Stereodude]

FFMPEG's compression options don't work with Fast recompress Mode. Is that expected? I have a YUV420 source. I'm saving to YUV420. The compression settings show no conversion is necessary. But when I try to save the AVI file I get the following error, "Video format negotiation failed: Use normal-recompress or full mode". Isn't that going to result in no longer lossless handling of the input file to FFMPEG with a unnecessary color space conversion to RGB and back to YUV420?

[shekh]

FFMPEG's compression options don't work with Fast recompress Mode. Is that expected? I have a YUV420 source. I'm saving to YUV420. The compression settings show no conversion is necessary. But when I try to save the AVI file I get the following error, "Video format negotiation failed: Use normal-recompress or full mode". Isn't that going to result in no longer lossless handling of the input file to FFMPEG with a unnecessary color space conversion to RGB and back to YUV420?

This is weird, will look into issue (repeated with FFV1 codec).

However, I have trouble getting "fast recompress" concept.
From docs:
VirtualDub automatically chooses a intermediate video format to use between the codecs
Indeed, historically the choice for output format is disabled.
To me, this is least conservative promise.

If you want to control unnecessary conversion, is is better to rely on the line "no conversion necessary" in normal/full mode. If the conversion is necessary you can still see if it is trivial like YUYV->YUV422 or involves any colorspace change.

[Tehnicni]

rgb level works very weird, see the orange surface behind the fence which became yellow regardless of the illumination. Gray is now OK.

Source 16 bit tif https://www.dropbox.com/s/dygmdo08knofla0/FZ1000_16bitCrop.tif?dl=0

It would be a good idea to add an Exposure correction slider to the rgb level plugin.

[shekh]

This is normal for per-channel clipping. If you amplify orange by 4 both r+g channels are maxed out.
What is exposure correction? "6-axis" has intensity slider, it works in YCbCr space / better for color consistency.

Your attachments are only visible to you, try to log off and view this page. Use service like postimages.org
I used to report posts with attachments and now the report button is gone! Is it just me? Maybe moderator had fed up with it :)

[Tehnicni]

These all around yellow is because these orange have no blue :)

Attachment can download those who have Dropbox account.

For exposure correction I don't know exactly. Effect must be the same as shutter increase or decrease, 1 step in exposure correction is the same as doubling shutter time (1 stop).

[Tehnicni]

Rgb scale filter is OK for exposure correction, but I could not found tone curve filter (level filter with more point between input black and white level) or level filter for 16 bit source. These type of filter is esential for transformation 16 bit source to 8 bit output, let say to create HDR.

[osgZach]

Has anyone noticed issues with hotkeys. I'm trying to assign hotkeys for starting/stopping video capture, while in video capture mode, but they never work unless the program has focus

[lansing]

I have a frame counting problem with the program. I was loading the same vpy file with vs editor and virtualdub2, while both shows a total frames of 62, vs editor ended at frame 61 but vd2 ended with a gray frame at frame 62.

[LigH]

Yes, the additional gray frame is just virtual, it was already so in Avery Lee's original, for a reason ... I believe you have to be able to set the end of a cut range behind the last frame to be exported.

[shekh]

This was mentioned few pages back :)
There is "zoom timeline" mode which can be handy for other purposes but you can also do this: right after opening source press Go->Zoom selection. The virtual frame will be out of reach.

[lansing]

This was mentioned few pages back :)
There is "zoom timeline" mode which can be handy for other purposes but you can also do this: right after opening source press Go->Zoom selection. The virtual frame will be out of reach.

The "go->zoom selection" option was grayed out when the script was first opened. It's just weird to have a frame on the timeline that doesn't belong to the clip.

[wonkey_monkey]

It's because setting an in-point is inclusive (the frame selected will be in the trimmed clip) but the out-point is exclusive (the frame selected will NOT be in the trimmed clip). This makes a certain amount of sense from a mathematical point of view - if you want a 50-frame clip, you select your in-point, then jump ahead 50 frames and selected your out-point.

Avisynth's in- and out-points are both inclusive, which is why trim(0,100) produces a 101-frame clip, not a 100-frame clip. That feels less sensible to me.

[shekh]

New build (43602), took a bit long to arrive.
In "other fixes" addressing some issues raised in the thread:

1) Blending inaccuracy in fflayer filter: fixed. (The original question was about logo, it still has the problem).
2) Quick saving of images: the File->Save image now offers unique (numbered) filename, also File->Save image (skip dialog) shortens the operation even more.
3) FFMPEG's compression options don't work with Fast recompress Mode: fixed.

[kolak]

Could we have ProRes presets updated so they better match official profiles (in this case ProRes_ks is better). It will be slower, but more Apple alike.

We need color tag as well, so parameters like this for ProRes HQ:

-metadata:s "encoder=Apple ProRes 422 (HQ)" -vendor apl0 -movflags write_colr -c:v prores_ks -flags "+bitexact"

Then also have interlaced box (+field order) to tick which adds:

-vf "setfield=1, fieldorder=tff" -top 1 -flags "+ildct+ilme+bitexact"

*tff or bff (and top 1 or 0)

This way we enforce proper interlaced encoding.

I'm not sure about this bit, but if you can set:
AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.

[stax76]

@shekh

I noticed main menu > File is very large, it might make sense to use some sub menus.

The icon looks nice (how did you create it?) and everything scales very well using 288 DPI, I wonder how hard it is doing all this with plain win32, even with advanced layout controls I had many difficulties using WinForms to implement High DPI.

Avery Lee is known to be an excellent dev, did you have a good experience working with his code base?

[shekh]

Could we have ProRes presets updated so they better match official profiles (in this case ProRes_ks is better). It will be slower, but more Apple alike.

We need color tag as well, so parameters like this for ProRes HQ:

-metadata:s "encoder=Apple ProRes 422 (HQ)" -vendor apl0 -movflags write_colr -c:v prores_ks -flags "+bitexact"

Then also have interlaced box (+field order) to tick which adds:

-vf "setfield=1, fieldorder=tff" -top 1 -flags "+ildct+ilme+bitexact"

*tff or bff (and top 1 or 0)

This way we enforce proper interlaced encoding.

I'm not sure about this bit, but if you can set:
AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.

> Could we have ProRes presets updated so they better match official profiles

Any hint how to do this? proresenc_kostya.c has prores_quant_matrices, do you mean to change that?

> -metadata:s "encoder=Apple ProRes 422 (HQ)" -vendor apl0 -movflags write_colr -c:v prores_ks -flags "+bitexact"

From this I understand:
-movflags write_colr: ok
-vendor apl0: ok
"encoder=Apple ProRes 422 (HQ)": can you help with all possible strings?
-c:v prores_ks: this is what I used anyway
-flags "+bitexact": can you provide any background on what it means?

> -vf "setfield=1, fieldorder=tff" -top 1 -flags "+ildct+ilme+bitexact"

setfield: ok
fieldorder: ok
ildct+ilme: ok
top: as I read it belongs to chroma location which can have 7 different values. This is disturbing option.
I think it is better if it is understood by the pipeline. Wondering how big is this problem? Can you have in practice only 422-top or anything else?

[shekh]

I noticed main menu > File is very large, it might make sense to use some sub menus.

Agree, something needs to be moved or deleted.



The icon looks nice (how did you create it?) and everything scales very well using 288 DPI, I wonder how hard it is doing all this with plain win32, even with advanced layout controls I had many difficulties using WinForms to implement High DPI.

Avery Lee is known to be an excellent dev, did you have a good experience working with his code base?

You mean the main icon? This was long trial and error. When I was almost fine with general look I made it as vector painting in Photoshop, then rasterized it in some practical resolutions, fixed some shapes, experimented with colors. The final image is combination of multiple resolutions. Down to 48x was easy from vector source, the smaller the more hand correction was necessary, and finally 16x I painted pixel by pixel.

DPI works automatically with standard controls like dialog with fonts and buttons. But it is a lot of trouble when doing any custom graphics. The timeline toolbar (position control) had a lot of scaling issues, I changed big part of its code. Overall IMO working with plain win32 GUI is like assembly, it is very slow to code but the documentation is mostly perfect and it can work.
Bitmaps with system colors (like toolbar icons) that can scale:
https://github.com/shekh/VirtualDub2/blob/a50fc6c58c0a529014b4c81062d0d5b84322dec2/src/VirtualDub/source/PositionControl.cpp#L132-L161
And then of course I maintain the created bitmap and redo it again if any scaling or system color parameters change.
Not too bad thanks to LR_LOADMAP3DCOLORS flag, otherwise would require to decode down to pixels and remap colors. Few dozen more lines of code...
In better GUI systems all this is standard function which doesn't need any implementation at all (not sure how is WinForms).

Did I have a good experience working with the code base:
I had all kinds of experiences. In most part I feel comfortable. I still don't know how to treat library names. Ami, Asuka, Dita, Kasumi and so on. Are these his girls? (ok got it, most likely anime heroes) To me looks like nonsense1, nonsense2, ... I never remember which one I need.
I hate almost everything about coding style: use of white space especially tabs, hungarian notation, multi-line parameter lists...
I like that the project is easy to build (very few dependencies). I like parts which are very simple, e.g. direct use of win32 API etc.

[kolak]

> Could we have ProRes presets updated so they better match official profiles

Any hint how to do this? proresenc_kostya.c has prores_quant_matrices, do you mean to change that?

> -metadata:s "encoder=Apple ProRes 422 (HQ)" -vendor apl0 -movflags write_colr -c:v prores_ks -flags "+bitexact"

From this I understand:
-movflags write_colr: ok
-vendor apl0: ok
"encoder=Apple ProRes 422 (HQ)": can you help with all possible strings?
-c:v prores_ks: this is what I used anyway
-flags "+bitexact": can you provide any background on what it means?

> -vf "setfield=1, fieldorder=tff" -top 1 -flags "+ildct+ilme+bitexact"

setfield: ok
fieldorder: ok
ildct+ilme: ok
top: as I read it belongs to chroma location which can have 7 different values. This is disturbing option.
I think it is better if it is understood by the pipeline. Wondering how big is this problem? Can you have in practice only 422-top or anything else?

Different profiles HQ, LT etc are basically encodes with specific Q level.
You control it with -profile:v flag. Options are here:
https://ffmpeg.org/ffmpeg-codecs.html#ProRes

If you specify both: profile and Q then Q overwrites profile (so for official profiles we want just profile flag). Q allows you to make any quality ProRes files up to almost lossless, but this is outside Apple official profiles (still useful to have as advanced mode). ProRes_ks better simulates Apple one as it has bitrate restrictions. Ffmpeg prores uses higher bitrate which provides bit better quality, but it rather poorly simulates official encoder. Maybe you can have both as an option. In this case use number for profiles as text naming doesn't work for prores encoder: [0 - apco, 1 - apcs, 2 - apcn (default), 3 - apch, 4 - ap4h, 5 - ap4x]. Apco is proxy profile, apcs is LT.

Strings for all official naming:

Proxy profile="Apple ProRes 422 Proxy"
LT profile="Apple ProRes 422 LT"
Standard profile= "Apple ProRes 422"
HQ profile= "Apple ProRes 422 HQ"
4444 profile="Apple ProRes 4444"
4444QX profile="Apple ProRes 4444 XQ"

bitexact will remove Software=Lavfxxxx metadata in MOV container. Can be useful, but not essential.

top is not about chroma location, but field order, so it basically tells ffmpeg to set field order flagging. It's somehow the same as fieldorder=tff and may be redundant, but it's safer to have it as well. Both should be aligned and have tff(1) as default (bff is needed very rarely).

Least note- color tags are written by the default based on resolution/fps. You can force them as well using correct flagging: https://trac.ffmpeg.org/wiki/colorspace. Default behaviour is fairly good though (at least for HD, PAL/NTSC SD formats).