[小ネタ] AWS Elemental MediaLiveでタイムコードがソースに埋め込まれていない場合の挙動が変わっていました

Timecode configurationをEMBEDDEDに設定してソースにタイムコードが埋め込まれていない場合、従来はZEROBASEでタイムコードが初期化されていました。最新の挙動ではSYSTEMCLOCKでの初期化となっています。
清水俊也
2025.09.30
 はじめに清水です。ブロードキャストグレードのライブ動画処理サービスであるAWS Elemental MediaLiveでは、タイムコードを出力映像にメタデータとして含めたり、ビデオフレーム自体に書き込んだりすることが可能です。MediaLiveへ映像ソースを送信する機器側のタイムコードを利用するのがデフォルトの設定ですが、ゼロベースでの開始やUTC時刻を使用することもできます。
MediaLiveの入力ソースにタイムコードが埋め込まれていない場合、ゼロベースでMediaLiveのタイムコードが初期化される認識だったのですが、先日動作検証を行った際に、UTC時刻を使用する挙動となっていました。従来までの挙動含めて確認してみると、以前はたしかにゼロベースで初期化されていたものが、2022年のどこかのタイミングでUTC時刻で初期化されるように変更されていました。
 ソースにタイムコードを埋め込んでいないのに現在時刻が使われる!?まずはMediaLiveのタイムコード設定についてざっと振り返りつつ、挙動が変わった点を確認してみます。
MediaLiveのChannel内で出力タイムコードを初期化する方法として、映像ソースに埋め込まれたタイムコードを利用してMediaLiveの出力タイムコードを初期化するEMBEDDED、UTC時刻で初期化するSYSTEMCLOCK、そして00:00:00:00で初期化するZEROBASEDの3種が指定できます。マネジメントコンソールの設定箇所を確認すると、ChannelのGeneral settings、Timecode ConfigurationのSourceの項目になりますね。
MediaLiveへ映像ソースを送信する機器にタイムコードを挿入する機能があればEMBEDDEDに設定しておくことで、そのタイムコードをそのまま継続してMediaLiveの出力にも利用できます。また映像ソース送信機器にタイムコードを挿入する機能がない場合でも、SYSTEMCLOCKを設定することでMediaLive側で現在時刻をタイムコードとして付与、それをMediaLiveからの出力時に使用することができます。
筆者は検証用のMediaLiveへの映像ソース送信機器としてOBS Studioを使用することが多いです。とても多機能なOBS Studioなのですが、タイムコードを埋め込みRTMPなどで映像とともにメタデータとして送信する機能は（少なくとも標準では）実装されていない認識です。そのため、検証の際にはMediaLive側のTimecode ConfigurationでSYSTEMCLOCKを設定、タイムコードを焼き付けたりメタデータとして後続の処理に利用する、ということを行ってきました。
個人的にはこの Timecode ConfigurationでSYSTEMCLOCKを設定 というのがミソで、これを設定し忘れてしまうとデフォルトのEMBEDDEDとして処理されるもののソース側のタイムコードがないため実際にZEROBASEDとして扱われる、という挙動で動作を把握していました。ZEROBASEDとなると現在時刻と関係のないタイムコードとなってしまい、動作確認に不向きになったり、場合によっては後続の処理で不具合が生じてしまう、というわけですね。（例えばブログエントリ「Cross-region failover可能なライブストリーミング構成をMediaPackageのCMAF Ingestで試してみた！ | DevelopersIO」でも、Sourceの設定をSYSTEMCLOCKに指定し、という記載をしていました。）
さて、このOBS Studioの利用でタイムコード使うときには Timecode ConfigurationでSYSTEMCLOCKを設定 することを、先日ついうっかり忘れてしまいました。単純に出力映像に現在時刻を焼き付けて確認したかっただけだったのですが、これでは00:00:00:00からはじまった時刻の表示になってしまうな、とMediaLiveから出力された映像をみると、きちんと現在時刻になっていたのです。設定を忘れてしまったのになぜ？と、狐に包まれたような気持ちになりました。
 改めてソースにタイムコードが埋め込まれていない場合の現時点の動作を確認改めて、MediaLiveで入力映像にタイムコードが埋め込まれていない場合に、EMBEDDEDで初期化した際の出力タイムコードが現時点ではどうなっているのか、確認してみます。
 動作検証用のMediaLiveならびに関連リソースの作成まずはMediaLiveと、出力映像の確認用のリソースを作成します。今回はMediaLiveのWorkflow wizardを使ってリソースを作成しました。
