486i videos encoded with h.264 are coming out as 488i

[Jeff Pulera]

Proper D1 NTSC video is 720×486, however in the digital world, the DV video standard is used at 720×480. When compressing digital files, video gets encoded in blocks (matrixes)of a certain size, often divisible by 8, so odd sizes may not be possible to encode. My guess is that is why the 486 turns to 488, since 480 plus 8 = 488.

Might be better off exporting as 720×480 and just cropping a few lines off perhaps?

Thanks

Jeff Pulera
Safe Harbor Computers

[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.

[Jeff Pulera]

Really not a strong area for me and I will defer to someone with more experience.

Just thought of something – it will be helpful if you can post a screen shot of the export settings please. Also, are you encoding as interlaced or progressive, and what is the playback (viewing) setup to be used at the museum?

Thanks

Jeff Pulera
Safe Harbor Computers

[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.

[Jeff Pulera]

Any file intended for computer/online viewing should typically be exported as PROGRESSIVE or the viewer will see interlacing artifacts on motion.

Thanks

Jeff Pulera
Safe Harbor Computers

[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?

[Jeff Pulera]

Hi Brendan,

It really sounds like you could use TWO versions of the videos – one for archiving, and a second for delivery/viewing. If capturing tapes for archival purposes, H.264 is lossy. Personally, I’d use something like an .avi (PC) or .mov (Mac) for archiving, with intra-frame compression, 4:2:2 color, and higher bitrate. Those clips will be interlaced. Then from those “master” clips, export the H.264 progressive clips for the museum display, online viewing, etc.

We must keep in mind that the average viewer doesn’t know what interlace artifacts are, or how to fix them in the viewing software. They try to view the H.264 clip on their computer, and all they know is “it doesn’t look right”. So I stand by the idea that clips for online and/or computer viewing ought to be delivered as deinterlaced for the best viewing experience for the end user.

Good luck with this

Jeff Pulera
Safe Harbor Computers

[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.