[Ffmpeg-devel-irc] ffmpeg.log.20191022

[burek]

[03:28:50 CEST] <YellowOnion> is matroska not good for udp streaming?
[03:31:30 CEST] <ponyrider> why not? isnt it just the open source version of mp4
[03:32:08 CEST] <pink_mist> not even close, ponyrider
[03:32:17 CEST] <pink_mist> in any case, mp4 isn't good for udp streaming
[03:32:21 CEST] <pink_mist> dunno about mkv
[03:33:04 CEST] <YellowOnion> I'm getting massive amount of errors about seeking issues
[03:42:45 CEST] <DHE> the best supported format for udp streaming is mpegts, but that has quite a few limitations....
[03:48:39 CEST] <YellowOnion> yeah mpegts has minimal errors
[14:54:09 CEST] <sidar> hey silence remove doesn't seem to work on m4a, is this a limitation?
[14:56:16 CEST] <durandal_1707> sidar: give more info, you are very vague
[14:56:44 CEST] <sidar> I export a wav to m4a but there is always a silence/padding at the start and end
[14:57:04 CEST] <sidar> while for ogg it matches the original wav file
[14:57:30 CEST] <sidar> is there a way to make ffmpeg correctly strip that or is it an m4a ( aac format ) problem?
[14:59:40 CEST] <sidar> I read that the aac encoder skips pre-roll data, so the file might be alright as it is
[14:59:47 CEST] <sidar> have to test
[15:01:28 CEST] <JEEB> pre-roll in formats where there isn't just one such and thus the decoder outputs it you have to skip until pts zero. ffmpeg.c last I checked didn't handle this correctly
[15:02:11 CEST] <JEEB> and not to mention that if you encoded and put aac into mp4 or other container in separate steps then you lost the preroll size
[15:03:05 CEST] <JEEB> f.ex. if you with ffmpeg.c output to wav it will see that wav does not support negative timestamps and moves that to zero
[15:03:29 CEST] <JEEB> api users have the chance of doing this correctly which many do
[15:10:32 CEST] <GingerGeek> I'm using ffmpeg to ingest a m3u8 stream and output in realtime to another device, when the stream goes onto a new chunk there is a ever so slight stutter, you can't notice it in video but you can notice it in the audio - is there a way to get ffmpeg to use an intermediatery buffer of maybe a second inbetween the m3u8 and the live output?
[15:15:59 CEST] <BtbN> it already buffers every input stream. Sounds more like it's an issue with the stream itself.
[15:19:59 CEST] <sidar> JEEB:  so no solution then other then editing in a tool or anthing?
[15:32:03 CEST] <JEEB> sidar: possibly seeking with ss when decoding? not sure
[15:32:12 CEST] <DHE> or a player that isn't doing any buffering and expects everything to be on a fast local disk?
[15:33:00 CEST] <JEEB> skipping data until pts 0 should do the trick, if possible
[15:36:28 CEST] <sidar> it's for web content
[15:36:34 CEST] <sidar> not sure how much control ill have over that
[15:37:02 CEST] <sidar> The wav file itself doesn't have any padding at the start and end
[00:00:00 CEST] --- Wed Oct 23 2019