DEV Community: Shige Fukushima

Lenovo TrackPoint Keyboard のチルトスタンドが折れた

Shige Fukushima — Fri, 28 Apr 2023 16:51:46 +0000

キーボードのチルトスタンド (高さ調整用の脚) が折れた

現在、デスクトップ PC 用に Lenovo TrackPoint Keyboard II を使っています。

購入してから約3年になりますが、結構使い勝手がよくお気に入りのキーボードです。

Lenovo ThinkPad 特有のトラックポイントがついている (キーボード・マウスが1接続で利用できる)
USB接続と BlueTooth 接続の両方に対応
電池不要で UCB-C で充電が可能

トラックポイントはキーボードのホームポジションから手を動かさずにマウス操作ができるので、
開発者向きと言えるのではないかと思います。

そのキーボードですが、先日使っていると、高さ調整用の脚 (チルトスタンド) が折れた！

他のユーザーも同様の状況に遭遇している

インターネットを検索すると、ちらほらと同様の事例が。
こちらが遭遇したのは破損事例7と同じような状況で、キーボードにくっついたままの状態で脚が折れている状態でした。

事例の中にはサポート修理や部品販売は行っていないとの情報もあり、
このキーボードを使い続けたいので、どうやって直すかが悩みどころでした。

3Dプリンターでプリントアウトしたチルトスタンド

壊れた部品をプラリペアで修理するという選択肢もありますが、また壊れそうということでやめました。

レノボの正規部品の販売を確認してみるという選択肢もありましたが、部品販売があっても、
結局また壊れてしまうかもしれない部品を使うのも考えものだったので、他の選択肢を検討してみることにしました。

皆さんの記事を見ていると、3D プリンターでプリントアウトしたチルトスタンドを使っている事例もあり、
こちらの方が正規品よりも丈夫との情報もあり、試してみる価値あり、との判断をしました。

Thingiverse という人気サイトで、
3D　プリンターでプリントアウトができる TrackPoint Keyboard のチルトスタンドが公開されていました。
3D プリンターを持っている方は試してみるとよいでしょう。

これを機に 3D プリンターの購入も考えましたが、販売品もあるとのことで、販売品を探しました。
上記のファイルを印刷したものが eBay や Etsy で出品されていました。

他にも、メルカリやラクマでも同様の 3D プリンター品が出品されていました。

左右ペアでだいたい 500～1000 円程度で出品されているようです。

出品されているものを買ってみた

早速、出品されている3Dプリンター品を買ってみて、壊れたものの代わりに取り付けてみました。

届いた品は、
ピッタリとはまるものではなかったですが、ニッパーとヤスリで少し形を整えてとりつけてみるとピッタリをはまりました。

正規品はゴム素材のソックスで滑り止めが付いているので少し心配はありましたが、
しばらく利用してみて、あまり気にならない感じです。

これでキーボードのチルトスタンドも元に戻り、
気に入ったキーボードを使い続けることができそうです。

Hyper-V ホストのネットワークパフォーマンスの改善

Shige Fukushima — Thu, 27 Apr 2023 17:38:10 +0000

はじめに

Windows 11 で Hyper-V を有効にした際に、仮想マシンをホストコンピューターが接続しているローカルネットワークに直接接続したい場合があります。例えば、複数の物理コンピューターがある場合に、ある物理コンピューターにホストした仮想マシンと物理コンピューターとの間で同じローカルネットワークのセグメントで直接通信させたい場合です。

Hyper-V の仮想スイッチマネージャーから [外部] ネットワークを作成すると、
物理ネットワークインターフェース (WiFi またはイーサネット) にブリッジネットワークが構成されます。
仮想マシンの仮想 NIC を作成した [外部] ネットワークに接続することで、仮想マシンをローカルネットワークに接続することができるようになります。

この際、Hyper-V ホストにも仮想 NIC が作成され、同じ [外部] の仮想スイッチに接続されるよう構成されますが、
Hyper-V ホストからの外部ネットワークへのアップロードのネットワーク速度が極端に低下する場合があります。

この記事では、ネットワークパフォーマンスを改善する方法を紹介します。

どのようなパフォーマンスの問題があったのか？

Hyper-V ホストに [外部] ネットワークの仮想スイッチを作成した後、
アップロードのネットワーク通信が極端に遅い、という現象が発生しました。

Network Speet Test という無料の Windows ストアアプリをインストールして試したところ、以下のような結果でした。

ダウンロード (下り) は約 120 Mbps の速度が出ているのですが、アップロード (上り) はたった 0.5Mbps 程度しか出ないという状況です。

明らかにおかしいと思われる様子なので、調べてみました。

Hyper-V を有効にする前に測定したネットワーク速度や同じ LAN に接続した他のデバイスからの測定結果とも異なりました。

ネットワークアーキテクチャの理解

具体的な問題解決方法の前に、Hyper-V ホストに [外部] ネットワークの仮想スイッチを作成すると、どのようなネットワーク構成になるのか？

ネットワーク構成は以下のような図になります。

Hyper-V ホスト OS からのネットワークパケットは、仮想 NIC とネットワークブリッジの両方を経由して、物理 NIC から外部へ送受信されます。

[コントロールパネル] -> [ネットワークとインターネット] -> [ネットワークと共有センター] -> 左サイドのメニューの [アダプター設定の変更] をクリックすると、ネットワークインターフェースの一覧が表示されます。

"vEthernet ([仮想スイッチの名前])" という名前のネットワーク接続の項目 (デバイス名が "Hyper-V Ethernet Adapter #[X]") が、ホスト OS に接続された仮想 NIC になります。

注: [X] には連番の数字が割り当てられます

また、ネットワークブリッジは、"Microsoft Network Adapter Multiplexor Driver" というデバイス名のネットワーク接続の項目が表示されています。

Hyper-V ホスト OS から外部への接続は、この2つのネットワークを経由して行われることになります。

問題の解決方法: LSO の無効化

様々な問題の原因が考えられますが、仮想ネットワークアダプター (ソフトウェア) でハードウェアの最適化機能があやしいのではないかと考え、アップロード (ネットワーク送信) に関するハードウェア最適化機能に目を付けます。

ネットワークのハードウェア最適化機能は、マイクロソフトのドキュメントによい記事 (「ハードウェアのみ (Hardware-Only) の機能とテクノロジ」があります。こちらを参考ください。

以下の機能があやしそうです。

Large Send Offload (LSO)

LSO を使用すると、アプリケーションは大量のデータブロックを NIC に渡すことができ、NIC はデータをネットワークの最大転送単位 (MTU) 内に収まるパケットに分割します。

ということで、デバイスマネージャーで仮想 NIC とネットワークブリッジのデバイス名のプロパティを確認します。[高度な設定] または [Advanced] タブを確認すると、詳細な機能のパラメーターが確認できます。

以下の Large Send Offload (LSO) 関連のパラメーターが、どちらのデバイスでも IPv4/IPv6 の両方で 有効 (Enabled) となっていました。

Large Send Offload Version 2 (IPv4)
Large Send Offload Version 2 (IPv6)

これを 無効 (Disabled) に変更します。

LSO 無効化後のネットワーク速度の確認

LSOv2 の設定変更後、再度、Network Speet Test でネットワーク速度を測定してみます。

測定の結果、アップロード (上り) の速度が約 30 Mbps と改善されました。
この結果は、以前に測定した結果と大きな差異もなく、設定変更により正しく改善されたように見えます。

インターネットで検索して得られた同じような現象の事例に対するアドバイスとも同じ結果になっています。

最後に

この記事では、Hyper-V 導入後に実際に遭遇したネットワークのパフォーマンス問題と解決策を紹介しました。

もし今回のような問題が発生した場合、ダウンロードの問題かアップロードの問題かを識別すること、Hyper-V を有効にした場合と無効にした場合の比較、仮説に基づく設定変更の前後の比較など、問題の切り分けを行うことが重要です。

問題の原因らしい箇所を想定を見つけて、他に同じような現象になっている事例がないかもインターネットで確認してみると、より確証が得られるかもしれません。

Ubuntu VM のセキュアブートの有効化

Shige Fukushima — Mon, 24 Apr 2023 14:29:13 +0000

はじめに

この記事では、記事: Ubuntu VM の移行 (VMware から Hyper-V へ)
で説明した以下の移行手順のステップ 4 について説明します。

VMDK 形式の仮想ディスクを VHD/VHDX 形式への変換
新しい仮想マシンを作成 (変換した仮想ディスクをアタッチする)
open-vm-tools のアンインストール
(オプション) 第2世代 Hyper-V 仮想マシン用の仮想ディスクへ変換
(オプション) Secure Boot の有効化
Hyper-V 統合サービスのインストール

セキュアブートの有効化

第 2 世代 Hyper-V 仮想マシンの Ubuntu Linux でセキュアブートを有効にするには、
セキュアブートに対応したカーネルと Grub ブートローダーをインストールする必要があります。

EFIブート対応済みの仮想マシンで起動して、以下の手順を実行します。

1) Grub EFI パッケージの取得

以下のコマンドを実行し、Grub EFI パッケージをネットワーク経由でダウンロードしインストールします。

VMware 仮想マシンから移行した場合、ネットワーク接続が可能となるように構成変更するのを忘れないでください。

sudo apt update
sudo apt install grub-efi-amd64 grub-efi-amd64-signed shim-signed -y

2) Grub EFI のインストール

~~以下のコマンドを実行し、起動ディスクに Grub EFI をインストールします。~~

[更新:2023/03/25]

Grub EFI パッケージのインストーラーにより、
自動的に Grub ブートローダーの更新が実行されるため、以下のコマンドの実行は不要です。

sudo grub-install --target=x86_64-efi --uefi-secure-boot /dev/sda
sudo grub-install --recheck --uefi-secure-boot /dev/sda
sudo update-grub2

3) セキュアブートの有効化

セキュアブート対応の Grub EFI ブートローダーのインストールが完了したら、
ライブサーバーをシャットダウンして、仮想マシンの設定を変更します。

仮想マシンの設定から、[セキュリティ] -> [セキュアブートを有効にする]　のチェックボックスを有効にし、
テンプレートに [Microsoft UEFI 証明機関] を選択します。

また、仮想マシンの設定の[ファームウェア]の項目で
grubx64.efi の代わりに shimx64.efi ファイルがブートローダーとして設定されていることを確認します。

正常に起動しない場合

bad shim signature というメッセージが表示される場合、kernel が最新でないケースが考えられます。

以下のコマンドを実行して、kernel を含む更新を最新の状態にアップグレードすると正常に起動するでしょう。

apt upgrade -y

セキュアブートが有効になっているかどうかの確認方法

以下のコマンドを実行して、セキュアブートが有効になっているかどうかを確認できます。

sudo dmesg | grep secureboot

"Secure boot enabled" というログが表示されていれば、セキュアブートが有効になっています。

最後に

この記事では、第 2 世代の Hyper-V 仮想マシンで Ubuntu Linux のセキュアブートを有効にする方法を説明しました。

Ubuntu Linux 上のサービスでセキュアブートを有効にすると、署名のないドライバーなどを使うことができなくなります。
セキュアな環境を構築できる一方で、セキュリティの考慮がないドライバーなどの利用の際に思わぬ問題に遭遇する場合もあります。
その際には、セキュアブートを無効にして動作を確認することで、問題の切り分けができます。

Ubuntu Linux 起動ディスクを BIOS ブートから EFI ブートへ変換

Shige Fukushima — Mon, 24 Apr 2023 14:28:51 +0000

はじめに

この記事では、記事: Ubuntu VM の移行 (VMware から Hyper-V へ)
で説明した以下の移行手順のステップ 4 について説明します。

VMDK 形式の仮想ディスクを VHD/VHDX 形式への変換
新しい仮想マシンを作成 (変換した仮想ディスクをアタッチする)
open-vm-tools のアンインストール
(オプション) 第2世代 Hyper-V 仮想マシン用の仮想ディスクへ変換
(オプション) Secure Boot の有効化
Hyper-V 統合サービスのインストール

Ubuntu Linux 起動ディスクを BIOS ブートから EFI ブートへ変換

第 2 世代 Hyper-V 仮想マシンで Ubuntu Linux を起動するには、
Ubuntu Linux の起動ディスクを BIOS ブートから EFI ブートへ変更する必要があります。

起動ディスクを EFI ブートに変更するには、Ubuntu インストーラーメディア (ライブサーバー) を使って以下の手順で行います。

新しい第2世代 Hyper-V 仮想マシンを作成する
パーティションのサイズの縮小
EFI パーティションの作成 (EFI パーティションはディスクの最後尾に準備)
Grub EFI のインストール
/etc/fstab の編集

インストーラーメディアはこちらのサイトからダウンロードします

ステップ 1: 新しい第 2 世代 Hyper-V 仮想マシンの作成

この移行作業は EFI ブート対応の仮想マシンで実行する必要があるため、第 2 世代 Hyper-V の新しい仮想マシンを作成する。
仮想マシンを作成したら、仮想マシンの設定から、[セキュリティ] -> [セキュアブートを有効にする]　のチェックボックスを外します。

