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

[burek]

[00:00:22 CEST] <durandal_1707> what a price?
[00:01:47 CEST] <JEEB> ok, no - it seems like they added i7-8550U
[00:01:55 CEST] <JEEB> to the available CPUs for the 13
[00:02:15 CEST] <durandal_1707> pricing?
[00:03:29 CEST] <JEEB> https://www.computeruniverse.net/en/products/90707596/dell-xps-13-9360-9986.asp
[00:03:35 CEST] <JEEB> in the EU around that price I guess
[00:03:43 CEST] <JEEB> (that's with 16GiB of RAM and 512GiB SSD)
[00:03:51 CEST] <JEEB> wait what
[00:03:56 CEST] <JEEB> that's with HD screen?!
[00:03:59 CEST] <JEEB> blasphemy
[00:04:49 CEST] <durandal_1707> because of SSD
[00:05:57 CEST] <atomnuker> I'm glad I bought my xps 15 back in january of last year, I got a good deal for a 4k + 16gb of ram + the 8 core cpu + 1 tb hdd
[00:06:24 CEST] <JEEB> 8 core?
[00:06:31 CEST] <atomnuker> 4 core, 8 cpu
[00:06:31 CEST] <JEEB> or do you mean 4+HT
[00:06:36 CEST] <JEEB> right
[00:07:27 CEST] <JEEB> https://www.computeruniverse.net/en/products/90707598/dell-xps-13-9360r-0029.asp
[00:07:31 CEST] <jkqxz> Pre-brexit pricing ftw?
[00:07:32 CEST] <JEEB> ok, this one is the 3200x1800 one
[00:11:30 CEST] <JEEB> hmm, what's this HP Spectre 13 thing?
[00:39:31 CEST] <cone-302> ffmpeg 03Anton Khirnov 07master:b76f6a76c631: h264dec: initialize field_started to 0 on each decode call
[00:39:32 CEST] <cone-302> ffmpeg 03Anton Khirnov 07master:83b2b34d06e7: h2645_parse: use the bytestream2 API for packet splitting
[00:39:33 CEST] <cone-302> ffmpeg 03James Almer 07master:f898df60bca3: Merge commit 'b76f6a76c6312dc551d7c37c6ded36bea7973c74'
[00:39:34 CEST] <cone-302> ffmpeg 03James Almer 07master:07cf202614a8: Merge commit '83b2b34d06e74cc8775ba3d833f9782505e17539'
[02:05:13 CEST] <atomnuker> jamrial: does the v2 of that side data buf patch look okay?
[02:08:52 CEST] <atomnuker> michaelni: does the opus decoder have any unfixed integer overflows?
[02:13:58 CEST] <jamrial> atomnuker: if it keeps the frame and user provided buffer intact on failure, then yes
[02:14:23 CEST] <jamrial> i still think it should use data array like we do with packet and stream side data, though
[02:14:57 CEST] <jamrial> and not an user allocated avbufferref, which in most use cases for this function will have to be allocated specifically for it
[02:24:42 CEST] <michaelni> atomnuker, iam not conciously aware of any 
[02:25:39 CEST] <atomnuker> I guess they have been fixed then, opus released an update to the rfc (8251)
[02:25:56 CEST] <atomnuker> which fixes a few of those to the original reference implementation
[02:27:31 CEST] <atomnuker> but I couldn't find any code we'd need to update here, we don't use a silk resampler, the decoder's float only and we reinit properly on channel change
[02:36:00 CEST] <cone-302> ffmpeg 03Michael Bradshaw 07master:279dc407163e: lavc: drop support for OpenJPEG 1.3-2.0
[03:50:02 CEST] <cone-302> ffmpeg 03Dale Curtis 07master:a5fd8aa45b11: avformat/mov: Set start_pad correctly in mov_fix_index()
[04:13:36 CEST] <jamrial> jkqxz: https://pastebin.com/eAWvrTTu https://0x0.st/srQ4.h264
[11:38:08 CEST] <ubitux> https://twitter.com/johnregehr/status/920691341738123264
[11:38:14 CEST] <ubitux> that's a nice way of deprecating an API
[11:38:32 CEST] <nevcairiel> just make it slow
[15:00:10 CEST] <jamrial> michaelni: what do you think of libav commit 522d850e68?
[15:00:35 CEST] <JEEB> anyone else noted regressions in seeking/files ending with http://git.videolan.org/?p=ffmpeg.git;a=commit;h=858db4b01fa2b55ee55056c033054ca54ac9b0fd ?
[15:00:46 CEST] <jamrial> it applies, but i can't reproduce the invalid reads with the sample from the ticket mentioned in it
[15:02:32 CEST] <jamrial> JEEB: what kind of regressions? eof never being signaled?
[15:03:09 CEST] <JEEB> seeking never finishing and being in a loop within lavf and then EOF never gotten
[15:04:00 CEST] <jamrial> sounds like the kind of regressions that were reported with previous versions of the patch
[15:04:30 CEST] <JEEB> I posted on the ML a log from a user who had just built latest FFmpeg+mpv. it could of course be mpv's API usage but if such internal semantics change has an effect on the API clients then that's not good, either :/
[15:05:57 CEST] <JEEB> I mean, the idea of the change in general is valid (you can get zero byte packets from a network protocol), but it seems like some other parts didn't work completely well with the semantics change
[15:52:58 CEST] <michaelni> jamrial, if theres an issue it should be fixed by enlarging the scantable (as its faster) or maybe you can even drop the if/else and use vlcs that are never returning a out of range value. Id say the FFMIN is wrong in all cases, it should be a error return if a check is added not silently continuing
[16:06:02 CEST] <jamrial> michaelni: i'll skip it then. if you think there's something to fix or change in it then feel free to
[16:06:05 CEST] <jamrial> I'm not familiar enough with this code to make such changes myself
[16:22:11 CEST] <michaelni> jamrial, i think the mb_padding stuff we have makes it unneeded but we can possibly improve it beyond what we have
[17:27:03 CEST] <cone-583> ffmpeg 03Anton Khirnov 07master:522d850e68ec: h264_cavlc: check the value of run_before
[17:27:03 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:994c4bc10751: x86util: Port all macros to cpuflags
[17:27:03 CEST] <cone-583> ffmpeg 03James Almer 07master:ede5ddb58683: Merge commit '522d850e68ec4b77d3477b3c8f55b1ba00a9d69a'
[17:27:03 CEST] <cone-583> ffmpeg 03James Almer 07master:2904db90458a: Merge commit '994c4bc10751e39c7ed9f67ffd0c0dea5223daf2'
[17:39:26 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:307eb1a8ee36: x86: vp8dsp: port FILTER_BILINEAR macro to cpuflags
[17:39:27 CEST] <cone-583> ffmpeg 03James Almer 07master:53eea3a5693a: Merge commit '307eb1a8ee363db1fcf869e427a8deb6d9538881'
[17:41:32 CEST] <JEEB> lol, seems like latest ubuntu comes with a opencv version that doesn't work with our C code since they're actively breaking the C API
[17:41:36 CEST] <JEEB> https://github.com/opencv/opencv/issues/8438
[17:43:02 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:e9bb77fb1012: x86: h264: Simplify DEQUANT macro with cpuflags
[17:43:03 CEST] <cone-583> ffmpeg 03James Almer 07master:11f5ffd33005: Merge commit 'e9bb77fb1012cba1951a82136df7071f71bce8fb'
[17:49:51 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:681a86aba6cb: x86: fft: Port to cpuflags
[17:49:52 CEST] <cone-583> ffmpeg 03James Almer 07master:b7c16a3f2c49: Merge commit '681a86aba6cb09b98ad716d986182060c7795d20'
[17:51:59 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:0d8013b88b1c: configure: Replace -no_weak_symbols with -Werror=partial-availability
[17:52:00 CEST] <cone-583> ffmpeg 03James Almer 07master:13c84b077ace: Merge commit '0d8013b88b1cb7d65da891a8819d3beebafb9bb5'
[18:23:45 CEST] <cone-583> ffmpeg 03James Almer 07master:827a05eaa948: matroskaenc: add support for Spherical Video elements
[18:23:46 CEST] <cone-583> ffmpeg 03James Almer 07master:fd59207c1c86: Merge commit '827a05eaa9482e9ac2a17f7f2e42ead07c1d7574'
[18:25:54 CEST] <cone-583> ffmpeg 03Martin Storsjö 07master:7995ebfad120: arm/aarch64: vp9: Fix vertical alignment
[18:25:55 CEST] <cone-583> ffmpeg 03James Almer 07master:a86e11521334: Merge commit '7995ebfad12002033c73feed422a1cfc62081e8f'
[18:28:48 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:cfee5e1a0fa8: build: Add missing object dependency for extract_extradata bitstream filter
[18:28:49 CEST] <cone-583> ffmpeg 03James Almer 07master:0814f4f720e8: Merge commit 'cfee5e1a0fa892fadd19b8848545d62f2386a6e7'
[18:33:55 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:b864230c4908: rtmp: Move RTMP digest calculation to a separate file
[18:33:56 CEST] <cone-583> ffmpeg 03James Almer 07master:5f84ad3ecce3: Merge commit 'b864230c49089b087eef56988a3d6a784f6f9827'
[18:40:18 CEST] <jamrial> michaelni: what do you think of bd805964f4?
[18:40:26 CEST] <jamrial> since you have jack installed
[18:40:47 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:b266ad56fe0e: hwcontext: Add device derivation
[18:40:48 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:b7487f4f3c39: hwcontext: Make it easier to work with device types
[18:40:49 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:d2e6dd32a445: avconv: Generic device setup
[18:40:50 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:62a1ef9f26c6: avconv: Enable generic hwaccel support for VAAPI
[18:40:51 CEST] <cone-583> ffmpeg 03wm4 07master:16a163b55a65: lavc: Add hwaccel_flags field to AVCodecContext
[18:40:52 CEST] <cone-583> ffmpeg 03wm4 07master:1a7ddba5762b: lavc: vdpau: add support for new hw_frames_ctx and hw_device_ctx API
[18:40:53 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:aa6b2e081c50: avconv: Enable generic hwaccel support for VDPAU
[18:40:54 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:303fadf5963e: avconv: Document the -init_hw_device option
[18:40:55 CEST] <cone-583> ffmpeg 03James Almer 07master:9cfdf0e3322b: Merge commit '303fadf5963e01b8edf4ba2701e45f7e9e586aeb'
[18:43:28 CEST] <ubitux> all work and no play makes jack a dull boy ~
[18:46:09 CEST] <ubitux> jamrial: removing jack from the autodetected lib probably makes sense yes
[18:46:18 CEST] <ubitux> (IMO)
[18:46:43 CEST] <jamrial> ok
[18:46:50 CEST] <ubitux> OTOH, we have --disable-autodetect now so it doesn't matter much
[18:46:54 CEST] <jamrial> ubitux: less than ten commits until the major bump :D
[18:47:01 CEST] <ubitux> yay
[18:47:36 CEST] <ubitux> btw, shouldn't sndio be handled the same?
[18:47:44 CEST] <ubitux> as in "not autodetected"?
[18:47:47 CEST] <jamrial> we'll finally be back to minor versions in the single and double digits :p
[18:47:53 CEST] <ubitux> :)
[18:48:22 CEST] <jamrial> libavcodec reaching minor 100 for this major version was a first i think
[19:06:17 CEST] <jamrial> ubitux: i'll look at sndio later
[19:06:57 CEST] <jamrial> but yeah, being used for an indev guess it should probably not be autodetected
[19:13:51 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:bd805964f40f: configure: Do not treat JACK as a system library
[19:13:52 CEST] <cone-583> ffmpeg 03James Almer 07master:a2a7b02fbd9d: Merge commit 'bd805964f40f7af83da64645ba83d1e8060a1214'
[19:16:03 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:ca960161f087: rtsp: Move message parsing to a separate function
[19:16:04 CEST] <cone-583> ffmpeg 03James Almer 07master:12b6166bcfb4: Merge commit 'ca960161f087ca38267b88ce90592010c59584f1'
[19:17:51 CEST] <cone-583> ffmpeg 03Konda Raju 07master:3df77b58e35a: nvenc: Allow different const qps for I, P and B frames
[19:17:52 CEST] <cone-583> ffmpeg 03James Almer 07master:2c966481091a: Merge commit '3df77b58e35a30ed550f99936a308f6bd2f47a20'
[19:20:05 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:e245d4f45ca5: dca: Validate the channel map
[19:20:06 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:a46a4f722d2f: dca: Refactor dca_filter_channels() a little
[19:20:07 CEST] <cone-583> ffmpeg 03James Almer 07master:157dc1495135: Merge commit 'a46a4f722d2fac07c57990f0f548777622599f59'
[19:22:42 CEST] <cone-583> ffmpeg 03Martin Storsjö 07master:3aa9c523e9cf: libavutil: Define the noreturn attribute for clang in MSVC mode as well
[19:22:44 CEST] <cone-583> ffmpeg 03James Almer 07master:1ba5e456dd6e: Merge commit '3aa9c523e9cf4f4a5e239ac737281e096c884907'
[19:26:49 CEST] <cone-583> ffmpeg 03Martin Storsjö 07master:8e2346154e6d: libavutil: Hook up the rest of the gcc specific attributes to clang as well
[19:26:50 CEST] <cone-583> ffmpeg 03James Almer 07master:072b14f39047: Merge commit '8e2346154e6d58b733fd20326ce706f82fd91b3e'
[19:35:41 CEST] <cone-583> ffmpeg 03Carl Eugen Hoyos 07master:628ce8b8b6b8: flvdec: Set avg_frame_rate for video streams
[19:35:42 CEST] <cone-583> ffmpeg 03James Almer 07master:4c0a8ff0610c: Merge commit '628ce8b8b6b80cb3985d39e195b71b9d7fad9008'
[19:58:42 CEST] <michaelni> jamrial, iam the wrong one to ask about configure and system libs, thats not my area
[19:59:14 CEST] <jamrial> michaelni: ah ok. i thought about you since you noticed the jack regression the other week during a configure merge
[19:59:21 CEST] <jamrial> will keep that in mind, thanks
[20:07:08 CEST] <ubitux> jamrial: so, are we bumping or what? :p
[20:07:19 CEST] <jamrial> ubitux: running fate :p
[20:07:25 CEST] <ubitux> :o
[20:07:40 CEST] <jamrial> since the last time i ran it with the bump applied was september :p
[20:11:00 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:07a2b155949e: Bump major versions of all libraries
[20:11:01 CEST] <cone-583> ffmpeg 03James Almer 07master:69b5ce64d226: Merge commit '07a2b155949eb267cdfc7805f42c7b3375f9c7c5'
[20:11:23 CEST] <jamrial> :D
[20:11:29 CEST] <ubitux> and now, the storm
[20:12:32 CEST] <jamrial> I'm hoping we can just start cleaning without major issues :p
[20:16:28 CEST] <jamrial> whooo wants to deal with some of the private-but-not-really fields stuff in public headers?
[20:17:14 CEST] <jamrial> i'll be cleaning dead code as part of the following merges for a bit
[20:24:11 CEST] <cone-583> ffmpeg 03Carl Eugen Hoyos 07master:535117d1f6de: lavd/lavfi: Constify two variables.
[20:25:50 CEST] <cone-583> ffmpeg 03Carl Eugen Hoyos 07master:ea049ad862a4: lavfi/graphparser: Constify a variable.
[20:27:49 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:88fd836a015a: lavfi: Drop deprecated way of passing options for a few filters
[20:27:50 CEST] <cone-583> ffmpeg 03James Almer 07master:0ed61546c459: Merge commit '88fd836a015a5f3380df74592e440e7d1e5b8000'
[20:29:32 CEST] <ubitux> jamrial: you reached a < 400 commits left checkpoint
[20:29:34 CEST] <ubitux> :)
[20:29:49 CEST] <jamrial> neat
[20:29:59 CEST] <jamrial> to me the real milestone is reaching the bump, though :p
[20:30:08 CEST] <jamrial> it was way too overdue
[20:31:06 CEST] <ubitux> about end of march, yeah
[20:33:45 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:c5c7cfd5e80d: lavfi: Drop deprecated functions to open a filter or a filterchain
[20:33:46 CEST] <cone-583> ffmpeg 03James Almer 07master:7c4f63d05b33: Merge commit 'c5c7cfd5e80d4c36568c01cc40abfde341657ad9'
[20:36:16 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:52067b3c0e5d: lavfi: Drop deprecated filter initialization
[20:36:17 CEST] <cone-583> ffmpeg 03James Almer 07master:5045cf27aacb: Merge commit '52067b3c0e5ddbcf7021a093420798420351a9e2'
[20:38:33 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:8e18328b18e6: lavfi: Drop deprecated filter registration
[20:38:34 CEST] <cone-583> ffmpeg 03James Almer 07master:de0b26ce2886: Merge commit '8e18328b18e69b38a5feae5d10ad01b403a205b6'
[20:45:07 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:96a47364d1cf: lavfi: Drop deprecated non-const filter retrieval
[20:45:08 CEST] <cone-583> ffmpeg 03James Almer 07master:d1b1a65662e3: Merge commit '96a47364d1cf346a5d0437e054b1b10d44d8d969'
[20:49:25 CEST] <atomnuker> jamrial: how does the removal of FF_API_ stuff happen?
[20:49:56 CEST] <atomnuker> does someone need to do each manually?
[20:50:04 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:5e71299758d3: lavf: Drop deprecated bitexact functionality
[20:50:05 CEST] <cone-583> ffmpeg 03James Almer 07master:f02bda3a03c1: Merge commit '5e71299758d3aa7c93c3cca618a8e048a9483794'
[20:50:46 CEST] <jamrial> not really. all the dead code inside these wrappers could be removed in one commit, but doing it separately is cleaner i guess
[20:51:03 CEST] <atomnuker> are you going to do those eventually?
[20:51:51 CEST] <jamrial> i'm doing that right now
[20:52:08 CEST] <jamrial> these merges are dropping most (if not all) of them
[20:53:24 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:263358e0c9e7: lavf: Drop deprecated AVFract type and related field
[20:53:25 CEST] <cone-583> ffmpeg 03James Almer 07master:a295fee28496: Merge commit '263358e0c9e7ffaa965fdbe986c8b18381d2b24a'
[20:54:58 CEST] <atomnuker> jamrial: I've just sent a v2 of your favorite patchset to the ml
[20:55:54 CEST] <atomnuker> (and do remember to remove url_feof from libavformat/libavformat.v)
[20:56:23 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:63fe79a3368c: lavf: Drop deprecated hint to set muxer timebase
[20:56:24 CEST] <cone-583> ffmpeg 03James Almer 07master:1198e34e1189: Merge commit '63fe79a3368cc53e6faf7fa265a9a1a8bec46a88'
[21:00:38 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:bc143ce1ac3f: lavc: Drop deprecated chroma subsample function
[21:00:39 CEST] <cone-583> ffmpeg 03James Almer 07master:c060ed02a865: Merge commit 'bc143ce1ac3f8cd851a7e6be69d9a1fbe6b633b6'
[21:01:05 CEST] <jamrial> atomnuker: eh, i would have rather waited a bit for that
[21:02:27 CEST] <jamrial> as i mentioned in the bump patch i sent to the ml, ffserver can be removed once the month grace period is over since until then we're still able to stop exposing all the internal api
[21:07:37 CEST] <jamrial> sigh, as i expected, your patchset once again touched people's nerves
[21:13:02 CEST] <michaelni> src/fftools/ffserver_config.c:294:15: error: AVCodecContext has no member named rc_eq
[21:16:20 CEST] <ubitux> jamrial: seems you got a new friend
[21:16:22 CEST] <atomnuker> jamrial: maybe cut the month to say, a day or so-ish ^^?
[21:16:34 CEST] <jamrial> atomnuker: i really wish you wouldn't have sent that
[21:16:50 CEST] <jamrial> why the fuck didn't ANYBODY report this ffserver build failure?
[21:16:58 CEST] <jamrial> I sent the fuckign bump patch a month and a half ago
[21:17:15 CEST] <jamrial> i can't deal with this shit
[21:17:43 CEST] <jamrial> why did nobody read it or test it? holy fucking shit i'm mad
[21:17:49 CEST] <michaelni> jamrial, i didnt realize that the bump was imminent
[21:17:50 CEST] <atomnuker> everyone tested with --disable-ffserver?
[21:18:12 CEST] <jamrial> michaelni: it was in the merge queue, and my intention was even to commit before reaching that point
[21:18:15 CEST] <jamrial> and i instead waited
[21:20:57 CEST] <jamrial> now, how to put this field back
[21:21:07 CEST] <jamrial> michaelni: what FF_API removed it?
[21:21:22 CEST] <michaelni> seems FF_API_MPV_OPT
[21:21:31 CEST] <jamrial> i'll just put that back in place until a month passes when we can remove it alongside ffserver
[21:21:42 CEST] <michaelni> agree
[21:22:48 CEST] <jamrial> michaelni: does ffserver build with it back in place?
[21:23:31 CEST] <michaelni> iam atm just testing with the single field in avcodeccontext back in place, it buils but ffmpeg looks very broken
[21:24:12 CEST] <jamrial> how so? fate passes
[21:25:39 CEST] <jamrial> that FF_API has a lot of code in mpegvideo_enc, so the field alone wouldn't do much
[21:26:03 CEST] <michaelni> yes i need to retest with FF_API_MPV_OPT reenabled
[21:28:25 CEST] <atomnuker> jamrial: wouldn't it be easier to just remove the rc_eq field usage from ffserver? its only used in a single place
[21:28:56 CEST] <jamrial> atomnuker: can you do that?
[21:28:58 CEST] <michaelni> FF_API_MPV_OPT wasnt even sheduled to be removed a day ago
[21:29:00 CEST] <jamrial> i have never touched ffserver
[21:29:57 CEST] <atomnuker> jamrial: yeah, just remove the 7 lines it uses to read rc_eq from the config file and set the value in avctx
[21:29:57 CEST] <jamrial> michaelni: the deprecation is older than two years, that's why it was removed
[21:30:09 CEST] <atomnuker> it would act as if rc_eq wasn't specified in the configure file
[21:30:45 CEST] <michaelni> jamrial, anyone testing bumping would not have noticed breakages in code that was not sheduled to be removed before today
[21:31:08 CEST] <jamrial> michaelni: the patch i sent and ultimately commited it disables it
[21:32:54 CEST] <jamrial> the deprecation is from 2013, i have no idea why it was listed with version 59, probably someone thinking a lot more bumps would happen during these four years and wanted to avoid having to constantly edit the line before two years passed
[21:33:21 CEST] <michaelni> i guess somehow noone tested it or maybe i tested and discarded it when it didnt build beliving tat this was work in progress i dont remember
[21:35:44 CEST] <jamrial> i'll reenable it for now if you can confirm ffserver builds with it
[21:36:22 CEST] <jamrial> a month from now we can decide what to do with it. but since it's a four years old deprecated api...
[21:36:59 CEST] <atomnuker> just change a few lines in ffserver_config
[21:38:29 CEST] <jamrial> atomnuker: then please do it. if anything to get ffserver back up while michaelni checks if this api can be safely removed
[21:40:14 CEST] <michaelni> jamrial, fate-api-mjpeg-codec-param fails with FF_API_MPV_OPT toggled back
[21:40:35 CEST] <jamrial> michaelni: that's because the field is readded to avcodec.h
[21:40:44 CEST] <michaelni> yes it needs to be updated
[21:41:00 CEST] <michaelni> build works
[21:41:40 CEST] <jamrial> did removing that api do anything else aside from breaking ffserver build?
[21:41:52 CEST] <michaelni> i dont know
[21:44:59 CEST] <jamrial> atomnuker: can you cook up a patch? if so we can apply that instead
[21:46:14 CEST] <michaelni> are any codecs loosing rc_eq support with this or any other options ?
[21:46:49 CEST] <michaelni> anything supporting the rate control code can use rc_eq
[21:47:17 CEST] <jamrial> the deprecated field mentions codec private options should be used
[21:48:00 CEST] <jamrial> nothing but ffserver was using the avcodeccontext field. anything else was alledgedly already using code private options for the same purpose
[21:48:25 CEST] <atomnuker> jamrial:  https://pars.ee/temp/ffserv_remove_rc_eq.patch
[21:48:32 CEST] <michaelni> f02bda3a03c1103a1c293ad030e6bcf089b21902 <-- breaks bitexact i suspect
[21:49:12 CEST] <michaelni> so i cant test anything anymore as i used this
[21:49:52 CEST] <jamrial> michaelni: that API remove is the one that made -flags +bitexact also trigger -fflags +bitexact
[21:50:02 CEST] <michaelni> or maybe another change broke it
[21:50:07 CEST] <jamrial> it's been deprecated for more than two years and a big warning issued eveyr time it was used
[21:50:37 CEST] <jamrial> the bump disabled it, that merge just removed the dead code cruft
[21:51:09 CEST] <jamrial> all the fate tests were updated to include -fflags +bitexact when required
[21:52:31 CEST] <jamrial> atomnuker: that doesn't make it use the codec private option...
[21:52:42 CEST] <jamrial> i'll just reenable the API and remove it a month from now
[21:52:53 CEST] <atomnuker> jamrial: what do you mean?
[21:52:53 CEST] <jamrial> I'd rather not touch ffserver at all to being with
[21:53:01 CEST] <atomnuker> yeah, ok
[21:53:08 CEST] <jamrial> read the field's deprecation notice
[21:53:29 CEST] <atomnuker> but please make sure that it won't be forgotten to be removed
[21:53:44 CEST] <atomnuker> so it won't become a 6 year old deprecated field by the time it has to be removed
[21:54:31 CEST] <cone-583> ffmpeg 03James Almer 07master:75bd2157272a: avcodec/version: re-enable FF_API_MPV_OPT until the open ABI period is over
[21:54:55 CEST] <michaelni> jamrial, so much gets removed and broken at the same time, its hard to deal with
[21:55:36 CEST] <jamrial> nothing is supposed to be broken... just deprecated API being dropped
[21:55:38 CEST] <JEEB> -34
[21:56:16 CEST] <jamrial> the point of the wrappers is to simply being able to flip a value to disable said deprecated API without breakign anything. FATE passing is what guarantees this
[21:57:06 CEST] <jamrial> admitedly, each API could have been disabled one by one, then the bump made effective
[21:57:13 CEST] <jamrial> wonder why libav didn't do that...
[21:57:23 CEST] <michaelni> that would make bisect also alot easier
[21:57:24 CEST] <jamrial> it was also something that could have been suggested to the patch i sent...
[21:58:04 CEST] <jamrial> anyway, ffserver builds again now that i put rc_eq back in place for the time being
[21:58:09 CEST] <jamrial> sorry for the unintended breakage
[21:58:24 CEST] <atomnuker> jamrial: you fixed it in the worst possible way, now when it gets removed someone will complain you didn't wait
[21:58:25 CEST] <michaelni> i thought (at some point at least) someone would implement a -bitexact option for ffmpeg before -flags +bitexact is droped
[21:58:36 CEST] <atomnuker> you should have just defined it to be 1 with a TODO comment
[21:58:58 CEST] <jamrial> atomnuker: maybe
[21:59:52 CEST] <atomnuker> jamrial: I'm adding a comment, I can't stand and leave it like that
[22:00:03 CEST] <jamrial> ok
[22:00:31 CEST] <jamrial> just keep it simple and obvious that it's in place for a short while
[22:02:15 CEST] <jamrial> atomnuker: maybe also make it 1 if you want
[22:03:23 CEST] <jamrial> michaelni: -flags +bitexact wasn't dropped. it just doesn't imply -fflags +bitexact anymore
[22:03:51 CEST] <michaelni> jamrial, yes, bad wording from me
[22:04:21 CEST] <cone-583> ffmpeg 03Rostislav Pehlivanov 07master:efb79cabb2c8: libavcodec/version: add a comment about FF_API_MPV_OPT deprecation
[22:04:43 CEST] <jamrial> i can't say if anyone ever intended to add a -bitexact option that enables both format and codec flags
[22:07:07 CEST] <michaelni> this changes: ./ffmpeg -f lavfi -i testsrc -vcodec libxvid -vframes 2  -flags +bitexact -fflags +bitexact  file-new.mov
[22:08:02 CEST] <jamrial> in what way?
[22:08:18 CEST] <michaelni> thats a good question
[22:08:22 CEST] <michaelni> file size differs
[22:09:27 CEST] <michaelni> 2nd frame crc changes on decode
[22:10:15 CEST] <michaelni> 0,        512,        512,      512,      194, 0x54ca7b72, F=0x0 vs. 0,        512,        512,      512,      257, 0xbefca5bc, F=0x0
[22:11:05 CEST] <michaelni> Reading option '-vismv' ...Unrecognized option 'vismv'.
[22:11:17 CEST] <michaelni> i guess that was deprecated too ?
[22:11:22 CEST] <jamrial> yeah
[22:11:34 CEST] <jamrial> version.h evne mentions the docs should be updated once it's dropped
[22:11:59 CEST] <michaelni> whats the replacement for -debug 16384 -vismv 7  ?
[22:12:13 CEST] <jamrial> i have no idea, i didn't deprecate any of these APIs
[22:13:14 CEST] <jamrial> looks like ubitux depreacted it in f888331769d
[22:13:20 CEST] <jamrial> three years ago
[22:13:46 CEST] <jamrial> seems the codecview filter is the replacement
[22:21:06 CEST] <michaelni> ok, codecview seems working not bit identica to before but it looks correct for the files i tried
[22:21:56 CEST] <jamrial> michaelni: i think the xvid thing is a default that changed after dropping me_method
[22:22:40 CEST] <jamrial> since default me_method  value was 5, and the private codec option default is 0
[22:23:02 CEST] <jamrial> i'll make sure its that and update the private option default
[22:27:11 CEST] <michaelni> me_method option for snow is failing -motion_est works, theres no warning shown with -me_method previously
[22:29:00 CEST] <jamrial> i don't think any of the deprecated options in options_table-h ever triggered warnings...
[22:29:15 CEST] <jamrial> the deprecation warnings were in the avcodecontext fields
[22:29:56 CEST] <jamrial> and yes, motion_est works after i fixed it last month before sending the bump patch
[22:30:17 CEST] <jamrial> it was one of the preparation fixes for this bump i worked with
[22:30:46 CEST] <michaelni> mpeg2video -me_method fails too the same way
[22:31:38 CEST] <jamrial> yes, me_method was a global option that was deprecated in favor of codec private options
[22:31:56 CEST] <jamrial> it's all stated in the @deprecated doxy for each field...
[22:31:56 CEST] <michaelni> it should have shown a warning if it was to be removed
[22:32:12 CEST] <jamrial> it never did, and how would it anyway from withing options_table.h?
[22:33:14 CEST] <michaelni> yestarday the -me_method command line option worked with no hint on changes, today it fails with no hint for a replacement
[22:33:19 CEST] <michaelni> this is not ideal
[22:33:51 CEST] <jamrial> this is not the first time options_table.h options are removed
[22:34:12 CEST] <jamrial> i don't get why it is an issue now
[22:34:57 CEST] <michaelni> users use case and scripts show no warnings yestarday and today stop working with no hint for what the replacement is
[22:35:08 CEST] <michaelni> its not an issue for me to update my stuff
[22:35:26 CEST] <jamrial> why wasn't this concern raised in previous bumps? or even when deprecations are made effective?
[22:35:35 CEST] <jamrial> scripts are broken all the time
[22:35:43 CEST] <jamrial> we can't handicap development because of that
[22:36:22 CEST] <michaelni> i think handicap is not the right term here
[22:38:21 CEST] <michaelni> options that are going to be removed should have printed a warning, and removed options should tell the user the replacement to use if the removed option is used
[22:38:31 CEST] <michaelni> that IMO of course
[22:39:19 CEST] <jamrial> ok, but that's something to keep in mind for future deprecations
[22:39:50 CEST] <jamrial> can't say how to make options_table.h options do that, though
[22:42:15 CEST] <michaelni> a flag could be added that prints the options help text on use, the help text would then be a deprecation warning pointing to te new option
[22:47:22 CEST] <durandal_1707> come on
[22:55:39 CEST] <michaelni> this changes too: ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg  -vcodec libxavs  -t 1 -flags +bitexact -fflags +bitexact new.avi
[22:56:31 CEST] <jamrial> michaelni: probably motion est defaults again. will take a look
[22:58:03 CEST] <durandal_1707> xavs is dead tech
[22:59:29 CEST] <michaelni> ./ffmpeg -analyzeduration 1M  -y -i ~/videos/matrixbench_mpeg2.mpg -vf setdar=16:9 -vframes 3 test.avi
[22:59:58 CEST] <jamrial> what changes there?
[23:00:15 CEST] <michaelni> DAR 16:9 vs. DAR 9:1 o the output
[23:00:23 CEST] <michaelni> shown in te printout and with ffprobe 
[23:06:38 CEST] <jamrial> i have no idea what could generate that
[23:07:11 CEST] <jamrial> and i still wonder why fate is so incomplete
[23:08:06 CEST] <durandal_1707> abi breach? off by one in struct?
[23:12:09 CEST] <cone-583> ffmpeg 03James Almer 07master:d3a3ee9c7a73: ffserver: remove usage of deprecated rc_eq option
[23:19:47 CEST] <cone-583> ffmpeg 03James Almer 07master:5ae972f63b76: avcodec/v4l2_m2m_enc: fix usage of deprecated codec flag
[23:20:32 CEST] <jkqxz> Heh, I was about to push that one too.
[23:21:21 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:4dee92f6bc8b: hevc: Fix aligned array declarations
[23:21:22 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:e0a967a40546: cinepakenc: Move declaration out of for initialisation statement
[23:21:23 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:e7d20d5e3500: movtextdec: Move declaration out of for initialisation statement
[23:22:28 CEST] <jamrial> jkqxz: ah, sorry
[23:23:14 CEST] <jkqxz> Doesn't matter (it did merge exactly, after all).
[23:28:28 CEST] <jkqxz> Wrt your leak above, the problem is that it's slightly unclear who should free the partial data if reading fails.
[23:29:03 CEST] <jkqxz> On the one hand, it might be useful to get partial output in some case, so the caller could get it and therefore would have to free it.
[23:29:17 CEST] <jamrial> what leak?
[23:29:40 CEST] <jkqxz> On the other, none of the current callers want it and therefore that would just add an extra cleanup call to them for no particular benefit.
[23:30:09 CEST] <jkqxz> The cbs one you posted this morning.
[23:30:15 CEST] <jamrial> oh
[23:31:16 CEST] <jkqxz> So, <http://sprunge.us/MJFL>.
[23:31:20 CEST] <jamrial> michaelni: i fixed the ffserver issue with rc_eq, so i'll undo the patch that put the field back in the struct
[23:31:39 CEST] <jamrial> but i'll do it later in case you're still testing the current tree
[23:38:17 CEST] <jamrial> and i need a break. i'm way too stressed right now
[23:38:28 CEST] <cone-583> ffmpeg 03James Almer 07master:e08897619e0e: avcodec/libxvid: make 4 the default for me_quality
[23:38:29 CEST] <cone-583> ffmpeg 03James Almer 07master:88e2e31d3460: avcodec/libxavs: make dia the default for motion-est
[23:58:34 CEST] <ubitux> jamrial: so can i trash vda now or i should wait?
[23:58:47 CEST] <jamrial> ubitux: you can
[23:59:07 CEST] <ubitux> cool, i'll do that maybe tomorrow or on monday
[23:59:48 CEST] <jamrial> and you don't need to ask me if you can do it. after the bump we have a month or two to make this kind of changes
[00:00:00 CEST] --- Sun Oct 22 2017