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

[burek]

[01:31:13 CEST] <atomnuker> BBB: about the vf_colorspace patch, is there really a need to use srgb and have iec61966-2.1 as an alias
[01:42:39 CEST] <BBB> Im not 100% sure
[01:43:05 CEST] <BBB> I dont think I have much of an opinion on aliases, I think theyre ok, they help people that are not intimately familiar with how this stuff work and make it sound a little bit easier
[02:03:44 CEST] <cone-535> ffmpeg 03Tobias Rapp 07master:e3196b686233: avformat/mxfdec: Detect field_order based on video_line_map
[02:14:15 CEST] <Zeranoe> Should the default/recommended FFmpeg build for Windows be the git version or the release versions? With the redesign the releases were set as the default.
[02:15:07 CEST] <iive> atomnuker: look at it from a different angle, iec61966-2.1 is the proper name and srgb is the alias
[02:15:20 CEST] <iive> i'd say aliases are ok.
[02:26:00 CEST] <llogan> Zeranoe: git
[02:26:38 CEST] <llogan> redesign look snice
[02:31:55 CEST] <jamrial> llogan: should it really? we're talking about windows binaries. the kind people download once and will use till the end of time, or until whatever they want to do can't be done with it
[02:32:28 CEST] <llogan> i'm tired of telling windows users to use the git version for x new feature
[02:35:33 CEST] <jamrial> llogan: you're aware that until now Zeranoe's page offered nightly git builds by default, right?
[02:35:48 CEST] <jamrial> people will not stop making questions where the reply is "get a newer version"
[02:39:42 CEST] <jamrial> by offering a stable release as recommended and nightlies as "bleeding edge, can be unstable", there will be less chances for people downloading a highly unstable build thinking it was a perfectly functional one, and sticking with it for who knows how long
[02:41:04 CEST] <llogan> yes, i am aware.
[02:41:42 CEST] <llogan> i disagree that they are [generally] highly unstable
[02:41:54 CEST] <llogan> we usually recommend general users to use git
[02:43:24 CEST] <jamrial> i didn't say they are generally highly unstable. i said there's a chance they may be
[02:44:02 CEST] <llogan> and there's a chance that an encountered bug in a release version is fixed in git
[02:44:41 CEST] <llogan> in the time that the site has had the new design i had to tell at least one user to use the git version, not the release version
[02:47:30 CEST] <jamrial> that for example wouldn't have happened if 3.2 hadn't been delayed, but that's just as anecdotic
[02:47:35 CEST] <jamrial> with a release every three months new features make it to stable releases pretty fast
[02:48:27 CEST] <jamrial> maybe a note saying "if something is missing from the release version, try a nightly build" or something like that could help in this regard
[02:48:49 CEST] <llogan> if people come asking for help and just downloaded a release they are often going to be told to use git version. if they report a bug they *will* be told to use git version.
[02:49:33 CEST] <llogan> yes, a note mentioning the differences would be helpful
[02:59:23 CEST] <Zeranoe> So to summarize: Switch to the git builds and add a tooltip to the release toggle with something like "Note that the git builds are generally considered more stable and are the only officially supported version." The tooltips I'm referring to can be seen when hovering over the linking types.
[03:17:39 CEST] <Zeranoe> The tooltip will read "Release versions of FFmpeg generally contain more bugs, less features, and are not supported on the bug tracker or mailing list." Hopefully that works for everyone.
[03:33:14 CEST] <llogan> Zeranoe: for git tooltip maybe something like: "Recommended for general users. More features, bleeding-edge but usually stable, required version if reporting bugs." and release: "Recommended for distributors and others who require a stable release version".
[03:42:38 CEST] <Compn> when something breaks its nice to see a bug report from a git nightly build user anyway
[03:53:28 CEST] <Zeranoe> So is the git version or the release version more stable?
[04:03:11 CEST] <Zeranoe> The wording is now "Nightly git builds contain more features, are usually stable, and are the required version for submitting bugs." and "Release builds are recommended for distributors, but cannot be used when submitting bugs."
[04:03:32 CEST] <llogan> release is more "stable". git will have more bug fixes that may be missing in release, but git may have bugs not in release. release versions within the same release branch will not have backward incomaptible API changes and no major new features.
[04:05:34 CEST] <llogan> got to go.
[04:10:34 CEST] <cone-535> ffmpeg 03Mark Reid 07master:3b82be9e3b7e: libavformat/mxfdec: export track name metadata
[04:10:35 CEST] <cone-535> ffmpeg 03Mark Reid 07master:263f8fd7e5c1: libavformat/mxfdec: don't assume first stream index to be primary
[04:10:36 CEST] <cone-535> ffmpeg 03Mark Reid 07master:6902e1c7fab3: libavformat/mxfdec: add metadata streams for external referenced sourclips
[04:10:37 CEST] <cone-535> ffmpeg 03Mark Reid 07master:0cfd6ccedeaa: tests/fate: add mxf metadata streams test
[06:15:44 CEST] <cone-535> ffmpeg 03Matt Oliver 07master:798c6ecce50f: openssl: Support version 1.1.0.
[06:16:57 CEST] <Matador> Zeranoe: Hello there
[06:17:57 CEST] <Zeranoe> Matador: Hi
[06:37:14 CEST] <Matador> Zeranoe : nice to see you around here
[06:37:34 CEST] <Matador> Zeranoe : I've used those builds and recommended others also
[06:37:48 CEST] <Zeranoe> Matador: Thank you for the kind words
[06:38:05 CEST] <Matador> I hope you saw on forum, about qsv/mfx issue :|
[06:38:43 CEST] <Matador> I even tried compiling ffmpeg myself on Ubuntu, what a PITA.. but still qsv/libmfx broken on latest git... really sad gotta use a April edition :|
[06:40:35 CEST] <Zeranoe> Matador: Which post are you referring to?
[06:41:27 CEST] <Matador> https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=4360
[06:41:58 CEST] <Matador> I just noticed another -- https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=4171
[06:42:14 CEST] <Matador> Let me know how much $$ donation you'd like to work on a fix ? :)
[06:44:26 CEST] <Matador> there is another titled -- ffplay crashes with h264_qsv codec (Intel QuickSync/QSV)
[06:44:45 CEST] <Zeranoe> Matador: This is a very complex issue. See https://trac.ffmpeg.org/ticket/4832
[06:45:37 CEST] <Matador> ya no doubt
[06:47:21 CEST] <Matador> Let me know if money will help get a few coders on this full time, I'm willing to put up a bounty here :)
[06:53:10 CEST] <Zeranoe> Matador: Do you have a machine to test with? I have trouble reliably reproducing it on my 4790K?
[08:07:53 CEST] <rcombs> oh man I forgot I pushed that termios fix
[08:08:03 CEST] <rcombs> `make -j<x> fate` doesn't break my terminal anymore
[08:08:08 CEST] <rcombs> I am the happiest person
[08:56:23 CEST] <cone-535> ffmpeg 03Rodger Combs 07master:ecb53e11014b: lavf/segment: decide whether to rename based on list URI
[14:19:45 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:6c5b98d40b8e: avcodec/dnxhdenc: Move allocation out of radix_sort()
[14:19:45 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:4f96f9d1118e: avcodec/utils: Clear MMX state before returning from avcodec_default_execute*()
[14:19:45 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:03ec6b780cfa: avcodec/mpegvideo_enc: Clear mmx state in ff_mpv_reallocate_putbitbuffer()
[14:57:33 CEST] <jkqxz> jamrial: nevcairiel:  Has anyone started on the suggested libmfx replacement from libav?
[14:57:46 CEST] <nevcairiel> not to my knowledge
[15:00:38 CEST] <jkqxz> Ok, I will start on it then.  I don't imagine it will be overly complex, but I wouldn't want to duplicate anything someone else has already done.
[15:04:39 CEST] <ubitux> is anyone aware of ffmpeg muxed mp3 with "random" durations reported in various players?
[15:05:12 CEST] <ubitux> i have someone reporting me that vlc at playback time reports a wrong duration (fixed at playback)
[15:05:15 CEST] <ubitux> just like quicktime
[15:05:27 CEST] <BtbN> Isn't that just what happens with VBR mp3?
[15:05:38 CEST] <ubitux> maybe; what's the explanation here?
[15:05:51 CEST] <ubitux> i'm assuming the wrong one is due to a bitrate estimation
[15:05:59 CEST] <BtbN> I think plain mp3 simply has no information about its length
[15:06:04 CEST] <BtbN> So it's calculated from size and bitrate
[15:06:10 CEST] <BtbN> which obviously fails for vbr
[15:06:10 CEST] <ubitux> because a generated sine of the same duration leads to a different "random" duration 
[15:06:46 CEST] <ubitux> how is the correct duration computed?
[15:06:50 CEST] <BtbN> putting mp3 in some container.
[15:07:01 CEST] <BtbN> by decoding the entire file I guess
[15:07:13 CEST] <ubitux> ffprobe reports the correct duration
[15:07:22 CEST] <ubitux> i'm pretty sure it's not decoding everything
[15:08:32 CEST] <BtbN> where even is the mp3 decoder? In which file in avcodec, that is
[15:09:12 CEST] <ubitux> mpegaudio*.c?
[15:09:16 CEST] <BtbN> mpegaudio_parser.c it seems
[15:09:18 CEST] <nevcairiel> raw mp3 files have headers for vbr info
[15:09:32 CEST] <nevcairiel> not sure if avformat writes that
[15:09:35 CEST] <nevcairiel> but it probably should
[15:09:53 CEST] <jamrial> mpegaudiodec_{float,fixed,template}
[15:10:20 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mp3enc.c#L513
[15:12:37 CEST] <ubitux> basically this file `ffmpeg -f lavfi -i sine -t 4:38 out.mp3` is reported as 5:17 in playback in vlc and 4:38 in pause
[15:12:46 CEST] <ubitux> (and reported as 5:18 in quicktime)
[15:13:17 CEST] <ubitux> ffprobe reports as 4:38
[15:13:29 CEST] <nevcairiel> maybe vlc doesnt read the xing tag
[15:13:35 CEST] <nevcairiel> (quicktime most probably does not)
[15:13:59 CEST] <ubitux> you mean vlc doesn't read it at playback
[15:14:11 CEST] <ubitux> but just in playlist/pause mode?
[15:14:16 CEST] <BtbN> it also seems to be somehow tied to mp3->pics_to_write
[15:14:29 CEST] <BtbN> which is set to s->nb_streams - 1
[15:14:47 CEST] <BtbN> the xing tag is only written if it's 0, so if there is exactly one stream
[15:14:55 CEST] <BtbN> which makes sense I guess?
[15:15:12 CEST] <nevcairiel> well if vlc is inconsistent in two modes, i would look for an explanation at vlc
[15:15:42 CEST] <jamrial> BtbN: depends, can't xing be written if id3v2 has a cover image?
[15:16:14 CEST] <BtbN> no ides if it can't. But it isn't.
[15:16:30 CEST] <nevcairiel> BtbN: it is, just later
[15:16:32 CEST] <nevcairiel> after the images
[15:16:51 CEST] <nevcairiel> mp3_queue_flush writes the xing tag
[15:16:56 CEST] <nevcairiel> which is called after the images are done writing
[15:19:44 CEST] <nevcairiel> because the id3v2 tag with the images has to be the first thign in the file
[15:37:03 CEST] <BtbN> Yeah, what ffmpeg writes looks fine to me.
[15:37:15 CEST] <BtbN> So I'd blame what VLC reads, or rather doesn't read.
[15:44:00 CEST] <BBB> michaelni: your patch series does exactly what scares me so much, it adds emms_c() in all kind of places which are practically untestable on a non-musl setup
[15:44:56 CEST] <BBB> michaelni: I thought all these encoders used mpegenc, cant we add the emms_c() in a general location inside mpegenc so its generalized in a single location where at least its shared?
[15:47:14 CEST] <Chloe> what does emms_c() do for non 32bit x86?
[15:59:04 CEST] <BBB> Im not sure theres a guarantee that were not using x87 fpu on 64bit, so although you typically dont need it, I think it still calls emms on 64bit
[15:59:13 CEST] <BBB> (you could have hand-written assembly or a silly compiler)
[15:59:22 CEST] <BBB> (x87fpu assembly, I mean)
[16:01:14 CEST] <Chloe> right ok, if there are cases where x87 may still be used then I guess it's just best to do it unconditionally.
[16:04:10 CEST] <michaelni> BBB, i didnt use musl to test or find these
[16:04:24 CEST] <BBB> right, you used your asserts
[16:04:33 CEST] <BBB> but that doesnt change the fact that theres emms_c sprinkled all over :)
[16:05:08 CEST] <BBB> nor that it only covers memory allocation functions, not all libc functionality
[16:05:17 CEST] <BBB> but lets ignore that second one for now
[16:05:27 CEST] <BBB> sicne musls only concern is memory allocation functions
[16:06:05 CEST] <michaelni> also these get triggered on x86-64 with cpuflags all you dont need to force mmx
[16:08:34 CEST] <michaelni> "<BBB> michaelni: I thought all these encoders used mpegenc, cant we add the emms_c() in a general location inside mpegenc so its generalized in a single location where at least its shared?  <-- not that i see, the code directly calls all kinds of SIMD and ref/unref stuff
[16:09:23 CEST] <BBB> hm& ok
[16:09:28 CEST] <BBB> that kinda sucks, but what can you do, right?
[16:53:10 CEST] <cone-212> ffmpeg 03Hiroyuki OYAMA 07master:47f74df29cb1: avformat/rtmpproto: Fix RTMP control message handling error in listen mode.
[17:11:26 CEST] <cone-212> ffmpeg 03Steven Liu 07master:4d92bd3ca225: avcodec/vda: define av_vda_default_init2 when CONFIG_H264_VDA_HWACCEL equ 0
[17:30:49 CEST] <Zeranoe> jkqxz: What libmfx replacement are you referring to?
[17:33:03 CEST] <jkqxz> Replace the libmfx implementation in ffmpeg with the one in libav, because it works and is incompletely awful.
[17:33:25 CEST] <RiCON> Zeranoe: this patch fixes those relocation errors you were getting with gcc 6.x: https://raw.githubusercontent.com/Alexpux/MINGW-packages/master/mingw-w64-gcc/0016-disable-weak-refs-in-libstdc%2B%2B.patch
[17:33:48 CEST] <jkqxz> Also because the current one is blocking further merges.
[17:34:23 CEST] <Zeranoe> jkqxz: Any timeframe for that? I'm curious if that will resolve some issues I've been seening
[17:35:07 CEST] <jkqxz> I am trying to do it now.
[17:35:42 CEST] <jkqxz> Later today for an initial patch, maybe?  It probably won't be complete at that point.
[17:35:43 CEST] <Zeranoe> RiCON: Interesting
[17:38:12 CEST] <jkqxz> I have working encode or decode separately so far, and I've tried to preserve current functionality - all except A53 CC (which seems to currently be broken anyway) look fine.
[17:38:16 CEST] <Zeranoe> RiCON: It looks like it hasn't made it into git yet. https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libstdc%2B%2B-v3/config/os/mingw32-w64/os_defines.h;hb=HEAD
[17:39:02 CEST] <RiCON> i don't know if it's actually a gcc issue nor do I know if anyone forwarded the patch to gcc
[17:39:54 CEST] <RiCON> it was just something i tried a few months ago based on a similar commit for the cygwin part
[17:43:05 CEST] <Zeranoe> RiCON: Do you know if it's x86_64 specific or could something like CFLAGS="-U_GLIBCXX_USE_WEAK_REF" be used?
[17:43:13 CEST] <RiCON> it's x86_64 specific
[17:43:47 CEST] <RiCON> i never tried with a specific CFLAG
[17:46:37 CEST] <RiCON> either way, it's not a FFmpeg issue nor with any lib in particular, it's with gcc and/or static libstdc++
[17:47:22 CEST] <RiCON> c++ libs that don't use exceptions also work without it, like x265
[17:47:26 CEST] <Zeranoe> RiCON: I appreciate the info
[19:42:45 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:93c39db5f154: aiff: check block_align in aiff_read_packet
[19:42:46 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:b0a043f51b8c: dcstr: fix division by zero
[19:42:47 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:1966ea012fd7: cavsdec: unref frame before referencing again
[19:42:48 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:a92f8edf0c51: mpeg12dec: unref discarded picture from extradata
[20:18:07 CEST] <jkqxz> Zeranoe:  On ML.  Testing on Windows would be welcomed :)
[20:18:42 CEST] <Zeranoe> jkqxz: Do you have a repo/branch set up?
[20:19:10 CEST] <JEEB> if you are lazy to grab patches from the ML, check the patchwork
[20:19:21 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/1104/
[20:19:21 CEST] <JEEB> you can get a file you can then git am into your repo from that one as well
[20:22:43 CEST] <Zeranoe> jkqxz: Have you seen this? https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195544.html
[20:23:43 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:c495f4ffde1e: avformat/mxfdec: Fix mixed declaration and code
[20:23:44 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:fecb3e82a4ba: avformat/mxfdec: Check size to avoid integer overflow in mxf_read_utf16_string()
[20:24:52 CEST] <ubitux> jkqxz: oh nice, thanks!
[20:25:47 CEST] <cone-212> ffmpeg 03Marton Balint 07master:2f3015c25aae: lavd/decklink_dec: add option to disable drawing bars on signal loss
[20:25:48 CEST] <cone-212> ffmpeg 03Marton Balint 07master:dfc561a38e94: lavd/decklink_dec: fix indentation
[20:31:45 CEST] <jkqxz> Zeranoe:  I had not seen that.  Urgh, is it really a dependency on the processor rather than the API version?
[20:31:57 CEST] <Zeranoe> As far as I can see the CO3 options are defined but aren't actually being set
[20:32:11 CEST] <Zeranoe> jkqxz: It appears so. I'm unable to even use QSV due to those
[20:32:28 CEST] <nevcairiel> the whole qsv thing should have runtime feature selection, not compile time
[20:32:32 CEST] <nevcairiel> but noone bothered to build that
[20:32:41 CEST] <Zeranoe> I agree
[20:33:27 CEST] <jkqxz> You aren't accidentally building against newer headers (such as those in mfx_dispatch) than the libfx you actually run with?
[20:33:31 CEST] <Zeranoe> jkqxz: I would see a reason to keep those CO3 options, but as I said they aren't even being used from what I've seen
[20:33:32 CEST] <jkqxz> *libmfx
[20:34:05 CEST] <Zeranoe> jkqxz: I don't use mfx_dispatch and build the latest version myself. That version is also being used on the machine.
[20:34:07 CEST] <nevcairiel> its also really not worth caryng about, qsv is just broken as f' even when its implemented properly, the drivers still randomly stall and give you endless busy signals
[20:34:32 CEST] <nevcairiel> caring*
[20:35:36 CEST] <Zeranoe> nevcairiel: Only with FFmpeg from what I've tested. Intel provides a "sample encoder" that does not hang with the same input, and it's implemented very similarly. That's while stressing the CPU while encoding (normally causes the hang)
[20:35:58 CEST] <nevcairiel> i got all sorts of random tools to freeze up the same way
[20:36:16 CEST] <nevcairiel> and various reports of that on intels forum
[20:36:32 CEST] <BtbN> OBS put the QSV encoder in a seperate process and just kills it and restarts it if it doesn't respond anymore...
[20:36:45 CEST] <Zeranoe> Wow.... That's bad
[20:37:22 CEST] <nevcairiel> and last I checked the "official" linux libmfx doesnt even interface with the hardware properly so it doesnt provide a hardware device for you
[20:37:30 CEST] <nevcairiel> hence the hacky code in ffmpeg that queried the dev nodes
[20:37:52 CEST] <nevcairiel> lucas fork of it has that added into it however, and libav probably only ever cared to work with that
[20:37:59 CEST] <Zeranoe> Apparently Libav's implementation is better though?
[20:40:39 CEST] <jkqxz> The hwcontext layer hides that nastiness in libav.  You build with either DXVA2 or VAAPI and it uses the hwcontext for that to make the device.
[20:43:25 CEST] <jkqxz> (In current ffmpeg, using encode and decode separately at the same time on Linux without X is broken - it segfaults in libmfx because the first open makes itself the DRM master on the card, and then the second dies horribly.  Amusingly, linking card0 to renderD128 makes it work.)
[20:47:56 CEST] <jkqxz> Zeranoe:  I guess that change makes sense given what you've said.  Do you test on anything older as well?
[20:48:58 CEST] <Zeranoe> jkqxz: There are numerous reports of the same issue on my forum with similar hardware.
[20:49:31 CEST] <Zeranoe> jkqxz: Though I haven't tested the fix on other hardware than mine.
[21:03:12 CEST] <cone-212> ffmpeg 03Carlos Fernandez 07master:d53a120ad63f: lavc: add SCTE-35 CUI codec ID
[21:03:13 CEST] <cone-212> ffmpeg 03Carlos Fernandez 07master:5db3c9476c79: lavf/mpegts: SCTE-35 extraction from mpegts
[21:15:22 CEST] <jamrial> i thought people in general were against this scte-35 patchset
[21:15:50 CEST] <JEEB> oh wait, it went into lavc? funky
[21:15:51 CEST] <Chloe> yes
[21:15:59 CEST] <JEEB> I thought it was a container concept
[21:16:22 CEST] <jamrial> or rather, some people against, others just neutral, but nobody except the submiter actually in favor
[21:17:48 CEST] <Chloe> wm4 was against it, I felt that it could have been done differently. There were still some outstanding issues, which were never solved. But it's not like anything is going to stop random stuff being commited
[21:17:52 CEST] <Matador> Cant wait for a QSV fix
[21:19:59 CEST] <BtbN> Well, complain to Intel
[21:20:06 CEST] <BtbN> Nobody else can fix it.
[21:24:46 CEST] <Zeranoe> What if I told you Intel thinks it's our fault....
[21:27:00 CEST] <BtbN> That their stuff fails in essentialy every application using it? Yeah sure
[21:27:45 CEST] <Zeranoe> Sometimes it's easier to blame the other guy
[21:28:17 CEST] <BtbN> Intel Software development has gone downhill the last few years
[21:28:21 CEST] <BtbN> specially the open source stuff
[21:28:27 CEST] <BtbN> but QSV is especially bad
[21:58:01 CEST] <CFS-MP3> jamrial don't know... I'm getting some feedback about the SCTE-35 stuff, so there's definitely some interesting other than my personal one 
[21:58:29 CEST] <CFS-MP3> Never understood the being against supporting an industry standard anyway
[21:58:51 CEST] <JEEB> I don't think anyone here is against implementing SCTE-35 in FFmpeg
[21:59:01 CEST] <Chloe> It's not that, it's how it's implemented, and how it fits (or rather, doesn't fit) into ffmpeg.
[21:59:36 CEST] <CFS-MP3> Chloe do you mean my specific implementation or the way SCTE-35 fits in the MPEG-TS?
[22:00:01 CEST] <CFS-MP3> If it's my implementation I'm happy to discuss it, if it's the specification not much we can do I guess except deal with it as well as we can
[22:00:32 CEST] <Chloe> I think there were issues with both. Particularly regarding the timestamps, what was done about that in the end?
[22:01:26 CEST] <CFS-MP3> What needed to be done that wasn't done? Timestamps in cues are relative to the PCR... what's the specific problem with it?
[22:03:26 CEST] <Chloe> How does it work with the AVPacket timestamps?
[22:03:51 CEST] <Chloe> Actually don't bother. It doesn't even matter anymore.
[22:19:16 CEST] <tmm1> is there a way to tell ffmpeg/ffplay to use a specific decoder
[22:19:38 CEST] <BtbN> -c
[22:21:13 CEST] <tmm1> ah right, as an input option
[22:21:19 CEST] <tmm1> works for ffmpeg but not ffplay
[22:21:44 CEST] <tmm1> n/m got it, thanks
[23:59:55 CEST] <cone-212> ffmpeg 03Andreas Cadhalpun 07master:c8a6eb58d7eb: doc: fix spelling errors
[00:00:00 CEST] --- Sat Oct 22 2016