-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: speaker_info
のリソースをURLで返すようにする
#1318
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
非常に雑なコードでテストも書いていません。
ここから問題点の洗い出しや設計方針の決定ができていければと思います。
@@ -78,6 +78,7 @@ def __init__(self, engine_speakers_path: Path) -> None: | |||
**json.loads((folder / "metas.json").read_text(encoding="utf-8")) | |||
) | |||
for folder in engine_speakers_path.iterdir() | |||
if folder.is_dir() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
speaker_info
にファイルがあるとエラーが発生する。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
プルリクエストありがとうございます!!
よりすっきりした設計できるなと感じました!!
ということで提案です・・・!(なんかどこか考慮漏れありそう)
たぶん、元のリソースファイル名にハッシュ値を足す形だと思うのですが、元のファイル名無視してハッシュ値だけのファイル名にすれば設計がかなり減る気がしました!
ルールが減るのと、ディレクトリ構造を意識しなくて済むのと、speakerUuid
やfilemap.json
の有無が関係なくなるので便利になるんじゃないかなと。
こんな感じをイメージしてます。
↓元
resources/speaker_infos/speakerA/icon.png
resources/speaker_infos/speakerA/potrtait.png
...
↓filemap作成後(ビルド時)
resources/HASH_A1
resources/HASH_A2
resources/filemap.json
...
↓resources/filemap.jsonの中身
{
"speaker_infos/speakerA/icon.png": "HASH_A1.png",
"speaker_infos/speakerA/potrtait.png": "HASH_A2.png",
...
}
実装手順はこんな感じ?
-
filemapUtility
みたいなクラスを作って、中でfilemap.jsonを読み込んでマッピングを持っておき、resourcePath
を受け取ってハッシュ値を返す。ハッシュ化されてなかったらそのままのパスを返すようにする。 -
filemapUtility
を使うとこ(/speaker_info
)で、アイコンなどのリソースパスをfilemapUtility
に渡してハッシュ値を返してもらい、URL を作って返す。 -
あとは
def static
APIはresourcePath
(ものによってはハッシュ値になってる)を受け取るようにし、ファイル名に従ったリソースファイルを返して終わり!たぶんなんならFastAPIのStaticFiles
に置き換えられる。 -
ビルド時に
filemap.json
を作る -
(オプション)製品版はハッシュ値になったリソースファイルのみを使いたいので、ハッシュ値になってないファイルへのgetが来たらエラーを返しても良いかも。
ハッシュ値はただのファイル名になってるので、def static
はspeakerUuid
などを気にしなくて良くなってます。
あとfilemap.json
を用意しなくても動くので、OSSでfilemap.json
を更新し続けるメンテナンスをしなくて大丈夫になります。
あとspeaker_info
以外がリソースパスのハッシュ化を使う時もそのまま流用できるはず!
@@ -50,6 +50,9 @@ class SupportedFeatures(BaseModel): | |||
manage_library: bool | None = Field( | |||
title="音声ライブラリのインストール・アンインストール" | |||
) | |||
resource_url: bool | None = Field( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
他が全部動詞始まりなので、return_resource_url
が良いかも。
まあでもこの値に関係なく古いエンジンでも新しいエンジンでもresource_url=True
を引数に渡せば良い気もするので、もしかしたらいらないかも・・・?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FastAPIは大丈夫ですが他のフレームワークは大丈夫なのでしょうか?
それとも未知のクエリを受け取ったとき無視することが一般的なのでしょうか?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
少なくともデフォルトで無視しないフレームワークは無いかもです。
気になってるのは、これを考慮することでエディタ側でのコードが複雑化しないかという点だけだったりします。
実装してみた感じ、どうでしたか・・・?(manifestへのアクセスが簡単だったらわりと簡単そう)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
そもそもソングAPIの有無をマニフェストのsing
で確認しているので簡単ですね。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
たしかに問題なさそうでした!
まあ、マニフェストにreturn_resource_url
的なの追加しますかー・・・!
というかよく考えたらこのフラグがないとresource_url
に対応しているかわからないから、返ってきたものがURLかどうかを判定するコードを書かないとかもですね。エディタ以外のサードパーティとかだと。
となるといろいろ不便なので、マニフェストにフラグあるべきな気がしてきました!!
filemapUtilityクラスのようなもので管理するのはいいと思いますが また |
ちゃんとわかってないかもなのですが、例えば製品版では
まあ少なくともSHA256にしておけばハッシュの衝突は考えなくて大丈夫です!
これは完全に盲点でした・・・。だいぶ僕の中の前提が崩れました、ご指摘ありがとうございます!!!!! ちょっと考え直してみたので書きます 🙏 |
リソースURL系APIは
あとファイルパスを キャラクターリソースのAPIは 一旦こんなところで。。。 🙇 |
@Hiroshiba とりあえず開発時には ところでリソース系APIについてドキュメントの欠如やキャッシュ周り扱いにくさからポータルページ等が使用するリソースやスクリプト等を配置するくらいしか思い浮かばないのですが他にどのような用途を考えていますか? |
`filemap.json`の構造変更 ハッシュアルゴリズムをsha256へ リソースの管理をクラスで行う
クラスで管理するように変更しました。 |
製品版検知、これが使えそう?:https://pyinstaller.org/en/stable/runtime-information.html |
voicevox_engine/voicevox_engine/utility/path_utility.py Lines 33 to 46 in 9f0d403
説明不足ですみません、これが使えることは気づいていますがマージまで時間がかかることは目に見えているのでコンフリクト解消の手間を減らすためにとりあえず固定値にしたという感じです。 ( path_utility の内部関数なので適切に切り出す必要がある)
|
意図がちょっとわかってないのですが、今後いくらでも増える可能性があるだろうな〜とは思います。サンプル音楽の配布とか。 |
requestからURL取ってると思ってて、そこにport番号も付く感じだと思うので大丈夫な気がします。 |
build_util/file_map.py
Outdated
|
||
def main() -> None: | ||
parser = ArgumentParser() | ||
parser.add_argument("--save", type=Path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
意味的にはoutput_pathかな
ファイルパスなら_file
、ディレクトリパスなら_dir
にしとくとわかりやすいかもです
build_util/file_map.py
Outdated
def main() -> None: | ||
parser = ArgumentParser() | ||
parser.add_argument("--save", type=Path) | ||
parser.add_argument("--target", default=SPEAKER_INFO_DIR, type=Path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
こちらもtarget_dir
にしとくとちょっとわかりやすいかもです
まあrun.pyと統一感があるかな、くらいですが。
build_util/file_map.py
Outdated
def mapping(target: Path) -> dict[str, str]: | ||
return { | ||
to_posix_str_path(filepath): filehash | ||
for filepath, filehash in walk_character_files(target, ("wav", "png")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
("wav", "png")
も与えられるようにしておくと使い回すときに便利&コマンド実行時に対象がわかって便利かも。
まあ過剰かもなので、とりあえず定数としてファイルの一番上に定義する形でも良さそう。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
一応--target_suffix
で変更可能にしておきました。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
すみません、まだだったかもなのですがドキュメントにコメントしました!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
指摘部分の修正完了しました。
再レビューOKになったら右上のReviewersのre-review requestなどで合図をいただけると! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ほぼLGTMです!!!
細かい部分だけコメントさせていただきました!!
Co-authored-by: Hiroshiba <[email protected]>
Co-authored-by: Hiroshiba <[email protected]>
Co-authored-by: Hiroshiba <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!!!
こちらで少し変えさせていただきます!!
@tarepan
実装周りの共有です!
APIドキュメントには乗らないGET /_resources/
APIで、キャラごとの画像・音声ファイルを返せる形になります。
/speaker_info
などで引数でurl
を指定するとURLが返ります。
キャッシュをなくすために、URLはリソースファイルのハッシュ値を含めています。
ハッシュはResourceManagerにて、パスとハッシュを対応付ける形で管理しています。
その対応マップをfilemapと呼んでいます。
filemapは事前にgenerate_filemap.pyで作成できます。
/_resources/
APIは現状speaker
routerで行っています。
より良い設計が思いつかず、一旦この形の実装で落ち着いた感じです 🙇
内容
/speaker_info
/singer_info
の画像と音声ファイルをURLで返し、そのURLから取得できるように変更します。評価・議論のため開発速度重視で雑に実装しています。
現時点ではマージするべきではない状態なのでDraftです。
関連 Issue
その他
エディタ側の対応PR