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?
On Mar 10, 7:53 pm, Lance I. [email protected] wrote:
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
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.