side-effects from STDIN.reopen ?

[Lance Ivy]

I'm encoding videos from a background process and found a video where
the audio sync is off ... but only when the encoder is run inside a
daemon. After some work boiling down the Daemons code, I was able to
reduce the entire problem down to this:

http://pastie.org/863675

I haven't simplified the ffmpeg command itself because eventually I
began using the resulting file size to indicate the problem. When line 4
is commented out and the audio syncs correctly, the file size is about
7400 bytes larger.

What I don't understand is how STDIN.reopen could have any effect on the
ffmpeg command. I tried directing the first-pass ffmpeg output to a
standard file instead of /dev/null, but it made no difference. I also
tried changing STDIN.reopen to a temporary file ... no difference.

Could anyone with deeper knowledge shed some light on the problem, or
suggest further tests?

 

[Luis Lavena]

I'm encoding videos from a background process and found a video where
the audio sync is off ... but only when the encoder is run inside a
daemon. After some work boiling down the Daemons code, I was able to
reduce the entire problem down to this:

http://pastie.org/863675

I haven't simplified the ffmpeg command itself because eventually I
began using the resulting file size to indicate the problem. When line 4
is commented out and the audio syncs correctly, the file size is about
7400 bytes larger.

What I don't understand is how STDIN.reopen could have any effect on the
ffmpeg command. I tried directing the first-pass ffmpeg output to a
standard file instead of /dev/null, but it made no difference. I also
tried changing STDIN.reopen to a temporary file ... no difference.

Could anyone with deeper knowledge shed some light on the problem, or
suggest further tests?

Why are you messing with the inherited STD handlers? Can't you
redirect ffmpeg output to /dev/null using pipes?

ffmpeg .... > /dev/null 2>&1

That will redirect STDOUT (1) and STDERR (2) to /dev/null

http://blog.segment7.net/articles/2006/08/17/stdout-vs-stdout

 

[Lance Ivy]

Why are you messing with the inherited STD handlers? Can't you

redirect ffmpeg output to /dev/null using pipes?

Well STDIN.reopen is the line I isolated from inside the Daemons library
that appears to be wholly responsible for my issue. I have no need of it
personally except that I'm running DelayedJob, which is built on top of
Daemons.

I have managed to further isolate the issue to the second ffmpeg command
though. If I save the output of the first command (a log file with
metadata), and run the second command separately with and without
STDIN.reopen, I can reproduce the issue more succinctly.

Technically, I just don't understand the effect of STDIN.reopen well
enough to see how it could affect the ffmpeg command, or how I can work
around it all.