Marumo ISDB Splitter ver. 0.2.9 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。
バグ報告＆機能提案してくださった方に感謝します。結局、追いかけ再生に関しては確保済みファイルサイズから最終的なコンテンツ長を推定してアプリケーション側に渡すように変更しました。内部構造をだいぶ変更しなければいけないため躊躇していたのですが、こちらの仕様の方がより望ましい挙動であると判断したので変更しました。
追いかけ再生時に録画済み範囲を超えてシークしようとした場合、録画済み範囲にシーク先は巻き戻されます。普通の使い方をしている場合、この挙動で問題ないと思いますが、より望ましい挙動と思われる仕様があれば連絡してください。
Marumo ISDB Splitter ver. 0.2.10 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。
バグ報告してくれた方に感謝します。今回の主たる変更点は、最初の「再生終了時に CPU 使用率が異常に上昇することがあるバグの修正」なのですが、それに加えて Qonoha ver. 2.0.26 がストリーム名の表示に対応してくれたので、言語コードを返さない仕様に戻す変更も行っています。
この仕様で何か困ることがある人がいる場合、連絡いただければ再検討します。
Marumo ISDB Splitter ver. 0.2.12 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。
バグ報告してくれた方に感謝します。ver. 0.2.9 で追いかけ再生に対処するため PCR の解釈処理を移動させた際にコードの修正が不十分だったためにエンバグしていました。
この記事は元々は ver. 0.2.11 の公開を伝えるものでしたが、ver. 0.2.11 にも未修正のバグが存在していたため、同日中という事情もあり ver. 0.2.12 の公開も併せて伝える形に書き換えています。
ver. 0.2.12 で修正したシークの不具合は 2ch DTV 板 TS 関連ソフトスレ part.11 の 837/840 さんが報告してくれたものです。840 の書き込みでは状況が違うということでしたが、おそらくアプリケーション側で認識している再生位置が終端にワープしてから再度 N 秒戻るを実行した場合は、終端からの相対移動となるためにループしていると誤解したのではないかと考えています。
同じく ver. 0.2.12 で変更した仕様の「終端」へのシークについてです。こちらは同じ TS 関連ソフトスレの 828 さん等、気にされている方がいたようなのでこの機会に変更しました。
少し事情が入り組んでいるので説明を書いておくと、ver. 0.2.11 までのバージョンでは「終端」ジャストへのシークは全て無視 (興味がある人は src/dsf/filter.cpp の SetPositions() メソッドの中に怪しげなコメントが書いてあるので確認してみてください) していました。今回の仕様変更は「終端から 1 秒以内の場所に居る時以外は、終端へのシークも受け付けるようにする」というものです。
この時、実際のシーク先の位置は、コンテンツ終端から大体 0.5〜1 秒ぐらい手前のどこかになります。これはこのフィルタのシーク仕様（指定した時間から 0.5〜1 秒の誤差が出る）の制限によるものです。
Marumo ISDB Splitter ver. 0.2.13 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。
バグ報告してくれた方に感謝します。ver. 0.2.11 での修正の際に見落としがあり、バグを埋め込んでしまっていました。
MPEG-2 VIDEO VFAPI Plug-In ver. 0.7.7 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。
バグ報告＆サンプル提供してくれた方に感謝します。PAT/PMT の解釈処理に問題があり、一部の TS ファイルを読み込んだ際に不正アクセス例外（0xC000005）を出すことがあったバグの修正がメインです。
また、リリース前に検証していたところ、ver. 0.7.6 を公開する際に、色差補間処理で SIMD 版を呼ばないようにしていた実験コードのままリリースしていた問題に気付いたので、その修正も行っています。
ver. 0.7.6 が旧バージョン比で遅くなると報告していただいた方々には修正までに時間がかかってしまい申し訳ありませんでした。
Marumo ISDB Splitter ver. 0.2.14 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。
バグ報告してくれた方に感謝します。追いかけ再生中に（ほぼ追い付いている状況で）録画完了コンテンツの終端に到達して再生終了する際に、例外を発生させてアプリケーションを巻き添えに落ちるバグの修正をしています。
一回の試行に必要な時間が長かったため、原因の特定に時間がかかり、現象確認から修正完了までお待たせすることになってしまいました。申し訳ありません。
MPEG-2 VIDEO VFAPI Plug-In ver. 0.7.7 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。
フィールド構造ピクチャというのは、二つの独立したフィールドピクチャで一枚のフレームを構成する形式で、H.264 ではフレーム AFF などと呼ばれている形式のストリームのことです。
この形式を利用しているストリームの場合に、ストリームの終端部分が片方のフィールドだけで切れてしまっていた場合に GOP リスト構築に失敗してファイルを開けなくなっていたのが今回修正した問題の原因でした。
バグ報告＆サンプルを提供してくれた方に感謝します。
Marumo ISDB Splitter ver. 0.2.15 を公開しました。ダウンロードは [URI] からどうぞ。今回の更新内容は次の通りです。
今回も追いかけ再生中の不具合修正です。バグ報告をしてくれた方に感謝します。
通常、DirectShow でファイルを再生する場合、FileSource (ASync) というフィルタを利用してファイルデータの読み込みが行われます。このフィルタは IAsyncReader というインタフェースを提供しており、このスプリッターも IAsyncReader::Length() でファイルのデータサイズを取得していたのですが……。
ファイル事前確保型でない録画環境では、録画中のファイルサイズは当然刻々と変化していきます。追いかけ再生に対応する際、IAsyncReader::Length() は当然その時々で有効なファイルサイズが取得可能なものと思いこんでいたのですが、どうやら FileSource (ASync) フィルタは違ったようでして、ファイルサイズが変わった場合も、開いた直後に取得したファイルサイズと同じ値しか返してくれませんでした。
まあフィルタを作る際に手抜きをすればそういう仕様になってしまうのも仕方がないかと思います。私でもそういう処理を書いてしまうことがあるかもしれません。
ただ…… FileSource (ASync) って Microsoft 純正のフィルタなんですよね……。いや…… DirectShow ってのはそういう適当でいい加減なものだと思い知っていたつもりだったのですが、ほぼ全てのファイル再生に使われるフィルタでもこうなのかとちょっと打ちのめされてしまいました。
今回の更新では、このそびえたつ糞のようなフィルタが相手でも問題が起きないように、再生中のファイル名を取得して、ファイル名からファイルサイズを直接取得するように変更しました。
複数の TS を束ねてまとめて 1 ストリームとして送り出すようなフィルタが存在した場合、今回の変更では問題が発生することになると思いますが…… ISDB の TS でその手のデータを作る環境は無いはずなのでキニシナイことにします。
あー毎回追いかけ再生はこれで完璧になってくれるといいなーと思いながら修正しているのですけれども、中々安定してくれないのが悲しいですね。