MediaLiveのマネジメントコンソール、Workflow wizardのページの [Create workflow] ボタンから進みます。Channel classはSINGLE_PIPELINE、InputはRTMP_PUSH、出力はMediaPackageで720p30解像度のみ利用、という設定でworkflowを作成しました。
Workflow wizardで各リソースが作成できたら、MediaLiveの設定詳細を確認、また一部を変更しておきます。まずはGeneral settingsのTimecode Configurationの項目です。Sourceの設定としてデフォルトのEMBEDDEDになっていますね。今回はこのEMBEDDEDの状態でソースにタイムコードが埋め込まれていない状態の挙動を確認したいので、このまま進めます。
続いて同じくGeneral setings、Timecode Configurationの2つ下のChannel loggingの項目です。Log leverlとしてデフォルトでDISABLEDとなっています。今回、ソースにタイムコードが埋め込まれていない状態でどのような挙動となるかをログレベルでも確認してみたいので、最も詳細にログを出力するDEBUGに設定しました。
Output groupsについても設定を変更します。MediaPackage output gropuのOutput 1: emp_720p30、Stream settingsのVideo、Timecodeの項目を展開します。Timecode InsertionについてはデフォルトのDISABLEDからPIC_TIMING_SEIに変更しました。またTimecode Brun-in Settingsについてもデフォルトの空欄状態（Don't include）からTimiecode burninに変更、またFont SizeをLARGE_48、PositionをBOTTOM_CENTERとしました。
以上でMediaLive設定の確認ならびに設定変更は完了です。[Update channel]ボタンを押下したあと、ChannelをStartさせておきます。
 OBS Studioから映像を打ち上げて実際に挙動を確認今回はOBS Studioでメディアソースを用いBig Buck Bunnyの映像をループ再生しておきます。設定項目については配信設定以外、デフォルト状態としました。配信ではサービスとして[カスタム…]を選択、MediaLive InputのEndpoint情報を入力します。
MediaLiveがRunningの状態でOBS Studioから配信を開始、Workflow wizardで作成したMediaPackage HLS endpointからhls.js demoページ経由でMediaLiveの出力映像を確認します。
Big Buck Bunnyの映像の中央下にタイムコードが表示されています。シークバーと重なってしまいましたが、12:50:00;24と表示されていますね。これは動作検証を行っている時間のUTC時刻と一致しました。
最新のMediaLiveの挙動として、Timecode configurationがEMBEDDEDの状態でソースにタイムコードが埋め込まれていない状態でも、ゼロベースではなくUTC時刻がタイムコードとして利用されるようです。
念のため、MediaInfoでも確認してみました。HLS endpointからマニフェストファイルをたどり、MediaInfo CLIにセグメントファイルのURLを渡しました。MediaInfoの出力として、Time code of first frame                 : 12:53:54;00が確認でき、こちらも同様にUTC時刻がタイムコードとして利用されていることが確認できました。

					
			[ec2-user@ip-10-82-21-47 ~]$ curl https://15bcxxxxxxxxxxxx.mediapackage.ap-northeast-1.amazonaws.com/out/v1/0a0bxxxxxxxxxxxxxxxxxxxxxxxxxxxx/index.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=5390704,AVERAGE-BANDWIDTH=3441680,RESOLUTION=1280x720,FRAME-RATE=29.970,CODECS="avc1.64001F,mp4a.40.2"
