Missing Timecode Transcoding MP4s

[MylesOSS]

Hi All,

I'm new to FFAStrans and trying to work my head around it.

We have a team that uploads proxy files (movs/mp4s) to our server in London from Alaska, and we want to see if FFAStrans can pick up these new files and transcode them to Avid MediaFiles BMX structure. We also want it so that the transcoded MXF files are accompanied by AAFs, and for the most part I've managed to get this to happen successfully.

I'm currently using the XDCAM-HD encoder to do quick experiments with, although ideally we need something that can go lower in res, as we usually transcode these files down to 10:1 in avid media composer, so i imagine we'll have to work up a custom ffmpeg command that suits us better, although i'm unsure how to get native Avid Media Files generated this way (any ideas?).

Workflow:

f1.jpg (49.56 KiB) Viewed 5494 times

The immediate issue I've spotted is the fact that there is an additional frame added to the duration of the transcoded clip, which doesn't seem like a big deal but it can cause issues for our conform process. The other problem is the timecode of the transcoded clip doesn't match that of the original when we link to it in avid (see screenshot of the avid bin below). Anyone know what could be causing this?

f3.jpg (21.67 KiB) Viewed 5494 times

This is a screenshot of my XDCAM-HD encoder settings. The "set start TC" is default to %s_start_tc% so i believe this is correct for using the original clip timecode right?

f2.jpg (65.19 KiB) Viewed 5494 times

Any help very much appreciated.

Thanks,
Myles.

[FranceBB]

HI and welcome to the forum.
First of all, you're right, the timecode variable set in the XDCAM node is correct, in the sense that %s_start_tc% will always return the timecode of the original file.
If it doesn't find it, then it will always revert to 00:00:00.00
Now, in your case, by linking the clip you get 11:47:37.11 while FFAStrans returns 00:28:17 which means that it has found a timecode in the original file, but it differs from the one AVID picks.
It is possible to have multiple timecodes in a single file, I've seen that a lot in some containers, however I've never seen that in MP4.
Are they delivering those files only or are they delivering a structure with .xml etc as well?
'cause AVID via the AMA Folder can find and interpret XML if they're found.
If they're sending the MP4 files only, can you share one with us so that we can confirm the multiple timecodes theory?
Feel free to upload it here in Samples: https://drive.google.com/drive/folders/ ... 1Baw8pjdAL

[MylesOSS]

Hi FranceBB,

Thanks for your response and appreciate any help you can give. I'm afraid as we're under contract and confidentiality agreements prevent us from sending out any footage (not my call). However, I can provide any other metadata you request. I can confirm that the MP4's do not come with any XML files. Happy to use any third party tool you recommend to extract the information you might have otherwise done yourself?

Will the following text output from MediaInfo help at all?

General
Complete name : C:\Engineers\XM_0102S03.MP4
Format : XAVC
Codec ID : XAVC (XAVC/mp42/iso2)
File size : 12.0 MiB
Duration : 26 s 880 ms
Overall bit rate mode : Variable
Overall bit rate : 3 749 kb/s
Encoded date : UTC 2021-04-26 11:48:48
Tagged date : UTC 2021-04-26 11:48:48

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Format settings, GOP : M=1, N=4
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 26 s 880 ms
Bit rate mode : Variable
Bit rate : 2 922 kb/s
Maximum bit rate : 9 999 kb/s
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.507
Stream size : 9.36 MiB (78%)
Encoded date : UTC 2021-04-26 11:48:48
Tagged date : UTC 2021-04-26 11:48:48
Color range : Full
Codec configuration box : avcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 26 s 880 ms
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 419 KiB (3%)
Encoded date : UTC 2021-04-26 11:48:48
Tagged date : UTC 2021-04-26 11:48:48

Other #1
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 26 s 880 ms
Time code of first frame : 11:47:37:11
Time code, striped : Yes
Encoded date : UTC 2021-04-26 11:48:48
Tagged date : UTC 2021-04-26 11:48:48

Other #2
Type : meta
Duration : 26 s 880 ms


Thanks.

[emcodem]

Hey Myles,
i fear in this case we really need a file sample. If you cannot share a whole file, it might be useful if you just share the first MB of such a file (let's hope the moov atom is at the start of file instead of at the end). If you don't know how to do that, open a commandline and do:

type "%INPUTFILE%" > "%INPUTFILE"_1mb.mp4

and hit ctrl+c after a second or such... if the output file is too big or too small just repeat

Thanks!
emcodem

[MylesOSS]

Hi emcodem,

This is OK to do. However, if I run that command in cmd as administrator I see Windows Media Player open up and then a 0kb file is produced. The command then ends immediately after running it.

Command being run:
XM_0102S03.mp4 > XM_0102S03_1mb.mp4

Thanks,
Myles.

[MylesOSS]

Hey, so i've tried to re-wrap / trim down to 5 secs in ffmpeg to produce a generic clip i can upload for you but it appears to be changing the source file in such a way that when i link to the new clip in avid it now reads the source timecode as the one that starts 00:28

Interestingly the output of the metadata section within ffmpeg after it's done the conversion shows the following:

Metadata:
major_brand : XAVC
minor_version : 16785407
compatible_brands: XAVCmp42iso2
creation_time : 2021-04-26T11:48:48.000000Z
timecode : 00:28:18:186
Duration: 00:00:26.88, start: 0.000000, bitrate: 3749 kb/s
Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc), 640x360 [SAR 1:1 DAR 16:9], 2922 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default)
Metadata:
creation_time : 2021-04-26T11:48:48.000000Z
handler_name : Video Media Handler
encoder : AVC Coding
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)
Metadata:
creation_time : 2021-04-26T11:48:48.000000Z
handler_name : Sound Media Handler
Stream #0:2(und): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2021-04-26T11:48:48.000000Z
handler_name : Time Code Media Handler
timecode : 00:28:18:186
Stream #0:3(und): Data: none (rtmd / 0x646D7472), 614 kb/s (default)
Metadata:
creation_time : 2021-04-26T11:48:48.000000Z
handler_name : Timed Metadata Media Handler
timecode : 11:47:37:11


As you suspected, we have more than one timecode here in this mp4 file (Stream #0:2 & Stream #0:3). If you still want a file uploaded is there alternate way i can trim down and preserve the contents of the original clip other than the first command you sent? I can't seem to get that one to work.

[emcodem]

Oh, sorry for the late response.
Nice findings. Of course it would still be interesting to have a sample, you can even upload the whole thing if you are allowed to, no prob.
Anyway, you just forgot the "type" in your command.

Code: Select all

type XM_0102S03.mp4 > XM_0102S03_1mb.mp4

But also you miss the full path to the file, so either you give both files the full path or you just cd into the folder where it is

[emcodem]

Maybe it works without a sample. So how you can Deal with this is to use $jsonget and %s_info_ffprobe% combination, we have an article on the Wiki for it.

https://ffastrans.com/wiki/doku.php?id= ... _functions

If you need help, we just need the ffprobe json from you. You can dump this by using a write Text processor and let it write %s_info_ffprobe% to a file and upload here

[MylesOSS]

That's great I will look into this. Thanks emcodem and francebb!