[Icecast-dev] Webm files written without duration in header

Sytze Visser sytze.visser at gmail.com
Thu May 2 11:14:30 UTC 2019

Hey Roger and everyone else commenting – I appreciate all the advice and 

I now have more work than before 😊!

Greetings from sunny South Africa!

Sent from Mail for Windows 10

From: Roger Hågensen
Sent: Thursday, May 2, 2019 12:12 PM
To: icecast-dev at xiph.org
Subject: Re: [Icecast-dev] Webm files written without duration in header

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.


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
Icecast-dev at xiph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20190502/44299b03/attachment.html>

More information about the Icecast-dev mailing list