index_1.m3u8
[ec2-user@ip-10-82-21-47 ~]$ curl https://15bcxxxxxxxxxxxx.mediapackage.ap-northeast-1.amazonaws.com/out/v1/0a0bxxxxxxxxxxxxxxxxxxxxxxxxxxxx/index_1.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:52
#EXTINF:6.006,
index_1_52.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_53.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_54.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_55.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_56.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_57.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_58.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_59.ts?m=xxxxxxxxxx
#EXTINF:6.006,
index_1_60.ts?m=xxxxxxxxxx
#EXTINF:2.002,
index_1_61.ts?m=xxxxxxxxxx
#EXTINF:2.002,
index_1_62.ts?m=xxxxxxxxxx
#EXTINF:2.002,
index_1_63.ts?m=xxxxxxxxxx
#EXT-X-ENDLIST
[ec2-user@ip-10-82-21-47 ~]$ mediainfo https://15bcxxxxxxxxxxxx.mediapackage.ap-northeast-1.amazonaws.com/out/v1/0a0bxxxxxxxxxxxxxxxxxxxxxxxxxxxx/index_1_52.ts
General
ID                                       : 1 (0x1)
Complete name                            : https://15bcxxxxxxxxxxxx.mediapackage.ap-northeast-1.amazonaws.com/out/v1/0a0bxxxxxxxxxxxxxxxxxxxxxxxxxxxx/index_1_52.ts
Format                                   : MPEG-TS
File size                                : 2.18 MiB
Duration                                 : 7 s 795 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 2 342 kb/s
Frame rate                               : 29.970 FPS

