Shawn Lewis <[email protected]> added the comment: On the priority - no problem did not know.
As to the alternative, something can be thrown to together in a few days that would act as a transparent proxy to the the ffmpeg issue. Thru testing we have narrowed the problem down to be within ffmpeg and its https transport mechanism. Meaning if the file is LOCAL - no errors encountered. if the file is remote (accessed via http), then that is when it pukes. So the data in the file, and the ability of ffmpeg are all good, except for the issue surrounding the http access within ffmpeg. So to correct the problem, we would insert a "bridge". The way it would have to work is: Process kicks in the background download the source http file to a local file. We would look within the header for the moov atom, if its at the end of the file, we would kick off process "b" to download the ending chunk of the file. Once we know we have the MOOV, we kick off FFMPEG in "-re" mode :( pointing to the local downloaded file. Another possability would be to kickoff the download as above, but instead of point ffmpeg at the actual file in -re mode, we may possibly be able to point FFMPEG to our local http server, kickoff ffmpeg in regular mode, just have our web server "stalling" the sending of bytes to keep in sync with what is download yet so far. And yet another possible alternative could be to utilize a 3rd party library (streamcoders) we have to read the mp4 over http, and decode to video to bgr24 and audio to raw, and re-encode on the fly with that tool or ffmpeg or whatever into the format we choose thru pipes. So there are some paths we can take, all taking time to do, and unnecessary overhead, but a solution none- the less. The problem with http access within ffmpeg seems to be the speed and number of seeks it is doing when accessing the data. Could it not be possible to increase the chunksize ffmpeg grabs each request? that would both reduce the number of seeks, and provide more data for processing for ffmpeg (as it looks like it is running out of data before getting more), and would ultimately increase the amount of time betweek seek requests. Or instead of seekeing, why not a stream, one open, not hundreds of individual get requests? (putting aside the seek and get for the MOOV if its at the end of the file) Shawn ________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/issue2282> ________________________________________________
