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

[burek]

[01:05:02 CET] <atomnuker> durandal_170: hey, what happened to the bonk decoder you wrote?
[01:05:56 CET] <atomnuker> last on the ML thread was some guy who fixed the crashes and the noise bug
[01:06:30 CET] <BBB> its funny that it was claimed theres a wide majority to remove ffserver, yet keep is leading 4-2, reminds me of trump/brexit being unexpected"
[01:06:52 CET] <BBB> (and many people refuse to vote)
[01:08:10 CET] <durandal_170> bonk? it is past, now I'm on pixlet
[01:08:24 CET] <atomnuker> I don't mind it if it gets fixed, and it's getting fixed, so I'm cool
[01:09:02 CET] <atomnuker> durandal_170: you have a plan on what to write? what's after pixlet :) ?
[01:09:25 CET] <kierank> BBB: all that's happened is certain people have had so many votes that people are fed up of voting
[01:10:41 CET] <durandal_170> atomnuker: reing stuff others don't want
[01:11:43 CET] <kierank> durandal_170: did I tell you newtek speedhq has f/idcts from xvid
[01:11:44 CET] <kierank> stolen
[01:12:24 CET] <durandal_170> lol, yes I remember
[01:13:18 CET] <durandal_170> but pixlet is wavelet and 16bit so yay
[01:15:21 CET] <durandal_170> atomnuker: if you want help there's deobfuscating contest of one function...
[01:21:44 CET] <jamrial_> BBB: with wm4, ubitux and i voting against this motion that can change. but then there's the people that commented but didn't yet vote, like carl, llogan and saste, so i can't say what will happen
[01:59:05 CET] <kierank> atomnuker: want to talk about ffa1 at fosdem?
[03:03:55 CET] <atomnuker> kierank: well, FFA1's a bunch of untested ideas atm, I could speak about something else though
[03:04:19 CET] <kierank> hmm we're missing a daala/av1 talk
[03:05:24 CET] <atomnuker> you can't have fosdem without one
[03:08:25 CET] <Compn> ffa1 ? audio ?
[03:08:40 CET] <Compn> based on anything ?
[03:08:44 CET] <Compn> flac ? 
[03:09:20 CET] <atomnuker> probably opus
[03:09:29 CET] <atomnuker> it might have a reversible preemphasis filter
[03:09:44 CET] <atomnuker> which might then go into a reversible integer dct-2
[03:10:00 CET] <atomnuker> which might go into a pyramid vector quantization
[03:11:05 CET] <atomnuker> and that's about as far as I've planned it, I need to see how much adaptation would help when coding that
[03:12:24 CET] <atomnuker> but it would definitely not do an LPC on the raw samples and have residuals, that's what everyone else does and I don't like it
[03:13:06 CET] <atomnuker> surely someone should have come up with a better idea in the last 20 years since everyone started to use it
[03:14:27 CET] <atomnuker> the fact ape tried to do prediction which fails so spectacularly is a testament to the staleness of lossless audio compression
[03:41:26 CET] <Compn> durandal_170 : if you want something fun, hack the h263 decoder to handle vivo files :D
[03:41:49 CET] <Compn> its the oldest format i've been trying to get someone to RE it forever
[03:43:17 CET] <Compn> mplayer has the demuxer, ffmpeg has decoder for the first format...
[04:00:21 CET] <kierank> lol nice
[04:07:07 CET] <jamrial> that's the kind of thing you post to the security list, not trac
[04:34:41 CET] <Timothy_Gu> BtbN: can you take a look at https://github.com/FFmpeg/FFmpeg-Coverity/pull/1 when you get a chance?
[04:38:06 CET] <BBB> atomnuker: omg new codec for you?
[04:38:09 CET] <BBB> wth
[04:40:35 CET] <atomnuker> BBB: yeah, it's that thing I said I was working on in March but I only got as far as having the Daala entropy coder working before learning Opus's entropy coder was more efficient and got bored
[04:44:06 CET] <atomnuker> would be fun to port Daala's adaptation to the Opus entropy coder and see the gains I can get
[04:45:53 CET] <atomnuker> I hate QMFs but they would be perfect for this, just make multiple of them bandpassing and plug them into a dct to get hopefully more or less laplacian distributions per each hybrid band
[05:00:10 CET] <BBB> atomnuker: is there need/want for a new/better audio codec?
[05:00:26 CET] <BBB> atomnuker: I dont want to be an asshole, but most effort nowadays appears to be in video codecs
[05:00:44 CET] <michaelni> BBB, you are listed in maintainers for http.c can you look into fixng ticket 5992 ? (i have to go to bed atm so can only in a few hours)
[05:01:21 CET] <BBB> I review patches
[05:05:17 CET] <BBB> and its 11pm, I need to sleep also, kids have school tomorrow
[05:06:32 CET] <BBB> I think the easiest fix is to change line 1264 if (!s->chunksize) into if (s->chunksize <= 0)
[05:07:34 CET] <BBB> that prevents the codepath hes talkinga bout
[05:09:54 CET] <atomnuker> BBB: nah, not really, on the lossless side everyone has terabytes of storage so the 70ish percet you get is good enough, but I think after 16 or so years we can do better
[05:10:20 CET] <atomnuker> FFV1's so good it beats flif which is derived from it, and it also beats every single lossless compression mode of everything else
[05:10:41 CET] <BBB> ffv1 is kinda slow
[05:10:46 CET] <BBB> you could make it faster
[05:11:04 CET] <atomnuker> flif takes a MINUTE to encode a single 3000x2000 or so image
[05:11:18 CET] <BBB> Im sure av1 takes a minute also
[05:11:21 CET] <atomnuker> ffv1 takes around a second on the highest level with a range coder
[05:11:25 CET] <BBB> that doesnt mean its acceptable
[05:11:32 CET] <BBB> you should aim for realtime 4k encoding
[05:11:50 CET] <BBB> ok Im going to bed
[05:11:55 CET] <BBB> see you guys tomorrow
[05:11:55 CET] <atomnuker> everything in that range lacks compression, like vc2
[05:12:06 CET] <BBB> http fix change ! to <=0 and itll fix it I think
[05:12:12 CET] <BBB> maybe Ill submit a patch tomorrow
[05:12:14 CET] <BBB> tired now
[05:12:18 CET] <atomnuker> it's all tuned for asic-like hardware, not SIMD of big ol' x86
[05:17:51 CET] <kierank> atomnuker: you could talk to pengvado about ffv2
[05:18:06 CET] <kierank> perhaps he might help you finish it
[05:35:37 CET] <atomnuker> you can get more efficient than ffv1?
[10:38:20 CET] <luozijun> Hi
[10:41:19 CET] <luozijun> Hi, i have one problem, `AVCodecContext` can't set reslution like `1440x900 / 1234/1020` ? 
[10:56:49 CET] <cone-816> ffmpeg 03Steven Liu 07master:55affd95bd9b: avformat/hlsenc: fix ticket id 5988 for DISCONTINUITY
[11:06:16 CET] <Timothy_Gu> luozijun: use AVOptions api
[11:08:15 CET] <Timothy_Gu> also please go to #ffmpeg-users
[11:25:39 CET] <luozijun> Timothy_Gu: AV_OPT_TYPE_IMAGE_SIZE ?
[11:30:47 CET] <j-b> 'morning
[13:51:13 CET] <wm4> lol at ffmpeg "decision" project
[13:51:23 CET] <wm4> basically trolls rule this project
[13:51:44 CET] <wm4> somehow made decisions become "unacceptable"
[14:10:26 CET] <mateo`_> "ffserver is dead, long live ffserver"
[14:16:34 CET] <wm4> it's more like "we all have decided to remove ffserver months ago? UNACCEPTABLE"
[14:25:49 CET] <kierank> wm4: not trolls but filibusterers
[14:28:34 CET] <wm4> I don't know this word
[14:29:31 CET] <J_Darnley> It refers to when politicians speak for hours to delay things
[14:29:33 CET] <funman> ttp://www.thefreedictionary.com/filibusterer
[14:29:36 CET] <funman> +h
[14:29:55 CET] <wm4> oh, that fits perfectly
[14:29:56 CET] Action: funman just learned that word's meaning as well
[14:30:41 CET] <kierank> obstruieren in german apparently
[14:45:55 CET] <BBB> you guys are crazy
[14:46:00 CET] <BBB> I dont get what I want, so let me whine"
[14:46:10 CET] <BBB> look, 6 people dont want to remove ffserver, 2 do
[14:46:22 CET] <BBB> the rest refuses to vote because youre too great to be wrong
[14:46:28 CET] <BBB> you want ffserver dead? vote it dead
[14:46:36 CET] <BBB> you lose the vote? be a man and accept defeat
[14:46:51 CET] <BBB> (or woman, whatever; not intended to be sexist, just telling you to grow up)
[14:47:22 CET] <JEEB> how many people who voted on the original vote didn't vote on this attempt at reverting the vote?
[14:47:28 CET] <BBB> so vote again
[14:47:32 CET] <BBB> dont be so difficult
[14:47:40 CET] <JEEB> I would if I was on the voter list >_>
[14:47:45 CET] <wm4> we _already_ voted
[14:47:59 CET] <BBB> JEEB: so get on the voter list
[14:48:14 CET] <BBB> wm4: so vote again. youre so difficult, you claim you have majority support but Im not seeing it
[14:48:23 CET] <BBB> Im seeing 6-2 in favour of keeping it, thats pretty decisive
[14:48:44 CET] <wm4> I never claimed this
[14:48:57 CET] <wm4> and don't pretend the way they're doing this is ok
[14:50:44 CET] <BBB> I dont think its great, but we never disallowed this so strictly speaking theyre simply using the rights bestowed upon them
[14:51:58 CET] <jamrial> wm4: no, you didn't vote
[14:52:12 CET] <wm4> jamrial: I didn't not vote either
[14:52:20 CET] <jamrial> but you still can, if you care about the result of this
[14:53:10 CET] <wm4> I don't acknowledge its vote so I won't give a yes/no/absent vote
[14:53:23 CET] <wm4> if they can be complicated, so can I
[14:53:46 CET] <jamrial> you complain a lot about management and awful decisions made by the project, but when you have the chance to affect the outcome you instead choose not to
[14:55:07 CET] <BBB> exactly my point
[14:55:35 CET] <BBB> trump is so terrible, and I dont like clinton perfectly either, so let me just express my opinion by not voting! look how great I am
[14:55:46 CET] <BBB> why is trump our president! *cry*
[14:56:31 CET] <wm4> BBB: isn't that why US citizens are allowed to carry weapons
[14:56:44 CET] <BBB> I dont think thats the intention
[14:56:45 CET] <wm4> so did we actually vote about ffserver before? I thought we did, but I can't find the thread
[14:57:30 CET] <jamrial> no, we didn't
[14:57:43 CET] <BBB> we didnt, someone sent a patch, it was OK'ed
[14:57:54 CET] <BBB> (patch to add news entry)
[14:58:02 CET] <BBB> that was the decision to remove ffserver
[14:58:08 CET] <jamrial> we discussed it here, atomnuker sent a patch, it was oked, committed, and not challenged for four months
[14:58:26 CET] <wm4> well shit
[14:58:38 CET] <jamrial> until the time to make it effective, where a billion people suddenly needed ffserver to live
[14:58:59 CET] <wm4> then it's pretty legitimate to demand a vote
[14:59:17 CET] <BBB> no shit sherlock
[14:59:20 CET] <BBB> now go vote
[14:59:27 CET] <jamrial> sure is, which is why i didn't attempt to void the vote
[15:03:55 CET] <durandal_170> did my vote counted? it was complicated
[15:04:23 CET] <durandal_170> does ffserver still use internal stuff?
[15:04:54 CET] <JEEB> I thought the ffm demuxer pretty much was a walking internal API boy. regarding ffserver.c I'm not sure any more?
[15:05:26 CET] <RiCON> the use of internal APIs was only one reason stated in the news post
[15:06:05 CET] <RiCON> "Furthermore the program has been hard for users to deploy and run due to reliability issues, lack of knowledgable people to help and confusing configuration file syntax."
[15:07:44 CET] <jamrial> JEEB: same, but michael did some magic and fixed in a week what nobody else attempted to fix for months
[15:08:02 CET] <JEEB> really?
[15:08:18 CET] <JEEB> ffm demuxer and ffserver.c no longer utilize the APIs we were planning to remove?
[15:08:26 CET] <JEEB> (because they shouldn't be around)
[15:08:38 CET] <jamrial> ffm* doesn't use deprecated api anymore. no ide about ffserver and internal api
[15:08:44 CET] <JEEB> \o/
[15:09:18 CET] <wm4> true
[15:09:42 CET] <jamrial> in any case, isn't it funny how michael solved in a week what others, the people supposedly interested in ffsever, didn't fix during the past few years?
[15:09:50 CET] <wm4> so after a year of drama michaelni took 1 day of time or so and fixed it
[15:10:14 CET] <JEEB> yes, after someone facedesks hard enough at the drama happening they might actually do something
[15:11:05 CET] <jamrial> all this would have been avoided if people actually developed that stupid program
[15:11:53 CET] <BtbN> Who even uses ffserver?
[15:12:01 CET] <ubitux> many users
[15:12:05 CET] <wm4> that is, actually fixing it, instead of filibustering it and then saying "let's keep it anyway"
[15:12:19 CET] <JEEB> a few people here and there seem to use it
[15:12:27 CET] <wm4> we'd probably do those users a service by dropping it
[15:12:34 CET] <JEEB> mostly on #ffmpeg we push people to other streaming servers
[15:12:42 CET] <JEEB> because they tend to be simpler to utilize
[15:12:47 CET] <JEEB> like nginx-rtmp, icecast etc
[15:12:53 CET] <JEEB> and/or vlc
[15:14:43 CET] <wbs> I don't think it's still "fixed" in the sense that ffserver and ffmpeg can be built from differing major versions
[15:14:57 CET] <wbs> since it sends literal enum values over the wire, and those enum values are free to be changed at any major bump
[15:15:05 CET] <wbs> and also, it doesn't even specify which major version it is talking about in the protocol
[15:15:22 CET] <wbs> so api-wise it might be "fixed"; design wise, not yet
[15:16:45 CET] <wm4> why not fix ffserver by using the ffprobe demuxer instead of ffmdec?
[15:18:36 CET] <ubitux> the ffm thing should be moved in ffserver itself, no?
[15:23:03 CET] <BBB> ffserver still uses ffm, which is still in libavformat
[15:23:17 CET] <BBB> I feel ffm should not be in lavf
[15:25:00 CET] <wm4> can it not be?
[15:25:18 CET] <BBB> there is no reason it exists in lavf other than ffserver
[15:25:25 CET] <BBB> same as all the deprecated APIs
[15:25:27 CET] <wm4> of course
[15:25:39 CET] <BBB> so it should indeed not be in lavf
[15:25:44 CET] <BBB> since ffserver is the only reason it is
[15:27:40 CET] <BBB> ubitux: yes
[15:27:51 CET] <BBB> I Dont know/care how ffmpeg/ffserver interaction would work, but thats to whoever does it
[15:27:53 CET] <BBB> ffm has to go
[15:28:09 CET] <wm4> so my question would be does ffserver always use ffm for input/output, require it only for one of them, or is it completely optional?
[15:28:59 CET] <wm4> ubitux, michaelni: questions for you ^
[15:30:04 CET] <ubitux> my knowledge of ffserver is very limited
[15:31:53 CET] <wm4> ok so only michaelni knows how ffserver actually works
[15:36:32 CET] <wbs> wm4: afaik both ffmpeg and ffserver uses ffm, so if ffmpeg were to be able to communicate with ffserver, it needs an ffm demuxer/muxer as well
[15:37:22 CET] <wbs> wm4: and it's all pretty backwards compare to most other protocols; if ffmpeg is to send data to ffserver, ffserver first tells it what codecs and encoder parameters to use, and then switches(?) communication direction to ffmpeg sending, ffserver receiving
[15:38:01 CET] <wm4> huh
[15:38:53 CET] <wbs> all of this is custom code in ffmpeg.c ofc
[15:39:09 CET] <wm4> lol really?
[15:39:26 CET] <wm4> so ffmpeg.c has explicit ffserver handling, outside of the ffm libavformat parts?
[15:39:33 CET] <wbs> yes
[15:39:39 CET] <wbs> see ffmpeg_opt.c, read_ffserver_streams etc
[15:39:46 CET] <wbs> was the first I found with a quick grep
[15:40:02 CET] <wm4> ah
[15:40:30 CET] <wbs> so yes, it no longer uses deprecated api (avstream->avcodeccontext), but it still uses a bunch of networking internals from lavf, and the design is buried deep in ffmpeg
[15:40:53 CET] <wbs> I've looked at it a few times before it was removed in libav, but I chose not to waste my time on such a design that I disagree with so much
[15:42:47 CET] <wm4> just looked at ffserver.c
[15:42:48 CET] <wm4> #include "libavformat/avio_internal.h"
[15:42:53 CET] <wm4> ...yeah
[15:43:10 CET] <wm4> even #include "libavformat/internal.h"
[15:43:43 CET] <wbs> and it uses a bunch of internal rtp/udp functions that don't fit in in the normal avio/urlprotocol api
[15:45:32 CET] <wbs> so it's not "fixed" yet. one of the deprecated details in codecpar might be worked around
[15:54:14 CET] <durandal_170> ^is that server code?
[15:54:54 CET] <wbs> no, it is client code, for talking to a ffserver
[15:55:13 CET] <wm4> wat
[15:55:27 CET] <wm4> durandal_170: do you mean the ticket?
[15:55:28 CET] <wbs> the one in ffmpeg_opt.c that is
[15:55:43 CET] <wbs> the ticket seems like the normal http client code
[15:56:23 CET] <wbs> (so not a valid reason to bash the http "server" mode)
[15:56:39 CET] <durandal_170> ok
[15:57:20 CET] <wm4> michaelni: can I get access to the ffmpeg security mailing list?
[15:59:50 CET] <BBB> Ive sent a patch for the http issue to ff-sec
[16:00:01 CET] <BBB> (Im listed as maintainer so apparently its up to me to do stuff with it)
[16:00:11 CET] <BBB> I dont know how sec review works
[16:00:49 CET] <BBB> hm, he claims to have reviewed them, I havent received the review
[16:00:50 CET] <BBB> strange
[18:21:14 CET] <nevcairiel> Why is it that coverity reports are so .. inconsistent? It mails me with new defects in files that haven't changed for ages, it's really a big annoying that way
[18:23:02 CET] <nevcairiel> bit*
[18:26:09 CET] <wm4> maybe because they change their heuristics?
[18:28:17 CET] <nevcairiel> Daily?
[18:28:36 CET] <nevcairiel> Every mail I got the last week touched some old code
[18:29:31 CET] <cone-511> ffmpeg 03James Almer 07master:b52d3574d466: configure: check for strtoull on msvc
[18:29:36 CET] <wm4> who knows
[18:29:54 CET] <wm4> maybe they have random heuristics lol
[18:32:48 CET] <philipl> It's a service. It improves every day!
[18:33:03 CET] <philipl> or maybe our code bitrots a little more every day.
[18:34:39 CET] <philipl> oh, and in this case Timothy_Gu added a bunch of extra dependencies last night
[18:34:42 CET] <philipl> that's probably why
[18:36:01 CET] <wm4> that makes a good explanation
[18:36:42 CET] <philipl> we're now testing with the full set of dependencies for x86
[18:36:50 CET] <philipl> only android stuff is missing
[18:46:51 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:0e3dc45ce81f: avcodec/interplayvideo: Check side data size before use
[18:46:52 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/3.1:2dcc0bce3924: vp9: change order of operations in adapt_prob().
[18:46:53 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:b7940ecb5a94: avcodec/dvdsubdec: Fix buf_size check
[18:46:54 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:b6b703441607: avformat/isom: Fix old API regression with exporting max bitrate
[18:46:55 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:37ff66d1bde7: avcodec/dvdsubdec: Fix off by 1 error
[18:46:56 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:e90fbc86c186: avformat/flvdec: Fix regression loosing streams
[18:46:57 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:668e47e9fda1: avcodec/8bps: Check side data size before use
[18:46:58 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:4f2716da68d9: avcodec/cinepak: Check side data size before use
[18:46:59 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:e23f86d2fb9d: avcodec/idcinvideo: Check side data size before use
[18:47:00 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:dec89aee89b0: avcodec/kmvc:  Check side data size before use
[18:47:01 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:d98d006eefb9: avcodec/msrle:  Check side data size before use
[18:47:02 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:1f8452b428f3: avcodec/qtrle:  Check side data size before use
[18:47:03 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:02ac02e2ac0f: avcodec/qpeg:  Check side data size before use
[18:47:04 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:6f1ef60d50cf: avcodec/msvideo1: Check side data size before use
[18:47:05 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:a190ca54f438: avcodec/rawdec: Check side data size before use
[18:47:06 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:755d6e41908c: avcodec/tscc:  Check side data size before use
[18:47:07 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:eaf2f750c356: avcodec/sunrast: Fix input buffer pointer check
[18:47:08 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:04310c11aa39: avcodec/movtextdec: Fix potential integer overflow
[18:47:09 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:096aab12a33f: avcodec/movtextdec: Fix tsmb_size check==0 check
[18:47:10 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:5f3043e51c5b: avcodec/movtextdec: Add error message for tsmb_size check
[18:47:11 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:571d4af28135: avcodec/ituh263dec: Avoid spending a long time in slice sync
[18:47:12 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:936d07ab2548: avcodec/rv40: Test remaining space in loop of get_dimension()
[18:47:13 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:42a20f1feaab: avformat/mpeg: Adjust vid probe threshold to correct mis-detection
[18:47:14 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:ebe104e82771: avformat/utils: Fix type mismatch
[18:47:15 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:60ca730d215a: avformat/idroqdec: Check chunk_size for being too large
[18:47:16 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:0d8a17410b2f: avcodec/flac_parser: Update nb_headers_buffered
[18:47:17 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:cc27b8e09fac: avformat/utils: Check start/end before computing duration in update_stream_timings()
[18:47:18 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:c2e4ced78e61: avformat/oggparsespeex: Check frames_per_packet and packet_size
[18:47:19 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:4a2f30eeff17: avcodec/flacdsp_template: Fix undefined shift in flac_decorrelate_indep_c
[18:47:20 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:140626b386c1: avcodec/flacdec: Fix signed integer overflow in decode_subframe_fixed()
[18:47:21 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:a7c7543a3dc7: avformat/ffmdec: Check media type for chunks
[18:47:22 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:5c1540553db0: avcodec/get_bits: Fix get_sbits_long(0)
[18:47:23 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:f788507607ad: avcodec/flacdec: Fix undefined shift in decode_subframe()
[18:57:47 CET] <cone-511> ffmpeg 03James Almer 07release/3.1:a1d9c1736870: avcodec/rawdec: check for side data before checking its size
[20:29:57 CET] <cone-511> ffmpeg 03Timothy Gu 07master:d903b4e3ad4a: zmqsend: Initialize ret to 0
[20:51:06 CET] <Timothy_Gu> J_Darnley: is it worth it to have AVX versions of the functions?
[20:51:17 CET] <Timothy_Gu> they don't seem to be any faster than SSE2
[20:53:00 CET] <J_Darnley> As you saw, they don't seem to be any faster.  Only a few instructions (buried in the macros) actually use 3-operand form.
[20:54:20 CET] <J_Darnley> Probably not worth it
[20:54:49 CET] <J_Darnley> Except in the unlikely event that some future microarchitecture gimps or removes sse(2)
[20:57:28 CET] <Timothy_Gu> right I'd probably just remove them
[21:22:25 CET] <BBB> J_Darnley: I dont think anyone will ever remove sse2, since you cant write avx without sse2 ;)
[21:22:34 CET] <BBB> J_Darnley: removing mmx is something else :-p
[21:25:36 CET] <BBB> michaelni: you can push them if you want, its faster if you do it than if I rebase and push, I think
[21:25:53 CET] <BBB> michaelni: if you dont mind
[21:29:51 CET] <michaelni> BBB, dunno, it had a few conflicts when backported, i think its better you backport it you know that code much better as you wrote it
[21:30:13 CET] <BBB> I dont have any release branches checked out :/
[21:30:15 CET] <BBB> hmm...
[21:30:50 CET] <cone-511> ffmpeg 03Michael Niedermayer 07master:7d57ca4d9a75: avformat/rtmppkt: Check for packet size mismatches
[21:30:51 CET] <cone-511> ffmpeg 03Michael Niedermayer 07master:a5f27a9c3aa9: Avoid using the term "file" and prefer "url" in some docs and comments
[21:30:52 CET] <cone-511> ffmpeg 03Michael Niedermayer 07master:a5d25faa3f4b: ffserver: Check chunk size
[21:30:53 CET] <cone-511> ffmpeg 03Jun Zhao 07master:f17eea883a6f: lavf: fix the wrong warning msg and comments about av_find_stream_info
[21:32:26 CET] <J_Darnley> BBB: I meant something along the lines of removing the instructions without the VEX prefix.
[21:32:39 CET] <BBB> oh I see
[21:32:41 CET] <J_Darnley> Do you think I should remove the avx?
[21:32:46 CET] <BBB> up to you
[21:33:29 CET] <BBB> Id personally probably remove it
[21:33:34 CET] <BBB> but up to you
[21:34:47 CET] <BBB> michaelni: what kind of conflicts did you see when backporting?
[21:35:52 CET] <BBB> git log is essentially unreadable because of all the merges :(
[21:36:52 CET] <michaelni> i tried to backport your http fix to 2.8 and there were conflicts, maybe its fine for 3.2 didnt try that, i tried 2.8 to see if anything would conflicts
[21:38:50 CET] <BBB> what branches need a backport?
[21:42:07 CET] <michaelni> BBB, the ones corresponding to whats listed on our download page. thats 3.2, 3.1, 3.0, 2.8 (and 2.7), this affects stuff down to 0.6 at least though so more backports are welcome
[21:44:43 CET] <BBB> hm...
[21:45:28 CET] <BBB> how do I see branches on a remote?
[21:48:24 CET] <michaelni> if you type a git command then tab completion after origin/ will list them
[21:48:53 CET] <michaelni> maybe it lists some other stuff too
[21:49:01 CET] <J_Darnley> if your shell knows git, otherwise git branch --all
[21:52:27 CET] <BBB> ls-remote apparently
[21:52:44 CET] <BBB> ok I see the conflicts, will send a fix in a second
[21:52:51 CET] <BBB> Ill do 3.2 to 2.8
[21:53:01 CET] <BBB> I dont think we should bother with 0.6, at some point stuff is unmaitained
[21:53:30 CET] <michaelni> yes, 0.6 is too old
[21:56:32 CET] <BBB> michaelni: 2.8 version http://pastebin.com/J9NgsFwk
[22:03:28 CET] <michaelni> BBB, should be ok with reference to the person reporting the issue and the git hash from where its backported
[22:05:19 CET] <cone-511> ffmpeg 03Timothy Gu 07release/3.1:540a4433bd35: zmqsend: Initialize ret to 0
[22:05:20 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:b0ebef0578fd: avformat/rtmppkt: Check for packet size mismatches
[22:05:21 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:518934b5f1db: Avoid using the term "file" and prefer "url" in some docs and comments
[22:05:22 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:37904d117794: ffserver: Check chunk size
[22:05:31 CET] <BBB> is there a CVE?
[22:06:08 CET] <michaelni> iam not aware of one
[22:06:21 CET] <BBB> Fixes #5992, reported and found by Paul Cher <paulcher at icloud.com>. ?
[22:07:13 CET] <michaelni> shounds good to me
[22:09:08 CET] <BBB> http://pastebin.com/599ipgpm
[22:09:24 CET] <BBB> Do you need a new version of the 3.0-head version?
[22:09:26 CET] <cone-511> ffmpeg 03Mark Thompson 07master:51020adcecf4: vaapi_encode: Write sequence header as extradata
[22:12:00 CET] <michaelni> BBB, you arent pushing any of the fixes ?
[22:12:13 CET] <BBB> I could, but I was hoping you would :-p
[22:12:49 CET] <BBB> want me to?
[22:13:00 CET] <BBB> ok let me re-cherrypick the head version to 3.0-2
[22:13:24 CET] <michaelni> yes, i think its easier if you push them ...
[22:14:34 CET] <BBB> ok, so I have 2.8, 3.0, 3.1, 3.2 and head
[22:14:42 CET] <BBB> master
[22:15:38 CET] <michaelni> ok
[22:16:50 CET] <BBB> oh it doesnt say wat it was cherry-picked from
[22:16:54 CET] <BBB> I thought itd auto-add that...
[22:17:02 CET] <BBB> I guess its obvious from the commit msg...
[22:17:08 CET] <BBB> also the hashes keep changing
[22:17:12 CET] <BBB> is that ok to omit?
[22:17:25 CET] <J_Darnley> That particular feature got changed in some version of git.
[22:18:01 CET] <BBB> hm...
[22:18:15 CET] <michaelni> "git cherry-pick -x" should add the hash
[22:18:35 CET] <michaelni> that is whe charry picking 
[22:21:15 CET] <michaelni> the hashes change when rebasing, it makes only sense to refer to hashes that were pushed (wont be rebased again)
[22:21:39 CET] <BBB> pain
[22:21:44 CET] <BBB> let me push head first then
[22:30:12 CET] <cone-511> ffmpeg 03Timothy Gu 07release/3.0:9c0b2b9d5b55: zmqsend: Initialize ret to 0
[22:30:13 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.0:a5513ae7bc7c: avformat/rtmppkt: Check for packet size mismatches
[22:30:14 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.0:e0d1db72dadf: Avoid using the term "file" and prefer "url" in some docs and comments
[22:30:15 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.0:1768e02a046a: ffserver: Check chunk size
[22:33:55 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07master:2a05c8f813de: http: make length/offset-related variables unsigned.
[22:33:56 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07master:845bb401781e: http: move chunk handling from http_read_stream() to http_buf_read().
[22:42:25 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/3.2:0e0a413725e0: http: make length/offset-related variables unsigned.
[22:42:26 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/3.2:e5be73e178e0: http: move chunk handling from http_read_stream() to http_buf_read().
[22:46:53 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/3.1:18e3e322b36a: http: make length/offset-related variables unsigned.
[22:46:54 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/3.1:ce44100cb02a: http: move chunk handling from http_read_stream() to http_buf_read().
[22:51:06 CET] <michaelni> ok, ill start making the releases
[22:51:26 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/3.0:2e3f0a1c6f39: http: make length/offset-related variables unsigned.
[22:51:27 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/3.0:726faff0aa86: http: move chunk handling from http_read_stream() to http_buf_read().
[22:51:44 CET] <BBB> dont you have a backport to 2.8 to do?
[22:51:59 CET] <BBB> (of the rtmp/ffserver patches)
[22:52:05 CET] <michaelni> i didnt push all my local stuff yet
[22:52:14 CET] <michaelni> also need changelog update
[22:52:20 CET] <michaelni> ill do that
[22:52:26 CET] <BBB> you probably need to push first so I can push 2.8 after you
[22:52:32 CET] <BBB> then you need to fetch it for the release etc.
[22:52:54 CET] <BBB> unless you want me to push 2.8 first, which is fine also
[22:54:47 CET] <michaelni> you can push the http stuff first, it makes no differecne
[22:57:32 CET] <BBB> ok done
[22:57:33 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/2.8:606b21353df7: http: make length/offset-related variables unsigned.
[22:57:34 CET] <cone-511> ffmpeg 03Ronald S. Bultje 07release/2.8:d3fc5c17de03: http: move chunk handling from http_read_stream() to http_buf_read().
[22:57:51 CET] <BBB> anything else needed from me?
[23:02:24 CET] <michaelni> not atm, thanks for the http fix and work. backporting it. Backporting it to older releases in the future would be welcome though
[23:05:33 CET] <cone-511> ffmpeg 03Andreas Cadhalpun 07master:46e75617d970: truemotion1: fix leaking frame on init failure
[23:06:12 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.1:e08b1cf2df8c: Update for 3.1.6
[23:13:21 CET] <cone-511> ffmpeg 03Mathieu Velten 07master:b1f630f1a6b0: avcodec/vp9: move bpp to the shared context for use in hwaccel
[23:13:22 CET] <cone-511> ffmpeg 03Mathieu Velten 07master:49e8e5fc5634: avcodec/vaapi-vp9: add support for profile 2 (bpp > 8)
[23:24:02 CET] <cone-511> ffmpeg 03Mathieu Velten 07n3.1.6:HEAD: avcodec/vaapi-vp9: add support for profile 2 (bpp > 8)
[23:24:22 CET] <cone-511> ffmpeg 03James Almer 07release/2.8:e8dfe3f34ade: configure: check for strtoull on msvc
[23:24:23 CET] <cone-511> ffmpeg 03James Almer 07release/3.0:c1435f9dfb9a: configure: check for strtoull on msvc
[23:24:24 CET] <cone-511> ffmpeg 03James Almer 07release/3.1:a57b701bdc20: configure: check for strtoull on msvc
[23:24:25 CET] <cone-511> ffmpeg 03James Almer 07release/3.2:16aa8c81469c: configure: check for strtoull on msvc
[23:56:02 CET] <cone-511> ffmpeg 03Michael Niedermayer 07release/3.0:b408dba23109: Chagelog: update
[00:00:00 CET] --- Tue Dec  6 2016