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

[burek]

[00:01:27 CEST] <mateo`> is there is a way to disable the automatic insertion of the bsf by an option for example, we can let the user do that when they use MediaCrypto
[00:01:56 CEST] <wm4> you could provide separate AVCodec entries
[00:02:10 CEST] <wm4> so you could feed them whatever brainfucked packet data they have
[00:04:42 CEST] <mateo`> so we would have h264_mediacodec and h264_mediacodec_nobsf_drm_whatever, right ?
[00:06:57 CEST] <wm4> yes
[00:07:20 CEST] <wm4> "shit" is shorter than "nobsf_drm_whatever", so I suggest that as name
[00:08:10 CEST] <jamrial> or just h264_mediacrypto, so users actually know what's being used :p
[00:08:51 CEST] <mateo`> h264_mediacryptoshit then :)
[00:09:01 CEST] <JEEB> :)
[00:09:25 CEST] <JEEB> oh
[00:09:27 CEST] <JEEB> https://github.com/android-ndk/ndk/issues/382
[00:09:29 CEST] <JEEB> maybe related?
[00:09:34 CEST] <mateo`> well, i'm sold, i'll port the mediacodec wrapper to the auto-bsf insertion
[00:10:28 CEST] <JEEB> although mateo` - you say r14b WorksForYou?
[00:11:22 CEST] <mateo`> JEEB: yes r14b works for me, and we don't use the NDK API (at least directly)
[00:11:49 CEST] <JEEB> ok
[00:11:58 CEST] <JEEB> I will give r14b a fly after I get some sleep
[00:49:32 CEST] <cone-524> ffmpeg 03Michael Niedermayer 07master:4bcde26172ba: avcodec/dvbsubdec: Use av_image_check_size2()
[00:49:32 CEST] <cone-524> ffmpeg 03Michael Niedermayer 07master:e1b0044c2347: avcodec/dvbsubdec: Check pixel buffer size constraint from ETSI EN 300 743 V1.3.1
[00:49:32 CEST] <cone-524> ffmpeg 03Michael Niedermayer 07master:09096fb68713: avcodec/h264_parse: Check picture structure when initializing weight table
[00:57:29 CEST] <J_Darnley> the amount of nested ifs and && and || in idctdsp_init is horrible
[01:45:09 CEST] <J_Darnley> Now how did fate not catch that bug?  I set idct_put to an idct_add function.
[02:28:01 CEST] <KGB> [13FFV1] 15michaelni pushed 2 new commits to 06master: 02https://git.io/vHDGJ
[02:28:01 CEST] <KGB> 13FFV1/06master 140ba8a4c 15Dave Rice: expanding on median predictor section...
[02:28:01 CEST] <KGB> 13FFV1/06master 149fc9544 15Michael Niedermayer: Clarify where t,l,tl,tr come from....
[09:36:55 CEST] <hanna> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b378f5bd640 does anybody have an example of a file that includes such metadata?
[09:37:13 CEST] <hanna> I want to work on mpv's implementation of MaxCLL/MaxFALL and HDR10, but I can't seem to find a test clip
[13:17:06 CEST] <J_Darnley> kierank, BBB, atomnuker: after some more work I think I have managed to speed up decoding of a real mpeg2 HD sample from 215 to 235 fps
[13:17:16 CEST] <BBB> sweet
[13:17:21 CEST] <BBB> with the idct?
[13:17:28 CEST] <J_Darnley> Yes
[13:17:35 CEST] <JEEB> coolio
[13:17:48 CEST] <nevcairiel> almost 10% jus from idct sounds quite neat
[13:18:37 CEST] <J_Darnley> I will send an intermediate series of patches because I still need to make a small optimisation by making a large change to the macros in that file.
[13:27:18 CEST] <cone-161> ffmpeg 03Michael Bradshaw 07master:50be8f214250: fate: add test for -time_base option
[13:29:21 CEST] <kierank> J_Darnley: nice
[13:29:42 CEST] <kierank> this is without any sse specific optimisations, right?
[13:29:50 CEST] <kierank> I have lost track a bit tbh
[13:42:01 CEST] <kierank> We need a newsletter called "weekly ffmpeg drama updates"
[13:45:13 CEST] <J_Darnley> :)
[13:45:57 CEST] <J_Darnley> You mean early termination for 0 coeffs, right?  No.  it still none of those.
[13:48:06 CEST] <BtbN> Has anyone ever successfully built this new "mysofa" dependency?
[13:48:11 CEST] <BtbN> I can't get it to build no matter what
[13:48:44 CEST] <JEEB> someone said only the git HEAD or something works
[13:48:52 CEST] <BtbN> that's what I'm using
[13:49:02 CEST] <JEEB> sounds like fun
[13:49:10 CEST] <BtbN> https://bpaste.net/show/e7e1c7e1d347
[13:49:31 CEST] <RiCON> BtbN: i did in mingw, only in static
[13:49:58 CEST] <BtbN> this is Linux, Ubuntu 17.04. Just plain cd build, cmake .., make
[13:50:58 CEST] <RiCON> i used -G ninja, didn't try with make
[13:51:20 CEST] <BtbN> it looks like messed up dependencies to me
[13:53:30 CEST] <kierank> J_Darnley: yeah
[13:53:43 CEST] <kierank> J_Darnley: i am also trying to understand the SUINT thread
[13:53:56 CEST] <kierank> this week has been too full of IRL drama (uk politics) as well
[13:54:24 CEST] <BtbN> yeah, it works if I manually make mysofa-static first, and then make
[13:55:10 CEST] <RiCON> BtbN: -DBUILD_TESTS=no also works
[13:55:23 CEST] <BtbN> yeah, guess I don't need them
[13:56:07 CEST] <BtbN> https://github.com/hoene/libmysofa/blob/master/src/CMakeLists.txt#L35
[13:56:08 CEST] <BtbN> this
[13:56:10 CEST] <BtbN> this is bullshit
[13:58:00 CEST] <RiCON> lol
[13:58:18 CEST] <RiCON> https://github.com/hoene/libmysofa/pull/11/files
[13:58:29 CEST] <RiCON> looks like he doesn't too hard on PRs
[13:58:31 CEST] <RiCON> look+
[13:58:39 CEST] <BtbN> it was broken before the PR
[13:58:41 CEST] <BtbN> the PR just moved it
[13:58:49 CEST] <BtbN> https://github.com/hoene/libmysofa/pull/11/files#diff-95e351a3805a1dafa85bf20b81d086e6L24
[13:58:50 CEST] <RiCON> oh, right
[13:59:08 CEST] <BtbN> I can't think of a sane reason for that
[13:59:10 CEST] <BtbN> gonna PR a fix
[14:19:13 CEST] <BBB> J_Darnley: patch sounds good to me
[15:34:10 CEST] <BtbN> I don't understand what's going on with the coverity container. The moment I update it to the latest Ubuntu or Debian, the build just freezes
[15:36:46 CEST] <J_Darnley> "I'm afraid I can't let you use software that new, Dave."
[15:36:59 CEST] <BtbN> But which software?
[15:37:05 CEST] <BtbN> It works on 16.10, and that also uses gcc-6
[15:37:23 CEST] <J_Darnley> Sorry, I really have no idea.
[15:37:35 CEST] <BtbN> oh, nevermind. It continued
[15:37:39 CEST] <JEEB> :)
[15:37:44 CEST] <BtbN> After like 10 minutes of sitting on the first 4 files
[15:38:00 CEST] <BtbN> I guess it downloaded stuff in the background or something
[15:52:52 CEST] <BtbN> wow, it spends like 10 minutes on stripping all the binaries. I know what I'm going to disable to save some build time
[15:53:21 CEST] <BtbN> hm, I wonder, can I disable linking? As stupid as it sounds.
[16:47:35 CEST] <BtbN> --ld=/bin/true will probably do the trick
[16:47:49 CEST] <BtbN> at least I hope so
[16:47:52 CEST] <cslcm> that's bad and you should feel bad
[16:48:06 CEST] <BtbN> why? I just don't want or need to link
[16:48:08 CEST] <BtbN> only compile
[16:48:16 CEST] <cslcm> it's correct, it's just dirty
[16:48:22 CEST] <BtbN> better idea?
[16:49:25 CEST] <cslcm> there's gotta be a compile only thing for cmake
[16:54:42 CEST] <BtbN> ffmpeg does not use cmake
[16:56:21 CEST] <BtbN> libavformat/network.c:234:5: error: implicit declaration of function 'closesocket' [-Werror=implicit-function-declaration]
[16:56:22 CEST] <BtbN> what?
[16:56:33 CEST] <BtbN> How does using /bin/true as LD trigger that?
[16:57:05 CEST] <BtbN> oh, I guess because It breaks configure...
[16:57:58 CEST] <JEEB> :D
[17:04:05 CEST] <BtbN> sed -i on ffbuild/config.mak after configure!
[20:58:31 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:54aaadf64807: avcodec/cfhd: Check band parameters before storing them
[20:58:31 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:90e8317b3b33: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int'
[21:28:22 CEST] <ubitux> looks like ff_ps_stereo_interpolate_neon is broken on arm
[21:32:09 CEST] <jamrial> ubitux: have access to an arm board, or using qemu?
[21:32:30 CEST] <ubitux> i'm testing on an arm board right now
[21:32:42 CEST] <ubitux> i have a bunch of them in 32-bit
[21:32:54 CEST] <ubitux> it's a decent 64-bit one i'm in need currently
[21:32:58 CEST] <uau> hmm wtf does that srt_to_ass() conversion function do with the persistent "an" variable anyway? it looks as if it was letting arbitrary {\foo} tags through but only between the first {\aN} and second???
[21:33:12 CEST] <uau> ubitux: you've at least touched that code, do you have any idea what it's supposed to do?
[21:34:45 CEST] <ubitux> arbitrary positioning
[21:34:52 CEST] <ubitux> is there something broken with it?
[21:35:03 CEST] <ubitux> (wouldn't be a surprise tbh)
[21:35:48 CEST] <uau> well what i meant above is that it seems to be letting _any_ ASS tag whatsoever through between {\a1} etc tags
[21:36:56 CEST] <uau> what is the purpose of the "an" variable there supposed to be?
[21:37:44 CEST] <ubitux> check the comments
[21:38:01 CEST] <ubitux> an5 is when the positioning is defined through a rectangle (so it's centered in it)
[21:38:15 CEST] <ubitux> and an1 happens when only 1 coordinate is given
[21:38:21 CEST] <ubitux> so it's aassuming top-left corner
[21:39:18 CEST] <uau> which comment? if you mean the "skip all {\xxx} substrings except for {\an%d} and all microdvd like styles such as {Y:xxx}" one, I don't see how it'd match the code
[21:40:55 CEST] <ubitux> wait
[21:41:04 CEST] <ubitux> what code are you talking about?
[21:41:17 CEST] <ubitux> aren't you refering to lavc/srtdec.c:srt_to_ass() ?
[21:42:10 CEST] <ubitux> ah you are in ff_htmlmarkup_to_ass?
[21:42:33 CEST] <uau> yes i guess i used the wrong name due to looking at its history
[21:42:48 CEST] <ubitux> so you're looking at the an sscanf?
[21:43:03 CEST] <uau> yes, and specifically why the code keeps that "an" variable
[21:43:05 CEST] <ubitux> yeah i didn't write that code, i think it ages from aurelien after i wrote it in mplayer
[21:43:45 CEST] <ubitux> yeah so it's skiping ASS tags present in srt
[21:44:17 CEST] <ubitux> and the \an ones are relatively common in srt
[21:44:24 CEST] <ubitux> so i think that's the rational behind this
[21:45:19 CEST] <uau> yeah, the "skip all {\xxx} substrings except for {\an%d} and all microdvd like styles such as {Y:xxx}" comment mostly makes sense - but i don't see how the behavior of the code would quite match that, and why the "an" variable...
[21:46:30 CEST] <ubitux> so an var counts the number of expected an...
[21:46:45 CEST] <ubitux> let me try to understand..
[21:47:20 CEST] <ubitux> ok
[21:47:26 CEST] <ubitux> i think it's just skipping the first one
[21:47:37 CEST] <ubitux> but if there is one in the middle it's assuming it's really wanted?
[21:48:07 CEST] <ubitux> wait no
[21:48:30 CEST] <ubitux> omfg that len = 0 in the middle
[21:50:55 CEST] <ubitux> uau: yeah i guess it honors only the first one
[21:51:02 CEST] <ubitux> i think that's it
[21:51:13 CEST] <uau> i'm trying to think of what kind of stupidity could result in that code if the effect is not intentional
[21:51:35 CEST] <uau> my best guess i that the intent of the persistent variable was to only copy the first {\an
[21:51:43 CEST] <ubitux> what you comonly see is an {an} tag at the begining of every subtitle event
[21:51:48 CEST] <durandal_1707> atomnuker: have you written filter?
[21:51:51 CEST] <kierank> J_Darnley: maybe you should push your changes
[21:51:54 CEST] <kierank> and then improve later
[21:52:01 CEST] <durandal_1707> push
[21:52:15 CEST] <durandal_1707> better than suint
[21:52:22 CEST] <uau> and that aurelien missed that it would also allow any OTHER tags while the variable stays at 1
[21:52:32 CEST] <kierank> durandal_1707: can you explain suint drama to me
[21:52:41 CEST] <ubitux> uau: so basically i think he wanted to honor subtitles with a "global" alignment at every event, and then ignore any alignment in the middle which would probably be very "ass specific"
[21:52:59 CEST] <ubitux> (or anything else ass specific)
[21:53:02 CEST] <ubitux> that's my guess
[21:53:18 CEST] <ubitux> feel free to rework this
[21:53:25 CEST] <durandal_1707> kierank: no, its plan to make ffmpeg code one big mpegvideoenc
[21:53:36 CEST] <ubitux> i really don't like that these tags honored at all
[21:53:39 CEST] <kierank> durandal_1707: ?
[21:54:01 CEST] <durandal_1707> kierank: makes code hard to follow
[21:54:13 CEST] <kierank> I agree, i just don't understand what it solves
[21:54:21 CEST] <kierank> why not just make it unsigned
[21:54:27 CEST] <durandal_1707> and now those weird timeouts 
[21:54:31 CEST] <ubitux> jamrial: http://sprunge.us/ibaT
[21:54:38 CEST] <ubitux> jamrial: do you think these mismatch are legit?
[21:54:41 CEST] <durandal_1707> want to make code worse
[21:54:55 CEST] <ubitux> jamrial: like, they fail with an eps > 0.01...
[21:54:59 CEST] <iive> kierank: some operations need a signed type to work properly, e.g. shifts
[21:55:12 CEST] <jamrial> ubitux: try FLT_EPSILON instead
[21:55:18 CEST] <jamrial> include <float.h> for it
[21:55:22 CEST] <durandal_1707> iive: it just teory
[21:55:23 CEST] <iive> kierank: and you need other operations as unsigned to avoid undefined behavior 
[21:55:33 CEST] <ubitux> jamrial: FLT_EPSILON is really really low
[21:55:44 CEST] <ubitux> 0.01 is extremely large
[21:55:49 CEST] <ubitux> and it's still mismatching
[21:55:54 CEST] <iive> there are 2 gcc options that control how gcc generates code for signed overflow
[21:55:59 CEST] <uau> kierank: my understanding is that michael's use case for SUINT is variables that should not ever overflow to get different behavior in different builds in error cases where they DO overflow
[21:56:05 CEST] <iive> one makes it handle it as unsigned overflow.
[21:56:19 CEST] <iive> this however might make some code slower, e.g. simple loops
[21:56:28 CEST] <kierank> uau: i still don't get it
[21:56:46 CEST] <kierank> they overflow, we fix, ???
[21:56:54 CEST] <iive> the other option makes signed overflow a fatal error, that would terminate the program
[21:56:57 CEST] <kierank> or is this for some kind of overflow accumulation?
[21:56:59 CEST] <uau> if you make them unsigned that means there is in undefined behavior even if they do overflow (whether nominally avoiding undefined behavior is actually an improvement over overflow depends, i guess...)
[21:57:25 CEST] <kierank> ok
[21:57:43 CEST] <uau> but on the other hand he wants to keep them signed because some tooling specifically checks for cases of signed behavior as that indicates bugs
[21:57:45 CEST] <kierank> makes more sense
[21:58:07 CEST] <kierank> hmm
[21:58:30 CEST] <uau> so he wants to run fuzzing or other tests under builds that have those variables signed and with extra checks that detect when signed overflow happens
[21:59:15 CEST] <atomnuker> durandal_1707: partly, I don't do anything with the FFT coeffs currently
[21:59:54 CEST] <atomnuker> I plan to reuse the ffopus transient detector but tweak it to detect quiet spots and use them as a noise signature
[22:00:24 CEST] <jamrial> ubitux: 0.01 or 0.001? the test in your branch has the latter
[22:00:28 CEST] <atomnuker> (and make it update the noise signature on the next quiet spot)
[22:00:50 CEST] <ubitux> jamrial: yeah i reduced even more, but look at the paste
[22:00:57 CEST] <ubitux> there is a clear mismatch > 0.01
[22:01:10 CEST] <ubitux> 0.001 is already pretty high..
[22:01:46 CEST] <jamrial> floatdsp uses 0.005 and 0.008 for some tests
[22:02:17 CEST] <jamrial> but yeah, you're right about that paste
[22:02:41 CEST] <jamrial> wonder why none of the aac tests fail then
[22:03:10 CEST] <jamrial> but then again, the ipdopd test didn't even notice i fucked up one instruction...
[22:06:27 CEST] <jamrial> ubitux: wonder if replacing vmla with vmul + vadd would help
[22:06:44 CEST] <jamrial> multiply add accumulate tends to be less precise. at least on x86
[22:07:43 CEST] <Gramner> fma is more accurate than mul+add on x86 since it doesn't do intermediate rounding
[22:08:49 CEST] <jamrial> really? odd, i remember it as the opposite
[22:08:55 CEST] <Gramner> assuming accurate means "as close to infinite precision as possible" and not "as close to IEEE 754 rounding as possible"
[22:10:01 CEST] <Gramner> C code does the latter, so it will differ more from C
[22:15:07 CEST] <Gramner> "VFMADD132PS: Multiplies [...], adds the infinite precision intermediate result [...], performs rounding and stores [...]"
[22:15:16 CEST] <Gramner> from the intel manual
[22:17:58 CEST] <jamrial> ok, that's cool
[22:33:09 CEST] <jamrial> ubitux: can you test https://pastebin.com/5iyDhRS7 on arm while at it?
[22:35:31 CEST] <jamrial> the arm neon version of hybrid_synthesis_deint probably only works with a few values of i (the ones the decoder explicitly uses)
[22:35:58 CEST] <jamrial> so making the test try everything from 0 to 63 will probably fail
[22:41:14 CEST] <ubitux> jamrial: i'll try that later yeah
[22:41:22 CEST] <ubitux> we should probably start merging the checkasm tests btw
[22:41:27 CEST] <ubitux> since you're already working on top
[22:42:16 CEST] <jamrial> i wrote an x86 version of hybrid_synthesis_deint, btw
[22:43:24 CEST] <jamrial> but like with the arm version i kept in mind that aacdec always sets len to 32, and i to either 3 or 5
[22:43:43 CEST] <jamrial> it saved me a bunch of instructions and register use
[22:45:00 CEST] <jamrial> making it work for any value of len and any value of i shouldn't be hard, but probably not worth it
[22:50:42 CEST] <Gramner> if a value is hardcoded it'd probably be better to actually hardcode it instead of having it as a parameter that doesn't work
[22:51:54 CEST] <jamrial> i guess. if someone can adapt the arm version then it could be done
[00:00:00 CEST] --- Sun Jun 11 2017