# Side-effects from STDIN.reopen? **URL:** \ **Category:** Ruby\ **Created:** [March 10, 2010, 7:53pm UTC](https://www.ruby-forum.com/t/side-effects-from-stdin-reopen/184943 "2010-03-10T19:53:38Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![cainlevy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ecccb3/32.png) [@cainlevy](https://www.ruby-forum.com/u/cainlevy)\ **Post date:** [March 10, 2010, 7:53pm UTC](https://www.ruby-forum.com/t/side-effects-from-stdin-reopen/184943/1 "2010-03-10T19:53:38Z")
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](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? ---
**Author:** ![cainlevy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ecccb3/32.png) [@cainlevy](https://www.ruby-forum.com/u/cainlevy)\ **Post date:** [March 10, 2010, 11:50pm UTC](https://www.ruby-forum.com/t/side-effects-from-stdin-reopen/184943/2 "2010-03-10T23:50:24Z")
On Mar 10, 7:53 pm, Lance I. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://blog.segment7.net/articles/2006/08/17/stdout-vs-stdout) ---
**Author:** ![cainlevy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ecccb3/32.png) [@cainlevy](https://www.ruby-forum.com/u/cainlevy)\ **Post date:** [March 11, 2010, 12:30am UTC](https://www.ruby-forum.com/t/side-effects-from-stdin-reopen/184943/3 "2010-03-11T00:30:33Z")
> 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.