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

burek burek021 at gmail.com
Sat Sep 30 03:05:02 EEST 2017

[00:09:37 CEST] <cone-230> ffmpeg 03Diego Biurrun 07master:533339bdcc3b: build: Drop leftover reference to old EXAMPLES logic
[00:09:38 CEST] <cone-230> ffmpeg 03James Almer 07master:d4b00a23c682: Merge commit '533339bdcc3b39bbd708c723b3cd0b5898350f0f'
[00:26:05 CEST] <cone-230> ffmpeg 03Diego Biurrun 07master:db4903eb4875: build: Avoid duplication in examples lists
[00:26:06 CEST] <cone-230> ffmpeg 03James Almer 07master:0351b8e358f6: Merge commit 'db4903eb4875bed6c5b8a4259cdd7bc1768dfdf6'
[00:35:36 CEST] <jamrial> why is there a Makefile in doc/examples if it's not included anywhere?
[00:35:58 CEST] <jamrial> and why does it look like it's mean to be used post libraries installation? wtf
[00:36:24 CEST] <jamrial> calling pkg-config for fflibs, duplicating the examples list
[00:40:46 CEST] <wm4> because you build them separately
[00:41:07 CEST] <wm4> (it's also something that really doesn't encourage me on working on the examples)
[00:56:56 CEST] <jamrial> wm4: make examples works fine in an out of tree build without installing anything
[00:57:26 CEST] <jamrial> from the root of the build folder i mean
[00:59:59 CEST] <wm4> it does?
[01:01:17 CEST] <jamrial> try it?
[01:02:00 CEST] <jamrial> as i said, doc/examples/Makefile is not included anywhere
[01:02:54 CEST] <jamrial> maybe some merge made it obsolete/unused and nobody realized it, because is see new entries have been added with ever new example
[01:05:30 CEST] <wm4> seems to work fine
[01:11:12 CEST] <Ahti333> wm4 wrt mp3 chapters: I don't see anything that would cause a crash. if both the format and id3 contain chapter info, it would probably mess up the order and/or cause duplicate chapters in s->chapters (or if they don't contain identical info, some or all of the id3 info could be overwritten by the format chapters). this depends on how the format identifies chapters and for some formats on chapter ids in the file. is that what you mean by
[01:11:12 CEST] <Ahti333>  undefined behaviour or would that be fine?
[01:15:02 CEST] <wm4> sounds like it's probably fine then
[01:21:20 CEST] <Ahti333> ok so what's the process to get this merged? do I need to do anything anywhere? i've already run fate test and they pass fwiw
[01:40:38 CEST] <wm4> I don#t know, the difference between ff_id3v2_read and id3v2_read_internal hints that this was intentional
[01:41:00 CEST] <tmm1> if i want to commit the hevc patchset that was reviewed on the list to master, do i need to add signed-off-by to the commits first? should i add myself or people who said LGTM on the ML too?
[01:41:10 CEST] <wm4> and the way the apic thing is done demonstrates how to do it in a way how to avoid these potential issues
[01:41:24 CEST] <wm4> if it were after me, I'd forbid using id3v2 in ffmpeg for most formats anyway
[01:42:04 CEST] <wm4> tmm1: I think the convention is to add yourself as signed-off-by, although ffmpeg as a project doesn't seem to enforce or require this
[01:42:31 CEST] <wm4> some people add "Reviewed-by: " headers for each reviewer
[01:42:45 CEST] <wm4> but that's also not enforced or required in ffmpeg
[01:43:55 CEST] <tmm1> ok thanks
[01:46:48 CEST] <iive> the documentation ask the sender to sign it off
[01:51:36 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:c32077c0ee1b: avcodec/hevc_ps: extract SPS fields required for hvcC construction
[01:51:37 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:3d4f8b9184a4: avcodec/videotoolbox: add hevc support
[01:52:19 CEST] <tmm1> and then i should reply to the patches on the list to say they were applied?
[01:53:16 CEST] <wm4> yeah, that's usually done
[01:56:50 CEST] <JEEB> so where in a patch could I add my own text which wouldn't get applied as the commit message?
[01:57:37 CEST] <tmm1> format-patch cover letter?
[01:58:01 CEST] <JEEB> that's separate
[01:58:15 CEST] <JEEB> as in, cover letter is a separate file IIRC
[01:58:32 CEST] <JEEB> while I've seen people put tl;dr in the patch in a location that doesn't get applied
[01:59:26 CEST] <wm4> after commit message and before the first file I think
[01:59:32 CEST] <JEEB> ah
[01:59:42 CEST] <wm4> below the ---
[01:59:49 CEST] <JEEB> right, there
[01:59:50 CEST] <JEEB> cheers
[02:00:05 CEST] <Ahti333> wm4 i guess the proper solution wouldn't require touching all the formats if we only supported id3 chapters in mp3 files, i'll take a stab at that later
[02:03:37 CEST] <JEEB> alright, sent a patch out to add me to the general devs list in MAINTAINERS
[02:10:11 CEST] <wm4> huh, ffmpeg still doesn't support ttml?
[02:10:33 CEST] <rcombs> it's ~XML~
[02:10:38 CEST] <rcombs> though there's an XML parser now so
[02:35:06 CEST] <cone-230> ffmpeg 03James Almer 07master:e16ea52ed35c: configure: fix enabling SDL2 without pkg-config
[08:43:43 CEST] <cone-095> ffmpeg 03Tobias Rapp 07master:792b1629a881: fate: increase fuzz for refcmp filter tests
[09:34:54 CEST] <JEEB> wm4: ugh, TTML
[09:35:13 CEST] <JEEB> I've got some stuff around that needs to be pretty much rewritten with regards to that :D
[09:57:40 CEST] <ubitux> so i'm killing vda today?
[10:47:53 CEST] <JEEB> ok, seems like the test case worked but negative cts offset actually gets broken by additional sanity checks added to movenc.c in FFmpeg :)
[10:48:00 CEST] <JEEB> I will be patching that and adding more tests
[11:35:31 CEST] <JEEB> I have this feeling that check_pkt() is completely irrelevant to the spec in various ways
[11:36:31 CEST] <JEEB> and is effectively breaking the negative cts offsets stuff
[11:36:38 CEST] <JEEB> it just doesn't pop up with the tests, funny enough
[12:12:46 CEST] <wm4> ubitux: kill it
[12:46:04 CEST] <JEEB> ok, I'm now torn by either removing check_pkt with predjudice (since the sanity checks are not actually according to the spec and break even more now with negative cts offset)
[12:46:37 CEST] <JEEB> so completely valid stuff gets "fixed" by that function (which is supposed to be some sort of "sanity checker"?)
[12:47:24 CEST] <JEEB> or I'll try to make it closer to what the spec says and hope that it is not breaking any valid cases (removal of the function will make sure *all* valid cases get through)
[13:52:20 CEST] <ubitux> ah fuck i didn't realized the public functions in vda.h
[13:52:22 CEST] <ubitux> meh
[13:53:07 CEST] <JEEB> \o/
[13:53:10 CEST] <wm4> these would need to be stubbed out
[13:57:48 CEST] <nevcairiel> we already had stubs
[13:57:55 CEST] <nevcairiel> in vda.c, for when the feature is disabled
[14:25:02 CEST] <BBB> ubitux: but youre just deprecating it, right?
[14:25:10 CEST] <BBB> so that should be ok
[14:25:29 CEST] <ubitux> no, i'm dropping it
[14:25:39 CEST] <ubitux> currently deprecating the pix fmt only
[14:25:48 CEST] <ubitux> i'll have to deprecate the stubs too
[14:34:50 CEST] <BBB> ubitux: ah, I see& sorry, that sucks, makes it a lot more complex :(
[14:35:13 CEST] <ubitux> well, actually&
[14:35:33 CEST] <ubitux> unless i'm missing something, the stubs in vda.o were never available
[14:35:56 CEST] <ubitux> because the file is compiled conditionnally (whether you have vda or not)
[14:36:18 CEST] <ubitux> OBJS-$(CONFIG_VDA)                        += vda.o videotoolbox.o
[14:36:25 CEST] <ubitux> that's the only place where vda.o is added
[14:42:33 CEST] <BBB> I dont tihnk you should be expected to fix that while deprecating it
[14:42:45 CEST] <BBB> so maybe change the check for CONFIG_VDA inside vda.c to FF_API_VDA?
[14:42:51 CEST] <BBB> then it actually does something meaningful ;)
[14:43:02 CEST] <BBB> and it doesnt make it worse :-p
[15:57:17 CEST] <BBB> so I guess that finishes vmafmotion, now on to vmafs dlm/adm& man this stuff takes so long
[16:09:18 CEST] <atomnuker> kierank: https://www.nytimes.com/2017/09/28/us/politics/immigrants-social-media-trump.html
[16:10:14 CEST] <atomnuker> how stress-free will be your flight to demuxed now that the man knows you support labour?
[16:12:51 CEST] <jamrial> ubitux, michaelni: care to check/test/comment https://github.com/jamrial/FFmpeg/commits/mergework ?
[16:12:57 CEST] <jamrial> basically, as the libav commit states, it splits the logic for building examples from doc/ off into a separate Makefile in the doc/example folder
[16:14:06 CEST] <jamrial> problem is, we already have a Makefile in that folder, but it's separate from the build system. it's meant to be installed as part of the documentation, to help users compile the installed .c example files
[16:14:16 CEST] <wm4> atomnuker: so the US state is now doing what advertisers have done for years?
[16:15:18 CEST] <jamrial> so what i did was move the existing for-install Makefile to "Makefile.install", then made the build system rename it when installing it
[16:16:08 CEST] <jamrial> dunno if that's the best solution, but it works and doesn't clash with the new build system Makefile
[16:17:15 CEST] <jamrial> what i might try later is remove the for-install Makefile altogether and create it automatically during configure (or maybe compilation)
[16:18:07 CEST] <jamrial> to remove duplication. we have like three places where we need to add a line for every new example
[16:18:22 CEST] <atomnuker> wm4: advertisers usually aren't resposible for border control or I think you'd have a headache by the time you got through
[16:19:09 CEST] <ubitux> jamrial: i'll have a look tonight (let's say in about 4hours)
[16:19:37 CEST] <jamrial> ubitux: ok, thanks!
[16:20:15 CEST] <atomnuker> (though tbf you always feel stressed when going through border control, that's part of why schengen is awesome)
[16:51:18 CEST] <hanna> you lose the moment you decide to enter the U.S.
[16:58:30 CEST] <ldts> just created an account on trac.ffmpeg.org to add documentation support for V4L2 M2M (https://trac.ffmpeg.org/wiki/HWAccelIntro) but is unclear to me how to modify this page...do I need special permissions?
[17:02:31 CEST] <ldts> btw this is Kodi running ffmpeg v4l2 being demoed today: https://goo.gl/E8iyZX 
[17:02:39 CEST] <wm4> ldts: is there a "Edit this page" button on the bottom?
[17:03:08 CEST] <ldts> wm4: argh! I expected to be at the top. sorry, yes
[18:14:28 CEST] <feliwir> hey, i am having trouble with resampling my audio. When i want to do av_free on a buffer allocated with av_samples_alloc my application always crashes
[18:14:33 CEST] <feliwir> see here: https://gist.github.com/feliwir/0431412ab1419b17e9bd69df6b0c2fd8#file-audiostream-cpp-L65
[18:15:23 CEST] <feliwir> help is greatly appreciated
[18:17:38 CEST] <feliwir> JEEB, you told me i had to do resampling the other day. Maybe you see any errors?
[18:35:07 CEST] <cone-095> ffmpeg 03Carl Eugen Hoyos 07master:44bdb88811a4: lavf/bit: Only build the G.729 bit demuxer if requested.
[18:39:50 CEST] <feliwir> noone? :(
[18:51:14 CEST] <cone-095> ffmpeg 03Carl Eugen Hoyos 07master:6f7bd8cd90de: lavf/bit: Use pkt->size instead of a constant for G.729 frame size.
[19:17:41 CEST] <ubitux> jamrial: can you push on your master the hash on which merge work is based?
[19:17:57 CEST] <ubitux> (it will help me identify where the mergework actually starts)
[19:20:26 CEST] <jamrial> ubitux: done
[19:20:38 CEST] <jamrial> i think
[19:24:58 CEST] <ubitux> jamrial: what you did seems sane to me
[19:25:10 CEST] <ubitux> i didn't look at the details, but your comment on irc makes sense
[19:25:25 CEST] <jamrial> any suggestion for the name other than Makefile.install?
[19:25:28 CEST] <ubitux> if you could add it to the commit description of the merge that would be nice
[19:25:35 CEST] <ubitux> Makefile.example
[19:25:46 CEST] <jamrial> ok
[19:25:55 CEST] <ubitux> i'm not sure about having it generated btw, it's nice to be able to link to it in the source tree
[19:26:14 CEST] <ubitux> (like, you give a gitweb url to someone "here is an example on how to build it")
[19:26:16 CEST] <ubitux> but well
[19:26:24 CEST] <ubitux> that could be discussed later
[19:26:45 CEST] <jamrial> sure. just figured that having three files where you have to add a line for every new example seemed annoying
[19:27:04 CEST] <ubitux> yeah, that sucks
[19:27:15 CEST] <ubitux> btw, i'd rather remove the Makefile in the subdirs
[19:27:23 CEST] <ubitux> since building within a subdir is not supported
[19:27:47 CEST] <ubitux> i'd rather have a FFconfig
[19:27:53 CEST] <ubitux> (as Kconfig in the kernel)
[19:27:56 CEST] <ubitux> or config.mak
[19:27:58 CEST] <ubitux> or whatever
[19:28:21 CEST] <ubitux> so it's explicit that we do not actually support make runs in subdir 
[19:28:50 CEST] <jamrial> sounds like quite the overhaul, especially for the library makefiles
[19:29:03 CEST] <ubitux> well, it can still be a makefile
[19:29:04 CEST] <atomnuker> the kernel supports such but our dirs are so huge it would be pointless
[19:29:15 CEST] <jamrial> the whole SUBDIR logic
[19:29:18 CEST] <ubitux> just running "make" will not find any makefile
[19:29:29 CEST] <ubitux> (unless you explicit the file)
[19:29:30 CEST] <jamrial> ah, you mean renaming them
[19:29:34 CEST] <ubitux> yeah :)
[19:29:42 CEST] <jamrial> sorry, thought you wanted to merge everything into one massive file :p
[19:29:45 CEST] <ubitux> jamrial: btw, you install as "Makefile"?
[19:29:50 CEST] <ubitux> no no :)
[19:30:28 CEST] <jamrial> I call install with -T (file as target rather than directory), and the target as doc/examples/Makefile
[19:30:37 CEST] <JEEB> ugh, why did I press the "defragment virtual disk" button
[19:30:44 CEST] <JEEB> now I can't work with the VM I wanted to work on \o/
[19:31:22 CEST] <ubitux> jamrial: then that's fine with me
[19:31:42 CEST] <JEEB> (I wanted to fix up the movenc "sanity" check which was already borked before negative cts offsets, but now can also fsck up pretty much all cases of negative cts offsets)
[19:32:07 CEST] Action: JEEB is getting a love-hate relationship with https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L4992...L5005
[19:32:39 CEST] <ubitux> jamrial: btw, you may want to fix the Makefile dir reference in the faq.texi ("examples" vs "example") and explicit that it's in the installed data directory
[19:32:46 CEST] <ubitux> or as "Makefile.example" in the source tree
[19:32:55 CEST] <jamrial> ok
[19:33:17 CEST] <ubitux> again, thanks for working on this
[19:34:16 CEST] <jamrial> no prob. i want the queue gone as much as everyone else :p
[19:34:45 CEST] <jamrial> for that matter, i'm about to reach the commit that will move the CLI files to a separate folder
[19:35:16 CEST] <stephan_> what's the size of the buffer allocated with av_samples_alloc ?
[19:35:49 CEST] <stephan_> when i use linesize as the size i get memory corruption
[19:59:49 CEST] <BBB> stephan_: frame->buf[0]->size (assuming its interleaved channels, not planar channels)
[20:06:50 CEST] <stephan_> BBB, i need the size writen by swr_convert
[20:07:00 CEST] <stephan_> https://github.com/feliwir/arda/blob/master/src/audio/audiostream.cpp#L276
[20:39:59 CEST] <cone-095> ffmpeg 03Diego Biurrun 07master:acb0dea27eff: build: Split logic for building examples off into a separate Makefile
[20:40:01 CEST] <cone-095> ffmpeg 03James Almer 07master:b25d6290c67e: Merge commit 'acb0dea27efff4b35796015b96570b59fd517078'
[20:42:35 CEST] <JEEB> huh
[20:42:36 CEST] <JEEB> http://up-cat.net/p/8df5d7e3
[20:47:06 CEST] <ubitux> doesn't seem to be used except for a sizeof
[21:04:37 CEST] <jamrial> ugh
[21:06:30 CEST] <jamrial> https://github.com/FFmpeg/FFmpeg/commit/b25d6290c67e193b91becab12e6c88df134cee81#commitcomment-24658478
[21:06:32 CEST] <jamrial> any ideas?
[21:07:26 CEST] <jamrial> ubitux: ^
[21:07:35 CEST] <jamrial> since you handled macOS build system stuff recently
[21:08:15 CEST] <ubitux> it's like cp
[21:08:19 CEST] <ubitux> you can explicit the outfile
[21:08:31 CEST] <ubitux> install -m 644 Makefile.example /foo/bar/Makefile
[21:08:55 CEST] <JEEB> oh fun, clang 5.0.x doesn't like our vorbis encoder :) I think this crashes is the second time http://up-cat.net/p/30903c31
[21:09:18 CEST] <JEEB> (it does the compile when I retry)
[21:09:23 CEST] <ubitux> (what's this assistcontrol? a bot?)
[21:09:37 CEST] <ubitux> JEEB: no warning?
[21:10:16 CEST] <jamrial> ubitux: ok
[21:14:43 CEST] <cone-095> ffmpeg 03James Almer 07master:72da8491ca05: build: don't call install with the -T option
[21:29:58 CEST] <feliwir> why could avcodec_decode_audio4 possibly crash?
[21:42:46 CEST] <jamrial> does it make sense for the examples to use PROGSSUF?
[21:43:40 CEST] <wm4> like .exe?
[21:44:40 CEST] <jamrial> no, suffix for the name, not a system dependant extension
[21:44:45 CEST] <jamrial> that's EXESUF
[21:45:15 CEST] <wm4> ah
[21:45:18 CEST] <jamrial> it was added for ffmpeg and such. no idea why the examples would need it
[21:45:58 CEST] <wm4> what can it be set to and what's the use case?
[21:46:47 CEST] <jamrial>  /usr/local/bin/ffmpeg-3.2, with /usr/local/bin/ffmpeg being 3.3
[21:47:04 CEST] <wm4> ok I have no idea why that would exist
[21:47:20 CEST] <jamrial> more than one installation of both the libraries and CLI
[21:47:55 CEST] <wm4> so, no opinion whether it makes sense for the examples
[21:48:21 CEST] <jamrial> downstream projects use library suffix for the libraries, like nevcairiel's LAVFilters
[21:48:28 CEST] <jamrial> prog suffix i assume is mainly for distro packagers
[21:53:10 CEST] <feliwir> hell, even av_send_packet crashes now. I thought that new fancy api would be more stable -.-
[21:53:44 CEST] <feliwir> https://github.com/feliwir/arda/blob/master/src/audio/audiostream.cpp#L264 (crashes in the 3rd iteration)
[21:54:38 CEST] <feliwir> can't i call av_read_frame as many times as i'd like?
[21:56:11 CEST] <nevcairiel> you dont seem to free any of the packets or frames you get
[21:56:15 CEST] <nevcairiel> probably running out of memory
[21:56:57 CEST] <feliwir> nevcairiel, i am decoding audio, and av_send_packet crashes in the 2nd iteration
[21:57:00 CEST] <feliwir> i am good on memory
[21:58:49 CEST] <nevcairiel> you also dont initialize the packet at all, should really do that
[22:00:42 CEST] <BBB> nevcairiel: I understand your point, my personal opinion is that regardless of effort (hardly any), if the gain is exactly 0.0, then its never worth it :-p
[22:00:58 CEST] <nevcairiel> well just dont break the ABI in any case?
[22:01:23 CEST] <BBB> I agree with that part (so if vda.c was there, the ABI should remain, even if it becomes dysfunctional and always returns error codes)
[22:01:24 CEST] <nevcairiel> if i build something today and build something tomorrow with the exact same configure command, and the ABI changes, thats a break
[22:01:30 CEST] <BBB> yes, I agree
[22:01:36 CEST] <BBB> Im not arguing against that
[22:01:41 CEST] <BBB> I 100% agree
[22:01:59 CEST] <BBB> just dont think its worth including vda.o abi on non-mac systems tomorrow since they werent there today
[22:02:01 CEST] <feliwir> nevcairiel, it's not a pointer so what would i need to initialize?
[22:02:05 CEST] <BBB> I agree its broken, but who cares
[22:02:22 CEST] <nevcairiel> the dummy things in vda may never have worked, but vda itself did and was autodetected (ie. always on), so these functions were in a default build, and need to remain in that
[22:03:01 CEST] <BBB> always on *on mac* :-p and so should remain on *on mac*, yes
[22:03:23 CEST] <nevcairiel> i dont care if its mac only or always, mac only seems more work and people dont seem to want mroe work =p
[22:03:30 CEST] <BBB> my understanding was that the question was whether the symbols should start to exist on linux builds. they should be in theory, but I dont think its worth it to do effort for that
[22:03:39 CEST] <BBB> ok, I guess we agree then ;)
[22:04:34 CEST] <jamrial> nevcairiel: hey, i just had to deal with a mac only stupid thing :p
[22:05:18 CEST] <feliwir> nevcairiel, what you meant by i don't initialize the packet? :(
[22:06:03 CEST] <jamrial> feliwir: you're not initializing it with av_init_packet()
[22:06:46 CEST] <nevcairiel> also, for future stability, dont use AVPacket on the stack, instead make it a pointer and use av_packet_alloc() which does the init for you
[22:08:31 CEST] <wm4> does anyone think this mac ABI thing is worth anything
[22:08:40 CEST] <wm4> like, your time, or the effort of discussion
[22:13:25 CEST] <cone-095> ffmpeg 03Diego Biurrun 07master:ab566cc96bc0: build: Separate logic for building examples from that for building avtools
[22:13:25 CEST] <cone-095> ffmpeg 03James Almer 07master:eace20a8623d: Merge commit 'ab566cc96bc0c31b34d944214bc06cec8ae8b640'
[22:20:26 CEST] <feliwir> ok, thanks nevcairiel 
[22:24:43 CEST] <feliwir> maybe also an idea what is making swr_convert crash here: https://github.com/feliwir/arda/blob/master/src/audio/audiostream.cpp#L285 ?
[22:33:40 CEST] <atomnuker> use swr_convert_frame()
[22:57:12 CEST] <cone-095> ffmpeg 03James Almer 07master:3df437c2d195: build: add missing changes to ensure examples build with progs-suffix
[23:05:29 CEST] <feliwir> did anyone take a look at my swr_convert issue?
[23:06:58 CEST] <Compn> more people are on the mailing list than are here :)
[23:07:00 CEST] Action: Compn runs afk
[23:08:57 CEST] <jamrial> feliwir: atomnuker made a comment. and this is not the channel to ask for help using the libraries
[23:09:35 CEST] <feliwir> jamrial, which one is it then? In #ffmpeg they tell me to go to #ffmpeg-devel
[23:09:45 CEST] <jamrial> they are wrong
[23:09:57 CEST] <jamrial> this channel is for development of ffmpeg, not with ffmpeg
[23:10:03 CEST] <jamrial> it's #ffmpeg, or https://lists.ffmpeg.org/mailman/listinfo/libav-user/
[23:10:33 CEST] <feliwir> i didn't get a single message from atomnunker
[23:11:04 CEST] <feliwir> but i'll ask in #ffmpeg then, thanks
[23:11:07 CEST] <jamrial> [17:33:41] <@atomnuker> use swr_convert_frame()
[23:12:07 CEST] <feliwir> wow, nice
[23:34:56 CEST] <JEEB> michaelni: do you have any recollection on why you set the sample[i+1].dts - sample[i].dts "duration" checks at INT_MAX instead of UINT32_MAX? (first in 2014 for assert0 and then in 2016 for the "j00ru" sample)
[23:35:26 CEST] <JEEB> because sample_default_duration is uint32 and then stts is uint32 for sample_delta
[23:36:00 CEST] <JEEB> ctts DTS-to-CTS offset can be either uint32 (v0) or int32 (v1)
[00:00:00 CEST] --- Sat Sep 30 2017

More information about the Ffmpeg-devel-irc mailing list