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

[burek]

[00:18:25 CEST] <BBB> Ive started reading up into this signed integer arithmetic overflow is undefined
[00:18:30 CEST] <BBB> because it so bothers me
[00:19:35 CEST] <BBB> so, my understanding is: undefined in the context of signed additions/multiplications (outside the scope of pointer arithmetic) is a misnomer and they really just mean we cant guarantee the outcome. so, it should have been implementation-defined, not undefined. the spec is a piece of crap when it comes to fine distinctions like this
[00:20:07 CEST] <BBB> second, the only reason this behaviour exists, is to allow implementations that dont use twos complement
[00:20:23 CEST] <BBB> within the sub-speace of twos complement, the behaviour is essentially defined
[00:20:44 CEST] <nevcairiel> does anything even exist that doesnt use two's complement
[00:20:46 CEST] <BBB> (its just that the c space doesnt know whether we are twos complement or not, so thats not helpful for auto-fuzzers)
[00:21:00 CEST] <BBB> but the point is: by making it unsigned, we enforce twos complement behaviour anyway
[00:21:04 CEST] <nevcairiel> (anything that matters, that is)
[00:21:18 CEST] <BBB> treating signed overflows as unsigned, as our docs state, only works if you use twos complement
[00:21:29 CEST] <BBB> otherwise its & implementation-defined! :)
[00:21:36 CEST] <BBB> (i.e. undefined-but-not-insecure)
[00:21:40 CEST] <BBB> so...
[00:22:01 CEST] <BBB> why are we going through all this effort to make signed stuff unsigned and thus reflect c spec for non-twos complement, if that requires twos complement?
[00:22:04 CEST] <BBB> I dont get it
[00:22:29 CEST] <nevcairiel> I doubt any of these things have ever been actually security relevant, the argument people usually use is "its undefined, so the compiler might remove bounds checks since it was undefined!!!"
[00:22:50 CEST] <BBB> as said, its undefined because of the requirement to work on non-twos complement
[00:22:55 CEST] <BBB> within twos complement, it is very much defined
[00:23:15 CEST] <BBB> but by making it unsigned, we require twos complement anyway
[00:23:19 CEST] <BBB> so it sounds like one big fraud to me
[00:23:24 CEST] <nevcairiel> it is
[00:23:29 CEST] <BBB> (I know thats not nice, but I dont know how else to say it)
[00:23:34 CEST] <nevcairiel> but someone has to pay security researches
[00:23:34 CEST] <BBB> so then why do we do it?
[00:23:39 CEST] <BBB> screw them
[00:23:42 CEST] <BBB> the code gets very unclean
[00:26:03 CEST] <BBB> by making it unsigned, we ensure that the code will not work on non-twos complement systems
[00:26:17 CEST] <nevcairiel> i've never seen anyone actually use a real argument to support this, the best you get "its undefined behavior, which means anything can happen", which is just a cop-out
[00:26:18 CEST] <BBB> by keeping it signed, we may actually be able to make it work on non-twos complement systems
[00:27:02 CEST] <BBB> so it seems much better to me - not just for code quality, but also for portability - to re-read the c-spec within this subpart as implementation-defined, not undefined, because its obvious that thats what was intended
[00:27:42 CEST] <BBB> the whole point of the c spec is to enable portability, and this particular piece basically does the exact opposite
[00:32:33 CEST] <peloverde> C spec defines a >> b as implementation defined when a is less than 0. It defines a << b as undefined when a is less than 0. This is an asymmetry in the spec.
[00:33:29 CEST] <BBB> I agree
[00:35:29 CEST] <peloverde> so it's known broken behavior but the spec authors seem to be in no big hurry to fix it. 
[00:36:02 CEST] <BBB> I hate that were bending backwards to fix our codebase to comply with a known-broken spec
[00:36:09 CEST] <BBB> and make our codebase less portable in the process
[00:36:41 CEST] <BBB> (and ugly)
[03:06:51 CEST] <iive> BBB: I guess you haven't read the llvm articles or any of the emails i've written. gcc have -fwrapv that "defines" signed overflow as wrapping.
[03:07:11 CEST] <iive> (the emails on the subject).
[03:40:23 CEST] <cone-516> ffmpeg 03Michael Niedermayer 07master:aeddb3607be9: avcodec/pixlet: Simplify nbits computation
[03:40:23 CEST] <cone-516> ffmpeg 03Michael Niedermayer 07master:8e275a74b09c: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH()
[05:22:13 CEST] <ElementalBlack> Where is the "unsharp" kernel function defined that's referenced on line 331 in unsharp_opencl.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/unsharp_opencl.c#L331)? I don't see that function in the kernel header
[05:30:18 CEST] <ElementalBlack> ah
[05:30:25 CEST] <ElementalBlack> maybe in allkernels.c
[05:57:04 CEST] <jamrial> ElementalBlack: pretty much nobody really knows the lavfi opencl code. it was submitted long ago and nobody has touched it since then
[05:58:20 CEST] <ElementalBlack> jamrial: I figured it out, it's using av_stristr() to find the provided string in the kernel source. Seems like a weird way to do it, but it works.
[08:44:17 CEST] <hanetzer> heyo. some questions regarding ffmpeg on mingw-w64. I'm using gentoo, amd64 glibc, and I've set up a cross toolchain that successfully crosscompiles a fair amount of libraries and programs without issue. the resultant binaries run on wine and windows 10. However, attempting to cross-compile ffmpeg fails for lack of detecting pthreads. this is version 3.3.2. Trying again and will post build logs.
[08:49:55 CEST] <hanetzer> https://paste.pound-python.org/show/ranPsBZQC7nXKJCf34IG/ gentoo build.log
[08:50:22 CEST] <hanetzer> https://paste.pound-python.org/show/JHFldMNA9lqD79WPlz15/ ffmpeg config.log
[12:09:46 CEST] <ldts> michaelni: on V4L2 patchset: gst imports the necessary v4l2 headers to guarantee the builds wont break (since the kernel API wont break legacy code) that means importing: v4l2-common.h  v4l2-controls.h  videodev2.h into ffmpeg...is there are place in the tree where these files should go? (some ext/v4l2/ ? or should I just add them to libavcodec/?) 
[12:10:31 CEST] <ldts> michaelni:  I am proposing to do just what gst does (ie bring the v4l2 header files into the ffmpeg tree)
[13:00:36 CEST] <Mavrik> This is strange... if I move AVPacket from one thread (calling av_read_frame) to another (calling avcodec_decode_video2), I'm getting bunch of decoding errors in H.264. Are there thread safety issues with reference counted packets?
[13:02:02 CEST] <ldts> michaelni:  aballier : compat/v4l2/*
[13:10:57 CEST] <nevcairiel> whats the point of that? its not like its actually going to run if the kernel doesnt have support
[13:11:14 CEST] <nevcairiel> better to build against what is actually available
[13:20:54 CEST] <ubitux> why do we still have that sdl dep?
[13:21:06 CEST] <ubitux> it's causing me issues for the autodetect thing :(
[13:21:45 CEST] <ubitux> is it just a shorthand?
[13:25:53 CEST] <JEEB> :<
[14:14:47 CEST] <ubitux> philipl: do you mind testing if crystalhd still work after the patch(set)?
[14:25:58 CEST] <JEEB> didn't his hardware die regarding that?
[14:26:07 CEST] <JEEB> I might be misremembering of course
[14:34:14 CEST] <ubitux> arh, actually it seems i missed something in that patchset
[14:43:18 CEST] <philipl> ubitux: I don't mind but I can't test until a week from now
[14:43:38 CEST] <philipl> One my cards died. I still have one left :-)
[15:05:34 CEST] <JEEB> ah, so you still have one left :D
[15:51:19 CEST] <JEEB> are lavf stream indexes unique?
[15:51:28 CEST] <JEEB> during a single input lavf context
[15:52:11 CEST] <JEEB> as in, can I just put stream indexes into a list of "these I don't care about" and know that no new stream is going to get there
[15:58:16 CEST] <nevcairiel> its only ever going to  add new streams in an existing context
[15:59:06 CEST] <JEEB> so effectively it wouldn't remove an indexed thing and re-add it
[15:59:11 CEST] <JEEB> as another thing
[15:59:22 CEST] <JEEB> (not that it would need since we have the positive side of int available)
[16:32:01 CEST] <ZeroWalker> is this wrong? audio->frame->pts += audio->frame->nb_samples / (audFormat.Samplerate / 1000) ;
[16:32:57 CEST] <iive> why the 1000?
[16:33:13 CEST] <ZeroWalker> aren't you supposed to make it in ms?
[16:33:57 CEST] <iive> no idea, but i know that there are things like timebase or something like that
[16:35:31 CEST] <ZeroWalker> isn't the timebase supposed to be the same as samplerate/fps?
[16:35:54 CEST] <iive> it usually is, to easy the calculations
[16:36:37 CEST] <ZeroWalker> 	context->sample_rate = 48000; 	context->time_base = AVRational{ 1, context->sample_rate };  So i got this part right;p?
[16:37:03 CEST] <iive> the problem above is that you are making a rounding error, quite bit at that. and in audio error accumulates easily.
[16:37:39 CEST] <ZeroWalker> elaborate, how does it occur?
[16:37:41 CEST] <iive> aka, it easies the calculations, so you just add the number of samples.
[16:38:40 CEST] <iive> the logic is simple, you have e.g. 48000 samples, and timebase of 1/48000, so it makes 1second.
[16:39:10 CEST] <iive> once again. i'm not familiar with this code, i'm just regargulating basic principles. I could be wrong.
[16:39:28 CEST] <ZeroWalker> ah, so adding pts just tells it (48000 pts == 1 second)
[16:39:42 CEST] <ZeroWalker> so as i have the same, i can just add samples
[16:39:44 CEST] <iive> pts*timebase=time
[16:39:49 CEST] <ZeroWalker> that makes sense
[16:39:50 CEST] <ZeroWalker> ah
[16:40:23 CEST] <ZeroWalker> hmm, well then it's probably not the timebase thing that messes up the audio for me, guess it's the resampling as it worked fine without it. Was sure i had the resampling working -_-
[16:49:08 CEST] <ZeroWalker> or maybe not, the audio time is super long compared to what it should be xd
[18:10:48 CEST] <Blubberbub_> ZeroWalker, it might be possible, that your output expects a different time_base than 1/samplerate, though
[18:11:01 CEST] <Blubberbub_> then you cannot do PTS += nb_samples
[18:13:08 CEST] <ZeroWalker> how would i determine that?
[18:13:20 CEST] <Blubberbub_> i learned that from afade
[18:13:30 CEST] <ZeroWalker> afade?
[18:13:37 CEST] <Blubberbub_> filter in libavfilter
[18:13:44 CEST] <ZeroWalker> ah
[18:14:14 CEST] <Blubberbub_> there is this av_rescale_q-method(or something like that) that is used there
[18:22:43 CEST] <ZeroWalker> ah yeah seen that, but i don't think i am supposed to use it as as the encoder and the frame has the same samplerate
[18:30:12 CEST] <PaoloP>  Hello. It seems that the mpegts muxer wants TWO adts-aac frames (av_write_frame()), before producing output. Do you know why?
[20:22:28 CEST] <J_Darnley> atomnuker: would you be kind enough to look at this when you have time
[20:22:29 CEST] <J_Darnley> https://pastebin.com/xfptY2v1
[20:23:06 CEST] <J_Darnley> and tell me whether you think that looks correct for the legall 5_3 transform?
[20:26:16 CEST] <J_Darnley> I tried to remove the edge handing from your transforms
[20:27:03 CEST] <J_Darnley> but I get left with a dark or black sample in the last of each row and column of a slice
[20:32:24 CEST] <JEEB> ubitux: gj with the patch set
[20:32:45 CEST] <atomnuker> BBB: oh wow tile threading
[20:33:00 CEST] <atomnuker> any performance comparisons yet?
[20:33:19 CEST] <JEEB> oh, cool
[20:37:42 CEST] <nevcairiel> the real question is if you can saturate your cpu with frame threading, because if you can all you might gain is reduced latency
[20:38:16 CEST] <JEEB> yea
[20:39:06 CEST] <BBB> no, its not bitexact yet
[20:39:11 CEST] <BBB> loopfilter still to be done
[21:29:11 CEST] <ubitux> JEEB: thx :)
[21:29:16 CEST] <ubitux> iconv still needs fixing tho
[21:37:33 CEST] <PaoloP> Hello. It seems that the mpegts muxer wants TWO adts-aac frames (av_write_frame()), before producing output. Do you know why and/or if is there a way to avoid this buffering?
[21:50:57 CEST] <ZeroWalker> is there some good site where i can upload a test file to provide here. I would like to have help diagnosing what the issue is with my audio encoding, or if it's timing or something. It works fine with having it in PCM with just writing directly. But resampling/FIFO causes issues, and i can't figure out what
[22:17:56 CEST] <BBB> is someone here familiar enough with pkg-config to review "configure: require pkg-config for libvmaf"?
[22:18:18 CEST] <BBB> I dont understand that kind of stuff and there were some comments about it earlier, so Id like to make sure that resolves all the issues with the configure-part of this feature
[22:31:45 CEST] <ZeroWalker> when adding a stream, are you supposed to copy the parameters of the already initialized codec to that stream or something, or is just avformat_new_stream enough?
[22:35:47 CEST] <BBB> I thought avcodec was supposed to be invisible to the avformat layer, and sharing of such parameters was supposed to be done using avcodecparameters?
[22:37:04 CEST] <ZeroWalker> well i have been doing that, by using avcodec_parameters_from_context
[22:37:21 CEST] <ZeroWalker> not sure where i got that from, but i guess i reached the same conclusion
[22:37:35 CEST] <ZeroWalker> but i see examples that handle it differently, so a bit confused
[22:38:01 CEST] <BBB> the examples may be old :-/
[22:39:32 CEST] <ZeroWalker> true
[22:41:08 CEST] <ZeroWalker> but trying to fix my damn timing errors. and i think it actually might be something with this. Cause i think it ignored the timebase i set on my codec, it seems to follow a "1/1000" timebase, and that's what the streams seems to default to after av_write_header, for some reason, but it feels like it should already be set in by then
[22:42:51 CEST] <Blubberbub_> do you set a time_base on your output stream?
[22:43:23 CEST] <Blubberbub_> because you need to do that. 
[22:46:01 CEST] <ZeroWalker> not sure what that means so probably not
[22:46:19 CEST] <ZeroWalker> i thought the stream is basically the codec, so it used that timebase
[22:47:48 CEST] <Blubberbub_> well - i had that problem when writing a demuxer, that i did avformat_new_stream in read_header and something was weird with timings. Turned out that i had to set (AVStream *)->time_base to (AVRational){1, sample_rate}
[22:49:44 CEST] <JEEB> yea some containers have hardcoded time bases and in other cases you can set it yourself
[22:50:22 CEST] <ZeroWalker> http://paste.awesom.eu/YGRs
[22:50:28 CEST] <ZeroWalker> well i tried to do something like this
[23:00:42 CEST] <Blubberbub_> time_base is not uninitialized, like it was in my case, i guess
[23:04:22 CEST] <ZeroWalker> well i am just more confused xd
[23:06:03 CEST] <Blubberbub_> but didn't you calculate the PTS yourself? Maybe the time_base from the codec is not 1/sample_rate, like you assume in your pts-code?
[23:11:20 CEST] <ZeroWalker> but i set my time_base manually, so shouldn't it be that;s
[23:21:04 CEST] <Blubberbub_> i have no idea - and probably only confuse you even more with my attempts :(
[23:27:31 CEST] <ZeroWalker> it's probably super simple but i just can't see it xd
[23:27:48 CEST] <ZeroWalker> not that used to the ffmpeg API so find many thing confusing.
[23:28:41 CEST] <ZeroWalker> But well this might also be why the bitrate i set on the video is all messed up, it doesn't follow it at all. But that might also be cause it's VFR (which is set by milliseconds, which seems to work, but it shouldn't as it should be fps timebase:S)
[23:48:02 CEST] <ZeroWalker> okay when calling avcodec_receive_packet, do you have to used a cleared AVPacket?
[23:48:29 CEST] <ZeroWalker> http://paste.awesom.eu/GHOo
[00:00:00 CEST] --- Sat Jul 29 2017