[Ffmpeg-devel-irc] ffmpeg-devel.log.20170321
burek
burek021 at gmail.com
Wed Mar 22 03:05:02 EET 2017
[00:12:03 CET] <cone-785> ffmpeg 03Gerion Entrup 07master:5e3a418b6047: add signature filter for MPEG7 video signature
[00:12:49 CET] <atana> michaelni, I am getting 2 failures with 2048 window size
[00:14:26 CET] <michaelni> atana, hmm, great
[00:14:44 CET] <michaelni> atana, can you push your code to github ?
[00:14:58 CET] <atana> but you were getting 7 failures I guess
[00:15:03 CET] <atana> I will push the code
[00:19:15 CET] <atana> michaelni, code pushed
[00:26:20 CET] <michaelni> atana, confirmed, its 2 here too, i must have had a mistake in the code when i tried earlier
[00:26:44 CET] <michaelni> atana, does it improve further for 4096 or 8192 ?
[00:26:52 CET] <atana> ok so I will try will other window setting too
[00:27:00 CET] <atana> *with
[00:46:44 CET] <atana> michaelni, it remain 2 for 4096 and 8129
[00:48:27 CET] <michaelni> atana, each case is split in 64 sample blocks and for 8 of them the peak frequencies are stored and looked up
[00:49:05 CET] <michaelni> atana, maybe using more than 8 works better, there should be more peaks beyond 1024
[00:57:44 CET] <atana> I will it
[00:57:50 CET] <atana> *try
[01:14:43 CET] <atana> michaelni, I used 10 points and it gives 160 errors. I replaced 8 with 10 and 7 with 9
[01:15:07 CET] <atana> *failures
[01:27:09 CET] <michaelni> atana, entry and buff sizes probably need to be bigger
[03:12:15 CET] <jamrial> so chromium now supports apng and firefox is going to support webp
[04:02:19 CET] <wm4> jamrial: and the world became a worse place
[04:34:52 CET] <philipl_> ubitux: Yeah. no-op was the right thing to do.
[04:35:18 CET] <philipl> There's no benefit in perpetuating this whole YUV444P16-is-ok thing.
[04:35:24 CET] <philipl> The nvenc mess is still outstanding there.
[04:36:20 CET] <philipl> BtbN: speaking of messes - have you looked at the bframe failure?
[06:41:11 CET] <cone-847> ffmpeg 03wm4 07master:d682ae70b4b3: avcodec, avformat: deprecate anything related to side data merging
[06:41:11 CET] <cone-847> ffmpeg 03wm4 07master:87c082c42602: ffmpeg: don't unnecessarily use a deprecated API function
[06:41:11 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:749262693247: pthread_frame: use atomics for PerThreadContext.state
[06:41:11 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:b6587421c779: pthread_frame: use atomics for frame progress
[06:41:11 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:98f89d615b64: pthread_frame: properly propagate the hw frame context across frame threads
[06:41:12 CET] <cone-847> ffmpeg 03Mark Thompson 07master:fb69a8e1f124: pthread_frame: Unreference hw_frames_ctx on per-thread codec contexts
[06:41:12 CET] <cone-847> ffmpeg 03Wan-Teh Chang 07master:c358c62550e6: pthread_frame: use better memory orders for frame progress
[06:41:13 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:14bb15bfd56d: pthread_frame: ensure the threads don't run simultaneously with hwaccel
[06:41:13 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:e0cd598bc468: pthread_frame: do not run hwaccel decoding asynchronously unless it's safe
[06:41:14 CET] <cone-847> ffmpeg 03wm4 07master:2e5c52896b0a: pthread_frame: remove some dead code
[06:41:15 CET] <cone-847> ffmpeg 03wm4 07master:66963d4b8d30: avcodec: remove warning against using frame threading with hwaccels
[06:46:00 CET] <wm4> hm forgot to clean up certain "details" (not related to actual code)
[06:46:03 CET] <wm4> but whatever
[07:40:16 CET] <wm4> wow fate doesn't print some commands even with V=1
[07:45:47 CET] <wm4> that gets pretty confusing when an earlier command is crashing
[08:05:22 CET] <cone-847> ffmpeg 03Carl Eugen Hoyos 07master:4b192ffdbe22: ffmpeg: Initialize two stack variables.
[08:27:37 CET] <cone-847> ffmpeg 03Vittorio Giovara 07master:de8e096c7eda: swscale: Consistently order input YUV pixel formats
[08:27:38 CET] <cone-847> ffmpeg 03Clément BSsch 07master:fa8db3f5975e: Merge commit 'de8e096c7eda2bce76efd0a1c1c89d37348c2414'
[08:30:02 CET] <ubitux> michaelni: opinions on e87a501e7d03ac68b58520108fe24ad9d0b36765?
[08:30:15 CET] <ubitux> it looks like we are currently checking against 14 instead of 15
[08:30:26 CET] <ubitux> but i'm wondering if that's not on purpose due to overflow risks
[09:24:24 CET] <ubitux> michaelni: basically this: http://sprunge.us/Rfde (passes FATE here)
[09:49:52 CET] <BtbN> philipl, bframe failure? Last thing I looked at was cuvid mpeg2 getting stuck, which doesn't happen on both of my machines, no matter how often I re-run it.
[10:32:16 CET] <wm4> jkqxz: are you going to push your changes to ffmpeg too?
[10:36:56 CET] <jkqxz> The hw_device_ctx support? Yes, soon. I think the generic hardware support in ffmpeg.c and deleting ffmpeg_*.c wants to wait for the next set, though.
[10:39:22 CET] <jkqxz> (It doesn't actually do anything other than cleanup yet.)
[10:41:35 CET] <wm4> why would that wait?
[10:43:51 CET] <durandal_1707> anyone can generate raw dnxhd/dnxhr files for me?
[10:44:19 CET] <durandal_1707> im looking for variable sizes of frames
[10:44:49 CET] <jkqxz> wm4: It needs clearer use-cases to resist attack by bikeshedders.
[10:57:56 CET] <jkqxz> Hmm. That VAAPI hwaccel example doesn't actually need to have any dependency on VAAPI at all.
[10:58:33 CET] <jkqxz> Given that it was from Intel they might not appreciate it working for VDPAU as well, though...
[11:00:11 CET] <wm4> they still need to know about the pixfmt, don't they
[11:05:47 CET] <jkqxz> Only for the actual output writing. rawvideo could deal with that, but probably isn't helpful for the example.
[11:06:17 CET] <wm4> I mean you need to select the hwaccel impl in get_format
[11:09:49 CET] <jkqxz> Hmm, yeah. The pixfmts supported by a given device aren't actually exported. Maybe they should be.
[11:11:03 CET] <wm4> yes, and/or making AVCodecContext.hw_device_ctx select it by default in the default get_format callback
[11:11:48 CET] <wm4> also elenril talked about changing the way hwaccels are selected (some other callback instead of get_format?)
[11:23:45 CET] <jkqxz> Yeah, selecting it by default if hw_device_ctx is set and get_format isn't is probably sensible. (That still needs some way to match pixfmt to device type, though.)
[11:46:52 CET] <feliwir> what is the bits and max_depth parameter of get_vlc2 supposed to be? If max_depth is the depth of the huffman tree that is also the amount of bits required to be read
[11:51:31 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:b4da4307a91e: avcodec/fmvc: small refactoring in decode_type1()
[11:55:09 CET] <feliwir> also what is n0 representing in the node struct?
[11:58:00 CET] <michaelni> ubitux, do you have any case where it makes a difference ? i also think the 14 was intentional but easiest would be if there was something to test these codepathes
[11:58:56 CET] <ubitux> it passes FATE so apparently it made no difference (except maybe faster in some cases?)
[11:59:29 CET] <michaelni> do we have 15bit pixel formats ?
[11:59:59 CET] <ubitux> not afaik
[12:00:31 CET] <wm4> RGB555?
[12:00:34 CET] <ubitux> IO... yuv420p10be 3 15
[12:00:36 CET] <ubitux> IO... yuv420p10le 3 15
[12:00:37 CET] <michaelni> ubitux, then maybe nothing triggers the changed path
[12:00:38 CET] <ubitux> these?
[12:00:50 CET] <ubitux> IO... p010le 3 15
[12:00:52 CET] <ubitux> IO... p010be 3 15
[12:00:55 CET] <michaelni> wm4, thats 5bit
[12:01:09 CET] <ubitux> IO... rgb555be 3 15
[12:01:11 CET] <ubitux> IO... rgb555le 3 15
[12:01:17 CET] <durandal_1707> heh
[12:01:18 CET] <michaelni> i should have said 15 bit per sample
[12:03:39 CET] <ubitux> so what's your opinion? should we move to 15 even if unused currently to make it consistent with libav and the function names, or keep our 14 suggesting there might be an issue with 15?
[12:05:33 CET] <ubitux> (functions are called hScale8To15_c, hScale16To15_c, ff_hscale8to15, ...
[12:05:35 CET] <ubitux> )
[12:06:33 CET] <michaelni> I prefer to keep 14 until theres a case that allows us to test this and i suspect it will not work with 15 at least not all the code
[12:06:47 CET] <ubitux> OK
[12:07:26 CET] <ubitux> in the same spirit i'll noop the rename from is9_OR_10BPS to is9_15BPS and keep our isNBPS
[12:07:47 CET] <michaelni> ok
[12:07:49 CET] <ubitux> as it's not actually the 9-15 range but a 9-14 that could change
[12:08:38 CET] <michaelni> also ill do some tests with avaseert to check that things arent 15 in some unexpected corner case
[12:08:39 CET] <ubitux> i might have some questions for the introduction of the pixel formats we already have as they may have introduced some differences
[12:09:04 CET] <ubitux> ok, thanks :)
[12:19:14 CET] <cone-847> ffmpeg 03Luca Barbato 07master:e87a501e7d03: swscale: Update bitdepth range check
[12:19:15 CET] <cone-847> ffmpeg 03Clément BSsch 07master:2ea585b8e3f6: Merge commit 'e87a501e7d03ac68b58520108fe24ad9d0b36765'
[12:22:58 CET] <cone-847> ffmpeg 03Luca Barbato 07master:2b5b1e1e9b89: swscale: Rename is9_OR_10 to match what it does
[12:22:59 CET] <cone-847> ffmpeg 03Clément BSsch 07master:51f88ac57b90: Merge commit '2b5b1e1e9b89063d352e2efed014f9d761b85032'
[12:38:56 CET] <cone-847> ffmpeg 03Clément BSsch 07master:6476bb84bca3: lavc/hwaccel: fix header copyright
[12:51:13 CET] <cone-847> ffmpeg 03Luca Barbato 07master:85406e7a8d5a: pixfmt: Add yuv420p12 pixel format
[12:51:14 CET] <cone-847> ffmpeg 03Luca Barbato 07master:0aebbbd02476: pixfmt: Add yuv422p12 pixel format
[12:51:15 CET] <cone-847> ffmpeg 03Luca Barbato 07master:9bd6ea569566: pixfmt: Add yuv444p12 pixel format
[12:51:16 CET] <cone-847> ffmpeg 03Luca Barbato 07master:0e8d1fc1f013: lavu: Bump version for the 12bit Planar YUV support
[12:51:17 CET] <cone-847> ffmpeg 03Clément BSsch 07master:876e32f7fc17: Merge commit '0e8d1fc1f013eb805a7b66656d9452bcbca36d22'
[12:53:38 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:6c09af7e46a5: APIchanges: fix a typo in the version number
[12:53:39 CET] <cone-847> ffmpeg 03Clément BSsch 07master:81dc9b77a757: Merge commit '6c09af7e46a5a1ada67ffe832f7895cf2749130b'
[12:55:54 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:6f733ecab6fa: mpegvideo_enc: add const to the AVCodec instance
[12:55:55 CET] <cone-847> ffmpeg 03Clément BSsch 07master:70ca9b76e2af: Merge commit '6f733ecab6faff2a16534f2ce7d2ffd41c07846b'
[13:00:19 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:f03f78bc1c99: mpegvideo_enc: handle encoding errors with b_strategy=2
[13:00:20 CET] <cone-847> ffmpeg 03Clément BSsch 07master:b2cb9191eaf2: Merge commit 'f03f78bc1c99b1e29624418e2f7315b8a47981e9'
[13:04:32 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:68811a41c70f: mpegvideo_enc: use the new encoding API for b_strategy=2
[13:04:34 CET] <cone-847> ffmpeg 03Clément BSsch 07master:e6be531a30b7: Merge commit '68811a41c70f019bde6df2a4f289674228c48958'
[13:15:49 CET] <wm4> BBB: I don't think an API user really needs to care about it, but it sure will be confusing if it tries to use both
[13:16:00 CET] <BBB> thats the whole point
[13:16:06 CET] <cone-847> ffmpeg 03Kieran Kunhya 07master:4cca2f74f253: vf_drawtext: Fix memory leak
[13:21:22 CET] <mateo`> wm4: for what it's worth, i also want a single API, i didn't take a look at the new API (is the transformation exported as a matrix ?)
[13:21:48 CET] <wm4> mateo`: yes, see libavutil/display.h
[13:22:21 CET] <wm4> there are also convenient accessors that give you the old API essentially (just not using AVDictionary)
[13:23:48 CET] <mateo`> where is the transformation matrix exported ? in AVCodecContext ?
[13:24:33 CET] <wm4> AVFrame side data
[13:24:43 CET] <nevcairiel> can i get the rotation directly from an avformatcontext after probing?
[13:24:51 CET] <nevcairiel> or avstream as it may be
[13:24:58 CET] <wm4> nevcairiel: yes via AVStream side data
[13:25:12 CET] <wm4> (seriously why is this side data stuff inconsistently duplicated everywhere)
[13:25:39 CET] <nevcairiel> if it wouldnt be, then my use-case would break =p
[13:25:51 CET] <nevcairiel> i dont have decoding or frames in the component that wants to export the rotation
[13:25:54 CET] <wm4> no mechanism gets lost
[13:28:59 CET] <mateo`> well, my probing library already uses this api
[13:46:25 CET] <mateo`> I just gave a quik look at the patch and I'm in favor of it, I also wonder if mjpeg{dec,enc} should honor this api (regarding the exif orientation tag)
[13:59:44 CET] <wm4> yes they should
[14:18:28 CET] <BBB> wm4: removing the metadata quite literally just means removing the side-data field from the AVFrame, e.g. in a filter
[14:18:42 CET] <wm4> ah
[14:18:49 CET] <BBB> wm4: theres many ways to do that, maybe ubitux wants a commandline switch to do that in ffmpeg.c? lets ask him
[14:19:05 CET] <BBB> there may not be a user-accessible way to do that in ffmpeg.exe ATM
[14:19:10 CET] <wm4> well that metadata hack I point out in the patch is supposed to do just that
[14:19:19 CET] <BBB> ah, ok
[14:19:24 CET] <wm4> old API => you could override the metadata field
[14:19:38 CET] <wm4> new API => needs a dedicated mechanism, but is emulated here
[14:20:22 CET] <ubitux> there are several cases you want to be able to handle at cli: hard rotate (filters), remux/transcode without loss of rotation information, remux/transcode dropping or altering the rotate information
[14:20:41 CET] <ubitux> (hard rotate means you want to drop the rotation information too btw)
[14:20:53 CET] <ubitux> these are commons cases for cli users
[14:21:20 CET] <cesdo> Hey guys, help me to configure ffmpeg, please!
[14:21:27 CET] <BBB> cesdo: #ffmpeg
[14:21:49 CET] <BBB> cesdo: this channel is for development of ffmpeg, not user support with ffmpeg
[14:24:54 CET] <cesdo> BBB: It's silence there(( Probably, only the developers know how to overcome it)) So, may I ask a question?
[14:25:18 CET] <BBB> cesdo: wait patiently until someone has time to help you, please dont ask user questions here
[14:27:29 CET] <wm4> BBB: maybe let him ask his question? then we know whether it's more a user or a devel question
[14:27:50 CET] <BBB> configure ffmpeg sounds very userish to me? ;)
[14:28:11 CET] <BBB> but sure if you isist
[14:28:18 CET] <hemalpatil> BBB: what task do I need to do to qualify for the VMAF project?
[14:29:23 CET] <BBB> hemalpatil: the original qual task was given out and finished already, so we need something else& Im considering whether it makes sense to librarify vmaf and link to it as an alternate qual task
[14:29:34 CET] <BBB> do you guys think thats suitable? should be ok right?
[14:30:36 CET] <hemalpatil> BBB: does that mean I will not be to able apply for it for GSoC'17?
[14:30:42 CET] <BBB> you will
[14:30:51 CET] <BBB> but it means theres multiple candidates for each project
[14:30:51 CET] <hemalpatil> ok
[14:32:24 CET] <BBB> https://github.com/Netflix/vmaf/blob/master/wrapper/src/vmaf.cpp thats the source code for the c++ version (non-python) of the vmaf tool. I think a suitable qualification task (this isnt easy, but should be doable nonetheless) is to basically turn the API used by this tool into a library on their end, and then link against that API in a ffmpeg video filter
[14:32:32 CET] <hemalpatil> will you be selecting the candidates after the applications close (April 3rd)? also, do you have only 1 student per project or multiple students?
[14:32:34 CET] <BBB> thats still pretty close to the original GSoC task
[14:32:45 CET] <BBB> 1 student, and well pick the best
[14:32:52 CET] <BBB> (if we get enough spots)
[14:33:13 CET] <BBB> if we have enough spots, well find alternative gsoc projects for the student not selected for his/her preferred project
[14:33:18 CET] <BBB> (or something like that)
[14:33:33 CET] <hemalpatil> alright. any deadlines (other than April 3rd)?
[14:34:09 CET] <wm4> BBB: I mean there's a chance he's a developer who can or did analyze the problem and even write a patch
[14:34:54 CET] <BBB> I only select students who finish a qualification task, so it needs to be finished by whenever we have to select projects
[14:35:33 CET] <hemalpatil> ok, thanks for your help
[14:44:23 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:de2ae3c1fae5: lavc: add clobber tests for the new encoding/decoding API
[14:44:24 CET] <cone-847> ffmpeg 03Clément BSsch 07master:ad98af27f710: Merge commit 'de2ae3c1fae5a2eb539b9abd7bc2a9ca8c286ff0'
[14:45:24 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:7bf8db4db61e: tdsc: use the new decoding API
[14:45:25 CET] <cone-847> ffmpeg 03Clément BSsch 07master:5dfe343d96dc: Merge commit '7bf8db4db61eb09fac00eb665d8ec58de8817da6'
[14:46:10 CET] <cesdo> wm4: Ok. I used --pkg-config-flags="--static" ---enable-libx265 and got "ERROR: x265 not found using pkg-config". I did instructions from https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu. Libx265-dev was installed from repos. What's the safest way to solve it?
[14:46:58 CET] <ubitux> wrong channel
[14:48:04 CET] <ubitux> wm4: do you wish to port our examples to the new decode/encode api?
[14:48:22 CET] <ubitux> advertising deprecated api is not that great
[14:49:02 CET] <ubitux> `make examples` shows ton of warnings related to the old api
[14:49:03 CET] <wm4> ubitux: I wish someone else to do it
[14:49:40 CET] <ubitux> i'm hitting 67d28f4a0fb where there is a port to that new api, but doesn't apply to our code
[14:49:45 CET] <ubitux> still, we need to fix it
[14:50:08 CET] <ubitux> i'd like to go ahead with the merges so i won't have time to do that
[14:50:18 CET] <ubitux> (and i have other daemons on the todo list)
[14:54:17 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:67d28f4a0fbb: examples/output: switch to the new encoding API
[14:54:18 CET] <cone-847> ffmpeg 03Clément BSsch 07master:bb7cc5b5d928: Merge commit '67d28f4a0fbb52d0734ca3682b85035e96d294fb'
[14:54:27 CET] <wm4> skipping it for now should be ok
[14:59:49 CET] <cone-847> ffmpeg 03Mark Thompson 07master:80a5d05108cb: vaapi_encode: Refactor initialisation
[14:59:50 CET] <cone-847> ffmpeg 03Mark Thompson 07master:892bbbcdc171: vaapi_encode: Check packed header capabilities
[14:59:51 CET] <cone-847> ffmpeg 03Mark Thompson 07master:086e4b58b59e: vaapi_encode: Sync to input surface rather than output
[14:59:52 CET] <cone-847> ffmpeg 03Mark Thompson 07master:956a54129db5: vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
[14:59:53 CET] <cone-847> ffmpeg 03Clément BSsch 07master:267cb20e2bf3: Merge commit '956a54129db522998a5abae869568dae2c9774cb'
[15:04:53 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:009adfd4fbdd: x86: fpel: Remove unnecessary sign extend
[15:04:54 CET] <cone-847> ffmpeg 03Clément BSsch 07master:f54da138e98c: Merge commit '009adfd4fbdd78a890a4a65d6f141c467bb027fa'
[15:11:31 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:92c5755a1850: hpeldsp: arm: Update comments left behind in 25841dfe806a13de526ae09c11149ab1f83555a8
[15:11:32 CET] <cone-847> ffmpeg 03Clément BSsch 07master:51b5672f49f5: Merge commit '92c5755a185086067fe49e7e64c23a8e7011be31'
[15:15:59 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:3281d823cdc7: intrax8: Change type of array stride parameters to ptrdiff_t
[15:16:00 CET] <cone-847> ffmpeg 03Clément BSsch 07master:6eb75e7d592d: Merge commit '3281d823cdc7601c4900eb103958c05f59f65555'
[15:21:12 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:b2939a75270b: blockdsp: Change type of array stride parameters to ptrdiff_t
[15:21:13 CET] <cone-847> ffmpeg 03Clément BSsch 07master:6d11b2f65676: Merge commit 'b2939a75270bc7e971462648168aa3a2a48c1c8c'
[15:27:56 CET] <ubitux> the next merges are starting to be quite annoying and will require some testing
[15:28:16 CET] <ubitux> (i may already have break some mips some way or another in previous ones)
[15:28:25 CET] <ubitux> anyone willing to take over those?
[15:28:43 CET] <ubitux> (ETA: 829)
[15:29:40 CET] <philipl> BtbN: As soon as you ask for bframes when transcoding with hwaccel, you get an out-of-surfaces error
[15:29:54 CET] <ubitux> is anyone working on some oracle-like on our fate?
[15:30:04 CET] <ubitux> so i can at least test that way?
[15:30:08 CET] <philipl> Regardless of input codec, and obviously h264 on the output (nvenc doesn't support hevc bframes)
[15:34:15 CET] <ubitux> michaelni: it seems there is a leak in swr: http://fate.ffmpeg.org/report.cgi?time=20170321032538&slot=x86_64-archlinux-gcc-valgrind
[15:34:24 CET] <ubitux> (might be an opus misusage)
[15:34:44 CET] <nevcairiel> there was a fix on the ml from jamrial, possibly thats this one
[15:34:54 CET] <jamrial> yes
[15:35:10 CET] <michaelni> nevcairiel, yes, thought the same
[15:35:39 CET] <jamrial> wm4 reviewed it but i didn't commit it yet to save ubitux some merge rebasing
[15:35:53 CET] <ubitux> you can go ahead, i'm not merging anything right now
[15:35:59 CET] <ubitux> thanks for caring :)
[15:36:07 CET] <jamrial> alright
[15:36:17 CET] <ubitux> btw, if you want to enjoy some ptrdiff_t search and replace, you can take over :p
[15:36:37 CET] <ubitux> i'll work on moving my fate instances this afternoon i guess
[15:37:20 CET] <ubitux> carefull with the ptrdiff_t as they may involve code we have in other arch such as mips, aarch64 or even... alpha
[15:37:21 CET] <jamrial> did you solve the bitflip issue? the other day i saw your instances failing on a lot of tests randomly
[15:37:51 CET] <ubitux> i don't know, i'm pissed of of it, so i just upgraded to a new machine at the same cost
[15:37:55 CET] <ubitux> i just need to do the migration
[15:38:04 CET] <jamrial> heh, alpha is alive because i carried it blindly through the dsputils purge :p
[15:38:10 CET] <jamrial> maybe we should just let it die
[15:38:33 CET] <jamrial> it doesn't even have real asm. just "optimal" c versions for some compiler from a decade ago
[15:39:33 CET] <jamrial> no wait, it does have some asm. meh
[15:40:32 CET] <jamrial> ubitux: i'll try to merge a couple of these
[15:40:51 CET] <ubitux> cool, thanks :)
[16:01:40 CET] <BBB> michaelni: bugs are fairly normal, dont take any of this so personal, its just code& regressions can be addressed
[16:02:17 CET] <michaelni> BBB: what do you talk about ?
[16:02:23 CET] <michaelni> i take nothing personal
[16:03:01 CET] <BBB> the hw accel/frame-mt patches being committed
[16:05:12 CET] <michaelni> BBB, why do you think iam taking any of it personal ?
[16:05:34 CET] <michaelni> i pointed out that patches should be sent to the ML after it was pushed and broke ffplay
[16:05:48 CET] <cone-847> ffmpeg 03James Almer 07master:2a8a8a2e9813: swresample/resample: move resample_free() higher in the file
[16:05:49 CET] <cone-847> ffmpeg 03James Almer 07master:db7a05dab065: swresample/resample: free existing ResampleContext on reinit
[16:09:59 CET] <BBB> michaelni: I dont know, it sounded like you were irritated& Im just suggesting we all chill
[16:11:13 CET] <jamrial> the problems of text based communication :p
[16:23:17 CET] <cone-847> ffmpeg 03James Almer 07release/2.8:f7f5a524590b: swresample/resample: move resample_free() higher in the file
[16:23:18 CET] <cone-847> ffmpeg 03James Almer 07release/2.8:31e65eb84d6d: swresample/resample: free existing ResampleContext on reinit
[16:23:19 CET] <cone-847> ffmpeg 03James Almer 07release/3.0:2423dd965637: swresample/resample: move resample_free() higher in the file
[16:23:20 CET] <cone-847> ffmpeg 03James Almer 07release/3.0:4c97b79cf560: swresample/resample: free existing ResampleContext on reinit
[16:23:21 CET] <cone-847> ffmpeg 03James Almer 07release/3.1:f9083dec0c2e: swresample/resample: move resample_free() higher in the file
[16:23:22 CET] <cone-847> ffmpeg 03James Almer 07release/3.1:8e4abfbb9dbc: swresample/resample: free existing ResampleContext on reinit
[16:23:23 CET] <cone-847> ffmpeg 03James Almer 07release/3.2:2d322bf3e9d9: swresample/resample: move resample_free() higher in the file
[16:23:24 CET] <cone-847> ffmpeg 03James Almer 07release/3.2:2bf28b9db6e7: swresample/resample: free existing ResampleContext on reinit
[16:29:12 CET] <wm4> michaelni, BBB: well the mention that patches should be sent to the ML is certainly bullshit (I posted an updated patch on the ML, just that it was a _link_ to a patch)
[16:29:25 CET] <wm4> also also this implicit accusation that I pushed too early
[16:30:34 CET] <wm4> I also pushed 24 h after the updated patch
[16:34:15 CET] <michaelni> http://ffmpeg.org/developer.html 1.6 Submitting patches "Patches should be posted to the ffmpeg-devel mailing list. Use git send-email when possible since it will properly send patches without requiring extra care. If you cannot, then send patches as base64-encoded attachments ..."
[16:52:03 CET] <nevcairiel> lets just fix the issue, shall we
[16:58:38 CET] <wm4> well, the mutex is initialized and locked, and then the first unlock call on it appears to fail
[16:58:42 CET] <wm4> valgrind seems clean
[16:59:03 CET] <wm4> it happens because ffplay calls ff_thread_flush first thing
[16:59:19 CET] <wm4> I guess I'll take a closer look at it later
[17:37:45 CET] <jamrial> michaelni: could you check on your qemu machines (arm, aarc64) if https://github.com/jamrial/FFmpeg doesn't complain about conflicting/incompatible types?
[17:42:25 CET] <mateo`> jamrial: i can check on my aarch64 box
[17:43:08 CET] <jamrial> mateo`: cool, thanks
[17:44:39 CET] <mateo`> jamrial: i'll run fate and let you know the outcome if that helps (the box is quite slow, i'll ping you back in 2 or 3hours if that's not too late)
[17:47:36 CET] <jamrial> mateo`: compiling to see if it warns about conflicting/incompatible types should be enough i think, no need to run the whole fate suite
[17:49:04 CET] <mateo`> jamrial: ok, i'll let you know
[17:49:06 CET] Action: mateo` afk for a bit
[17:59:48 CET] <peloverde> Has the pushurl changed recently? my auth is failing
[18:02:01 CET] <jamrial> peloverde: source.ffmpeg.org is failing for me every now and then, but only when i tried to pull
[18:02:07 CET] <jamrial> had no issues trying to push
[18:04:11 CET] <michaelni> peloverde, nothing should have chnaged recently
[18:07:14 CET] <michaelni> jamrial, should i just test build or fate too under qemu ?
[18:08:07 CET] <jamrial> michaelni: build should be enough imo
[18:08:47 CET] <ubitux> jamrial: well it changes the way args are handled, so it should probably run the asm, no?
[18:09:02 CET] <ubitux> (doesn't it need use of different registers?)
[18:09:40 CET] <jamrial> the actual commit i'm merging doesn't touch asm on any arch, just the prototypes, so dunno
[18:09:46 CET] <jamrial> fate passes on x86 at least
[18:10:07 CET] <cone-847> ffmpeg 03Alex Converse 07master:2c8a3aa985ac: aacsbr: Turnoff in the event of over read.
[18:10:23 CET] <peloverde> ^ solved
[18:10:40 CET] <nevcairiel> should be fine without asm changes, you can afterwards perhaps remove a bit of redundant asm that did zero-extend in asm
[18:10:55 CET] <nevcairiel> but that would only affect 64-bit asm to begin with
[18:11:15 CET] <nevcairiel> so aarch64 and x86_64 at most
[18:12:38 CET] <jamrial> yeah, next commit in queue removes a sign extend instruction from an aarch64 asm function, for example
[18:12:59 CET] <jamrial> same thing we have always done for x86_64
[18:17:24 CET] <michaelni> jamrial, here is arm: build log http://pastebin.com/SiaL434h
[18:23:10 CET] <michaelni> jamrial, heres mips: http://pastebin.com/DrBghvZG (minus half a megabyte of unrelated msingle-float warnings)
[18:26:20 CET] <ubitux> does that mips have msa or mii or both?
[18:26:33 CET] <ubitux> (or none)
[18:31:15 CET] <jamrial> both those logs seem good
[18:38:24 CET] <michaelni> MSA seems disabled, does modern qemu support msa ?
[18:52:45 CET] <jamrial> michaelni: shouldn't you be able to cross compile it even if qemu doesn't support emulating it?
[18:53:25 CET] <michaelni> if my compiler supports it ... what configure params should i try ?
[18:54:26 CET] <michaelni> also i have that real mips machine i can try if its important
[18:56:22 CET] <jamrial> michaelni: looks like --cpu should do it
[18:56:36 CET] <jamrial> no idea which one to choose, though
[18:57:33 CET] <jamrial> the only fate instance apparently also disables all asm
[18:58:03 CET] <jamrial> meh, if it breaks someone who cares about mips can report it
[18:59:52 CET] <jamrial> michaelni: try --cpu=p5600
[19:00:08 CET] <michaelni> will do in a moment just need to finish a bisect
[19:00:18 CET] <jamrial> configure checks for compiler support for that one and seems to enable all asm
[19:03:54 CET] <michaelni> jamrial, ccache mips-linux-gnu-gcc-4.4 is unable to create an executable file.
[19:04:07 CET] <michaelni> cc1: error: unrecognized command line option "-mtune=p5600"
[19:04:30 CET] <jamrial> ah well
[19:05:09 CET] <jamrial> with no --cpu configure checks for msa inline asm anyway, so guess the compiler is too old
[19:05:25 CET] <jamrial> i'll push it then
[19:07:39 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:2ec9fa5ec60d: idct: Change type of array stride parameters to ptrdiff_t
[19:07:40 CET] <cone-847> ffmpeg 03James Almer 07master:5a49097b42cb: Merge commit '2ec9fa5ec60dcd10e1cb10d8b4e4437e634ea428'
[19:11:49 CET] <michaelni> gcc 5 with --cpu=p5600 still #define HAVE_MSA 0
[19:12:35 CET] <michaelni> mips-linux-gnu-gcc-5: error: unrecognized command line option '-mmsa'
[19:20:23 CET] <jamrial> wonder if it even work with any compiler at all then...
[19:27:08 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:e4a94d8b36c4: h264chroma: Change type of stride parameters to ptrdiff_t
[19:27:09 CET] <cone-847> ffmpeg 03James Almer 07master:a8474df9447d: Merge commit 'e4a94d8b36c48d95a7d412c40d7b558422ff659c'
[19:54:58 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:ba479f3daafc: hevc: Change type of array stride parameters to ptrdiff_t
[19:54:59 CET] <cone-847> ffmpeg 03James Almer 07master:1e185488269f: Merge commit 'ba479f3daafc7e4359ec1212164569ebe59f0bb7'
[19:56:43 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:a339e919cad1: ea: Change type of array stride parameters to ptrdiff_t
[19:56:44 CET] <cone-847> ffmpeg 03James Almer 07master:b16752f694a5: Merge commit 'a339e919cad1ab0125948f0dd9d49f6cb590db89'
[19:58:51 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:15b4f494fc6b: mss*: Change type of array stride parameters to ptrdiff_t
[19:58:52 CET] <cone-847> ffmpeg 03James Almer 07master:a0478341f34b: Merge commit '15b4f494fc6bddb8178fdb5aed18b420efc75e22'
[20:05:52 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:2caa93b813ad: mpegaudiodsp: Change type of array stride parameters to ptrdiff_t
[20:05:53 CET] <cone-847> ffmpeg 03James Almer 07master:9a0fbb9ca925: Merge commit '2caa93b813adc5dbb7771dfe615da826a2947d18'
[20:11:40 CET] <cone-847> ffmpeg 03Hendrik Leppkes 07master:8d1267932ca9: x86/h264_weight: use appropriate register size for weight parameters
[20:11:41 CET] <cone-847> ffmpeg 03James Almer 07master:387d96fcf54b: Merge commit '8d1267932ca9c2e343ef303349101bab6681d02e'
[20:13:14 CET] <jamrial> 83548fe894cdb455cc127f754d09905b6d23c173 is the kind of commit that makes us regret having so many de/muxers :P
[20:57:42 CET] <cone-847> ffmpeg 03Michael Niedermayer 07master:b15818642b4e: avcodec/mpegaudiodec_template: Fix 2 runtime error: signed integer overflow
[20:57:43 CET] <cone-847> ffmpeg 03Michael Niedermayer 07master:423375d4f06a: avcodec/wavpack: Check shift
[21:00:25 CET] <kierank> do memory leaks require backporting?
[21:01:19 CET] <jamrial> doesn't hurt
[21:03:44 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:83548fe894cd: lavf: fix usage of AVIOContext.seekable
[21:03:45 CET] <cone-847> ffmpeg 03James Almer 07master:4de591e6fb73: Merge commit '83548fe894cdb455cc127f754d09905b6d23c173'
[21:05:29 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:75c1db6152c7: avio: cosmetics, prettify AVIO_SEEKABLE_NORMAL
[21:05:30 CET] <cone-847> ffmpeg 03James Almer 07master:de36e98a16f4: Merge commit '75c1db6152c7c90c7ce28c9adb945028e5512c4f'
[21:10:33 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:8ea35af7620e: avio: add a new flag for marking streams seekable by timestamp
[21:10:34 CET] <cone-847> ffmpeg 03James Almer 07master:fc9f14c7de5b: Merge commit '8ea35af7620e4f73f9e8c072e1c0fac9a04ec161'
[21:11:16 CET] <jamrial> ubitux: done with the search and replace party
[21:11:27 CET] <ubitux> jamrial: thanks!
[21:11:43 CET] <ubitux> i'll take over starting tomorrow
[21:12:03 CET] <jamrial> no prob
[21:37:14 CET] <kierank> what does this mean
[21:37:16 CET] <kierank> usr/bin/ld:libswscale/libswscale.ver:1: syntax error in VERSION scrip
[22:27:02 CET] <mateo`> jamrial: sorry for being late, but the build went fine on my aarch64 box, executing the simple_idct_put_neon functions
[22:27:08 CET] <mateo`> went well
[22:27:35 CET] <jamrial> mateo`: thanks
[22:27:59 CET] <mateo`> jamrial: thanks for the merges :)
[23:16:26 CET] <cone-847> ffmpeg 03James Almer 07master:d8962ffbd8aa: avutil/x86util: don't use movss in VBROADCASTSS macro when src and dst args are the same
[23:16:27 CET] <cone-847> ffmpeg 03James Almer 07master:874eb012f75b: avformat/apng: fix setting frame delay when max_fps is set to no limit
[23:16:28 CET] <cone-847> ffmpeg 03James Almer 07master:7bfbb7229971: avformat/apng: set max_fps to no limit by default
[23:49:40 CET] <jkqxz> wm4: The VDPAU code on the two tines is subtly different such that device setup doesn't merge cleanly, so I've not done that for now.
[00:00:00 CET] --- Wed Mar 22 2017
More information about the Ffmpeg-devel-irc
mailing list