Make ffmpeg operate directly on temp file #162
Conversation
There was a problem hiding this comment.
wondering if it's maybe worth considering just making load_audio take a string file path only? nice to do both, i only got a little mixed up in wrapping my head around the few different places in that method that accounted for both argument types. 🤔
that aside, 🚢
It's true that we only need the file path version at this point, but I'm not really a fan of APIs that only work with files on disk. I'll clean up the logic a bit so hopefully it's not so hard to follow. |
that little change made a big difference 🎸 |
🙌 Thanks! |
In an attempt to figure out why .m4a files were resulting in empty transcripts, I tried running ffmpeg via the command line, and it had no problem converting it to a .wav file with the audio intact. My understanding is that the main reason .m4a files are different is that their metadata gets stored at the end of the file. Since our
load_audiofunction was piping audio into ffmpeg, I think this was defeating ffmpeg's file format detection; it had no file extension since it was reading from stdin, and it could not determine the file type by looking at the beginning of the stream.I tried passing the filename instead of a file stream into the ffmpeg library, and sure enough, .m4a files are detected and handled properly. Since we use temp files to pass the audio from the web service to the worker, we're already guaranteed to have a file on disk for our use cases. So, I adapted
load_audioto accept either a file object or a filename string, and made our web service pass the filename instead. Fixes #160