RV 2025.0.0 Release is available!

Release Date: September 5, 2025

Download available here.

We are happy to announce this new major release of RV 2025.0.0!

This release of RV offers a new Live Review workflow, currently in Beta, allowing RV users to participate in a session presented by the Creative Review web app (Beta). It also contains several SDK and API updates, including Qt6. Additionally, it introduces new features such as Hold and Ghost for annotations, and more!

New Supported Platform

  • RV is now natively supported on ARM64 macOS devices. [SG-31969] - [SG-36751]
  • RV now supports macOS Sequoia 15.5.

New Features

  • Added support for RV users to join as participants in a Live Review session run by a user from the Creative Review app (Beta). [SG-37297]
  • Auto-mark annotations on the timeline are always enabled when working in a Live Review session while the Creative Review app is the presenter. [SG-39946]
  • New Hold and Ghost (also known as Onion skinning) features have been added for annotations. [SG-38044]
  • Added the support of High DPI Display in RV on MacOS and Linux operating systems. [SG-28658]
  • Added support for multiple media representations when loading an OTIO [SG-38202]
  • Added the ability to mute participants’ audio when joining a Live Review session. [SG-39187]
  • Added the ability for the presenter to mute all participants while working in a Live Review session. [SG-23041]
  • Added a feature to extend or override the list of multiple media representations available in RV’s Screening Room. [SG-39308]
  • Added the 120 Hz SDI output timing for Blackmagic Video. [SG-39413]
  • ProRes hardware decoding is now available for Apple Silicon (ARM64). [SG-39511]
  • Added a new Diagnostic Tool feature for Live Review. [SG-39145]
  • Added an option in the Annotation tools to clear all annotations on timeline. [SG-38113]

SDK and API updates

  • OpenEXR library has been updated to 3.2.4. [SG-34609]
  • OCIO libraries have been updated to 2.3.2. [SG-34610]
  • Python libraries have been updated to 3.11.9. [SG-34611]
  • BOOST library has been updated to 1.82.0. [SG-34612]
  • FFmpeg has been updated to 6.1.2. [SG-34758]
  • ARRI RAW SDK has been updated to version 0.21.1. [SG-35977]
  • OpenSSL library has been updated to version 3.0. [SG-36694]
  • Added support for Qt 6.5.3 for all platforms. [SG-37872]
  • BlackMagic Design SDK has been updated to version 14.3. [SG-37413]
  • Flow Production Tracking Toolkit in RV has been updated to tk-core v0.22.3. [SG-38971]
  • NDI feature has been updated to SDK 6.2.0. [SG-39393]

Bug Fixes

  • Fixed an issue that prevented users on a Mac M1 from using the presentation mode. [SG-25296]
  • Fixed an issue that would cause RV to stop working with Nuke versions 13/14/15. [SG-32963]
  • Fixed a crash that occurred when RV tried to read incomplete rendered PNG image sequences. [SG-34647]
  • Fixed an issue that caused intermittent audio synchronization issues while playback was runnning in presentation mode. [SG-34860]
  • Fixed an issue that blocked the application of the RV_NETWORK_PROXY_x environment variables. [SG-35205]
  • Fixed errors when launching RV on a Linux Rocky 8 platform with Plasma X11 (KDE) desktop environment. [SG-35235]
  • Fixed delays around the drawing of annotations while working in a Live Review session. [SG-35879]
  • Fixed a regression that caused the source frame value of a clip to be incorrect. [SG-38282]
  • Fixed an issue that caused RV to crash when loading movie clips using AV1 codec. [SG-38778]

Known issues and limitations

  • High DPI support on Windows is disabled by default due to known instabilities with QtWebEngineWidgets in Qt 6.5.3 on Windows which are used by Flow Production Tracking packages. You can still activate High DPI on Windows by setting the “RV_QT_HDPI_SUPPORT” environment variable but we cannot guarantee the results. [SG-40030]
  • The new High DPI displays support in RV can also be disabled by setting the “RV_NO_QT_HDPI_SUPPORT” environment variable if you encounter any issues with custom RV packages, for example.
2 Likes

If RV isnt authenticated, when we try to open a quicktime from CLI, RV will just hard Crash.

Here are 2 seperate steps to reproduce the issue.

A. Open h264 media through CLI

  1. Clear your authentication cache (~.rv, ~./config/TweakSoftware, ~/.local/share/TweakSoftware)
  2. Open your h264 media through CLI (/opt/RV/bin/rv /my/file.mov)
  3. RV will sloly open and then crash

B. Set RV to be your default media player in Maya

  1. Open Maya Preference, set Quicktime Viewing Application: /opt/RV/bin/rvpush -tag playblast merge %f
  2. Do a simple quicktime playblast (encoding jpeg)
  3. RV will slowly open and then crash

The expected behaviour

Let the user authenticate. From my understanding, ffmpeg libraries are loaded after the authentication process, thus crashing if not logged in.

This is reaaally annoying for our Animators since RV is our default media player.

In both cases, here are my error logs when it’s occuring.

