[Brendan Roney]

I’m only working with SD stuff, so like you say, I’d expect everything to be lower field first. I’m actually on a PC with an oddball motherboard that supports Thunderbolt. I’ve been capturing right into Media Express, and haven’t actually set up an SD monitor. I’ll see what I can do with that. Now the TBC I have claims to be full frame, so does that mean it couldn’t be causing this lagging field issue?

I tried running my allegedly top field first MJPEG capture through an ffmpeg script that’s supposed to determine field order by comparing frames, and it’s telling me it’s lower field first. Could Media Express just be flagging interlaced MJPEGs incorrectly?

[Brendan Roney]

You are absolutely right about the two files. Our masters are going to be some variety of jpeg2000 (QT’s implementation doesn’t seem properly mathematically lossless although the compression ratios we’re getting are within what is generally reported for being “visually lossless,” and meanwhile I’m still working on getting OpenDCP to shallow the j2k plugin’s truly lossless output). Our original captures are Blackmagic codec avi’s, unfortunately we don’t have the space to keep those as the master files.

The h.264 ones are indeed our service files. We were assuming since these would be both for streaming by the general public and licensing to interested parties (we aren’t entirely comfortable with letting the masters out in the wild, nor would they be convenient to ferry around), we’d split the difference and keep them interlaced even if they might look somewhat off to everyday folks. We did toss around the idea of doing additional temporary deinterlaced versions for streaming, which we wouldn’t end up storing internally after upload. I think AME makes that easy enough that it wouldn’t upset our workflow. I’m still not sure how the h.264 files are coming out with those two extra lines though.

[Brendan Roney]

As the footage was originally produced as interlaced video, we wish to maintain that format for preservation purposes. We also believe methods of deinterlacing will improve as computers get faster, and more sophisticated algorithms are drawn up, therefore we’d rather leave performing such a lossy action to future viewers and users, rather than locking it in place right now.

Would this question be better suited to the Adobe Media Encoder forum here? Am I allowed to repost this there, or do I need a mod to move it?

[Brendan Roney]

No problem. Thanks for your help so far.

Here’s the settings:

Note that we have it set to “scale to fit” at the top right. The “change output to match” option is greyed out. However both the input and output listings here give 486 for the vertical resolution.

The source video is interlaced, and we’d like to maintain that on the compressed version. These video will be viewed primarily on computer monitors and other modern equipment. We’re exploring making some of it available on Youtube or Vimeo, as well as hoping to make the files available to documentary-makers, researchers, and the like. Should anyone license the footage, we reckon they’re better able to make decisions about de-interlacing than we are.

We’re also keeping lossless jpeg2000 versions of all the videos, so not everything is riding on these h.264 ones.

[Brendan Roney]

Thanks, Jeff. I had some run-ins with DV previously so that had crossed my mind. However from what I understand, h.264 uses multiples of 16–which 488 isn’t nor is 486–but it can handle in-between resolutions by including information about cropping in the file.

I tried taking a screen shot in QT of the h.264 file, and although the video claimed to be 720×488 the screen shot came out as 720×486. Is that that automatic cropping coming into play, or has some degree of distortion been introduced?

I’m doing this project for a museum, and would like to keep the digitized versions of the videos as close to the originals as possible.