[Ffmpeg-devel-irc] ffmpeg-devel.log.20170516
burek
burek021 at gmail.com
Wed May 17 03:05:04 EEST 2017
[00:26:11 CEST] <jkqxz> Can it be assumed that files uploaded to the bug tracker are ok to be put in fate?
[00:33:17 CEST] <J_Darnley> I think not.
[00:33:43 CEST] <J_Darnley> I seem to recall some fuss over the "standard" lena image a few years ago.
[00:33:58 CEST] <J_Darnley> Maybe because it was porn, maybe because it is copyrighted.
[00:34:49 CEST] <J_Darnley> Uploaded samples may have the same problems.
[00:36:08 CEST] <Threads> lol do people actually upload porn samples ?
[00:42:33 CEST] <nevcairiel> technically lena is "porn", it is a scan from playback afterall
[00:42:46 CEST] <nevcairiel> but yes, some of the most broken and weirdest samples are porn
[00:42:54 CEST] <nevcairiel> playboy*
[00:47:07 CEST] <Compn> jkqxz : ask whoever maintains fate about adding whatever sample
[00:47:22 CEST] Action: Compn not helping
[00:47:23 CEST] <Compn> hehe
[00:54:36 CEST] <jamrial> J_Darnley: lena was debian and because licenses
[00:55:49 CEST] <J_Darnley> ah
[00:57:55 CEST] <thebombzen> hey, I'd like to submit a short documentation patch
[00:58:04 CEST] <thebombzen> (http://0x0.st/gpn.patch)
[00:58:29 CEST] <thebombzen> do these go through the mailing list anyway, even ones small like this
[00:59:08 CEST] <J_Darnley> If you don't have commit access then you will need to ask someone to do that somewhere.
[00:59:38 CEST] <thebombzen> well yea but I meant do I need to go through the mailing list or is putting it here enough
[01:08:18 CEST] <JEEB> I've seen plenty of doc patches on the ML
[01:08:40 CEST] <JEEB> git send-email is your friend if you like command line (once you set up SMTP with it)
[01:08:54 CEST] <JEEB> (and yes, it's got a dry-run switch)
[01:11:03 CEST] <J_Darnley> just make sure you install all the required bits before editing an email.
[01:11:27 CEST] <J_Darnley> otherwise you'll hit save, it will try to send, fail, then you'll have to make it again.
[01:24:14 CEST] <thebombzen> I've used send-email before, I just didn't know if it was necessary to use something heavyweight like that for such a minor patch. but will do
[01:26:29 CEST] <thebombzen> JEEB: do I need a message ID?
[01:26:47 CEST] <nevcairiel> no, thats only for replying to existing mails
[01:28:04 CEST] <thebombzen> alright sent it
[01:36:12 CEST] <thebombzen> oops
[01:38:47 CEST] <thebombzen> alright rejoined and resent
[01:50:21 CEST] <jamrial> nevcairiel: push your hvcc patch already :p
[01:51:21 CEST] <nevcairiel> hvcc?
[01:51:24 CEST] <nevcairiel> you mean vpcc?
[01:51:34 CEST] <jamrial> right, that
[01:58:25 CEST] <nevcairiel> my fate box should also be back up soon, been doing a long-overdue rebuild now that the disc was finally full, purging old msvc versions is such a pain, better to start fresh
[02:15:21 CEST] <cone-685> ffmpeg 03Hendrik Leppkes 07master:64ad44a3817a: movenc/isom: update vpcC box to version 1.0 of the specification
[02:23:59 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07master:f08122fbe039: avcodec/tiff: reset sampling[] if its invalid
[02:24:00 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07master:a6eb006ad47b: avcodec/svq3: Fix runtime error: left shift of negative value -6
[02:28:09 CEST] <DHE> libavfilter is not very friendly to being updated for parallel processing. I wanted to add either per-filter threads (a true pipeline using threading) or at least allow [a]split to distribute, but it's a lot less friendly to that...
[02:28:31 CEST] <DHE> are the internals of libavfilter documented for hacking somewhere?
[02:29:21 CEST] <J_Darnley> In my opinion: not really, no
[02:30:02 CEST] <DHE> I was afraid of that...
[02:30:07 CEST] <J_Darnley> I recall that I never understood it quite well enough to finish my idea of writing an example filter
[02:30:58 CEST] <J_Darnley> One that does nothing but pass frames through but shows the places where you should buffer, should return more than 1 frame, etc.
[02:31:50 CEST] <J_Darnley> Even that sounds like it isn't enough for what you're asking
[02:32:50 CEST] <DHE> I'm more interested in the avfilter framework itself. the graph builder, filter allocator and connector, and so on
[03:18:26 CEST] <jamrial> J_Darnley: "h264_idct.asm:1144: warning: redefining multi-line macro 'STORE_DIFFx2'"
[03:20:07 CEST] <J_Darnley> Ah. I thought I had fixed that. It should still work though.
[03:21:04 CEST] <J_Darnley> Oh no. I had to comment out that %unmacro
[03:53:44 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:c521f9a5cd8c: avcodec/tiff: reset sampling[] if its invalid
[03:53:45 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:8e6d9d48a0b4: avcodec/svq3: Fix runtime error: left shift of negative value -6
[03:53:46 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:1274e920152d: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[03:53:47 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:f61c888743d1: Update for FFmpeg 3.2.5
[04:23:08 CEST] <cone-685> ffmpeg 03Gregory J. Wolfe 07release/3.2:5d737a3d0ca2: avformat/tests/fifo_muxer: includes libavformat/network.h to define ETIMEDOUT for fate build.
[04:37:19 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07n3.2.5:HEAD: avcodec/svq3: Fix runtime error: left shift of negative value -6
[04:50:48 CEST] <jamrial> looks like we're getting some spam in trac
[04:51:29 CEST] <jamrial> and now it doesn't even load
[04:52:53 CEST] <alevinsn> nevcairiel: Did you have to patch d3d9.h to fix the issue with the IDirect3D9Ex vtable
[04:52:54 CEST] <alevinsn> ?
[04:53:01 CEST] <alevinsn> when building with MSVC?
[04:55:33 CEST] <alevinsn> I had to do that to get hwcontext_dxva2.c to work properly (with regard to dxva2_device_create9ex())
[05:02:07 CEST] <jamrial> michaelni: who manages trac? we're getting spam from what looks like a single user with several accounts in the above ticket
[05:02:46 CEST] <jamrial> llogan isn't around
[05:10:57 CEST] <michaelni> jamrial, ive added you to the spam fighters so you have some more permissions, maybe it will come in usefull
[05:11:20 CEST] <michaelni> iam a bit tired ATM (should go to bed ...) :(
[05:11:23 CEST] <jamrial> michaelni: cool, thanks
[07:10:51 CEST] <alevinsn> jkqxz: you there?
[07:49:53 CEST] <ubitux> wtf is wrong with the guy in #6389
[09:08:19 CEST] <wm4> [amediaformat @ 0x2030432300] No Java virtual machine has been registered
[09:08:35 CEST] <wm4> mateo`: I guess ffmpeg.c doesn't work with mediacodec due to missing JNI crap?
[09:15:48 CEST] <JEEB> wm4: yea
[09:16:19 CEST] <JEEB> since the JVM instance auto-get thing wasn't something usable
[09:19:34 CEST] <jkqxz> alevinsn: Yes.
[10:29:24 CEST] <cone-630> ffmpeg 03Aman Gupta 07master:376247a1028f: configure: jni no longer requires -ldl
[11:17:18 CEST] <durandal_170> llogan is adding bad ips out of where?
[11:18:42 CEST] <wm4> probably spam?
[11:21:21 CEST] <durandal_170> votes are not spam
[11:24:00 CEST] <nevcairiel> if its the same person doing the voting, it is =p
[11:24:11 CEST] <stevenliu> It's not
[11:25:18 CEST] <stevenliu> The winlin is my friend, he invitation many people to append message vote to the ticket :)
[11:25:27 CEST] <nevcairiel> you should find better friends
[11:25:56 CEST] <stevenliu> There have lots of people invitation him add the hevc codec into flv and his SRS rtmp server
[11:26:18 CEST] <stevenliu> for support real time live stream
[11:26:39 CEST] <nevcairiel> supporting a new codec in a container is not something you can just make appear, it requires an official specification, otherwise you just produce unreadable files
[11:26:41 CEST] <JEEB> basically he should stop ignoring what I actually said and not focus on what I mentioned regarding HLS/DASH
[11:27:06 CEST] <nevcairiel> especially in a container like flv which doesnt use FourCCs or whatever
[11:27:09 CEST] <nevcairiel> but a simple numeric index
[11:27:10 CEST] <JEEB> switching solutions to Matroska/MPEG-TS/fragmented mp4 over HTTP will make you more future-proof
[11:27:26 CEST] <JEEB> the fact that current software media server solutions don't have that is just... too bad
[11:27:34 CEST] <JEEB> FLV has come to the end of its useful lifespan
[11:27:37 CEST] <stevenliu> mhmm, i think mpegts is better way
[11:27:38 CEST] <AaronL> anyone here familiar with hwcontext_dxva2.c?
[11:27:52 CEST] <JEEB> stevenliu: well whatever you prefer. both matroska and mpeg-ts should be workable
[11:28:06 CEST] <JEEB> the fun fact of that person *completely* ignoring my points about that is just welp
[11:28:20 CEST] <JEEB> he just focuses ASDF ASDF HLS/DASH can't do 3-5 seconds of latency
[11:28:22 CEST] <stevenliu> but the CDN Compnay maybe not friendly support them
[11:28:40 CEST] <stevenliu> JEEB, Don't care that
[11:28:58 CEST] <JEEB> whatever stops them from breaking with your hacked-up RTMP
[11:29:08 CEST] <AaronL> nevcairiel: you there?
[11:29:09 CEST] <JEEB> if you hack up RTMP (FLV) with HEVC
[11:29:18 CEST] <stevenliu> He just want get a low latency result of HLS or DASH
[11:29:25 CEST] <nevcairiel> AaronL: everything builds just fine for me
[11:29:40 CEST] <AaronL> nevcairiel: the d3d9.h issue is a run-time problem
[11:29:43 CEST] <AaronL> not a build issue
[11:29:55 CEST] <AaronL> only occurs if using DXVA hardware frame context
[11:30:13 CEST] <AaronL> it may depend on the version of the Windows 10 SDK installed
[11:30:24 CEST] <AaronL> older versions of d3d9.h are missing an entry
[11:30:40 CEST] <AaronL> for one of the interfaces--only affects C-style COM usage
[11:31:11 CEST] <AaronL> anyway, I think I've found a bug having to do with hwcontext_dxva2.c (unrelated to the d3d9.h issue)
[11:31:17 CEST] <AaronL> I'm not sure what the proper way to fix it
[11:31:24 CEST] <AaronL> it is freeing memory that it shouldn't be freeing
[11:33:40 CEST] <nevcairiel> all win10 sdks I have seem to have the missing function, the 8.1 sdk seems to lack it though
[11:34:06 CEST] <alevinsn> yeah
[11:34:18 CEST] <alevinsn> at least with my install of Visual Studio 2015
[11:34:26 CEST] <alevinsn> it uses d3d9.h from the 8.1 SDK
[11:34:46 CEST] <alevinsn> and there are only UCRT related headers in the 10 directory
[11:35:33 CEST] <alevinsn> but, I just installed the latest Windows 10 SDK
[11:35:36 CEST] <alevinsn> and that has all the headers
[11:35:51 CEST] <jkqxz> What is the problem?
[11:36:01 CEST] <alevinsn> and it also fixes the source stepping issue with the CRT
[11:36:29 CEST] <alevinsn> as in, I can step through _aligned_malloc, etc
[11:36:45 CEST] <alevinsn> at least when using the debug CRT
[11:36:53 CEST] <alevinsn> ok, so, it crashes in buffer_pool_free()
[11:37:04 CEST] <alevinsn> for the pool associated with hwcontext_dxva2
[11:37:11 CEST] <nevcairiel> we should check for RegisterSoftwareDevice to be present and only then make use of 9ex then, i guess
[11:37:19 CEST] <alevinsn> I'm doing this through qsv (hw encoding)
[11:37:57 CEST] <alevinsn> so, there is the sort of fake qsv pool
[11:38:12 CEST] <alevinsn> and then the child hw frame context which is dxva2
[11:38:33 CEST] <alevinsn> it is crashing at the line buf->free(buf->opaque, buf->data);
[11:38:39 CEST] <alevinsn> for the dxva2 pool
[11:38:59 CEST] <alevinsn> the problem is, buf->data was not allocated by hwcontext_dxva2.c
[11:39:10 CEST] <alevinsn> each of the elements stored in buf->data are DXVA2 surfaces
[11:39:41 CEST] <alevinsn> that were originally created by CreateSurface()
[11:40:04 CEST] <alevinsn> a search for surfaces_internal
[11:40:16 CEST] <alevinsn> will demonstrate that's how data is assigned to buf
[11:40:26 CEST] <alevinsn> with the call to av_buffer_create() in dxca2_pool_alloc()
[11:40:59 CEST] <alevinsn> I think perhaps the solution is to pass in a dummy free
[11:41:03 CEST] <alevinsn> as the third parameter
[11:41:13 CEST] <alevinsn> to av_buffer_create()
[11:41:30 CEST] <alevinsn> qsv_pool_alloc() does that
[11:41:36 CEST] <alevinsn> when it calls av_buffer_create()
[11:42:12 CEST] <nevcairiel> alevinsn: for the record, building with msvc here uses the latest windows 10 sdk, but then again I do actually have them fully installed and not only the ucrt :)
[11:42:24 CEST] <alevinsn> nevcairiel: That's one way--but, there is a good reason to use 9ex--works with headless displays
[11:42:39 CEST] <alevinsn> I think it would be preferable to display a warning
[11:42:48 CEST] <nevcairiel> we dont do that
[11:42:50 CEST] <alevinsn> than revery to dx9
[11:43:13 CEST] <alevinsn> nevcairiel: I examined the check-in log that added support for Ex
[11:43:20 CEST] <alevinsn> that was specifically mentioned as the reason for doing that
[11:43:24 CEST] <nevcairiel> it should just check if the interface is working properly in configure, and only compile the 9ex code if that is the case
[11:43:40 CEST] <nevcairiel> well we still dont randomly spout warnings about missing features
[11:43:57 CEST] <wm4> you mean git commit?
[11:43:58 CEST] <alevinsn> if its done that way, then users won't know that they are missing something that is easily corrected
[11:44:09 CEST] <alevinsn> I just manually edited the file to correct it
[11:44:12 CEST] <nevcairiel> modifying a SDK header is not an "easy correction" in my book
[11:44:26 CEST] <wm4> what's wrong with the SDK header?
[11:44:28 CEST] <alevinsn> the line is already there for the non-ex interface
[11:44:33 CEST] <alevinsn> just copy and paste
[11:44:57 CEST] <nevcairiel> pre-win10 headers lack one function in the vtbl of the IDirect3D9Ex header, which makes its offsets wrong for C-style use
[11:45:18 CEST] <alevinsn> this has been an issue for many years and Microsoft only fixed it recently supposedly
[11:45:20 CEST] <wm4> ouch
[11:45:24 CEST] <wm4> so use win10 headers?
[11:45:28 CEST] <alevinsn> because almost no one uses the C-style
[11:45:37 CEST] <alevinsn> well, even some Win10 headers didn't have it fixed
[11:45:41 CEST] <alevinsn> was apparently fixed in 10240
[11:45:51 CEST] <wm4> ask MS to fix them?
[11:45:56 CEST] <alevinsn> but, if you just get it via Visual Studio 2015
[11:46:02 CEST] <alevinsn> it only installed the 8.1 d3d9.h header
[11:46:02 CEST] <nevcairiel> it is fixed, but they are not going to fix old releases of the windows sdk
[11:46:03 CEST] <wm4> alternatively we could provide our own headers in compat/
[11:46:27 CEST] <nevcairiel> meh its not worth that headache, just add a check and only use ex when the header is correct
[11:47:08 CEST] <alevinsn> I guess that's better than crashing
[11:47:10 CEST] <wm4> seems good
[11:47:23 CEST] <alevinsn> but, it would be nice to inform the user that their header is bad, I think
[11:47:31 CEST] <nevcairiel> like I said, we dont do that
[11:47:48 CEST] <alevinsn> I know, I think this is a special case
[11:47:52 CEST] <jkqxz> alevinsn: I think I agree with your surfaces_internal / buffer comments above. Dummy free function looks like the right solution.
[11:48:09 CEST] <jkqxz> Not sure why it doesn't always die, though.
[11:48:29 CEST] <alevinsn> jkqxz: it gets past it without any problems when built without using the debug C-runtime
[11:48:38 CEST] <alevinsn> with the debug C-runtime, it notices what appears to be
[11:48:42 CEST] <alevinsn> memory corruption
[11:48:47 CEST] <alevinsn> after the fake "free"
[11:48:54 CEST] <alevinsn> or rather, the free attempt
[11:49:12 CEST] <alevinsn> it isn't memory corruption
[11:49:49 CEST] <alevinsn> but, because of code in the debug version of _aligned_free
[11:50:19 CEST] <alevinsn> that expects 0xCD (or somethhing like that) to show up before the allocation returned to the user
[11:50:21 CEST] <alevinsn> and that isn't there
[11:50:27 CEST] <alevinsn> it reports memory corruption
[11:50:47 CEST] <wm4> uh wait
[11:51:08 CEST] <wm4> if no free callback is set, it should do nothing
[11:51:28 CEST] <wm4> you mean the last arg to av_buffer_pool_init2?
[11:51:46 CEST] <alevinsn> no, this is av_buffer_create()
[11:51:55 CEST] <alevinsn> the third arg is used to override the default free behavior
[11:52:02 CEST] <jkqxz> No, av_buffer_create(). It uses av_buffer_default_free(), which is av_free(), if you don't pass an argument.
[11:52:06 CEST] <alevinsn> otherwise, it uses av_buffer_default_Free()
[11:53:46 CEST] <wm4> ok
[11:54:32 CEST] <wm4> I'm fairly sure the AVBuffer should reference the surface though
[11:54:42 CEST] <wm4> instead of implicitly relying that something else does
[11:54:43 CEST] <wm4> maybe
[11:56:41 CEST] <alevinsn> nevcairiel: do you know if Zeranoe builds with MSVC or gcc for Windows?
[11:58:02 CEST] <nevcairiel> probably gcc
[11:58:27 CEST] <nevcairiel> msvc would probably hell to get going with all those useless external libraries
[11:59:05 CEST] <BtbN> Pretty sure it's a cross-compile aswell
[11:59:27 CEST] <nevcairiel> that isnt exactly required
[12:00:08 CEST] <alevinsn> do you know anyone else that builds using MSVC?
[12:01:03 CEST] <nevcairiel> unless you need it for static linking or debugging purposes, there probably isnt a good reason to do that, builds are slower and its hard
[12:01:09 CEST] <nevcairiel> so likely very little people do that
[12:02:10 CEST] <alevinsn> debugging is the main reason it seems
[12:02:15 CEST] <alevinsn> you can't do static linking with gcc?
[12:03:23 CEST] <nevcairiel> it uses a different crt, so static linking a msvc build app to a mingw-gcc library is a bit iffy
[12:03:59 CEST] <alevinsn> possibly even true for dynamic linking?
[12:04:01 CEST] <nevcairiel> it is possible, but requires hacking
[12:04:07 CEST] <nevcairiel> dynamic linking works fine
[12:05:03 CEST] <wm4> the only "real" reason to build on MSVC is apparently winrt, which doesn't support dxva2 anyway
[12:05:21 CEST] <nevcairiel> i would use msvc builds at all times if they werent quite a bit slower
[12:06:18 CEST] <alevinsn> nevcairiel: I guess it works fine because all memory passed to ffmpeg DLLs is allocated and deallocated in ffmpeg code
[12:06:29 CEST] <alevinsn> if someone used free() instead of av_free(), might be problematic
[12:06:59 CEST] <nevcairiel> well of course, the public API documents which memory requires using av_malloc/av_free
[12:07:48 CEST] <nevcairiel> under the hood its also _aligned_malloc, so even if it would be the same crt you would have to use _aligned_malloc as well, ordinary memory from malloc or new would never be fine
[12:09:02 CEST] <nevcairiel> (although its generally not that commong for user-allocated memory to be free'ed by the library, or vice-versa)
[12:10:36 CEST] <alevinsn> jkqxz: yeah, that fixes it
[12:10:47 CEST] <alevinsn> a pretty easy fix
[12:13:21 CEST] <alevinsn> the whole way the QSV hwcontext is setup is incredibly complicated
[12:18:39 CEST] <jkqxz> Well, yes. Do you think any of the complexity is unjustified, though?
[12:19:41 CEST] <alevinsn> I don't know--much of it seems to be there to support Windows and Linux
[12:19:54 CEST] <alevinsn> I don't understand why the qsv code bothers doing some of the things it is doing
[12:19:55 CEST] <alevinsn> though
[12:21:39 CEST] <alevinsn> for example, in qsv_init_pool()
[12:22:00 CEST] <alevinsn> is allocates a surfaces_internal and fills out each surface
[12:22:20 CEST] <alevinsn> I don't know why it needs this if it is just going to use the child frame context for everything
[12:22:37 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:e6ec482b429b: opusenc: initialize PVQ prng seed
[12:22:38 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:8e7e74df93d1: opus_pvq: port to allow for SIMD functions
[12:22:39 CEST] <cone-630> ffmpeg 03Daniil Cherednik 07master:9c4e69b8eac8: avcodec/dcaenc: Do not abort process in case of bitrate deficit
[12:22:53 CEST] <alevinsn> furthermore, qsv.c allocates its own HW frame context as well
[12:23:14 CEST] <jkqxz> The mfxFrameSurface1 structures have to exist somewhere.
[12:24:11 CEST] <jkqxz> (The child context only supplies the MemId for each one.)
[12:25:34 CEST] <jkqxz> qsv.c allocates one if the user doesn't supply one.
[12:25:53 CEST] <alevinsn> I supplied one, and it is allocated no matter what
[12:26:34 CEST] <alevinsn> ok, I see how the mfxFrameSurface1 stuff is done
[12:26:49 CEST] <jkqxz> With H.265?
[12:26:51 CEST] <alevinsn> although, the Intel sample code has it being populated in a way that perhaps more sense
[12:26:54 CEST] <alevinsn> H.264
[12:26:59 CEST] <alevinsn> although I don't think that matters
[12:27:23 CEST] <alevinsn> in my code, I have something like:
[12:27:43 CEST] <alevinsn> // Allocate surface headers (mfxFrameSurface1) for encoder
[12:27:43 CEST] <alevinsn> mfxFrameSurface1 *pmfxSurfaces = new mfxFrameSurface1[numSurfaces];
[12:27:43 CEST] <alevinsn> memset(pmfxSurfaces, 0, sizeof(mfxFrameSurface1) * numSurfaces);
[12:27:43 CEST] <alevinsn> mfxU16 i;
[12:27:43 CEST] <alevinsn> for (i = 0; i < numSurfaces; i++)
[12:27:43 CEST] <alevinsn> {
[12:27:45 CEST] <alevinsn> memcpy(&(pmfxSurfaces[i].Info), &(m_mfxEncParams.mfx.FrameInfo), sizeof(mfxFrameInfo));
[12:27:47 CEST] <alevinsn> if (m_bUseVideoMemory)
[12:27:49 CEST] <alevinsn> {
[12:27:53 CEST] <alevinsn> pmfxSurfaces[i].Data.MemId = m_mfxResponse.mids[i];
[12:27:55 CEST] <alevinsn> }
[12:27:57 CEST] <alevinsn> else
[12:27:59 CEST] <alevinsn> {
[12:28:01 CEST] <alevinsn> mfxU8 *surfaceBuffer = (mfxU8 *) _aligned_malloc(surfaceSize, 32);
[12:28:03 CEST] <alevinsn> pmfxSurfaces[i].Data.Y = surfaceBuffer;
[12:28:05 CEST] <alevinsn> pmfxSurfaces[i].Data.U = pmfxSurfaces[i].Data.Y + (width * height);
[12:28:07 CEST] <alevinsn> pmfxSurfaces[i].Data.V = pmfxSurfaces[i].Data.U + 1;
[12:28:09 CEST] <alevinsn> pmfxSurfaces[i].Data.Pitch = width;
[12:28:11 CEST] <alevinsn> }
[12:28:13 CEST] <alevinsn> }
[12:28:22 CEST] <jkqxz> Please don't paste nontrivial things into the channel.
[12:28:32 CEST] <alevinsn> ok
[12:28:41 CEST] <alevinsn> rather than filling bogus parameters in surf->Info
[12:28:53 CEST] <alevinsn> like a frame rate of 25/1
[12:29:28 CEST] <atomnuker> planning to push the librsvg library wrapper in a few moments, any objections (patches have been on the ML for a week)
[12:30:05 CEST] <alevinsn> jkqxz: regarding qsv.c, what I see happen is
[12:30:08 CEST] <jkqxz> I'm not entirely familiar with it, but IIRC the external allocation requirement is because H.265 doesn't work properly with hardware surfaces input without it (due to additional buffer requirements).
[12:30:25 CEST] <alevinsn> it gets to qsv_frame_alloc()
[12:30:36 CEST] <alevinsn> hits the internal_frame case
[12:30:54 CEST] <alevinsn> and that automatically triggers the creation of a hwframe_ctx
[12:31:04 CEST] <alevinsn> this hwframe_ctx is different from the one
[12:31:07 CEST] <alevinsn> that is used by the user
[12:31:08 CEST] <jkqxz> And once you have the external allocator, the library forces you to use it for everything else as well. Hence it getting used for the reconstructed surfaces, separately to the input surfaces.
[12:31:25 CEST] <alevinsn> it has lock and unlock implemented, for example
[12:31:41 CEST] <jkqxz> And that's your second hwframes context in H.264.
[12:32:15 CEST] <alevinsn> I'm not aware of any special HEVC requirements
[12:32:31 CEST] <alevinsn> I basically use the same code for HEVC as I use for H.264
[12:32:58 CEST] <jkqxz> And you give it hardware surfaces at the input?
[12:33:04 CEST] <alevinsn> yes
[12:33:12 CEST] <jkqxz> (It would probably be easier to ask elenril about this.)
[12:33:19 CEST] <alevinsn> works with software memory as well, but it is more robust to use hardware memory
[12:34:23 CEST] <alevinsn> its just sort of odd to have two hwframe contexts and basically two different mfxFrameAllocator objects
[12:35:12 CEST] <alevinsn> elenril is on libav-devel?
[12:35:48 CEST] <alevinsn> yeah
[12:43:44 CEST] <alevinsn> I'd like to fix the memory leak with default_lockmgr_cb (in utils.c) for the AV_LOCK_OBTAIN case
[12:43:53 CEST] <alevinsn> but I'm not sure if a good way to free this memory
[12:44:00 CEST] <alevinsn> its only 87 bytes, but still....
[12:44:05 CEST] <alevinsn> sure of a
[12:44:29 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:a13eac5a9959: lavc: add codec ID and description for SVG
[12:44:30 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:f68ea9283347: img2dec: add support for piped SVG demuxing
[12:44:31 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:5fd4cffe3214: lavc: add a librsvg rasterization library wrapper
[12:44:54 CEST] <nevcairiel> you cant really fix this case
[12:45:46 CEST] <nevcairiel> a tiny one-time leak in an executable is rather irrelevant, it gets freed on exit anyway
[12:45:47 CEST] <durandal_170> omg, i forgot to block this svg nonsense
[12:45:57 CEST] <alevinsn> yeah, its allocated once for all the codecs
[12:46:14 CEST] <alevinsn> some sort of static cleanup I guess would be needed to eliminate the leak
[12:47:14 CEST] <durandal_170> vectorized video when?
[12:47:43 CEST] <alevinsn> maybe the reverse of av_register_all()?
[12:47:48 CEST] <alevinsn> that is called at the end of the program
[12:49:30 CEST] <nevcairiel> better would be to eliminate the need for the lockmgr and make everything thread safe, then we can just delete it :)
[12:49:55 CEST] <wm4> yes, the lock manager is bullshit and will be removed once all codecs have been fixed
[12:50:11 CEST] <nevcairiel> some people started working on it, but its along and tedious process
[12:50:36 CEST] <kierank> derek did a lot of work on it
[12:50:57 CEST] <kierank> but iirc it's not just needed for threadsafe stuff
[12:51:04 CEST] <kierank> there is some other reason
[12:51:09 CEST] <nevcairiel> he identified a bunch of codecs that were already safe
[12:51:12 CEST] <nevcairiel> not sure he fixed many
[12:51:27 CEST] <nevcairiel> but thats already helpful, to identify areas that need work
[12:52:36 CEST] <cone-630> ffmpeg 03Carl Eugen Hoyos 07master:66e56e7b2e76: librsvgdec: Fix pix_fmt on big-endian hardware.
[13:09:18 CEST] <atomnuker> J_Darnley, BBB: patch to use strip -x instead of -wN ..@ sent to the ML
[13:10:01 CEST] <alevinsn> jkqxz: I submitted a patch just now for the issue in hwcontext_dxva2.c
[13:10:40 CEST] <nevcairiel> your commit message would benefit from some whitespace
[13:10:41 CEST] <nevcairiel> :D
[13:12:10 CEST] <alevinsn> ?
[13:12:29 CEST] <alevinsn> not sure I follow
[13:13:08 CEST] <nevcairiel> an appropriate newline here and there increase readability
[13:13:37 CEST] <alevinsn> its a single paragraph
[13:13:41 CEST] <alevinsn> with like 3 sentences
[13:13:53 CEST] <alevinsn> maybe 5
[13:15:01 CEST] <nevcairiel> well my mail client shows it as 13 lines without a single line break
[13:15:39 CEST] <alevinsn> hmm
[13:15:55 CEST] <alevinsn> Each line is 72 characters long
[13:16:00 CEST] <alevinsn> there are technically line breaks
[13:16:05 CEST] <alevinsn> at most 72 characters long I mean
[13:16:25 CEST] <alevinsn> if you compare it to the lines of actual code
[13:16:35 CEST] <alevinsn> you'll see that there are no lines as long as those
[13:17:43 CEST] <alevinsn> but, if you meant, 13 lines without any blank lines in between
[13:17:46 CEST] <alevinsn> yes, that's correct
[13:17:56 CEST] <nevcairiel> who ever shortened the 80 col limit which was already insanely tiny even further to 72 anyway
[13:18:07 CEST] <alevinsn> It still seems to me to be a fairly short paragraph
[13:18:25 CEST] <nevcairiel> all I know is that it doesnt look extremely readable to me
[13:19:56 CEST] <alevinsn> ok, I don't think I'll do anything with it now though after 4 AM here
[13:20:18 CEST] <alevinsn> at least I now know how to use a hw frame context for encoding
[13:20:30 CEST] <alevinsn> there is only a qsv decoding example in doc/examples
[13:20:51 CEST] <alevinsn> its a bit non-intuitive
[13:20:54 CEST] <alevinsn> I think
[13:20:55 CEST] <nevcairiel> the hwcontext stuff is still rather new and under development
[13:21:28 CEST] <J_Darnley> atomnuker: thanks. I'll send a reply at some point.
[13:21:43 CEST] <alevinsn> maybe I'll create a sample to demonstrate how to do this
[13:21:46 CEST] <nevcairiel> ultimately jkqxz even dreams of a world without qsv decoding, and instead mapping dxva2 or vaapi surfaces into the qsv encoder
[13:22:01 CEST] <alevinsn> its already doing that
[13:22:14 CEST] <alevinsn> mapping dxva2 or vaapi surfaces into the qsv encoder
[13:22:17 CEST] <nevcairiel> was that merged ? i didnt pay much attention
[13:22:18 CEST] <alevinsn> it has to
[13:22:36 CEST] <alevinsn> I can't imagine that it ever worked without that
[13:22:59 CEST] <nevcairiel> well it could use the qsv pix_fmt, which hides a bit what it actually is
[13:23:05 CEST] <alevinsn> there is no such thing as a QSV surface
[13:23:08 CEST] <nevcairiel> straight from the qsv decoder
[13:23:13 CEST] <alevinsn> yeah, the QSV pix fmt is a little odd
[13:23:27 CEST] <nevcairiel> the point is to actually use dxva2 or vaapi decoding
[13:23:28 CEST] <alevinsn> but, it really is just a layer on top of DXVA2 or VAAPI pix fmt
[13:23:29 CEST] <nevcairiel> not qsv decoding
[13:23:36 CEST] <alevinsn> it has to use QSV decoding
[13:23:44 CEST] <alevinsn> I mean, I want it do use QuickSync
[13:23:52 CEST] <alevinsn> that's what actually provides the hardware encoding or decoding
[13:23:53 CEST] <nevcairiel> its the same hardware, so why?
[13:24:04 CEST] <alevinsn> DXVA2 doesn't provide any codecs
[13:24:06 CEST] <J_Darnley> More generally: I was looking at adding checkasm tests for the simple_idct code I wrote but I see there is already a test in 8x8dct. Does this test predate the creation of checkasm?
[13:24:07 CEST] <nevcairiel> if you can use dxva2 decoding and qsv encoding
[13:24:16 CEST] <nevcairiel> without system memory round-trips
[13:24:21 CEST] <nevcairiel> why have qsv decoding?
[13:24:31 CEST] <alevinsn> there is no such thing as dxva2 decoding
[13:24:37 CEST] <nevcairiel> of course there is
[13:24:39 CEST] <nevcairiel> i use it e very day
[13:25:23 CEST] <alevinsn> ok, I see that
[13:25:30 CEST] <alevinsn> it doesn't appear to be using QuickSync
[13:25:31 CEST] <alevinsn> though
[13:25:57 CEST] <nevcairiel> no, it uses dxva2, thats the entire point =p
[13:26:11 CEST] <alevinsn> yes, but there is good reason to use QuickSync
[13:26:17 CEST] <nevcairiel> which is?
[13:26:17 CEST] <alevinsn> if the hardware supports it
[13:26:28 CEST] <nevcairiel> dxva2 accesses the same decoder hardware
[13:26:30 CEST] <alevinsn> possibly better quality encoding, more flexibility
[13:26:39 CEST] <nevcairiel> we're talking about decoding
[13:26:45 CEST] <nevcairiel> decoding with dxva2 -> encoding with qsv
[13:26:54 CEST] <alevinsn> there are different knobs that can be controlled
[13:26:56 CEST] <nevcairiel> dxva2 doesnt have encoding support
[13:27:37 CEST] <alevinsn> plus, can use pipelines in theory with QSV
[13:27:44 CEST] <alevinsn> decode then VPP
[13:27:49 CEST] <alevinsn> all in hardware memory
[13:27:55 CEST] <alevinsn> which in theory should be faster
[13:28:14 CEST] <nevcairiel> you can do that with a dxva2 decoder, as we established, qsv just outputs dxva2 surfaces anyway
[13:29:04 CEST] <alevinsn> true, but need to setup the entire session to use QSV if you want to use VPP too in the most efficient way possible
[13:29:27 CEST] <alevinsn> if it is setup properly, could be using VPP on one frame while performing decoding with another
[13:29:37 CEST] <alevinsn> don't think you can get that kind of setup if you use DXVA2
[13:29:44 CEST] <nevcairiel> why not?
[13:29:57 CEST] <BtbN> why wouldn't you? Except for ffmpeg.c not supporting that kind of parallelism.
[13:30:08 CEST] <nevcairiel> sounds pretty normal, decode frame A, process frame B, encode frame C
[13:30:11 CEST] <nevcairiel> sounds perfectly normal
[13:30:42 CEST] <nevcairiel> (for more logical outcome, probably invert the letters :p)
[13:31:07 CEST] <alevinsn> ok, here's a good reason to use qsv--it will work cross-platform, since it will do the right thing for either Windows (DXVA2) or Linux (VAAPI)
[13:31:13 CEST] <alevinsn> qsv for decoding
[13:31:28 CEST] <BtbN> If you want to go through the pains of getting QSV to work on Linux, sure
[13:31:58 CEST] <nevcairiel> thats not really a good argument, ffmpeg could just have a magic switch that does the right thing
[13:32:48 CEST] <nevcairiel> ie. specify -hwaccel qsv and it uses dxva2 on windows and vaapi on linux
[13:32:49 CEST] <nevcairiel> or whatever
[13:32:54 CEST] <jkqxz> alevinsn: Patch looks ok. Commit message is a bit funny. Maybe "hwcontext_dxva2: Don't incorrectly free IDirect3DSurface9 objects", and please write in the present like all other commit messages.
[13:33:34 CEST] <jkqxz> Yeah, I'm intending to replace -hwaccel qsv with "magically do the right thing and then map back to qsv pixfmt".
[13:34:01 CEST] <alevinsn> that's in reference to decoding, right?
[13:34:22 CEST] <jkqxz> Though really you don't want the qsv pixfmt except in the last step, it's just that the VPP stuff exists and equivalent D3D implementation currently doesn't.
[13:34:30 CEST] <jkqxz> Yes, for decoding.
[13:34:48 CEST] <alevinsn> jkqxz: OK, I'll adjust the text to do everything in the present
[13:34:49 CEST] <jkqxz> Getting rid of the QSV decoder entirely is the end goal, though probably legacy people will force it to persist forever.
[13:35:19 CEST] <alevinsn> jkqxz: I would think that there are some knobs that can only be controlled with QSV decoding
[13:35:38 CEST] <jkqxz> Like what? Decoding has one answer, so there isn't anything you can do differently.
[13:35:40 CEST] <nevcairiel> decoding doesnt have many knobs
[13:35:54 CEST] <nevcairiel> you can control performance a bit by messing with the async thing
[13:36:04 CEST] <nevcairiel> but thats not very relevant
[13:36:56 CEST] <jkqxz> The async thing is trivially implementable by the user delaying frames, anyway. It could maybe have an option in lavc so that it can be used with all hardware decoders.
[13:37:07 CEST] <jkqxz> ... in the command line tools.
[13:37:31 CEST] <nevcairiel> .. and if any and every usecase of the qsv decoder can be easily replicated with dxva2+map, we can just deprecate it and remove it after due time
[13:38:16 CEST] <jkqxz> Anyway, the biggest gain of using dxva2/vaapi + hwmap is that it uses the proper decoder, so you don't have to specify the codec in advance and you get proper software fallback and full support of every feature you would expect normally without it having to be separately implemented in the special qsv decoder.
[13:39:17 CEST] <alevinsn> what about HEVC?
[13:39:24 CEST] <alevinsn> there are a bunch of different QSV plugins
[13:39:27 CEST] <alevinsn> for HEVC
[13:39:38 CEST] <nevcairiel> dxva2 implements full hevc decoding on intel
[13:39:44 CEST] <nevcairiel> not sure how well vaapi works
[13:39:52 CEST] <jkqxz> What about it? DXVA2 and VAAPI give you H.265 support directly without having to mess around with plugins.
[13:39:54 CEST] <alevinsn> there are a bunch of different HEVC plug-ins for QSV from Intel
[13:40:04 CEST] <alevinsn> there is reason to use different plugins
[13:40:09 CEST] <alevinsn> there is the Skylake HW plugin
[13:40:19 CEST] <alevinsn> but there are also hybrid software/hardware plugins
[13:40:30 CEST] <alevinsn> that are availablbe as part of the Intel Media Server Studio
[13:40:33 CEST] <BtbN> why would you use the worse ones?
[13:40:37 CEST] <alevinsn> that apparently result in better quality
[13:40:42 CEST] <alevinsn> than the HW plugin
[13:40:45 CEST] <BtbN> it's a decoder.
[13:40:52 CEST] <alevinsn> may not matter for the decoder
[13:40:54 CEST] <jkqxz> "better quality" is not a thing for a decoder. There is one right answer. If you don't get that, it's wrong.
[13:40:55 CEST] <alevinsn> not sure
[13:43:16 CEST] <jkqxz> (Certainly it makes sense to support the different encode plugins, but there is no intent here to change anything about the encoder.)
[13:44:28 CEST] <nevcairiel> dxva2 at least supports the hybrid decoding
[13:44:33 CEST] <nevcairiel> not sure about vaapi, probably not
[13:44:38 CEST] <alevinsn> to me, it seems a little bit odd to use one path for decoding and another for encoding--are you wanting qsvdec.c and related qsv files to disappear?
[13:44:48 CEST] <nevcairiel> (hybrid is only used when no full hw support is available)
[13:45:36 CEST] <alevinsn> nevcairiel: not true (for encoding)--there is reason to use hybrid for HEVC even if hardware support available because the HEVC hardware encoder in Skylake isn't very good
[13:45:49 CEST] <alevinsn> at least, that's what the person from Intel told me
[13:46:04 CEST] <nevcairiel> we've been only talking about decoding here
[13:46:18 CEST] <nevcairiel> encoding remains with qsvenc at all times anyway
[13:46:26 CEST] <jkqxz> Media SDK VAAPI doesn't have hybrid, there is a separate project for the free stuff which kindof works.
[13:47:31 CEST] <BtbN> the hybrid stuff is terrible anyway
[13:47:32 CEST] <jkqxz> alevinsn: Yes, I would like to delete qsvdec.c. Most of the other qsv stuff in lavc stays because it is used by the encoder.
[13:47:37 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:3fefaeaa0b85: img2dec: use standard way to probe for svg/svgz files
[13:48:43 CEST] <alevinsn> so, if programmatically setting up decoding and want to use QSV for decoding
[13:48:46 CEST] <alevinsn> how would you do that?
[13:49:56 CEST] <alevinsn> assuming qsvdec.c were removed
[13:50:06 CEST] <jkqxz> Use DXVA2 or VAAPI and point it at your Intel device.
[13:50:32 CEST] <alevinsn> then you don't have a cross-platform solution anymore
[13:51:08 CEST] <jkqxz> You need to specify the QSV device anyway in different ways on the two platforms, and after that the only difference is the pixfmt.
[13:51:39 CEST] <alevinsn> won't "auto" do the right thing regardless of the platform?
[13:52:52 CEST] <jkqxz> Not if you have a non-Intel graphics device as well.
[13:53:40 CEST] <alevinsn> are you talking about the third argument to av_hwdevice_ctx_create()?
[13:53:59 CEST] <alevinsn> the value of which is different depending on DXVA2 or VAAPI?
[13:54:11 CEST] <alevinsn> for the child device in hwcontext_qsv.c
[13:54:38 CEST] <jkqxz> In this setup you use device derivation to make the QSV device, so that never gets run.
[13:55:42 CEST] <alevinsn> ok, not exactly following, but that's okay
[13:56:13 CEST] <jkqxz> You start by making the VAAPI / DVXA2 device. (See command line examples in <https://lists.libav.org/pipermail/libav-devel/2017-April/083488.html> or <https://lists.libav.org/pipermail/libav-devel/2017-April/083487.html>.)
[13:56:27 CEST] <alevinsn> regarding the commit message, I'm not sure how to make some of the things make sense if stated in the present
[13:56:55 CEST] <BBB> atomnuker: any reason why? I have no opinion on the patch basically
[13:57:39 CEST] <jkqxz> I mean the changes you make should be happening in the present.
[13:58:22 CEST] <alevinsn> "Add dxva2_pool_release_dummy() and use it in call to av_buffer_create() in dxva2_pool_alloc()."
[13:58:32 CEST] <jkqxz> Yes, precisely.
[13:58:36 CEST] <alevinsn> It sounds odd to me, but I think that's what you are looking for, right?
[13:58:48 CEST] <alevinsn> because it hasn't happened yet (in a sense)
[13:59:04 CEST] <alevinsn> the rest of the text referred to what currently exists--was that written in the right tense?
[13:59:12 CEST] <jkqxz> Yes, that's fine.
[13:59:21 CEST] <alevinsn> ok, I think I have it, I'll resubmit
[13:59:26 CEST] <jkqxz> You don't need to repeat the subject line inside the patch, either.
[14:00:15 CEST] <atomnuker> BBB: I too dislike seeing .loops in perf printouts
[14:00:15 CEST] <jkqxz> So subject "hwcontext_dxva2: Don't incorrectly free IDirect3DSurface9 objects", commit message "Add dxva2_pool_release_dummy() and use it in call to av_buffer_create() in dxva2_pool_alloc().\n\n[Explanation for why that is the right thing to do]".
[14:00:23 CEST] <alevinsn> I usually try to flesh out the subject line in a little more detail, although in this case, I didn't really do that
[14:00:55 CEST] <BBB> atomnuker: aha, I see& ok, understood
[14:05:29 CEST] <alevinsn> jkqxz: ok, new version that is hopefully the last version just sent
[14:05:58 CEST] <alevinsn> nevcairiel: and it has not just one, but two new lines separating the text :-)
[14:12:12 CEST] <jkqxz> alevinsn: LGTM. I can push it later today when I'm next to a machine with keys, assuming nevcairiel doesn't want to say anything else.
[14:12:50 CEST] <alevinsn> thanks, and good night, going to get a few hours of sleep and then back at it....
[14:17:35 CEST] <jkqxz> You're in UTC-7? Good morning :P
[14:52:14 CEST] <saulotoledo> Hello all :D I need some help with MPEG2 Transport Stream. Is there somebody here that can help me? I want to understand how the TS works, and I do not know where I can get some help about. I do not understand how the descriptors are transferred inside the PMT table. Can somebody help me? If this is off-topic, please send me a PM. Thanks in advance.
[16:26:48 CEST] <cone-630> ffmpeg 03Matt Wolenetz 07release/3.1:0abc88f0fdb8: lavf/mov.c: Avoid OOB in mov_read_udta_string()
[16:26:49 CEST] <cone-630> ffmpeg 03Matt Wolenetz 07release/3.1:5cd2fcd0a723: lavf/mov.c: Avoid heap allocation wraps in mov_read_{senc,saiz}()
[16:26:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:3364c8c53a4b: avformat/http: Check for truncated buffers in http_connect()
[16:26:51 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a6b5e670f49e: avcodec/wavpacl: Fix runtime error: left shift of negative value -1
[16:26:52 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eb322e44eaa2: avcodec/mpeg12dec: Fix runtime error: left shift of negative value
[16:26:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:654942045137: avcodec/pngdec: Check bit depth for validity
[16:26:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ad2f9874b5cc: avcodec/srtdec: Fix signed integer overflow: 1811992524 * 384 cannot be represented in type 'int'
[16:26:55 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:5fcb98f34f5a: avcodec/pictordec: Do not read more than nb_planes
[16:26:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:aa5e396d42f9: avcodec/rv34: Simplify and factor get_slice_offset() code
[16:26:57 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:751f3f4f5ab1: avcodec/mpegaudiodec_template: Correct return code on id3 tag discarding
[16:26:58 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:c0b9d223902a: avcodec/vp56: Fix sign typo
[16:26:59 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eee75451e117: avcodec/pngdec: Fix runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
[16:27:00 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:fccbd911fb09: avcodec/amrwbdec: Fix 2 runtime errors: left shift of negative value -1
[16:27:01 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eca3cfe9c4bd: avcodec/vp56: Implement very basic error concealment
[16:27:02 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b541a79c99b8: avcodec/vp56: Clear dimensions in case of failure in the middle of a resolution change
[16:27:03 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:38c7a1ef5cb0: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -1
[16:27:04 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2015c109ac93: Add CHECK/SUINT code
[16:27:05 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:aff4b91b8df0: avcodec/vp3dsp: Fix multiple signed integer overflow: 46341 * 47523 cannot be represented in type 'int'
[16:27:06 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0db93a9d403d: avcodec/vp56: Factorize vp56_render_mb() out
[16:27:07 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e587594741c8: avcodec/vp8: Check for bitsteam end in decode_mb_row_no_filter()
[16:27:08 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a7e924324e7c: avcodec/vp3: Do not return random positive values but the buf size
[16:27:09 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:17444379696d: avcodec/vp56: Require a correctly decoded frame before using vp56_conceal_mb()
[16:27:10 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b6cbbd22739c: avcodec/vp8: remove redundant check
[16:27:11 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:7ba15a631501: avcodec/vp568: Check that there is enough data for ff_vp56_init_range_decoder()
[16:27:12 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e365921419e1: avcodec/vp8: Check for the bitstream end per MB in decode_mb_row_no_filter()
[16:27:13 CEST] <cone-630> ffmpeg 03Thomas Guilbert 07release/3.1:4c66ead5b7a8: avcodec/vp8: Fix hang with slice threads
[16:27:14 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b8814515c63f: avcodec/vp56: Reset have_undamaged_frame on resolution changes
[16:27:15 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8c36b7ab360d: avcodec/vp6: clear dimensions on failed resolution change in vp6_parse_header()
[16:27:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:77ffc7596cb7: avcodec/htmlsubtitles: Fix reading one byte beyond the array
[16:27:17 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e82cddfd05ac: avcodec/eac3dec: Fix runtime error: left shift of negative value
[16:27:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f03df423ab02: avcodec/mjpegdec: Fix runtime error: left shift of negative value -507
[16:27:19 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:535c1411d746: avcodec/mpeg4videodec: Fix runtime error: shift exponent -2 is negative
[16:27:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:11c2a96c2306: avcodec/h264_cabac: runtime error: signed integer overflow: 2147483647 + 14 cannot be represented in type 'int'
[16:27:21 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d837140eb4e0: avcodec/rv40: Fix runtime error: left shift of negative value
[16:27:22 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f0f4b66dff89: avcodec/ituh263dec: Fix runtime error: left shift of negative value -22
[16:27:23 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cae07dd27fc6: avcodec/mpeg4video: Fix runtime error: left shift of negative value
[16:27:24 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0df55b0ffc2e: avcodec/mpeg4videodec: Check sprite_offset in addition to shifts
[16:27:25 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:72d01d4c14f7: avcodec/mpeg4videodec: Check the other 3 sprite points for intermediate overflows
[16:27:26 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b8883af656eb: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -2
[16:27:27 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:fc5b7e109217: avcodec/eac3dec: Fix runtime error: left shift of negative value -3
[16:27:28 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0456e2f3e050: avcodec/mpeg4videodec: Fix runtime error: left shift of negative value -2650
[16:27:29 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a0366ef7e74f: avcodec/pictordec: Check plane value before doing value/mask computations
[16:27:30 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a72b17ca403d: avcodec/h264_direct: Fix runtime error: left shift of negative value -14
[16:27:31 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cd09ad190f03: avcodec/mjpegdec: Fix runtime error: left shift of negative value -511
[16:27:32 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e34feaf93e9f: avcodec/mpeg4videodec: Improve the overflow checks in mpeg4_decode_sprite_trajectory()
[16:27:33 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b69f97933126: avcodec/adxdec: Fix runtime error: left shift of negative value -1
[16:27:34 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:67d84d2c48a6: avcodec/h264_mvpred: Fix multiple runtime error: left shift of negative value
[16:27:35 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ce54743d8280: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -13
[16:27:36 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:49697df49c72: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 134527392 * 16 cannot be represented in type 'int'
[16:27:37 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e92e587ceeb0: avcodec/wavpack: Fix runtime error: left shift of negative value -2
[16:27:38 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9beb60855beb: avcodec/wavpack: Fix runtime error: left shift of negative value -5
[16:27:39 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:90c408fa65f3: avcodec/mjpegdec: Fix runtime error: left shift of negative value -127
[16:27:40 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f487f9bfdfa7: avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1
[16:27:41 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d9e54c335d56: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int'
[16:27:42 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:92d6b2b9342d: avcodec/amrwbdec: Fix runtime error: left shift of negative value -1
[16:27:43 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:025dc25ecbf1: avcodec/rv34: Fix runtime error: signed integer overflow: 36880 * 66288 cannot be represented in type 'int'
[16:27:44 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:bafec54a9328: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[16:27:45 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:139a5390623b: avcodec/tiff: Check for multiple geo key directories
[16:27:46 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f4b8e7f2c692: avcodec/mpegaudiodec_template: Make l3_unscale() work with e=0
[16:27:47 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:91f821ed5d55: avcodec/tiff: Check stripsize strippos for overflow
[16:27:48 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:184d957b5401: avcodec/vp56: Check avctx->error_concealment before enabling EC
[16:27:49 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8fc7fd63f21f: avcodec/tiff: Check geotag count for being non zero
[16:27:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:840d5bf994d9: avcodec/h264_ps: Fix runtime error: signed integer overflow: 2147483647 + 26 cannot be represented in type 'int'
[16:27:51 CEST] <cone-630> ffmpeg 03Philip Langdale 07release/3.1:987675ba0d94: avcodec/vdpau_hevc: Fix potential out-of-bounds write
[16:27:52 CEST] <cone-630> ffmpeg 03Timothy Gu 07release/3.1:6522a5dcf09f: omx: Fix OOM check
[16:27:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d4aea81f2cce: avcodec/tiff: Perform multiply in tiff_unpack_lzma() as 64bit
[16:27:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8c54c2934371: avfilter/avfiltergraph: Add assert to write down in machine readable form what is assumed about sample rates in swap_samplerates_on_filter()
[16:27:55 CEST] <cone-630> ffmpeg 03wm4 07release/3.1:2f8356df12af: avcodec: fix uninitialized variable read
[16:27:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e80a525934ab: avfilter/af_sofalizer: Fix bad shift
[16:27:57 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:dc4fc2520072: avformat/oggparsedaala: Check duration for AV_NOPTS_VALUE
[16:27:58 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0a966b056fd6: avformat/oggparsedaala: Do not leave an invalid value in gpshift
[16:27:59 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:da25519aff84: avcodec/dvdsubdec: Fixes 2 runtime error: left shift of 170 by 24 places cannot be represented in type 'int'
[16:28:00 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:500212310944: avformat/oggparseogm: Check available data before reading global header
[16:28:01 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a46e0879b9ac: avformat/oggparseogm: Check ff_alloc_extradata() for failure
[16:28:02 CEST] <cone-630> ffmpeg 03Derek Buitenhuis 07release/3.1:a1d740ff098e: avformat/webmdashenc: Require the 'adaptation_sets' option to be set
[16:28:03 CEST] <cone-630> ffmpeg 03Derek Buitenhuis 07release/3.1:82e5f2c76b6f: avformat/webmdashenc: Validate the 'streams' adaptation sets parameter
[16:28:04 CEST] <cone-630> ffmpeg 03Martin Vignali 07release/3.1:b391e4c8f4fe: libavcodec/exr : fix float to uint16 conversion for negative float value
[16:28:05 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:52d07518a32d: avcodec/x86/vc1dsp_init: Fix build failure with --disable-optimizations and clang
[16:28:06 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:388ef988f8ff: avcodec/mdec: Fix runtime error: left shift of negative value -127
[16:28:07 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f3d300497fc7: doc/developer: Add terse documentation of assumed C implementation defined behavior
[16:28:08 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2b733acce9e0: avcodec/vp3: Check remaining bits in unpack_dct_coeffs()
[16:28:09 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:132796f1d15f: avcodec/indeo2: Check remaining bits in ir2_decode_plane()
[16:28:10 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:44fd56337616: avcodec/svq3: Increase offsets to prevent integer overflows
[16:28:11 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2cfd230759e7: avcodec/svq3: Reject dx/dy beyond 16bit
[16:28:12 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cfc85cead9e9: avcodec/dcadsp: Fix runtime error: signed integer overflow
[16:28:13 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6798f9c551b4: avcodec/h264_cavlc: Fix undefined behavior on qscale overflow
[16:28:14 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d4f008557ae7: avcodec/msvideo1: Check buffer size before re-getting the frame
[16:28:15 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:55d8fd38d66e: avcodec/pngdec: Use ff_set_dimensions()
[16:28:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cbc471d1b323: libavcodec/mpeg4videodec: Convert sprite_offset to 64bit
[16:28:17 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cc9b7db429f1: avcodec/dvdsubdec: Fix runtime error: left shift of 242 by 24 places cannot be represented in type 'int'
[16:28:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a6fb07d5ba3a: avcodec/cavsdec: Fix undefined behavior from integer overflow
[16:28:19 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ac74ac9e1d2f: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'
[16:28:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:67561969947e: avcodec/tiertexseqv: set the fixed dimenasions, do not depend on the demuxer doing so
[16:28:21 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0eb229a427cd: avcodec/wnv1: Fix runtime error: left shift of negative value -1
[16:28:22 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ba0081fbbe9c: avcodec/dss_sp: Fix multiple left shift of negative value -466
[16:28:23 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:45470150971a: avcodec/g722: Fix multiple runtime error: left shift of negative value -1
[16:28:24 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:dd907bec361e: avcodec/cdxl: Fix signed integer overflow: 14243456 * 164 cannot be represented in type 'int'
[16:28:25 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e01f02894931: avcodec/nellymoser: Fix multiple left shift of negative value -8591
[16:28:26 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eb234fa89b94: avcodec/dfa: Fix off by 1 error
[16:28:27 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:092449179955: avcodec/mdec: Fix signed integer overflow: 28835400 * 83 cannot be represented in type 'int'
[16:28:28 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:fb4a81dc3aa3: avcodec/aacsbr_template: Do not leave bs_num_env invalid
[16:28:29 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1fe0de8934cd: avutil/softfloat: Fix multiple runtime error: left shift of negative value -8
[16:28:30 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e7755214bbf9: avcodec/snowdec: Check qbias
[16:28:31 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:23a76f1057bd: avcodec/mlpdec: Fix runtime error: left shift of negative value -22
[16:28:32 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ceb456e3e9e9: avcodec/fic: Fix multiple left shift of negative value -15
[16:28:33 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9f7bc8296bdd: avcodec/mimic: Fix runtime error: left shift of negative value -1
[16:28:34 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:677c9f27cc60: avcodec/g723_1: Fix multiple runtime error: left shift of negative value
[16:28:35 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2c7e4e5e7176: avcodec/dfa: Fix signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
[16:28:36 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:5578f63494aa: avcodec/webp: Fix null pointer dereference
[16:28:37 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:22de9c949aba: avcodec/shorten: Check k in get_uint()
[16:28:38 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cbd8be63cf34: avcodec/mss3: Change types in rac_get_model_sym() to match the types they are initialized from
[16:28:39 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:78b47e922961: avcodec/hq_hqa: Fix runtime error: left shift of negative value -207
[16:28:40 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:54eaa109ed8b: avutil/softfloat: Fix overflow in av_div_sf()
[16:28:41 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:94029d7e179e: avcodec/cdxl: Check format parameter
[16:28:42 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:47e2c70dcdbe: avcodec/dds: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[16:28:43 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8464f2508925: avcodec/msmpeg4dec: Correct table depth
[16:28:44 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ef40a32dbb0e: avcodec/svq3: Fix multiple runtime error: signed integer overflow: 44161 * 61694 cannot be represented in type 'int'
[16:28:45 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d9faa9bd6366: avcodec/ivi_dsp: Fix multiple left shift of negative value -2
[16:28:46 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b892a0b1c078: avcodec/texturedsp: Fix multiple runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[16:28:47 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:23853514e5af: avcodec/targa_y216dec: Fix width type
[16:28:48 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a11e5577a253: avcodec/mss34dsp: Fix multiple signed integer overflow
[16:28:49 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b0f57bd32697: avcodec/ra144: Fix runtime error: left shift of negative value -798
[16:28:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:93f9d9dc6c3d: avcodec/g726: Fix runtime error: left shift of negative value -2
[16:28:51 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:aab7b9e6bcf9: avcodec/eamad: Fix runtime error: signed integer overflow: 49674 * 49858 cannot be represented in type 'int'
[16:28:52 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:71a568e47d04: avcodec/s302m: Fix left shift of 8 by 28 places cannot be represented in type 'int'
[16:28:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e2103ad36d45: avcodec/xwddec: Check bpp more completely
[16:28:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:be531b476236: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -12156865 cannot be represented in type 'int'
[16:28:55 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:782473f9dfca: avcodec/ffv1dec: Fix copying planes of paletted formats
[16:28:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4f98b97b2ad1: avcodec/cdxl: Check format for BGR24
[16:28:57 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:7e5ece105227: avcodec/cavsdec: Check sym_factor
[16:28:58 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:45763713e81a: avcodec/hqxdsp: Fix multiple runtime error: signed integer overflow: 248220 * 21407 cannot be represented in type 'int' in idct_col()
[16:28:59 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:34a7677f296e: avcodec/vp8dsp: Fixes: runtime error: signed integer overflow: 1330143360 - -1023040530 cannot be represented in type 'int'
[16:29:00 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e3368b7f8217: avcodec/dvbsubdec: check region dimensions
[16:29:01 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d766376f4b53: avcodec/dss_sp: Fix multiple runtime error: signed integer overflow: -15699 * -164039 cannot be represented in type 'int'
[16:29:02 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ddef5acc3156: avcodec/bmvvideo: Fix runtime error: left shift of 137 by 24 places cannot be represented in type 'int'
[16:29:03 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d48a152b7cd8: avcodec/htmlsubtitles: Check for string truncation and return error
[16:29:04 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e82d6dafdef6: avcodec/g723_1dec: Fix several integer related cases of undefined behaviour
[16:29:05 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:99341b2a7fd1: avcodec/indeo2: Check for invalid VLCs
[16:29:06 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1e52bd434498: avcodec/takdec: Fix multiple runtime error: left shift of negative value -1
[16:29:07 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1ddb2441d6bf: avcodec/lagarith: Fix runtime error: left shift of negative value -1
[16:29:08 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9b14178421c7: avcodec/lagarith: Check scale_factor
[16:29:09 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:22f9831d0db1: avcodec/texturedsp: Fix runtime error: left shift of 218 by 24 places cannot be represented in type 'int'
[16:29:10 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9bc7868bc916: avcodec/svq3: Fix multiple runtime error: signed integer overflow: -237341 * 24552 cannot be represented in type 'int'
[16:29:11 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:24d048f3e6bf: avcodec/y41pdec: Fix width in input buffer size check
[16:29:12 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4170c380247f: avcodec/cavs: Check updated MV
[16:29:13 CEST] <cone-630> ffmpeg 03N^ 07release/3.1:9f3267def692: avformat/wavdec: Check chunk_size
[16:29:14 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:159e5ba8d79a: avcodec/dss_sp: Fix runtime error: signed integer overflow: 2147481189 + 4096 cannot be represented in type 'int'
[16:29:15 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e4def6e0b608: avcodec/eatqi: Fix runtime error: signed integer overflow: 4466147 * 1075 cannot be represented in type 'int'
[16:29:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:41392c52499a: avcodec/truemotion1: Fix multiple runtime error: left shift of negative value -1
[16:29:17 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8ec17629d72d: avfilter/vf_uspp: Fix currently unused input frame dimensions
[16:29:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:21b1dd8f74c9: avcodec/webp: Always set pix_fmt
[16:29:19 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:7edd1cd6fa9f: avcodec/mpeg12dec: Fixes runtime error: division by zero
[16:29:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:79c489952a8c: avcodec/aacdec_fixed: Fix multiple shift exponent 33 is too large for 32-bit type 'int'
[16:29:21 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e9b0d127b0da: avcodec/dvbsubdec: Check entry_id
[16:29:22 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:becd83e164db: avcodec/cllc: Factor VLC_BITS/DEPTH out, do not use repeated literal numbers
[16:29:23 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:5e23b4a8396e: avcodec/cllc: Check num_bits
[16:29:24 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1147b109b7e0: avcodec/msmpeg4dec: Check for cbpy VLC errors
[16:29:25 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4476107e3acb: avcodec/diracdec: Fix Assertion frame->buf[0] failed at libavcodec/decode.c:610
[16:29:26 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9f0f354a97bf: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -17047030 cannot be represented in type 'int'
[16:29:27 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:bf7bcd803a5c: avcodec/g723_1dec: Fix runtime error: left shift of negative value -1
[16:29:28 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f224214ae24f: avcodec/texturedsp: Fix runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[16:29:29 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d5c3132d6fbd: avcodec/avcodec: Limit the number of side data elements per packet
[16:29:30 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e85a3a1d3e3d: avcodec/vp8dsp: vp7_luma_dc_wht_c: Fix multiple runtime error: signed integer overflow: -1366381240 + -1262413604 cannot be represented in type 'int'
[16:29:31 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f450115354ef: avcodec/mlp: Fix multiple runtime error: left shift of negative value -1
[16:29:32 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:84e272d4e23f: avcodec/aacsbr_template: Do not change bs_num_env before its checked
[16:29:33 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b6c8e4733330: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1
[16:29:34 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e5abfbf2abc1: avcodec/webp: Add missing input padding
[16:29:35 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b18a2cbdbf27: avcodec/ac3dec: Keep track of band structure
[16:29:36 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:536e29d4cf91: avcodec/mlpdec: Check that there is enough data for headers
[16:29:37 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d792783f5632: avcodec/svq3: Fix runtime error: signed integer overflow: 169 * 12717677 cannot be represented in type 'int'
[16:29:38 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6d2a00d0f113: avcodec/webp: Fix signedness in prefix_code check
[16:29:39 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:536275b673c0: avcodec/ffv1dec: Fix runtime error: signed integer overflow: 1550964438 + 1550964438 cannot be represented in type 'int'
[16:29:40 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d5ac8a296a01: libswscale/tests/swscale: Fix uninitialized variables
[16:29:41 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:993671b570f3: avcodec/g723_1dec: Fix LCG type
[16:29:42 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d8082e5e6cdf: avcodec/hqxdsp: Fix runtime error: signed integer overflow: -196264 * 11585 cannot be represented in type 'int'
[16:29:43 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:c1aa23caae2c: avcodec/ac3dec: Fix: runtime error: index -1 out of bounds for type 'INTFLOAT [2]'
[16:29:44 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0d3efe30b5ff: avcodec/mpeg4videodec: Clear sprite wraping on unsupported cases in VOP decode
[16:29:45 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e964d47439d5: avcodec/dds: Fix runtime error: left shift of 210 by 24 places cannot be represented in type 'int'
[16:29:46 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:528fb0b27d70: avcodec/rscc: Check pixel_size for overflow
[16:29:47 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1cdc9447f423: avcodec/cllc: Check prefix
[16:29:48 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6f4e69d661e0: avcodec/webp: Factor update_canvas_size() out
[16:29:49 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4e5543571a10: avcodec/webp: Update canvas size in vp8_lossy_decode_frame() as in vp8_lossless_decode_frame()
[16:29:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1e5d151417a6: avcodec/snowdec: Check width
[16:29:51 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6fa860449f36: avcodec/flacdec: Return error code instead of 0 for failures
[16:29:52 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:70cda595c3f3: avcodec/opus_silk: Fix integer overflow and out of array read
[16:29:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0159afe0c2f1: avcodec/aacps: Fix undefined behavior
[16:29:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b25aca2af8e4: avcodec/tiff: reset sampling[] if its invalid
[16:29:55 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ab22fca14b38: avcodec/svq3: Fix runtime error: left shift of negative value -6
[16:29:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:54918674f7cb: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[16:36:18 CEST] <atomnuker> rcombs: are you going to push your flac patches?
[16:52:41 CEST] <wm4> so do we want to apply this libturing patch or not?
[16:55:24 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:7f2eeb2c7478: avformat/concatdec: fix the h264 annexb extradata check
[16:55:25 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:d2c6bcdbf181: avcodec/options: factorize avcodec_copy_context() cleanup code
[16:55:26 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:1564125e4eb1: avcodec/options: do a more thorough clean up in avcodec_copy_context()
[16:55:27 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.1:9ebbb29ad61d: avformat/utils: free AVStream.codec properly in free_stream()
[16:55:28 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:75f9fe1519de: avcodec/aac_adtstoasc: fix ASC passthrough on small frames
[16:56:58 CEST] <jamrial> wm4: not as is, unless they can prove it's better than libx265. the order in allcodecs.c as it is in the latest patch would make it the default encoder
[16:57:49 CEST] <wm4> hm does that even matter, since you have to explicitly enable those anyway
[16:59:11 CEST] <cone-630> ffmpeg 03James Almer 07release/3.2:d4241affd8e8: avcodec/aac_adtstoasc: fix ASC passthrough on small frames
[16:59:37 CEST] <jamrial> it does, there's a section in that file for external libraries that have less priority than others
[17:02:26 CEST] <J_Darnley> BBB: in the simple_idct C function, in the idctRowCondDC inline function, there is some stange code which I think checks for zeros. Is this some early termination for DC-only coeffs?
[17:03:05 CEST] <BBB> let me have a look
[17:04:00 CEST] <BBB> oh that
[17:04:05 CEST] <BBB> sort of
[17:04:13 CEST] <BBB> so, the dc only case is a very special one
[17:04:16 CEST] <BBB> this is a more generic one
[17:05:20 CEST] <BBB> but this basically checks that within the 1d of this lane only, all non-first coefs are zero, yes
[17:05:50 CEST] <J_Darnley> Ah, I guess DC-only is not strictly correct.
[17:05:52 CEST] <BBB> similarly, if (AV_RN64A(row + 4)) { checks whether the second half of the coefs have any non-zeroes
[17:06:00 CEST] <BBB> DC is the first coef of the first lane
[17:06:04 CEST] <J_Darnley> DC would be the top-left coeff only
[17:06:05 CEST] <BBB> but it does it for every lane
[17:06:08 CEST] <BBB> right
[17:06:09 CEST] <BBB> exactly
[17:06:35 CEST] <J_Darnley> thank you
[17:08:55 CEST] <BBB> its similar to the sub-idct mechanism in vp9s x86 simd code, except thats at 2d level and this is at 1d level
[17:13:15 CEST] <wm4> jamrial: then someone should post that
[17:13:56 CEST] <jkqxz> The problem with the libturing patch is that no developers are interested so noone wants any responsibility for it (I mean, it looks like an internal project wall-throw with no external use or involvement at all).
[17:14:30 CEST] <jkqxz> The lack of proper API also doesn't help, because it encourages comments which don't actually make any forward progress.
[17:15:58 CEST] <wm4> well, with all that patch review, there's somewhat of an implicit promise that we'd merge it
[17:34:09 CEST] <jkqxz> Yeah, it should probably just be merged.
[17:35:32 CEST] <jkqxz> (If it hangs there I'm sure people can come up with objections indefinitely.)
[17:36:00 CEST] <nevcairiel> if its setup in such a way that its never the default or preferred over x265, then merging it probably doesnt hurt anyone
[17:36:43 CEST] <jkqxz> It's sufficiently hard to build that I doubt anyone would be confused anyway.
[17:37:25 CEST] <jkqxz> Well, maybe "enable all the things" people will get it.
[17:48:36 CEST] <jamrial> jkqxz: exactly, builds like zeranoe's or some linux distros that ship a single binary with all the deps hardcoded must not find themselves with the hevc encoder default changed
[18:05:32 CEST] <jkqxz> At least if Linux distributions pick it up then they probably have to fix the internal boost library stuff to work properly.
[18:05:53 CEST] <jkqxz> But yes, that does need to be fixed.
[18:06:06 CEST] <nevcairiel> whoever pushes could just reorder the registration
[18:06:10 CEST] <jkqxz> Does anything else? Has anyone else even run the thing?
[18:06:48 CEST] <jkqxz> Yeah, avoiding another round trip just for that would be sensible.
[19:12:02 CEST] <cone-630> ffmpeg 03James Almer 07release/3.2:e958bfac8b9f: avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message
[19:18:13 CEST] <cone-630> ffmpeg 03Paul B Mahol 07master:5605108f4dca: avfilter/af_bs2b: add missing flag for options
[19:25:13 CEST] <alevinsn> No, I'm UTC-8.00
[19:25:30 CEST] <alevinsn> 8:00
[19:25:42 CEST] <alevinsn> It was 0500 when I went to sleep
[19:25:57 CEST] <alevinsn> nevcairiel: I thought some how to do the d3d9.h check
[19:26:14 CEST] <alevinsn> seems like the easiest thing is try to build some simple code that tries to use that interface method
[19:29:11 CEST] <wm4> that's how it's normally done
[19:34:02 CEST] <nevcairiel> we have checks for similar things already, iirc
[19:34:35 CEST] <PeterStream> Salutations all.
[19:35:29 CEST] <PeterStream> Does anyone know if there is a job board for ffmpeg-developers ( source developers ).
[19:36:23 CEST] <PeterStream> I'm looking to hire a consultant at the senior/architect level for a well funded/known company in the streaming industry.
[19:37:10 CEST] <alevinsn> nevcairiel: were you wanting to add that check to configure (and also make the appropriate changes to anywhere it is needed in the code base)?
[19:37:20 CEST] <alevinsn> you personally, I mean
[19:39:02 CEST] <alevinsn> because if not, I'm familiar enough with it that I can do it I think
[19:40:20 CEST] <alevinsn> PeterStream: I'm not aware of such a job board, but the FFmpeg Web site has a list of individuals at http://ffmpeg.org/consulting.html that you might find useful
[19:41:45 CEST] <PeterStream> alevinsn thank you! I will take a look.
[19:42:09 CEST] <PeterStream> It's a pretty cool gig and just looking for help with the nuances of ffmpeg.
[19:45:55 CEST] <cone-630> ffmpeg 03James Almer 07master:605c5ca3123a: avcodec/allcodecs: move librsvg_decoder to the external library section
[20:26:25 CEST] <thebombzen> what is "lgtm" mean
[20:27:45 CEST] <Gramner> "looks good to me"
[20:55:28 CEST] <tdjones> If I am to adapt the vorbis encoder to use the af buffer queue, is it necessary to store all frames within the primary encoder context? I'm not quite understanding how the 64-sample frames would be concatenated into one of the two frame sizes encoded in the file header
[20:56:22 CEST] <tdjones> Looking at the opus encoder doesn't quite fit since Vorbis only allows 1 frame per audio packet in the stream.
[20:56:59 CEST] <atomnuker> tdjones: ff_bufqueue_add(avctx, &s->bufqueue, av_frame_clone(frame));, that's all you need to do
[20:57:27 CEST] <atomnuker> then the frame is in the context's buffer queue and you can use it
[20:58:01 CEST] <atomnuker> (after you're finished with it you call av_frame_free() to free the frame
[21:00:22 CEST] <atomnuker> you can actually just copy opus_encode_frame() and use that as the main encoding function
[21:00:30 CEST] <atomnuker> just always assume you'll only have 1 packet
[21:00:51 CEST] <atomnuker> I mean 1 frame per packet
[21:02:17 CEST] <atomnuker> the simplest way to start would be to just make the encoder output the smallest frame size allowed since you'd need no buffer queue
[21:12:48 CEST] <tdjones> atomnuker: Thanks, I'll give that a try
[22:36:20 CEST] <J_Darnley> jamrial: regarding the pgp signed mails. I see what you were talking about. I seem unable to verify my own mail sent to the list recieved by another address.
[22:47:57 CEST] <cone-630> ffmpeg 03Aaron Levinson 07master:0c1c514643d5: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[22:49:14 CEST] <jkqxz> I'm still wtf at that bug not being world-breaking memory corruption, but apparently noone noticed for a year. Oh well.
[22:51:47 CEST] <J_Darnley> Nobody uses it?
[22:53:14 CEST] <alevinsn> perhaps should be backported to production?
[22:53:15 CEST] <alevinsn> 3.1?
[22:53:51 CEST] <jkqxz> Everyone using qsv on Windows, and the players would use it too in many cases (mpv at least). Not a small sample.
[22:54:05 CEST] <alevinsn> well, only if hw frame context used
[22:54:13 CEST] <alevinsn> if software memory used, not relevant
[22:54:40 CEST] <alevinsn> I'm not sure if there is a way to cause qsv encoding to use hw frame context via ffmpeg
[22:55:24 CEST] <jkqxz> ? Feed it any hardware frames on input. (Either from hwaccel on a decoder or from hwupload.)
[22:55:24 CEST] <alevinsn> I only encountered this because I wrote code to do that using the shared libraries
[22:56:03 CEST] <jkqxz> Um, yeah. That should probabaly be backported to release branches.
[22:56:14 CEST] <alevinsn> if software memory is used for, the hw frame context object (the one declared in hwcontext_qsv.c) is not created, and it won't be used in that case
[22:56:43 CEST] <alevinsn> but, maybe relevant for the hw frame context created by qsv.c? not sure
[22:57:25 CEST] <alevinsn> the reason it might not have impacted things
[22:57:31 CEST] <jkqxz> hwupload and hwmap can also make new hw frames contexts in your filter chain.
[22:57:42 CEST] <alevinsn> is that, if any memory corruption occurs, it happens at cleanup, when the process is likely exiting anyway
[22:58:25 CEST] <alevinsn> and, release version of _aligned_free may not overwrite memory
[22:58:35 CEST] <jkqxz> mpv not dying is the more surprising case to me, since that definitely does reinitialise things in the same process repeatedly.
[22:59:01 CEST] <alevinsn> may be smart enough to realize those weren't allocated from the heap and it does nothing?
[22:59:19 CEST] <alevinsn> I find that hard to believe, but it might be possible
[22:59:35 CEST] <alevinsn> I imagine that libav will want this one
[22:59:48 CEST] <jkqxz> Yeah. Do you want to send it there?
[23:00:45 CEST] <alevinsn> I guess they don't have a merge process setup
[23:01:54 CEST] <alevinsn> I got lucky in finding it--if I hadn't build with MDd, I wouldn't have noticed it
[23:02:10 CEST] <alevinsn> and I built ffmpeg that way to figure out the cause of a large memory leak that MSVC was reporting
[23:02:37 CEST] <alevinsn> I think the memory leak might have been caused by the spurious frees
[23:03:04 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.3:19fea7d703b0: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[23:03:27 CEST] <jamrial> J_Darnley: yeah, mailman somehow screws up and alters the signed portions of enigmail formated mail
[23:03:56 CEST] <jamrial> with the MIME multipart boundaries
[23:04:34 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.2:7793fc5b339d: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[23:05:54 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.1:f125c54b7a5f: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[23:06:57 CEST] <jkqxz> And 3.0 predates hwcontext, so not relevant.
[23:08:28 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:c823d72a5f43: avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message
[23:13:52 CEST] <alevinsn> question: regarding commit log e-mails received on ffmpeg-cvslog
[23:14:16 CEST] <alevinsn> If I remove the
[23:14:23 CEST] <alevinsn> "ffmpeg | ..." line
[23:14:28 CEST] <alevinsn> and put the next line in the subject
[23:14:32 CEST] <alevinsn> is that the equivalent of a patch?
[23:16:04 CEST] <alevinsn> besides the git.videolan stuff
[23:16:09 CEST] <alevinsn> forget it, I'll create it manually
[23:16:23 CEST] <jkqxz> The subject should be fine already because git am ignores the bit in [], so just remove the second line as well I think?
[23:17:28 CEST] <jkqxz> Easier to get it directly by pulling, though.
[23:18:29 CEST] <jkqxz> (ffmpeg and libav are sufficiently compatible that you can have a single repo with multiple remotes and cherry-pick patches between them.)
[23:19:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:e45226adc46e: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[23:19:17 CEST] <cone-630> ffmpeg 03Leo Izen 07master:f810c469223b: doc/filters: Added line to the af_bs2b filter docs mentioning --enable-libbs2b
[23:19:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:5666b95c9f27: avcodec/scpr: mask bits to prevent out of array read
[23:25:46 CEST] <alevinsn> jkqxz: I did it in a more manual fashion, maybe I could have done it faster in a way that saved a few minutes :-)
[23:33:28 CEST] <jkqxz> One of the perils of git. However you do something, someone else will always be able to tell you a more obscure way you could have done it faster :P
[00:00:00 CEST] --- Wed May 17 2017
More information about the Ffmpeg-devel-irc
mailing list