Hmm, that's a little unfortunate. I do like using ffmpeg for some tasks, for
example, the frequency visualiser in this livestream
https://www.youtube.com/watch?v=mNSTeO0Y_3M which has audio coming from my
liquidsoap radio.
I had been trying with something like this on input
`ffmpeg -f avi -c:a
I can't for the life of me get the input format correct for reading with ffmpeg.
The following example in the documentation does not work for me.
```output.file(
%external(process="ffmpeg -i pipe:0 -f avi pipe:1",video=true),
"/tmp/test.avi", s)```
Can I get a hint about how I should read in w
Yes i understand it should be 17k by default. I had reports from a listener of
there looking like a cutoff at 15k (this was likely the source file)
Not sure why you would suggest using SBR (AAC+/HE-AAC) however. Seems like a
bunch of extra steps to achieve a similar goal as just setting the band
It seems in CBR mode the cutoff frequency is being fixed to the library default
of 14k? (Should be 17k)
With vbr=5 this cutoff is not imposed (as per the spec) however there is no
ability to set a cutoff within liquidsoap's encoder settings to force the
lowpass value. So even very high bitrates
@toots my case is when moving from a local playlist to a higher priority live
harbor connection (track insensitive). It just seems that if I use the 'old'
playlist source within the transition(jingle, old, new) function it
'reactivates' it, and in the case of fade.final, its internal on_end hand
I've confirmed that removing fade.final, which causes a hard transition, works
correctly
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/savonet/liquidsoap/issues/719#issuecomment-465826258
Also from the cookbook
```def next(j,a,b)
add(normalize=false,
[ sequence(merge=true,
[ blank(duration=3.),
fade.initial(duration=6.,b) ]),
sequence([fade.final(duration=9.,a),
j,fallback([])]) ])
end
```
This
In current master (1.4.0) fade.final is not sending the source to blank in the
following transition (from the cookbook)
This is resulting in the autodj stream continuing to play and being added to
the live stream (a mess)
```
def transition(j,a,b)
add(normalize=false,
[ fade.initial
@toots i do a somewhat more advanced LUFS based determination of what my gains
should be. Setting my own custom meta tags and reading them back in, and using
that for the gain.
(perhaps this could be a new feature, as its a relatively easy ffmpeg filter)
However I am not getting the the above iss
@toots can you confirm how smart_crossfade works for a live source? would it
attempt to crossfade the DJs (already mixed) tracks? In particular the chained
ogg case? Or only the connect/disconnect events?
--
You are receiving this because you are subscribed to this thread.
Reply to this email d
@PB-SF @hmorneau on the earlier suggested use of buffer, get rid of mksafe()
and use buffer(fallible=true,...)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/savonet/liquidsoap/issues/695#issuecomment-457
@daniel-j I have this exact issue with smart_crossfade as well, likewise I dont
think moving the crossfade after my live sources would be a good idea, did you
get anywhere with this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@toots this may or may not be related. But when i have a DJ streaming with
(chained) OGG to a harbor input that is later connected to a fallback with
transitions. Something seems to cause the transition to be half triggered. I
end up with a fade in on each metadata update from a DJ, which cuts t
@ddmng I'm using ffmpeg with output.external, like
```
output.external(
%wav(stereo=true, channels=2, samplesize=16, header=false),
"ffmpeg -f s16le -ar 44100 -ac 2 -i - ")
```
I've found aac (i use fdk_aac) to be the most compatible stream for browsers.
```
%fdkaac(
bitrate=320,
afterbur
@toots I seem to have solved this by using separate clocks and buffers for my
live+autodj fallback, where the crossfade is acting on the autodj stream. I did
this last week and no longer have the logs of the error. Would need to try to
replicate.
--
You are receiving this because you commente
I also had crashes recently with the crossfade / smart_crossfade helper when
combined with a fallback().
I had a live harbor stream with a fallback to to a crossfaded playlist. Upon
the connection of a DJ (mixxx) the live connection would crash instantly
--
You are receiving this because you ar
RTMP is open sourced and used in a multitude of live streaming applications. It
would be amazing if liquidsoap could ingest an RTMP stream.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/savonet/liquidsoa
Thank's for looking in to this @toots
Looks like the problem is then with chrome/chromium's handling of chained ogg's
It is an ongoing battle with these formats and browser compatibility,
previously ogg worked perfectly on chrome however firefox had a similar issue
with headers, so I had to ser
Eventually this is the error that occurs, as shown in chrome://media-internals
```
01:49:59 279 | error | FFmpegDemuxer: PTS is not defined
01:49:59 279 | error | FFmpegDemuxer: demuxer error: 13
01:49:59 279 | pipeline_error | DEMUXER_ERROR_COULD_NOT_PARSE
01:49:59 280 | pipeline_state | kStopping
The timestamp drift seems to start to occur on a song change, so many be
related to headers?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/savonet/liquidsoap/issues/588#issuecomment-409087461
I've been having intermittent hangs on an ogg stream in chrome, checking
chrome://media-internals i get the following
```
00:04:41 478 | warning | Large timestamp gap detected; may cause AV sync to
drift. time:282033896us expected:282096326us delta:-62430us
00:04:41 864 | warning | Large timestam
Stream plays fine in chrome, however in firefox it hangs on a metadata error
related to this
https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1448762
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github
@silfversound Personally I use SSE to push metadata updates out of liquidsoap
with a http GET similar to @akosveres
I wrote a simple metadata relay server in golang, I chose SSE over websockets
for HTTP2 and QUIC compatibility.
--
You are receiving this because you are subscribed to this threa
23 matches
Mail list logo