仮想マシンの設定の [SCSI コントローラー] から [DVD Drive] を追加し、
ダウンロード済みの Ubuntu Server インストーラーメディアをイメージファイルに設定します。

また、仮想マシンの設定の [ファームウェア] では、[DVD Drive] からの起動を優先するよう、
一番上のエントリとなるように設定します。

インストーラーが起動したら、右上に表示された [ Help ] を選択し、Enter shell を選択して、
シェルコンソールを起動します。

ライブサーバーは外部から SSH でリモートアクセスすることも可能です。

[ Help ] -> Help on SSH access でリモートアクセスのためのユーザー名とパスワードを確認することができます。

ステップ 2: パーティションのサイズの縮小

EFI パーティションを確保するために、パーティションのサイズを縮小します。

EFI パーティションは 2 GB の容量を確保することを目標とします。

ステップ 2-1: パーティションの確認

まず、最初に、現在のパーティションと使用状況を以下のコマンドで確認します。

lsblk /dev/sda && pvs && vgs && lvs

コマンドの出力結果は以下の通りです。

NAME                      MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda                         8:0    0  32G  0 disk
|-sda1                      8:1    0   1M  0 part
|-sda2                      8:2    0   2G  0 part
`-sda3                      8:3    0  30G  0 part
  `-ubuntu--vg-ubuntu--lv 253:0    0  15G  0 lvm

  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda3  ubuntu-vg lvm2 a--  <30.00g 15.00g

  VG        #PV #LV #SN Attr   VSize   VFree
  ubuntu-vg   1   1   0 wz--n- <30.00g 15.00g

  LV        VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ubuntu-lv ubuntu-vg -wi-a----- <15.00g

パーティション名	説明	サイズ
sda1	BIOS ブート用のパーティション	1 MB
sda2	/boot (ブートローダー用) パーティション	2 GB
sda3	システム (root) パーティションを含む論理ボリュームを格納したパーティション	30 GB
ubuntu--vg-ubuntu--lv	論理ボリューム	15 GB 使用中

物理ボリュームのボリュームグループ (ubuntu-vg) は、パーティションサイズ全体に割り当てられていて、
ボリュームグループ内の論理ボリューム (ubuntu-lv) は現在 15 GB 使用中です。

この例では、ボリュームグループに空きがあるため、論理ボリュームのサイズを変更する必要はありません。

ステップ 2-2: 論理ボリュームのサイズを縮小する

ここで取り上げた例では、論理ボリュームのサイズの変更をする必要はありませんが、
論理ボリュームのサイズを変更する方法を説明します。

1) 空き容量の確認

まず、論理ボリューム内の空き容量を確認するために、以下のコマンドを実行します。

mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt
df /mnt
umount /mnt

15 GB 中の 42% 使用中となっており、論理ボリュームのサイズを縮小することができます。

Filesystem                        1K-blocks    Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv  15371208 6115404   8453196  42% /mnt

2) ファイルシステムのエラーチェック

論理ボリュームのサイズを縮小する前に、ファイルシステムのエラーチェックを行います。

e2fsck -f -v /dev/mapper/ubuntu--vg-ubuntu--lv

3) ファイルシステムのサイズの縮小

次に、ファイルシステムのサイズを縮小します。

resize2fs -p /dev/mapper/ubuntu--vg-ubuntu--lv 13G

4) 論理ボリュームのサイズの縮小

最後に、論理ボリュームのサイズを縮小するために、以下のコマンドを実行します。
この例では、2 GB のサイズを縮小 (13GB) します。

lvresize -L 13G /dev/ubuntu-vg/ubuntu-lv && lvs

コマンドの出力結果は以下の通りとなり、15 GB から 2 GB 縮小し、13 GB となりました。

  WARNING: Reducing active logical volume to <13.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce ubuntu-vg/ubuntu-lv? [y/n]: y
  Size of logical volume ubuntu-vg/ubuntu-lv changed from <15.00 GiB (3839 extents) to <13.00 GiB (3327 extents).
  Logical volume ubuntu-vg/ubuntu-lv successfully resized.

  LV        VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ubuntu-lv ubuntu-vg -wi-a----- <13.00g

再度、ファイルシステムのチェックを行い、問題がないか確認します。

e2fsck -f -v /dev/mapper/ubuntu--vg-ubuntu--lv

ステップ 2-3: 物理ボリュームのサイズを縮小する

以下のコマンドを実行して、物理ボリュームの使用状況を再度確認します。

pvs

コマンドの出力結果は以下の通りで、17 GB の空き状況となっています。

  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda3  ubuntu-vg lvm2 a--  <30.00g 17.00g

次に、物理ボリュームのサイズを縮小するために、以下のコマンドを実行します。
この例では、元の 30 GB のサイズを 28 GB に縮小します。

pvresize --setphysicalvolumesize 28g /dev/sda3

/dev/sda3: Requested size 28.00 GiB is less than real size <30.00 GiB. Proceed?  [y/n]: y
  WARNING: /dev/sda3: Pretending size is 58720256 not 62908416 sectors.
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

pvs コマンドの出力結果は以下の通りとなり、28 GB のサイズへ変更されました。

  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda3  ubuntu-vg lvm2 a--  <28.00g 15.00g

ステップ 2-4: パーティションテーブルの変更

LVM の物理ボリューム・論理ボリュームを変更操作では、パーティションの情報は変更されないため、
以下のコマンドの実行結果の通り、パーティションは依然として 30 GB のサイズのままとなっています。

lsblk /dev/sda3

コマンドの出力結果:

