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

[burek]

[00:43:17 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:4b17205c7756: swscale/swscale-test: Fix slice height in random reference data creation.
[00:43:19 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:9d230f4666ac: avcodec/aacenc: Check both channels for finiteness
[00:43:19 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:d3cefc271daa: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper()
[00:43:20 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:1a88eef93bd1: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper()
[00:43:22 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:edc7ef376bbe: swscale/x86/rgb2rgb_template: Fix planar2x() for short width
[00:43:23 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:1b6390dd5be9: swscale/swscale: Add some sanity checks for srcSlice* parameters
[00:43:23 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:eb0872335f01: avcodec/tiff: Check subsample & rps values more completely
[00:43:24 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:f6755e5e19eb: avcodec/put_bits: Assert buf_ptr in flush_put_bits()
[00:43:26 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:40e846bb3f8e: avcodec/gif: Fix lzw buffer size
[00:43:26 CET] <cone-305> ffmpeg 03Derek Buitenhuis 07release/2.7:c6ab367dbe73: mov: Add an option to toggle dref opening
[00:43:28 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:6fabd8586599: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get()
[00:43:29 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:4180a83892b4: avformat/img2dec: do not interpret the filename by default if a IO context has been opened
[00:43:30 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:3cd17b9b5c43: avformat/avio: Limit url option parsing to the documented cases
[00:43:31 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:8c2f006d10c7: avformat/img2dec: Use AVOpenCallback
[00:43:31 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:302f11e719cc: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads
[00:43:33 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:974f9d255d28: avcodec/wmaenc: Check ff_wma_init() for failure
[00:43:34 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:874945c7b93e: avformat/avformat: Replace some references to filenames by urls
[00:43:34 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:e229fbf5ce84: avcodec/mpegvideo_enc: Check for integer overflow in ff_mpv_reallocate_putbitbuffer()
[00:43:36 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:965a8bda9422: avcodec/mjpegdec: Check for end for both bytes in unescaping
[00:43:36 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:3c7597f2e9c9: doc/demuxers: Document enable_drefs and use_absolute_path
[00:43:38 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:573a7b4c6706: avformat/concat: Check protocol prefix
[00:43:39 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:197c0f618acf: avformat/libquvi: Set default demuxer and protocol limitations
[00:43:40 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:41f97fe378e3: avformat: Document urls a bit
[00:43:41 CET] <cone-305> ffmpeg 03Paul B Mahol 07release/2.7:d8b37664d524: avcodec/flacenc: fix calculation of bits required in case of custom sample rate
[00:43:42 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:b54b8a628c8b: avutil/opt: check for and handle errors in av_opt_set_dict2()
[00:43:43 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:12f256a729a8: avcodec/jpeg2000dec: More completely check cdef
[00:43:44 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:bbea86d80922: Update for 2.7.6
[00:50:41 CET] <ubitux> https://github.com/Microsoft/FFmpegInterop am i late to the party?
[00:51:52 CET] <wm4> the fuck is this
[01:06:11 CET] <omerjerk> hahaha
[01:07:34 CET] <rcombs> LAV Filters, but for the Win8 media thing?
[01:09:24 CET] <wm4> apparently
[04:38:40 CET] <cone-453> ffmpeg 03Michael Niedermayer 07master:6ffac5d33d33: avcodec/rawdec: Switch to monowhite if there is no palette & bpp=1
[05:14:56 CET] <Timothy_Gu> "This project is licensed from Microsoft under the Apache 2.0 License"
[05:15:24 CET] <Timothy_Gu> is that even legal?
[07:30:27 CET] <rcombs> Timothy_Gu: why not?
[07:30:43 CET] <rcombs> (AFAIK poor phrasing is not illegal)
[07:49:05 CET] <TD-Linux> it's actually quite nice because the Apache 2.0 includes a patent grant
[07:49:42 CET] <TD-Linux> meanwhile, Facebook is off inventing their own broken licenses and patent terms
[07:58:13 CET] <Timothy_Gu> rcombs: oh wait ffmpeg is LGPL
[07:58:35 CET] <rcombs> well, mostly
[07:59:27 CET] <Timothy_Gu> meanwhile, their ffmpeg copy is half a year old
[08:01:28 CET] <Timothy_Gu> and no threading
[08:01:47 CET] Action: Timothy_Gu goes back to lavfilters
[09:29:25 CET] <nevcairiel> michaelni: the hls .m3u8 filename checks breaks opening  URLs like http://www.example.org/stream.m3u8?parameter_here, which isn't that uncommon to have
[11:07:21 CET] <michaelni> nevcairiel, should i revert it or search for ".m3u8?" anywhere in the string ?
[11:24:23 CET] <cone-985> ffmpeg 03Paul B Mahol 07master:0c28aa6ddc88: doc/filters.texi: fix typo in spectrumsynth example
[11:29:49 CET] <durandal_1707> when are API merges going to happen again?
[13:01:22 CET] <cone-985> ffmpeg 03Paul B Mahol 07master:b4af7d68fe14: avcodec/fraps: remove superfluous "Fraps:" from av_log
[13:05:59 CET] <wm4> 6 mats reply in succession
[13:06:11 CET] <wm4> with most of its content being that he doesn't know that git revert exists
[13:20:04 CET] <nevcairiel> some people should just get thrown out of the good of everyones sanity
[13:20:13 CET] <nevcairiel> s/of/for7
[13:30:20 CET] <cone-985> ffmpeg 03Vittorio Giovara 07master:d74961533308: lavc: Move timecode_frame_start to codec private options
[13:30:20 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:9938697c1c11: Merge commit 'd749615333084e62c9fcc480d1ae466369fdf14f'
[13:37:45 CET] <Daemon404> hmmm ubitux ping
[13:38:02 CET] <Daemon404> origins of this 'feature' trace back to a commit you did with a one lien commit message
[13:38:05 CET] <Daemon404> and no other info
[13:38:15 CET] <Daemon404> b1ca5634fdeac3bba8edee8a89e9246e9cb5188f
[13:38:17 CET] <durandal_1707> michaelni: are you going to submit ffmpeg to gsoc this year?
[13:38:56 CET] <Daemon404> ah... it's for ffprobe.
[13:39:33 CET] <Daemon404> ubitux, do you have any samples i can tets
[13:48:21 CET] <Daemon404> lol mp3
[14:20:15 CET] <cone-985> ffmpeg 03Vittorio Giovara 07master:936f0d98f864: lavc: Move rtp_payload_size to codec private options
[14:20:16 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:899e19f1776c: Merge commit '936f0d98f864f9f6bb4f9e5458b78537e146bacd'
[14:25:44 CET] <ubitux> Daemon404: ffmpeg -f lavfi -i testsrc2=d=10:r=30000/1001 -gop_timecode '01:02:03;04' test.mpg
[14:25:53 CET] <ubitux> then ffmpeg -debug pict -i test.mpg -f null -
[14:25:56 CET] <Daemon404> ubitux, there's a patchset on ml
[14:26:00 CET] <Daemon404> if you want to look
[14:29:49 CET] <cone-985> ffmpeg 03Vittorio Giovara 07master:243df1351d2d: lavc: Move {min,max}_prediction_order to codec private options
[14:29:50 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:c86ecdf3f7b0: Merge commit '243df1351d2d928caa084a5704ed783f0b83f072'
[14:30:19 CET] <Daemon404> almost done these tedious API merges
[14:31:40 CET] <ubitux> Daemon404: broadcasters are not going to be happy about the information going away from ffprobe
[14:33:54 CET] <Daemon404> ubitux, it's not
[14:33:59 CET] <Daemon404> it's in show_frames
[14:34:10 CET] <Daemon404> and it was always wrong to have it global
[14:34:12 CET] <Daemon404> it changes per gop
[14:34:19 CET] <ubitux> does it look pretty, or does it look an int64?
[14:34:31 CET] <wm4> ideally AVCodecContext would have no fields at all
[14:34:43 CET] <Daemon404> ubitux, int64, however, it can be special case, if you wish
[14:35:13 CET] <ubitux> yes, and probably a changelog entry if you're willing to break compat
[14:35:13 CET] <Daemon404> i dont buy into the "people will be angry that is obvious wrong thing went away" argument though
[14:35:16 CET] <Daemon404> ok
[14:35:28 CET] <wm4> Daemon404: wrong, people will always be angr<
[14:35:35 CET] <Daemon404> ;p
[14:35:39 CET] <wm4> even if the thing that went away was insane
[14:35:40 CET] <ubitux> well, they can be angry, so far it wasn't available anywhere else
[14:35:44 CET] <wm4> and was replaced with something sane
[14:36:07 CET] <ubitux> i'm not saying it's a wrong move, i'm just saying it will break compatibility instantly
[14:36:38 CET] <wm4> ffprobe should have a "collect info from first frame" mode
[14:36:44 CET] <wm4> which would include things like resolution
[14:36:46 CET] <Daemon404> ubitux, i can leave it in ffprobe under deprecation defines
[14:36:49 CET] <iive> what are you talking about?
[14:36:51 CET] <wm4> instead of relying on libavformat probing it
[14:36:54 CET] <ubitux> Daemon404: that would be great
[14:36:59 CET] <Daemon404> then it will have teh same deprecation period as the old thing itself
[14:37:10 CET] <ubitux> Daemon404: yes, please do this if you can
[14:37:15 CET] <Daemon404> sure.
[14:37:35 CET] <Daemon404> the next commit (2862b63783b5556f7f3fb2d097629bc6879f833a) looks like a massive pain in the butt
[14:38:03 CET] <Daemon404> "This options is only used by huffyuv, ffvhuv, jpegls, mjpeg,
[14:38:04 CET] <Daemon404> mpegvideoenc, png, utvideo."
[14:38:15 CET] <ubitux> yeah i "laugh" at this one
[14:38:31 CET] <Daemon404> ive agreed with all the avctx changes so far
[14:38:35 CET] <Daemon404> this one im a bit iffy about
[14:38:54 CET] <Daemon404> it'll be pain regardless.
[14:39:09 CET] <ubitux> yeah it's a bit like pushing an ideology to the point where it doesn't make sense anymore :X
[14:40:26 CET] <ubitux> saying "very codec specific" when it affects 7 encoders is weird, especially since probably other encoders could use it
[14:40:38 CET] <ubitux> but well :)
[14:41:27 CET] <Daemon404> we'll see what wm4 and nevcairiel thing
[14:44:14 CET] <ubitux> Daemon404: you kept the avctx field assignment under deprecation guards too, right?
[14:44:39 CET] <Daemon404> it is in v2, which i havent sent yet
[14:44:46 CET] <Daemon404> it kind of has to be 
[14:45:50 CET] <ubitux> ffprobe -v warning -show_entries stream=timecode -of flat test.mpg
[14:45:53 CET] <ubitux> if you need to test
[14:46:03 CET] <ubitux> (with the sample generated with the command earlier)
[14:46:10 CET] <Daemon404> ok
[14:51:39 CET] <nevcairiel> Daemon404: what is codec specific about that option is its values, ie. png doesnt share a single option with the others
[14:52:54 CET] <Daemon404> ah
[14:52:55 CET] <Daemon404> ok
[14:53:03 CET] <Daemon404> well ill merge it in a bit
[14:53:09 CET] <Daemon404> its gonna be tedious
[14:59:26 CET] <ubitux> Daemon404: thanks for doing this btw
[15:02:15 CET] <Daemon404> this == ?
[15:02:57 CET] <wm4> merging
[15:03:27 CET] <Daemon404> o ok
[15:06:51 CET] <Daemon404> good thing i tested
[15:06:53 CET] <Daemon404> (gdb) print (*s).current_picture_ptr
[15:06:53 CET] <Daemon404> $3 = (Picture *) 0x0
[15:07:03 CET] <Daemon404> hmm.
[15:07:18 CET] <Daemon404> so there is no picture at the time of decoding the gop header.
[15:11:05 CET] <Daemon404> ah there we go...
[15:18:02 CET] <wm4> is that the new decoder?
[15:18:28 CET] <nevcairiel> yes
[15:18:45 CET] <wm4> that guy sure is fast
[15:29:27 CET] <Daemon404> i dont know how he finds thiss tuff
[15:29:52 CET] <wm4> or why?
[15:33:10 CET] <nevcairiel> fuzzing isnt exactly hard =P
[15:36:01 CET] <ubitux>  [cfhd @ 0x4a5f420] Sample format of 259 is unsupported
[15:36:03 CET] <ubitux>  [cfhd @ 0x4a5f420]  is not implemented. Update your FFmpeg version to the
[15:36:06 CET] <ubitux> ugly formating
[15:37:07 CET] <Daemon404> ubitux, new patchset sent
[15:45:57 CET] <wm4> durandal_1707: so how do I tell a buffersink that it should not accept anymore frames?
[15:46:09 CET] <wm4> sort of like EOF
[15:46:49 CET] <wm4> normal filters apparently can do it by having av_buffersrc_add_frame() return AVERROR_EOF
[16:30:12 CET] <durandal_1707> wm4: IIRC no way
[16:46:57 CET] <nevcairiel> Daemon404: did you break fate
[16:47:11 CET] <Daemon404> not afaik...
[16:47:19 CET] <nevcairiel> lavf-ffm is not happy
[16:48:08 CET] <Daemon404> ... the only stuff i merged was soem avctx field stuff for mpeg timecodes and rtp payload
[16:48:15 CET] <Daemon404> and pred order
[16:48:22 CET] <Daemon404> wtf would ffm need with that
[16:48:38 CET] <nevcairiel> some metadata that it lost along the way?
[16:48:49 CET] <wm4> unintended interaction with features you never heard of!
[16:49:49 CET] <nevcairiel> it uses mpeg1 encoding i think
[16:50:11 CET] <Daemon404> ... and why would only ffm be hit
[16:50:25 CET] <nevcairiel> those commits like to "lose" default parameters sometiems =p
[16:51:00 CET] <Daemon404> let's see..
[16:52:17 CET] <Daemon404> i think i see it
[16:52:21 CET] <wm4> durandal_1707: is there a filter that always send EOF?
[16:52:23 CET] <Daemon404> and here i thought i caught them all
[16:52:26 CET] <Daemon404> since i fixed liek 4 of them
[16:52:27 CET] <Daemon404> -_-
[16:53:11 CET] <Daemon404> nevcairiel, it's veyr bizzarre that only ffm would be hit though
[16:53:15 CET] <Daemon404> and you know
[16:53:18 CET] <Daemon404> not mpeg1 tests
[16:53:30 CET] <Daemon404> which i rnas
[16:53:33 CET] <Daemon404> ran*
[16:53:35 CET] <nevcairiel> ffm uses a crc of the output file, maybe the others test differently
[16:53:43 CET] <nevcairiel> personally i tend to run full fate =p
[16:53:50 CET] <Daemon404> i think the ps option changed from DEFAULT to 0
[16:53:54 CET] <Daemon404> assumign DEFAULT is not 0
[16:54:11 CET] <Daemon404> running a ufll fate for every single commit seems utterly insane to me
[16:54:14 CET] <Daemon404> :/
[16:54:38 CET] <Daemon404> 90% of these are broken in libav too, but they dont have tests
[16:54:39 CET] <Daemon404> quality.
[16:54:52 CET] <nevcairiel> i warned you about koda refactoring
[16:55:05 CET] <Daemon404> [15:52] <@Daemon404> and here i thought i caught them all
[16:55:05 CET] <Daemon404> [15:52] <@Daemon404> since i fixed liek 4 of them
[16:55:05 CET] <Daemon404> [15:52] <@Daemon404> -_-
[16:57:37 CET] <Daemon404> no that wasnt it
[16:57:39 CET] <durandal_1707> wm4: nope
[16:58:21 CET] <Daemon404> nevcairiel, how new is this breakage
[16:58:24 CET] <wm4> man I have no idea how not to stall this damn libavfilter thing if one stream just has n input
[16:58:24 CET] <wm4> *no
[16:58:43 CET] <durandal_1707> what changed in ffm output?
[16:59:10 CET] <Daemon404> trying to figure that out
[16:59:52 CET] <durandal_1707> wm4: sources?, ah you receive unlimited frames? :)
[17:00:33 CET] <nevcairiel> Daemon404: ffm is literally evil
[17:00:44 CET] <nevcairiel> it encodes codec configuration
[17:00:54 CET] <nevcairiel> including timecode_frame_start=0
[17:00:58 CET] <nevcairiel> which vanishes now =p
[17:01:01 CET] <nevcairiel> not sure why it does
[17:01:03 CET] <nevcairiel> but it does
[17:01:57 CET] <nevcairiel> ah because 0 was not the default
[17:02:06 CET] <Daemon404> what the fuck?
[17:02:11 CET] <nevcairiel> -1 is the default
[17:02:18 CET] <Daemon404> -1 should still be default
[17:02:26 CET] <Daemon404> i made sure it was the same
[17:02:38 CET] <nevcairiel> the point is, the mpeg1encoder changed the value in the context to 0
[17:02:47 CET] <nevcairiel> so it was no longer equal to the default
[17:02:51 CET] <nevcairiel> so it got written to the file
[17:03:30 CET] <Daemon404> something isnt right then
[17:03:34 CET] <Daemon404> it shouldnt change it
[17:03:58 CET] <nevcairiel> cant fix previous versions of the code
[17:03:59 CET] <Daemon404> behvior looks the same..
[17:04:00 CET] <nevcairiel> it did
[17:04:07 CET] <Daemon404> ah
[17:04:09 CET] <Daemon404> i see it...
[17:04:10 CET] <Daemon404> i think?
[17:04:19 CET] <Daemon404>      } else {
[17:04:19 CET] <Daemon404> -        s->avctx->timecode_frame_start = 0; // default is -1
[17:04:19 CET] <Daemon404> +        s->timecode_frame_start = 0; // default is -1
[17:04:20 CET] <Daemon404>      }
[17:04:25 CET] <Daemon404> but this would mean it was always 0
[17:04:36 CET] <Daemon404> and now it isnt
[17:05:28 CET] <Daemon404> oh it vanishes because it *wasnt* default before... classy
[17:05:37 CET] <nevcairiel> in any case, you can just push an update to fate with the new ref
[17:05:43 CET] <nevcairiel> thats the only difference in the file
[17:05:52 CET] <Daemon404> yes
[17:06:00 CET] <Daemon404> it sitll boggles my mind why ffms would do that
[17:06:16 CET] <nevcairiel> no idea, its ffserver crap, who knows why it does anything
[17:06:28 CET] <JEEB> iä iä ffserver the usual
[17:06:29 CET] <nevcairiel> its not too crazy of an idea to write out all options that are non-default, i guess
[17:07:33 CET] <Daemon404> [15:48] <+wm4> unintended interaction with features you never heard of!
[17:07:35 CET] <Daemon404> ^
[17:07:54 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:b552f3afa2a7: fate/ffm: Update test ref
[17:08:16 CET] <Daemon404> why is this PAL8 trhead so long
[17:08:27 CET] <Daemon404> i get a mail ever few minutes in it
[17:08:31 CET] <Daemon404> and all of it is noise
[17:08:35 CET] <nevcairiel> because that mats guy posts 10 mails instead of thinking more than 10ms
[17:10:21 CET] <durandal_1707> consider marking his mails as spam
[17:12:37 CET] <Daemon404> im very close to the end of this wave of refactorings... i can see the light
[17:12:41 CET] <Daemon404> should be smoother after
[17:14:15 CET] <cone-985> ffmpeg 03foo86 07master:46089967722f: avcodec/dca: remove old decoder
[17:14:16 CET] <cone-985> ffmpeg 03foo86 07master:64f6d17b405b: avcodec/dca: add REV1AUX sync word
[17:14:17 CET] <cone-985> ffmpeg 03foo86 07master:9a0a3bbeaaf4: avcodec/dca: add more tables
[17:14:18 CET] <cone-985> ffmpeg 03foo86 07master:4a53b83691ac: avcodec/dca: add math helpers and fixed point DCT
[17:14:19 CET] <cone-985> ffmpeg 03foo86 07master:8984806a510b: avcodec/synth_filter: fix whitespace
[17:14:20 CET] <cone-985> ffmpeg 03foo86 07master:5b1b536e2b7c: avcodec/synth_filter: add more filters
[17:14:21 CET] <cone-985> ffmpeg 03foo86 07master:0930b2dd1f01: avcodec/dca: add generic defines
[17:14:22 CET] <cone-985> ffmpeg 03foo86 07master:ae5b2c52501d: avcodec/dca: add new decoder based on libdcadec
[17:14:35 CET] <nevcairiel> (in before someone whines about lack of real names)
[17:14:53 CET] <Daemon404> some guy name popcorn is getting pushed soon... so..
[17:14:58 CET] <Daemon404> named*
[17:15:06 CET] <nevcairiel> some people still keep whining
[17:15:14 CET] <JEEB> nice
[17:15:19 CET] <Daemon404> i think it's crappy myself, too
[17:15:23 CET] <Daemon404> but i have 0 power here, so.
[17:15:39 CET] <JEEB> (nice at the new dcadec
[17:18:16 CET] <wm4> Daemon404: at least that guy is relatively well known in the rpi and xbmc community
[17:20:54 CET] <kierank> J_Darnley: so h264 patch, is it pushable?
[17:21:42 CET] <J_Darnley> Oh shit.  Thanks for the reminder
[17:21:59 CET] <J_Darnley> I made a couple of changes so I should probably post the list again.
[17:22:10 CET] <fritsch> that popcorn guy is one of the rpi founders :-)
[17:22:44 CET] <fritsch> writing the rpi firmware and kodi
[17:56:42 CET] <JEEB> hmm, did this work before? https://gist.github.com/andrey-utkin/c6fb55bb3e13faf82fbe
[18:01:58 CET] <Daemon404> it looks like it should
[18:02:28 CET] <JEEB> well with current libx264 defaults that shouldn't happen
[18:02:48 CET] <JEEB> that stuff is for the default that got overridden in like 2011 or so
[18:02:55 CET] <JEEB> also someone says it used to work in 2.8.x
[18:03:38 CET] <Daemon404> wait.. what is being run here
[18:03:45 CET] <Daemon404> the cli or the transcoding example
[18:03:58 CET] <JEEB> both, ffmpeg is for creation of the input
[18:04:07 CET] <Daemon404> which one is erring then
[18:04:09 CET] <JEEB> and then the transcoding example is used for the crap done afterwards
[18:04:15 CET] <JEEB> the transcoding example
[18:04:25 CET] <Daemon404> then i have no idea.
[18:04:47 CET] <JEEB> it's as if avcodec's libx264 defaults just went back a few years 
[18:05:53 CET] <Daemon404> i cant tell WHAT is wrong
[18:05:59 CET] <Daemon404> the error message is the most useless thing ever
[18:07:02 CET] <JEEB> IIRC libx264 checks against (at least some) params that FFmpeg used to set up until 2011 or so
[18:07:10 CET] <JEEB> back when all encoders had the same defaults
[18:07:40 CET] <Daemon404> well ffmpeg cli would fail rtoo if defaults were the problem.
[18:08:11 CET] <JEEB> well ffmpeg cli can be a special snowflake. could just be an error in the example
[18:08:18 CET] <JEEB> which was brought up by something that came up lately
[18:09:52 CET] <BBB> ffmpeg cli is a snowflake for sure
[18:11:01 CET] <Daemon404> looking at the x264 code theres no way it shoild trip that
[18:11:16 CET] <Daemon404> can you repro it?
[18:11:34 CET] <JEEB> I'll try after I've finished my chinese cartoons for the day
[18:11:58 CET] <JEEB> and yes, in any usual case you wouldn't be tripping that thing
[18:24:24 CET] <durandal_1707> I get red text when encoding flac
[18:27:39 CET] <jkqxz> wm4:  I was trying to conform to the documented convention that the argument to av_log() is a "pointer to an arbitrary struct of which the first field is a pointer to an AVC lass struct" (where the arbitrary struct is context-meaningful).  Once that is discarded then whatever, it's just a const AVClass**.
[18:28:18 CET] <jkqxz> And AVVAAPIHardwareContext is deliberately compatible with (that is, usable as) struct vaapi_context, with extra fields at the end.
[18:28:33 CET] <nevcairiel> should really use NULL instead of inventing a new context
[18:28:55 CET] <wm4> jkqxz: then maybe it shouldn't do that
[18:29:04 CET] <wm4> make vaapi_context a simple field
[18:29:55 CET] <jkqxz> Then you lose the backward-compatibility with existing users of the VAAPI decoders.
[18:32:26 CET] <wm4> jkqxz: no, it just means you can't use the pointers interchangeably
[18:35:59 CET] <durandal_1707> Daemon404: try encode flac, red text appear
[18:36:28 CET] <wm4> red text is a feature
[18:36:33 CET] <wm4> it looks cooler
[18:44:31 CET] <jkqxz> wm4:  How do you do the later upgrade to add correct locking to the decoders, in that case?
[18:44:34 CET] <J_Darnley> Red text?  Error messages (or worse)?
[18:45:12 CET] <wm4> jkqxz: there needs to be a second context pointer in the codeccontext I guess
[18:45:23 CET] <jkqxz> Without the structure compatibility everything has to change simultaneously.
[18:46:35 CET] <Daemon404> J_Darnley, if it was an error, fate would fail.
[18:46:37 CET] <Daemon404> it doesn't.
[18:46:44 CET] <jkqxz> Oh, hwaccel_context2 in AVCodecContext?  I guess that also works.
[18:49:35 CET] <wm4> jkqxz: maybe we should wait for that Libav patch? it also adds a new context
[18:49:37 CET] <durandal_1707> gonna fix it?
[18:50:15 CET] <J_Darnley> What?  There's no atestsrc?
[18:52:06 CET] <wm4> there are some simple sources
[18:52:31 CET] <Daemon404> i can only move so fast, while all i hear is https://www.youtube.com/watch?v=1Isjgc0oX0s
[18:52:36 CET] <J_Darnley> Oh I was looking in the wrong section of the list.
[18:57:35 CET] <durandal_1707> Daemon404: LOL
[19:01:05 CET] <Daemon404> trying to figure out wtf happened
[19:01:16 CET] <Daemon404> slowed down by builds.
[19:01:46 CET] <wm4> jkqxz: so how does your patch distinguish a sole vaapi_context, and one embedded in a hw ctx?
[19:05:16 CET] <jkqxz> I was hoping that a delay for users to transition would be sufficient to avoid the problem (deprecate user-instantiated struct vaapi_context, wait).  If they have to exist simultaneously then some magic numbers set by the allocation function could be added.
[19:07:34 CET] <wm4> so you have this problem either way
[19:10:36 CET] <Daemon404> as yes of course
[19:10:44 CET] <Daemon404> it was of course broken in libav and fixed later
[19:10:47 CET] <Daemon404> of course.
[19:10:56 CET] <Daemon404> every damn commit has to be broken
[19:10:57 CET] <Daemon404> and fixed later
[19:11:48 CET] <wm4> seems like the reviews on the Libav side are pretty worthless, despite being strict
[19:11:58 CET] Action: JEEB pats Daemon404 
[19:14:33 CET] <jkqxz> wm4:  Ok.  The backward compatibility is not relevant to me, so I am happy to change to do what you say.
[19:15:11 CET] <wm4> my main problem here is that the planned change in Libav will change everything again
[19:16:34 CET] <Daemon404> oh my bad
[19:16:38 CET] <Daemon404> it's *still* broken in avconv.
[19:26:51 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:e9eb8b3ba253: flacenc: Restore defaults and range for {min,max}_prediction_order
[19:26:54 CET] <Daemon404> durandal_1707, ^
[19:26:56 CET] <Daemon404> sigh
[19:27:08 CET] <Daemon404> he made the default value out of range
[19:38:57 CET] <nevcairiel> i complained about that patch a couple times and he still didnt get it right
[19:38:58 CET] <nevcairiel> oh well
[20:14:59 CET] <cone-985> ffmpeg 03Michael Niedermayer 07master:3c8e95ab5da5: avcodec/flacenc: Fix prediction_order parameter
[20:22:48 CET] <Daemon404> michaelni, can you expland on 3c8e95ab5da5a1e5ada0379020911d99efe48534 a bit
[20:23:06 CET] <Daemon404> -1 was the default in the past
[20:23:39 CET] <Daemon404> and that bit wasnt touched
[20:23:59 CET] <michaelni> yes, -1 or when the user explicityl set a value then that value, the code then overwrites either before my commit
[20:24:29 CET] <Timothy_Gu> ubitux: http://coverage.ffmpeg.org/ seems to be down
[20:24:39 CET] <michaelni> previously the users value was in avcodec context so wasnt overwritten
[20:26:51 CET] <Daemon404> staring a bit longer... urg
[21:50:46 CET] <wm4> kierank: you did see these, right? ^
[21:51:22 CET] <durandal_1707> he is drinking, leave him alone
[22:15:31 CET] <cone-985> ffmpeg 03Henrik Gramner 07master:58313f2dda0a: msvc: Fix libx264 linking
[22:18:37 CET] <cone-985> ffmpeg 03Paul B Mahol 07master:4ab4793c155e: avfilter/avf_showfreqs: properly handle pts
[22:25:31 CET] <kierank> wm4: on the train
[22:25:34 CET] <kierank> can only look now
[22:26:25 CET] <wm4> just so that you don't miss it
[23:02:23 CET] <jya> is there an official schedule on the next official release ?
[23:06:46 CET] <JEEB> jya: nope
[23:07:18 CET] <JEEB> releases are something somewhat random since they're generally only made for distros and such that seem to require a "release"
[23:19:28 CET] <jya> JEEB: Firefox 46 will be using the current master. but I would have much preferred to follow a "2.9" or something
[23:20:04 CET] <jya> Ubuntu 16.04 freeze is soon too.
[23:20:17 CET] <jamrial> 2.9 is supposedly going to be made soon
[23:20:36 CET] <jya> so it will ship with 2.8 unless things are released soon
[23:20:42 CET] <JEEB> would make sense as we got the AAC encoder and dcadec replacement in
[23:20:44 CET] <jya> jamrial: good to know
[23:21:09 CET] <jya> (stable release make cherry-picking changes much easier)
[23:34:22 CET] <durandal_170> it should be 3.0
[23:39:13 CET] <Compn> it should be versioning based on dates, otherwise we are going to be at ffmpeg 40 in a year or three :P
[23:39:23 CET] Action: Compn runs
[23:41:19 CET] <nevcairiel> Compn: everyone does that these days, so why not
[23:50:44 CET] <jya> what's wrong with version 40 ?
[23:51:08 CET] <Compn> whats wrong with version $date ?
[23:51:23 CET] <jya> date format of which country ? :)
[23:52:40 CET] <iive> there are other countries?
[23:52:48 CET] <nevcairiel> version inflation in many projects seems kinda silly, especially when some things just seem to do it to follow a trend, ie. chrome started it, firefox had to follow =p
[23:57:56 CET] <nevcairiel> these days even gcc does it
[23:59:46 CET] <Timothy_Gu> jamrial: I wanted to use the native-sized regs for everything but then I saw the gcc disass used this mixture of reg sizes
[00:00:00 CET] --- Mon Feb  1 2016