A query on FFmpeg and NFS mounts

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

A query on FFmpeg and NFS mounts

Brainiarc7
Hello there,

Is it possible to keep FFmpeg running when dealing with unreliable NFS
mounts when using the tee muxer configured with the onfail=ignore option?

I've observed that when an NFS server goes offline with FFmpeg still
writing to one (or more) mount(s) , the program "pauses"/halts and then
resumes as soon as the NFS server is back online.  Can this behavior be
overridden, perhaps through a change in how NFS shares are mounted (on the
client side or on the server side), to replicate the behavior observed with
local files where a directory rename simply results in a tee slave mixer
failing without pausing or halting the FFmpeg process?

Here's what I've tried so far, with no success:

1. Using the soft mount option, combined with a timeout on NFS.
2. Switching to UDP instead of the default TCP with NFS.

Thanks,

Dennis.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: A query on FFmpeg and NFS mounts

andrei ka
run 2 ffmpegs, one sending to local multicast,  2nd running in bash
infinite loop copying from that multicast to nfs, if nfs fais, restart
ffmpeg after the loop sees nfs coming back

Le mar. 1 oct. 2019 à 18:50, Dennis Mungai <[hidden email]> a écrit :

> Hello there,
>
> Is it possible to keep FFmpeg running when dealing with unreliable NFS
> mounts when using the tee muxer configured with the onfail=ignore option?
>
> I've observed that when an NFS server goes offline with FFmpeg still
> writing to one (or more) mount(s) , the program "pauses"/halts and then
> resumes as soon as the NFS server is back online.  Can this behavior be
> overridden, perhaps through a change in how NFS shares are mounted (on the
> client side or on the server side), to replicate the behavior observed with
> local files where a directory rename simply results in a tee slave mixer
> failing without pausing or halting the FFmpeg process?
>
> Here's what I've tried so far, with no success:
>
> 1. Using the soft mount option, combined with a timeout on NFS.
> 2. Switching to UDP instead of the default TCP with NFS.
>
> Thanks,
>
> Dennis.
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: A query on FFmpeg and NFS mounts

Brainiarc7
On Tue, 1 Oct 2019 at 19:55, andrei ka <[hidden email]> wrote:
>
> run 2 ffmpegs, one sending to local multicast,  2nd running in bash
> infinite loop copying from that multicast to nfs, if nfs fais, restart
> ffmpeg after the loop sees nfs coming back
>

Hey Andrew,
That's not a solution to my problem.
Invariably, FFmpeg does not crash or stop when the NFS mount is
unavailable, but rather, it pauses and resumes automatically when the
NFS mount is back online.
My query is: Can the pause induced by an NFS mount going offline and
resuming operation be completely eliminated, such that other outputs
(from the tee muxer's slaves) can proceed uninterrupted?

Warm regards,

Dennis.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".