NAME                    MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda3                      8:3    0  30G  0 part
`-ubuntu--vg-ubuntu--lv 253:0    0  13G  0 lvm

fdisk /dev/sda とコマンドを実行して、パーティションテーブルを書き換えます。
fdisk はインタラクティブ操作のツールとなっていて、コマンドは以下の通りです。

'p' コマンド: パーティションテーブルの表示
'd' コマンド: パーティションテーブルの削除
'n' コマンド: パーティションテーブルの作成

コマンド実行の様子は以下の通りで、既存のパーティションテーブルの削除、新しいパーティションテーブルの操作により、
パーティションのテーブルの書き換えを行います。ただし、パーティションに含まれるシグネチャ情報を削除しないように注意してください。

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.


Command (m for help): p   <== 'p' を入力する

Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 9DB29DC2-4F7D-4E2A-B917-31BE798E6613

Device       Start      End  Sectors Size Type
/dev/sda1     2048     4095     2048   1M BIOS boot
/dev/sda2     4096  4198399  4194304   2G Linux filesystem
/dev/sda3  4198400 67106815 62908416  30G Linux filesystem

Command (m for help): d   <== 'd' を入力する
Partition number (1-3, default 3): 3   <== '3' を入力する

Partition 3 has been deleted.

Command (m for help): n   <== 'n' を入力する
Partition number (3-128, default 3): 3   <== '3' を入力する
First sector (4198400-67108830, default 4198400):   <== ENTER を入力する
Last sector, +/-sectors or +/-size{K,M,G,T,P} (4198400-67108830, default 67108830): +28G   <== '+28G' を入力する

Created a new partition 3 of type 'Linux filesystem' and of size 28 GiB.
Partition #3 contains a LVM2_member signature.

Do you want to remove the signature? [Y]es/[N]o: N   <== 'N' を入力する

Command (m for help): p   <== 'p' を入力する

Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 9DB29DC2-4F7D-4E2A-B917-31BE798E6613

Device       Start      End  Sectors Size Type
/dev/sda1     2048     4095     2048   1M BIOS boot
/dev/sda2     4096  4198399  4194304   2G Linux filesystem
/dev/sda3  4198400 62918655 58720256  28G Linux filesystem

Command (m for help): w   <== パーティションを確認し、問題なければ 'w' を入力して、パーティションテーブル情報をディスクに書き込む
The partition table has been altered.
Syncing disks.

物理ボリュームに問題がないか、以下のコマンドを実行します。

pvdisplay

コマンドの出力結果は以下の通りです。

  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               ubuntu-vg
  PV Size               <28.00 GiB / not usable 3.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              7167
  Free PE               3840
  Allocated PE          3327
  PV UUID               50Kkwj-1v59-d5IX-GNUS-Goph-v6fo-5p7CKU

ステップ 3: EFI パーティションの作成

1) EFI パーティションテーブルの作成

fdisk コマンドを使って、EFI パーティションを作成します。

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.


Command (m for help): p   <== 'p' を入力する

Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 9DB29DC2-4F7D-4E2A-B917-31BE798E6613

Device       Start      End  Sectors Size Type
/dev/sda1     2048     4095     2048   1M BIOS boot
/dev/sda2     4096  4198399  4194304   2G Linux filesystem
/dev/sda3  4198400 62918655 58720256  28G Linux filesystem

Command (m for help): n   <== 'n' を入力する
Partition number (4-128, default 4): 4   <== '4' を入力する
First sector (62918656-67108830, default 62918656):   <== ENTER を入力する
Last sector, +/-sectors or +/-size{K,M,G,T,P} (62918656-67108830, default 67108830):   <== ENTER を入力する

Created a new partition 4 of type 'Linux filesystem' and of size 2 GiB.

Command (m for help): t   <== 't' を入力する
Partition number (1-4, default 4): 4   <== '4' を入力する
Partition type or alias (type L to list all): 1   <== '1' を入力する

Changed type of partition 'Linux filesystem' to 'EFI System'.

Command (m for help): w   <== 'w' を入力する
The partition table has been altered.
Syncing disks.

2) EFI パーティションのフォーマット

まず、以下のコマンドでパーティション情報を確認します。

EFI パーティションは /dev/sda4 となります。

lsblk /dev/sda

コマンドの実行結果:

NAME                      MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda                         8:0    0  32G  0 disk
|-sda1                      8:1    0   1M  0 part
|-sda2                      8:2    0   2G  0 part
|-sda3                      8:3    0  28G  0 part
| `-ubuntu--vg-ubuntu--lv 253:0    0  13G  0 lvm
`-sda4                      8:4    0   2G  0 part

以下のコマンドを実行して、/dev/sda4 パーティションを FAT32 でフォーマットします。

mkfs.vfat -v -c -F 32 /dev/sda4

コマンドの実行結果:

mkfs.fat 4.2 (2021-01-31)
/dev/sda4 has 255 heads and 63 sectors per track,
hidden sectors 0x3c01000;
logical sector size is 512,
using 0xf8 media descriptor, with 4190130 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 8 sectors per cluster.
FAT size is 4088 sectors, and provides 522740 clusters.
There are 32 reserved sectors.
Volume ID is ad004b99, no volume label.
Searching for bad blocks

ステップ 4: Grub EFI のインストール

EFI パーティションの作成が完了したら、EFI ブート用の Grub ブートローダーをインストールします。

1) 起動ディスクのマウント

以下のコマンドを実行し、起動ディスクをマウントします。

mount /dev/ubuntu-vg/ubuntu-lv /mnt
mount /dev/sda2 /mnt/boot/
mkdir /mnt/boot/efi
mount /dev/sda4 /mnt/boot/efi

2) boot パーティションのバックアップ

以下のコマンドを実行し、起動ディスクの /boot パーティションのバックアップをとります。

cp -rp /mnt/boot /mnt/boot2

3) Grub EFI パッケージの取得

以下のコマンドを実行し、Grub EFI パッケージをネットワーク経由でダウンロードし、ライブサーバー環境にインストールします。

apt update
apt install grub-efi-amd64 -y

4) Grub EFI のインストール

以下のコマンドを実行し、起動ディスクに Grub EFI をインストールします。

cp -rp /mnt/boot/grub /mnt/boot/grub.old
mkdir /mnt/boot/efi/EFI

for i in /usr /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do mount --bind $i /mnt$i; done

chroot /mnt

grub-install --target=x86_64-efi /dev/sda
grub-install --recheck /dev/sda

update-grub2

ステップ 5: /etc/fstab の編集

Grub EFI ブートローダーのインストールが完了したら、
最後に /etc/fstab を編集して、EFI パーティションをマウントするよう設定します。

以下のコマンドを実行し、パーティションの UUID を確認します。

blkid /dev/sda4

コマンドの実行結果:

/dev/sda4: UUID="XXXX-XXXX" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5c027d5d-e842-b54c-a013-ee2c6a325b19"

上記の "XXXX-XXXX" がパーティションの UUID となります。
パーティションごとに固有の UUID となりますので、それぞれの環境の UUID に置き換えてください。

以下のコマンドを実行して、/mnt/etc/fstab にマウントポイントのエントリを追加します。

echo "/dev/disk/by-uuid/XXXX-XXXX /boot/efi vfat defaults 0 1" >> /mnt/etc/fstab

最後に

以上の作業により、EFI ブートが可能なディスクに変更されました。
ライブサーバーを reboot コマンドで再起動すると、第 2 世代 Hyper-V 仮想マシンで Ubuntu Linux が起動できるようになります。

セキュアブートを有効にした構成にはなっていないため、仮想マシンの設定ではセキュアブートを無効にしたままにします。

Ubuntu Linux 16.06 以降のバージョンでは、マイクロソフトの提供する Ubuntu Linux 用のセキュアブート環境が用意されています。
詳細な手順については、こちらの記事を参照ください。

仮想ディスクの変換 (VMDK 形式から VHD/VHDX 形式への変換)

Shige Fukushima — Mon, 24 Apr 2023 14:28:12 +0000

はじめに

この記事では、記事: Ubuntu VM の移行 (VMware から Hyper-V へ)
で説明した以下の移行手順のステップ 1 について説明します。

VMDK 形式の仮想ディスクを VHD/VHDX 形式への変換
新しい仮想マシンを作成 (変換した仮想ディスクをアタッチする)
open-vm-tools のアンインストール
(オプション) 第2世代 Hyper-V 仮想マシン用の仮想ディスクへ変換
(オプション) Secure Boot の有効化
Hyper-V 統合サービスのインストール

VMDK ディスクを VHD/VHDX ディスクへ変換する

VMware 仮想マシンでは仮想ディスクに VMDK 形式を利用しているため、Hyper-V 仮想マシンで利用できる仮想ディスク形式 (VHD/VHDX) とは異なります。
Hyper-V で同じ仮想ディスクを利用するためには、VMDK 形式を VHD/VHDX 形式に変換する必要があります。

MVMC (Microsoft Virtual Machine Converter) のインストール

仮想ディスク VMDK 形式は、マイクロソフトが 2014 年にリリースした
MVMC (Microsoft Virtual Machine Converter) 3.0
を利用して、VHDX 形式に変換することができました。

2023-03-16 現在、リリース記事内のリンクは無効となっていてダウンロードすることはできませんが、
以下のマイクロソフトのダウンロード URL からダウンロードすることができます。

http://download.microsoft.com/download/9/1/E/91E9F42C-3F1F-4AD9-92B7-8DD65DA3B0C2/mvmc_setup.msi

インストーラーファイルのハッシュ値は以下の通りです。

SHA256 = 520B0D08E0B9D2D95206369E56461D3873FB208F507FBCCC28651D43ABA37F33
SHA-1 = F67812339083376507F51A0B28853C38A3488CF7

仮想ディスク変換ツールの実行

MSMC 変換ツールには、GUI 変換ツールも付属しますが、
この記事では PowerShell コマンドを使って仮想ディスクの変換を行います。

以下のコマンドを実行して、
Import-Module コマンドで MVMC PowerShell コマンドレットをロードし、
ConvertTo-MvmcVirtualHardDisk コマンドで VMDK 形式の仮想ディスクファイルを VHDX 形式に変換します。

以下の例では、VMDK 形式のファイルは Ubuntu_OsDisk.vmdk という名前で、OsDisk.vhdx という名前の VHDX 形式（ダイナミック）に変換します。

Import-Module 'C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1'

ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath Ubuntu_OsDisk.vmdk -VhdType DynamicHardDisk -VhdFormat Vhdx -DestinationLiteralPath OsDisk.vhdx

オプション	説明
-SourceLiteralPath	変換元の VMDK ファイルのパス
-VhdType	VHD のタイプ (FixedHardDisk または DynamicHardDisk)
-VhdFormat	VHD の形式　(Vhd または Vhdx)
-DestinationLiteralPath	変換先の VHD/VHDX ファイルのパス

コマンドレットの詳細な説明については
MVMC_cmdlets.doc
ファイルを参照してください。

ConvertTo-MvmcVirtualHardDisk コマンドは管理者権限が必要となるため、
管理者権限に昇格していない PowerShell コマンドラインで実行すると以下のエラーが表示されます。
管理者権限で昇格済みの PowerShell コマンドラインで実行してください。

ConvertTo-MvmcVirtualHardDisk: Local administrator privileges are required.
ConvertTo-MvmcVirtualHardDisk: One or more errors occurred. (Local administrator privileges are required.)

Disk Database Entry に関する変換エラーが出る場合

現在 MVMC 変換ツールのメンテナンスが行われていないため、ConvertTo-MvmcVirtualHardDisk コマンドの実行で以下のエラーが出る場合があります。

手持ちの仮想ディスクの変換を実行した際にも、最近作成した VMware 仮想ディスクでエラーが出ました。

ConvertTo-MvmcVirtualHardDisk: The entry 4 is not a supported disk database entry for the descriptor.
ConvertTo-MvmcVirtualHardDisk: One or more errors occurred. (The entry 4 is not a supported disk database entry for the descriptor.)

このエラーは、MVMCツールがサポートしていない DDB (Disk Database) エントリ情報が VMDK に設定されている場合に発生します。
サポートしていないエントリーを無効にするために、VMDK ファイルを編集します。

VMDK ファイルが分割されている場合
- VMDK DDB エントリは、マスターファイル (*-sXXX.vmdk という名前規則でない *.vmdk ファイルでテキスト形式となっている) に格納されているため、テキストエディタで直接編集します。
VMDK ファイルが単一ファイルの場合
- VMDK DDB エントリは、VMDK ファイル (バイナリ形式) に埋め込まれています。このエントリ情報の書き換えについては、DSFOK ツールを利用して行います。
- DSFOK ツールの詳細については、こちらの記事 (英語)を参照しました。
- 以下のコマンドを利用して、DDB エントリ情報 (ファイルの先頭から 512 バイトの位置から 1024 バイト) を取り出します。
```
dsfo.exe Ubuntu_OsDisk.vmdk 512 1024 descriptor.txt
```

* 取り出した DDB エントリ情報 (`descriptor.txt`) をテキストエディタで編集したら、
以下のコマンドを利用して、DDB エントリ情報 (ファイルの先頭から 512 バイトの位置から 1024 バイト) を書き出します。

```cmd
dsfi.exe Ubuntu_OsDisk.vmdk 512 1024 descriptor.txt
```

DDB エントリ情報は以下のような内容になります。

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=a48f63c4
parentCID=ffffffff
createType="monolithicSparse"

# Extent description
RW 134217728 SPARSE "Ubuntu-LTS-x64.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "8354"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "3bf70afaa672951de3328531a48f63c4"
ddb.toolsInstallType = "4"
ddb.toolsVersion = "12320"
ddb.uuid = "60 00 C2 97 7a d0 13 78-1f e0 18 0f 03 1f 8f ff"
ddb.virtualHWVersion = "19"

上記のエラーの場合、該当部分を以下のようにコメントアウトする (# を追加する) ことで、
変換コマンドのエラーを回避することができました。

変換前：

ddb.toolsInstallType = "4"

変換後：

#ddb.toolsInstallType = "4"

VMDK DDB エントリ情報を編集後にコマンドを実行すると、正常に変換が開始します。変換が完了すると以下の結果のメッセージが表示されます。

Destination                     Source
-----------                     ------
Z:\shigeyf\VMs\work\OsDisk.vhdx .\Ubuntu-LTS-x64.vmdk

最後に

この手順ガイドは、VMware 仮想マシンを Hyper-V に変換するときに得た経験と、Google 検索で得られた記事等に基づいて作成しました。

この記事に記載されている情報に基づいて行った結果についての損失や損害について責任を負いません。
仮想ディスクの変換を行う際には、十分な容量を確保した環境で、必ず仮想ディスクファイルのバックアップを必ず行ってから、自身の責任の元で実行してください。

Ubuntu VM の移行 (VMware から Hyper-V へ)

Shige Fukushima — Mon, 24 Apr 2023 14:26:50 +0000

VMware 仮想マシンを Hyper-V へ移行する

これまで、Windows の開発環境で
VMware Workstation Player
(個人利用では無償バージョンを利用することができる) を使って開発用の仮想化環境 (Ubuntu Linux マシン等) を用意していましたが、
新しい PC の購入に伴い、開発環境を引っ越しすることにしました。
この引っ越しに伴って、仮想化マシンも Hyper-V へ引っ越しすることにしました。

Ubuntu OS の VMware 仮想マシンを Hyper-V へ移行するには以下の手順で行います。

VMDK 形式の仮想ディスクを VHD/VHDX 形式への変換
新しい仮想マシンを作成 (変換した仮想ディスクをアタッチする)
open-vm-tools のアンインストール
(オプション) 第2世代 Hyper-V 仮想マシン用の仮想ディスクへ変換
(オプション) Secure Boot の有効化
Hyper-V 統合サービスのインストール

ステップ 1: VMDK ディスクを VHD/VHDX ディスクへ変換する

詳細な手順については、こちらの記事を参照ください。

ステップ 2: 新しい Hyper-V 仮想マシンを作成

ほとんどの場合、VMware で作成した Ubuntu Linux の仮想マシンは BIOS ブートとなっています。

BIOS ブートとなっているかどうかを確認するには、移行前に VMware 仮想環境で以下のコマンドを実行してください。

sudo fdisk -l

コマンドの出力結果は以下の通りです。
/dev/sda のディスクに BIOS boot のパーティションが表示されています。

Disk /dev/loop0: ... (中略)
   :
Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 9DB29DC2-4F7D-4E2A-B917-31BE798E6613

Device       Start      End  Sectors Size Type
/dev/sda1     2048     4095     2048   1M BIOS boot
/dev/sda2     4096  4198399  4194304   2G Linux filesystem
/dev/sda3  4198400 67106815 62908416  30G Linux filesystem


Disk /dev/mapper/ubuntu--vg-ubuntu--lv: 15 GiB, 16101933056 bytes, 31449088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

BIOS ブートのディスクを正しく起動するには、「第 1 世代」の
Hyper-V 仮想マシンを作成する必要がありますので、注意してください。

Hyper-V 仮想マシンの詳細な作成方法はこの記事を参照してください (ここでは割愛します)。
「既存の仮想ハードディスクを使用する」を選択して変換した仮想ディスクを指定してください。

Hyper-V 仮想マシンを作成する際のフォルダ構成は、以下のような構成がおすすめです。

仮想マシンの名前のフォルダー
├─Virtual Machines
├─Virtual Hard Disks : ここに変換した VHD/VHDX ファイルをコピーする
└─Snapshots

ステップ 3: open-vm-tools のアンインストール

VMware 仮想マシンに Ubuntu Linux をインストールすると、自動的に open-vm-tools パッケージがインストールされています。
このパッケージのアンインストールをします。

アンインストールの実行:

sudo apt remove open-vm-tools -y

削除されたか確認する:

sudo apt list | grep "open-vm-tools/"

以下のように residual-config と表示されている場合、パッケージの残骸 (構成ファイルなど) が残っている状態を表しています。

open-vm-tools/jammy-updates,now 2:12.1.0-1~ubuntu0.22.04.1 amd64 [residual-config]

以下のコマンドで構成ファイルを削除します。

sudo apt purge open-vm-tools -y

以下のコマンドを実行して、open-vm-tools に依存するパッケージで不要なパッケージを自動的に削除します。

sudo apt autoremove -y

ステップ 4: (オプション) 第2世代 Hyper-V 仮想マシン用の仮想ディスクへ変換

第 2 世代 Hyper-V 仮想マシンで Ubuntu Linux を起動するには、
Ubuntu Linux の起動ディスクを BIOS ブートから EFI ブートへ変更する必要があります。

詳細な手順については、こちらの記事を参照ください。

ステップ 5: (オプション) Secure Boot の有効化

詳細な手順については、こちらの記事を参照ください。

ステップ 6: Hyper-V 統合サービスのインストール

以下のコマンドを実行して、Hyper-V 統合サービスをインストールします。

sudo apt update
sudo apt install linux-virtual linux-cloud-tools-virtual linux-tools-virtual -y
sudo reboot -f

再起動後、以下のコマンドを実行して、Hyper-V 統合サービスが実行しているか確認することができます。

Hyper-V 用のカーネルモジュールの確認のコマンド:

lsmod | grep hv_

出力結果:

hv_balloon             36864  0
hv_storvsc             24576  3
hv_netvsc              98304  0
scsi_transport_fc      98304  1 hv_storvsc
hv_utils               45056  3
hv_vmbus              135168  8 hv_balloon,hv_utils,hv_netvsc,hid_hyperv,hv_storvsc,hyperv_keyboard,hyperv_drm,hyperv_fb

Hyper-V 用デーモンの確認のコマンド:

compgen -c hv_

出力結果:

hv_fcopy_daemon
hv_vss_daemon
hv_set_ifconfig
hv_get_dhcp_info
hv_get_dns_info
hv_kvp_daemon
hv_fcopy_daemon
hv_vss_daemon
hv_set_ifconfig
hv_get_dhcp_info
hv_get_dns_info
hv_kvp_daemon

移行後のその他の作業

仮想化環境の変更により、仮想マシンのハードウェアの変更が発生しています。
以下の作業を行います。

ネットワークインターフェースの変更

VMware 仮想マシンでは、ネットワークインターフェースは ens33 と認識されましたが、
Hyper-V 仮想マシンでは eth0 と認識されます。

ネットワーク接続の構成ファイル (/etc/netplan/00-installer-config.yaml) を
(例えば以下のように) 正しく変更してください。

# This is the network config written by 'subiquity'
network:
  ethernets:
    eth0:
      dhcp4: true
  version: 2

/dev/fd0 に関するエラー

コンソール出力に以下のようなエラーが表示されたり、sudo dmesg コマンドの実行結果に以下のエラーが表示される場合があります。
起動している Hyper-V の仮想マシンにフロッピーデバイスがないため、表示されるエラーです。

floppy0: disk absent or changed during operation
blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
floppy0: disk absent or changed during operation
blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Buffer I/O error on dev fd0, logical block 0, async page read

VMware 仮想マシンでは、仮想マシンにフロッピードライブを接続していなくても、
仮想マシンのマザーボードにフロッピードライブのインターフェースが用意されているため、
floppy カーネルモジュールが読み込まれています。

以下のコマンドで、フロッピーデバイスを無効化します。

sudo rmmod floppy
echo "blacklist floppy" | sudo tee /etc/modprobe.d/blacklist-floppy.conf
sudo dpkg-reconfigure initramfs-tools

まとめ

VMware 仮想化環境でインストールした Ubuntu Linux 仮想マシンを Hyper-V 仮想化環境に移行することができました。

最新の Ubuntu Linux インストーラーでは、第 2 世代の Hyper-V 仮想マシンでセキュアブートを有効にした仮想マシンを
自動的にインストールすることができるようになっていますが、既存の資産を活用したい場合などは、このガイドを参考に移行をしてみてください。

Wowza Streaming Engine での HLS ストリーミング

Shige Fukushima — Thu, 30 Mar 2023 14:24:59 +0000

はじめに

この記事では、Wowza Streaming Engine での HLS 方式でのストリーミングに関する
技術的に詳細な設定・カスタマイズの方法について触れます。

HLS プレイリスト (マニフェスト) について

HLS プレイリストには、EXT-X-VERSION タグと呼ばれる Apple HLS (HTTP Live Streaming) のプレイリスト互換性バージョンを示すタグが含まれています。

Wowza Streaming Engine の HTTPStreamer の既定の設定では、Apple HLS 互換性バージョン 3 のプレイリストを生成します。

#EXT-X-VERSION:3

VOD またはライブアプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) 内の
以下のパラメーターで HLS プレイリストの互換性バージョンを制御することができます。

Wowza Streaming Engine では、バージョン 3 から 6 までをサポートしています。

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	cupertinoExtXVersion
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	プレイリストの互換性バージョンを指定する (既定値: 3)

Wowza Streaming Engine では、指定された EXT-X-VERSION (プレイリストの互換性バージョン) に基づいてプレイリスト機能を有効または無効にすることができます。

次の機能は EXT-X-VERSION の値によって制御されます。

浮動小数点形式によるセグメント長
- EXT-X-VERSION が 3 以上の場合、整数形式ではなく浮動小数点形式を使用してセグメント長を表します
コーデック形式
- EXT-X-VERSION が 4 以上の場合、iOS 4.0 以降のコーデック形式 (例: avc1.42c015) を使用して、playlist.m3u8 レスポンスのコーデック値を表します
- EXT-X-VERSION が 4 未満の場合、iOS 4.0 以前のコーデック形式 (例: avc1.66.21) を使用します
- cupertinoCodecStringFormatId (パス名:/Root/Application/HTTPStreamer) プロパティの値によってコーデック形式の制御することも可能です
- Integer 型で、値が 2 の場合、iOS 4.0 以降のコーデック形式を使用します
- Integer 型で、値が 1 の場合、iOS 4.0 以前のコーデック形式を使用します

HLS セグメントの長さについて

Wowza Streaming Engine では、HLS ストリーミングを行うためにビデオファイルをセグメントに分割してプレイヤーに提供します。

分割するセグメントの長さは、既定では 10 秒 (10000 ミリ秒) となっていますが、
以下のアプリケーションプロパティを変更することでセグメントの長さをカスタマイズすることができます。

注意

HLS アダプティブストリーミングが正しく動作するには、ビデオセグメントの始まりは必ずキーフレーム (I-フレーム) で開始する必要があり、
ビデオセグメントの境界はキーフレームの間隔と整合性がとれている必要があります。
例えば、10秒のビデオセグメントの場合、2秒、2.5秒、5秒、10秒などのキーフレーム間隔でエンコードされたビデオを入力する必要があります。
これにより、再生中に異なるビットレートや解像度のビデオストリーム間で再生の切り替えを正しく行うことができます。

このため、Wowza Streaming Engine に入力するビデオ (VOD ファイルやライブストリーム) は、指定するセグメントの長さに気を付けて入力する必要があります。

VOD ストリーミングのセグメントの長さの設定パラメーター

VOD アプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下の項目を設定することで、HLS VOD ストリーミングのセグメントの長さを変更することができます。

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	cupertinoChunkDurationTarget
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	セグメントの長さ (ミリ秒) を指定する (既定値: 10000)

ライブストリーミングのセグメントの長さの設定パラメーター

ライブ入力デバイス等からのオーディオ・ビデオパケットは、 Wowza Streaming Engine で時刻に基づいてセグメントに分割されます。
各セグメントの長さは、cupertinoChunkDurationTarget プロパティによって制御されます。
セグメントは、作成時にアクセス可能なセグメントリストに追加されます。
リストに格納される項目の最大数は、cupertinoMaxChunkCount プロパティによって制御されます。
MPEG-DASH クライアント (プレイヤー) がストリームを要求すると、Wowza Streaming Engine は最近追加された n 個のセグメントを含むマニフェストを提供します。
マニフェストで返されるアイテムの数 (n) は、cupertinoPlaylistChunkCount プロパティによって制御されます。

また、ライブストリームリピーターシステムは、オリジン/エッジの構成で単一のライブストリームを複数のエッジサーバーに配信するために使用されます。
エッジサーバーは、ライブストリームを最初に要求するときに、オリジンへセグメント化されたライブストリームのリクエストを行って、クライアントに配信します。
cupertinoRepeaterChunkCount プロパティは、最初の接続後すぐにオリジンからエッジに送信されるセグメントの数を制御します。
cupertinoRepeaterChunkCount は cupertinoPlaylistChunkCount 以上で cupertinoMaxChunkCount 未満であることが最適です。
この設定パラメーターは、Live Edge タイプのアプリケーションでリピーター構成となっている場合に利用します。

ライブアプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下の項目を設定することで、HLS ライブストリーミングのセグメントの長さを変更することができます。

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	cupertinoChunkDurationTarget
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	セグメントの長さ (ミリ秒) を指定する (既定値: 10000)

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	cupertinoMaxChunkCount
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	WSE 内部で格納する有効なライブストリームのセグメント数を指定する (既定値: 10)

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	cupertinoPlaylistChunkCount
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	プレイリストで提供するライブストリームのセグメント数を指定する (既定値: 5)

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	cupertinoRepeaterChunkCount
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	エッジからオリジンへの最初の接続後、オリジンからエッジにすぐに送信されるセグメント数を指定する (既定値: 5)

HLS Audio-only ストリームの設定

過去の Apple デバイス向けの Apple HLS オーサリングガイドラインでは、
3G ネットワークなどの低帯域ネットワークに向けたアクセスのために、
HLS ストリーミングコンテンツに Audio-only (音声のみ) のストリームを用意することが
ガイドラインとして設けられていました。

例えば、取得したプレイリスト
(例: https://[アドレス]/[アプリ名]/mp4:sample.mp4/playlist.m3u8)
は以下のような内容となります。

_ao.m3u8 のサフィックスが付いたプレイリスト (以下の例では chunklist_[WowzaセッションID]_ao.m3u8) が、
Audio-only ストリームのプレイリストです。

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=868638,CODECS="avc1.42c015,mp4a.40.2",RESOLUTION=512x288
chunklist_w298755728.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=116046,CODECS="mp4a.40.2"
chunklist_w298755728_ao.m3u8

現在のガイドラインには、該当する記載はなくなっているようです。

HTTP Live Streaming (HLS) Authoring Specification for Apple Devices

この Audio-only のストリームが追加されるように HLS プレイリストの変更を行うには、以下のプロパティの設定を行います。

VOD HLS Audio-only ストリームの設定

VOD アプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下の項目を設定することで、HLS VOD ストリーミングのプレイリストに Audio-only ストリームを追加します。

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	cupertinoAutoCreateMultibitratePlaylist
プロパティのタイプ (Type)	Boolean
プロパティの値 (Value) の説明	true に設定する (既定値: false)

ライブ HLS Audio-only ストリームの設定

ライブアプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下の項目を設定することで、HLS ライブストリーミングのプレイリストに Audio-only ストリームを追加します。

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	cupertinoCreateAudioOnlyRendition
プロパティのタイプ (Type)	Boolean
プロパティの値 (Value) の説明	true に設定する (既定値: false)

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	cupertinoAutoCreateMultibitratePlaylist
プロパティのタイプ (Type)	Boolean
プロパティの値 (Value) の説明	true に設定する (既定値: false)

HLS KeyFrames-only プレイリストの設定

Apple のネイティブ HLS プレイヤーでは、VOD コンテンツのトリックプレイ再生をサポートしています。
トリックプレイ再生とは、プレーヤーでコンテンツの巻き戻しや早送りをしてコンテンツのタイムラインを探すときに、
ビューア―に視覚的な手がかりとなるビデオのサムネイルを提供するものです。

トリックプレイ再生をサポートするために特別な目的のコンテンツを別に作成する必要はなく、
ビデオストリームのキーフレーム¹ の場所をプレイヤーに提供するだけです。
ビデオストリームのキーフレームの場所を指定するために、Apple iOS 5 以降では KeyFrames-only プレイリスト (Iフレームのみのプレイリスト) を使用します。

この設定はラVODアプリケーションにのみ有効な設定です

Wowza Streaming Engine では、KeyFrames-only プレイリストを動的に生成し、ビデオストリームのキーフレームをストリーミングすることができます。
KeyFrames-only プレイリストは、playlist.m3u8 プレイリストの中で EXT-X-I-FRAME-STREAM-INF タグを使って URL を指定します。
KeyFrames-only プレイリストは EXT-X-I-FRAMES-ONLY タグを使用してキーフレームのみを提供するプレイリストです。
KeyFrames-only プレイリストでは、EXTINF タグはセグメントの長さのかわりにキーフレームの間隔を参照します。

ビデオフレームのエンコード時に他のフレームから独立してエンコードされたビデオフレームです。

この I-Frames-only のプレイリストが追加されるように HLS プレイリストの変更を行うには、以下のプロパティの設定を行います。

VOD アプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下の項目を設定することで、HLS VOD ストリーミングのプレイリストに I-Frames-only プレイリストを追加します。

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	cupertinoExtXVersion
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	4 以上の値に設定する (既定値: 3)

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	cupertinoCreateKeyFrameOnlyPlaylist
プロパティのタイプ (Type)	Boolean
プロパティの値 (Value) の説明	true に設定する (既定値: false)

プレイリストのサンプルは以下の通りです。

playlist.m3u8

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=868638,CODECS="avc1.42c015,mp4a.40.2",RESOLUTION=512x288
chunklist_w1520434929.m3u8
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=875,CODECS="avc1.42c015",URI="chunklist_w1520434929_ko.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=116046,CODECS="mp4a.40.2"
chunklist_w1520434929_ao.m3u8

KeyFrames-only プレイリスト

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-I-FRAMES-ONLY
#EXTINF:2.0,
#EXT-X-BYTERANGE:999624@376
media_w1520434929_ko_0.ts
#EXTINF:2.0,
#EXT-X-BYTERANGE:999624@376
media_w1520434929_ko_1.ts
#EXTINF:2.0,
#EXT-X-BYTERANGE:999624@376
media_w1520434929_ko_2.ts
#EXTINF:2.0,
#EXT-X-BYTERANGE:999624@376
media_w1520434929_ko_3.ts
  :

HLS Audioストリームの TS パッケージングの設定

Wowza Streaming Engine の既定の設定では、HLS Audio ストリームは、MPEG-2 エレメンタリストリームでパッケージングされます。

以下のプロパティの設定を行うことで、HLS Audio ストリームをビデオストリームと同様に
HLS Audio ストリームを　MPEG-2 トランスポートストリーム (TS) でパッケージングを行います。

VOD HLS Audio ストリームの TS パッケージングの設定

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	cupertinoPacketizeAllStreamsAsTS
プロパティのタイプ (Type)	Boolean
プロパティの値 (Value) の説明	true に設定する (既定値: false)

ライブ HLS Audio ストリームの TS パッケージングの設定

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	cupertinoPacketizeAllStreamsAsTS
プロパティのタイプ (Type)	Boolean
プロパティの値 (Value) の説明	true に設定する (既定値: false)

タイムコードに基づいたライブストリームのセグメントの番号付けの設定

Wowza Streaming Engine では、エンコーダーから受信したライブストリームにタイムコードが含まれている場合に、
タイムコードに基づいたセグメント (チャンク) の番号付けを行うことができます。

この設定はライブアプリケーションにのみ有効な設定です

この機能を有効にするには、ライブアプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下のプロパティを設定します。

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	cupertinoCalculateChunkIDBasedOnTimecode
プロパティのタイプ (Type)	Boolean
プロパティの値 (Value) の説明	true に設定する (既定値: false)

この機能を有効にすると、セグメントの ID はタイムコードを cupertinoChunkDurationTarget 値で割った (割り算の) 商に等しくなります。

注意: cupertinoCalculateChunkIDBasedOnTimecode プロパティは、
時刻同期されたタイムコードを Wowza Streaming Engine に送信するエンコーダーを使う場合のみ有効にしてください。
時刻同期されたタイムコードは、UTC またはその他の時刻をベースに同期するようにします。

もし、時刻同期されたタイムコードを送信しないエンコーダーのライブソースストリームと cupertinoCalculateChunkIDBasedOnTimecode が使用されている場合、
ソースストリームが再起動するとセグメント ID は 0 で再起動するか、場合によってはランダムな値で再起動します。
HTTP オリジンを使ってプライマリサーバーとバックアップサーバーの2つのソースから取り込まれたライブストリームを取り扱う場合、
セグメント ID の整合性がとれなくなってしまうため、特に問題になります。

キーフレームは、I フレーム、または、イントラコード化されたフレームと呼ばれることもあり、 ↩

Wowza Streaming Engine での MPEG-DASH ストリーミング

Shige Fukushima — Thu, 30 Mar 2023 14:24:46 +0000

はじめに

この記事では、Wowza Streaming Engine での MPEG-DASH 方式でのストリーミングに関する
技術的に詳細な設定・カスタマイズの方法について触れます。

MPEG-DASH MPD マニフェストについて

MPEG-DASH サーバーは、メディアプレゼンテーション記述 (MPD) マニフェストファイルで、
利用可能なメディアセグメント URL のリストをプレーヤーに提供します。
その後、プレイヤーは、中断のない再生を行うために、必要に応じてメディアセグメントを順次要求します。

MPD ファイル内でこのセグメント URL のリストの識別方法を定義する方式をセグメントアドレス方式とは呼び、
以下のセグメントアドレス方式があります。

セグメントリスト方式
- 利用可能なすべてのセグメントについて、セグメント URL の完全なリストを提供する方式です
セグメントテンプレート (時刻ベース) 方式
- プレイヤーがセグメント URL リストを作成できるようにするための URL テンプレートを提供する方式です
- セグメント URL にはセグメントごとの開始時刻が含まれます
セグメントテンプレート (セグメント番号ベース) 方式
- プレイヤーがセグメント URL リストを作成できるようにするための URL テンプレートを提供する方式です
- セグメント URL にはセグメントごとのセグメントの番号 (インデックス番号など) が含まます
セグメントベース (BaseURL) 方式
- すべてのセグメントが単一の URL (BaseURL) で識別されるセグメント分割を行わない方式で、セグメントがバイトレンジの HTTP リクエストを通じて取得する方式です

Wowza Streaming Engine の MPEG-DASH サポートでは、セグメントベース方式以外のセグメントアドレス方式の MPD 形式をサポートしていて、
プレイヤーは以下の URL フォーマット指定で必要なマニフェスト形式を指定できます。

http://[アドレスまたはホスト名]:[ポート]/[アプリケーション名]/[アプリインスタンス]/[ストリーム名]/manifest*_mv[セグメントアドレス方式]*.mpd

[セグメントアドレス方式]には、以下のいずれかを指定します。

mvtime: セグメントテンプレート (時間ベース) 方式
mvlist: セグメントリスト方式
mvnumber: セグメントテンプレート (セグメント番号ベース) 方式

_mv[セグメント形式] の指定がない場合は、mvtime が既定値となります。

MPEG-DASH セグメントの長さについて

Wowza Streaming Engine では、MPEG-DASH ストリーミングを行うためにビデオファイルをセグメントに分割してプレイヤーに提供します。

注意

MPEG-DASH アダプティブストリーミングが正しく動作するには、ビデオセグメントの始まりは必ずキーフレーム (I-フレーム) で開始する必要があり、
ビデオセグメントの境界はキーフレームの間隔と整合性がとれている必要があります。
例えば、10秒のビデオセグメントの場合、2秒、2.5秒、5秒、10秒などのキーフレーム間隔でエンコードされたビデオを入力する必要があります。
これにより、再生中に異なるビットレートや解像度のビデオストリーム間で再生の切り替えを正しく行うことができます。

このため、Wowza Streaming Engine に入力するビデオ (VOD ファイルやライブストリーム) は、指定するセグメントの長さに気を付けて入力する必要があります。

VOD ストリーミングのセグメントの長さの設定パラメーター

VOD アプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下の項目を設定することで、MPEG-DASH VOD ストリーミングのセグメントの長さを変更することができます。

項目	内容
XML パス	/Root/Application/HTTPStreamer
プロパティ名 (Name)	mpegdashSegmentDurationTarget (バージョン 4.7.8 以降)
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	セグメントの長さ (ミリ秒) を指定する (既定値: 10000)

ライブストリーミングのセグメントの長さの設定パラメーター

ライブ入力デバイス等からのオーディオ・ビデオパケットは、 Wowza Streaming Engine で時刻に基づいてセグメントに分割されます。
各セグメントの長さは、mpegdashSegmentDurationTarget プロパティによって制御されます。
セグメントは、作成時にアクセス可能なセグメントリストに追加されます。
リストに格納される項目の最大数は、mpegdashMaxSegmentCount プロパティによって制御されます。
MPEG-DASH クライアント (プレイヤー) がストリームを要求すると、Wowza Streaming Engine は最近追加された n 個のセグメントを含むマニフェストを提供します。
マニフェストで返されるアイテムの数 (n) は、mpegdashPlaylistSegmentCount プロパティによって制御されます。

また、ライブストリームリピーターシステムは、オリジン/エッジの構成で単一のライブストリームを複数のエッジサーバーに配信するために使用されます。
エッジサーバーは、ライブストリームを最初に要求するときに、オリジンへセグメント化されたライブストリームのリクエストを行って、クライアントに配信します。
mpegdashRepeaterSegmentCount プロパティは、最初の接続後すぐにオリジンからエッジに送信されるセグメントの数を制御します。
mpegdashRepeaterSegmentCount は mpegdashPlaylistSegmentCount 以上で mpegdashMaxSegmentCount 未満であることが最適です。
この設定パラメーターは、Live Edge タイプのアプリケーションでリピーター構成となっている場合に利用します。

ライブアプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) の
以下の項目を設定することで、MPEG-DASH ライブストリーミングのセグメントの長さを変更することができます。

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	mpegdashSegmentDurationTarget (バージョン 4.7.8 以降)
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	セグメントの長さ (ミリ秒) を指定する (既定値: 10000)

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	mpegdashMaxChunkCount (バージョン 4.7.8 以降)
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	WSE 内部で格納する有効なライブストリームのセグメント数を指定する (既定値: 10)

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	mpegdashPlaylistChunkCount (バージョン 4.7.8 以降)
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	プレイリストで提供するライブストリームのセグメント数を指定する (既定値: 5)

項目	内容
XML パス	/Root/Application/LiveStreamPacketizer
プロパティ名 (Name)	mpegdashRepeaterSegmentCount (バージョン 4.7.8 以降)
プロパティのタイプ (Type)	Integer
プロパティの値 (Value) の説明	エッジからオリジンへの最初の接続後、オリジンからエッジにすぐに送信されるセグメント数を指定する (既定値: 5)

MPD リダイレクト

サーバーの使用状況の分析や監視を行うための統計情報を提供するために、
Wowza Streaming Engine はそれぞれのストリーミング再生セッションについて HTTP セッションコンテキストを保存します。

通常の HTTP ストリーミング技術では、プレーヤーがマニフェストを要求したときにセッションが作成されるようになっていて、サーバーはプレイヤーが同じ再生セッションで同じマニフェストに対して追加のリクエストを行うことを期待していません。もし同じマニフェストに対してリクエストがあると新しいセッションが作成されますが、これは別の再生セッションとなります。

しかし、MPEG-DASH ライブストリーミングの場合は、プレーヤーが (MPEG-DASH の設計上の理由により) 定期的にDASH MPD マニフェストを再リクエストして、新しいセグメントの発行や古いセグメントの有効期限を識別する必要があります。すると、プレーヤーが DASH MPD マニフェストを再リクエストするたびに新しい HTTP セッションが誤って作成されてしまいます。

Wowza Streaming Engine では、MPD.Location リダイレクト機能 (MPD マニフェスト内部のリダイレクトのメカニズム) か HTTP リダイレクト機能を使用することによりこの問題に対処することができます。

MPD.Location リダイレクト機能

MPD.Location リダイレクト機能は、HTTP リダイレクトと同様の機能を提供する MPEG-DASH MPD マニフェストの MPD.Location 要素のサポートにより、
以下のように実現されています。

MPD.Location 要素は、オリジナルの MPD URL のファイル名に Wowza セッション ID を埋め込んだ更新された MPD URL を提供します
プレーヤーは、そのセッション中の以降のすべての MPD リクエストに対して、更新された MPD URL を使用するようになります
MPD.Location 要素は、最初の MPD だけでなく、以降のすべての MPD の中で提供されます
新しいセッションは、リクエストされた MPD URL に Wowza セッション ID が含まれない MPD URL へのリクエストに対してのみ作成されます
- それ以外の場合、サーバーはリクエストに含まれる Wowza セッション ID を使用し、同じ HTTP セッション内で続行します

例えば、元の MPD URL が以下の場合は、

http://[アドレス]:1935/[アプリケーション名]/mp4:sample.mp4/manifest_mpm4sav_mvlist.mpd

新しい URL は次のようになります。

http://[アドレス]:1935/[アプリケーション名]/mp4:sample.mp4/manifest_mpm4sav_mvlist_w1499067310.mpd

w1499067310 は埋め込まれた Wowza セッション ID となります。

MPD HTTP リダイレクト機能

MPEG-DASH MPD HTTP リダイレクト機能を使用すると、Wowza Streaming Engine はプレーヤーからの最初の DASH MPD リクエスト
に HTTP リダイレクトステータスコード (302, 307 等) で応答するように構成されます。

HTTP リダイレクトのレスポンスに含まれる Location ヘッダーは、MPD URL のファイル名に Wowza セッションID が埋め込まれた、更新された MPD URL を提供します
プレーヤーは、そのセッション中の以降のすべての MPD リクエストに新しい URL を使用するようになります
正しいサーバーが HTTP セッションを作成/管理 (その後、必要に応じてサーバーが MPD URL リダイレクトを実行) するよう、サーバー側の API 呼び出し (httpSession.redirectSession()) を介して実装されたリダイレクト機能は、MPEG-DASH ストリーミングのセッションに関連するリダイレクトの前に実行されます
このリダイレクトの仕組みが期待する効果を発揮するためには、リダイレクト後の MPD URL がプレーヤーで保存されて、その再生セッション中の以降のすべての MPD リクエストにその URL が使用される必要があります > Wowza セッションID の情報を持たない元の MPD URL をセッションで再度使用してはいけません
新しいセッションは、リクエストさえれた MPD URL に Wowza セッション ID の情報が含まれない MPD URL に対してのみ作成され、それ以外の場合、サーバーは提供されたセッション ID を使用して、同じ HTTP セッション内で続行します
既定では、HTTP リダイレクトは 307 (一時リダイレクト) ステータスコードを使用します
- HTTP 1.0 リクエストの場合、サーバーは 302 リダイレクトステータスコードで上書きします
- mpegdashHttpRedirectDisableStatusCode302Override, mpegdashHttpRedirectDefaultStatusCode プロパティを使って、既定の動作を変更できます

DASH MPD HTTP リダイレクト機能を有効にするには、mpegdashHttpRedirectEnabled プロパティを使って構成します。

以下、HTTPリダイレクト機能のパラメーターに関する情報です。

プロパティ名 (Name)	プロパティのタイプ (Type)	プロパティの値 (Value) の説明
mpegdashHttpRedirectEnabled	Boolean	true に設定すると MPEG-DASH MPD ファイルの HTTP リダイレクトが有効になります: 既定値は false です
mpegdashHttpRedirectDefaultStatusCode	Integer	MPEG-DASH MPD ファイルの HTTP リダイレクト応答で使用されるデフォルトのリダイレクトステータスコードを指定します: 既定値は 307 (一時的なリダイレクト) です
mpegdashHttpRedirectDisableStatusCode302Override	Boolean	"HTTP 1.0" プロトコルの DASH MPD の HTTP 要求は、通常、上記のリダイレクトステータスコードではなく、302 リダイレクトステータスコードで応答します。このプロパティを true に設定すると、そのオーバーライドを無効にして、通常のステータスコードを使用することができます: 既定値は false です

その他の設定パラーメーターについて

以下のパラメーターが Wowza Streaming Engine でのMPEG-DASH ストリーミングのカスタマイズのために用意されています。

XML パスが `/Root/Application/HTTPStreamer` のパラメーター

プロパティ名 (Name)	プロパティのタイプ (Type)	プロパティの値 (Value) の説明
mpegdashAdjustCTTSForFirstKeyFrameToZero (バージョン 4.5.0 以降)	Boolean	true に設定すると、VODファイル内のすべてのエンコードされたフレームの CompositionTimeToSample (CTTS) を調整して、MPEG-DASH プレーヤーでの再生を有効にします。このプロパティが設定されていない場合、または、設定されていても値が false に設定されている場合、ビデオの最初のフレームに CTTS 値があると、Wowza Streaming Engine は次のメッセージを `[install-dir]/logs/wowzastreamingengine_access.log` ファイルに記録します : `MediaReaderH264MPEGDash.indexFile[vod/definst/earnings_release_1q16.mp4]: First frame of video has a non-zero CTTS value [200], playback may not work on all browsers, try setting HTTPStreamer/Properties boolean property mpegdashAdjustCTTSForFirstKeyFrameToZero to true`
mpegdashEnableUTCTimingElements	Boolean	false に設定すると、ライブストリーミングの MPEG-DASH MPD マニフェストファイルの UTCTiming 要素を削除します: 既定値は true です (MPD マニフェストファイルに UTCTiming 要素が含まれます)
mpegdashUTCTimingSchemeOrder (バージョン 4.7.0 以降)	String	UTCTiming スキームを順序付けで有効にするための、優先順位が付けられたコンマ区切りのリストを指定します (リストの最初のものが最も優先されます)。有効な値は、`direct`, `http-head`、`http-xsdate`、`http-iso`、`http-ntp`、`ntp`、`sntp` です。既定値は `direct` です (ほとんどの場合この値で問題ありません)。注意: `direct` または `http-head` 以外の値を指定する場合、対応する mpegdashUTCTiming`[スキーム名]` プロパティを構成する必要があります。例えば、`http-xsdate` を指定する場合は、`mpegdashUTCTimingHttpXsDateList` プロパティを構成する必要があります。
mpegdashUTCTimingHttpHeadList (バージョン 4.7.0 以降)	String	HTTP ヘッダー内の日付情報を取得するために HTTP HEAD 要求を行うことができる HTTP URL の優先順のコンマ区切りリストを指定します (リストの最初のものが最も優先されます)。任意の有効な HTTP/HTTPS サーバー URL を指定します: 既定値はローカルの Wowza Streaming Engine サーバー (`${com.wowza.wms.context.ApplicationInstance.MPEGDash.domain}/dashtime.txt`) を指す URLです
mpegdashUTCTimingHttpXsDateList (バージョン 4.7.0 以降)	String	適切な時間を取得するためにリクエストを送信できる HTTP URL の優先順のコンマ区切りリストを指定します。時刻は `xs:dateTime` 形式で返されます。任意の有効な HTTP/HTTPS サーバー URL を指定します。例えば、http://myPublicServer.com/xsdate、https://mySecureServer.com/xsdate です: 既定値は `null` です
mpegdashUTCTimingHttpISOList (バージョン 4.7.0 以降)	String	適切な時間を取得するためにリクエストを送信できる HTTP URL の優先順のコンマ区切りリストを指定します。時刻は ISO タイムコード形式で返されます。任意の有効な HTTP/HTTPS サーバー URL を指定します。例えば、http://myPublicServer.com/xsdate、https://mySecureServer.com/xsdate です: 既定値は `null` です
mpegdashUTCTimingHttpNTPList (バージョン 4.7.0 以降)	String	適切な時間を取得するためにリクエストを送信できる HTTP URL の優先順のコンマ区切りリストを指定します。時刻は NTP タイムスタンプ形式で返されます。任意の有効な HTTP/HTTPS サーバー URL を指定します。例えば、http://myPublicServer.com/ntptime、https://mySecureServer.com/ntptime です: 既定値は `null` です
mpegdashUTCTimingNTPList (バージョン 4.7.0 以降)	String	適切な時刻を取得するために NTP プロトコル (IETF RFC 5905 で定義) が利用可能な優先順位が付けられたコンマ区切りのサーバーのリストを指定します。有効な NTP サーバー名または IP アドレスを指定します。例えば、time-a.nist.gov、time-b.nist.gov、129.6.15.29 です: 既定値は `null` です
mpegdashUTCTimingSNTPList (バージョン 4.7.0 以降)	String	適切な時刻を取得するために SNTP プロトコル (IETF RFC 5905 で定義) が利用可能な優先順位が付けられたコンマ区切りのサーバーのリストを指定します。有効な SNTP サーバー名または IP アドレスを指定します。例えば、time-a.nist.gov、time-b.nist.gov、129.6.15.29 です: 既定値は `null` です

XML パスが `/Root/Application` のパラメーター

プロパティ名 (Name)	プロパティのタイプ (Type)	プロパティの値 (Value) の説明
mpegdashMinBufferTime (バージョン 4.5.0 以降)	Integer	MPEG-DASH MPD の minBufferTime 属性を変更します: 既定値は 6000 (ライブストリームの場合) または 1500 (VODストリームの場合) です
mpegdashAddMPDSegmentBaseURL (バージョン 4.6.0 以降)	Boolean	`<BaseURL>` タグを MPD に含めるかどうかを制御します。 `<BaseURL>` の挿入を有効にするには値を true に設定します: 既定値 false です

Wowza Streaming Engine を使ったライブストリーミング (3)

Shige Fukushima — Tue, 28 Mar 2023 16:00:10 +0000

はじめに

前回の記事では FFmpeg で生成したマルチビットレートの RTMP ライブストリーム (マルチストリーム) をアップロードして、
Wowza Streaming Engine 経由でストリーミング配信を行うための設定を紹介しました。

この記事では、RTMP のシングルビットレートのライブソースを Wowza Streaming Engine に入力し、
Wowza Streaming Engine のトランスコーディング機能を使ってマルチビットレートのライブストリームを生成して、
アダプティブストリーミングのライブストリーミング配信を行うための方法を紹介します。

ライブソースのオリジンからマルチビットレートのストリームを Wowza Streaming Engine へ入力する際に十分なネットワーク帯域が確保できない場合、
一番画質のよいライブソースのみを Wowza Streaming Engine へ入力し、Wowza Streaming Engine でマルチビットレートの生成を行って、
アダプティブストリーミングのライブストリーミング配信を実現することができます。

作業の手順は、以下の通りです。

ライブソースストリームの入力セキュリティの設定 (省略)
FFmpeg によるビデオファイルを使った RTMP ライブソースの入力 (省略)
ライブトランスコーダーの設定
ライブストリーミング再生のテスト

Big Buck Bunny サイトのビデオコンテンツをサンプルとして使うストリーミングコンテンツとします。

配信で利用するビデオファイルはこちらを利用しました。

手順1: ライブソースの入力セキュリティの設定 (省略)

前回の記事で作成した設定を利用するため、ここでは省略します。

手順の詳細は、前回の記事を参照します。

手順2: ライブトランスコーダーの設定

Wowza Streaming Engine のライブトランスコーダーを設定すると、入力したライブソースのトランスコードを行うことができます。

ライブトランスコーダーを設定するには、以下の手順で行います。

ここでは既存のトランスコーダーテンプレートを利用します。

Wowza Streaming Engine Manager 管理 UI にログインし、上部メニューバーの [Application] をクリックします。
左のメニューから [live] アプリケーションをクリックし、[Transcoder] をクリックします。
[Edit] ボタンを押します。

以下のパラメーター情報を入力して、[Save] ボタンをクリックします。

パラメーター	値
Template Directory	既定のテンプレートを利用するため、既定値のままとします
Transcoder Options	チェックボックスを有効にしたままにします (Match source stream name to template name)
Fallback Template	"Transrate (Default)" (既定値) を選択します

トランスコーダーの "Status" が "Not Enabled" の場合、[Enable Transcoder] をクリックします。
画面上部の情報バーの [Restart Now] ボタンをクリックします。
アプリケーションの再起動が完了したら、準備完了です。

また、[Transcoder] 画面では、トランスコーダーのテンプレートをクリックすると、
トランスコーダーで生成するストリームの詳細を表示することができます。

トランスコーダーの生成するストリームごとに有効・無効の設定が異なる場合がありますが、
トランスコーダーのテンプレートの詳細画面から、プリセット名 (Preset) をクリックすると、そのストリームを有効・無効を変更することができます。

ここでは、以下の通り、160p, 360p, source を有効にします (既定値のとおり)。

注意: トランスコーダーを動作させる際には、Wowza Streaming Engine が動作している環境の CPU スペックが
トランスコード処理の合計に対して十分なキャパシティがあるかを確認してください。

手順3: FFmpeg によるビデオファイルを使ったライブソースの入力

前回の記事と同様に以下の FFmpeg コマンドで、ビデオファイルから生成したライブソースを Wowza Streaming Engine に入力します。

ffmpeg -threads 4 -re -stream_loop -1 \
  -i ~/videos/bbb_sunflower_1080p_30fps_normal.mp4 \
  -rtmp_live live -pix_fmt yuv420p -r 30 \
  -map 0:v:0 -c:v libx264 -preset veryfast -tune animation \
    -b:v 1500k -profile:v high -s:v 1280x720 -minrate:v 1500k -maxrate:v 1500k -bufsize:v 3000k \
    -flags:v +cgop -g 60 -x264opts keyint=60:keyint_min=60:no-scenecut \
    -sc_threshold 0 -crf 23 -vsync 1 \
  -map 0:1 -c:a aac -b:a 64k -ac 2 \
    -af:a aresample=async=1:min_hard_comp=0.100000:first_pts=0 \
  -f flv rtmp://[username]:[password]@[wowza_hostname]:1935/live/livestream1

この FFmpeg コマンドでは前回利用したビデオフィルターによるビットレートや時刻情報の埋め込みは行いません

ライブソースストリームの入力が開始したら、上部メニューバーの [Applications] をクリックし、
左のメニューから既定のライブアプリケーション (live) をクリックします。
次に、左のメニューから [Incoming Streams] をクリックすると、livestream1 という名前の入力ストリームと
トランスコーダーで生成したライブストリームが入力ストリームとして表示されていることが確認できます。

[View by Group] をクリックすると、複数のストリームをまとめたストリームグループが表示されます。

これらのグループは、トランスコーダーテンプレートで定義されたグループで、以下の例では、livestream1_all と livestream1_mobile の 2 つのグループが表示されています。

ストリームグループは、トランスコーダーテンプレートで自由にグループを定義できるため、必要に応じて、トランスコーダーのテンプレートを新しく作成したり、既存のテンプレートを変更したりします。

手順4: ライブストリーミング再生のテスト

手順3でライブストリームの入力が完了したら、ライブストリームの配信ができる状態になります。

ライブストリームの再生 URL は以下のように構成されます。

ngrp というプレフィックス名を使うことでストリームグループにアクセスすることができます。

ストリーミング形式	URL
HLS	https://[WowzaStreamingEngineのドメイン名]/[アプリケーション名]/ngrp:[入力ストリーム名]/playlist.m3u8
DASH	https://[WowzaStreamingEngineのドメイン名]/[アプリケーション名]/ngrp:[入力ストリーム名]/manifest.mpd

[アプリケーション名] は、この例では live となります。

[入力ストリーム名] は、この例では livestream1_all または livestream1_mobile となります。

Web プレイヤーを使って、再生のテストを行います。

まとめ

この記事では、FFmpeg で生成したシングルビットレートの RTMP ライブストリームをアップロードし、
Wowza Streaming Engine 経由でマルチビットレートのトランスコードを行って、
アダプティブストリーミング配信を行うための設定を紹介しました。

Wowza Streaming Engine を利用することで、RTMP, RTSP, SRT 等のライブストリームを Apple HLS, MPEG-DASH などの
ストリーミング形式に変換することができるようになります。
また、CDN と組み合わせを行うことで大規模なアダプティブストリーミング配信を実現することも可能となります。

Wowza Streaming Engine を使ったライブストリーミング (2)

Shige Fukushima — Tue, 28 Mar 2023 13:35:48 +0000

はじめに

前回の記事では FFmpeg で生成した RTMP ライブストリーム (シングルストリーム) をアップロードして、
Wowza Streaming Engine 経由でストリーミング配信を行うための設定を紹介しました。

この記事では、アダプティブストリーミングのライブストリーミング配信を行うための方法を紹介します。

作業の手順は、以下の通りです。

ライブソースストリームの入力セキュリティの設定 (省略)
FFmpeg によるビデオファイルを使った RTMP ライブソースの入力
SMIL ファイルの作成
ライブストリーミング再生のテスト

Big Buck Bunny サイトのビデオコンテンツをサンプルとして使うストリーミングコンテンツとします。

配信で利用するビデオファイルはこちらを利用しました。

手順1: ライブソースの入力セキュリティの設定 (省略)

前回の記事で作成した設定を利用するため、ここでは省略します。

手順の詳細は、前回の記事を参照します。

手順2: FFmpeg によるビデオファイルを使ったライブソースの入力

以下のコマンドを実行し、ビデオファイルとスクリプトファイルをダウンロードします。
スクリプトファイルは Gist で公開しているシェルスクリプトを利用します。

cd ~/
mkdir videos
cd videos
curl -O https://download.blender.org/demo/movies/BBB/bbb_sunflower_1080p_30fps_normal.mp4
curl -LO https://gist.github.com/liveinstantly/7969cc44d14e96c98434cf4e8744a15f/raw/88d2a83c77e01ff32262db04f739e5755efbd6a5/ffmpeg_filelive_abr_transcode.sh
chmod +x ffmpeg_filelive_abr_transcode.sh
curl -O https://wowzademostorage1.blob.core.windows.net/transcoding/liveencode_spec_sample.txt

以下のコマンドを実行して、ビデオのトランスコードとライブソースの入力を行います。

このスクリプトでは、ビデオファイルから複数のビットレートのライブストリームを生成し、Wowza Streaming Engine に入力します。
生成する複数のライブストリームの詳細は liveencode_spec_sample.txt ファイルで定義します。

./ffmpeg_filelive_abr_transcode.sh -f ~/videos/bbb_sunflower_1080p_30fps_normal.mp4 -s ./liveencode_spec_sample.txt -h **[WowzaStreamingEngineのドメイン名]** -a **live** -u **[username]** -p "**[password]**"

liveencode_spec_sample.txt ファイルは、コンマ区切りのファイルになっていて、以下の情報が含まれています。

ストリーム名	解像度(幅)	解像度(高さ)	ビットレート	プロファイル
livestream1	1280	720	1500	high
livestream2	960	540	800	baseline
livestream3	640	360	500	baseline

ライブソースストリームの入力が開始したら、上部メニューバーの [Applications] をクリックし、
左のメニューから既定のライブアプリケーション (live) をクリックします。
次に、左のメニューから [Incoming Streams] をクリックすると、livestream1, livestream2, livestream3 という名前のストリームが入力されていることが確認できます。

手順3: SMIL ファイルの作成

アダプティブストリーミング配信のために SMIL ファイルを作成します。

以下の SMIL ファイル (XML ファイル) を作成し /usr/local/WowzaStreamingEngine/content ディレクトリに追加します。

liveencode_spec_sample.txt ファイルの詳細情報に従って、以下のように SMIL ファイルを定義します。

<?xml version="1.0" encoding="UTF-8"?>
<smil title="Sample SMIL file for Live Adaptive Streaming">
  <body>
    <switch>
      <video height="720" src="livestream1" systemLanguage="eng" width="1280">
        <param name="videoBitrate" value="1500000" valuetype="data"></param>
        <param name="audioBitrate" value="128000" valuetype="data"></param>
      </video>
      <video height="540" src="livestream2" systemLanguage="eng" width="960">
        <param name="videoBitrate" value="800000" valuetype="data"></param>
        <param name="audioBitrate" value="64000" valuetype="data"></param>
      </video>
      <video height="360" src="livestream3" systemLanguage="eng" width="640">
        <param name="videoBitrate" value="500000" valuetype="data"></param>
        <param name="audioBitrate" value="64000" valuetype="data"></param>
      </video>
    </switch>
  </body>
</smil>

手順4: ライブストリーミング再生のテスト

手順2でライブストリームの入力が完了したら、ライブストリームの配信ができる状態になります。

ライブストリームの再生 URL は以下のように構成されます。

ストリーミング形式	URL
HLS	https://[WowzaStreamingEngineのドメイン名]/[アプリケーション名]/smil:[SMILファイル名]/playlist.m3u8
DASH	https://[WowzaStreamingEngineのドメイン名]/[アプリケーション名]/smil:[SMILファイル名]/manifest.mpd

[アプリケーション名] は、この例では live となります。

[SMILファイル名] は、この例では adaptivelivestream となります。

Web プレイヤーを使って、再生のテストを行います。

まとめ

この記事では、FFmpeg で生成したマルチビットレートの RTMP ライブストリームをアップロードして、
Wowza Streaming Engine 経由でストリーミング配信を行うための設定を紹介しました。

Wowza Streaming Engine を利用することで、RTMP, RTSP, SRT 等のライブストリームを Apple HLS, MPEG-DASH などの
ストリーミング形式に変換することができるようになります。また、CDN と組み合わせを行うことで大規模な HTTP ベースの
アダプティブストリーミング配信を実現することも可能となります。

Wowza Streaming Engine を使ったライブストリーミング (1)

Shige Fukushima — Tue, 28 Mar 2023 13:35:37 +0000

はじめに

この記事では、Wowza Streaming Engine でライブストリーミング配信を行うためのセットアップを行います。

ライブ配信は、Wowza Streaming Engine にライブソースストリームを入力し、そのライブストリームをストリーミング方式に変換して、ライブストリーミング配信を行います。

作業の手順は、以下の通りです。

ライブソースストリームの入力セキュリティの設定
FFmpeg によるビデオファイルを使った RTMP ライブソースの入力
ライブストリーミング再生のテスト

Big Buck Bunny サイトのビデオコンテンツをサンプルとして使うストリーミングコンテンツとします。

配信で利用するビデオファイルはこちらを利用しました。

手順1: ライブソースの入力セキュリティの設定

Wowza Streaming Engine にライブソースストリームを入力する際にパスワードで認証を行うことにより、
ライブソースの入力セキュリティを確保することができます。

ライブソースの入力セキュリティを設定にするには、以下の手順で行います。

Wowza Streaming Engine Manager 管理 UI にログインし、上部メニューバーの [Server] をクリックします。
左のメニューから [Source Authentication] をクリックします。
[+Add Source] ボタンを押します。
以下のパラメーター情報を入力して、[+Add] ボタンをクリックします。

パラメーター値

Source User Name ソース認証のユーザー名: 例: livestream1

Source Password (Confirm Password) ソース認証のパスワード

注意: ユーザー名とパスワードの値は、大文字と小文字が区別され、英数字、ピリオド (.)、アンダースコア (_)、およびハイフン (-) 文字のみを含めることができます。
上部メニューバーの [Applications] をクリックし、左のメニューから既定のライブアプリケーション (live) をクリックします。
左のメニューから [Source Security] をクリックし、ソースセキュリティの設定を確認します。
- [RTMP Sources] が Require password authentication となっているかを確認する。
- もし設定が異なる場合は、[Edit] ボタンをクリックし、設定変更を行う。

パラメーター	値
Source User Name	ソース認証のユーザー名: 例: `livestream1`
Source Password (Confirm Password)	ソース認証のパスワード

手順2: FFmpeg によるビデオファイルを使ったライブソースの入力

以下のコマンドを実行し、ビデオファイルをダウンロードします。

cd ~/
mkdir videos
cd videos
curl -O https://download.blender.org/demo/movies/BBB/bbb_sunflower_1080p_30fps_normal.mp4

ビデオのダウンロードが完了したら、FFmpeg ツールを使ってダウンロードしたビデオファイルから、
次の FFmpeg コマンドを使って、RTMP ライブソースストリームを生成し、Wowza Streaming Engine の live アプリケーションに入力します。

ライブソースストリームの入力 URL には、手順1で設定したソース認証のユーザー名 ([username]) と
ソース認証のパスワード ([password]) を正しく指定します。

ffmpeg -threads 4 -re -stream_loop -1 \
  -i ~/videos/bbb_sunflower_1080p_30fps_normal.mp4 \
  -rtmp_live live -pix_fmt yuv420p -r 30 \
  -map 0:v:0 -c:v libx264 -preset veryfast -tune animation \
    -b:v 1500k -profile:v high -s:v 1280x720 -minrate:v 1500k -maxrate:v 1500k -bufsize:v 3000k \
    -flags:v +cgop -g 60 -x264opts keyint=60:keyint_min=60:no-scenecut \
    -sc_threshold 0 -crf 23 -vsync 1 \
    -filter:v drawtext=:text=(bitrate=1500K):fontsize=32:x=32:y=32:box=1:boxcolor=white:fontcolor=black,drawtext=:text=%{localtime}:x=32:y=64:fontsize=32:box=1:boxcolor=white:fontcolor=black,drawtext=:text=%{pts\\:hms}:x=32:y=96:fontsize=32:box=1:boxcolor=white:fontcolor=black \
  -map 0:1 -c:a aac -b:a 64k -ac 2 \
    -af:a aresample=async=1:min_hard_comp=0.100000:first_pts=0 \
  -f flv rtmp://[username]:[password]@[wowza_hostname]:1935/live/livestream1

この FFmpeg を使ったコマンドでは、ビデオファイルを 1280x720 の解像度でエンコードしたストリームで RTMP ストリームを生成しています。
エンコード時に、ビデオフィルター機能を使って、現在の日時・時刻の情報を映像に埋め込む処理をしています。

ライブソースストリームの入力が開始したら、上部メニューバーの [Applications] をクリックし、
左のメニューから既定のライブアプリケーション (live) をクリックします。
次に、左のメニューから [Incoming Streams] をクリックすると、livestream1 という名前の
ストリームが入力されていることが確認できます。

手順3: ライブストリーミング再生のテスト

手順2でライブストリームの入力が完了したら、ライブストリームの配信ができる状態になります。

ライブストリームの再生 URL は以下のように構成されます。

ストリーミング形式	URL
HLS	https://[WowzaStreamingEngineのドメイン名]/[アプリケーション名]/[入力ストリーム名]/playlist.m3u8
DASH	https://[WowzaStreamingEngineのドメイン名]/[アプリケーション名]/[入力ストリーム名]/manifest.mpd

[アプリケーション名] は、この例では live となります。

[入力ストリーム名] は、この例では livestream1 となります。

Web プレイヤーを使って、再生のテストを行います。

まとめ

この記事では、FFmpeg で生成した RTMP ライブストリームをアップロードして、Wowza Streaming Engine 経由で
ストリーミング配信を行うための設定を紹介しました。

Wowza Streaming Engine を使った VOD ストリーミングのセットアップ

Shige Fukushima — Tue, 28 Mar 2023 13:32:15 +0000

はじめに

この記事では、Wowza Streaming Engine で VOD (ビデオ・オンデマンド) でストリーミングコンテンツの配信を行うためのセットアップを行います。

作業の手順は、以下の通りです。

アダプティブストリーミング用の VOD ファイルの作成
SMIL ファイルの作成
ビデオファイルのアップロード
Wowza Streaming Engine のセットアップ
アダプティブストリーミング再生のテスト

Big Buck Bunny サイトのビデオコンテンツをサンプルとして使うストリーミングコンテンツとします。

配信で利用するビデオファイルはこちらを利用しました。

手順1: アダプティブストリーミング用の VOD ファイルの作成

アダプティブストリーミング方式でのストリーミング再生では、プレイヤーのネットワーク接続の帯域幅に合わせて複数のビットレートと解像度のビデオを切り替えながら、ストリーミングビデオを再生します。まず、FFmpeg ツールを使って、オリジナルのビデオファイルから、複数のビットレートの MP4 ファイルを作成します。

Ubuntu Linux への FFmpeg のインストールは以下のコマンドを実行します。

sudo apt install ffmpeg

参考までに、利用した FFmpeg のバージョンは以下になります。

  $ ffmpeg -version
  ffmpeg version 4.4.2-0ubuntu0.22.04.1 Copyright (c) 2000-2021 the FFmpeg developers

FFmpeg を使った複数ビットレートの MP4 のトランスコードにあたり、Gist で公開しているシェルスクリプトを利用します。以下のコマンドを実行して、ビデオのダウンロード、トランスコードを行います。

cd ~/
mkdir videos
cd videos
curl -O https://download.blender.org/demo/movies/BBB/bbb_sunflower_1080p_30fps_normal.mp4
curl -LO https://gist.github.com/liveinstantly/adfdcdeb8ab2a4ecb7fe2b3844ef5cac/raw/a2b0272dd06f9676a02cc6f0ff812123e0490742/ffmpeg_abr_transcode.sh
curl -O https://wowzademostorage1.blob.core.windows.net/transcoding/encode_spec_sample.txt
chmod +x ffmpeg_abr_transcode.sh
./ffmpeg_abr_transcode.sh bbb_sunflower_1080p_30fps_normal.mp4 BigBuckBunny-h264-1080p-30fps encode_spec_sample.txt
mkdir bigbuckbunny-1080p-30fps-h264
mv BigBuckBunny-h264-1080p-30fps*.mp4 bigbuckbunny-1080p-30fps-h264/

生成された MP4 ビデオファイルは以下の通りです。

BigBuckBunny-h264-1080p-30fps_0400_320x180.mp4
BigBuckBunny-h264-1080p-30fps_0650_640x360.mp4
BigBuckBunny-h264-1080p-30fps_1000_640x360.mp4
BigBuckBunny-h264-1080p-30fps_1500_960x540.mp4
BigBuckBunny-h264-1080p-30fps_2250_960x540.mp4
BigBuckBunny-h264-1080p-30fps_3400_1280x720.mp4
BigBuckBunny-h264-1080p-30fps_4700_1920x1080.mp4
BigBuckBunny-h264-1080p-30fps_6000_1920x1080.mp4

手順2: SMIL ファイルの作成

アダプティブストリーミング方式での配信用に SMIL ファイルを作成します。

下記の XML (SMIL) ファイルを ~/videos/bbb_h264_1080p_30fps.smil に保存します。

<?xml version="1.0" encoding="UTF-8"?>
<smil title="Big Buck Bunny H264 1080p 30fps Adaptive Bitrate sample content">
    <body>
        <switch>
            <!-- BigBuckBunny-h264-1080p-30fps_0400_320x180.mp4 -->
            <video width="320" height="180" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_0400_320x180.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="400000" valuetype="data"></param>
                <param name="audioBitrate"  value="64000" valuetype="data"></param>
            </video>
            <!-- BigBuckBunny-h264-1080p-30fps_0650_640x360.mp4 -->
            <video width="640" height="360" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_0650_640x360.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="650000" valuetype="data"></param>
                <param name="audioBitrate"  value="64000" valuetype="data"></param>
            </video>
            <!-- BigBuckBunny-h264-1080p-30fps_1000_640x360.mp4 -->
            <video width="640" height="360" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_1000_640x360.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="1000000" valuetype="data"></param>
                <param name="audioBitrate"   value="64000" valuetype="data"></param>
            </video>
            <!-- BigBuckBunny-h264-1080p-30fps_1500_960x540.mp4 -->
            <video width="960" height="540" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_1500_960x540.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="1500000" valuetype="data"></param>
                <param name="audioBitrate"   value="64000" valuetype="data"></param>
            </video>
            <!-- BigBuckBunny-h264-1080p-30fps_2250_960x540.mp4 -->
            <video width="960" height="540" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_2250_960x540.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="2250000" valuetype="data"></param>
                <param name="audioBitrate"   value="64000" valuetype="data"></param>
            </video>
            <!-- BigBuckBunny-h264-1080p-30fps_3400_1280x720.mp4 -->
            <video width="1280" height="720" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_3400_1280x720.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="3400000" valuetype="data"></param>
                <param name="audioBitrate"   value="128000" valuetype="data"></param>
            </video>
            <!-- BigBuckBunny-h264-1080p-30fps_4700_1920x1080.mp4 -->
            <video width="1920" height="1080" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_4700_1920x1080.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="4700000" valuetype="data"></param>
                <param name="audioBitrate"   value="128000" valuetype="data"></param>
            </video>
            <!-- BigBuckBunny-h264-1080p-30fps_6000_1920x1080.mp4 -->
            <video width="1920" height="1080" src="bigbuckbunny-1080p-30fps-h264/BigBuckBunny-h264-1080p-30fps_6000_1920x1080.mp4" systemLanguage="eng">
                <param name="videoBitrate" value="6000000" valuetype="data"></param>
                <param name="audioBitrate"   value="128000" valuetype="data"></param>
            </video>
        </switch>
    </body>
</smil>

注意: SMIL ファイルは階層化されたディレクトリには配置できないため、ソースファイルを階層化する場合は src 属性を相対パスで記載します。

手順3: ビデオファイルのアップロード

Wowza Streaming Engine では VOD 配信用に以下の3つのアプリケーションのタイプがあります。

タイプ	説明
VOD	単一サーバー向けのアプリケーション (VOD ファイルを読み込み、プレーヤーにストリーミングするために使用します)
VOD Edge	メディアキャッシュソースから VOD ファイルを取り込み、VOD ファイルをプレーヤーにストリーミングするために使用します
VOD HTTP Origin	ビデオ・オンデマンドファイルのオリジンとして動作し、HTTP ストリーミングプロトコル (MPEG-DASH および Apple HLS) を使用して HTTP キャッシングインフラストラクチャに配信するために使用します

Wowza Streaming Engine のインストール後の既定のセットアップでは、"VOD" タイプのアプリケーションが自動的にセットアップされていて、既定では [インストール先のディレクトリ]\content フォルダから VOD ファイルを読み込みます。

手順1と手順2で作成したファイルを content フォルダにコピーしても構いません。

この記事では、メディアキャッシュ機能を使って外部のクラウドストレージにアップロードした VOD ファイルを配信するよう設定します。

外部のクラウドストレージとして、Azure Storage を使ってみます。Azure CLI の手順を以下に説明しますので、「Azure CLI をインストールする方法」を参考に Azure CLI をインストールしてください。

export AZ_LOCATION=japanwest
export AZ_RESOURCE_GROUP=YourResourceGroup
export AZ_STORAGE_ACCOUNT=wowzavodstorage
az group create --resource-group ${AZ_RESOURCE_GROUP} --location ${AZ_LOCATION}
az storage account create --name ${AZ_STORAGE_ACCOUNT} --resource-group ${AZ_RESOURCE_GROUP} --location ${AZ_LOCATION} --sku Standard_LRS
AZ_STORAGE_KEY=$(az storage account keys list --account-name ${AZ_STORAGE_ACCOUNT} --resource-group ${AZ_RESOURCE_GROUP} | jq -r .[0].value)
az storage container create --name vod --account-name ${AZ_STORAGE_ACCOUNT} --account-key "${AZ_STORAGE_KEY}"
cd ~/videos/
az storage copy -s bigbuckbunny-1080p-30fps-h264 --destination-container vod --account-name ${AZ_STORAGE_ACCOUNT} --account-key ${AZ_STORAGE_KEY} --recursive

手順4: Wowza Streaming Engine のセットアップ

コンテンツのアップロードが完了したら、以下の手順で Wowza Streaming Engine のセットアップを行います。

メディアキャッシュの有効化

メディアキャッシュ機能を有効にするには、以下の手順で行います。

Wowza Streaming Engine Manager 管理 UI にログインし、上部メニューバーの [Server] をクリックします。
左のメニューから [Media Cache] をクリックします。
"Status: Enabled" と表示されている場合は、すでに有効になっているため、以降のステップは必要はありません。
[Enable Media Cache] ボタンを押します。
画面上部に [Media Cache enabled. You must restart the server for changes to take effect.] と表示されたら、[Restart Now] ボタンをクリックします。

メディアキャッシュソースの追加

メディアキャッシュソースとして、Azure Blob Storage を追加するには、以下の手順で行います。

Wowza Streaming Engine Manager 管理 UI にログインし、上部メニューバーの [Server] をクリックします。
左のメニューから [Media Cache] をクリックします。
[Source] タブをクリックし、[+Add Media Cache Source] ボタンを押します。

以下のパラメーター情報を入力して、[+Add] ボタンをクリックします。

パラメーター	値
Source Name	Azure Blob Storage のメディアソースキャッシュの任意の名前: 例: `Azure:wowzavodstorage`
Description	Azure Blob Storage のメディアソースキャッシュの説明 (任意)
Source Type	メディアキャッシュソースのタイプ: `Azure`
Prefix	メディアキャッシュソースのプレフィックス: `azblob/`
Blob Storage Account Name	Azure Blob Storage アカウントの名前: `wowzavodstorage`
Blob Storage Account Access Key	Azure Blob Storage アカウント鍵: `${AZ_STORAGE_KEY}` の値

VOD Edge アプリケーションの作成

VOD Edge アプリケーションの作成は、以下の手順で行います。

Wowza Streaming Engine Manager 管理 UI にログインし、上部メニューバーの [Applications] の ▼ をクリックし、[Add Application] をクリックします。
VOD Edge のボタンをクリックし、[Enter a name for your new application] のテキストボックスに "vodedge" と入力し、[+Add] ボタンをクリックします。
[Playback Types] では、配信に必要となる方式の項目をチェックします (ここではすべての項目をチェックします)。
[Media Cache Source] では、[All Media Cache Sources are available] を選択します。
[Closed Caption Sources] では、配信に必要となる字幕形式の項目をチェックします (ここではすべての項目をチェックします)。
[Save] ボタンをクリックし、VOD Edge アプリケーション設定を保存します。

手順5: アダプティブストリーミング再生のテスト

手順3でコンテンツのアップロードと手順4が完了したら、VOD ファイルの配信ができる状態になります。

SMIL ファイルのメディアキャッシュソースの再生 URL は以下のように構成されます。

http(s)://[Wowza Streaming Engine のドメイン名]/[VOD Edgeアプリケーション名]/_definst_/smil:[Media Cache Source Prefix][Media Source の Path]/[Manifest]

[Manifest] は playlist.m3u8 または manifest.mpd

VOD コンテンツの再生 URL は、以下の通りです。

ストリーミング形式	URL
HLS	https://[WowzaStreamingEngineのドメイン名]/vodedge/_definst_/smil:azblob/bbb_h264_1080p_30fps.smil/playlist.m3u8
DASH	https://[WowzaStreamingEngineのドメイン名]/vodedge/_definst_/smil:azblob/bbb_h264_1080p_30fps.smil/manifest.mpd

Web プレイヤーを使って、再生のテストを行います。

メディアキャッシュソース上の MP4 ファイルに対して、RTMP や RTSP での配信も可能です。

再生 URL の中の "smil:" の代わりに "mp4:" を使います。

まとめ

この記事では、VOD ファイルをクラウドストレージにアップロードして、Wowza Streaming Engine 経由で
ストリーミング配信を行うための設定を紹介しました。

Wowza Streaming Engine を利用することで、マルチビットレートの MP4 ファイルを Apple HLS, MPEG-DASH などの
ストリーミング形式に変換することができるようになります。

複数の Wowza Streaming Engine サーバーを導入することでスケーラビリティ高い配信を実現することもできます。
また、さらに CDN と組み合わせを行うことで大規模な HTTP ベースのアダプティブストリーミング配信を実現することも可能となります。

DEV Community: Shige Fukushima

Lenovo TrackPoint Keyboard のチルトスタンドが折れた

キーボードのチルトスタンド (高さ調整用の脚) が折れた

他のユーザーも同様の状況に遭遇している

3Dプリンターでプリントアウトしたチルトスタンド

出品されているものを買ってみた

Hyper-V ホストのネットワークパフォーマンスの改善

はじめに

どのようなパフォーマンスの問題があったのか？

ネットワーク アーキテクチャの理解

問題の解決方法: LSO の無効化

LSO 無効化後のネットワーク速度の確認

最後に

Ubuntu VM のセキュアブートの有効化

はじめに

セキュアブートの有効化

1) Grub EFI パッケージの取得

2) Grub EFI のインストール

3) セキュアブートの有効化

正常に起動しない場合

セキュアブートが有効になっているかどうかの確認方法

最後に

Ubuntu Linux 起動ディスクを BIOS ブートから EFI ブートへ変換

はじめに

Ubuntu Linux 起動ディスクを BIOS ブートから EFI ブートへ変換

ステップ 1: 新しい第 2 世代 Hyper-V 仮想マシンの作成

ステップ 2: パーティションのサイズの縮小

ステップ 2-1: パーティションの確認

ステップ 2-2: 論理ボリュームのサイズを縮小する

1) 空き容量の確認

2) ファイルシステムのエラーチェック

3) ファイルシステムのサイズの縮小

4) 論理ボリュームのサイズの縮小

ステップ 2-3: 物理ボリュームのサイズを縮小する

ステップ 2-4: パーティション テーブルの変更

ステップ 3: EFI パーティションの作成

1) EFI パーティション テーブルの作成

2) EFI パーティションのフォーマット

ステップ 4: Grub EFI のインストール

1) 起動ディスクのマウント

2) boot パーティションのバックアップ

3) Grub EFI パッケージの取得

4) Grub EFI のインストール

ステップ 5: /etc/fstab の編集

最後に

仮想ディスクの変換 (VMDK 形式から VHD/VHDX 形式への変換)

はじめに

VMDK ディスクを VHD/VHDX ディスクへ変換する

MVMC (Microsoft Virtual Machine Converter) のインストール

仮想ディスク変換ツールの実行

Disk Database Entry に関する変換エラーが出る場合

最後に

Ubuntu VM の移行 (VMware から Hyper-V へ)

VMware 仮想マシンを Hyper-V へ移行する

ステップ 1: VMDK ディスクを VHD/VHDX ディスクへ変換する

ステップ 2: 新しい Hyper-V 仮想マシンを作成

ステップ 3: open-vm-tools のアンインストール

ステップ 4: (オプション) 第2世代 Hyper-V 仮想マシン用の仮想ディスクへ変換

ステップ 5: (オプション) Secure Boot の有効化

ステップ 6: Hyper-V 統合サービスのインストール

移行後のその他の作業

ネットワークインターフェースの変更

/dev/fd0 に関するエラー

まとめ

Wowza Streaming Engine での HLS ストリーミング

はじめに

HLS プレイリスト (マニフェスト) について

HLS セグメントの長さについて

VOD ストリーミングのセグメントの長さの設定パラメーター

ライブストリーミングのセグメントの長さの設定パラメーター

HLS Audio-only ストリームの設定

VOD HLS Audio-only ストリームの設定

ライブ HLS Audio-only ストリームの設定

HLS KeyFrames-only プレイリストの設定

HLS Audioストリームの TS パッケージングの設定

VOD HLS Audio ストリームの TS パッケージングの設定

ライブ HLS Audio ストリームの TS パッケージングの設定

タイムコードに基づいたライブストリームのセグメントの番号付けの設定

Wowza Streaming Engine での MPEG-DASH ストリーミング

はじめに

ネットワークアーキテクチャの理解

ステップ 2-4: パーティションテーブルの変更

1) EFI パーティションテーブルの作成

XML パスが `/Root/Application/HTTPStreamer` のパラメーター

XML パスが `/Root/Application` のパラメーター

メディアキャッシュソースの追加