Problems playing and converting unfamiliar codec

[robjv1]

Having a bit of trouble working with some files in a format I'm not familiar with. I paid a company to convert some old UMATIC tapes for me and asked if they would convert them to some kind of lossless or uncompressed format, in an SD resolution with the interlacing left intact so that I could do further processing on them. My intention is to eventually convert them to MPEG4/MPEG2 files. They said they could do them as 10-bit uncompressed interlaced files in standard definition and I agreed.

The files they gave back to me are .mov files, so I assume these were done on some kind of Mac workstation. While trying to play the files in VLC, or taking a look at them in VirtualDub2, I consistently get an intermittent video stutter, where it appears either the video just jumps ahead a few frames, or the video freezes and I get about a 23 frame still image, before it seems to jump ahead in the future (probably 23 frames in the future I'm guessing). Audio is continuous and has no issues. The freezes are always in the same places. I also notice in VirtualDub2, the frames that are frozen display [+] in the status bar instead if [K] for keyframe. I'm not familiar with the [+] notation. I suspect there is something wrong with the capture but before I wanted to make sure there's not another potential explanation for why it might be happening before I contact them. Also I want to be able to intelligently communicate to them how to fix the issue -- as I'm a bit out of my comfort zone when it comes to UMATIC tapes and some of the particulars of these codecs.

Here is the MediaInfo output for one of the files. The one thing that stands out to me is the frame rate being listed as variable.

Please let me know if I can provide any other info to help -- thanks in advance!


General
Complete name : J:\File001.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt 0000.02 (qt )
File size : 4.62 GiB
Duration : 3 min 10 s
Overall bit rate mode : Constant
Overall bit rate : 208 Mb/s
Encoded date : UTC 2022-09-21 14:53:16
Tagged date : UTC 2022-09-21 14:53:16
Writing application : Lavf58.76.100

Video
ID : 1
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 3 min 10 s
Bit rate mode : Constant
Bit rate : 206 Mb/s
Width : 720 pixels
Clean aperture width : 720 pixels
Height : 486 pixels
Clean aperture height : 486 pixels
Display aspect ratio : 4:3
Clean aperture display aspect ratio : 4:3
Frame rate mode : Variable
Frame rate : 27.572 FPS
Minimum frame rate : 0.999 FPS
Maximum frame rate : 29.970 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Interlaced
Scan type, store method : Interleaved fields
Scan order : Bottom Field First
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 4.57 GiB (99%)
Language : English
Encoded date : UTC 2022-09-21 14:53:16
Tagged date : UTC 2022-09-21 14:53:16
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Audio
ID : 2
Format : PCM
Format settings : Little / Signed
Codec ID : in24
Duration : 3 min 10 s
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 52.4 MiB (1%)
Language : English
Default : Yes
Alternate group : 1
Encoded date : UTC 2022-09-21 14:53:16
Tagged date : UTC 2022-09-21 14:53:16

[Alwyn]

Remind me not to use that outfit!

[Cornucopia]

Somebody there doesn't know what they're doing. You can tell them that a post production veteran said so.

Umatic tapes can ONLY be NTSC (29.97FPS), PAL or SECAM (25FPS), so what they gave you should have been constant framerate. Likely 29.97 in your case. I am a little surprised that aja actually even allows vfr.

And the aja codec is a Mac/QuickTime only codec, so it is not easily transferrable to other platforms (Windows, Linux).
Not to mention that some of those aja codecs require hardware assistance, which would mean that they aren't decodable without similar proprietary (aja brand only) hardware (bmd and matrox have had some similar-acting types for their brands). I believe there are some aja codecs that don't require hardware assistance, but in those cases, a proper production house should have given you a copy of those (at LEAST the decoders) to assist you in your subsequent use. They should have REALLY given you a common cross-platform format.

You might, using an (older?) Mac, be able to convert to something more cross-platform, but it is possible with that VFR that irreparable damage has already been done.

If I were you, I would take them back and ask them to do it right (with the aforementioned constraints in mind), or get your money back.


Scott

[robjv1]

Thank you so much for your detailed and thoughtful response. I suspected that the variable frame rate is what did it in and I was surprised to get them in (what feels like at least ) a proprietary codec.

I'll pass along the information and see if they can accommodate me. If they are unable to, do you (or anybody) know of any reputable places to have this work done?

[jagabo]

V210 is uncompressed 10 bit UYVY: https://wiki.multimedia.cx/index.php/V210

It's probably not really variable frame rate. Many programs store 29.97 fps video in MOV (or MP4) marked as VFR even though it's essentially CFR.

I'm pretty sure I've used ffmpeg to convert V210 to something more common for Windows (Lagarth AVI?) . VirtualDub2 might be able to open the files via its ffmpeg input module. Players like VLC and MPCHC should be able to play it.

If you can provide a small sample I can give more explicit instructions.

[robjv1]

V210 is uncompressed 10 bit UYVY: https://wiki.multimedia.cx/index.php/V210

It's probably not really variable frame rate. Many programs store 29.97 fps video in MOV (or MP4) marked as VFR even though it's essentially CFR.

I'm pretty sure I've used ffmpeg to convert V210 to something more common for Windows (Lagarth AVI?) . VirtualDub2 might be able to open the files via its ffmpeg input module. Players like VLC and MPCHC should be able to play it.

If you can provide a small sample I can give more explicit instructions.

Awesome -- here's a short clip. Dropped the original video into VirtualDub2, cut it down to a portion that displays two problem areas and did a direct stream AVI copy of that portion. Problems appear for me at Frame 57 and Frame 140.

https://www.dropbox.com/s/idlubsdadwhnef3/TestClip.avi?dl=1

Just as an FYI the original videos are able to play on my computer in VLC and are able to be opened in VDub2. Both display issues -- only difference is in VDub2 it usually it appears as a jump ahead when you hit a problem frame (such as in the clip above), where in VLC it seems like it pauses for a few moments, before jumping ahead.

[Cornucopia]

CFR appearing as VFR is a different beast than true VFR.
With the former, you might see min fr as 28.45 avg 29.97 max 30.99, or similar, and has to do with rounding when certain timebase reference is used. But true vfr often reads something like min 6fps, avg 29.97, max 40, the variability is clear.


Scott

[jagabo]

Muxing int AVI removes the timecodes and other metadata. Note that AVI doesn't support variable frame rates.

You need to provide the original MOV file. Or at least a segment remuxed into a new MOV container.

ffmpeg should work with something like:

ffmpeg  -i source.mov -ss 00:00:00.000 -to 00:00:05.000 -c copy remux.mov

The -ss is the start time, -to is the end time of the segment to be extracted. That example will remux the first 5 seconds to a new file. Of course, pick a good 5 seconds -- one with moderate motion, a clear picture, and well lit. And something that shows the problems you are seeing.

[robjv1]

Thank you -- here you go. Frame 53 -> 54 is jump one, frame 136 --> 137 is jump two.

https://www.dropbox.com/s/0h11552kwua4q1m/remux.mov?dl=1

[jagabo]

There are severe problems with the capture. Players like VLC and MPCHC are playing the video properly -- ie, they're playing it exactly as the timestamps indicate. The durations of frames 53 and 136 are much longer than the others (834 ms and 968 ms, vs 33 ms for the others), indicating a bunch of missing frames at each of those locations. But even elsewhere in the video only about half the fields are unique, with an irregular duplicate pattern.

[robjv1]

Thanks again for taking a look at that. They got back to me yesterday and have stated they are committed to making it right. I mentioned the variable bitrate being a potential issue and a desire for a cross-platform codec, is there anything else you think I should mention? The duplicate frame pattern concerns me for sure.

I wonder if I'd have more luck with this pushing them towards an MPEG-2 workflow -- just having them capture it at like 25 Mbit/s or something to give me some overhead to do my filtering and to keep them in a realm they may have more experience working in (I assume most of their business is probably VHS to DVD type conversions). Who knows though.

[jagabo]

Variable bitrate isn't a problem. The massive frame and field drops is the problem. 24 missing frames at frames 53, 28 missing frames at frame 136, and missing ~half the fields all over indicate something is very wrong. Missing half the frames could indicate that the clip has an underling 30p frame rate but you would still capture as 30i.

I would avoid MPEG2. Even at high bitrates It will generate DCT ringing and blocking artifacts, and lose a little detail. A lossless (Lagarith?) or near lossless codec (Prores?) would be a better choice.

[Cornucopia]

If they are dropping frames it sounds like they need to add a TBC (probably frame type) in line, but because they are capturing at a higher bitrate, they also need to make sure their computer system is able to keep up (min drive write speed well above bitrate of the codec).

You had asked for lossless. Because of the quality of VHS, you could lower your requirements a bit there, but not too much.
Since they are using a Mac system, AFAIK, there are almost NONE that allow capture to MPEG2. I might recommend they capture using ProRes422, which at 720x486@60i is 42Mbps. Quite a drop from the 207 of the Aja codec, and visually nearly the same. Plus, while not "officially" licensed by Apple, the cross-platform implementation in ffmpeg for prores is quite good. At 42Mbps, the computer requirements are much relaxed.


Scott

[robjv1]

Thanks for the suggestions and info. Yeah my computer is definitely up to the task of processing and keeping up with it. I would be shocked if they weren't capturing with a TBC and such as they seem like a reputable place that gets a lot of work. I'm hoping they'll be able to accommodate me but we'll see how it goes.