Exported Video Not Interlaced

Hi Chris

Yep, the safest option is XDCAM 4:2:2 wrapped in a OP1a MXF.

Yes it is.

Are you referring to streaming services or traditional broadcasters?
H.264 is great for streaming but not great for editing.

From October we will also accept AVCintra class 100 as part of the new DPP delivery specs.
Many European broadcasters have adopted it as the new standard.
Not sure what is happening on the other side of the “pond”.

Unfortunately yes.
I certainly couldn’t afford them but since the station has them…:grinning:
Send some, when I have a gap will run them trough.

Another option may be AVS scripts to detect interlacing, I don’t have the time to learn them and don’t know how reliant they are on ffmpeg, if at all.

Yet another way to interlace footage is to get a real time scalar/interlacer.
We have just a unit which we use to put skype calls on air.
The HDMI output from a mac we patch through the scalar (with ref in, in your case you can have it free-running ) and out comes interlaced video 1920 X 1080 (with embedded audio) on SDI.
This SDI output you could then record on a ATOMOS recorder or similar.

[quote=“Paul2, post:23, topic:11418”]
Are you referring to streaming services or traditional broadcasters?[/quote]

Program distribution for over-the-air broadcast. Of course the shows will have been transcoded to MPEG2 when transmitted.

Who makes this magic box you use for Skype?

We use the Gefen HDMI to 3GSDI scalar but other companies like AJA and possibly BMD (not a fan) probably make similar boxes.

AJA makes a lovely unit called the FS2 but heck of a pricey.
Rather look at their smaller ROI (Region Of Interest) converters.


Broadcast equipment is normally very pricey, but if you are prepared to accept older models with some nicks and scratches but in good working order, look at web sites of second hand, refurbished equipment dealers and brokers.
I have picked up some good deals in the past.

Here is the MediaInfo dump:

Format profile : Base Media / Version 2
Codec ID : mp42
File size : 5.44 GiB
Duration : 1h 19mn
Overall bit rate mode : Variable
Overall bit rate : 9 774 Kbps
Encoded date : UTC 2017-11-08 15:14:42
Tagged date : UTC 2017-11-08 15:16:35
©TIM : 00:00:00:00
©TSC : 25
©TSZ : 1

ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 19mn
Bit rate mode : Variable
Bit rate : 9 450 Kbps
Maximum bit rate : 12.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.182
Stream size : 5.26 GiB (97%)
Language : English
Encoded date : UTC 2017-11-08 15:14:42
Tagged date : UTC 2017-11-08 15:14:42
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

MediaInfo does not actually check the frames/fields, it just relies on the flags being properly set and reports those.

We discovered that MediaInfo is not accurate in dealing with interlace so we don’t rely on it as noted in an earlier post. We prefer to use Shotcut’s own “Properties” feature

Interlace may not mean much to a casual YouTube or non-broadcast user, but if you’re submitting video to a professional broadcaster who scrutinizes such things as part of their quality control, it needs to pass muster with them before they will put it on the air and then it becomes important.

In the U.S. PBS is pretty strict about such things.


I saw something that suggested the “Properties” part of Shotcut is using ffprobe. I’ll post more info if I can remember where I saw it.

Here is a bit of ffmpeg code I have tried. MediaInfo reports “Interlaced” and “Top Field First”. ffprobe recognizes “top first”. So maybe MediaInfo isn’t broken after all?

 ffmpeg -i "test_pattern_709.MP4"  -y  -s 1920x1080  -pix_fmt yuv422p  -vcodec mpeg2video    -vf tinterlace=4  -flags +ilme+ildct  output.mpg 

I think it needs the ilme and ildct flags set. Ilme is “interlace mothion estimation” and ildct is “interlace discrete cosine transform”. Maybe these flags need to be set in Shotcut’s “Other” export tab?

Here is the MediaInfo dump:

Frame rate : 25.000 fps  <-
Standard : PAL  <-
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced  <-
Scan order : Top Field First  <-

You don’t say how this dump was generated, but note that PAL gets it right with a frame rate of 25 frames per second. Note that in NTSC this would be an erroneous frame rate of 59.94 frames per second. In NTSC it should be 29.97 frames per second.

I don’t think MediaInfo is broken, it’s just that the only check it does for interlacing is reading how the flags are set.
ffmpeg on the other hand is definitely not right.

I remember messing about with those a while back with limited success.
Depending on the codec and scan of the source footage and the target codec for export,
it would sometimes get it right (actually interlacing the footage and setting flags correctly) and sometimes not.

I know that @shotcut made a few changes and he may have added those as defaults, not sure.
Interlaced mov exports are still not 100% and depend on source footage as noted above.
For now, the only interlace export I trust is XDCAM in a mxf container as I use them successfully in some workflows for broadcast.

What frame rate are you getting on your interlaced XDCAM exports, both progressive and interlaced? I get 59.94 for interlaced which is the correct field rate, not frame rate. The frame rate should be 29.97. Shotcut’s frame rate appears to be unstable.

I’ve been transcoding H.264 mp4 files (many camcorders output H.264 so I don’t start with XDCAM originals). I may make some XDCAM test files, but still the frame rate should remain stable.

If any changes were made I would think those flags would show up in the “Other” export field. I have added them to my custom export settings.


For interlaced, I get the proper 50 fields but not in a mov, only mxf.
Another problem with ffmpeg is it sets the codec_ID to xd5e which is incorrect
when there are fields, it should be xd5c.

The codec_ID for XDCAM progressive is xd5e and for interlaced it’s xd5c.
(@ 1920 X 1080)
ffmpeg gets this wrong at times and other times it’s right.
I don’t know why and what triggers it.
Have given up trying to export XDCAM in a QT mov using ffmpeg and only use MXF.

The only time I export progressive footage is if I’m making viewing copies for sponsors.
There I use H.264 (baseline profile) and in a MP4.
The idea is that they can then view it on pretty much any computer, smartphone, tablet
or media box.
This ffmpeg gets right, at least with progressive, i.e. no fields and 25 frames per second.

Should I join the mailing list and report this as a bug?

You are welcome to try, others have complained about this too but they will just give you a whole song and dance about it and do nothing.

Kind of like getting Firefox to change the color space from bt.601 to bt.709. The bug has been known about literally for years but Firefox programmers tell you they “don’t have time”. It would probably take about 10 minutes to change the code. Somehow Chrome finally managed to go to bt.709.

Forget it with ffmpeg.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.