Closed emutavchi closed 1 year ago
A test case is available here https://raw.githubusercontent.com/emutavchi/tests/master/mse/apple_tv_parse_error.html
Just one quick question: Are you applying https://github.com/WebPlatformForEmbedded/buildroot/blob/main/package/gstreamer1/gst1-plugins-good/1.18.6/0011-qtdemux-Add-MSE-style-flush.patch and https://github.com/WebPlatformForEmbedded/buildroot/blob/main/package/gstreamer1/gst1-plugins-good/1.18.6/0012-qtdemux-Fix-crash-on-MSE-style-flush.patch in your GStreamer build, as well as https://github.com/WebPlatformForEmbedded/WPEWebKit/commit/b4e9f4a3a43f33504b0963703e1a32b4a5c1fb01 in your wpe-2.38 branch?
Do you really really need a full qtdemux reset even in those circumstances? Might the Apple TV code be lacking a SourceBuffer.abort()?
Hi @eocanha. Yes, both patches are applied and I'm testing with the tip of wpe-2.38 branch (c613c9a4f8b48d3701b4f34edfd002e04cb1a85e).
Adding SourceBuffer.abort() doesn't make any difference. It still fails after appending new init segment. Here is the log for test run with SourceBuffer.abort() added: https://gist.githubusercontent.com/emutavchi/d148d10c3bae07625a18b46b250048d6/raw/bf86d4afb3525cf687219e26a0e62d48b4c45d69/apple_tv_parse_error.log
The problem is that appsink is left in EOS state after removing an "old stream" pad. And it rejects subsequent data.
Do you really really need a full qtdemux reset even in those circumstances?
This change doesn't reset demuxer. It resets appsink and optional parser.
Commit ported upstream as https://bugs.webkit.org/show_bug.cgi?id=263532 / https://github.com/WebKit/WebKit/pull/19424 and backported to wpe-2.38 as https://github.com/WebPlatformForEmbedded/WPEWebKit/commit/d89d709c76e8cee5d8e52b24124b88c2666aaad3
Closing PR.
… track
After applying 1, appsink can receive EOS event that was sent by qtdemux before removing an "old" streamd. This marks the sink as "received_eos" and makes it reject any events from subsequent appends. Resulting in append failing with ParsingFailed error.