INFO: loading plugin /opt/RV-Linux-Rocky9-Release-2025.0.0/RV/plugins/Output/AJADevices.so
INFO: loading plugin /opt/RV-Linux-Rocky9-Release-2025.0.0/RV/plugins/Output/BlackMagicDevices.so
INFO: loading plugin /opt/RV-Linux-Rocky9-Release-2025.0.0/RV/plugins/Output/NDI.so
ERROR: cannot find proper authorization.
WARNING: /opt/RV-Linux-Rocky9-Release-2025.0.0/RV/plugins/MovieFormats/mio_ffmpeg_commercial.so failed to load
INFO: trying brute force to find an image reader for 30s_010_0010_anim_v114.mov
INFO: trying brute force to find an image reader for 30s_010_0010_anim_v114.mov
INFO: NDIModule found NDIVideoDevice
INFO: trying brute force to find an image reader for 30s_010_0010_anim_v114.mov
INFO: trying brute force to find an image reader for 30s_010_0010_anim_v114.mov
INFO: trying brute force to find an image reader for 30s_010_0010_anim_v114.mov
INFO: trying brute force to find an image reader for 30s_010_0010_anim_v114.mov
INFO: trying brute force to find an image reader for 30s_010_0010_anim_v114.mov
/usr/tmp/rez_context_hjhwk_5r/rez-shell.sh: line 8: 2087193 Segmentation fault (core dumped) rv /X/PROJETS/dev_5747/prod/sht/30s/30s_010/30s_010_0010/anm_out/playblast/30s_010_0010_anim_v114.mov

We were not having this issue on RV 2023.0.1 (what we used before using 2025.0.0)

Support team confirmed they were able to reproduce this issue (Both on RockyLinux 8 and 9).

An escalation ticket was made for their team to dig deeper.

Hi,

this is a promising update. Unfortunately we experience a show stopping bug and need to revert to 2024.x

We can replicate this on portable and installed RVs on Windows 11 without any pipeline adjustments - ake the Vanilla version.

Any adjustments made in the Screening Room browswer are not saved anymore.

  • Page favorits
  • Visible fields

Once adjusted to taste and restarting RV, everything is lost.

Anyone else experiencing this as well?

Best,

Tobi

2 Likes

Hi, thanks for this new release.

Like @pixelconductor however, Screening Room for RV is not remembering any of our custom fields or pages with this version. This is a big issue for our artists, which made us rollback to the previous 2024.2.0 release.

I believe the issue is due to the default QT WebView profile which is now “off-the-record” by default in QT6 (meaning the cookies with the preferences are not saved between instances). CF This QT page. I tried editing the shotgrid_review_app.mu file to make the views in the _webViews attribute use an explicit profile without luck (it seems the stock QWebEngineView() constructor keeps getting called despite my modifications).

Thanks,
Gilles.

1 Like

I was just setting up 2025 in pipe yesterday and thought I would try to reproduce the issue.

Surprisingly, my “recently viewed” history does stay from session to session, but the favorites do not. Is the history stored differently?

1 Like

I did manage to replace the profiles used in the views, the problem now is that apparently modern chromium versions in Qt6 do not allow redirections to local files when cookies are enabled? I’m struggling to find reliable information about the change, this might be a gemini hallucination, but essentially as soon as I enable cookies, the webview errors with an ERR_UNSAFE_REDIRECT when accessing **https://genesis.shotgunstudio.com/user/redirect_with_local_fallback?url=XXX&fallback=XXX

Edit:
Removing the redirect, and directly accessing the final URL made things work, sometimes requiring me to login directly in the webview, which isn’t really a problem for me.**

Maybe someone from Autodesk is watching this thread, maybe not, but it seems like as of this morning, the saving of favorites and fields has possibly moved server-side rather than relying on cookies?

We had all of our favorites and settings disappear studio-wide, but now it works in RV 2025, and seems to stick around from session to session, even without any apparent cookie saving.

Hi there, I can clarify this for you.

It was a change to the way Qt saves persistent data using its WebEngine that broke this.

Screening room works by downloading javascript code served to it from an FPT server, and we made a fix to that code to solve the issue with the Qt’s persistent directories.

Since RV executes the JS code locally using its QtWebEngine, no changes have been made to how or where they are saved, only the code that does the saving has been modified to account for the new Qt version in RV 2025. Since that fix was deployed this morning, that’s why it started working again for you.

Hope that helps.

Hi Nelsonr.
First of all, thank you for looking into this issue.
Can you confirm where the data is now saved? It used to be under C:\Users\eleroy\AppData\Local\TweakSoftware\RV in my case, if I deleted the QWebEngine’s cache it would clear favorites and settings. Today I can delete this entire folder and the favs and settings stick around, which was what made me wonder if maybe it had been moved server-side (although logging in on another machine made me realize that’s not the case, wishful thinking).
I can also tell the change is not in the RV package as I’m running my own branch.
Cheers

When you save it will now invoke RV’s commands.writeSetting method. By default on Windows this in indeed HKEY_CURRENT_USER\Software\Tweak Software\RV, but you can technically set that to whatever you want.

You can delete the web engine cache if you so desire and it will not impact your favourites.

I’ve not been able to find where the new settings are being written, this registry key doesn’t exist on my machine.

Edit: Oh nevermind, it’s saved in the RV.ini with the rest of RV settings, makes sense

Hi Nelson,

I got reports from a bunch of Artists lately that they lost their preferences (fields, favorites) - even in RV 2024.x

That leads me to some questions:

  • Is this related to changes you did on your side?
  • Is this considered to be a one-time hickup and should be working again?
  • Is it now safe to test the 2025 versions due to the changes you made?

Looking forward to you answers.

Best,

Tobi

Hi @nelsonr

We’re getting reports from our supes that while favorites are fixed, the filters and grouping in the details pane still do not save.

Same here. Even on 2025.1.0