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

[burek]

[00:00:53 CEST] <cone-672> ffmpeg 03Pedro Arthur 07master:f67aff3ad716: swscale: added proper error check for ff_init_filters
[00:00:54 CEST] <cone-672> ffmpeg 03Pedro Arthur 07master:3059562aa19a: swscale: re-enable gamma
[00:11:30 CEST] <durandal_170> whats libsound?
[00:11:56 CEST] <wm4> audio output wrapper lib
[00:12:13 CEST] <wm4> does wasapi (windows), coreaudio (osx), and alsa/pulse
[00:12:20 CEST] <cone-672> ffmpeg 03Arnaud Bienner 07master:fd6b38bed781: lavf/riff: Support fourcc AVd1 for dvvideo.
[00:12:21 CEST] <cone-672> ffmpeg 03Arnaud Bienner 07master:35ab967f52ec: lavf/mxf: Support video essence container uls for vc1.
[00:12:22 CEST] <cone-672> ffmpeg 03Arnaud Bienner 07master:0cdba4ac6806: lavf/mxfdec: Support more codecs in mxf_picture_essence_container_uls[].
[00:48:09 CEST] <cone-672> ffmpeg 03Michael Niedermayer 07master:205c31b30186: avcodec/hapdec: Check section_size for non negativity in parse_section_header()
[00:48:10 CEST] <cone-672> ffmpeg 03Michael Niedermayer 07master:9e704755515f: avcodec/jpeg2000dec: Assert that step_x/y are valid
[00:48:11 CEST] <cone-672> ffmpeg 03Michael Niedermayer 07master:a87ada53c39c: avcodec/jpeg2000dec: Initialize ret to avoid warning and make the code more robust
[01:16:00 CEST] <michaelni> BBB, coverity found a potential issue in vp9 (1322309) Unchecked return value
[01:20:56 CEST] <BBB> got a link?
[01:21:45 CEST] <BBB> also, do we have a way of md5ing individual frames in scalable codecs without invoking any part of sws?
[01:22:04 CEST] <BBB> like, I just want to get the raw yuv frames as they come out of the decoder, I dont care how. how do I do that?
[01:29:02 CEST] <michaelni> framemd5, or am i missing something ?
[01:30:22 CEST] <nevcairiel> that goes through ffmpeg.c, doesn it? which would mean it scales to one size at all times
[01:30:36 CEST] <BBB> framemd5 scales
[01:30:44 CEST] <BBB> and does jpeg range correction also if that changes within the sequence
[01:30:48 CEST] <BBB> and many other things
[01:31:37 CEST] <BBB> why does ff_thread_release_buffer have a return value?
[01:31:41 CEST] <BBB> what is that good for
[01:31:43 CEST] <nevcairiel> maybe kierank's student can use her test tools for that?
[01:32:15 CEST] <BBB> oh its ref_frame
[01:32:17 CEST] <BBB> hm...
[01:32:18 CEST] <BBB> ok
[01:32:22 CEST] <BBB> michaelni: will fix
[01:32:23 CEST] <BBB> sorr
[01:33:36 CEST] <BBB> michaelni: fixed
[01:33:50 CEST] <BBB> nevcairiel: I feel that ffmpeg should support scalable input also
[01:34:06 CEST] <BBB> if my output format (be that vp9 or framemd5) supports scalable input, I should be able to use that feature
[01:34:12 CEST] <BBB> maybe not by default, but at least as an option
[08:00:39 CEST] <y2k> in a demuxer, I have a packet (and not a frame read via av_read_frame), this is why pkt->pts, and pkt->dts values are not correct. is their a way to use av_read_frame (or something similar) on exiting data in memory (or a packet)?
[10:14:10 CEST] <cone-626> ffmpeg 03Rostislav Pehlivanov 07master:4565611b04d5: aacenc_is: add a flag to use pure coefficients instead
[10:14:10 CEST] <cone-626> ffmpeg 03Rostislav Pehlivanov 07master:7591f8319b06: lpc: increase error array size of ff_lpc_calc_ref_coefs_f by one
[10:14:10 CEST] <cone-626> ffmpeg 03Rostislav Pehlivanov 07master:e3faad811e42: aacenc_tns: adjust coefficient calculation, add double filter support
[10:14:10 CEST] <cone-626> ffmpeg 03Rostislav Pehlivanov 07master:5ab3b6a8a53d: fate: adjust AAC encoder TNS test target
[10:55:10 CEST] <cone-626> ffmpeg 03Carl Eugen Hoyos 07master:da8eb70dc3fc: lavf/aiffenc: Clarify an error message.
[11:52:23 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:5d859e59809f: avfilter/avfilter: Add a few more basic filters to the list which support frame size changes
[12:43:27 CEST] <nevcairiel> its fascinating when you check the libs for stuff that gets disabled in the bump and you can remove, and you find something that was disabled in the previous bump but then never removed
[12:43:30 CEST] <nevcairiel> more code to clean!
[12:45:57 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:c41a59330f49: avcodec/rawenc: Use AVFrame parameters instead of AVCodecContext
[12:48:40 CEST] <michaelni> BBB, with "-reinit_filter 0" you should get non-scaled frames from input to output if there is no filter which equalizes the dimensions
[12:49:18 CEST] <BBB> I see youve been busy :-p
[12:49:19 CEST] <BBB> thanks
[12:49:22 CEST] <BBB> let me try
[12:53:49 CEST] <nevcairiel> what was the preferred order of bumping things? follow the libav model, ie. drop deprecated blocks one by one before the bump, for better bisecting later, i guess?
[12:56:44 CEST] <BBB> thats what andreas/michael suggested, yes
[12:56:58 CEST] <nevcairiel> well then
[12:57:11 CEST] <BBB> did people ever agree to drop ab from the options table?
[12:57:12 CEST] <nevcairiel> i'll finish merging the libav removals and then see what is left to remove
[12:57:15 CEST] <BBB> I still have that patch
[13:00:30 CEST] <iive> nevcairiel: that won't work for xvmc, be careful.
[13:00:39 CEST] <wm4> y2k: explain again what you try to achieve
[13:01:02 CEST] <wm4> y2k: there's a mp3 extension that stores chapters using frame numbers as timestamps?
[13:01:30 CEST] <nevcairiel> linux hwaccels are annoying anyway, i cant even build-test them :)
[13:01:41 CEST] <nevcairiel> but apparently vdpau got postponed anyway
[13:02:04 CEST] <nevcairiel> as did xvmc
[13:02:14 CEST] <iive> heh...
[13:03:54 CEST] <wm4> what was postponed?
[13:04:13 CEST] <nevcairiel> https://git.libav.org/?p=libav.git;a=commitdiff;h=4e649debcf7f71d35c6b38cdb7ee715eba95d64a all in there :p
[13:04:16 CEST] <BBB> michaelni: I thought I fixed them all?
[13:04:32 CEST] <BBB> michaelni: why does adding AVFMT_NOTIMESTAMPS not disable the timestamp order checks?
[13:04:41 CEST] <wm4> the hell...
[13:04:49 CEST] <BBB> I get warnings like this Application provided invalid, non monotonically increasing dts to muxer in stream 0: 9 >= 9 with md5, but not framemd5
[13:05:13 CEST] <nevcairiel> i ran into that before as well, somehow the flag doesnt disable that
[13:05:29 CEST] <BBB> michaelni: and that seems to be b/c of the NOTIMESTAMPS flag, if I remove that and add the ones from framemd5, the warning goes away
[13:05:52 CEST] <BBB> nowadays I typically run a build where that return AVERROR(EINVAL) after that warning is commented out
[13:06:02 CEST] <BBB> its just so hard to get actual decoder work done with ffmpeg.c
[13:08:20 CEST] <y2k> wm4, hi! I am trying to add support for chapters in a demuxer. the demuxer only knows about packets (it doesn't have frame information). I am trying to calculate the temporal offsets of the chapters. hopefully this makes better sense.
[13:08:37 CEST] <BBB> shall I submit a patch to change the md5 flags to those of framemd5?
[13:08:43 CEST] <BBB> I dont know if that has side effects
[13:09:31 CEST] <y2k> but the packet dts, pts, and duration values are all missing. to I have to convert the packet into frame(s) within the demuxer itself to get good pts, dts, and duration values?
[13:09:51 CEST] <y2k> s/to I have/do I have
[13:09:59 CEST] <wm4> y2k: which demuxer?
[13:10:28 CEST] <JEEB> sounds like your container has absolutely no timestamps :P
[13:10:50 CEST] <JEEB> (yet it would have for chapters!?)
[13:11:42 CEST] <y2k> JEEB, Yes, exactly right! the data stream has only markers which tell you that a chapter has started.
[13:11:59 CEST] <y2k> JEEB, and it has no timestamps (like you said).
[13:12:08 CEST] <y2k> (the underlying codec is mp3)
[13:13:30 CEST] <JEEB> so it's just extra shit in raw mp3?
[13:14:08 CEST] <y2k> JEEB, yes, raw mp3 is obfuscated a bit, and the chapters have a small header at the beginning. 
[13:15:02 CEST] <JEEB> well you're pretty much dicked if there are no timestamps on the container level at all. I guess it's crap like song changes in a web stream or something
[13:15:07 CEST] <y2k> curiously enough, ffprobe -dump_packets is able to get correct dts, pts, and duration ... but I am guessing that internally it does frame decoding and what not (I really don't know this stuff) :)
[13:15:08 CEST] <JEEB> where the overall position doesn't matter
[13:15:15 CEST] <michaelni> encoding 2 frames with identical timestamps is not really correct, framemd5 prints the actual timestamps in the output so one sees the problem, md5 would not
[13:15:32 CEST] <JEEB> yes, ffprobe if it shows audio packets those are decoded
[13:15:47 CEST] <JEEB> mp3 has no way of knowing exact timestamps without decoding
[13:15:52 CEST] <BBB> michaelni: right, but sometimes I just want to get the md5 of the file, not for ffmpeg to tell me I cannot do that
[13:16:06 CEST] <michaelni> BBB, yes i agree that makes sense
[13:16:09 CEST] <JEEB> which is why many music players resort to decoding the whole clip first to get the full length as well as make it possible to seek at all :P
[13:16:42 CEST] <michaelni> maybe some user option could be used to ignore this ts poblem
[13:17:34 CEST] <y2k> JEEB, I see! ;( ... can I patch ffplay's next chapter "button" to flush the current mp3 buffer, and move to a new *data offset* in the underlying file?
[13:18:33 CEST] <y2k> JEEB, is the ffmpeg's chapter API extensible in this fashion? (jump to a new data offset instead of trying to muck around with timestamps).
[13:18:51 CEST] <BBB> michaelni: I think it would the most popular option for developers
[13:18:53 CEST] <y2k> this would solve the problem very nicely
[13:18:58 CEST] <BBB> michaelni: maybe we could merge it with -vsync 0?
[13:20:08 CEST] <michaelni> yes that sounds like an option
[13:21:17 CEST] <michaelni> but thinking again, some users of -vsync 0 might want to know if there are faulty ts 
[13:21:33 CEST] <JEEB> y2k: nfi really. chapters are generally a timestamp thing
[13:21:56 CEST] <nevcairiel> could write an index entry with the byte position and the timestamp of the chapter, hoping that the seek function uses that
[13:22:57 CEST] <y2k> JEEB, ok ;(  .. well it seems ffprobe + grep is the way to go then, LOL
[13:23:23 CEST] <y2k> ffprobe is pretty fast, and accurate in itself.
[13:24:27 CEST] <wm4> <JEEB> mp3 has no way of knowing exact timestamps without decoding <- actually, parsing the frames is enough, and that's what libavformat does
[13:26:07 CEST] <y2k> wm4, I can't use avfromat_read_frame (since I have to deobfuscate the underlying data first), all I have is packets (I memcpy deobfuscated data into the packets). how do I get frames from a packet? 
[13:26:54 CEST] <wm4> use a parser manually to determine byte length, samplerate and sample count of a packet
[13:27:51 CEST] <y2k> I am pretty new to this stuff - is there an existing demuxer / code where I can see this in action?
[13:29:35 CEST] <wm4> the mp3 parser itself is pretty simple: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mpegaudio_parser.c;h=7849fed649b74c996326b15a78097591e9809a01;hb=HEAD
[13:29:54 CEST] <wm4> so you don't need to use the parser API, but could just call avpriv_mpa_decode_header2() yourself
[13:32:23 CEST] <y2k> wm4, cool, I will give it a try :)
[14:23:46 CEST] <BBB> michaelni: I get a bus error when using -reinit_filter 0 in combination with per-plane output files (file-%d.Y)
[14:25:10 CEST] <BBB> (I believe bus error is macs version of a segfault)
[14:26:00 CEST] <nevcairiel> so much code to delete
[14:26:28 CEST] <BBB> isnt that the fun part?
[14:26:57 CEST] <nevcairiel> .. and i'm still in the process of merging the remvoals from libav, there will be a bunch more which only exists in ffmpeg i'm sure
[14:27:55 CEST] <nevcairiel> (also, i'm glad i got a fancy 6-core cpu last year)
[14:36:43 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:4eca1939ef06: avformat/hls: Check for av_opt_set_dict() failure
[14:41:22 CEST] <y2k> wm4, how does avpriv_mpa_decode_header2() help in getting a timestamp / duration of a packet? I already know the properties (frame size, bitrate, etc) of the underlying mp3 stream. I just can't calculate timestamps corresponding to data offsets.
[15:05:45 CEST] <wm4> y2k: a frame has a specific number of samples, so you know the duration of a frame
[15:06:21 CEST] <wm4> and if you assume the file starts from timestamp 0, you just need to sum up the duration to get the timestamp
[15:22:49 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:7eab904d11de: avfilter/vf_stack: Fix memleak of out frame
[15:22:50 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:a3ad51e0d5b3: avfilter/af_amerge: avoid undefined shift (<<64) in outlayout setup
[15:34:48 CEST] <wm4> durandal_1707: aren't you always looking for new filters to add? it appears more than 0 users like the mplayer af_extrastereo and af_export filters
[15:38:08 CEST] <durandal_1707> huh, vf_export?
[15:45:24 CEST] <wm4> no, af_
[15:47:50 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:7213d3fbf30b: avfilter/avf_showfreqs: Free fin
[15:47:51 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:0ada8ec1a50c: avfilter/avf_showfreqs: Fix "may be used uninitialized in this function" warning
[15:47:52 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:8ca97b5e4f47: avfilter/avf_showfreqs: Fix memleak of out frame
[15:48:01 CEST] <durandal_1707> for what it is used?
[15:48:09 CEST] <wm4> good question
[15:48:15 CEST] <wm4> apparently GUIs doing audio visualozation
[15:50:46 CEST] <nevcairiel> why is git incapable of rebasing merge commits, thats f'ing annoying
[15:50:57 CEST] <nevcairiel> i cant finish a large merge without anyone else commiting in between =p
[15:51:45 CEST] <nevcairiel> guess i'll just merge my working branch when i'm done
[15:54:08 CEST] <BBB> just tell people to not commit
[15:54:41 CEST] <michaelni> one way to reduce the  work is to test+push more frequently
[15:55:06 CEST] <nevcairiel> i usually do that, but with the deprecation removal it seemed like a better choice to collect all of it
[15:57:32 CEST] <nevcairiel> but i guess if we consider the ABI/API unstable for the next days anyway I could start pushing them individually instead
[15:59:33 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:9d58639e270f: sws: Drop deprecated SWS_CPU_CAPS defines
[15:59:34 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:cebe51a6255e: Merge commit '9d58639e270f7612874681e0ca30fa461e2667b7'
[16:00:14 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:11b2eed43e91: lavr: Drop deprecated context reinitialization if resampling was not enabled
[16:00:15 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:e2adb00ec587: Merge commit '11b2eed43e91b35b8295ed47115cae2e29bd687d'
[16:07:23 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:86e5056575f5: lavfi: Drop deprecated public AVFilterPad struct
[16:07:24 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:2751d5f0ba2e: Merge commit '86e5056575f55f070609dd3926605302f7d2280e'
[16:12:10 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:e65e4cbbda03: lavfi: Drop deprecated *_count suffixed variables
[16:12:11 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:43e2e172dfbd: Merge commit 'e65e4cbbda03ca3c9087f069c9867d518415fca1'
[16:18:34 CEST] <durandal_1707> wm4: could you open bug report for each filter you need?
[16:34:59 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07release/2.8:HEAD: Merge commit 'e65e4cbbda03ca3c9087f069c9867d518415fca1'
[16:35:44 CEST] <nevcairiel> the bot is weird
[16:35:48 CEST] <nevcairiel> that commit aint in that branch
[16:37:27 CEST] <BBB> maybe somebody else did that?
[16:37:53 CEST] <nevcairiel> i know, michaelni did, but the commit still isnt in that branch
[16:38:16 CEST] <nevcairiel> bot is just being weird
[16:39:08 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:f6974fe651d2: lavfi: Drop deprecated AVFilterBuffer* code
[16:39:09 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:033764e015e3: Merge commit 'f6974fe651d29ef6eb68d66d73f7b6c011062aa0'
[16:39:10 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:144fb0680666: Remove left-over FF_API_AVFILTERBUFFER cruft
[16:47:24 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:dc70c19476e7: lavc: Drop deprecated request_channels related functions
[16:47:25 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:b27ddffbfb29: Merge commit 'dc70c19476e76f1118df73b5d97cc76f0e5f6f6c'
[16:52:59 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:01bcc2d5c23f: lavc: Drop deprecated destruct_packet related functions
[16:53:00 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:87c88122703f: Merge commit '01bcc2d5c23fa757d163530abb396fd02f1be7c8'
[16:53:01 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:83a5df54eae6: Remove left-over FF_API_DESTRUCT_PACKET cruft
[17:01:23 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:9f90b2487701: lavc: Drop deprecated get_buffer related functions
[17:01:24 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:4eb86b83a407: Merge commit '9f90b24877016e7140b9b14e4b1acee663bb6d8a'
[17:01:25 CEST] <BtbN> wm4, did something recently change with mpv and ladspa? The Gentoo git ebuild started failing because configure doesn't know --disable-ladspa anymore.
[17:02:03 CEST] <durandal_1707> ladspa was removed from mpv
[17:02:18 CEST] <BtbN> Ok, so just dropping it from the ebuild should be fine.
[17:04:08 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:069713aa4b13: lavc: Drop deprecated thread opaque and codec pkt
[17:04:09 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:7f6b794da051: Merge commit '069713aa4b137781e270768d803b1f7456daa724'
[17:06:31 CEST] <wm4> there's a ladspa filter in libavfilter, so that's it
[17:08:09 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:cad40a3833ad: lavc: Drop deprecated deinterlace module
[17:08:10 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:41194f065c8e: Merge commit 'cad40a3833ad81a352e7657ec6f7d637cea3b798'
[17:12:13 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:183db02a51a4: lavu: Drop deprecated old_pix_fmt.h and related code
[17:12:14 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:c10caea2144f: Merge commit '183db02a51a422568084b113a7571c845ca68622'
[17:14:40 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:2f8cbbc962df: lavu: Drop deprecated external access to AVPixFmtDescriptor table
[17:14:41 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:0eed703d648c: Merge commit '2f8cbbc962dfc0dc1dd0a90b2cd6c21266380f51'
[17:17:30 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:cdfe45ad371b: lavu: Drop deprecated av_reverse function
[17:17:31 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:d96d0252fd53: Merge commit 'cdfe45ad371b7a8e6135b6c063b6b2a93152cb3a'
[17:19:19 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:2d40968dd3ff: lavu: Drop deprecated audioconvert.h header
[17:19:20 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:d9218011ef41: Merge commit '2d40968dd3ff17b12f7c80dbfad409b14418e267'
[17:20:07 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:bf7114b6caad: lavu: Drop deprecated AV_CPU_FLAG_MMX2 symbol
[17:20:08 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:58ebb39127da: Merge commit 'bf7114b6caad8cf94696b0299c13b0d26bf291be'
[17:26:57 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:f1b02e6ca889: lavu/cpu: remove old cmov cruft
[17:40:27 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:8f12ef9860d0: lavu: Drop deprecated duplicated AVFrame/AVCodecContext parameters
[17:40:27 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:b9fd81335173: Merge commit '8f12ef9860d0e164e4647fd5d5cebdb3cfb34a79'
[17:40:29 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:a9915268327b: lavu/frame: put frame QP elements under a new version guard
[17:45:36 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:2f9b652e8c64: lavu: Drop deprecated context size variables
[17:45:37 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:f940931995d0: Merge commit '2f9b652e8c646eabef74a6742f0d7d4c9118fd0e'
[17:47:51 CEST] <nevcairiel> phew that concludes merging their removals
[17:47:58 CEST] <nevcairiel> now to check out our r emaining stuff
[17:48:59 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:3d89373fae28: lavu: Drop deprecated private lls functions
[17:49:00 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:6f6c025d6d11: Merge commit '3d89373fae281053154772d5e3e4370da09d3880'
[17:49:38 CEST] <jamrial> i'm going to undo the FF_API_CRYPTO_CONTEXT changes in the 2.8 branch now
[17:52:32 CEST] <Compn> someone help finish off this r3d support will ya?
[17:52:48 CEST] <Compn> enjoy 2 weeks without compn
[17:53:33 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:4e649debcf7f: Postpone API-incompatible changes until the next bump
[17:53:34 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:2df52088ef5c: Merge commit '4e649debcf7f71d35c6b38cdb7ee715eba95d64a'
[17:54:00 CEST] <nevcairiel> .. now starts the fun checking all the things which llibav doesnt have, see when they were deprecated, and decide to drop them or not =p
[17:55:43 CEST] <BBB> nevcairiel: are those things libav dropped earlier and we delayed before?
[17:55:54 CEST] <nevcairiel> some yes, some libav never had
[17:56:04 CEST] <BBB> we should kill all of them
[17:56:07 CEST] <BBB> no exceptions
[17:56:17 CEST] <BBB> especially if libav dropped them earlier
[17:56:27 CEST] <BBB> its so bad to just keep old shit around for no reason
[17:56:50 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:545559e43db5: Remove FF_CONST_AVUTIL55 cruft
[17:56:56 CEST] <BBB> Im already wondering about Postpone API-incompatible changes until the next bump
[17:56:57 CEST] <jamrial> nevcairiel: FF_API_URL_FEOF andreas didn't complain about, so i guess it's safe to remove since no package uses it
[17:57:28 CEST] <nevcairiel> BBB: those are the ones that libav has and they decided to keep, usually newer than the 2 year deadline
[17:57:47 CEST] <nevcairiel> i didnt bother to check every single one however
[17:58:26 CEST] <nevcairiel> i'll go get some dinner in me and then come back to this
[17:58:33 CEST] <BBB> youre awesome btw
[17:58:37 CEST] <BBB> thank you for merging
[18:03:45 CEST] <nevcairiel> jamrial: about FF_API_HMAC, i guess i can remove the explicit number for 384 as well?
[18:04:11 CEST] <jamrial> yeah, t it can be easily removed
[18:05:08 CEST] <jamrial> it didn't even need an FF_API define for that matter. i could have just added a version check in the hash.h header
[18:06:25 CEST] <jamrial> regarding the explicit number, if we don't care about libav adding new enum values then remove it. otherwise i guess we could leave it
[18:06:57 CEST] <nevcairiel> are they likely to add something thats not going to be 384 and 512?
[18:07:01 CEST] <nevcairiel> i guess i could just leave it
[18:07:44 CEST] <cone-626> ffmpeg 03James Almer 07release/2.8:1a56be9cdc9b: avutil: undo FF_API_CRYPTO_CONTEXT deprecation for 2.8 release
[18:08:00 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:137f07599333: lavu/hmac: remove deprecated type ids
[18:08:33 CEST] <nevcairiel> anyway dinner for realz now
[18:12:19 CEST] <wm4> nevcairiel: so we can push commits again, without messing up your tree, right?
[18:12:38 CEST] <nevcairiel> sure
[18:12:55 CEST] <nevcairiel> only one merge left, the actual bump, and a whole bunch of things to do before thats ready
[18:22:16 CEST] <jamrial> is this ok to push http://pastebin.com/1Xfamc76?
[18:22:30 CEST] <durandal_1707> wm4: porting extrastereo
[18:23:11 CEST] <nevcairiel> jamrial: lgtm
[18:23:47 CEST] <wm4> huh, somehow "mate fate" is behaving strange
[18:23:59 CEST] <wm4> it keeps recompiling libavutil
[18:24:06 CEST] <nevcairiel> do a full clean
[18:24:14 CEST] <nevcairiel> that happens when a .d file references a header which no longer exists
[18:24:24 CEST] <wm4> sigh
[18:24:47 CEST] <nevcairiel> i found all the quirks today!
[18:24:48 CEST] <nevcairiel> :D
[18:24:49 CEST] <BBB>  happy its only libavutil
[18:25:11 CEST] <BBB> libvpx somehow requires a full recompile for any source file change when you enable vp10
[18:25:30 CEST] <BBB> make; touch any/source/file; make will fail at the second make
[18:25:59 CEST] <wm4> sounds terrible
[18:26:09 CEST] <cone-626> ffmpeg 03James Almer 07master:4a447e3e692e: avcodec/ac3: sync AC3HeaderInfo struct with the fork
[18:26:14 CEST] <jamrial> nevcairiel: thanks
[18:26:43 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:998fa4fa3010: avcodec/libutvideodec: remove AVFrame->reference usage, otherwise the code does not build
[18:26:44 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:a753e6c9f508: doc/examples/demuxing_decoding: Drop old api mode, because the code fails to build otherwise
[18:26:45 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:982e235d76d3: doc/APIchanges: add 2.8 cut line
[18:26:46 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:0acd4e75fdad: doc/APIchanges: Fill in missing fields and correct one lavu version
[18:27:13 CEST] <nevcairiel> hm, examples should be included in fate =p
[18:27:14 CEST] <wm4> so can I remove the Libav ABI hacks?
[18:27:47 CEST] <wm4> we also can stop API users from using accessors where Libav doesn't
[18:29:46 CEST] <jamrial> if we really aren't abi compatible with libav right with the tree as is even with that configure option, then there's no point keeping the hacks
[18:31:13 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:237cf3786ef7: lavu: Drop old deprecated AVOption API
[18:31:19 CEST] <nevcairiel> that was one old piece of API
[18:32:16 CEST] <jamrial> the first git pull i ran earlier today after you merged most of the api removal was glorious. tons of red "-" and deleted files
[18:32:32 CEST] <nevcairiel> hehe
[18:32:50 CEST] <nevcairiel> lavfi lost a lot of pre-AVFrame shit
[18:33:05 CEST] <cone-626> ffmpeg 03Andy Wu 07master:c43bd08f8b04: avformat/mp3dec: Make MP3 seek fast
[18:35:15 CEST] <nevcairiel> that reminds me that I saw something else in lavfi that wanted to get removed
[18:35:32 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:343322879574: lavfi: remove old graph parser API with different semantics
[18:36:23 CEST] <nevcairiel> dead code for a year or so
[18:37:57 CEST] <wm4> do we still need avcodec_find_best_pix_fmt_of_2?
[18:39:02 CEST] <jamrial> btw, just sent a pixfmt patch to the ml
[18:39:48 CEST] <nevcairiel> sounds like a good idea to sort that mess out, thanks jamrial
[18:40:11 CEST] <wm4> jamrial: that's not very complete
[18:40:21 CEST] <jamrial> what is it missing?
[18:40:26 CEST] <wm4> I'll send my own patch which removes this throughly
[18:40:41 CEST] <wm4> for starters, AV_HAVE_INCOMPATIBLE_LIBAV_ABI is used in some other places
[18:40:56 CEST] <wm4> you kept "AV_PIX_FMT_0RGB=0x123+4,"
[18:41:43 CEST] <jamrial> that's because it's the first pixfmt that's ffmpeg exclusive
[18:42:33 CEST] <jamrial> libav ends at AV_PIX_FMT_D3D11VA_VLD
[18:42:54 CEST] <wm4> and? there's no need to have this weird offset
[18:43:34 CEST] <jamrial> assuming we're no longer abi compatible with them then true, i guess
[18:43:43 CEST] <jamrial> i'll let you clean this then
[18:43:46 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07release/2.8:2710c14a83bc: doc/APIchanges: add 2.8 cut line
[18:43:46 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07release/2.8:f598ca088ed8: doc/APIchanges: Fill in missing fields and correct one lavu version
[18:44:46 CEST] <wm4> so the old vdpau API isn't dropped yet?
[18:50:44 CEST] <BBB> I thought I fixed that?
[18:50:46 CEST] <BBB> just remove it
[18:51:01 CEST] <BBB> even if libav decided to keep it, just remote it, its silly to keep old shit like that
[18:51:04 CEST] <BBB> *remove
[18:51:56 CEST] <wm4> +1
[18:52:17 CEST] <wm4> the vdpau stuff is especially intrusive and insane
[18:52:20 CEST] <wm4> lots of code duplication
[18:52:25 CEST] <wm4> and the API...
[18:52:26 CEST] <wm4> pure madness
[18:53:13 CEST] <wm4> "AV_CODEC_ID_FIRST_AUDIO"
[18:53:34 CEST] <wm4> and the fourccs even ruin this
[18:53:36 CEST] <wm4> hilarious
[18:54:12 CEST] <wm4> "AV_CODEC_ID_PCM_S24LE_PLANAR_DEPRECATED"
[18:56:34 CEST] <wm4> FF_API_CODEC_ID is also not removed?
[18:58:05 CEST] <wm4> I'm about to cry
[18:58:26 CEST] <wm4> old_codec_ids.h duplicates all constants in the most fragile way possible
[19:00:22 CEST] <wm4> av_assert0(AV_CODEC_ID_PCM_S8_PLANAR==65563);
[19:00:37 CEST] <wm4> michaelni: seriously what the fuck
[19:01:26 CEST] <nevcairiel> i'm not done removing things yet, stay cool =p
[19:01:36 CEST] <wm4> well I'm sending a patch to remove it
[19:01:40 CEST] <iive> wm4: ffmpeg specific enums should be on safe distance from libav ones.
[19:01:50 CEST] <wm4> iive: what the fuck
[19:02:11 CEST] <wm4> iive: no, they must not, and there's not a single reason they have to
[19:02:13 CEST] <nevcairiel> everything that was not postponed in version.h is slated for removal, unless its pretty new
[19:02:20 CEST] <wm4> unless you want to keep this absolute Libav ABI madness
[19:02:20 CEST] <nevcairiel> codec ids are among those
[19:02:49 CEST] <wm4> oh I see, I thought the version was already numped
[19:02:53 CEST] <wm4> bumped even
[19:03:09 CEST] <wm4> so am I too early with this stuff?
[19:03:30 CEST] <iive> i think libav delayed it, again
[19:03:45 CEST] <nevcairiel> libav hasnt had the old codec ids for two releases or so, iirc
[19:04:40 CEST] <jamrial> wm4: if you mean if nev merged the bump commit then no, not yet
[19:04:41 CEST] <iive> oh... then time to clean up.
[19:04:58 CEST] <nevcairiel> for avcodec, anything that says < 57 would be turned off by the bump
[19:05:08 CEST] <nevcairiel> so i'm  going to check them how old they are, and removing if too old
[19:05:19 CEST] <nevcairiel> if you want to pitch in, do it yourself, since i'm eating now :D
[19:06:09 CEST] <nevcairiel> (libav removed the codecs in 2013, https://git.libav.org/?p=libav.git;a=commitdiff;h=bdd1567c355a8092e7746ef99e831d579e34fa6a)
[19:06:15 CEST] <nevcairiel> codec ids*
[19:06:56 CEST] <jamrial> FF_API_DV_FRAME_PROFILE can go. it's wraps a private function that was made public by accident
[19:08:05 CEST] <durandal_1707> the special codecs ids need to go
[19:08:35 CEST] <wm4> "special"?
[19:09:58 CEST] <durandal_1707> with fourcc
[19:10:08 CEST] <wm4> sending a patch to remove them
[19:10:16 CEST] <wm4> any other areas with the insane fourcc stuff?
[19:10:45 CEST] <durandal_1707> the deprecated ones should be undeprecated
[19:10:54 CEST] <wm4> huh?
[19:12:23 CEST] <durandal_1707> Ones with capslock DEPRECATED
[19:12:32 CEST] <jamrial> durandal_1707: if you mean codecids they aren't really deprecated, just duplicated
[19:12:34 CEST] <wm4> why are they marked as such?
[19:12:42 CEST] <durandal_1707> insane mess
[19:13:01 CEST] <durandal_1707> Abi comp with libav
[19:13:15 CEST] <jamrial> wm4: we added the codecid first, then libav with a different enum value, so the first was renamed to deprecated
[19:13:29 CEST] <durandal_1707> Did abi ever was compatible?
[19:13:35 CEST] <wm4> nobody knows
[19:14:03 CEST] <wm4> actually I'd also like to get rid of things like AV_CODEC_ID_FIRST_AUDIO
[19:14:06 CEST] <jamrial> durandal_1707: i thought it was, seeing the amount of considerations that were added to the tree by michaelni, but some say it never really was
[19:14:18 CEST] <durandal_1707> build shared mpv to find out
[19:14:42 CEST] <jamrial> wm4: no, keep that in place. it's good to have that kind of offset
[19:15:53 CEST] <durandal_1707> If this cause flames just fork and i will be with you
[19:16:49 CEST] <ubitux> wm4: av_assert0(LIBAVCODEC_VERSION_MICRO >= 100);
[19:16:52 CEST] <ubitux> why do you remove this one?
[19:17:24 CEST] <wm4> why keep it
[19:17:45 CEST] <ubitux> because it makes sure we misbump
[19:18:02 CEST] <ubitux> many external contributors do not know the micro is 100+
[19:18:15 CEST] <wm4> then tell them in patch review
[19:18:18 CEST] <wm4> or add a damn comment
[19:18:24 CEST] <ubitux> we can save a round of review
[19:18:42 CEST] <ubitux> is it really a problem to keep it?
[19:19:03 CEST] <wm4> it doesn't belong in a version call
[19:19:17 CEST] <ubitux> well it can be put somewhere else then
[19:23:45 CEST] <BBB> wm4: FF_API_CODEC_ID patch is ok
[19:24:10 CEST] <BBB> and the libav abi hacks should all go
[19:24:15 CEST] <BBB> if theyre untested, they surely dont work
[19:25:55 CEST] <cone-626> ffmpeg 03James Almer 07master:251fb7dcd486: avcodec: remove FF_API_DV_FRAME_PROFILE cruft
[19:26:44 CEST] <wm4> ubitux: is it ok if I remove the assert now, and later we add it somewhere else?
[19:27:04 CEST] <wm4> if not I'll add it back to where it was on push
[19:27:26 CEST] <ubitux> i don't like it but i'm not going to block the patch
[19:29:04 CEST] <michaelni> for the record, the abi compatibility worked when i last tested it (is a while ago=
[19:29:34 CEST] <nevcairiel> did anyone ever use that?
[19:29:41 CEST] <ubitux> wm4: about --enable-incompatible-libav-abi patch; you might want to comment that it's simply not used last we talked about it
[19:29:52 CEST] <durandal_1707> with what tested?
[19:30:19 CEST] <ubitux> wm4: i mean, from an historical perspective, this bunch of commits are kind of a change of politics, so a small description would be welcome i think
[19:30:20 CEST] <michaelni> IIRC avconv build against libav and linked to ffmpeg but its a while ago
[19:31:03 CEST] <wm4> was there ever a serious user of this ABI compat?
[19:31:16 CEST] <ubitux> last we discussed it, it appeared not
[19:31:40 CEST] <ubitux> i think it was originally intended for distributions, but none of them used it
[19:31:51 CEST] <iive> that^
[19:31:55 CEST] <ubitux> i would guess it was one of the attempt to get ffmpeg back into debian
[19:32:00 CEST] <ubitux> it was solved differently
[19:32:12 CEST] <ubitux> i think that's the kind of information you want to put in the description
[19:32:23 CEST] <ubitux> (after verifying what i'm saying)
[19:32:54 CEST] <wm4> ubitux: then how about "This was originally intended for use by distros in the early days of the Libav fork, but it ended up as never being used. Remove it, because it's untested and causes considerable complexity."
[19:33:17 CEST] <ubitux> s/untested/unused/
[19:33:24 CEST] <ubitux> s/considerable/unecessary/
[19:34:39 CEST] <wm4> "This was originally intended for use by distros in the early days of the Libav fork, but it ended up as never being used. Remove it, because it's unused and no automatic tests are available, and causes unnecessary complexity."
[19:35:18 CEST] <ubitux> no objection, from my side, but don't rush it to avoid the flames please
[19:35:20 CEST] <iive> put somewhere ABI compatibility
[19:35:38 CEST] <iive> and explain that ffmpeg would try to be API compatible.
[19:35:59 CEST] <wm4> so what's the proposed wording
[19:37:32 CEST] <iive> "This ABI compatibility hack was originally intended for use by distros in the early days of the Libav fork, but it ended up as never being used. Remove it, because it's unused and no automatic tests are available, and causes unnecessary complexity. FFmpeg would continue to be API compatible with Libav,"
[19:38:11 CEST] <wm4> hm the last part got messed up?
[19:38:29 CEST] <iive> i had "for now", but it looked too sinister :E
[19:40:36 CEST] <ubitux> wm4: https://ffmpeg.org/pipermail/ffmpeg-devel/2014-April/156292.html
[19:40:42 CEST] <ubitux> see this thread for more info
[19:41:28 CEST] <ubitux> "fine i guess
[19:41:30 CEST] <ubitux> so applied
[19:41:32 CEST] <ubitux> "
[19:41:35 CEST] <ubitux> so it wasn't applied in the end?
[19:42:04 CEST] <ubitux> oh, or that's just the alias maybe
[19:42:10 CEST] <nevcairiel> just the alias
[19:42:17 CEST] <ubitux> alright, my bad then
[19:42:54 CEST] Action: wm4 lols at his own post in this thread
[19:48:54 CEST] <nevcairiel> we have a replacement for vismv now, dont we? so do we drop it?
[19:49:15 CEST] <BBB> nevcairiel: vismv includes visq
[19:49:22 CEST] <jamrial> Gentoo seems to be the only distro shipping both libav and ffmeg and their script doesn't use the incompatible-libav-abi option
[19:49:24 CEST] <BBB> nevcairiel: and ubitux replacement wasnt ready yet I believe
[19:49:28 CEST] <nevcairiel> hm
[19:49:29 CEST] <BBB> nevcairiel: I still think we can drop it
[19:49:33 CEST] <jamrial> but then again they don't ship precompiled packages
[19:49:35 CEST] <BBB> nevcairiel: its a developer only option
[19:49:40 CEST] <BBB> nevcairiel: users never need it
[19:49:46 CEST] <nevcairiel> its a fun thing to play with :D
[19:49:48 CEST] <BBB> nevcairiel: the only user of that feature in practice is michael
[19:50:11 CEST] <nevcairiel> actually vis_qp is not protected under FF_API_VISMV
[19:50:15 CEST] <BBB> fun isnt necessarily worthy of being in the main source tree and making everyones life a pain
[19:50:56 CEST] <BBB> its under FF_API_DEBUG_MV
[19:51:01 CEST] <BBB> I dont know why theyre different
[19:51:19 CEST] <BBB> or, at least, the relevant code for it needs to be under FF_API_DEBUG_MV for the source to compile
[19:51:31 CEST] <BBB> remind me at VDD that you like that feature
[19:51:46 CEST] <nevcairiel> VISMV only protects the direct mv drawing code in mpegvideo
[19:51:59 CEST] <nevcairiel> nothing else
[19:52:09 CEST] <nevcairiel> the API parts are the one you mentioned
[19:52:26 CEST] <nevcairiel> which isnt part of this bump yet anyway
[19:53:03 CEST] <nevcairiel> or at least are not right now, since their version check is one higher
[19:54:23 CEST] <nevcairiel> vismv was only deprecated a year ago or so, so the strict rules would say it stays
[19:55:13 CEST] <jamrial> wm4: until the whole "are we compatible and do we want to remain so" deal is solved, we can still push my version of the pixfmt change since it should in theory be compatible with libav
[19:55:39 CEST] <durandal_1707> wm4: why keep DEPRECATED codecs?
[19:56:27 CEST] <jamrial> durandal_1707: we probably wont. it depends on the discussion about compatibility
[19:56:49 CEST] <nevcairiel> which are the deprecated ones? the libav ids, or  the ones we had before libav added it?
[19:57:24 CEST] <wm4> so can I push this shit or not
[19:57:24 CEST] <nevcairiel> (in both cases we can remove them, fwiw, just may need to re-order them to match libav ABI if that is the outcome)
[19:57:26 CEST] <durandal_1707> the codecs named that way
[19:58:55 CEST] <durandal_1707> or rename depecated to normal and remove ours
[19:59:41 CEST] <jamrial> nevcairiel: ours are the deprecated, i think, but better check
[20:00:10 CEST] <durandal_1707> no, other way around
[20:01:13 CEST] <nevcairiel> ABI compat is an insane goal in any case .. I was looking at avformat deprecations, and tehre is the one where we increase max_analyze_duration and probesize to 64-bit
[20:01:21 CEST] <nevcairiel> how would we ever do that and remain ABI compatible
[20:01:32 CEST] <nevcairiel> by doubling the fields, surely
[20:01:56 CEST] <jamrial> that's the one i mentioned in an email that's sure to break abi compatibility
[20:03:30 CEST] <nevcairiel> hm, avio_feof is only a year old
[20:03:59 CEST] <jamrial> nevcairiel: andreas didn't complain about it so i assume there are no packages using url_feof
[20:04:43 CEST] <jamrial> still, it could be postponed until next bump. it doesn't hurt
[20:05:06 CEST] <nevcairiel> thats a one line alias function, yeah no maintenance at all
[20:06:05 CEST] <nevcairiel> alkthough the name clashes with libcurl, which apparently uses that scheme
[20:06:21 CEST] <wm4> sounds like a good reason to kill it now
[20:06:50 CEST] <wm4> "Get the facts straight please. FFmpeg's libraries were ABI-compatible with the fork's for most of the time."
[20:06:54 CEST] <wm4> what the fuck is up with this guy
[20:07:49 CEST] <wm4> I'm really not fucking surprised Libav devs show not the slightest interest in reunification
[20:07:53 CEST] <nevcairiel> url_feof doesnt have many hits on google in any case, most are ffmpeg itself, and very few are ancient ffmpeg users
[20:08:58 CEST] <nevcairiel> a fun fact is that url_feof was removed once before in favor of pb->eof_reached
[20:09:01 CEST] <jamrial> wm4: i still don't even know if we are even abi compatible right now at all
[20:09:03 CEST] <nevcairiel> only later was the function added back
[20:09:04 CEST] <jamrial> you and others say we aren't, michaelni says we used to be at least several months ago, nicolas says we still are
[20:09:23 CEST] <wm4> jamrial: nicolas seems to say we are even without this option enabled?
[20:09:32 CEST] <nevcairiel> thats definitely wrong
[20:09:33 CEST] <jamrial> that's certainly not true...
[20:09:52 CEST] <jamrial> with the option enabled we may be, but without it we absolutely aren't
[20:10:31 CEST] <nevcairiel> maybe he tested like yuv420p only, which is the same pixel format id in both
[20:10:35 CEST] <nevcairiel> i dont know what else is different
[20:12:37 CEST] <ubitux> BBB, nevcairiel: yeah sorry not done, need some fixes; there are also some other complex visualizer, it's not only about QP
[20:12:53 CEST] <BBB> I tohught it was qp and mv?
[20:14:21 CEST] <nevcairiel> the old vis feature seems very self-contained in mpegvideo, so considering the replacement is only a year old and not perfect yet, should probably just postpone it, apparently some people consider it useful if ubitux is even bothering to build a fancy replacement :)
[20:14:49 CEST] <ubitux> BBB: no... block types too
[20:14:53 CEST] <nevcairiel> (and its not even API, just functionality, so no bloat on that side)
[20:15:34 CEST] <ubitux> this visualizer in mpegvideo doesn't bother
[20:15:43 CEST] <ubitux> i'm happy if it's deported to lavfi but it's not completely done
[20:15:50 CEST] <ubitux> (bother +me)
[20:16:05 CEST] <ubitux> BBB: http://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors
[20:16:10 CEST] <nevcairiel> what else do i have on my list..
[20:16:14 CEST] <nevcairiel> FF_API_GET_CHANNEL_LAYOUT_COMPAT
[20:16:17 CEST] <nevcairiel> 123 vs 123c
[20:16:29 CEST] <nevcairiel> again no API impact, just functionality
[20:17:54 CEST] <BBB> I fixed that
[20:17:56 CEST] <BBB> so you can remove that
[20:18:26 CEST] <nevcairiel> it has been spitting out a warning if used improperly for 2 years, so its probably fine
[20:19:41 CEST] <BBB> Im hitting this weird issue where vpxdec outputs something, but ffmpeg -c:v libvpx-vp9 .. -vsync 0 spits out something different
[20:19:44 CEST] <BBB> how annoying
[20:30:46 CEST] <wm4> does anyone know in which commit the libav compat was added?
[20:31:04 CEST] <wm4> I only find 5efbeae38cdcf8ed099be06f59fb422b5004e163
[20:31:11 CEST] <wm4> which claims it's renaming it, but actually it's adding it
[20:32:59 CEST] <ubitux> wm4: git log -p --reverse -Gincompatible_fork_abi configure raises 42e78552c8a7d977c9573e6b1d5744ed65b6fc3f
[20:33:41 CEST] <wm4> thanks, so it wasn't documented at this point
[20:34:59 CEST] <wm4> I take my patches back
[20:35:07 CEST] <wm4> you can fix your shitty crap yourself
[20:38:05 CEST] <jamrial> wm4: calm down, please
[20:38:07 CEST] <jamrial> while nicolas is wrong about compatibility without the option, he's right that dropping it in the case it works (alledgedly with the option enabled) needs an actual discussion. it is a change in policy
[20:38:47 CEST] <wm4> what "policy"
[20:38:54 CEST] <wm4> this project has an insane decision process
[20:39:02 CEST] <wm4> honestly fuck all this
[20:39:13 CEST] <ubitux> tss
[20:39:48 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:d83dd630a09d: lavu: Drop FF_API_GET_CHANNEL_LAYOUT_COMPAT cruft
[20:39:48 CEST] <jamrial> blagh
[20:40:18 CEST] <ubitux> kids want what they want instantly these days ;)
[20:40:24 CEST] <jamrial> and it should be obvious, ever since the split we aimed at being abi compatible so ffmpeg libraries could work a drop in replacement
[20:40:45 CEST] <ubitux> yeah
[20:40:45 CEST] <jamrial> it hasn't been thorougly tested in the past year or so, but it's been the aim all this time
[20:40:54 CEST] <jamrial> there's a reason all those ugly hacks are in place...
[20:41:01 CEST] <ubitux> i'm fine with the changes themselves personally, but nicolas has a point about discussing the change of policy first
[20:41:13 CEST] <ubitux> or it's going to be just like 2011 again
[20:41:18 CEST] <jamrial> so instead of rage quitting, we should find out if we still really are compatible AND if we still want to be
[20:41:25 CEST] <jamrial> yeah
[20:41:51 CEST] <nevcairiel> cleaning up the pixfmts to be libav compatible for the time being is good anyway, it gets rid of a lot of noise, so without reviewing that its actually ABI compatible to libav, in general ok for me
[20:42:38 CEST] <nevcairiel> do we still have the rule that BE/LE formats need to be on odd/even respectively?
[20:42:53 CEST] <jamrial> should i push it then? it's pretty much the same as wm4's patch, except i kept the pixfmts that match libav
[20:42:56 CEST] <nevcairiel> probably not, i think its violated in many places anyway
[20:44:48 CEST] <nevcairiel> just push it
[20:44:52 CEST] <nevcairiel> its ABI only  anyway
[20:45:06 CEST] <nevcairiel> ...unless some (l)user used the *_LIBAV symbols, which would be silly
[20:47:35 CEST] <nevcairiel> so since we w ont decide about the ABI over night, I guess i have to keep the duped probesize fields huh
[20:51:00 CEST] <jamrial> for the time being at least, yeah
[20:51:24 CEST] <jamrial> i still would like if someone could confirm if we are compatible with the option enabled. nobody really tested it in several months...
[20:52:02 CEST] <BBB> do we have a feature to output individual yuv images (not planes) to individual files, like png?
[20:52:18 CEST] <BBB> -f rawvideo image%d.yuv doesnt work the same way as image%d.Y
[20:52:39 CEST] <BBB> or is it -f image2?
[20:53:04 CEST] <nevcairiel> image2 is needed for such glob pattern
[20:53:24 CEST] <cone-626> ffmpeg 03James Almer 07master:c956cb2c0256: avutil/pixfmt: remove duplicate AVPixelFormat values
[20:54:37 CEST] <nevcairiel> where does AV_PIX_FMT_ABI_GIT_MASTER come from anyway
[20:54:46 CEST] <nevcairiel> was the user supposed to set that in cflags?
[20:55:32 CEST] <jamrial> apparently. grep doesn't show anything in the source tree, or even the generated header files
[21:01:07 CEST] <nevcairiel> anyone want to make an argument to keep old encode and decode functions?
[21:01:16 CEST] <nevcairiel> some people used to feel strongly about those
[21:04:02 CEST] <nevcairiel> oddly enough they are not on andreas list
[21:04:32 CEST] <nevcairiel> probably bnecause libav nixed them years ago, and debian got all the projects fixed since they wanted to run with libav
[21:07:29 CEST] <kierank> has get_buffer gone yet?
[21:07:36 CEST] <nevcairiel> yes thats gone
[21:19:45 CEST] <durandal_1707> BBB: vf_extractplanes?
[21:24:39 CEST] <BBB> so uh
[21:24:41 CEST] <BBB> michaelni: 
[21:24:46 CEST] <BBB> is md5 flag changes ok?
[21:27:50 CEST] <ubitux> durandal_1707: what's retinex doing?
[21:28:32 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:2c8ee2547ef1: avcodec: remove deprecated old audio decode API
[21:28:33 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:64c33f9624ee: avcodec: remove deprecated old audio encode API
[21:28:34 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:76cac7ed45fb: avcodec: remove deprecated old video encode API
[21:28:35 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:24e3bac52a2b: avcodec: remove deprecated codec id aliases
[21:28:36 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:590ea32e54ee: Postpone removal of API changes from within the last two years
[21:29:25 CEST] <BBB> ;(
[21:29:30 CEST] <BBB> postpone api changes
[21:29:32 CEST] <BBB> sad
[21:29:54 CEST] <nevcairiel> the rule is 2 years, thats that
[21:30:17 CEST] <jamrial> nevcairiel: audio_convert as well?
[21:30:29 CEST] <nevcairiel> its not two years old, and i didnt want to silently start drama
[21:30:35 CEST] <nevcairiel> feel free to send a patch to discuss
[21:30:44 CEST] <jamrial> but didn't libav remove it long ago? i thought it was old as heck by now
[21:30:47 CEST] <ubitux> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commitdiff;h=c956cb2c02563ca87c7feec532c1c63a6385fccf  this is causing an ABI break (all kind of id shift); is that on purpose?
[21:31:23 CEST] <ubitux> (outside the ifdefery)
[21:31:34 CEST] <kierank> how do you do your own buffer referencing without get_buffer
[21:31:37 CEST] <ubitux> (typically YUVA444P)
[21:31:42 CEST] <kierank> (i.e not using avbufferref)
[21:31:52 CEST] <jamrial> yes, it's now in sync with libav and shouldn't break anything since we're bumping major
[21:32:07 CEST] <ubitux> ok
[21:34:01 CEST] <nevcairiel> why is our avdevice one major in front of libav
[21:35:39 CEST] <ubitux> nevcairiel: 2ffa9e611e5c1e84b360cb43cb18c5af4b8ee1a6 maybe
[21:36:09 CEST] <ubitux> maybe sth related to avformat
[21:36:11 CEST] <nevcairiel> oh well
[21:36:16 CEST] <nevcairiel> so much for ABI compat =)
[21:36:51 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:e88103a7f92c: Bump major versions of all libraries
[21:36:52 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:160e92c8bfad: Merge commit 'e88103a7f92cf27a2868b50acc8a9912f6088249'
[21:36:54 CEST] <nevcairiel> anyway, there you go
[21:37:03 CEST] <nevcairiel> i'll sit back and watch the fireworks now
[21:37:04 CEST] <jamrial> nevcairiel: FF_API_AVCODEC_RESAMPLE is from march 2013, FF_API_AUDIO_CONVERT from october 2013
[21:37:22 CEST] <nevcairiel> pushed in november 2013, thats two months from now
[21:37:40 CEST] <nevcairiel> anyway just send a patch for discussion, its not like we cant remove it still
[21:37:47 CEST] <jamrial> did andreas complain about it?
[21:37:49 CEST] <jamrial> true enough
[21:37:54 CEST] <michaelni> BBB, the fate tests which use md5 should probably be changed to use framed5, i think there are few
[21:38:39 CEST] <michaelni> fate-g722-encode, fate-g726-encode*, fate-dcinema-encode 
[21:39:42 CEST] <nevcairiel> and andreas probably didnt complain, because libav didnt have it, so debian couldnt have used it
[21:39:47 CEST] <michaelni> or is there a reason why they use md5 ?
[21:40:39 CEST] <nevcairiel> but https://github.com/search?q=av_audio_convert_alloc&type=Code&utf8=%E2%9C%93 found quite a bunch of hits, so since the 2 years arent really up yet, I felt better keeping it initially
[21:40:45 CEST] <nevcairiel> can discuss it, of course :)
[21:40:54 CEST] <BBB> michaelni: I assure you its got nothing to do with timestamp handling
[21:42:14 CEST] <BBB> michaelni: and Im not very good at understanding fate at that level, I dont mind an option or what not
[21:42:30 CEST] <BBB> I just need a mode where ffmpeg.c does not touch my frames and just gives me what the decoder gives it
[21:42:41 CEST] <BBB> I dont want to have to change fate or anything like that
[21:42:56 CEST] <BBB> I just want a ffmpeg -leave-me-alone -i myfile -f whatever -
[21:43:12 CEST] <BBB> and then it does nothing smart
[21:43:40 CEST] <BBB> whatever can be md5, framemd5, maybe even image2
[21:45:30 CEST] <nevcairiel> in any case, i've been at this for like 10 hours, so i'm going to enjoy the rest of my evening. I'll await any flames on the ML :P
[21:45:58 CEST] <ubitux> nevcairiel: thanks for your work
[21:46:05 CEST] <BBB> indeed
[21:46:06 CEST] <jamrial> ^
[21:46:09 CEST] <BBB> nevcairiel: you are awesome
[21:46:15 CEST] <BBB> thank you
[21:46:21 CEST] <kierank> nevcairiel: <3
[21:46:42 CEST] <cone-626> ffmpeg 03wm4 07master:89b0a9f3fa9d: avcodec/vdpau: remove incompatible-libav-abi hack from vdpau_render_state struct
[21:52:44 CEST] <jamrial> install: cannot stat /home/ux/fate/ffmpeg/libavcodec/old_codec_ids.h: No such file or directory
[21:52:45 CEST] <jamrial> :D
[21:53:33 CEST] <nevcairiel> oh my bad
[21:53:55 CEST] <jamrial> it's a reference in makefile
[21:54:03 CEST] <jamrial> one line change, i can do it if you prefer
[21:54:35 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:3d7173b50965: vp9: always sync segmentation.feat between threads.
[21:54:36 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:873dbc6758d8: vp9: sync segmentation.absolute_vals between threads.
[21:54:37 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:9cdeb105a6d5: vp9: do unscaled MC in scaled path if size of this reference matches.
[21:54:38 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:1f7871ec428f: vp9: fix edge copy for 10/12bpp frames.
[21:54:39 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:342bca7f02fc: vp9: fix integer overflow in 10/12bpp DC-only calculation.
[21:54:40 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:ef8740d8e58d: vp9: fix type of iadst4_1d intermediates.
[21:54:41 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:ae9344cb9ffa: vp9: check return value of ff_thread_ref_frame().
[21:54:42 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:086c9b78d42f: vp9: fix rounding error in idct_8x8_ssse3.
[21:55:06 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:393b472362e5: avcodec: fix make install after old_codec_ids.h removal
[21:55:16 CEST] <RiCON> nevcairiel: http://j.fsbn.eu/qzbK.png
[21:55:43 CEST] <nevcairiel> its in check headers too? damn that thing
[21:56:18 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:8042d6c49248: avcodec: remove old_codec_ids.h from SKIPHEADERS as well
[22:09:52 CEST] <durandal_1707> ubitux: killing dynamic range, defog
[22:10:31 CEST] <durandal_1707> Look doom9 thread
[22:15:57 CEST] <BBB> does anyone else have opinions on how to accomplish md5 not removing frames with invalid timestamps?
[22:16:06 CEST] <BBB> I really dont care how we do it, I just want to be able to do it
[22:21:15 CEST] <Zeranoe> OpenCL has been added to the Windows builds: https://ffmpeg.zeranoe.com/blog/?p=419
[22:21:58 CEST] <BtbN> It should realy be used for more stuff
[22:22:17 CEST] <BtbN> currently it's only used for those two filters.
[22:25:25 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:8d860f9a772e: avcodec/x86/w64xmmtest: Fix another build failure
[22:36:58 CEST] <cone-626> ffmpeg 03Ganesh Ajjanagadde 07master:78995dc241ea: avfilter/vf_unsharp: use the name 's' for the pointer to the private context
[22:37:36 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:69c344eed274: configure: Remove reference to no longer existing avcodec_encode_video()
[22:50:23 CEST] <cone-626> ffmpeg 03Rostislav Pehlivanov 07master:cf6fb6f3f721: fate: increase the fuzz of the AAC encoder aref test
[23:08:27 CEST] <durandal_1707> BBB: add another muxer?
[00:00:00 CEST] --- Sun Sep  6 2015