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

Thomas B. Rücker thomas at ruecker.fi
Fri May 3 07:23:42 UTC 2019


Hi,

Please dont't post usage questions to this list as it's devoted to the
further development of the Icecast server itself.

General note: For this list I will enforce no-HTML more strictly.

Thanks!

TBR

On 5/2/19 11:14 AM, Sytze Visser wrote:
>
> 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>  
>
> *From: *Roger Hågensen <mailto:rh_icecast at skuldwyrm.no>
> *Sent: *Thursday, May 2, 2019 12:12 PM
> *To: *icecast-dev at xiph.org <mailto: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
>
>  
>
>
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev


More information about the Icecast-dev mailing list