[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
questions.
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.
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
Icecast-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast-dev
-------------- 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