Video
ID                                       : 481 (0x1E1)
Menu ID                                  : 1 (0x1)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L3.1
Format settings                          : CABAC / 3 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 3 frames
Codec ID                                 : 27
Duration                                 : 6 s 6 ms
Bit rate mode                            : Variable
Maximum bit rate                         : 3 000 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 29.970 (30000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Time code of first frame                 : 12:53:54;00
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

Audio
ID                                       : 482 (0x1E2)
Menu ID                                  : 1 (0x1)
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Format version                           : Version 4
Muxing mode                              : ADTS
Codec ID                                 : 15-2
Duration                                 : 5 s 994 ms
Bit rate mode                            : Variable
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Delay relative to video                  : 17 ms

Menu
ID                                       : 480 (0x1E0)
Menu ID                                  : 1 (0x1)
Format                                   : AVC / AAC
Duration                                 : 7 s 774 ms
List                                     : 481 (0x1E1) (AVC) / 482 (0x1E2) (AAC)

[ec2-user@ip-10-82-21-47 ~]$

		
		
 MediaLiveのログからもUTC時刻で初期化されることを確認映像に埋め込まれたタイムコード以外に、MediaLiveのログからもこの挙動を確認してみましょう。CloudWatch LogsでElementalMediaLiveのarn_aws_medialive_ap-northeast-1_[AWSアカウントID]_channel_[Channel ID]_0といった名称のロググループを参照します。4つほどタイムコードに関するログ出力が確認できました。
まず1つ目です。タイムコードが[--:--:--:--]ということで、入力ソース側で埋め込まれていない、ということがわかります。

					
			{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:1234567",
    "encoder_pipeline": 0,
    "logger_name": "",
    "message": "Video stream [0]: id [1] program [] codec [H264] res [1280x720] color [4:2:0] framerate [30/1] PAR[1:1] scan type[unknown], [2500]kbps, Initial timecode [--:--:--:--]",
    "severity": "I",
    "timestamp": "2025-09-30T12:48:41.615787"
}

		
		
続いて2つ目のログ出力です。こちらは正に入力タイムコードが存在していない、というログですね。またタイムコードがないことから、パイプラインロッキングが利用できないことが記載されています。

					
			{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:1234567",
    "encoder_pipeline": 0,
    "logger_name": "ve",
    "message": "Input timecodes are not present; pipeline locking unavailable",
    "severity": "I",
    "timestamp": "2025-09-30T12:48:41.652088"
}

		
		
そして3つ目のログ出力です、こちらが今回の動作の肝の部分となります。Timecode source設定がEMBEDDEDとはなっているが、ソースに埋め込まれたタイムコードが利用できないので、 SYSTEMCLOCKにフォールバックする という記載があります。

					
			{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:1234567",
    "encoder_pipeline": 0,
    "logger_name": "ve",
    "message": "Encoder [1] configured with a timecode source of EMBEDDED, but no embedded timecodes are available. Falling back to SYSTEMCLOCK timecode [12:48:41;22].",
    "severity": "I",
    "timestamp": "2025-09-30T12:48:42.529178"
}

		
		
4つ目のログ出力については、上記の通りUTC時刻で初期化されたタイムコードを使用している旨が記載されていました。

					
			{
    "channel_arn": "arn:aws:medialive:ap-northeast-1:123456789012:channel:1234567",
    "encoder_pipeline": 0,
    "logger_name": "",
    "message": "{\"as_run_type\":\"initial_timecode\",\"date\":\"2025-9-30 (tz=0)\",\"destinations\":3,\"input_id\":\"timecode-test\",\"output_name\":\"emp_720p30\",\"timecode\":\"12:48:41;22\",\"timestamp\":{\"nanoseconds\":\"568514125\",\"seconds\":\"1759236523\"}}",
    "severity": "I",
    "timestamp": "2025-09-30T12:48:43.568526"
}

		
		
 ドキュメントなどの記載を確認してみる ~ いつから挙動が変更されていたのか!?MediaLive ChannelのTimecode Configuration、Sourceの設定がEMBEDDEDとなっていてソース側にタイムコードが埋め込まれていない場合でも、SYSTEMCLOCKタイムコードにフォールバックすることが最新のMediaLiveの動作仕様であることが確認できました。この設定について、ドキュメントなどではどういった記載となっているのでしょうか、確認してみたいと思います。
まずはMediaLiveのマネジメントコンソール、Infoをクリックして出現する情報欄です。

こちらは以下のように、ソースにタイムコードが埋め込まれていない場合は Start at 0 （ZEROBASED）にフォールバックする旨が記載されています。これは従来の挙動ですね。
-Embedded (embedded): Initialize the output timecode with timecode from the the source. If no embedded timecode is detected in the source, the system falls back to using "Start at 0" (zerobased).
なお、こちらはMediaLiveのAPI Referenceでも現段階で同様の記載があることを確認できます。


引用元: Channels - AWS Elemental MediaLive API Reference
続いてMediaLive User Guideについても確認してみます。こちらにはしっかりと、If the input does not contain a timecode, MediaLive uses UTC. という記載がありました。こちらが最新の挙動となっている、という認識です。


引用元: About timecodes and timestamps - MediaLive
このMediaLiveのUser Guideの更新タイミングについても確認してみましょう。Document historyを確認してもそれらしい記載がなかったので、Wayback Machineを使って確認します。
上記のスクリーンショットで示したページについては2024/08/25のものが最古であり、更新タイミングはわかりませんでした。しかし、その1段上のページ「Working with timecodes and timestamps - MediaLive」で確認してみると、2022/01/22の段階ではZEROBASEDにフォールバックしていたことが確認できます。


引用元: Timecode configuration - AWS Elemental MediaLive （Wayback Machineから2022/01/22のアーカイブ）
そして2022/10/05の時点ではSYSTEMCLOCKにフォールバックする旨の記載へと更新されていました。User Guideによると2022/01から2022/10のどこかのタイミングで、従来までのゼロベースへのフォールバックからUTC時刻へのフォールバックへ変更があったようです。


引用元: Timecode configuration - AWS Elemental MediaLive （Wayback Machineから2022/10/05のアーカイブ
 まとめAWS Elemental MediaLiveで埋め込みタイムコードを使用する設定とした際に、入力ソースにタイムコードが埋め込まれていなかったときの挙動が変わっていた点を確認しました。従来まではゼロベースのタイムコード（ZEROBASED）にフォールバックしていましたが、現在はUTC時刻（SYSTEMCLOCK）にフォールバックするようになっています。MediaLive User Guideの変更をだどってみると、2022/01/22から2022/10/05のどこかで変更があったようです。
個人的にはTimecode configurationをSYSTEMCLOCKに変更することを忘れてしまったことが稀にあったので、今後は気にしなくてもいいかなと安堵しています。しかしその反面、どこを基準としたタイムコードを使っているか、という点が少しわかりにくくなったかな、という気もしています。
従来までのソースにタイムコードが埋め込まれていない挙動であれば、MediaLive出力のタイムコードが明らかにおかしな時刻で、ソース側でタイムコードを載せ忘れているということに気がつく、ということができたかもしれません。
対して最新の挙動ではMediaLiveでUTC時刻ににフォールバックするため、本当は入力ソース、MediaLiveへ送信する段階でのタイムコードを使いたかったのが、埋め込み忘れでMediaLiveで付与して微妙なズレが生じてしまう、といったケースも起こりうるのかなと思いました。この対策としては、そもそもの入力ソース側のタイムコード設定をしっかり確認することと、また本ブログエントリで確認してきたとおりMediaLiveのログでタイムコード設定をフォールバックしているという情報が出力されるので、これをうまく活用することが挙げられます。