Re: Webm files written without duration in header
Roger Hågensen <[email protected]> Thu, 2 May 2019 12:03:41 +0200
| Newsgroups | gmane.comp.audio.icecast.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2019-05-01 11:58, Sytze Visser wrote:> I am streaming live with webm with ffmpeg to icecast 2.4.2. After the > stream ends, I am unable to determine the duration of the file using > ffprobe or mediainfo. Not sure but it seems that this has to do with > headers? > > Should icecast be writing the duration into the header or should this > somehow be passed from ffmpeg? Do you mean the stream you sent to icecast or the stream listeners get from icecast? If it's the user stream then no, as a listener may drop packets and any length would be incorrect, in this case it is the listeners player that should track duration played (received) and add this to the file header if the player allows archiving of live streams. For livestreams I think Icecast sets a length of -1 (but it could be 0, or no length at all). If you use a stream capture tool then I'm sure there exists one that will write the duration header to a file. Have you tried using ffmpeg to capture the stream? Look at the manual, you should be able to make it write a duration to the header (if possible/supported by the file format) > The requirement is really to determine the duration of the streamed > event (i.e. not radio). If you are using ffmpeg as the stream encoder then you should log the duration either prior to ffmpeg getting the audio or after ffmpeg encoding. There is no way for ffmpeg to magically add a length (duration) to the header (which may have been streamed an hour ago). If you only want to track duration before streaming it "out", then encode and store the stream locally, then when it ends run a script to add/fix the header to have a duration then stream the file to icecast, this would mean the liveness of the stream would be delayed by the duration of it. But I doubt you want to do this (why stream live otherwise right?) I can't recall if you can get ffmpeg to trigger a script or executable when it quits or not, but you could (be it Windows or Linux) easily make a script that you call instead of ffmpeg directly, in the script you log the time before calling ffmepg and again after ffmpeg quits. If you log as a datestamp you can simply subtract the start value from the end value to get duration. Do note that this may not match the actual duration of the archived stream (even if you archive it straight from ffmpeg), it could be off by a second for example. You should also consider how to handle things in case ffmpeg crashes or looses the connection to icecast (something sure to happen if using public networks instead of a local LAN). If a script you can "easily" restart ffmpeg and you can log the start and end time (you could maybe even detect a ffmpeg crash or quit and log a message). I note you said "streamed event", are you using some form of broadcast software? In that case that should have it's own log for events, or you can set it to trigger a script at the start and end of events. Regards, Roger. -- Unless specified otherwise, anything I write publicly is considered Public Domain (CC0). My opinions are my own unless specified otherwise. Roger Hågensen, Freelancer, Norway. _______________________________________________ Icecast-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/icecast-dev