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

[burek]

[00:26:06 CEST] <cone-093> ffmpeg 03Michael Niedermayer 07master:1f53bde6d817: avcodec/h264_slice: Fix overflow in slice offset
[00:26:07 CEST] <cone-093> ffmpeg 03Michael Niedermayer 07master:1e443051b277: avcodec/aacdec_fixed: fix invalid shift in predict()
[03:01:31 CEST] <jamrial> does anyone know how to report bugs to clang and can do it? because clang since version 5 is miscompiling the jpeg encoder (and maybe also decoder)
[03:02:01 CEST] <jamrial> probably only encoder
[03:13:03 CEST] <thebombzen> jamrial: probably on their bug tracker :P
[03:14:17 CEST] <thebombzen> just a google search took me to this: https://bugs.llvm.org/
[03:20:01 CEST] <Compn> probably the correct place
[03:20:21 CEST] <Compn> thebombzen : its possible jamrial wants someone to create samples that miscompile though
[03:20:34 CEST] <Compn> because compiler projects require sample code (and they dont want full .c files)
[03:20:50 CEST] <Compn> and especially not 1mb ffmpeg project zip ;)
[03:21:17 CEST] <Compn> jamrial : we could probably ask on twitter for a volunteer
[03:21:29 CEST] <Compn> jamrial : if you want to post what happens to our bugtracker and then we point twitter at it 
[03:21:49 CEST] <jamrial> nobody here uses clang at all?
[03:21:58 CEST] <Compn> there are some clang users here i think
[03:21:59 CEST] <jamrial> seems a bit too extreme to ask on twitter about it
[03:22:01 CEST] <Compn> maybe just afk :D
[03:22:09 CEST] Action: Compn hides
[03:38:04 CEST] <iive> jamrial: ask atomnuker 
[04:03:16 CEST] <BBB> jamrial: about your patch
[04:03:29 CEST] <jamrial> BBB: yeah?
[04:03:30 CEST] <BBB> jamrial: lets hypothetically suggest that I wanted to put h264 ps headers in the frame side data
[04:03:36 CEST] <BBB> e.g. the slice header
[04:03:46 CEST] <BBB> that would break for multi-slice frames afte your patch
[04:04:24 CEST] <jamrial> how do you access them? custom code looping over existing side data? because av_frame_get_side_data() will always only return the first result of the requested type
[04:04:32 CEST] <BBB> custom code loop yes
[04:04:45 CEST] <jamrial> is that proper/documented api usage?
[04:04:50 CEST] <BBB> I dont know
[04:04:52 CEST] <BBB> it works
[04:05:38 CEST] <BBB> you could also add an api to get the nth of a type of side data
[04:05:40 CEST] <jamrial> plenty of things will work when you abuse an api :P
[04:05:45 CEST] <BBB> where the default function returns nth=0
[04:05:50 CEST] <BBB> sure
[04:05:55 CEST] <BBB> but this is not a crazy use case
[04:05:56 CEST] <jamrial> but you should expect them to be broken without notice
[04:05:58 CEST] <BBB> how would you do it?
[04:06:07 CEST] <BBB> lets sya you are me and want slice headers
[04:06:11 CEST] <BBB> what would you do?
[04:06:21 CEST] <jamrial> i agree, so maybe this should be documented, or a new function allowing one to get the other results should be added
[04:06:31 CEST] <BBB> thats what I just said
[04:06:43 CEST] <BBB> add a function to get the nth element of a type of side data
[04:06:48 CEST] <BBB> and for the default function, get nth=0
[04:07:12 CEST] <jamrial> epatchwelcome :p
[04:07:13 CEST] <BBB> and if we reach the end of the side data list without encountering n side datas of that type, return NULL
[04:07:28 CEST] <BBB> you proposed a patch to break a use case
[04:07:31 CEST] <jamrial> i can drop this patch. i wrote it just to be consistent with the current packet side data behavior
[04:07:34 CEST] <BBB> I just loop over the struct directly
[04:07:44 CEST] <BBB> because I dont want to add external api that is weird
[05:33:15 CEST] <atomnuker> jamrial: yeah, I use clang, it work fine with ccache and is slightly faster than gcc
[06:06:10 CEST] <jamrial> atomnuker: can you try to make a testcase for the above and report it to llvm?
[06:12:20 CEST] <atomnuker> jamrial: was it clang's fault? the commit doesn't say
[06:13:00 CEST] <jamrial> what commit?
[06:13:24 CEST] <jamrial> look at fate, every jpeg encoder test is failing with clang 5 (release) and newer
[06:13:50 CEST] <jamrial> on both x86_32 and x86_64
[06:15:40 CEST] <atomnuker> ah, I thought you meant the bug which was just closed
[06:18:40 CEST] <atomnuker> "New user self-registration is disabled due to spam. For an account please email bugs-admin at lists.llvm.org with your e-mail address and full name."
[06:24:34 CEST] <jamrial> same happened to gcc's bugzilla afaik
[07:21:08 CEST] <atomnuker> speaking of compiler errors, debian's latest gcc-snapshot fails to compile at all
[07:21:11 CEST] <atomnuker> "libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed"
[07:53:28 CEST] <Blubberbub_> https://www.ffmpeg.org/developer.html#Contributing <- this should probably changed, because pull requests aren't accepted through github, right?
[09:12:48 CEST] <cone-726> ffmpeg 03DeHackEd 07master:eabeb9093abe: avformat/hlsenc: allow dynamic encryption key rotation
[09:54:02 CEST] <nevcairiel> Blubberbub_: you can still do that and send it to the ML for review, it doesnt mention pull request specifically
[09:54:55 CEST] <Blubberbub_> yea, i think i misunderstood it. Its probably about having my own fork of ffmpeg and referencing a branch in my fork on the mailing list?
[09:59:34 CEST] <cone-726> ffmpeg 03Muhammad Faiz 07release/3.3:e51e07c34eb7: avfilter/vf_ssim: fix temp size calculation
[11:36:22 CEST] <cone-726> ffmpeg 03Muhammad Faiz 07release/3.2:5987b16f868c: avfilter/vf_ssim: fix temp size calculation
[11:58:16 CEST] <cone-726> ffmpeg 03Muhammad Faiz 07release/3.1:eadb52d45904: avfilter/vf_ssim: fix temp size calculation
[12:36:17 CEST] <Blubberbub_> a simple NaN can really ruin a productive day...
[12:45:58 CEST] <atomnuker> Blubberbub_: where?
[12:47:02 CEST] <atomnuker> (and yeah, nans suck, they also make every float op take 300-400 cycles so they're pretty easy to detect)
[12:47:33 CEST] <Blubberbub_> i'm writing a filter that trims silence from the start and end of audio. The compute_rms-function in af_silenceremove uses a sqrt() which apparently can generate NaNs
[12:48:05 CEST] <Blubberbub_> and i wrote my code where the nan triggered the wrong condition
[12:51:34 CEST] <Blubberbub_> i can't english today. :D 
[13:06:54 CEST] <durandal_1707> Blubberbub_: use fabs
[13:07:57 CEST] <Blubberbub_> assuming that a*a is >= 0 for double values i shouldn't need fabs. But maybe that assumption is wrong?
[13:16:09 CEST] <durandal_1707> Blubberbub_: are you modifying existing filter?
[13:16:26 CEST] <Blubberbub_> kind of
[13:16:33 CEST] <Blubberbub_> i'm writing a variant
[13:19:54 CEST] <durandal_1707> Blubberbub_: what variant?
[13:20:29 CEST] <Blubberbub_> i want to remove silence from the start and end of the file, but not anything else
[13:22:19 CEST] <durandal_1707> Blubberbub_: and how would you do that if you dont know duration?
[13:22:45 CEST] <Blubberbub_> writing everything that looks like silence into a fifo until i encounter eof or non-silence
[15:16:19 CEST] <atomnuker> Blubberbub_: what if you have silence in the middle of the file
[15:16:37 CEST] <atomnuker> if you want to remove from the start and end only you'll need to cache everything until EOF
[15:16:47 CEST] <Blubberbub_> only the silence, but yes
[15:17:33 CEST] <Blubberbub_> so i write the silence to a buffer and if i notice that there is non-silence after the silence i just buffered i empty that buffer and start over
[15:17:45 CEST] <Blubberbub_> if i find eof i just ignore the buffered silence
[15:19:28 CEST] <BtbN> a filter that hold back output for a very long time and then dumps it all sounds problemetic
[15:19:50 CEST] <atomnuker> BtbN: that's how the areverse and reverse filters work
[15:20:16 CEST] <atomnuker> (and they work alright as long as you have enough ram to store everything uncompressed)
[15:21:58 CEST] <Blubberbub_> i also destroy the regularity of frame sizes in the progress, but i haven't yet encountered any problems with that
[17:44:28 CEST] <durandal_1707> why nobody wrote ff edit like utility years ago
[17:45:03 CEST] <durandal_1707> they just complain and use shit like vs or avs
[17:50:41 CEST] <atomnuker> exactly
[18:20:40 CEST] <BtbN> https://bpaste.net/show/92253bb6d717 is it intended that the hls muxer keeps spamming this?
[18:27:12 CEST] <DHE> yes, ever since it turned out to be a potential security hazard to open the contents of playlist-based formats...
[18:27:21 CEST] <DHE> that is, it's intentional. not that I agree with it.
[18:30:01 CEST] <BtbN> it's spamming so hard that reducing the log level made it go notably faster
[18:30:35 CEST] <JEEB> it's writing so I'm not sure if that is necessary
[18:30:37 CEST] <BtbN> I don't really understand how creating a hls video/stream is a security issue though
[18:30:41 CEST] <JEEB> yea
[18:31:10 CEST] <JEEB> just make a patch about it making the logging level something more verbose
[18:31:17 CEST] <JEEB> than AV_LOG_LEVEL_INFO
[18:31:27 CEST] <BtbN> I don't even see where in the code those logs come from
[18:31:27 CEST] <JEEB> that goes into VERBOSE or TRACE for me personally?
[18:31:29 CEST] <BtbN> it's not in hlsenc.c
[18:33:26 CEST] <nevcairiel> it generically logs all file opening
[18:35:03 CEST] <BtbN> that should be at least verbose
[18:35:31 CEST] <nevcairiel> i'm sure someone will argue that its "security relevance" is only meaningful if its shown to people by default =p
[18:35:49 CEST] <DHE> see commit 53e0d5d7247548743e13c59c35e59fc2161e9582
[18:38:24 CEST] <BtbN> So I guess adding the hls muxer to that check is in order
[18:39:38 CEST] <BtbN> Or in general at least some option to silence it.
[18:39:52 CEST] <BtbN> Specially with short segmented non-live hls it's a massive wall of spam
[21:18:52 CEST] <jamrial> <atomnuker> "libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed"
[21:19:08 CEST] <jamrial> what configure options and how old is the snapshot?
[21:21:44 CEST] <DHE> an ICE is automatically a compiler or hardware fault. try again. if it happens twice, update gcc. if it doesn't, check your hardware
[21:23:36 CEST] <atomnuker> jamrial: gcc (Debian 20170731-1) 8.0.0 20170731 (experimental) [trunk revision 250749], config options were https://0x0.st/dNP.txt
[21:24:52 CEST] <DHE> ... gcc 8.0.0 isn't an official release... see gcc.gnu.org/
[21:25:14 CEST] <jamrial> DHE: it's the in development version
[21:25:36 CEST] <DHE> yes I see that... 
[21:25:56 CEST] <jamrial> svn trunk snapshots are all 8.0.0
[21:26:28 CEST] <jamrial> so if it's crashing compiling ffmpeg, better report it now so they fix it before it's released
[21:44:39 CEST] <jamrial> atomnuker: can reproduce, will make a ticket on gcc's bugzilla later
[21:45:24 CEST] <JEEB> cool
[22:27:41 CEST] <atomnuker> is there anything odd at all about our tta decoder? anything at all?
[22:28:14 CEST] <atomnuker> running showcqt in mpv's lavfi-complex causes pauses once every second or so
[22:28:23 CEST] <atomnuker> but only when decoding tta
[22:28:53 CEST] <atomnuker> (number of audio decoding threads makes no difference so its not a threading bug)
[22:31:53 CEST] <jamrial> atomnuker: not that i know of, but ask durandal_1707
[22:31:59 CEST] <jamrial> try cpuflags 0 and such as well
[22:34:11 CEST] <durandal_1707> tta have some strange heuristic for guessing last frame
[22:34:31 CEST] <durandal_1707> i failed to get it working
[22:43:47 CEST] <jamrial> durandal_1707: doesn't that depend on the container? .tta files are fine, it's matroska where things can get iffy since for some reason in the spec they decided to drop the tta header
[22:44:58 CEST] <durandal_1707> jamrial: tta is same, as when you seek you forget when you are
[00:00:00 CEST] --- Mon Aug  7 2017