Closed colthreepv closed 10 years ago
Ditto with this
Same here. Any update on a fix?
This is the same error as #167, take a look at that issue for the workaround.
Likewise, except I'm using an input stream from web sockets based library called binaryjs
Progress is not well supported for streams because it relies on getting media metadata, which requires the stream to be seekable (and this is not the case for readable streams passed with fluent-ffmpeg, as they are piped to ffmpegs stdin).
Fluent-ffmpeg should use a more reliable way of getting progress information. The thing is, in the general case, we cannot know the full size of the streamed data (and ffmpeg cannot either), so getting progress information has no real sense when using streams, and there is no reliable way of doing it for all cases.
There are a few workarounds however. You could just dump the stream to a temp file and pass that file to fluent-ffmpeg. Or, if you know the size of data, you could use events on the stream (or use an intermediate Transport stream) to monitor data as it is passed to ffmpeg, (but with a caveat: streams are buffered by node and by the OS, so you won't know when the data is actually passed to ffmpeg).
That's very true and thanks for the thoughtful response.
In most cases progress can be measured. From my understanding aren't most properties of the progress based on the output? At the very least, timemark, frames, size, bitrate, etc. I understand an overall percentage of completion is out of the question for some inputs types.
I have a working local 'hack' that reports progress on an input stream even though I don't get total percentage.
I'd submit a pull request to enable but I'm cautious I don't know all the impacts.
@GregTurner there's a fix been put in today and is released to npm in 1.7.1
@bencevans I did see that but I didn't see how it would show progress for missing metadata scenarios. Looks like it gracefully suppressed progress reporting.
@GregTurner I think that's a good idea. I'll have a closer look soon.
This seems like its still broken. Can someone explain how they got around this issue? Thank you!
It's working for me with v1.7.1 and github master. Could you please paste some code to reproduce the problem ?
Thanks.
@njoyard Are you trying to use it with an input stream instead of a file?
@bluejamesbond I have a fix in my fork. There's also a fix for getting codecs as well. Remember codec's duration may not be there, so your code will have to tolerate it.
@GregTurner yes. That's why I'd like to have the exact code you used to reproduce the problem :)
@GregTurner There has been a lot change to the code since I posted it as we implemented workaround by saving the file first instead of reading from stream. The issue was that inputFile
was undefined
in the stream. When I experience the issue, I tried debugging by printing out all the first level keys in the stream object but it did not have that defined when I printed its first level keys.
This should be fixed in 2.0.0-rc1. Feel free to reopen if it isn't !
I'm using this library intensively with httpStreams, i wanted to give some feedback to the user about conversion happening so i wrote something like:
if i use the following code node-ffmpeg always generates an error
clarification
If i don't track the progress from the stream i don't have any problem
I'm using the following version of ffmpeg from this PPA :
I will try and will dive into the code, and if i'm able will provide a PR, in the meantime if anyone had the same issue could help me :smiley: