server
server copied to clipboard
CasparCG
Async creation of ffmpeg producer never throws
This makes ffmpeg accept every (even unplayable) file and return a 200 PLAY OK, even when it fails afterwards. It also breaks playing PLAY 1-1 http://google.com (which is less important). We might be able to still asynchronously create the producer, but await it with a promise (and a timeout, because the creation might stall indefinitely).
I'm not keen to change this. And it kind of goes with my future wish, file extension always required :).
We should change so that ffmpeg, if HTTP and no file extension don't play it.
Are you sure? There are HLS streams not specifically using an extension, because it's not mandatory. Of course it's good practice to use a .mpd or .m3u8 extension, but this not always happens. #905 gave us a chance to catch the ffmpeg producer not being able to play something, and feed it to other producers. For example PLAY 1-1 http://google.com. This doesn't have an extension, but it would be unfortunate if we weren't able to play those anymore. Currently this will only work if you explicitly tell the HTML producer it's for it ([HTML]), but wouldn't you want CasparCG to find out itself which producer is able to play it?
We should change so that ffmpeg, if HTTP and no file extension don't play it.
This would indeed fix for almost every use case, except for DASH/HLS streams without an extension. If you are okay with this, I'm happy to create a PR. Maybe we should allow for a specific [FFMPEG] prefix as well for that specific case. Then you have all situations covered.
This would indeed fix for almost every use case, except for DASH/HLS streams without an extension. If you are okay with this, I'm happy to create a PR. Maybe we should allow for a specific [FFMPEG] prefix as well for that specific case. Then you have all situations covered.
I vote for this! PR please.
@ronag How do we go with the 200 PLAY OK then? Is this wanted behaviour? This would make it a 'Producer has accepted the play request', but not a specific PLAY OK, because that's to be determined later.
@pkeuter that's the problem with AMCP. For now we'll have to live with it. 200 should say ok the command is valid and has been accepted. Not whether it has succeeded or not... because that can take an indeterminate amount of time which will block everything.
@ronag Thinking about this, we can also check specifically for .m3u8 or .mpd files. Combined with the [FFMPEG] prefix (for other, or no extensions) this would handle all possible scenarios as well. Agreed?