New streaming issues

[tommedema]

I'm sure something is still going wrong with the file descriptors. Anyway, the synchronized file descriptor closing methods you were using were causing the following error:

  return binding.close(fd);
                 ^
Error: EBADF, Bad file descriptor
    at Object.closeSync (fs.js:192:18)
    at ChildProcess.<anonymous> (/media/sda3/Workspaces/Node.js/node-fluent-ffmpeg/lib/processor.js:118:18)
    at ChildProcess.emit (events.js:67:17)
    at ChildProcess.onexit (child_process.js:192:12)

Apparently, the fd was properly closed already. I fixed this by making the call asynchronous (which it should be anyway), like so:

     ffmpegProc.on('exit', function(code, signal) {
        if (processTimer) clearTimeout(processTimer);
        // close file descriptor on outstream
        fs.close(stream.fd, function() {
          if (self.options.inputstream) {
            fs.close(self.options.inputstream.fd, function() {
              callback(code, stderr);
            });
          }
          else {
            callback(code, stderr);
          }
        });
      });

Unfortunately a 5Mb mp3 is only converted to 23KB of ogg audio, which plays for about 1 second. The awkward thing is that retcode is 0 indiciating a normal termination of ffmpeg. This is the output:

DEBUG: inputStream end event: stream received EOF, no more data events DEBUG: inputStream close event: file descriptor has been closed DEBUG: input stream written to write stream successfully, err: ffmpeg version git-N-30727-gd127d26, Copyright (c) 2000-2011 the FFmpeg developers built on Jun 12 2011 14:49:21 with gcc 4.4.5 configuration: --disable-encoder=vorbis --enable-libvorbis libavutil 51. 8. 0 / 51. 8. 0 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 3. 1 / 53. 3. 1 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 15. 1 / 2. 15. 1 libswscale 0. 14. 1 / 0. 14. 1 [NULL @ 0x3251400] Format mp3 detected only with low score of 25, misdetection possible! [mp3 @ 0x32533a0] Header missing [mp3 @ 0x3251400] Estimating duration from bitrate, this may be inaccurate Input #0, mp3, from 'pipe:': Duration: N/A, start: 0.000000, bitrate: 160 kb/s Stream #0.0: Audio: mp3, 44100 Hz, stereo, s16, 160 kb/s Output #0, ogg, to 'pipe:1': Metadata: encoder : Lavf53.3.1 Stream #0.0: Audio: libvorbis, 44100 Hz, stereo, s16, 64 kb/s Stream mapping: Stream #0.0 -> #0.0 [mp3 @ 0x32533a0] Header missing Error while decoding stream #0.0 [mp3 @ 0x32533a0] overread, skip -6 enddists: -2 -2 [mp3 @ 0x32533a0] overread, skip -7 enddists: -5 -5 [mp3 @ 0x32533a0] overread, skip -7 enddists: -3 -3 [mp3 @ 0x32533a0] Header missing Error while decoding stream #0.0 [mp3 @ 0x32533a0] incomplete frame Error while decoding stream #0.0 size= 24kB time=00:00:02.71 bitrate= 72.0kbits/s video:0kB audio:20kB global headers:4kB muxing overhead 1.083495%

You can see my code here: https://github.com/tommedema/NodeFFmpegTest/blob/master/main.js

Note that this is exactly the same input file as I used before, which was handled successfully.

[tommedema]

I confirmed that this is in fact caused by recent changes by checking out to commit f62a558 - this is without the streaming changes. At this commit, everything worked fine again.

There must be something wrong with passing in streams like this. Maybe there are issues related to piping. In that case, we should manually pipe the input stream to ffmpeg's stdin stream.

[tommedema]

fixed in #16, tested too.

[schaermu]

i'll re-add the old streaming code by adding an option to switch between the piping (customFds) and the pumping (stream.pump()) mode (sounds awkward i know ;))

[tommedema]

@schaermu, ehh that sounds highly illogical - why would you ever want to do that?

The fix I provided is the best of both worlds. Just passing in Fds is not possible because the write buffer will get full, apparently, this is why we had to use piping.