Prev: Float in Spreadsheet
Next: Sequel migrations
From: Lance Ivy on 10 Mar 2010 13:53
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?
--
Posted via http://www.ruby-forum.com/.

From: Luis Lavena on 10 Mar 2010 17:46
On Mar 10, 7:53 pm, Lance Ivy <la...(a)cainlevy.net> wrote:
> 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

--
Luis Lavena
From: Lance Ivy on 10 Mar 2010 18:30
> 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.
--
Posted via http://www.ruby-forum.com/.

 | 
Pages: 1
Prev: Float in Spreadsheet
Next: Sequel migrations