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

[burek]

[00:00:34 CET] <michaelni> the way the output is printed looks endian sensitive
[00:01:38 CET] <ubitux> maybe i should remap back endian specific pix fmt to their native ones?
[00:02:19 CET] <michaelni> yeah, these 2 macros need some other way of printing their contents
[00:02:51 CET] <ubitux> speaking of these 2 macros
[00:03:01 CET] <ubitux> http://b.pkh.me/0001-sws-make-is-RGB-BGR-inInt-functions.patch any objection to this?
[00:03:08 CET] <ubitux> (and http://b.pkh.me/0002-sws-tests-pixdesc_query-remove-func-wrappers.patch)
[00:05:26 CET] <michaelni> ubitux, sure if its equivalent, nice cleanup
[00:06:14 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:0bfdcce4d42a: hevc: move the SliceType enum to hevc.h
[00:06:15 CET] <cone-520> ffmpeg 03James Almer 07master:dc39ccdc3b88: Merge commit '0bfdcce4d42a6e654c00ea5f9237dc987626457f'
[00:06:16 CET] <ubitux> jamrial: are you doing merges or i can push some stuff?
[00:06:22 CET] <ubitux> ah i guess you are
[00:06:24 CET] <jamrial> now you can :p
[00:06:46 CET] <cone-520> ffmpeg 03Clément BSsch 07master:bc7308aae820: sws: make is{RGB,BGR}inInt functions
[00:06:48 CET] <cone-520> ffmpeg 03Clément BSsch 07master:99dd6fe62cb4: sws/tests/pixdesc_query: remove func wrappers
[00:06:50 CET] <ubitux> done
[00:51:11 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:59c90097a0ef: hevc: factor out a repeated condition
[00:51:12 CET] <cone-520> ffmpeg 03James Almer 07master:e9d4b3dc375b: Merge commit '59c90097a0eff0dc81fbec15b8900c929859d1e7'
[00:55:47 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:7c9e2b295e4f: Makefile: fix checking whether reconfiguring is required
[00:55:48 CET] <cone-520> ffmpeg 03James Almer 07master:9bcc5e8973ea: Merge commit '7c9e2b295e4f70e8fedf9cceb12d95399a859a9c'
[00:57:15 CET] <jamrial> i remember people complained about the enum value from 0d9b9bd37f43ee29ad9f709d85c8f3be9db71104
[00:57:23 CET] <jamrial> what should we do?
[00:58:17 CET] <nevcairiel> is there any reason why it is 22, its seems super arbitrary
[00:58:39 CET] <nevcairiel> other then being its name, i guess
[01:00:09 CET] <jamrial> i have no idea :p
[01:00:53 CET] <jamrial> matroska uses 22 for it as well
[01:01:31 CET] <jamrial> supposedly, the values are taken from table 2 of ISO/IEC 23001-8:2013/DCOR1
[01:25:13 CET] <nevcairiel> is that the same table that feeds the values in the h264/hevc specs usually?
[01:25:29 CET] <nevcairiel> although some people had concerns about the gap, i guess
[01:30:29 CET] <philipl> BtbN: for what it's worth, the libx264 option is -cqp and not -qp (in the x264 binary, it's -qp). Maybe worth changing for consistency?
[01:31:04 CET] <nevcairiel> would be nice to use the same option for the same things
[01:31:23 CET] <philipl> right
[01:31:23 CET] <JEEB> wouldn't -q:v be the thing for constant quantizer?
[01:31:30 CET] <JEEB> like, in libavcodec general
[01:33:14 CET] <philipl> I dunno, I don't think libx264 uses that.
[01:33:38 CET] <nevcairiel> q is qscale, not sure that really maps to constant qp semantically
[01:34:29 CET] <nevcairiel> but it does set global_quality
[01:34:38 CET] <nevcairiel> which apparently is being faded out due to its weird lambda hackery
[01:35:32 CET] <JEEB> interesting
[01:35:48 CET] <JEEB> I always thought -q:v 0 with libx264 in avcodec would set lossless, for example
[01:35:56 CET] <JEEB> but if it's not constant quant then welp
[01:36:09 CET] <nevcairiel> no q doesnt do a nything with libx264
[01:36:20 CET] <JEEB> cool
[01:37:03 CET] <nevcairiel> philipl: i just checked and it appears libx264 uses -qp, not -cqp
[01:38:16 CET] <nevcairiel> (the struct member is called cqp, but thats just internal, the avoption is called qp)
[01:41:57 CET] <philipl> oh, ok. BtbN did his research.
[01:43:13 CET] <nevcairiel> JEEB: the reason global_quality isnt used is apparently that it doesn't map well to anything. constant-qp isnt really a good "constant quality" mode as depending on the scenes the quality can vary quite a bit, and crf often does a better job at constant quality, but since people know crf under the crf name and know the crf numbers, the global_quality with its mpeg2/4 lambda stuff is just annoying
[08:48:29 CET] <JEEB> nevcairiel: yes, I did know constant quant is not for real usage (other than forcing lossless on >8bit)
[08:48:50 CET] <JEEB> but I didn't know the global quality mess :p
[10:55:45 CET] <wm4_> is there any reason there's no FATE android instance that actually runs fate?
[10:55:51 CET] <wm4_> they all seem to be "build only"
[10:58:13 CET] <wbs> wm4_: you'd need a shared mount (nfs/smb) with the target device, or build on-device for that to be feasible. on the other side, I've got a few fate instances that build with the android toolchain built link the libc statically, and run tests on a normal vanilla-linux
[11:00:14 CET] <wm4_> I find it strange that nobody did that
[11:26:12 CET] <cone-060> ffmpeg 03Vittorio Giovara 07master:0d9b9bd37f43: lavu: Add JEDEC P22 color primaries
[11:26:12 CET] <cone-060> ffmpeg 03Clément BSsch 07master:a44ab512e6b9: lavu/pixfmt: fix redundant comment
[11:26:12 CET] <cone-060> ffmpeg 03Clément BSsch 07master:0b3decc5964b: Merge commit '0d9b9bd37f43ee29ad9f709d85c8f3be9db71104'
[11:34:00 CET] <cone-060> ffmpeg 03Vittorio Giovara 07master:4b07ebf1eb13: mov: Update colr values
[11:34:01 CET] <cone-060> ffmpeg 03Clément BSsch 07master:30ac66abf099: Merge commit '4b07ebf1eb13561492f7e3c30a67f34415016b3e'
[11:41:59 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:043b0b9fb148: Replace leftover uses of -aframes|-dframes|-vframes with -frames:a|d|v
[11:42:00 CET] <cone-060> ffmpeg 03Clément BSsch 07master:71d541751ef1: Merge commit '043b0b9fb1481053b712d06d2c5b772f1845b72b'
[11:46:36 CET] <cone-060> ffmpeg 03Clément BSsch 07master:40ac22601408: lavc/x86/hevc: rename hevc_res_add to hevc_add_res
[11:59:42 CET] <ubitux> dammit these !@#$ cosmetics
[11:59:49 CET] <ubitux> renaming everything and shuffling all the spaces
[12:00:09 CET] <ubitux> adding random _ and shuffling words just to make them different
[12:02:15 CET] <wm4_> heh
[12:09:21 CET] <ubitux> so apparently they prefer a reg loop instead of %rep
[12:09:25 CET] <ubitux> what should i keep?
[12:10:48 CET] <ubitux> add res mmx looks pretty different too
[12:12:06 CET] <atomnuker> I prefer %rep
[12:12:44 CET] <ubitux> ok
[12:13:06 CET] <ubitux> opinion on the differences between TR_ADD_MMX_4_8 and ADD_RES_MMX_4_8?
[12:13:18 CET] <ubitux> (ffmpeg / libav)
[12:13:58 CET] <kierank> atomnuker: you prefer at&t syntax?
[12:13:59 CET] <kierank> wow
[12:14:34 CET] <ubitux> %rep is refering to the pp
[12:14:45 CET] <ubitux> it's not "%reg"
[12:14:52 CET] <ubitux> it's a way of unrolling
[12:17:29 CET] <atomnuker> granted it does increase code when you know how much to loop for but it spares a register
[12:25:17 CET] <kierank> oh %rep
[12:25:22 CET] Action: kierank read %rsp
[12:31:56 CET] <furqan> my ffmpeg hangs while executing this command 
[12:32:13 CET] <furqan> http://pastebin.com/FJTvci6j
[12:34:24 CET] <cone-060> ffmpeg 03Pierre Edouard Lepere 07master:6d5636ad9ab6: hevc: x86: Add add_residual() SIMD optimizations
[12:34:26 CET] <cone-060> ffmpeg 03Clément BSsch 07master:3d6535983282: Merge commit '6d5636ad9ab6bd9bedf902051d88b7044385f88b'
[12:40:23 CET] <cone-060> ffmpeg 03Alexandra Hájková 07master:ed48a9d8143d: checkasm: Add a test for HEVC add_residual
[12:40:25 CET] <cone-060> ffmpeg 03Clément BSsch 07master:3d4039f964e4: Merge commit 'ed48a9d8143d2575a4458589cebde69ec326afd8'
[12:41:41 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:2f806622e127: bktr: Use memset(0) instead of zero initialization for struct sigaction
[12:41:42 CET] <cone-060> ffmpeg 03Clément BSsch 07master:761bbb06ff59: Merge commit '2f806622e1270d3ed1d41a53049a19673dafbe70'
[12:51:41 CET] <cone-060> ffmpeg 03Martin Storsjö 07master:016387fe0fe3: rtmpdh: Don't use the OpenSSL DH struct
[12:51:42 CET] <cone-060> ffmpeg 03Clément BSsch 07master:2c47d243585a: Merge commit '016387fe0fe3eff1a03ec0673bf4d2967f6cad94'
[13:00:23 CET] <cone-060> ffmpeg 03Matt Oliver 07master:ee050797664c: openssl: Support version 1.1.0.
[13:00:24 CET] <cone-060> ffmpeg 03Clément BSsch 07master:fc83de7e1d0e: Merge commit 'ee050797664c7c74cae262ffab05006b55d47a11'
[13:02:10 CET] <cone-060> ffmpeg 03Gwenole Beauchesne 07master:754b20d7ebcc: vaapi_h264: fix RefPicList[] field flags.
[13:02:11 CET] <cone-060> ffmpeg 03Clément BSsch 07master:b0625388411a: Merge commit '754b20d7ebccbe8d316b12128c8cb433d5a516ac'
[13:05:10 CET] <cone-060> ffmpeg 03Mark Thompson 07master:5e879b54a3a4: vaapi_decode: Clear parameter buffers to fix picture reuse
[13:05:11 CET] <cone-060> ffmpeg 03Mark Thompson 07master:0aec37e62582: vaapi_decode: Remove vestigial unmap code
[13:05:12 CET] <cone-060> ffmpeg 03Clément BSsch 07master:9da2b376683b: Merge commit '0aec37e625821040c103641eec9c1e7a1efa2952'
[13:06:47 CET] <cone-060> ffmpeg 03Yogender Gupta 07master:99aeae20de4d: scale_npp: fix passthrough mode
[13:06:48 CET] <cone-060> ffmpeg 03Clément BSsch 07master:99c9e00c685d: Merge commit '99aeae20de4d09ea313fdc619d4e2df825155e62'
[13:09:59 CET] <cone-060> ffmpeg 03Luca Barbato 07master:052b97855de2: aviocat: Support avio options
[13:10:01 CET] <cone-060> ffmpeg 03Clément BSsch 07master:d1ab8c66cf47: Merge commit '052b97855de2396e46682bcbae97f95a258816d4'
[13:10:39 CET] <cone-060> ffmpeg 03Martin Storsjö 07master:f22363c72968: openssl: Avoid double semicolons after the GET_BIO_DATA macro
[13:10:43 CET] <cone-060> ffmpeg 03Clément BSsch 07master:65cb02301acc: Merge commit 'f22363c72968f1a1fc4881d8695ec7068b0aa03c'
[13:12:55 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:14cab426b03a: build: Hardcode avversion.h dependency
[13:12:56 CET] <cone-060> ffmpeg 03Clément BSsch 07master:3a3791a5826e: Merge commit '14cab426b03afd08bc9fe9b6e021a9543c4bdd7e'
[13:14:31 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:255526998501: mpegaudio: Do not print value of uninitialized variable
[13:14:33 CET] <cone-060> ffmpeg 03Clément BSsch 07master:fe7cae38801f: Merge commit '255526998501f0040ae43fe4848c817a97fc578a'
[13:16:40 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:0574780d7a19: h264_loopfilter: Do not print value of uninitialized variable
[13:16:41 CET] <cone-060> ffmpeg 03Clément BSsch 07master:4c840c249dff: Merge commit '0574780d7a196f87ddd89d6362f4c47f3532b4c4'
[13:18:14 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:0456e684394d: audio_fifo: Drop write-only variable
[13:18:15 CET] <cone-060> ffmpeg 03Clément BSsch 07master:2a69724fd5e0: Merge commit '0456e684394dc5a7b98ab9ebb48396d743bf3730'
[13:18:54 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:47756f51fe83: dnxhdenc: Drop pointless, commented-out debug output
[13:18:55 CET] <cone-060> ffmpeg 03Clément BSsch 07master:e809c2e40d7a: Merge commit '47756f51fe836959ffa5c6e2baeacbd71e150069'
[13:19:39 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:c3dad1bf3b5e: nsv: Drop unnecessary TRACE level debug code
[13:19:41 CET] <cone-060> ffmpeg 03Clément BSsch 07master:50a06c841f05: Merge commit 'c3dad1bf3b5e04e01c291b1ac41e6bef0adf2206'
[13:21:48 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:07eea5a5ded1: nut: Drop pointless TRACE level debug code
[13:21:49 CET] <cone-060> ffmpeg 03Clément BSsch 07master:bb9fdd9f616f: Merge commit '07eea5a5ded1141632aefecfa59dcdc26de2d7ea'
[13:24:55 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:ca1e5eea0c7b: Remove some pointless TRACE level debug code
[13:24:56 CET] <cone-060> ffmpeg 03Clément BSsch 07master:1436769c57cc: Merge commit 'ca1e5eea0c7b72a6e30aa6488cfeced3a4853521'
[13:37:13 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:1263b2039eb5: Adjust printf conversion specifiers to match variable signedness
[13:37:14 CET] <cone-060> ffmpeg 03Clément BSsch 07master:46f4f8ad865d: Merge commit '1263b2039eb5aaf1522e9de9f07c787ab30a5f50'
[13:38:34 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:fbe425c8d29e: hap: Adjust printf length modifiers to match variable types
[13:38:35 CET] <cone-060> ffmpeg 03Clément BSsch 07master:63ad47d76b8f: Merge commit 'fbe425c8d29e473a8f69ae2dc52b1a10b77f3b44'
[13:39:17 CET] <ubitux> dammit that next commit
[13:40:35 CET] <nevcairiel> just merge those parts that apply at least somewhat similarly, leave other occurances to be fixed by someone else?
[13:43:26 CET] <ubitux> yeah sure but... technically i should check if we didn't change signdness
[13:43:33 CET] <ubitux> also, some of these a braindead
[13:44:05 CET] <ubitux> most of them actually are
[13:44:50 CET] <ubitux> replacing the %x with PRIx8, like, really? :/
[13:45:32 CET] <JEEB> lol
[13:45:38 CET] <ubitux> yeah i don't want to merge that one, at least no now
[13:45:42 CET] <ubitux> i need to take a break
[13:45:46 CET] <JEEB> gg
[13:45:52 CET] <JEEB> you've done quite a bunch
[13:45:56 CET] <nevcairiel> i have no clue which of those are really properly portable
[13:46:25 CET] <ubitux> (ETA: 725)
[13:46:32 CET] <ubitux> still a long way to go
[13:46:55 CET] <ubitux> we're at end end of oct 2016
[13:47:30 CET] Action: ubitux &
[13:48:53 CET] <atomnuker> ubitux: throughout all the code?
[13:48:57 CET] <atomnuker> why would they do that?
[13:49:28 CET] <nevcairiel> presumably because %x isnt standardized?
[13:49:31 CET] <atomnuker> what's the advantage? PRIx8 does masking for you?
[13:49:48 CET] <wm4> what's the commit?
[13:50:16 CET] <nevcairiel> https://git.libav.org/?p=libav.git;a=commitdiff;h=c454dfcff90f0ed39c7b0d4e85664986a8b4476c
[13:51:12 CET] <atomnuker> even for integers?
[13:51:15 CET] <atomnuker> this is retarded
[13:52:02 CET] <atomnuker> well at least its only for hex
[13:53:15 CET] <wm4> I mean the change is correct
[13:53:24 CET] <wm4> you can't pass int32_t for %d etc.
[13:53:48 CET] <wm4> personally I'd rather cast it like int32_t v; printf("%d", (int)v);
[13:53:51 CET] <wm4> looks less ugly
[13:56:08 CET] <wm4> if you want the ffmpeg equivalent of such correct but pointless changes, it's those fuzz fixes
[13:56:28 CET] <wm4> and other static analyzer stuff
[13:57:48 CET] <ubitux> i'd rather do that instead
[13:58:07 CET] <ubitux> any idea of the tool used? clang static analyzer?
[14:04:05 CET] <wm4> no, I can ask
[14:07:14 CET] <ubitux> oh god
[14:07:21 CET] <wm4> well....
[14:17:24 CET] <ubitux> TimothyGu: what's going on wrt "fate2"?
[15:30:14 CET] <cone-060> ffmpeg 03James Almer 07master:ac42f080991c: x86/hevc_add_res: merge missing changes from 3d6535983282bea542dac2e568ae50da5796be34
[15:44:51 CET] <durandal_1707> fine to push dnxhd parser fix?
[15:47:17 CET] <BBB> finally openssl is fixing its license: https://www.openssl.org/blog/blog/2017/03/20/license/
[15:47:50 CET] <JEEB> yea
[15:48:41 CET] <BBB> ubitux: thanks for doing the merges
[15:53:23 CET] <durandal_1707> ubitux, jamrial still merging something?
[15:53:39 CET] <ubitux> i'm not doing any merge currently
[15:53:50 CET] <jamrial> durandal_1707: not right now, so you can push
[15:54:01 CET] <ubitux> BBB: i'm not alone, but we did around 300/1000 in about a week i'd say
[15:54:21 CET] <ubitux> we'll need one month at this pace to keep up
[15:54:35 CET] <ubitux> (but i'll stop at the end of the week)
[15:54:40 CET] <BBB> j-b: so hows your project to fix this going?
[15:54:58 CET] <durandal_1707> what fixing?
[15:55:22 CET] <BBB> merge libav and ffmpeg back together"
[15:55:31 CET] <j-b> BBB: hahaha
[15:55:38 CET] <j-b> BBB: people are not interested.
[15:55:41 CET] <BBB> :(
[15:55:42 CET] <BBB> I am
[15:55:42 CET] <j-b> so, plonk
[15:55:49 CET] <j-b> and I'm fed up of being insulted.
[15:56:19 CET] <j-b> I should just do a startup and make money, like bitmovin or elemental
[15:56:24 CET] <j-b> instead of caring about floss
[15:56:53 CET] <BBB> the market for bitmovin companies is already saturated
[15:57:03 CET] <BBB> theres literally 13-in-a-dozen versions of that company everywhere
[15:57:11 CET] <j-b> I'll buy and sell buildings then
[15:57:16 CET] <BBB> thats a good idea
[15:57:19 CET] <BBB> you can be president after that
[15:57:30 CET] <j-b> yeah
[15:57:34 CET] <j-b> JB Trump JR
[15:57:35 CET] <BBB> as for elemental, didnt people say it typically wasnt such a great encoder?
[15:57:57 CET] <BBB> or you mean the amazon integration api?
[15:58:56 CET] <ubitux> jamrial: are you looking at the ADD_RES_MMX_4_8 thinh?
[15:58:59 CET] <ubitux> thing*
[15:59:33 CET] <cone-060> ffmpeg 03Paul B Mahol 07master:e1940d245835: avcodec/dnxhd_parser: take into account compressed frame size and skip it
[16:03:23 CET] <durandal_1707> ubitux: regarding dnxd parser commit i picked shorter variant
[16:03:37 CET] <ubitux> okay
[16:03:44 CET] <jamrial> ubitux: it's functionally the same, but instead of doing stuff on four half filled registers it combines the data and does it on two full registers
[16:04:11 CET] <ubitux> any idea why? i doubt that's a change from Diego himself, he may have take it from a more recent code in x264 or something
[16:07:11 CET] <jamrial> ubitux: it was probably alexandra
[16:07:29 CET] <jamrial> but i can't say
[16:08:02 CET] <jamrial> i remember the loop change was hers as recommended by Gramner
[16:08:54 CET] <jamrial> that commit's authorship and comments are kinda wrong/incomplete to be honest
[16:40:44 CET] <BBB> does anyone have experience with reporting bugs to clang?
[16:41:03 CET] <BBB> I tried using the apple bug reporter tool but it seems nobody is looking at those bugs, I have no comments for 2 weeks
[16:46:20 CET] <iive> BBB: clang is not apple product , afaik
[16:58:55 CET] <wm4> iive: it sort of is
[16:59:43 CET] <wm4> I don't remember the history, but I guess they were probably the driving force to make it a realistic gcc replacement...
[16:59:52 CET] <iive> i've heard that they've bought cups
[17:01:35 CET] <wm4> according to wikipedia apple wrote clang and then open sourced it
[17:03:25 CET] <iive> mybad
[17:04:54 CET] <iive> hum, wiki doesn't say that.
[17:08:03 CET] <iive> found it.
[17:19:29 CET] <kierank> BBB: doesn't matter that it was a crap encoder, they had aggressive sales guys
[17:31:35 CET] <JEEB> kierank: aggressive sales team and nice "educational" events do sell indeed
[17:31:48 CET] <kierank> White Papers and being old also sells
[17:31:49 CET] <JEEB> just looking at stuff like the fighter plane competitions in various countries
[17:32:12 CET] <JEEB> it just gets even more big-scale when people put billions on the line
[17:32:29 CET] <JEEB> but yes, White Papers
[17:32:37 CET] <JEEB> also a Very Important Ingredient
[17:33:13 CET] <cone-060> ffmpeg 03Thomas Turner 07master:824fe914fee7: avcodec/tests: added test for celp_math.c
[17:39:25 CET] <ubitux> michaelni: that dubious IsAlmostEqual macro is creating an empty statement
[17:39:44 CET] <ubitux> (its existence as macro also makes no sense btw)
[17:46:47 CET] <michaelni> ubitux, will fix
[17:47:34 CET] <michaelni> just need to double check its still passing on all platforms i can easily test
[17:50:13 CET] <durandal_1707> new release when?
[17:55:16 CET] <michaelni> preferably a month ago ...
[17:55:39 CET] <jamrial> i don't think there's any blocker right now
[17:55:53 CET] <jamrial> the side data size printing thing was fixed
[17:56:14 CET] <michaelni> i think ffplay is broken unless that was fixed today
[17:56:49 CET] <michaelni> i needed to revert one commit locally when i want to test with ffplay ... 
[17:57:15 CET] <jamrial> which one? i thought marton was only working on porting it to the new decode api
[17:57:42 CET] <jamrial> is he aware of it?
[17:58:20 CET] <durandal_1707> we should remove ffplay and use external mpv
[17:59:15 CET] <michaelni> i dont think the issue is in ffplay
[18:00:26 CET] <nevcairiel> for the frame threading thing wm4 posted a patch on the ML, feel free to review to get it along
[18:03:56 CET] <wm4> I think a new release should wait a while
[18:08:20 CET] <jamrial> ubitux or whoever wants to check, i fixed most of the fate failures introduced by merging 8e2ea69135 and pushed to https://github.com/jamrial/FFmpeg/commits/mergework
[18:08:48 CET] <jamrial> the remaining failing test are reporting different extradata size and contents
[18:09:04 CET] <jamrial> probably because of differences in the old code based on the return value of AVParser.split() and the new code creating custom extradata rather than just taking part of the packet raw
[18:18:58 CET] <jamrial> decoding of those h264 samples seems unaffected with the changed extradata
[18:19:34 CET] <durandal_1707> wm4: more than 3 months passed since last release
[18:19:36 CET] <cone-060> ffmpeg 03Michael Niedermayer 07master:d92ad42fb38a: avcodec/tests/celp_math: Change IsAlmostEqual() to a function
[18:22:58 CET] <BBB> kierank: I guess we should all learn from them then
[18:23:33 CET] <BBB> kierank: lets dump our code, forget everything we know, and take an MBA from some expensive suitniversity?
[18:23:55 CET] <kierank> to some extent that is broadcast industry
[18:24:18 CET] <wm4> what code was dumped?
[18:24:20 CET] <kierank> they basically go round saying to broadcasters that you must must must have an OTT encoder
[18:24:30 CET] <kierank> because neflix netflix netflix
[18:24:37 CET] <kierank> and milennials don't want tv
[18:24:45 CET] <kierank> when in fact webcasting has tiny audiences
[18:24:52 CET] <wm4> wtf is OTT
[18:24:59 CET] <kierank> over the top
[18:25:11 CET] <kierank> hls/dash/etc
[18:25:15 CET] <kierank> all http delivered crap basically
[18:25:26 CET] <kierank> i.e no telco/cableco or broadcaster
[18:25:36 CET] <wm4> you're saying there's another adaptive http streaming proto?
[18:25:44 CET] <kierank> smooth streaming
[18:26:00 CET] <wm4> oh I see
[18:31:01 CET] <ubitux> michaelni: what is the multiplication by largest for?
[18:31:40 CET] <michaelni> so the scale for epsilon is correct 
[18:32:43 CET] <jfmcarreira> heyy guys
[18:33:26 CET] <jfmcarreira> where i can find examples of the new API avcodec_receive_frame?? of where it is used on the code so i can have an ideia how to use it :)
[18:58:15 CET] <JEEB> jfmcarreira: there's a patch for it in ffplay on the mailing list, not sure if ffmpeg.c uses it. vlc and mpv also use it
[19:00:50 CET] <jfmcarreira> JEEB: i guess i found the problem.. i guess it is the same behaviour of avcodec_decode_video2
[19:02:21 CET] <wm4> durandal_1707: what does audio threading do differently from video? (see michaelni's reply on the pthread changes)
[19:11:24 CET] <michaelni> jamrial, extradata could also contain global data that isnt essential for decoding, information about bitsteram restrictions, colorspace details, all kinds of other stuff 
[19:20:45 CET] <jamrial> supposedly, this bsf should extract the same information out of the packet as AVParser.split() reports back (for h264, that is sps/vps/pps it seems)
[19:20:47 CET] <jamrial> but in one of the h264 tests, the extradata post patch is 50 bytes instead of 795 bytes
[19:21:25 CET] <jamrial> that said, extract_extradata_h2645 uses ff_h2645_packet_split() whereas h264_split does some manual bitstream parsing
[19:40:29 CET] <uau> wm4: there's nothing obvious about the patch that could affect anything else other than by changing timing (implying a bug elsewhere) or causing a deadlock
[19:40:47 CET] <uau> can you actually reproduce that assertion failure?
[19:43:26 CET] <wm4> uau: didn't try yet
[19:53:59 CET] <cone-060> ffmpeg 03Carl Eugen Hoyos 07master:66c1c9b27749: lavc/xface: Reorder conditions to silence a gcc warning.
[19:55:34 CET] <Compn> michaelni / durandal_1707 / anyone : someone sent me dvr .tfs file , do you want to take a look / reverse engineer it ?
[19:55:50 CET] <JEEB> inb4 encrypted
[19:55:55 CET] <Compn> could be
[19:56:05 CET] <Compn> i think this is standard camera dvr file though (e.g. cctv)
[19:56:09 CET] <Compn> not ... cable dvr
[19:56:14 CET] <JEEB> oh
[19:56:18 CET] <Compn> like lvf format
[19:56:28 CET] <JEEB> goddamnit with these pretty words
[19:56:36 CET] <JEEB> for me DVR has always been broadcast
[19:56:45 CET] <Compn> yea i dont make the names. :(
[19:57:07 CET] <durandal_1707> Compn: is there signature at beggining?
[19:57:27 CET] <durandal_1707> see in hex editor
[19:57:34 CET] <Compn> 6000 series DVR is designed specially for security  and defence field which is an outstanding digital surveillance product. in introduces embedded linux operating system which is more stable.
[19:57:44 CET] <cone-060> ffmpeg 03Paul B Mahol 07release/3.2:a60e66516233: avcodec/dnxhd_parser: take into account compressed frame size and skip it
[19:58:02 CET] <Compn> it introduces standard h.264mp video compressed format and g711a audio compressed format which insures the high quality image. 
[19:58:03 CET] <Compn> heh
[19:58:14 CET] <Compn> the guy sent me the manual for hte dvr too haha
[19:58:35 CET] <Compn> guess i have to de-rar this...
[19:59:18 CET] <durandal_1707> Compn: just upload video file
[19:59:54 CET] <Compn> he uploaded it to this site i paste you addy
[19:59:55 CET] <Compn> :P
[20:00:08 CET] <Compn> lookinmg for my hex editor now...
[20:01:32 CET] <Compn> durandal_1707 : starts with "TSF4"
[20:02:53 CET] <farfel> are there plans to support newer Red Cinema R3D files ?  I realize this is probably a lot of work
[20:03:15 CET] <JEEB> farfel: if someone provides samples and a decoder to RE if there is no specification
[20:03:26 CET] <JEEB> and after that someone needs to get deep
[20:03:27 CET] <Compn> we have samples 
[20:03:39 CET] <JEEB> and in that case if someone can sponsor the work, there are more chances of results
[20:03:46 CET] <farfel> http://www.red.com/sample-r3d-files has sample files _ 8K !
[20:03:55 CET] <Compn> ehe
[20:03:57 CET] <JEEB> since R3D stuff is used in professional context
[20:04:12 CET] <Compn> we get a few people who say that ffmpeg cant handle the complex colorspaces :D
[20:04:20 CET] <JEEB> sure
[20:04:26 CET] <farfel> :)
[20:04:28 CET] <JEEB> that's usually related to colorspace conversions
[20:04:33 CET] <Compn> https://trac.ffmpeg.org/ticket/2690
[20:04:39 CET] <farfel> Bayer 16 bit ?
[20:04:40 CET] <JEEB> because swscale is something I can't wait to have derp'd
[20:05:04 CET] <JEEB> I wonder if zimg can support it
[20:05:14 CET] <durandal_1707> nope
[20:05:20 CET] <Compn> farfel : i dont think there is anyone working on it... 
[20:05:31 CET] <farfel> so, as I understand, R3D is a wrapper around J2K files plus colour space conversion
[20:05:32 CET] <Compn> but usually people work in secret and then drop a huge patch anyhow :D
[20:05:35 CET] <durandal_1707> unless you pay
[20:06:03 CET] <farfel> so, perhaps it would be enough to simply extract the J2K
[20:06:08 CET] <farfel> for starters
[20:06:18 CET] <JEEB> yea, as I noted R3D is a professional thing so if a company or companies want support, some sort of sponsorship through VideoLAN could a good idea
[20:06:18 CET] <durandal_1707> There are more complicated r3d compressions
[20:06:39 CET] <JEEB> since VideoLAN already hosts a bounty page
[20:06:49 CET] <Compn> farfel : for starters would be using the r3d sdk with ffmpeg ;)
[20:06:53 CET] <JEEB> https://wiki.videolan.org/Bounties/
[20:06:53 CET] <durandal_1707> Compn: open bug report with that file
[20:06:56 CET] <Compn> then... we work on other things
[20:07:09 CET] <Compn> durandal_1707 : ok
[20:07:20 CET] <farfel> Compn: would this be fine with LGPL ?
[20:07:33 CET] <JEEB> j-b: wait what is there really a bounty for amarecco? :D
[20:07:33 CET] <farfel> I guess as long as it is not distributed
[20:07:39 CET] <Compn> farfel : of course not distributed
[20:07:50 CET] <farfel> gotcha
[20:07:51 CET] <Compn> the SDK license probably wont allow distribution either
[20:07:55 CET] <farfel> yes
[20:07:56 CET] <Compn> farfel : but the wrapper code is OK
[20:08:01 CET] <farfel> hmmm
[20:08:16 CET] <Compn> well maybe non-free :D
[20:08:17 CET] <Compn> ehe
[20:09:19 CET] <farfel> is it possible that VideoLAN already supports this?
[20:10:03 CET] <Compn> durandal_1707 : uploading now... http://samples.ffmpeg.org/camera-dvr/0000241985.tfs
[20:10:17 CET] <farfel> well, anywho, thanks for the back-story on this format
[20:10:19 CET] <JEEB> farfel: highly unlikely
[20:10:19 CET] <durandal_1707> farfel: why you need this?
[20:10:32 CET] <Compn> farfel : no, r3d is pretty proprietary. dont think there is any open source supporting it right now
[20:10:42 CET] <Compn> (i could be wrong)
[20:11:00 CET] <farfel> durandal: some benchmark for j2k compression used these files, so I wanted to take a look myself
[20:11:14 CET] <farfel> at the images
[20:11:16 CET] <JEEB> right
[20:11:31 CET] <Compn> yeah... great reason for us to spend weeks reverse engineering the format :P
[20:11:43 CET] <Compn> months... years
[20:12:09 CET] <durandal_1707> hmm, if they are real j2k then it should be not hard to grasp it
[20:12:16 CET] <farfel> http://comprimato.com/jpeg2000-is-ready-for-your-8k-video/
[20:12:22 CET] <Compn> farfel : did you know ffmpeg created a codec, ffv1, which some archiving people have started to use instead of j2k ?
[20:12:39 CET] <farfel> yeah, I heard about that: looks very cool. lossless
[20:12:41 CET] <JEEB> (being standardized at the EU level)
[20:12:43 CET] <Compn> and there is now a ffv1 standard... :)
[20:12:52 CET] <JEEB> did it finish?
[20:12:53 CET] <farfel> I like it : J2K is brutally slow
[20:13:05 CET] <farfel> except, it is the standard for cinema
[20:13:08 CET] <JEEB> farfel: yea, almost like it was made for hardware manufacturers
[20:13:08 CET] <farfel> and not going away
[20:13:12 CET] <farfel> :)
[20:13:19 CET] <Compn> farfel : interestingly, videolan supports some DCP i think
[20:13:21 CET] <Compn> or wants to...
[20:13:34 CET] <farfel> yeah, I think you need a 32 core server CPU to get it to play
[20:13:36 CET] <JEEB> yes, we had a demo of that a few years back at VDD
[20:14:01 CET] <Compn> just some hardware decoder... :)
[20:14:08 CET] <farfel> I really wish they did support it in software
[20:14:13 CET] <Compn> wonder if there is consumer hardware j2k decoder
[20:14:22 CET] <JEEB> pretty sure there isn't
[20:14:25 CET] <JEEB> since there's the money in it
[20:14:52 CET] <farfel> if you buy a big-ass server box, you can use OpenJPEG
[20:14:55 CET] <farfel> to decode
[20:14:58 CET] <farfel> so
[20:15:12 CET] <Compn> is openjpg faster than ffjpeg decoder? hmm
[20:15:28 CET] <farfel> sorry, but yes it is
[20:15:39 CET] <JEEB> yea
[20:15:49 CET] <JEEB> also the effing weirdly licensed fork of it I think
[20:15:58 CET] <farfel> yes
[20:16:07 CET] <Compn> no one wrote new asm for old jpeg decoder? :P
[20:16:45 CET] <farfel> assembly is the key, but that takes a lot of time
[20:16:57 CET] <farfel> just throw a few Ryzen at the problem
[20:17:39 CET] <durandal_1707> openjpeg2000 is flawed
[20:17:49 CET] <farfel> really?
[20:18:10 CET] <farfel> you mean large attack surface? any codec has that problem
[20:18:28 CET] <durandal_1707> yes see bugs on bug tracker on github
[20:19:02 CET] <farfel> here is an interesting fact: project lead works for a hardware j2k board manufacturer
[20:19:38 CET] <farfel> I suppose they don't want high quality software codec taking business away
[20:19:46 CET] <Compn> farfel : so can you use r3d sdk to extract jp2k out of .r3d files ?
[20:19:59 CET] <farfel> Compn: don't know, will give it a try
[20:20:49 CET] <farfel> but won't look good without colour conversion, I guess
[20:21:06 CET] <farfel> I will see what I can do in a day or so
[20:21:07 CET] <Compn> maybe sdk does it too who knows
[20:21:29 CET] <farfel> yes, that is true - I was just hoping for the open solution
[20:21:31 CET] <cbsrobot> I thought kakadou can decompress 2k j2k files on moderate hw
[20:21:55 CET] <farfel> Yes, someone made a Kakadu patch for FPGA
[20:21:59 CET] <farfel> a while ago
[20:22:13 CET] <farfel> Kakadu is rather expensive
[20:22:14 CET] <farfel> though
[20:23:00 CET] <Compn> red cameras still sub $3k ?
[20:23:01 CET] <cbsrobot> frauenhofer easydcp uses the kakadu lib and it plays dcp - well maybe at a lower res (not sure)
[20:24:53 CET] <farfel> yes, I think they often do replay at 1/4 size, and full res when pause
[20:25:08 CET] <cbsrobot> farfel: I'd be happy for any speed improvement on j2k
[20:25:27 CET] <cbsrobot> btw are you behind grok ?
[20:25:38 CET] <farfel> yep
[20:26:11 CET] <cbsrobot> I'd be glad to talk about it but I need to leave now
[20:26:19 CET] <cbsrobot> maybe we can talk later ...
[20:26:25 CET] <farfel> np, will be back
[20:26:27 CET] <farfel> later
[20:26:33 CET] <farfel> have to go too - cheers everyone
[20:30:58 CET] <Compn> cya
[20:41:32 CET] <tlshum> hi, I'm curious if anyone has already expressed interest in implementing DICOM support in GSoC
[20:41:43 CET] <tlshum> i'd have hilighted cehoyos but they don't seem to be here
[20:45:48 CET] <Compn> dicom was suggested to another student
[20:45:51 CET] <Compn> in my irc logs
[20:46:18 CET] <Compn> but i dont know what they chose... 
[20:46:26 CET] <Compn> durandal_1707 might know
[20:47:20 CET] <durandal_1707> i dont know, ask carl via email
[20:49:36 CET] <tlshum> thank you both. would carl mind if I end up sending what amounts to an unsolicited email directly to him
[20:49:49 CET] <tlshum> or is there some sort of procedure that i should follow?
[20:50:29 CET] <Chloe> You could email him to ask if you can email him? 
[20:51:39 CET] <tlshum> i could probably ask him the question via email, along with asking if he's fine with me continuing to email him
[20:51:51 CET] <tlshum> since the first email would just be wasting his time
[21:04:59 CET] <jamrial> michaelni: pushed a "fix" for the h264 failures
[21:05:50 CET] <jamrial> basically, just copied the code from h264_split(), since the parsing code in the bsf was discarding several nals that apparently are needed in extradata
[21:16:38 CET] <Compn> tlshum : please feel free to email carl direct
[21:17:04 CET] <Compn> carl is a mentor? i think? so he has accepted being a contact for GSOC students...
[21:19:39 CET] <tlshum> thanks for the reassurance! I wasn't sure about the etiquette here
[21:27:02 CET] <ubitux> how do people manage their fate instances here? is there anything smarter than running custom shell script in a screen or through cron?
[21:41:22 CET] <nevcairiel> thats what i do,  timed custom script :d
[22:40:48 CET] <ubitux> nevcairiel: the sample you uploaded is available on rsync://fate-suite.ffmpeg.org/fate-suite/ but not rsync://fate.ffmpeg.org/fate-suite/
[22:41:04 CET] <nevcairiel> why is there both with different content
[22:41:09 CET] <ubitux> don't ask me
[22:41:11 CET] <ubitux> :D
[22:41:17 CET] <nevcairiel> fate-suite is the official URL we reference in the makefile
[22:41:42 CET] <ubitux> my old script uses fate.ffmpeg.org
[22:41:47 CET] <ubitux> like probably many of the other instances
[22:42:31 CET] <nevcairiel> fate-rsync:
[22:42:31 CET] <nevcairiel> rsync $(RSYNC_OPTIONS) rsync://fate-suite.ffmpeg.org/fate-suite/ $(SAMPLES)
[22:42:34 CET] Action: nevcairiel shrugs
[22:42:44 CET] <nevcairiel> i only have access to that one
[22:43:31 CET] Action: ubitux looks at michaelni :°
[22:44:11 CET] <nevcairiel> i dont know where the other url even ever came from
[22:44:41 CET] Action: michaelni runs fate rsync sync script
[22:44:49 CET] <nevcairiel> 236ecc3502e35b4f513c19c542075dc5737a4633 changed it apparently
[22:44:52 CET] <nevcairiel> 5 years ago
[22:45:00 CET] <ubitux> my script is older :3
[22:45:27 CET] <nevcairiel> this is your chance!
[22:45:27 CET] <nevcairiel> :D
[22:45:52 CET] <ubitux> i'm updating my script but other fate instances will continue failing
[22:45:53 CET] <nevcairiel> michaelni: is that on a cron job otherwise, or do we have to upload it twice?
[22:46:11 CET] <nevcairiel> i think i uploaded it ov er 24 hours ago already now
[22:47:55 CET] <michaelni> its just a local script with a few rsync commands, i need to run it for one of my fate clients too IIRC. I forgot running it
[22:51:04 CET] <cone-060> ffmpeg 03Clément BSsch 07master:b68068eed20e: fate: mask errors while constructing report files
[23:04:12 CET] <TimothyGu> ubitux: huh?
[23:09:31 CET] <ubitux> TimothyGu: wasn't there some fate beta at some point?
[23:09:44 CET] <ubitux> and an oracle-like
[23:09:48 CET] <ubitux> and all kind of stuff?
[23:10:59 CET] <ubitux> oh there is still actually fatebeta.ffmpeg.org 
[23:11:12 CET] <ubitux> when is it going to replace the current one?
[23:11:20 CET] <BtbN> It did
[23:11:25 CET] <BtbN> Unless there is already a new beta
[23:12:07 CET] <ubitux> well i mean replace fate.ffmpeg.org
[23:12:32 CET] <BtbN> yes, I'm pretty sure that already happened quite a while ago
[23:12:42 CET] <BtbN> Probably just wasn't ever taken down
[23:12:44 CET] <nevcairiel> it did not
[23:12:47 CET] <TimothyGu> IIRC it iddn't
[23:12:57 CET] <nevcairiel> fatebeta has release branch tabs
[23:12:59 CET] <nevcairiel> fate does not
[23:13:13 CET] <nevcairiel> (which is the main feature i would really like to have, the release branches really crowd the list)
[23:13:14 CET] <TimothyGu> I wanted to do it (and sent an email to the list saying I'd do it) but it never materialized
[23:13:16 CET] <BtbN> I remember talk about it replacing the normal fate from months ago
[23:13:55 CET] <TimothyGu> in short it just got stalled. more important things in real life (like university applications) took precedence
[23:14:25 CET] <ubitux> ok :(
[23:32:59 CET] <jamrial> there, patchset sent
[23:47:05 CET] <ubitux> jamrial: nice :)
[23:47:17 CET] <ubitux> i'm currently making up a freedos fate instance&
[23:47:25 CET] <ubitux> kill T_T
[23:47:29 CET] <ubitux> kill me T_T
[23:47:38 CET] <jamrial> of all the missing targets, you're doing that one? :p
[23:47:52 CET] <JEEB> le djgpp face
[23:48:17 CET] <ubitux> jamrial: i need it to merge the next commit properly
[23:48:41 CET] <ubitux> btw, i started migrating my fate instances, so they should be back in the green
[23:49:20 CET] <jamrial> the printf specifiers one?
[23:49:22 CET] <ubitux> i still miss ones though, like coverage, enable shared, old yasm or icc 
[23:49:25 CET] <ubitux> jamrial: yes
[23:55:38 CET] <jpabq_> I read that the proper way to submit a patch, was to email it to the ffmpeg developer email list.   Is that correct?
[23:56:04 CET] <jpabq_> ffmpeg only uses the ticket system for problem reports?
[23:56:04 CET] <JEEB> yes, git send-email nicely can handle it for you as well :)
[23:56:49 CET] <jpabq_> I submitted a patch a few days ago.   I just discovered that it does not handle ALL cases, so I need to submit a replacement.   Should I just reply to the email I sent originally?
[23:57:11 CET] <JEEB> you can do that :)
[23:58:49 CET] <jpabq_> `git send-email` is problematic for me, since I am developing this at work and a machine that does not have email configured :(    I ended up using git-format-patch and then attaching the result.  I hope that is acceptable. 
[23:59:00 CET] <JEEB> should be
[23:59:27 CET] <JEEB> you can also check if patchwork was able to grasp your patch https://patchwork.ffmpeg.org/project/ffmpeg/list/
[23:59:40 CET] <RiCON> jpabq_: you can also use gmail's smtp
[00:00:00 CET] --- Sat Mar 25 2017