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

[burek]

[00:34:14 CET] <cone-651> ffmpeg 03James Almer 07master:eeca8921e265: configure: add missing adts_header to aac_fixed decoder
[00:39:01 CET] <cone-651> ffmpeg 03James Almer 07master:935a9986fc2e: avformat/movenc: move the concatenated eac3 packet reference
[02:11:37 CET] <cone-651> ffmpeg 03Jun Zhao 07master:e0e72539cf5c: lavu/opt: add AV_OPT_FLAG_BSF_PARAM
[02:11:37 CET] <cone-651> ffmpeg 03Jun Zhao 07master:7b5cf0a41076: lavu/opt: add bit stream filter option dump support.
[02:11:38 CET] <cone-651> ffmpeg 03Jun Zhao 07master:a675eed17538: ffmpeg: support dump bit stream filter options.
[02:13:53 CET] <nevcairiel> the thermal improvements on the new Pi 3B+ seem to be working great, put a small heatsink on  it like I always do, and its been compiling shit for half an hour, reached stable temps and not throttling at all
[02:24:18 CET] <tmm1> did the amf headers get split out into another repo?
[02:33:52 CET] <jamrial> tmm1: https://github.com/GPUOpen-LibrariesAndSDKs/AMF they have always been there
[02:34:06 CET] <tmm1> ah ok, thanks
[02:34:22 CET] <tmm1> i was remembering an old patch that included them
[02:45:10 CET] <rcombs> nevcairiel: nice
[04:20:28 CET] <cone-651> ffmpeg 03James Almer 07master:7af2336598e9: avutil: bump version after the latest AVOption flag addition
[04:23:56 CET] <rcombs> should aac_adtstoasc be merged into extract_extradata
[08:24:18 CET] <nevcairiel> rcombs: that would have odd side-effects, they are close in functionality but still used differently
[08:25:49 CET] <rcombs> nevcairiel: I'm wondering if it should be used for e.g. movenc and matroskaenc
[09:09:28 CET] <cone-698> ffmpeg 03Tobias Rapp 07master:1296a718dc62: avutil/log: print level prefix also when no AVClass context is available
[09:19:20 CET] <nevcairiel> rcombs: isnt it used for those right now
[09:19:28 CET] <rcombs> I know
[11:26:09 CET] <gagandeep> y
[11:28:34 CET] <gagandeep> kierank: i made the patch file using format-patch and have sent it to ffmpeg-devel
[11:28:58 CET] <gagandeep> subject and desc might be a bit messy 
[11:30:44 CET] <gagandeep> will be sending the current interlaced by sunday midnight
[11:35:08 CET] <durandal_1707> gagandeep: make topic follow others commits in ffmpeg
[12:39:42 CET] <cone-530> ffmpeg 03Paul B Mahol 07master:5941179e28b9: avfilter/af_surround: drain input at EOF
[14:02:20 CET] <durandal_1707> gagandeep: make topic follow others commits in ffmpeg
[14:03:29 CET] <gagandeep> durandal_1707: yeah, will do that
[14:08:07 CET] <kierank> gagandeep: yes, what is that massive thing at the end of your patch
[14:08:55 CET] <gagandeep_> kierank: i thought it was something system generated
[14:09:05 CET] <gagandeep_> i have checked using make fate
[14:09:23 CET] <gagandeep_> i have no idea what that might be
[14:10:28 CET] <gagandeep_> kierank: can you remove that from the patch
[14:10:52 CET] <kierank> you should do it
[14:10:53 CET] <kierank> to learn
[14:15:18 CET] <gagandeep_> kierank: by the way now i am asking about the stride that you are setting while getting the data of width in the tag processing
[14:15:45 CET] <kierank> The honest answer is I made it up when reverse engineering
[14:19:16 CET] <gagandeep_> ok, i was disconnected a moment ago so i only know of you message @ [18:48:57]
[18:31:57 CET] <atomnuker> AAARGHT mesa people are awful
[18:32:26 CET] <atomnuker> there's a guy in a bug report I made refuting everything I say by saying "you can't do that"
[18:32:37 CET] <atomnuker> then I post a link TO THE FUCKING spec and he shuts up
[18:32:55 CET] <atomnuker> I've had to provide quotes and links to the spec 3 times now
[18:33:50 CET] <atomnuker> how do you tell someone to kindly shut the fuck up and read the only documents that matters
[18:37:09 CET] <sigdrak> qzAMLLZDTFVVTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
[18:37:09 CET] <sigdrak> TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
[18:44:39 CET] <kierank> atomnuker: be linus torvalds
[18:45:38 CET] <iive> atomnuker, link?
[18:58:23 CET] <wm4> sigdrak: was that the cat
[20:10:55 CET] <JEEB> http://up-cat.net/p/eb3d1a64
[20:11:09 CET] <JEEB> is the compiler drunk or...
[20:12:22 CET] <durandal_1707> if you can reproduce it again, it is not drunk
[20:12:58 CET] <nevcairiel> seems fine? the code is rather weird
[20:17:58 CET] <JEEB> right, that is strftime
[20:18:32 CET] <JEEB> nevcairiel: talking of weird code, I will have to try to see if I can make a version of this that makes more sense during the week-end :D https://github.com/jeeb/ffmpeg/commit/dfeeeb226094a8b00f7319b89e4d3b3660326d35
[20:20:24 CET] <JEEB> (I have a hunch that that logic actually just wants the reference of the track that is supposed to handle the PCR)
[20:21:09 CET] <JEEB> (because with the sample I have that logic gets utilized only once, and the PID from which the value is taken is the PID that handles PCR for that program)
[20:22:15 CET] <BtbN> JEEB, %s is not in the standard IIRC
[20:22:22 CET] <BtbN> it's a glibc/Linux extension, so not portable
[20:22:34 CET] <nevcairiel> yeah the code is being dumb and just tries to use it
[20:22:41 CET] <nevcairiel> and uses something else if it fails
[20:22:48 CET] <JEEB> :)
[20:43:47 CET] <BodecsB> Hi JEEB and durandal_1707, this is my code
[20:44:12 CET] <BodecsB> this code try to avoid to use it when it is not available
[20:45:37 CET] <BodecsB> there was a conversation about to decide at compile time or runtime
[20:45:48 CET] <durandal_1707> BodecsB: i see no code
[20:46:04 CET] <BodecsB> JEEB referenced in his link
[20:46:12 CET] <JEEB> hlsenc I presume
[20:46:20 CET] <BodecsB> yes
[20:54:51 CET] <BodecsB> %s is not in the standard but originally it was in the code
[22:18:58 CET] <BtbN> well "As you may be aware, there recently was an interruption in the availability of the Coverity Scan service. In February 2018, we discovered that servers used for the Coverity Scan service were accessed by an unauthorized third-party. The access appears to have started earlier in the month. We suspect that the access was to utilize our computing power for cryptocurrency mining."
[22:19:39 CET] <kierank> LOL
[22:20:54 CET] <JEEB> hah
[23:52:11 CET] <philipl> BtbN: I would be really impressed if someone could trick the scanner into running the mining code. I assume in this case it was a more direct break-in though.
[00:00:00 CET] --- Sat Mar 17 2018