[Len Hugh]

These are not solutions, but might help confirm some things.

If you run your ffmpeg code without the fast start flag does it fix the white flash fault?
If so, if you run ffmpeg over the output and only add the fast start does the fault remain gone?
eg
ffmpeg -i outputFile.mov -movflags +faststart outputFile_with_faststart.mov

Is the Mpegstreamclip output the correct number of frames and the FFMPEG output is one frame longer then your avid sequence?

If you use -ss and specify the same start and end code as you have in avid does that effect the result?

[Len Hugh]

Thanks Michael,

So I would need to change the directory structure after copying from this
[drive]\Avid MediaFiles\MXF\[system.numbered folders]\[xxxx.mxf]

and move the mxf files into a numbered folder in this structure
[drive]\Avid MediaFiles\MXF\[numbered folders]\[xxxx.mxf]

Then the local MC would rebuild databases and be linked to media?

And from what I can tell this would be true of either a NAS or Direct attached storage (DAS)

Do you think gigabit ethernet would be fast enough to playback dnx36?

[Len Hugh]

Halved your encode time, thats great. even 10 or 20% time saved is well worth it when it comes time for mad turnovers.

re TC, yes, I have had some success.

maybe easier to contact me at whosofferingathotmaildotcom

[Len Hugh]

I added in a rescale and it worked. it seemed to work.
Altho I got that same error

[swscaler @ 0x7ff971805800] Warning: data is not aligned! This can lead to a speedloss

/usr/local/bin/ffmpeg -threads 0 -y -use_absolute_path 1 -i 'input.mov' -c:v libx264 -pix_fmt yuv420p -b:v 1500k -preset fast -vf crop=1686:720:117:180,scale=iw/1.5:-1,pad=width=1280:height=720:x=78:y=120:color=black "crop_out.mp4"


[Len Hugh]

Hey,

/usr/local/bin/ffmpeg -threads 0 -y -use_absolute_path 1 -i 'input.mov' -flags +global_header -c:v libx264 -pix_fmt yuv420p -b:v 1500k -preset fast -vf crop=1686:720:117:180,pad=width=1920:height=1080:x=117:y=180:color=black -c:a libfdk_aac -b:a 128k "crop_out.mp4"

so i have cropped top and bottom and left and right. just to cover all the bases in my test.

there are probably a few flags in here that don’t need to be there but its something that has evolved over a long time and I havent gone back to see what could go.
In my tests I had burn in TC and a watermark but I stripped out that for you.
I do get one error I cant seem to figure out. On some mov files I get this,

[swscaler @ 0x7ff971805800] Warning: data is not aligned! This can lead to a speedloss

in the terminal output but not all the time. the movs that work are exactly the same as the ones that dont ie dnx36 so I dont get why I only get it some times

[Len Hugh]

Hey Mark,
FYI, thought you might be interested in this.

I ran some tests to create a 2.40 mask.
(I took a 100 min dnx38 mov and made a h264, with timecode and watermark being burnt in with drawtext.)

1. drawbox
2. overlay a png file
3. crop it and pad it back out to HD

surprising to me, it turns out draw box was the slowest, taking 50 mins
the overlay method took 45 mins
and the crop and pad took 37 mins

I then checked how long it would take without a crop at all and it was the same time as the crop and pad, 37mins.

[Len Hugh]

Thanks for the code. I have not had time to play with other options. The only other way I can think to to it is to overlay a mask.

Its really a question of whats fastest. Ill run a test and see if there is a difference between your code and overlaying a mask and let you know.

I think your code sounds the best way, it saves having to have a png file or similar in a location and making sure it is there when the code runs.
I like it, thanks

cropping is another option but I worry that someone will try and bring the output file into another app and stretch the image without realizing.

looks to me like you have a similar occupation to me so while I have you could I ask you another question, (which I will post on its own in the forum later)
H264 and quicktime have always suffered from what is known as “the gamma bug” see this link for more info….
https://vitrolite.wordpress.com/2010/12/31/quicktime_gamma_bug/
how do you handle this if you are using H264 and delivering to clients?

[Len Hugh]

Yes, it is rendered.
I render in to out, then export.
I am using the default digital mastering setting in the avid quicktime reference export pane.

[Len Hugh]

thanks, ill check it out

[Len Hugh]

I wouldn’t think there would be a substantial difference between 115 and 175, not the way you are describing it.

I don’t work with AMA very often, I tend to transcode and work with low res mxf files (DNX36) and then reconform at a higher res when finished.

All I can add is to transcode the ama files to DNX175,
Or file->import the logo in and check your import options are set to 175 on the import window, then cut it in to your sequence.
Or even try exporting using a custom quicktime codec, e.g. pro res.

I seem to remember similar issues could occur if your format was set to SD in the project window. But I don’t think so as you have checked the output and its HD at around 115Mb