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

Wed Sep 27 03:05:03 EEST 2017

[01:50:08 CEST] <JEEB> aaa, blame it on the 02:50
[01:50:26 CEST] <JEEB> didn't even notice in my editor that the docs were also 80 char/line
[01:52:30 CEST] <JEEB> (yes, my editor window happened to be rather narrow)
[01:55:39 CEST] <JEEB> there, that should be OK
[02:30:08 CEST] <cone-082> ffmpeg 03James Almer 07master:ecb9741ba294: avcodec/avpacket: deprecate av_copy_packet()
[02:30:08 CEST] <cone-082> ffmpeg 03James Almer 07master:a447b75de8ed: avformat: replace all uses of av_copy_packet()
[02:30:08 CEST] <cone-082> ffmpeg 03James Almer 07master:c463b81d037f: ffplay: replace use of av_copy_packet()
[04:06:19 CEST] <jamrial> rcombs: do you think you could look at the current dashenc merge queue and see if they can/should be applied or just no-op'd?
[04:06:29 CEST] <rcombs> how do I do that
[04:07:00 CEST] <jamrial> it's about seven commits, starting with https://git.libav.org/?p=libav.git;a=commitdiff;h=9df9309d233f59d9706444a1e24ac24139f2640d
[04:07:43 CEST] <jamrial> you can try to merge them yourself (look at doc/libav-merge.txt)
[04:08:12 CEST] <jamrial> or just create a brach in github or somewhere with the same commits but adapted to apply to ffmpeg
[04:08:25 CEST] <jamrial> and i'll handle the mergign
[04:09:38 CEST] <jamrial> we've been stuck at this point for months since the person that wrote some apparently incompatible dashenc code for us hasn't replied or taken care of this, so it'd be nice if we could resume the merges
[04:17:08 CEST] <tmm1> i need to create an hvcC atom in memory for videotoolbox. looks like the code i need is in ff_isom_write_hvcc(), but that requires a AVIOContext to write to.. is there an easy way i can create a fake iocontext with a memory buffer?
[04:23:21 CEST] <jamrial> tmm1: you can't call ff_isom_write_hvcc() from libavcodec if that's your intention
[04:24:43 CEST] <tmm1> no?
[04:25:15 CEST] <tmm1> so i have to replicate it into lavc either way
[04:27:10 CEST] <rcombs> jamrial: sorry, what's the full commit range?
[04:27:36 CEST] <jamrial> rcombs: 9df9309d233f59d9706444a1e24ac24139f2640d to 7295b7373862ee54903b33d6ef3335531dfa93ad
[04:34:14 CEST] <jamrial> tmm1: does videtoolbox only need extradata in hvcc format, or also the bitstream?
[04:36:00 CEST] <tmm1> just the hvcc
[04:36:17 CEST] <tmm1> just the extradata i mean
[04:36:28 CEST] <tmm1> to set up the decoder
[04:39:26 CEST] <jamrial> so basically a simple function like ff_videotoolbox_avcc_extradata_create() but for hevc? then yeah, duplicating a bit of code from lavf in lavc is fine
[04:48:24 CEST] <cone-082> ffmpeg 03James Almer 07master:89a2472ec536: avformat/img2enc: remove av_dup_packet() call
[04:49:46 CEST] <tmm1> jamrial: yes exactly
[04:49:55 CEST] <tmm1> seems like a lot more code for hvcc though
[04:50:19 CEST] <tmm1> theres a struct and a bunch of decoding and encoding routines
[04:53:35 CEST] <jamrial> tmm1: the code in lavf avc.c is also longer than what's in ff_videotoolbox_avcc_extradata_create(). you don't need all that
[04:54:04 CEST] <jamrial> for starters, in videotoolbox.c you have the NALUs already split and parsed
[05:02:54 CEST] <tmm1> fair enough
[05:07:17 CEST] <rcombs> I was considering adding HEVC after finishing up the split of VideoToolbox into independent decoders
[05:08:06 CEST] <rcombs> the only thing that's missing (afaik) is adding code mirroring the `if (s->dts_sync_point >= 0) {` block in h264_parser.c to the parsers for the other relevant codecs
[05:13:57 CEST] <jamrial> rcombs: do we need decoders when we already have hwaccels?
[05:14:33 CEST] <rcombs> the hwaccels integrate messily with the software decoders, and pull in unnecessary dependencies
[05:14:53 CEST] <rcombs> (because VT is meant to be used for full-stream decode)
[05:22:46 CEST] <rcombs> jamrial: see github/rcombs/ffmpeg/dash-merge; there's a fixup I couldn't figure out how to get rid of
[05:22:53 CEST] <rcombs> other than that it's pretty clean
[05:23:04 CEST] <rcombs> haven't tested
[05:28:28 CEST] <jamrial> rcombs: you couldn't squash the fixup commit into the commit merge in question?
[05:28:46 CEST] <rcombs> I tried!
[05:28:51 CEST] <rcombs> for some reason it stuck around
[05:29:28 CEST] <jamrial> i suppose that without it, the merge prior to it is broken? if so i'll try to squash it here
[05:29:48 CEST] <rcombs> yeah
[05:30:40 CEST] <tmm1> rcombs: are you working on vt decoders?
[05:30:56 CEST] <tmm1> did you find a way to reorder frames
[05:32:01 CEST] <rcombs> tmm1: I've got a dumb method that just reorders based on pts+dts, which is fine for h264 since the parser can generate those already
[05:33:22 CEST] <jamrial> rcombs: thanks a lot for that matter. should have asked for your help earlier :p
[05:33:29 CEST] <jamrial> i'm surprised it applied so cleanly
[05:33:43 CEST] <rcombs> I mean there were conflicts, but they weren't hard to resolve
[05:33:56 CEST] <rcombs> just some stuff that moved around, really
[05:35:29 CEST] <jamrial> i see there were small conflicts, but i assumed our codebase had diversed a lot more than this
[06:41:50 CEST] <jamrial> rcombs: https://github.com/jamrial/FFmpeg/commits/mergework
[06:42:06 CEST] <jamrial> ubitux: ^ :D
[06:42:15 CEST] <jamrial> if you want/can test it
[06:42:45 CEST] <jamrial> or review it
[10:17:24 CEST] <cone-080> ffmpeg 03Frédéric Devernay 07master:eec67f25224a: avcodec/dnxhdenc: fix DNxHR 444 encoding crashes
[11:19:05 CEST] <BtbN> The CUDA thumbnail filter sure munches some VRAM
[11:19:38 CEST] <BtbN> My 1050 with 2GB of VRAM can handle around n=350
[11:19:50 CEST] <BtbN> at 1080p
[15:07:13 CEST] <cone-080> ffmpeg 03Moritz Barsnick 07master:16c8a9feeab3: lavf/tls_gnutls: fix compilation with GnuTLS 2.x
[15:07:14 CEST] <cone-080> ffmpeg 03Moritz Barsnick 07master:6bf48c4805cb: lavf/tls_gnutls: fix warnings from version check
[16:15:31 CEST] <Chloe> Is there any reason to have both the dv1394 and iec61883 libavdevices?
[16:16:33 CEST] <Chloe> also looks like dv1394 is legacy from https://www.kernel.org/doc/Documentation/ABI/removed/dv1394
[16:19:30 CEST] <wm4> nice
[16:19:34 CEST] <wm4> is that 7 years ago
[16:30:40 CEST] <jamrial> cool, send a patch to remove it then
[16:31:58 CEST] <Chloe> will do
[16:33:48 CEST] <jamrial> ubitux: going to push your vda removal patch?
[16:52:43 CEST] <ubitux> jamrial: dunno& maybe i should
[16:52:48 CEST] <mateo`> go
[16:53:01 CEST] <ubitux> i was able to "refactor" the apple garbage kit without dropping vda
[16:53:14 CEST] <ubitux> so i care less about it now
[16:53:17 CEST] <ubitux> just some more zombie code
[16:53:34 CEST] <wm4> the zombie code will cause us more problems later
[16:53:44 CEST] <wm4> such as getting rid of hwaccel-specific stuff in ffmpeg.c
[16:54:30 CEST] <Chloe> ubitux: if it removes code, push it
[16:54:40 CEST] <Chloe> any patch that removes code is probably a good patch
[16:55:10 CEST] <ubitux> you can remove all the code with that reasonning
[16:55:34 CEST] <ubitux> but yeah sure i'll drop it, maybe tomorrow©
[16:55:48 CEST] <ubitux> jamrial: cool btw the merge work
[16:55:57 CEST] <ubitux> i'm working on the side data thing
[16:56:10 CEST] <ubitux> i basically copied the avframe side data
[16:56:29 CEST] <ubitux> it's a bit of a shame that you can't really have multiple side data of the same type, but whatever
[16:56:36 CEST] <ubitux> at least it's buffer ref counter
[16:56:38 CEST] <ubitux> -r+d
[17:11:42 CEST] <jamrial> ubitux: if you mean in packet side data, the thing about only one per type was a recent change of mine
[17:11:59 CEST] <jamrial> since get_side_data() would just fetch the first one and ignore any other you could have added
[17:12:09 CEST] <jamrial> you can undo that if needed
[17:13:09 CEST] <ubitux> i meant in frame side data
[17:13:17 CEST] <ubitux> where the get only raise the first match
[17:13:43 CEST] <jamrial> you can have more than one in frame side data, but get() will also only give you the first, yeah
[17:14:19 CEST] <wm4> I'm also going to argue that side data should have a flat/global namespace
[17:14:30 CEST] <jamrial> with packet, the new() functions will replace the existing one if you add a new one, unlike in frame
[17:15:16 CEST] <JEEB> any additionaly opinions on http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216816.html and http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216699.html ?
[17:15:16 CEST] <atomnuker> jamrial: the example command on the doc commit in mergework needs to be fixed
[17:16:04 CEST] <jamrial> atomnuker: what should it be?
[17:17:10 CEST] <wm4> JEEB: probably good? is it ported from Libav?
[17:17:24 CEST] <atomnuker> jamrial: avconv -> ffmpeg
[17:17:33 CEST] <jamrial> right
[17:17:45 CEST] <JEEB> wm4: yea
[17:18:11 CEST] <JEEB> took me a while to back-port it and I double-checked that the tests' CTS offsets match (other than the time base, FFmpeg's for some reason makes the time base 512 times bigger)
[17:18:20 CEST] <JEEB> but on the other hand the patch touches *nothing* in the time base stuff
[17:18:28 CEST] <JEEB> so (´4@)
[17:18:41 CEST] <wm4> Libav merges usually don't require reviews for pushing
[17:18:47 CEST] <JEEB> so where in libav you have +/-1 offset with a time base 30
[17:18:55 CEST] <wm4> as long as you make clear from which libav commit it was merged, probably
[17:19:09 CEST] <JEEB> you have +/-512 offset with a time base of 30*512
[17:19:19 CEST] <JEEB> so the code works correctly
[17:19:22 CEST] <jamrial> oh yeah, add a "cherry picked from" line if it comes from libav
[17:19:46 CEST] <JEEB> I don't have push rights so whoever pushes it can do that I guess... or do I send a v4 :D
[17:20:05 CEST] <JEEB> let me find the hashes
[17:20:31 CEST] <JEEB> https://git.libav.org/?p=libav.git;a=commit;h=c380a0d7f7a2c7411aae60463e25d916541f0388 , https://git.libav.org/?p=libav.git;a=commit;h=7c35bee0251efc271c8f7900ce816fcb8ec25d19
[19:33:37 CEST] <cone-080> ffmpeg 03Peter Große 07master:9df9309d233f: dashenc: calculate stream bitrate from first segment if not available
[19:33:38 CEST] <cone-080> ffmpeg 03Peter Große 07master:3d23a5f96ad7: dashenc: add support for assigning streams to AdaptationSets
[19:33:39 CEST] <cone-080> ffmpeg 03Peter Große 07master:efd2fc41b3f0: dashenc: allow assigning all streams of a media type to an AdaptationSet
[19:33:40 CEST] <cone-080> ffmpeg 03Peter Große 07master:ca9bc9de6902: dashenc: default to one AdaptationSet per stream
[19:33:41 CEST] <cone-080> ffmpeg 03Peter Große 07master:dce2929efa8e: dashenc: copy language and role metadata from streams assigned to sets
[19:33:42 CEST] <cone-080> ffmpeg 03Peter Große 07master:01f1f017d831: dashenc: use avio_dynbuf instead of packet_write callback
[19:33:43 CEST] <cone-080> ffmpeg 03Peter Große 07master:7295b7373862: dashenc: add webm support
[19:33:44 CEST] <cone-080> ffmpeg 03Peter Große 07master:c5c663541739: doc: add dash muxer
[19:33:45 CEST] <cone-080> ffmpeg 03James Almer 07master:52223ffe4461: Revert "lavf/dashenc: update bitrates on dash_write_trailer"
[19:33:46 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:3b9ef1358836: Merge commit '9df9309d233f59d9706444a1e24ac24139f2640d'
[19:33:47 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:777d53c793a2: Merge commit '3d23a5f96ad72961c14ba3a0c2add8f2ab374b61'
[19:33:48 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:c0fae3ff902e: Merge commit 'efd2fc41b3f0749f9715d50b581f22bbaa8c5b99'
[19:33:49 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:3f7a8bb67b27: Merge commit 'ca9bc9de690258d4761a19b0df6e9c9113b80115'
[19:33:50 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:5c9373385d1a: Merge commit 'dce2929efa8e82b0832a828f7e8cb81ff8c20a4e'
[19:33:51 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:a9f51d19d6b5: Merge commit '01f1f017d831cf14617aaaeafcec3ae3a81efce7'
[19:33:52 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:1b8ef01f04ab: Merge commit '7295b7373862ee54903b33d6ef3335531dfa93ad'
[19:33:53 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:3eb1d05ef719: Merge commit 'c5c663541739cb813a2a5668ee8339b535b35d7d'
[19:35:03 CEST] <wm4> nice
[19:35:33 CEST] <jamrial> now a bunch of noops
[19:38:13 CEST] <wm4> philipl: did you ever take a look at Libav's cuvid support?
[19:39:26 CEST] <wm4> it definitely looks like it would require adding a few new symbols to our cuvid headers
[19:39:36 CEST] <wm4> and I have no idea how to do this without violating copyright
[19:39:57 CEST] <wm4> although the headers say " * Copyright (c) 2010-2017 NVIDIA Corporation" so *shrug*
[19:46:01 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:f033ba470fba: vaapi_encode: Support VBR mode
[19:46:02 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:eddfb5721029: vaapi_h264: Enable VBR mode
[19:46:03 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:ff35aa8ca406: vaapi_encode: Pass framerate parameters to driver
[19:46:04 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:ca62236a89f4: vaapi_encode: Add VP8 support
[19:46:05 CEST] <cone-080> ffmpeg 03James Almer 07master:efc4b3e9d702: Merge commit 'ca62236a89f47bd871eaf69d8d9e837c93c55a6c'
[19:50:21 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:708e84cda1bd: mov: Avoid memcmp of uninitialised data
[19:50:22 CEST] <cone-080> ffmpeg 03James Almer 07master:a6596831a03d: Merge commit '708e84cda1bdbffb92847f3d6ccf6fbeb26d9948'
[20:01:45 CEST] <cone-080> ffmpeg 03Andreas Cadhalpun 07master:612cc0712836: pgssubdec: reset rle_data_len/rle_remaining_len on allocation error
[20:01:46 CEST] <cone-080> ffmpeg 03James Almer 07master:4c359200b142: Merge commit '612cc0712836af2f025b0c68b11da29b9f259d5a'
[20:04:25 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:ab87af41636b: configure: Add proper weak dependency of avformat on network
[20:04:26 CEST] <cone-080> ffmpeg 03James Almer 07master:7289c7658a1a: Merge commit 'ab87af41636b081dd3562423999351b5444fa09e'
[20:09:02 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:d4c2103bd30f: golomb: Convert to the new bitstream reader
[20:09:03 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:0c89ff82e9dd: aic: Convert to the new bitstream reader
[20:09:04 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:ffc00df0a61b: cavs: Convert to the new bitstream reader
[20:09:05 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:6b1f559f9a06: dirac: Convert to the new bitstream reader
[20:09:06 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:0f94de8a092b: fic: Convert to the new bitstream reader
[20:09:07 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:d85b37a95531: loco: Convert to the new bitstream reader
[20:09:08 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:5a6da49dd0c0: ralf: Convert to the new bitstream reader
[20:09:09 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:2b94ed12de7b: shorten: Convert to the new bitstream reader
[20:09:10 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:2d72219554ad: h261dec: Convert to the new bitstream reader
[20:09:11 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:ab2539bd374f: ffv1: Convert to the new bitstream reader
[20:09:12 CEST] <cone-080> ffmpeg 03James Almer 07master:475ff3ec2487: Merge commit 'ab2539bd374fe7ddbc6e2f058b62645cd5076192'
[20:10:51 CEST] <wm4> so they're all skipped, right
[20:24:24 CEST] <tmm1> woohoo, i got vt hevc decoding working
[20:24:35 CEST] <tmm1> building that hvcC was a pita
[20:29:02 CEST] <JEEB> 'grats
[20:29:15 CEST] <JEEB> and yea, hvcC is overly complex if I recall correctly
[20:29:23 CEST] <JEEB> you duplicate a crapload of stuff that's in the darn parameter sets
[20:29:38 CEST] <rcombs> jamrial: \o/
[20:30:48 CEST] <wm4> did they make it worse than avcc
[20:30:53 CEST] <JEEB> yes
[20:30:58 CEST] <wm4> how...
[20:31:05 CEST] <JEEB> wm4: https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html
[20:31:14 CEST] <JEEB> this is pretty much 1-1 to the 14496-15 thing
[20:31:40 CEST] <wm4> oh right, I remember this
[20:32:24 CEST] <nevcairiel> for some reason they keep mirroring more and more info from the sps into it
[20:32:31 CEST] <JEEB> yea
[20:33:09 CEST] <JEEB> probably to enable things that don't implement the parameter set parsing to get some values so that players can say nope quicker?
[20:34:34 CEST] <wm4> that kind of stuff is the only thing that'd make sense
[20:34:41 CEST] <TD-Linux> is parsing a sps really that hard?
[20:34:42 CEST] <wm4> but it's still dumb
[20:35:13 CEST] <JEEB> TD-Linux: it had some coding mode for the values
[20:35:19 CEST] <TD-Linux> do they still have inband and out of band sps
[20:35:22 CEST] <JEEB> which I guess people are lazy to implement?
[20:35:38 CEST] <JEEB> there's one identifier for "you can have in and out of band"
[20:35:45 CEST] <JEEB> and another for no in-band
[20:35:56 CEST] <JEEB> apple decided to use the "no in-band" one
[20:45:37 CEST] <cone-080> ffmpeg 03Anton Khirnov 07master:b420a27e7475: avconv: allow -b to be used with streamcopy
[20:45:38 CEST] <cone-080> ffmpeg 03James Almer 07master:2508e606fba8: Merge commit 'b420a27e74750b60d2e064236afb10be06a38ace'
[20:52:26 CEST] <tmm1> JEEB: you mean the array_completeness flag?
[20:52:40 CEST] <JEEB> yea
[20:52:53 CEST] <JEEB> there was a rule related to the identifier regarding that IIRC
[20:53:02 CEST] <tmm1> i just tried sending first PPS in hvcC and second in stream
[20:53:04 CEST] <tmm1> and it seems to work
[20:53:18 CEST] <tmm1> with array_completeness=0 in the hvcc
[20:54:32 CEST] <JEEB> pretty sure that is against the spec tho :D
[21:02:31 CEST] <wm4> you know, Apple could just have fixed the videotoolbox API
[21:08:18 CEST] <rcombs> 1. accept Annex B sans-extradata
[21:08:24 CEST] <rcombs> 2. reorder internally
[21:08:29 CEST] <rcombs> but nope
[21:23:58 CEST] <cone-080> ffmpeg 03Anton Khirnov 07master:fd9212f2edfe: Mark some arrays that never change as const.
[21:23:59 CEST] <cone-080> ffmpeg 03James Almer 07master:318778de9ebe: Merge commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3'
[21:28:30 CEST] <rcombs> jamrial: wait shit I done fucked up
[21:28:51 CEST] <jamrial> rcombs: how so?
[21:29:18 CEST] <jamrial> i ran the example command in the dashenc doxy and the output seemed the same, for that matter
[21:29:40 CEST] <rcombs> swapped write_header/init_output
[21:29:45 CEST] <rcombs> patch in a sec
[21:30:02 CEST] <rcombs> though it might not matter with the dynbuf change
[21:30:22 CEST] <cone-080> ffmpeg 03wm4 07master:3ad825793a43: hwcontext_cuda: implement frames_get_constraints
[21:30:23 CEST] <cone-080> ffmpeg 03James Almer 07master:e7c91850531a: Merge commit '3ad825793a43253154bed05827f27425fc0757df'
[21:39:12 CEST] <rcombs> jamrial: OK, while trying to test this, I'm finding dashenc is broken in a weird unrelated way
[21:39:36 CEST] <rcombs> init_output_stream_streamcopy copies the codec_tag from the input to the output, which breaks because the output doesn't have compatible tags
[21:39:44 CEST] <rcombs> if e.g. the input is MPEGTS and the output is DASH
[21:40:10 CEST] <jamrial> rcombs: that'd be something that 61f589e31e fixes
[21:40:12 CEST] <jamrial> i think
[21:40:22 CEST] <jamrial> we can cherry pick that since it's too far away in the queue
[21:40:42 CEST] <rcombs> if anything it would be the opposite
[21:40:49 CEST] <rcombs> dashenc already doesn't have a codec_tag here
[21:41:04 CEST] <jamrial> actually no, you're right
[21:41:21 CEST] <rcombs> the problem is that there isn't a tag member, so ffmpeg.c tries to copy it
[21:41:32 CEST] <rcombs> so, either ffmpeg.c should stop that, or dashenc should unset it
[21:43:30 CEST] <cone-080> ffmpeg 03wm4 07master:577326d43059: lavc: deprecate refcounted_frames field
[21:43:31 CEST] <cone-080> ffmpeg 03James Almer 07master:b1cf151c4dfd: Merge commit '577326d430593a25456393a75212b95d1cd94131'
[21:43:41 CEST] <rcombs> I don't know when this regressed
[21:43:46 CEST] <jamrial> wm4: why didn't you apply that here back then?
[21:44:19 CEST] <wm4> oh, it's not? not sure
[21:44:50 CEST] <jamrial> rcombs: maybe d086e40459
[21:45:06 CEST] <rcombs> is that applied?
[21:45:20 CEST] <jamrial> thats an ffmpeg commit, so yes :p
[21:45:43 CEST] <jamrial> i mean that one might have introduced the regression. it's the one that removed .codec_tag
[21:49:25 CEST] <rcombs> yeah that seems likely
[21:49:56 CEST] <rcombs> I'll copy the handling code from segment.c
[21:50:37 CEST] <jamrial> that commit was needed btw because mov muxer changed something regarding codec_tags
[21:51:52 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:b3825723dcef: configure: Merge compiler/libc/os hacks sections
[21:51:53 CEST] <cone-080> ffmpeg 03James Almer 07master:f9445760289d: Merge commit 'b3825723dceffc64240da7b0e562bd1fd024da26'
[21:54:17 CEST] <rcombs> it'd have also been needed due to adding matroska dash support
[21:55:11 CEST] <rcombs> alright, patches sent
[21:56:12 CEST] <jamrial> rcombs: you could have just applied the merge fix
[21:56:46 CEST] <rcombs> ¯\_(Ä)_/¯
[21:57:28 CEST] <jamrial> i mean, it's not like it needs a review if it's rolling back an accidental change you did :p
[22:05:32 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:24d5680bbc01: configure: Simplify inline asm check with appropriate helper function
[22:05:33 CEST] <cone-080> ffmpeg 03James Almer 07master:932e28b13e9a: Merge commit '24d5680bbc01fc124709d522d348572ad4672563'
[22:09:16 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:66988320794a: configure: Add proper weak dependency of drawtext filter on libfontconfig
[22:09:17 CEST] <cone-080> ffmpeg 03James Almer 07master:740e557d6eac: Merge commit '66988320794a107f2a460eaa71dbd9fab8056842'
[22:13:12 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:acfa7a2178f0: configure: Drop weak dependencies on external libraries for webm muxer
[22:13:13 CEST] <cone-080> ffmpeg 03James Almer 07master:3f9e7ddd90d3: Merge commit 'acfa7a2178f08fd81b66279959cd55ec3ae237e2'
[22:14:32 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:c29da01ac95e: svq3: Convert to the new bitstream reader
[22:14:33 CEST] <cone-080> ffmpeg 03James Almer 07master:a901869c19ed: Merge commit 'c29da01ac95ea2c8c5c4b3a312a33aaaa8fb7068'
[22:19:25 CEST] <rcombs> jamrial: also did you see my commit changing the merge tool to use HEAD instead of master
[22:19:44 CEST] <jamrial> yes, but didn't push it since it's not a merge
[22:20:09 CEST] <jamrial> send it to the ml, or ask ubitux what he thinks (he wrote the script afaik)
[22:21:48 CEST] <rcombs> OK
[22:24:21 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:a97563c889fe: configure: Simplify libxcb check
[22:24:22 CEST] <cone-080> ffmpeg 03James Almer 07master:1985071e41f4: Merge commit 'a97563c889fefd81ad6b3758471434d8c2e2e550'
[22:32:26 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:aba7fdcc8baa: configure: Add require_header() convenience function
[22:32:27 CEST] <cone-080> ffmpeg 03James Almer 07master:14194090a6f6: Merge commit 'aba7fdcc8baaed35e804c7882b70a848a0e566c7'
[22:34:40 CEST] <ubitux> rcombs: master or origin/master?
[22:35:35 CEST] <ubitux> jamrial: thx a lot for the merges btw
[22:35:52 CEST] <JEEB> yea, great stuff
[22:36:14 CEST] <jamrial> ubitux: no prob
[22:36:33 CEST] <durandal_1707> more oil on fire
[22:37:06 CEST] <JEEB> I ain't seeing no fire
[22:38:22 CEST] <rcombs> ubitux: patch sent
[22:39:36 CEST] <wm4> jamrial: yeah, it's great to see merges continuing
[22:40:47 CEST] <ubitux> rcombs: oh you're actually switching from master to HEAD mmh
[22:41:00 CEST] <durandal_1707> why?
[22:41:09 CEST] <rcombs> yeah, to allow doing merges while not on local master
[22:41:30 CEST] <ubitux> should be fine i guess
[22:45:37 CEST] <ubitux> what's going on with the bitstream reader?
[22:45:51 CEST] <ubitux> we still haven't the 64-bit version?
[22:54:09 CEST] <durandal_1707> you mean libav one?
[22:55:28 CEST] <ubitux> no, ffmpeg
[22:55:33 CEST] <ubitux> or was it merged?
[22:55:40 CEST] <ubitux> i mean, pushed
[22:56:26 CEST] <durandal_1707> pushed what?
[22:56:38 CEST] <ubitux> our get_bits.h was supposed to get a 64-bit cache version
[22:56:44 CEST] <ubitux> enabled on some configurations
[22:56:55 CEST] <ubitux> i thought a patch was sent for that purpose
[22:57:14 CEST] <durandal_1707> you are misinformed
[22:57:59 CEST] <durandal_1707> it have issues
[22:58:06 CEST] <ubitux> https://patchwork.ffmpeg.org/patch/4260/
[22:58:12 CEST] <ubitux> you were actually the one behind this
[22:58:52 CEST] <ubitux> i mean, we have a performance gap to close compared to libav on x86 with important decoders such as h264
[22:59:48 CEST] <BBB> most h264 doesnt use get_bits (cavlc), though...
[23:00:11 CEST] <durandal_1707> see last review by foo86
[23:06:24 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:bcaedef1189a: configure: Add require_cpp_condition() convenience function
[23:06:25 CEST] <cone-080> ffmpeg 03James Almer 07master:c83c164f05cb: Merge commit 'bcaedef1189a3531aa4dfb020627eb0133ffa89c'
[23:29:56 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:a1a143adb0fd: rtmp: Rename packet types to closer match the spec
[23:29:57 CEST] <cone-080> ffmpeg 03James Almer 07master:f858a6e27817: Merge commit 'a1a143adb0fd11c474221431417cff25db7d920f'
[23:35:56 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:15a92e0c402c: rtmp: Correctly handle the Window Acknowledgement Size packets
[23:35:57 CEST] <cone-080> ffmpeg 03James Almer 07master:4ea63d2cdd04: Merge commit '15a92e0c402c830b607f905d6bf203b6cfb4fa8c'
[23:49:19 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:740b0bf03b4b: build: Ignore generated .version files
[23:49:21 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:7abdd026df6a: asm: Consistently uppercase SECTION markers
[23:49:21 CEST] <cone-080> ffmpeg 03James Almer 07master:62f1c9f10671: Merge commit '740b0bf03b4bb8b0a0e964750817ac0363a33c55'
[23:49:22 CEST] <cone-080> ffmpeg 03James Almer 07master:0c005fa86f01: Merge commit '7abdd026df6a9a52d07d8174505b33cc89db7bf6'
[23:51:46 CEST] <cone-080> ffmpeg 03John Stebbins 07master:8e67039c6312: asfdec: Use the ASF stream count when iterating
[23:51:47 CEST] <cone-080> ffmpeg 03James Almer 07master:e666c2b5ec97: Merge commit '8e67039c6312ba520945f2c01b7b14df056d5ed1'
[23:56:46 CEST] <horox> sample video uploading... here is discussion of the problem: https://www.magiclantern.fm/forum/index.php?topic=18392.0   a issue with black level decoding (Green Cast)....
[23:57:19 CEST] <JEEB> right, bayer_rgb16le
[23:58:59 CEST] <horox> https://pastebin.com/Z7jV9knA
[00:00:00 CEST] --- Wed Sep 27 2017