Do you have ffmpeg.exe in the same folder as the script? Sounds like the script isn’t finding ffmpeg.exe.
ffmpeg is found and runs, that is where the error messages are coming from.
It’s ffmpeg that is not happy with many of the options passed to it.
Try running this abbreviated code.
Where is input.mp4 in relation to ffmpeg.exe?
ffmpeg -y -i "input.mp4" -acodec copy output.mp4I will be AFK for a while but will get back to you.
Not to worry Chris, found the problem, outdated ffmpeg.
Sorry my bad.
OK it does seem to show interlaced characteristics.
However, one thing bothers me, it’s flagged as MBAFF (Macro Block Adaptive Frame Field Coding).
What this means is, it can be interlaced but there is no actual guarantee that it is.
In fact, it could be a mix of interlaced and progressive as it can vary per macro block.
The encoder decides this based on motion per block in a frame.
This could be dangerous, especially when playout servers are involved.
Another potential problem, MBAFF is relatively new so some players (and indeed servers) may not
support it and thus just give up without even attempting to play it as the MBAFF flag is read first.
Other potential “gotchas”:
The script as it stands, does not allow for bit rate control.
My input was a ProRes clip at about 80Mb/s and out was 4.5Mb/s.
There should also (ideally) be control over I frames.
My test clip was 166 frames long and only the first frame was I, the rest were all P and B.
Although good from a size perspective, many broadcasters (not sure about the U.S.), will not like the shortage of I frames.
I think all my questions got answered in here. Thank you, and to everyone. I was also concerned about acquisition rules, because in the past when I looked at submission guidelines, some networks were very specific that material should not be acquired at 24fps (this is for 30fps ATSC stations). Well, that is extremely limiting for somebody that would also like to take their work to a film festival or play it in a theater. I looked again, and the “no 24fps sources” rule is no longer in the guidelines, so maybe that’s been relaxed. I wondered why the broadcaster would care if the producer did a pull-down as part of the delivery. Feature films have no problem being pulled down to 30fps, so I didn’t understand why that restriction was there.
I’m on a budget. Brave and Lucky are my middle names. 
Doesn’t bother me at all.
For an ATSC-compliant 1080i file, what frame rate should the input file be if it’s progressive? I assume a 29.97 frames/sec input will get split into 59.94 fields/sec by tinterlace? Is that the ideal workflow?
True, but that is easily remedied with additional output codec options. Also, the MBAFF problem is because the output was specified as MP4 and encoding probably defaulted to libx264 which is MBAFF-only and won’t do PAFF by design. If the encoding was forced to XDCAM in MXF, that problem would probably go away. So, this is looking promising.
Paul:
You can try to jockey the script to deliver the correct output, however, I have a feeling the problems you mention are not with the script but with ffmpeg itself. There is a limited number of interlace options with ffmpeg, so I think it would be necessary to do some re-coding and compile it yourself. You can inuire on one of the ffmpeg boards or I can do it for you.
This script is not intended to do bit rate control but I do have one at home that does.
What is the correct way to handle i frames?
In a movie theater showing feature films you have one projector and total control over it. In broadcast you have potentially millions of receivers with no guarantee that any or all of them can handle 24 fps, so they choose the safe route which is 29.97/59.94. If a receiver won’t play back your programming and spots then you’re up sh*t’s creek.
See here:
It is defaulting to libx264 since the output file ends with “.mp4”, so the standard -b:v and -crf and -qp options apply.
With the -g parameter, which is the Group Of Pictures specifier. Using -g 1 is equivalent to -intra to get an all-intra encoding. If you do something like -g 15 for half the frame rate assuming 30fps, you can also add -bf 2 to set the number of B-frames that are allowed. Everything else will be P frames.
Do playout servers support MP4? I thought we were limited primarily to XDCAM which shouldn’t have this problem in the first place.
I wouldn’t expect any of them to. That’s why if I had acquired at 24fps, I would have pulled down to 59.94 per the network’s requirements when I submit my file. That’s why I didn’t understand why a network would specifically forbid footage to be acquired at 24fps. They don’t see the actual 24fps, only a pull-down of it, so what would they care? Why limit the production company?
Hence why I think using XDCAM would eliminate the problem.
After installing the K-Lite codec pack on my travel machine, this now gives me interlaced TFF, eliminating MBAFF.
ffmpeg -y -i "input.mp4" -vf scale=out_color_matrix=bt709:width=1920:height=1080:out_range=limited,tinterlace=4:vlpf -flags +ilme+ildct -r 29.97 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -vcodec mpeg2video output.mpgUnless you have a custom ffmpeg build, it usually doesn’t have spec compliant XDCAMHD422 encoding
You can use FFmbc (the broadcast version of FFmpeg) for XDCAMHD422 encoding . Baptiste Courdurier was commissioned by BBC to develop this fork some years ago, but the project is mostly abandoned. It still produces broadcast spec XDCAMHD422 encoding and FFMbc has been used successfully for submissions for years both North America and European
The MOV version accepts the vtag, but some stations prefer the MXF version (ask)
The standard requires at least 2 mono 24bit 48Khz audio tracks to be standards compliant
use proper vtag for whatever format you are using
"xd54" XDCAM HD422 720p24 CBR
"xd59" XDCAM HD422 720p60 CBR
"xd5a" XDCAM HD422 720p50 CBR
"xd5b" XDCAM HD422 1080i60 CBR
"xd5c" XDCAM HD422 1080i50 CBR
"xd5d" XDCAM HD422 1080p24 CBR
"xd5e" XDCAM HD422 1080p25 CBR
"xd5f" XDCAM HD422 1080p30 CBR e.g
starting from 1080p59.94 4:2:0 source , 1 track stereo audio; progressive upscale to 4:2:2, interlace content with lowpass, encode to XDCAMHD422, split channels to two 24bit 48Khz mono tracks
ffmbc -i INPUT.mp4 -vf format=yuv422p,tinterlace=4:flags=vlpf -r 29.97 -tff -target xdcamhd422 -an -vtag "xd5b" OUTPUT.mov -acodec pcm_s24le -ar 48000 -newaudio -acodec pcm_s24le -ar 48000 -newaudio -map_audio_channel 0:1:0:0:1:0 -map_audio_channel 0:1:1:0:2:0Which networks, if any, require delivery in XDCAM:
BBC?
ABC?
CBS?
ABC?
PBS?
Which require delivery in 4:2:2?
Very cool. Would that be supported by your hardware playout server?
This is some gold here. Not just the command line for conversion, but the reminder about mono tracks too. It clicks with me now why broadcasters are so picky about the submission format. We haven’t talked about the mono downmix and alternate language tracks yet, or closed captioning which is required by the FCC at least. As in, the standards imposed by the FCC are much more labor-intensive and comprehensive than for videos submitted to YouTube. The broadcaster does not want to be responsible for taking stereo tracks and downmixing them to mono and ensuring it doesn’t clip or phase-cancel part of the audio. That burden should be on the content producer. Same for captions and the secondary language audio stream. There are a lot more assets being produced for broadcast than there are for YouTube, and it takes a standardized format to bundle them all together. I can dig that.
I can’t speak for all of them as I was mostly interested in PBS. Here is their 2016 Red Book (currently being updated but the new version isn’t released yet to my knowledge):
They take MPEG-2 in XDCAM, or DNxHD 145. Starts at Section 8.5 on printed page 15, PDF page 19.
NETA follows their lead, but also allows ProRes if submitted as an external hard drive:
https://www.netaonline.org/webfiles/FileSubmissionRequirements-2016.pdf
All of them require 4:2:2.
There is some good info here, thanks guys.
I can confirm that when delivering in XDCAM, 4:2:2 is a given.
The audio is a bit more tricky and will vary from broadcaster to broadcaster.
Our standard is 8 stereo tracks (not discrete mono) all at 24 bit, 48Khz sample rate.
Stereo pair 1 is the main sound track, pairs 2 to 6 are for foreign languages (or just a copy of the first pair), pair 7 is an ambience/effects only track and the last track is reserved for now, just silence.
As regards the wrapper, Op1a MXF is preferred over MOV.
These specs only apply to long form, for short inserts, commercials and promos, a single stereo pair (main language) is acceptable.
Then of course the news worthy clips, here anything goes, animated gifs excluded. 
We need a way of exporting video which is captive to Shotcut. The question is, can Shotcut do this and comply with specs?
We know Shotcut cannot do interlace, so do we export from Shotcut in XDCam progressive then run my script in standalone ffmpeg or ffmbc if interlace is needed?
One way, if SC supports it, is to have the ability to pipe to either ffmpeg or something else.
Don’t know if @shotcut will be willing to add something like that.
Perhaps an extra tab or option in the export menu, where instead of exporting as it does now, it pipes
to an external program/script?
This way, time is saved as two exports are no longer needed.
Did y’all see this?
MOV files containing ProRes essence must be delivered via external or portable hard drives or a removable device such as a flash drive.
Here are the UK specs for reference: