Okay, so extending off of my prior post, here is the bug:
User replaces non-web-optimized video with web-optimized video using the "Replace Video" function.
New video is treated like the old video and is restricted from disabling the compression -- even though the new video, when inserted as a fresh instance, allows for the compression to be disabled.
There. I just did your QA team the favor of troubleshooting this on my dollar instead of yours... your welcome.
Thanks for circling back on your other discussion, and I'm sorry you've come across this issue. I see you've done a ton of troubleshooting on this, and can appreciate how frustrating this has been.
This article offers excellent insight into why the Compression property could be grayed out. Since you experience this snag when replacing a newly encoded video, I'd like to connect you with our Support Engineers so we can lend a hand.
I've opened a case on your behalf, and you'll hear from our team shortly. We'll take a closer look at what's happening with the replaced video files and explore approaches. Thanks for bringing this to our attention!
1 Reply
Greetings, Ian!
Thanks for circling back on your other discussion, and I'm sorry you've come across this issue. I see you've done a ton of troubleshooting on this, and can appreciate how frustrating this has been.
This article offers excellent insight into why the Compression property could be grayed out. Since you experience this snag when replacing a newly encoded video, I'd like to connect you with our Support Engineers so we can lend a hand.
I've opened a case on your behalf, and you'll hear from our team shortly. We'll take a closer look at what's happening with the replaced video files and explore approaches. Thanks for bringing this to our attention!
This discussion is closed. You can start a new discussion or contact Articulate Support.