Log in

View Full Version : Reliability of Avisynth in SMB AVID Nexis


FranceBB
25th November 2020, 10:33
Hi there,
it's me again.
I have several SMB Share with several TB in which masterfiles are stored temporarily before they're encoded.
I generally write .avs files in there and I run .bat from there.
Those storages are part of an AVID Nexis system.
The problem I'm facing has to do with the bandwidth and with the write failures. You see, from time to time, the system can delay a write or can even fail to write and enter for a very brief time (ms, really) in "protection" which means that it's in "read only mode" if it detects that there are too many operations on the disks. Of course all the AVID-Infrastructure software are well aware of this and can deal with it just fine, but this isn't the same for Avisynth, x264, x265, avs2yuv and FFMpeg...
In the very recent days, I had to run some pretty long jobs which involve QTGMC, MVTools and other filters which sadly run at about 0.6fps-4fps on a 28c/56th Xeon...
Those jobs take a very long time to complete, especially for files which last 3 hours or so and I leave them encoding for hours and hours. This morning, just like the other morning, I came back to the workstation only to find out that the jobs were stuck due to one of those connection errors occurred when I wasn't there...
Of course I can't do those things locally...
So, the question is: are you experiencing the same behavior? And if you do, is there a way to prevent my encodes to hang there stuck and not progressing when there's a connection error?

Frank62
25th November 2020, 11:23
Is it possible to run your batch from the Nexis-Linux?

FranceBB
25th November 2020, 12:20
Is it possible to run your batch from the Nexis-Linux?

The .bat is on the share, so it's physically on Nexis, but I run it from Windows 'cause Avisynth and all its filters run on Windows...

Frank62
25th November 2020, 14:41
Without question... I just thought that the only way that your workflow could respect those "waiting-states" was to somehow use its own architecture or some kind of "wrapper" it might provide.

real.finder
25th November 2020, 14:56
The .bat is on the share, so it's physically on Nexis, but I run it from Windows 'cause Avisynth and all its filters run on Windows...

Avisynth+ and some filters (https://forum.doom9.org/showthread.php?t=182032) can run on Linux, but most filters not yet

FranceBB
25th November 2020, 15:28
Avisynth+ and some filters (https://forum.doom9.org/showthread.php?t=182032) can run on Linux, but most filters not yet

Yep but only a bunch of filters and it would be a new uncharted territory.
By the way, there must be a way to improve the reliability of Avisynth/FFMpeg and make it resume from where it was on Windows. After all, it would be just a matter of "retry"...
I wish I could give you more information about it, but when I see the cmd I literally just see the frame number which doesn't change and the RAM of the process that is allocated but remains steady without increasing nor decreasing, which means that it's stuck, but what makes me wonder is that the process is still technically there, with the RAM allocated, so I don't see any reason why it couldn't continue from where it was...
Sure I could brutally copy the raw stream that has already been encoded and then re-launch the encoding from the successive frame and lastly use "concat" in FFMpeg to append the parts, but I would like something better, like a better alternative.

Frank62
25th November 2020, 15:54
If the problems occur just with writing, and you encode to some small final format, why not simply write the files locally and copy back to the Avid-managed storage later, which also could be in the batch.

FranceBB
25th November 2020, 21:48
If the problems occur just with writing, and you encode to some small final format, why not simply write the files locally and copy back to the Avid-managed storage later, which also could be in the batch.

'cause my output is an AVC Intra Class 100, so at least 100 Mbit/s 10bit... Way smaller than ProRes worth several GBs with bitrates of 800 Mbit/s, but still...