Cannot preview video 4.1.1 Rolled back to 4.1.0

Windows 11.
Settings: Preview (In–> Out)
Behavior in 4.1.0 was that the video is outputted during processing to a subdirectory within the C:\Users(username)\AppData\Local\Temp directory. You could click on Process–>Show Export Command and determine the temporary export directory. The file was viewable by media players during construction, and upon completion transferred to the intended output directory.
In 4.1.1 The video is outputted to the intended output directory and is NOT viewable during construction. I do not know if it is viewable upon completion but I cannot wait for 2 days to find out. I cannot determine during preview whether the file is going to look OK which I could in 4.1.0, because I need full resolution to find out.
If putting the preview in the intended output directory makes the file not viewable during preview then the 4.1.0 behavior is preferable despite its inconvenience and should be restored.

1 Like

Try the preview button? It creates a shorter video that will look exactly how the export will…

I processed over 300 movies up to 3 hours play time long across so many versions of Video AI and never ever had a preview file overwrite my export file even though I always set the export path for both files the same. The export file preview was disabled in 4.1.1 to fix a bug that never ever happened on my end. :eyes:

you can still view the file while it is rendered even at the final export Directory, you just need to wait a bit until the file has some data in it. usually few min.

I have actually waited several hours, and with several gigabytes of data in the file and I get the same “the file cannot be rendered” error in my video player.

Well they need to “unfix” the problem.

1 Like

You now need to use .mkv container for this to work (playing back the temp file in an external player)

1 Like

I will try that and report back. Having to use mkv container is certainly acceptable–had been using mp4.

Same here.

Mines is AVI and/or MKV, i manage to playback before rendering completion.

@frederick.artiss @jo.vo @Imo
It is not really a bug…
With MP4 the video headers info are written last at the end of the file during encoding , so you can’t playback the video until the header data is written, or in other words, the file is completed…

There is a way to command ffmpeg to write those 1st using the -movflags faststart flag.
The -movflags +faststart option will relocate the moov atom from the end of the file to the beginning allowing playback to begin before the file is completely downloaded/rendered, so you can start playing as the file downloads/renders. this was originally created for Streaming, that one can start stream the media while downloading the file, before the entire file needs to download that playback could start…

1 Like

I have confirmed that with the mkv format, I CAN preview the file during construction. With the mp4 format, I CANNOT preview the file during construction, but it is viewable only on completion. The file is NOT accidentally deleted in either case, which is what I wished to confirm before making additional replies. I see another poster with more technical knowledge than myself say that ffmpeg cannot write mp4 headers until the file is complete, but I recall that prior to 4.1.1 the file was nevertheless viewable in its temp file location so I am at a loss to explain the contradiction. At any rate, the ability to preview the file during construction, by some method, is a vital feature that needs to be preserved at all cost. The task of the developers is to make a choice between two options:
A. To decide that the issue of preview only working with MKV format to be unresolvable, and therefore it needs to be documented in the 4.1.2 release or B. To regard it as a bug that needs to be resolved. It is the developers’ choice. Respectfully submitted.

Well if what you say is true then maybe the -movflags +faststart option should be standard procedure if the not so technically expert user such as yourself decides to output the file as mp4 or whatever. I get the vague idea that after processing, Topaz sends a series of commands to ffmpeg. If that is the case the way may be paved or a resolution of this issue in 4.1.2.

I don’t know what is the downside of adding this flag with Topaz models. maybe there isn’t any.
In any case you can add it yourself in the Command line to see if it solves the issue. topaz uses ffmpeg at the beginning, not after. actually the entire process is done through that ffmpeg command/process.

  1. load video and set all your settings in the UI ready for export
  2. press CTRL+SHIFT+E and copy the command text
  3. paste into notepad & add the flag into the command line text
  4. press CTRL+T (in TVAI) , a command prompt window will open, paste the new command from notepad into the command prompt window and press “enter”

I agree that it is a bug. And not a minor bug, but a very important one that affects the workflow of many users. I personally reported it along with other beta testers when the beta was published, but we haven’t even managed to exchange opinions with the developers.

Yes, the (most of the time) total missing feedback from the devs is a bit disturbing.

You don’t really know if your reports in those beta threads are even read by anyone from the dev team which would render those beta threads obsolete.

And some (apparently not that hard to solve) bugs survive over several releases for months :thinking:

P.S.: You did see the workaround with using the .mkv container instead of .mov?

1 Like

Yes, it’s really a good workaround and I tried it successfully, then I think I will use it in the future if the decision about the product persists. But for macos it is more useful to use Quicktime Player and if you need an mp4 or mov format you will need a later conversion pass to change the container. And it is possible to do it without re-encoding video or audio, but it is one more step.

You still use Quicktime Player?

Ever tried IINA (like VLC but with a more Mac-like UI)?
IINA - The modern media player for macOS

Thank you, I’ve took a look. The problem is upscaling for pixel peeping. Is very user friendly in QT, but not in IINA nor VLC, to my taste.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.