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

Sat May 20 03:05:03 EEST 2017

[00:13:23 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vHeyL
[00:13:23 CEST] <KGB> 13FFV1/06master 14ef51962 15Dave Rice: describe use of len in pseudo-code...
[00:35:54 CEST] <jkqxz> Um, what?  Who has a posix_memalign() which doesn't work for that?
[00:56:44 CEST] <cone-357> ffmpeg 03James Almer 07master:1e8daf31e079: avcodec/hevc_parser: add missing call to ff_hevc_reset_sei()
[00:58:14 CEST] <jamrial> that fifo-muxer-tst test is failing randomly on every fate instance running with more than one thread
[10:51:30 CEST] <ubitux> > The null demuxer does not have a backing AVIOContext.
[10:51:35 CEST] <ubitux> what does this refer to?
[10:51:42 CEST] <ubitux> is it a typo for "null muxer"?
[10:51:53 CEST] <ubitux> i see no such thing as a null demuxer
[10:53:04 CEST] <ubitux> (refering to 44129e380)
[10:53:42 CEST] <ubitux> the diff looks related to an output so i'll assume it's the null muxer
[10:59:16 CEST] <wm4> yeah, must be a muxer
[10:59:41 CEST] <cone-280> ffmpeg 03Luca Barbato 07master:44129e38047b: avconv: Do not pass NULL to avio_tell
[10:59:42 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:313264ba2494: Merge commit '44129e38047b6a27291e487c2084894958c6f399'
[11:01:15 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:a895292f2734: mov: Convert to the new bitstream reader
[11:01:16 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:b1e7394ea042: rtp: Convert to the new bitstream reader
[11:01:17 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:4795e4f61f99: alac: Convert to the new bitstream reader
[11:01:18 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:aec4812cb3b3: Merge commit '4795e4f61f993940c5384044caff56cc15078698'
[11:02:49 CEST] <ubitux> who is responsible of the cuda code?
[11:02:58 CEST] <ubitux> next commit is related to nvenc (fb59f87ce72035b940c3f5045884098b9324e1b2)
[11:03:00 CEST] <wm4> BtbN or philipl 
[11:03:25 CEST] <ubitux> it looks like we already handle that symbol but we don't use it
[11:03:37 CEST] <wm4> I bet we fixed that ourselves
[11:03:39 CEST] <BtbN> we use it a lot
[11:04:04 CEST] <ubitux> ah?
[11:04:09 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=be74ba648cf4063c9805ebe95ee83fd7299f7fd5
[11:04:13 CEST] <ubitux> i may not be grepping the proper symbol
[11:04:25 CEST] <BtbN> Seems to be the exact same commit I made myself
[11:04:35 CEST] <ubitux> oh
[11:04:39 CEST] <ubitux> it's because of "v2"
[11:05:00 CEST] <ubitux> any reason why it's not using v2?
[11:05:04 CEST] <BtbN> We are
[11:05:12 CEST] <BtbN> We already have that commit, so it's a noop
[11:05:16 CEST] <ubitux> ah
[11:05:18 CEST] <ubitux> ok ok
[11:05:25 CEST] <ubitux> do you have a hash to refer to?
[11:05:27 CEST] <BtbN> Well, not that commit, but I made the exact same change myself.
[11:05:31 CEST] <BtbN> The one I just linked
[11:05:50 CEST] <ubitux> ok
[11:05:52 CEST] <ubitux> thank you
[11:06:14 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/cuda/dynlink_loader.h;h=33f23af1e2069628a357e38316b316ba197ccb94;hb=be74ba648cf4063c9805ebe95ee83fd7299f7fd5#l187
[11:06:22 CEST] <BtbN> <- _v2 right there
[11:06:45 CEST] <ubitux> i see
[11:06:48 CEST] <ubitux> great, thanks!
[11:07:29 CEST] <cone-280> ffmpeg 03Luca Barbato 07master:fb59f87ce720: nvenc: Explicitly push the cuda context on encoding
[11:07:30 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:917853661f95: Merge commit 'fb59f87ce72035b940c3f5045884098b9324e1b2'
[11:08:16 CEST] <BtbN> I'm surprised libav didn't even have the PushCtx symbol before that
[11:08:22 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:54dcd2288546: als: Convert to the new bitstream reader
[11:08:23 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:545d14f06733: Merge commit '54dcd2288546e135986338107ea87db1fcedd633'
[11:09:51 CEST] <cone-280> ffmpeg 03Derek Buitenhuis 07master:00b775dda2b3: hevc: Mark as having threadsafe init
[11:09:52 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:426f5e66a6cb: Merge commit '00b775dda2b3f78ae60ff3278d3b3d6545883a83'
[11:15:02 CEST] <cone-280> ffmpeg 03Anton Khirnov 07master:296eff4d9dc5: zmbvenc: get rid of a global table
[11:15:03 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:52a4004d8b5f: Merge commit '296eff4d9dc53d441b672319524a051d04f4a8cf'
[11:18:41 CEST] <cone-280> ffmpeg 03Anton Khirnov 07master:b4a911c18996: mpegvideoenc: make a table const
[11:18:42 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:19bb2cade5c8: Merge commit 'b4a911c189962e563a09fb0efaf6fa9ab56263a4'
[11:18:43 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:584366a43657: lavc/mpegvideoenc: reformat inv_zigzag_direct16 so the zigzag pattern is visible
[11:20:17 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:4d49a4c55054: apedec: Convert to the new bitstream reader
[11:20:19 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:fd8de7f2d8c3: dxtory: Convert to the new bitstream reader
[11:20:19 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:e5630ce5b122: Merge commit 'fd8de7f2d8c31195d309247cb129c0ad787ef76e'
[11:22:13 CEST] <cone-280> ffmpeg 03Dave Yeo 07master:7ff018c1cb43: OS/2: Try to commit memory above 1GB
[11:22:14 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:42ed79a2294c: Merge commit '7ff018c1cb43a5fe5ee2049d325cdd785852067a'
[11:23:30 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:5c0e2b13eb79: swscale-test: const correctness for pointer variable
[11:23:31 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:5d986609ba47: Merge commit '5c0e2b13eb79b455b15355d64f7993b0f66ea9ec'
[11:24:57 CEST] <nevcairiel> BtbN: do you have any idea whats this v2 stuff is about anyway? did they slightly change the signature at some point?
[11:26:13 CEST] <BtbN> As they just #define the function name to the v2 on in the official headers, at least the signatur is identical
[11:26:23 CEST] <BtbN> I'd guess they changed some behaviour in an incompatible way
[11:28:51 CEST] <nevcairiel> some things in the headers change type defs based on __CUDA_API_VERSION defines, but that seems to be mostly about CUdeviceptr
[11:29:53 CEST] <nevcairiel> (which they made 64-bit on 64-bit systems, previously it was 32-bit everywhere, probably an oversight in early API development)
[11:31:06 CEST] <BtbN> Yeah, might actually be about the devptr size
[11:31:50 CEST] <BtbN> At least the first batch of _v2 within __CUDA_API_VERSION >= 3020
[11:31:58 CEST] <BtbN> are all memory management functions
[11:32:07 CEST] <BtbN> alloc/free/copy/array/tex
[11:51:59 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:b83aea73404f: des-test: Pass the proper types to av_des_*() functions
[11:52:00 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:6a3538bb233e: Merge commit 'b83aea73404f6f9314e72fe5d6238deaffa12b2c'
[11:53:39 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:6668bc80b5ee: mpc: Convert to the new bitstream reader
[11:53:40 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:e7f24c9ffc6a: wavpack: Convert to the new bitstream reader
[11:53:41 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:b061f298f7f2: truemotion2rt: Convert to the new bitstream reader
[11:53:42 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:2e0e150144d6: magicyuv: Convert to the new bitstream reader
[11:53:43 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:381a4e31a6b8: tak: Convert to the new bitstream reader
[11:53:44 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:89d277af00f5: Merge commit '381a4e31a6b801a046e38b0e2b08fb61499157a7'
[11:58:09 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:bf38959a30ec: configure: Move optflags checks to a more sensible place
[11:58:10 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:f78f3df7e01c: Merge commit 'bf38959a30ecba4e4ee95d4f2a80ba7ece4f34be'
[12:00:47 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:9bf262f4c6e1: configure: Use proper compiler-specific speed flags for hostcc
[12:00:48 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:2fbeb42df358: Merge commit '9bf262f4c6e14f43f291cdb745ed372884ee2a7f'
[12:01:36 CEST] <cone-280> ffmpeg 03Luca Barbato 07master:562ef82d6a7f: fifo: Return the correct AVERROR value
[12:01:37 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:c909b77fe364: Merge commit '562ef82d6a7f96f6b9da1219a5aaf7d9d7056f1b'
[12:02:07 CEST] <cone-280> ffmpeg 03Martin Storsjö 07master:f96d07f4ec41: configure: Add quotes around a variable which might be empty
[12:02:08 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:55b56a8d6a06: Merge commit 'f96d07f4ec4193fb5293d7ac8f1324aac3c3ea07'
[12:59:33 CEST] <JEEB> does anyone here have any recommendations on cameras for HDR video sample creation?
[13:15:17 CEST] <cone-280> ffmpeg 03Michael Niedermayer 07master:2ccd2c9003c7: avcodec/aacsbr_fixed: Fix multiple runtime error: left shift of negative value -407
[13:15:18 CEST] <cone-280> ffmpeg 03Michael Niedermayer 07master:3fb104f4476a: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int'
[13:23:16 CEST] <kierank> JEEB: sony f65
[13:23:18 CEST] <kierank> but aint cheap
[13:23:24 CEST] <kierank> blackmagic if you are cheap
[13:24:17 CEST] <JEEB> alright. I was looking at a panasonic that's getting a HLG update in July
[13:24:41 CEST] <JEEB> but > buying without being able to assess
[13:32:51 CEST] <wm4> $65,000
[13:32:53 CEST] <wm4> woah
[13:33:20 CEST] <nevcairiel> its pro hardware
[13:33:28 CEST] <JEEB> yea
[13:33:45 CEST] <JEEB> the panasonic I was looking was like $2,500 with a lense
[13:34:44 CEST] <nevcairiel> (not to mention that its 60fps 8K)
[13:35:40 CEST] <JEEB> yea
[14:41:26 CEST] <durandal_1707> atomnuker: wrote that audio filter?
[14:44:30 CEST] <atomnuker> crap, its friday
[15:13:55 CEST] <durandal_1707> and tommorow is saturday
[15:14:28 CEST] <ubitux> https://www.youtube.com/watch?v=kfVsfOSbJY0
[15:14:55 CEST] <ubitux> jamrial: cool for raise major :)
[15:15:13 CEST] <jamrial> good ridance :p
[15:15:27 CEST] <nevcairiel> elenril has also made a patch for the cropping bug, maybe we can strike that line again soon from the file
[15:15:43 CEST] <jamrial> ubitux: i hate you for making me giving this thing a click
[15:16:02 CEST] <ubitux> ;)
[15:16:10 CEST] <durandal_1707> same
[15:17:55 CEST] <jamrial> nevcairiel: yeah, just tested it and it seems to work, so i'll cherry pick it and apply it alongside the skipped stuff once it's pushed to libav
[15:32:39 CEST] <cone-280> ffmpeg 03Muhammad Faiz 07master:162414cefee6: avfilter/graphparser: allow specifying filter at id as filter instance
[16:39:31 CEST] <DHE> are misaligned memory accesses grounds for being fixed in ffmpeg? I'm trying gcc's -fsanitize=... feature and it's showing some errors in a program
[16:41:49 CEST] <iive> DHE: unaligned sse access will segfault.
[16:42:19 CEST] <iive> DHE: however e.g. get_bits usues unaligned access specifically to avoid doble read and shift
[16:42:27 CEST] <DHE> no, just integer work
[16:42:43 CEST] <iive> sse2 has integer work.
[16:46:25 CEST] <DHE> oh, yeah that makes sense...
[16:52:32 CEST] <atomnuker> michaelni: got any idea why swr_get_out_samples(sws, 0) returns some number of samples but a call to swr_convert() doesn't actually reduce that count?
[16:53:04 CEST] <atomnuker> so the API user deadlocks if while (swr_get_out_samples(sws, 0) is used to flush sws
[16:53:55 CEST] <atomnuker> (it does decrement until it reaches something like 38 samples at which point it doesn't get any lower despite repeated calls to sws_convert)
[16:56:05 CEST] <kierank> use libspeexdsp
[16:56:06 CEST] Action: kierank runs
[16:58:16 CEST] <atomnuker> I think the issue is I gave it a non-null source (but 0 input samples)
[16:58:41 CEST] <atomnuker> if I use NULL the issue is swr_next_pts gives me junk
[16:58:53 CEST] <atomnuker> why are timestamps so fucking horrible retarded mess
[16:58:57 CEST] <atomnuker> they shouldn't exist
[16:59:29 CEST] <atomnuker> or at least they should be very stictly defined as current sample number
[17:01:32 CEST] <kierank> blame vfr
[17:01:49 CEST] <atomnuker> what the fuck, calling swr_get_out_samples after sws_convert with NULL, 0 increases
[17:02:37 CEST] <wm4> atomnuker: I think get_out_samples returns an upper bound
[17:03:02 CEST] <atomnuker> well crap, that makes sense
[17:03:02 CEST] <wm4> and swr_convert should at least filter 1 sample if get_out_samples > 0
[17:26:04 CEST] <atomnuker> also a thing which must die is our audio encoders taking non-planar formats as input
[17:27:18 CEST] <atomnuker> latency is irrelevant when you use frames, performance is irrelevant since only insane codecs with SIMD designed to encode non-planar samples are affected and it makes everything more difficult
[17:27:20 CEST] <kierank> most of them don't afaik
[17:27:28 CEST] <atomnuker> flac does, tta does, libopus does
[17:27:34 CEST] <kierank> lib*, sure
[17:27:38 CEST] <kierank> you can't do much there
[17:32:53 CEST] <BBB> DHE: it depends on what type if unaligned accesses
[17:33:29 CEST] <BBB> DHE: for vector, that should crash and be fixed. for scalar, I dont think we care much (see HAVE_FAST_UNALIGNED_*) since its valid on systems that use it
[17:33:38 CEST] <BBB> DHE: so -ENEEDMOREDETAIL :)
[17:34:10 CEST] <DHE> h2645_parse.c:56:     if (!((~AV_RN64A(src + i) &    // affected line, HAVE_FAST_UNALIGNED and HAVE_FAST_64BIT are true
[17:34:31 CEST] <DHE> and others, but this is representative
[17:35:33 CEST] <BtbN> Where does HAVE_FAST_UNALIGNED even come from?
[17:37:09 CEST] <DHE> it's in my config.h
[17:38:04 CEST] <DHE> fast_unaligned_if_any='aarch64 ppc x86'
[17:38:27 CEST] <DHE> so it sounds like gcc is being pedantic
[17:39:44 CEST] <jamrial> AV_RN* expect alignment
[17:40:55 CEST] <BBB> they expect alignment _or_ have_fast_unaligned
[17:41:04 CEST] <jamrial> no wait, that was AV_RN*A
[17:41:06 CEST] <BBB> they imply an aligned read
[17:41:20 CEST] <BBB> :)
[17:41:44 CEST] <BBB> DHE: given that FAST_UNALIGNED is true, I dont think its an issue and I Dont think we want to fix it, since theres a codepath for non-fast-unaligned also
[17:42:13 CEST] <BBB> DHE: its similar to simd optimizations; we all know SSE code doesnt work on arm yet we still allow it on supported systems because we know it works there
[17:42:35 CEST] <DHE> well, obviously. :)
[17:43:38 CEST] <DHE> so I'll just chalk this up as a gcc false positive
[17:43:45 CEST] <jamrial> or maybe that line should use AV_RN* then instead of AV_RN*A
[17:44:50 CEST] <BBB> jamrial: I dont think AV_RN*A implies the data is aligned, it implies the read is aligned
[17:45:07 CEST] <BBB> jamrial: that can be either because the data is aligned or because the system supports aligned reads from unaligned sources
[17:45:29 CEST] <BBB> jamrial: and here clearly the second is implied (and theres a code path if that condition is not true also)
[17:45:45 CEST] <nevcairiel> it definitely works either way
[17:45:57 CEST] <BBB> whether its worth it is a different question and could be argued either way
[17:46:02 CEST] <BBB> but hey, the code exists, so what do we care
[17:48:46 CEST] <jamrial> BBB: "The AV_[RW]NA macros access naturally aligned data in a type-safe way."
[17:48:50 CEST] <jamrial> so i guess that's what it assumes
[17:49:33 CEST] <BBB> that documentation is wrong :-p
[17:49:53 CEST] <jamrial> patch welcome :p
[17:50:03 CEST] <BBB> crap
[17:50:31 CEST] <nevcairiel> what it basically does is tell the compiler to access 32-bit like an 32-bit value, and such, which on some platforms (notably old arm) can expect proper alignment, but on x86 that should be fine anyway
[17:51:26 CEST] <BBB> see? nevcariel is an expert
[17:51:29 CEST] <BBB> he should send a patch instead
[17:51:33 CEST] <BBB> he much cleverer than me
[17:52:22 CEST] <nevcairiel> no clue how to describe that properly
[17:52:46 CEST] <nevcairiel> technically the statement is true, just that the natural alignment required on x86 is very low :p
[18:55:53 CEST] <philipl> BtbN: ordered myself a 1030
[18:56:17 CEST] <BtbN> Didn't see a real benefit compared to a 1050
[18:56:22 CEST] <BtbN> 30¬ cheaper, but meh
[18:59:49 CEST] <jamrial> power consumption maybe?
[19:01:40 CEST] <BtbN> they are both bus powered, and idle usage should be roughly identical
[19:05:28 CEST] <jamrial> BtbN: i see there's a fanless msi GT 1030, so that one should consume less than any 1050
[19:07:11 CEST] <BtbN> so far my 1050 hasn't been using its fans
[19:07:20 CEST] <nevcairiel> the max usage is definitely less, but you might as well  not use it at 100% then =p
[19:09:06 CEST] <jamrial> i like how these are being sold as "e-sports GPUs"
[19:11:25 CEST] <nevcairiel> heh yeah they like to use that for low-end gpus
[19:18:08 CEST] <kierank> jamrial: it's like "sport" RAM
[19:18:39 CEST] <wm4> grrr so there was something almost like 1050 but without fans
[19:18:42 CEST] <wm4> would have loved that
[19:18:48 CEST] <wm4> next GPU is going to be AMD anyway, lol
[19:19:49 CEST] <jamrial> kierank: well, at least in this case it's an real label, since if all you're going to play is dota then they are indeed more than enough :p
[19:21:11 CEST] <nevcairiel> get trolled by hardware decoding so long, just buy the GPU where you might as well give up since it never works anyway? :D
[19:22:08 CEST] <jamrial> it works great, as long as you stick with h264 1080p :p
[19:22:24 CEST] <nevcairiel> i meant for the AMD choice :p
[19:22:52 CEST] <jamrial> i know, that's what i mean :p
[19:22:55 CEST] <nevcairiel> they managed to even screw up h264 decoding in their latest gen
[19:27:11 CEST] <kierank> i love trolling cheap hw h264 decoders
[19:27:39 CEST] Action: kierank throws High422 at the decoder
[19:27:52 CEST] <kierank> and remember that you can have 4:2:0 streams since profiles are meant to be a subset
[19:28:24 CEST] <nevcairiel> noone really does that
[19:28:43 CEST] <nevcairiel> and if its fully main/high compatible without using any new features, it would likely even work
[19:29:00 CEST] Action: kierank does it to troll people
[19:29:44 CEST] <BtbN> MY 1050 is crazy fast with nvenc
[19:30:00 CEST] <BtbN> Like, almost 900fps with 1080p
[19:42:48 CEST] <nevcairiel> the media chips are largely decoupled from the main gpu, so it runs similarly fast on all GPUs, and yeah its gotten really fast in recent generations
[19:43:14 CEST] <BtbN> 1050 (Ti) is even faster
[19:43:18 CEST] <BtbN> it's Pascal Gen. 2
[19:54:17 CEST] <wm4> I don't care for hw decoding, other than testing
[20:03:58 CEST] <kiloreux> I am trying to contribute to the project and would love if I could get any starting point guidance :D 
[20:05:06 CEST] <JEEB> first step: build it!
[20:05:11 CEST] <jamrial> kiloreux: https://ffmpeg.org/developer.html#Contributing :)
[20:05:58 CEST] <kiloreux> I have actually already read that. I was looking more into a hint to familiarize myself with the codebase.
[20:06:16 CEST] <JEEB> depends on what you want to work on
[20:06:38 CEST] <JEEB> decoders? demuxers? filters? ffmpeg.c?
[20:07:03 CEST] <philipl> BtbN: so you got cuvid vp9 10bit verified on it?
[20:07:11 CEST] <BtbN> yes
[20:07:16 CEST] <BtbN> and 12bit
[20:07:21 CEST] <philipl> yay.
[20:07:36 CEST] <kiloreux> JEEB, which one of those needs most work? Or is the slowest?
[20:08:15 CEST] <kiloreux> I want to invest my time in something important for the project.
[20:08:36 CEST] <philipl> BtbN: I've got this super convoluted set up here because I insisted on using a mini-itx case. So I have a u.2 port as my only pcie expansion after the primary graphics card. So from there, it's a cable out to a breakout board that has a 4x slot on it and gets power from a sata power connector. I figure the 1030 is smaller and lighter and so less likely to fall over...
[20:09:29 CEST] <JEEB> kiloreux: haha. slowness usually means asm optimizations
[20:09:32 CEST] <jamrial> kiloreux: decoders can always use optimizations and missing features, like hevc
[20:09:39 CEST] <JEEB> which isn't usually easy
[20:10:00 CEST] <jamrial> some demuxers and muxers may be missing features
[20:10:20 CEST] <philipl> BtbN: and vp8 is not supported? The matrix implies it was in GP104 and then dropped forever.
[20:10:23 CEST] <JEEB> but yes, hevc is one of the slower ones
[20:10:33 CEST] <kiloreux> JEEB, I can try :) . 
[20:10:37 CEST] <jamrial> mov/mp4, matroska, mpegts, all missing stuff to be feature complete
[20:10:45 CEST] <BtbN> I haven't actually tested that, but I think it's just fine?
[20:11:08 CEST] <kiloreux> jamrial, is there a way to know which stuff are "missing" from those?
[20:11:16 CEST] <JEEB> kiloreux: most people either miss something or find that something's broken
[20:11:28 CEST] <JEEB> and that's their first contribution
[20:11:59 CEST] <jamrial> reading the specs, looking at feature requests in the bug tracker, or TODO/FIXME comments in the code
[20:12:54 CEST] <kiloreux> jamrial, JEEB ,Thank you. How do you guys review pull requests? 
[20:12:54 CEST] <jamrial> matroska is missing edit lists, mov/mp4 has that but it's kinda buggy, mpegts i think needed a couple fixes to properly handle opus
[20:13:02 CEST] <kiloreux> The process I mean.
[20:13:09 CEST] <jamrial> kiloreux: patches are sent to the mailing list, and reviewed there
[20:13:28 CEST] <kiloreux> Great. Thank you.
[20:16:30 CEST] <jamrial> kiloreux: basically, git send-email to send the patches, or the output created by git format-patch attached to the email
[21:16:36 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07master:7383a835e47c: avformat/aviobuf: Only downscale the buffer once it has been used
[21:16:36 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07master:0cc6dd1b817b: avformat/id3v2: Use ffio_ensure_seekback() in id3v2_read_internal()
[00:00:00 CEST] --- Sat May 20 2017