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

burek burek021 at gmail.com
Tue Jan 2 03:05:03 EET 2018

[01:21:55 CET] <kierank> Happy new year FFmpeg psychopaths
[01:24:13 CET] <DHE> high functioning psychopaths, thanks
[01:47:07 CET] <iive> i find that really offensive.
[01:57:17 CET] <atomnuker> you have to be mental and a psychopath to a degree to do what we do
[01:57:42 CET] <atomnuker> else we'd be writing decoders in python or whatever else is in style
[01:58:38 CET] <iive> psyhopathy is very specific desices and is in no way releated to coding anything.
[02:00:27 CET] <atomnuker> guess your dictionary's different then, words tend to get watered down the more they're used
[02:01:22 CET] <iive> psychpaths are people who have no empaty and act mostly in self interest
[02:01:42 CET] <iive> calling this people who work on open source project is insult.
[02:07:32 CET] <atomnuker> whatever
[02:08:29 CET] <tmm1> 2017 is over, lets agree that words have meanings
[02:09:01 CET] <iive> we shuold have learning this back in 2016...
[02:47:54 CET] <jamrial> iive: i thought that was sociopaths?
[02:50:46 CET] <iive> jamrial, psychopaths are born like this, sociopaths are trained to behave like this.
[18:06:18 CET] <cone-636> ffmpeg 03Carl Eugen Hoyos 07master:bddf31ba7570: configure: bump year
[20:15:47 CET] <RiCON> atomnuker: getting this linking ffms2 with ffmpeg with disabled opus encoder/decoder since your changes, any idea what's causing it? https://i.fsbn.eu/4zl2.txt
[20:20:12 CET] <atomnuker> can you check if adding #include <opus.h> right after ffmath.h helps?
[20:20:44 CET] <atomnuker> (opus.h is already included by opus_celt.h which is already included by opus.c)
[20:20:59 CET] <atomnuker> and opus.h includes opus_rc.h
[20:33:07 CET] <RiCON> atomnuker: does opus_parser.c include the necessary headers?
[20:33:24 CET] <RiCON> it's probably because of that (disabled dec/enc but not disabled parser)
[20:35:00 CET] <atomnuker> none of the errors look like opus_parser.c issues
[20:38:36 CET] <RiCON> opus_parser doesn't list opus_rc.o in the makefile
[20:51:11 CET] <RiCON> atomnuker: yeah, this is enough to fix it: https://0x0.st/sKk6.txt
[20:56:55 CET] <cone-636> ffmpeg 03Rostislav Pehlivanov 07master:fdbd26196702: lavc/Makefile: fix opus_parser dependencies
[20:57:00 CET] <atomnuker> RiCON: fixed, thanks
[21:09:40 CET] <kierank> michaelni: thanks
[21:57:41 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:9f7dbaad7e36: avfilter/af_crystalizer: use outlink instead of inlink
[22:11:25 CET] <wm4> another part in the "fucking broken EOF change" saga: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls_schannel.c#L419
[22:25:45 CET] <kierank> michaelni: so you don't have an issue with s->block2?
[22:25:48 CET] <kierank> i dislike it a lot
[22:27:48 CET] <cone-636> ffmpeg 03Carl Eugen Hoyos 07master:1112ba012df3: lavf/mov: Use av_fast_realloc() in mov_read_stts().
[22:30:39 CET] <cone-636> ffmpeg 03Carl Eugen Hoyos 07master:21b5990da461: lavu/mem: Do not realloc in av_fast_realloc() if size == min_size.
[22:39:48 CET] <rcombs> wm4: what changed in EOF handling anyway
[22:39:56 CET] <michaelni> kierank, i dont see a obvious better way. So no i dont see an issue. Maybe it could be renamed to something with 32 in the name to indicate the type
[22:39:58 CET] <rcombs> tbh I've never really understood how EOF works in lavf
[22:40:27 CET] <BtbN> rcombs, a lot of functions just returned 0 on EOF
[22:40:37 CET] <BtbN> but reading 0 bytes is actually a thing, and AVERROR_EOF exists
[22:40:56 CET] <BtbN> And the more stuff is fixed, the more other stuff breaks because of it...
[22:41:43 CET] <wm4> 0 for EOF matches POSIX semantics too
[22:41:44 CET] <rcombs> read()-style
[22:42:03 CET] <rcombs> I guess it's kinda unavoidable for e.g. avio_r8
[22:42:04 CET] <wm4> but now returning 0 will strictly make the avio buffer code retry
[22:42:28 CET] <wm4> (which means things will get stuck instead of ending)
[22:42:54 CET] <wm4> and the assumption that 0==eof is apparently hardcoded in tons of code
[22:43:17 CET] <rcombs> was it undocumented
[22:43:53 CET] <wm4> I guess pretty much, which lead to nicolas george claim things
[22:46:05 CET] <wbs> no it was documented; for external use, a wrapper allows the old behaviour still (with a warning about this changing), but for internal code no such wrapper should be used since all code was intended to be changed at once
[22:46:31 CET] <rcombs> but there wasn't enough testing so cases weren't found, I guess?
[22:47:05 CET] <wbs> probably not much outside of what fate covers
[22:47:09 CET] <wm4> wbs: I thought we were talking about the situation before the change
[22:47:24 CET] <rcombs> and fate covers little in the way of avio
[22:47:25 CET] <wbs> wm4: before the change, I think it was documented that 0 meant EOF
[22:47:55 CET] <rcombs> 0 for EOF seems particularly bad for nonblocking I/O
[22:48:11 CET] <wm4> nobblocking IO returns EAGAIN
[22:48:16 CET] <wm4> *non
[22:48:21 CET] <rcombs> ah
[23:52:40 CET] <durandal_1707> nobody uses afir :(
[23:54:41 CET] <wm4> why would anyone
[23:55:29 CET] <wm4> these filters have no visibility and are probably hard to use
[23:55:58 CET] <wm4> and also too many filters that appear to roughly do similar things
[00:00:00 CET] --- Tue Jan  2 2018

More information about the Ffmpeg-devel-irc mailing list