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

[burek]

[01:32:22 CET] <faLUCE> well. MATROSKA AUDIO http stream works with ffplay, vlc and mplayer.   MPEGTS works with ffplay, buggy with vlc and no-way with mplayer.   OGG works with ffplay, mplayer and doesn't work with vlc
[01:32:27 CET] <faLUCE> matroska is the winner
[01:32:39 CET] <furq> or alternatively, vlc is the loser
[01:32:45 CET] <faLUCE> furq: LOL
[01:34:10 CET] <faLUCE> anyway, this matroska seems excellent to me. and much better than mpegts and ogg.
[01:34:31 CET] <faLUCE> ogg must be avoided at all. It supports few things
[01:34:45 CET] <faLUCE> mpegts is not good for HTTP, because of the PCR
[01:35:01 CET] <faLUCE> so, matroska is the right choice
[01:36:15 CET] <faLUCE> do you know if ffmpeg does well support matroska? it seems to me that, for example, some params can't be set, like the muxer's buffersize
[01:43:43 CET] <furq> it's not widely used for streaming
[01:43:46 CET] <kepstin> matroksa wasn't really designed for realtime streaming, so you won't get that level of control
[01:43:50 CET] <furq> unless you include webm, which is based on matroska
[01:44:01 CET] <furq> mpegts is pretty much the standard for this
[01:44:33 CET] <furq> didn't you say you got the same pcr warning from vlc when you tried streaming ogg
[01:44:50 CET] <furq> it could've just been a false alarm and the issue was somewhere else
[01:44:53 CET] <faLUCE> kepstin: I don't agree:   https://matroska.org/technical/streaming/index.html
[01:46:38 CET] <faLUCE> furq: yes, but it's a bug of vlc.
[01:46:47 CET] <furq> how come the matroska site styles it as matroaka and not matrëaka
[01:47:18 CET] <faLUCE> kepstin: in addition, there's a "suggested buffer" field in the matroska header
[01:47:38 CET] <furq> faLUCE: well yeah, i'm just suggesting that there was nothing wrong with your mpegts pcr
[01:47:55 CET] <furq> and vlc was shitting the bed for some undisclosed reason
[01:48:00 CET] <kepstin> I don't dispute that matroksa container /supports/ live streaming...
[01:48:28 CET] <faLUCE> furq: yes, because it decodes http streams like dvb streams
[01:48:52 CET] <faLUCE> then it causes this bug
[01:49:47 CET] <faLUCE> furq: this doesn't happen with VBR, then, when I have audio+video vlc works good for mpegts
[01:50:10 CET] <furq> i should hope so considering livestreaming was the only reason to use vlc for years
[01:50:51 CET] <faLUCE> furq: anyway, for http livestriming MPEGTS is overkill
[01:50:54 CET] <furq> it's pretty funny if it doesn't work with ogg live streams though
[01:51:05 CET] <furq> although i guess most netradio stuff is using aac-he now
[01:51:18 CET] <faLUCE> furq: I did not many tests with ogg, because it supports few codecs
[01:51:30 CET] <Diag> faLUCE is your name a play on phallus...
[01:51:31 CET] <furq> it supports the best audio codec though
[01:51:36 CET] <kepstin> there's still a bunch of "shoutcast" style radios using ogg vorbis over http, i'd expect they work fine in vlc
[01:51:49 CET] <furq> yeah maybe it works better with icecast stuff
[01:51:58 CET] <kepstin> but yeah, if you can use opus why bother with any other codec? :)
[01:52:07 CET] <faLUCE> kepstin: because of AAC
[01:52:24 CET] <kepstin> opus is equivalent or better quality to aac, and lower latency
[01:52:24 CET] <Diag> kepstin is opus ogg?
[01:52:25 CET] <faLUCE> maybe AAC is better than opus... who knows?
[01:52:29 CET] <furq> it isn't
[01:52:45 CET] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png
[01:52:46 CET] <furq> hth
[01:53:08 CET] <faLUCE> ok, but the main problem of OGG is that I can't use H264
[01:53:11 CET] <kepstin> Diag: tricky question. Opus is a codec can be used in many containers/protocols. An ".opus" file is opus in an ogg container.
[01:53:21 CET] <kepstin> faLUCE: I thought you were just streaming audio tho
[01:53:23 CET] <Diag> Huh
[01:53:26 CET] <furq> i thought you were still using mpegts for video+audio
[01:53:32 CET] <furq> i guess if you want the same thing for both then ogg is no good
[01:53:40 CET] <faLUCE> kepstin: no, I stream both audio and video. But when I stream audio only I can't use mpegts
[01:54:14 CET] <faLUCE> furq: yes, I can use mpegts for audio+video and ogg for audio only.... but it would be better to have a common container
[01:54:32 CET] <faLUCE> in addition, matroska is codec independent
[01:54:57 CET] <kepstin> alright, sounds like matroska fits your goals fairly well then.
[01:54:58 CET] <furq> i mean i'm not trying to tell you to not use mkv, mkv is all right
[01:55:13 CET] <furq> but i wouldn't hold your breath for advanced params for tuning streaming stuff
[01:55:21 CET] <furq> and that's already there for mpegts because it's extremely widely used for that
[01:56:04 CET] <faLUCE> the main advantage of mpegts is that you don't need a global header. then, you can share one muxer's instance between all the streamers
[01:56:20 CET] <faLUCE> with matroska I have to create one muxer per client
[01:56:43 CET] <faLUCE> (same with ogg)
[01:57:15 CET] <furq> i think i'll just stick with hls
[01:57:24 CET] <kepstin> I guess it makes the app logic more complex, but muxing overhead really isn't that big of a deal
[01:57:24 CET] <furq> 20 seconds of latency is all right by me
[01:57:28 CET] <faLUCE> but the disadvantage of mpegts is that it has this pcr, which confuses the http receivers
[01:58:00 CET] <faLUCE> kepstin: there's not a overhead.
[01:58:18 CET] <kepstin> (I mean, you already have to handle separate tcp connections, ssl context, etc. per client)
[01:58:28 CET] <furq> he means the cpu overhead of muxing twice instead of once
[01:58:31 CET] <furq> what little there is of it
[01:58:41 CET] <faLUCE> well, it is really little
[01:59:04 CET] <faLUCE> kepstin: yes, but remember that the libav API is broken
[01:59:12 CET] <faLUCE> IMHO
[01:59:50 CET] <faLUCE> so, when I manage the HTTP clients with libevent, it's all simple
[02:00:05 CET] <faLUCE> when I manage muxers with libav ... it's a torture
[02:00:20 CET] <Diag> kepstin: whats the best way to encode opus
[02:00:26 CET] <faLUCE> so I'm considering to use libmatroska
[02:00:50 CET] <kepstin> Diag: most convenient is probably to do it with ffmpeg? (-c:a libopus)
[02:00:53 CET] <faLUCE> the other problem of opus is that you have to resample
[02:00:59 CET] <Diag> reeeetarded
[02:01:11 CET] <furq> is your source not 48k
[02:01:16 CET] <Diag> fuck no
[02:01:19 CET] <furq> not you
[02:01:19 CET] <Diag> its at 192
[02:01:22 CET] <Diag> oh
[02:01:33 CET] <furq> although lol if you have 192khz shit
[02:01:40 CET] <Diag> ?
[02:01:52 CET] <Diag> i think its actually 96/24
[02:02:00 CET] <Diag> its from my badass soundblaster
[02:02:16 CET] <furq> only three times bigger than it needs to be then
[02:02:22 CET] <Diag> ?????//
[02:02:25 CET] <gurki> then you probably can just downsample it as sbs quality is kinda shitty
[02:02:26 CET] <gurki> scnr
[02:02:26 CET] <gurki> :P
[02:02:39 CET] <kepstin> if you're wondering why opus doesn't support >48kHz, go read https://people.xiph.org/~xiphmont/demo/neil-young.html - there's no point :/
[02:02:47 CET] <furq> you can downsample it anyway unless your name is rex and you like to chase sticks because you are a dog
[02:03:16 CET] <gurki> nah. 96/24 is actually pretty usefull assuming ure into recording n stuff
[02:03:18 CET] <Diag> lol wrong button
[02:03:28 CET] <furq> anything above 48k is completely pointless
[02:03:30 CET] <kepstin> (iirc, the opus encoder also has a lowpass filter around ~20kHz before encoding, too)
[02:03:30 CET] <Diag> i said this in  ##audio
[02:03:39 CET] <Diag> Theres a big difference between 441 and 96
[02:03:41 CET] <furq> 24-bit is useful if you are mastering a record
[02:03:48 CET] <furq> the extra sample rate makes no difference though
[02:03:57 CET] <Diag> yes it does
[02:04:09 CET] <Diag> umcompressed
[02:04:13 CET] <Diag> un*
[02:04:26 CET] <kepstin> only if your recording equipment has aliasing problems at lower rates... :/
[02:04:28 CET] <furq> if you believe that then i have got some cables to sell you
[02:04:39 CET] <furq> be sure to plug them in the right way or the bits will uh
[02:04:40 CET] <furq> fall out
[02:04:42 CET] <Diag> no, if you dont believe theres a difference youre a fuckin idiot
[02:04:54 CET] <Diag> The closer you are to 24khz the shittier the wave will be
[02:05:07 CET] <Diag> its not huge
[02:05:11 CET] <furq> whoa whoa enough with the science terms there einstein
[02:05:14 CET] <Diag> but its big
[02:05:16 CET] <kepstin> the higher you are above 20kHz the more inaudible the sound is so it doesn't matter?
[02:05:23 CET] <Diag> well
[02:05:31 CET] <Diag> at 16khz on a 48khz sample rate
[02:05:48 CET] <kepstin> at 16kHz on 48kHz sample rate... the wave will be represented perfectly.
[02:05:57 CET] <Diag> no it wont lol
[02:06:09 CET] <furq> here come some cool edit pro screenshots
[02:06:11 CET] <faLUCE> another shitty thing of vlc is that I have to add the muxer format to the url.
[02:06:15 CET] <faLUCE> this is so baaaad
[02:06:25 CET] <faLUCE> http://foooo/stream.ts
[02:06:32 CET] <furq> faLUCE: it's really best to just forget vlc exists
[02:06:34 CET] <Diag> honestly
[02:06:39 CET] <faLUCE> furq: I can't
[02:06:48 CET] <furq> didn't you say you had control over the receiving end
[02:06:56 CET] <faLUCE> furq: no, absolutely not
[02:07:01 CET] <furq> oh
[02:07:04 CET] <furq> well that's a shame
[02:07:11 CET] <Diag> youre getting 3 samples per wave
[02:07:14 CET] <faLUCE> I have to make it working with vlc player on android
[02:07:15 CET] <Diag> thats fucking shit
[02:07:29 CET] <Diag> id rather have 6
[02:08:05 CET] <phillipk> I'm having issues with my filter_complex.  I have one video (with audio) on which I'd like to layer 3 or more audio files, starting at specific times.
[02:08:24 CET] <faLUCE> in addition, I can't ask anything in the vlc channel, because I've been banned
[02:08:26 CET] <kepstin> Diag: as long as you have >2 samples per sine wave period, the reconstruction will be perfect, by nyquist theorem.
[02:08:36 CET] <Diag> I dont want "reconstruction"
[02:08:41 CET] <Diag> I want better input
[02:08:44 CET] <gurki> kepstin: theres a problem. world doesnt consist of sine waves.
[02:08:44 CET] <phillipk> Neither of the following commands work--but what's doubly odd, is the command makes the audio (in the one video input) get out of synch:
[02:08:46 CET] <phillipk> http://pastebin.com/fMhXuS9v
[02:08:49 CET] <furq> actually, that's only a "theory". i believe in intelligent audio design
[02:08:57 CET] <phillipk> http://pastebin.com/uN5nnSCr
[02:09:20 CET] <gurki> its actually kind of problematic to just call nqquist and be done with. (which is why i call b$ on that link...)
[02:09:33 CET] <kepstin> gurki: then you need to go read the theorem; all wave patterns can be represented by an infinite series of sine waves; an in practise you can ignore the ones above a point because they're inaudible anyways.
[02:09:39 CET] <phillipk> if anyone can just tell me what might not be correct in my -filter_complex and -map commands that'd be awesome.
[02:09:45 CET] <gurki> kepstin: i a aware of that.
[02:09:54 CET] <phillipk> thanks in advance--gotta go eat dinner
[02:10:11 CET] <gurki> problem: you will need quite a few high frequencies to reconstruct a sawtooth function, leave alone a rect
[02:10:24 CET] <gurki> hf reconstructing a rect with sines.
[02:10:51 CET] <kepstin> you need infinite sampling rate to represent a step function correctly, yes.
[02:10:54 CET] <kepstin> what's the point?
[02:11:09 CET] <faLUCE> anyway, is there any other multiplatform player that I can try, other than VLC and MPLAYER ?
[02:11:14 CET] <furq> mpv
[02:11:23 CET] <kepstin> all using higher sampling rates does is add more inaudible harmonics :/
[02:11:36 CET] <gurki> point is: there is reason behind 48kHz. but nyquist isnt the reason imho
[02:12:06 CET] <faLUCE> furq: let's try it
[02:12:23 CET] <faLUCE> but... is it better than vlc ?
[02:12:26 CET] <furq> yes
[02:12:29 CET] <Hello71> why do you CAPITALIZE random WORDS
[02:12:31 CET] <kepstin> well, the audio cd 44.1kHz is perfectly fine, 48kHz is just a nice round number with easy integer divisions that's high enough to represent ~20kHz correctly.
[02:12:43 CET] <Hello71> but YOU only do it HALF the TIME
[02:12:53 CET] <gurki> you can swap out 44.1 and 48 as you like in that statement i made there :)
[02:14:30 CET] <furq> my cables are still for sale btw
[02:14:33 CET] <furq> http://i.ebayimg.com/00/s/MTA2NlgxNjAw/z/P9oAAOSwAKxWYsnn/$_57.JPG
[02:17:23 CET] <kepstin> hmm? no, it follows - humans hear up to around or a little over 20kHz, by nyquist you need at least double that to represent it correctly, then round up a bit so we have a nice integer and a little headroom for the falloff of the anti-aliasing filter.
[02:19:13 CET] <furq> ah, but you see; if it was pointless to have 24/192 flac, then why would i have spent so much money on it?
[02:19:17 CET] <furq> check and mate
[02:20:05 CET] <kepstin> maybe it has secret messages hidden in the high frequencies. try slowing it down to 1/4 or 1/8 speed to hear them.
[02:20:19 CET] <Diag> furq: dunno, i could play 96mhz AM out of my card if i wanted to lol
[02:20:29 CET] <furq> actually it's because it allows for better hidden drawings of aphex twin's face in the spectrals
[02:20:30 CET] <Diag> KHZ*
[02:20:31 CET] <Diag> jesus
[02:20:34 CET] <Diag> i must be tired
[02:20:55 CET] <Diag> i have plenty of samples
[02:21:04 CET] <Diag> and plenty of room for higher freqs
[02:21:09 CET] <Diag> why cap yourself to 24k lol
[02:21:23 CET] <furq> because i'm not a dog
[02:21:26 CET] <furq> at least, not yet
[02:21:37 CET] <furq> who knows what the future holds
[02:21:41 CET] <Diag> dunno
[02:21:46 CET] <Diag> I like my card
[02:21:50 CET] <Diag> Lots of good shit
[02:22:10 CET] <Diag> Shit like
[02:22:20 CET] <Diag> actual amps for the volume control
[02:22:25 CET] <Diag> rather than just bit shifting/dropping
[02:22:37 CET] <Diag> or stupid software shit
[02:22:53 CET] <Diag> oh also
[02:22:54 CET] <Diag> ALSO
[02:23:03 CET] <furq> that's good because it is impossible to connect a soundcard to an external amp
[02:23:08 CET] <kepstin> amps in general don't have volume control; that's usually done with variable resistors if it's done in analog
[02:23:33 CET] <Diag> it produces a 96khz wave at ~95% amplitude of same at 60hz
[02:23:41 CET] <Diag> cant say that about much audio hardware
[02:23:45 CET] <kepstin> digital volume control probably has less distortion in most cases, particularly if you're using 24bit
[02:23:45 CET] <Diag> my old desktop for ex
[02:24:02 CET] <Diag> was dropping to about 25% at 20khz
[02:24:19 CET] <furq> you keep saying a lot of things which are not remotely the same as "it sounds better"
[02:24:25 CET] <Diag> it sounds better
[02:24:44 CET] <furq> have you abx tested it
[02:24:52 CET] <Diag> wtf is abx
[02:25:05 CET] <furq> why am i even talking to someone about audio quality who doesn't know what abx testing is
[02:25:25 CET] <furq> i guess at least that's better than the audiophiles who earnestly claim that doing an abx test reduces sound quality
[02:25:29 CET] <Diag> because you think resampling sounds good loloololololol
[02:25:40 CET] <Diag> you have no idea
[02:26:11 CET] <kepstin> there's a lot of things that are easily way, way, more audible than resampling
[02:26:22 CET] <furq> i bet you don't even have any 96khz audio
[02:26:25 CET] <Diag> Ok
[02:26:26 CET] <Diag> lol
[02:26:27 CET] <furq> i bet you don't even have any ears
[02:27:05 CET] <furq> this is just the card you picked from the tedious internet argument generator
[02:27:12 CET] <Diag> ha
[02:27:18 CET] <Diag> uhhuh
[02:27:21 CET] <Diag> sorry i test this shit
[02:27:27 CET] <Diag> and watch the waveforms with a scope
[02:27:34 CET] <Diag> and watch the actual deformation
[02:27:37 CET] <furq> shame you don't abx test it, eh
[02:27:40 CET] <kepstin> confirmed: no ears. listens to music with eyes.
[02:27:59 CET] <furq> the truth comes out at last
[02:28:14 CET] <Diag> Couldnt you dumb fucks tell taht when i was posting pictures of waveforms
[02:28:28 CET] <furq> i could tell something when you were doing that
[02:29:44 CET] <kepstin> https://youtu.be/cIQ9IXSUzuM?t=520 hey look pictures of waveforms: https://youtu.be/cIQ9IXSUzuM?t=424
[02:29:51 CET] <kepstin> er, second link is more fun
[02:30:48 CET] <furq> i should donate to xiph.org so monty can buy a razor
[02:31:48 CET] <faLUCE> is there a way to detect a reference frame with libav? I have the AVPacket got from av_encode_audio()
[02:32:07 CET] <kepstin> not sure what you mean by "reference frame"
[02:32:21 CET] <kepstin> audio codecs in general don't have anything like keyframes in video
[02:32:49 CET] <faLUCE> kepstin: something that helps to make the stream seekable
[02:33:11 CET] <faLUCE> I encode on the fly, and at a certain point, I stream the packets
[02:33:24 CET] <faLUCE> I don't stream when the encoding starts
[02:33:39 CET] <kepstin> faLUCE: you can start decoding audio at any frame, but the decoder has to throw out the first few samples it decodes (depending on the codec this is either handled automatically, or has to be signalled)
[02:34:54 CET] <faLUCE> kepstin, mp4 wants a seekable stream
[02:35:21 CET] <faLUCE> then I have to start the stream with a keyframe
[02:35:45 CET] <kepstin> for video, yes... audio isn't video.
[02:36:35 CET] <faLUCE> kepstin: it warns me for audio-only
[02:36:54 CET] <kepstin> what warns you, and what warning message do you get?
[02:37:55 CET] <faLUCE> kepstin: [mp4 @ 0x353f860] muxer does not support non seekable output
[02:38:37 CET] <kepstin> that has nothing to do with the codec, that's just saying you can't write mp4 container to a stream/pipe
[02:38:52 CET] <kepstin> you can only write mp4 to files, because the format's silly.
[02:39:08 CET] <kepstin> needs to write some data at the start which you only know after you've already written the end.
[02:39:21 CET] <faLUCE> kepstin: I see
[02:39:22 CET] <faLUCE> thanks
[02:39:40 CET] <faLUCE> I thought mp4 could be streamed
[02:39:41 CET] <kepstin> aac in mkv should work find, just mp4 won't
[02:40:12 CET] <kepstin> mp4 can only be used for streaming with segmented files or video-on-demand pre-encoded files
[02:40:44 CET] <kepstin> (where segmented files obviously has high latency, and you can't pre-encode live streams)
[02:44:35 CET] <faLUCE> kepstin: but does the streamer send trailer infos to the receiver before it starts?
[02:45:33 CET] <kepstin> for pre-encoded live streams, you can use tools after encoding (e.g. ffmpeg's "-movflags faststart") to move the index & format info to the start of the file so it can be played without seeking
[02:45:41 CET] <kepstin> for pre-encoded not-live streams*
[02:47:47 CET] <faLUCE> furq: mpv doesn't play matroska http at all. Tried with both my program and with ffmpeg (ffmpeg -i test.mka -listen 1 -f matroska http://localhost:8080/stream)
[02:48:54 CET] <kepstin> faLUCE: works fine for me...?
[02:49:49 CET] <faLUCE> kepstin: you can play http matroska live streams with mpv?
[02:49:58 CET] <kepstin> yep
[02:50:11 CET] <faLUCE> kepstin: how did you test it?
[02:51:15 CET] <kepstin> in one terminal, `ffmpeg -f pulse -i default -c:a libopus -b:a 128K -listen 1 -f matroska http://localhost:8080/stream` in the other `mpv http://localhost:8080/stream` and now my room is full of feedback so i ctrl-c'd it.
[02:53:31 CET] <faLUCE> kepstin: same error, which version of mpv do you use?
[02:53:49 CET] <faLUCE> prebuilt or compiled?
[02:54:15 CET] <kepstin> whatever my distro has, --version output claims 0.21
[02:54:58 CET] <kepstin> hmm, i should update that.
[02:55:09 CET] <faLUCE> which distro do you use?
[03:02:20 CET] <furq> that works for me with 0.23
[03:02:23 CET] <furq> it doesn't spawn a window though
[04:06:29 CET] <gurki> dear god. theese libmfx compile-error-messages really need a rework. telling me that "libmfx not found using pkg-config" although it clearly has been found from what the config.log tells me, the issue being some mixup while throwing gcc at it
[04:06:43 CET] <gurki> configure *
[04:08:06 CET] <furq> that's not specific to libmfx, that happens with pretty much every dependency
[04:08:27 CET] <gurki> i didnt know that. i assume the best until proven otherwise :)
[04:08:51 CET] <furq> it's not great but anyone who builds ffmpeg regularly knows to just check config.log
[04:09:25 CET] <gurki> well it took me quite a while and fumbling with strace output before i figured checking that might be an option :(
[04:09:36 CET] <furq> it mentions config.log in the error doesn't it
[04:10:01 CET] <gurki> actully it doesnt
[04:10:02 CET] <furq> but yeah it should at least say something like "not found using pkg-config or error running tests"
[04:10:10 CET] <furq> because it's normally the latter
[04:10:11 CET] <gurki> (i was actually going to propose doing just that)
[04:10:35 CET] <gurki> argh. i have to take that back. gurki failed.
[04:11:52 CET] <gurki> it stats that including the log by whining here about the error might help
[04:11:53 CET] <furq> it mentions it in a slightly roundabout way
[04:11:57 CET] <furq> yeah
[04:12:04 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L477-L498
[04:12:06 CET] <gurki> guess thats why i overlooked it
[04:13:16 CET] <furq> i can imagine it's non-trivial to reliably tell why the test failed, but "not found using pkg-config" is usually not the reason
[04:13:46 CET] <gurki> well it might actually be an idea to print the very error that could be found in the config.log ...
[04:14:07 CET] <gurki> but then you seem to try-and-error a lot of stuff during the configure process, so that might not be that easy
[04:14:32 CET] <furq> the way it's written atm makes that difficult
[04:18:18 CET] <gurki> well you could tail the config.log ...
[04:18:34 CET] <gurki> thats kind-of independent of internal states of whatever
[04:18:53 CET] <gurki> not exactly good style, but should work
[04:52:14 CET] <faLUCE> well. I don't understand.... it seems that there's no way to stream HTTP live audio with ffmpeg without having a big delay on the receiver
[05:37:33 CET] <kepstin> unless you control the client side and can manage the buffering there, that's gonna be true regardless of whether ffmpeg is involved or not...
[05:40:04 CET] <kepstin> i wouldn't be surprised if it's less noticable with video simply because the players are using a min buffer size that holds more audio than audio+video.
[09:44:06 CET] <ePirat> What are good settings for swresample for realtime resampling with high quality?
[09:48:49 CET] <thebombzen> anyone know how to get the image2 muxer to overwrite the same file
[10:46:05 CET] <durandal_1707> thebombzen: you cant
[10:46:21 CET] <thebombzen> um you used to be able to?
[10:47:45 CET] <thebombzen> lol rtfm
[10:47:50 CET] <thebombzen> @me it's just -update 1
[14:53:39 CET] <joltmode> I have a video source that emits a png to stdout at random intervals. How can I use it as an input for ffmpeg and render a video @ constant frame rate? I want that the last image to be looped until replaced.
[14:58:40 CET] <DHE> I think you can do that if it overwrites the old file
[15:00:58 CET] <joltmode> I have some png reading errors at times then. ffmpeg eventually stops because of those. Don't know, something with overwrite I/O or what not..
[15:02:03 CET] <DHE> probably needs to be an atomic overwrite. write to a new file and rename() over the old one
[15:03:33 CET] <joltmode> Ah, I attempted with cp()... is rename() different from it?
[15:03:49 CET] <BtbN> it's atomic
[15:04:09 CET] <JohnPreston72> Anyone has some good doc ref: Use NVIDIA + FFMPEG for nvenc etc.
[15:04:19 CET] <JohnPreston72> and maybe even some benchmarks ? :)
[15:11:18 CET] <kerio> joltmode: cp will open the old file, write, truncate and close
[15:11:48 CET] <kerio> anyone with that file open will see any of the modifications done to the file, essentially at random
[15:12:11 CET] <kerio> (i'm not even sure the order of modification is preserved, without an explicit fsync)
[15:12:25 CET] <kerio> so instead of updating the file by opening and writing to it
[15:12:32 CET] <kerio> you should write to a brand new temporary file
[15:12:36 CET] <kerio> and rename it
[15:12:50 CET] <kerio> whoever opened the file will either get the old file, or the new file
[15:13:00 CET] <kerio> and both will be written to completion
[15:14:30 CET] <joltmode> cool, good to know
[15:17:03 CET] <kerio> you can even do some slightly fancier and crazier stuff
[15:18:12 CET] <kerio> but it depends on the OS, it's nonstandard
[15:18:18 CET] <kerio> you can like
[15:18:36 CET] <kerio> open a temporary file with no name, write to it, then rename its file descriptor onto the new file
[15:36:29 CET] <joltmode> cool, changed cp to mv and it works flawlessly. thanks guys!
[18:44:21 CET] <phillipk> I have a question about this excerpt: f -filter_complex "[0:2]adelay=10000|  10000[delayed];[0:1][delayed]amix[mixout]"
[18:44:36 CET] <phillipk> what's "0:2" --the first input, third stream in that input?
[18:48:31 CET] <JEEB> yup
[18:49:44 CET] <phillipk> what if I did [0:a]   audio in the first input?
[18:51:38 CET] <JEEB> phillipk: that would map against all audio tracks
[18:51:53 CET] <JEEB> thus 0:a:0 is something specific to a single track
[18:52:03 CET] <JEEB> also languages can be picked etc
[19:07:09 CET] <phillipk> thanks--now if I can figure out another issue (when I have a video+audio input and then several audio onlys that I'm adelay and amix... the audio in the main video gets out of synch).  I'll see if doing adelay=n|n works better than what I had before: adelay=n
[19:09:38 CET] <phillipk> so, if in my filter_complex, I do:  [1]  it just takes the entire second input right?
[19:13:29 CET] <phillipk> here's my current command for this step--any insights are welcome (my issue is the audio in  "audio_and_video.ts" gets out of synch!): http://pastebin.com/hbn3AzgP
[19:40:49 CET] <durandal_1707> phillipk: all audio are stereo?
[19:51:03 CET] <phillipk> yes
[19:52:30 CET] <phillipk> the stuff in the -filter_complex (channel_layouts=stereo) is what I figured would ensure this--but I actually pre-process the audio to make sure every one is stereo
[20:11:53 CET] <shincodex> so... this is a stupid question but
[20:12:04 CET] <shincodex> is ffmpeg leaking like 4 bytes every other idk 5 minutes
[20:12:41 CET] <JEEB> it shouldn't, but everything is possible so run that baby under valgrind to make sure :P
[20:13:56 CET] <shincodex> hopefully vld will shoot something out
[20:14:02 CET] <shincodex> and hopefully its my misuse
[20:16:58 CET] <shincodex> whoa i think i found the pattern
[20:17:10 CET] <shincodex> 8 seconds 4 bytes, 2 seconds 4 bytes 5 seconds 4 bytes repeat
[20:17:35 CET] <shincodex> do these lotto numbers make anyone remember a time?
[20:30:04 CET] <GNU\colossus> hi. I have a few hundred audio files (in OGG Vorbis and MP3 files) that I have rescued from a broken storage medium. can I somehow use ffmpeg to decode (but not play) them as fast as possible, and produce a list of files that seem to have problems in their data paylod/did not decode cleanly?
[20:31:46 CET] <kerio> GNU\colossus: ffmpeg -i foo.mp4 -f null dummy
[20:31:52 CET] <kerio> er, mp3
[20:32:05 CET] <kerio> it'll decode all the streams
[20:32:10 CET] <GNU\colossus> kerio, thanks!
[20:32:14 CET] <kerio> not sure how to make it block on errors
[20:32:27 CET] <kerio> or how much of an error is an error, to you
[20:32:58 CET] <GNU\colossus> I think Ican work with that :)
[20:33:23 CET] <kerio> you probably want -nostats
[20:33:27 CET] <kerio> to disable the progress thingy
[20:33:31 CET] <GNU\colossus> I'm not sure, actually :) just looking for a way to trim down the list of files I'll have to listen to to determine if I need to restore them from elsewhere
[20:35:33 CET] <kerio> and that is why we use filesystems with redundancy and checksums
[20:38:32 CET] <GNU\colossus> kerio, well, not on a crappy mp3 hifi appliance that only supports FAT32-formatted media :)
[20:38:41 CET] <GNU\colossus> but yeah, in a perfect world...
[20:39:04 CET] <kerio> apple got so close
[20:39:14 CET] <kerio> and then they decided that they didn't need checksums on data
[20:39:29 CET] <Diag> >crappy mp3
[20:39:35 CET] <Diag> mp3 sounds fan fucking tastic
[20:39:40 CET] <kerio> no it doesn't
[20:39:45 CET] <Diag> (inb4 furq)
[20:39:51 CET] <kerio> you can make it sound decent
[20:40:00 CET] <kerio> by using way too much bits
[20:40:04 CET] <kerio> many
[20:40:05 CET] <Diag> kerio: http://i2.kym-cdn.com/photos/images/newsfeed/000/992/401/e37.png
[21:11:02 CET] <DHE> I ran "sh configure --disable-hwaccels" but it still lists hwaccels as enabled, including nvenc, cuda, xvmc and so on. Bug?
[21:32:21 CET] <francesco_> hey people, could you explain me the use of AVDiscard ?
[21:32:28 CET] <francesco_> when is it useful?
[00:00:00 CET] --- Tue Jan 31 2017