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

[burek]

[00:07:41 CEST] <cone-915> ffmpeg 03Michael Niedermayer 07master:0e2f0fedcd22: ffmpeg: Change duration to int64_t
[00:07:55 CEST] <Compn> J_Darnley : either no one wrote one or found it wasnt faster than c version ?
[00:08:02 CEST] <Compn> probably the first
[00:09:30 CEST] <J_Darnley> Perhaps I need to be more specific.  I am asking why there is the notcpuflag(sse4) at libswscale/x86/scale.asm:404
[00:13:36 CEST] <kierank> J_Darnley: ask BBB 
[00:13:57 CEST] <J_Darnley> Perhaps I need to be more specific.  I am asking why there is the notcpuflag(sse4) at libswscale/x86/scale.asm:404 <-- BBB
[00:14:29 CEST] <J_Darnley> Why doesn't swscale have sse4 variants of the hscaleXto15 functions?  No different instructions to use?
[00:14:38 CEST] <BBB> probably, yes
[00:14:48 CEST] <BBB> or I tested it and it wasnt faster
[00:33:56 CEST] <J_Darnley> oh he's gone again
[00:34:35 CEST] <J_Darnley> I have made a quick test of using pmovzxbw in sse4 but it doesn't look like it is noticibly faster or slower.
[00:51:52 CEST] <iive> is that move zero-extend byte to word ?
[00:58:08 CEST] <J_Darnley> yes
[01:33:12 CEST] <J_Darnley> oh wow.  the assembled code looks so much shorter without the masses of iffery in the source
[01:33:33 CEST] <nevcairiel> heh
[01:41:37 CEST] <kierank> J_Darnley: yes
[01:42:07 CEST] <kierank> J_Darnley: i recall writing a simple swscale function for one case and then BBB coming along and blowing my mind with macros
[02:00:24 CEST] <BBB> J_Darnley: the macros dont always help readability, yes :(
[02:08:44 CEST] <BBB> J_Darnley: I do still feel they help maintainability because most code is duplicated between the different variants, and the macros help expose that
[02:08:58 CEST] <BBB> J_Darnley: but I agree they make it harder to get into it...
[02:16:03 CEST] <J_Darnley> Please don't take it as a critcism.  It was just an ovbservation.
[02:22:10 CEST] <J_Darnley> oh cock, here's where avx2's split lanes is trouble
[02:22:55 CEST] <J_Darnley> Something about splitting/loading previous and next pixels
[02:34:14 CEST] <BBB> J_Darnley: hahaha :) some parts may be tricky yes
[02:57:36 CEST] <J_Darnley> kierank: I'm not sure I can simply unroll hscale8to15 for avx2 because it relys on runtime information.
[03:00:43 CEST] <J_Darnley> I think it requires using fltsize as an offset to get the data
[03:01:13 CEST] <J_Darnley> ... the data for the next dqword.
[03:07:12 CEST] <J_Darnley> Anyway, I'm going to sleep
[03:07:19 CEST] <J_Darnley> Good night all.
[04:11:31 CEST] <cone-688> ffmpeg 03Michael Niedermayer 07master:afe950e1fa87: avcodec/bitpacked: Fix mixed declarations and statement
[04:11:31 CEST] <cone-688> ffmpeg 03Michael Niedermayer 07master:61ee2ca77586: avcodec/dvdsubdec: Fixes 2 runtime error: left shift of 170 by 24 places cannot be represented in type 'int'
[05:03:42 CEST] <cone-688> ffmpeg 03Diego Biurrun 07master:e122b12c8848: build: Drop gcrypt support
[05:03:43 CEST] <cone-688> ffmpeg 03Anton Khirnov 07master:dc4b62502876: tta: use get_unary() instead of a custom implementation
[05:03:44 CEST] <cone-688> ffmpeg 03Anton Khirnov 07master:4adbb44ad154: tta: avoid undefined shifts
[05:03:45 CEST] <cone-688> ffmpeg 03Mark Thompson 07master:d30719e62de6: hwcontext_vaapi: Don't abort on failing to allocate from a fixed-size pool
[05:03:47 CEST] <cone-688> ffmpeg 03James Almer 07master:8489d1427490: Merge commit 'e122b12c88487ac8766ff4eb071856b0666f0134'
[05:03:47 CEST] <cone-688> ffmpeg 03James Almer 07master:208cceb24c9a: Merge commit 'dc4b62502876c0ebeeba317233cd1348c5b0b2b7'
[05:03:48 CEST] <cone-688> ffmpeg 03James Almer 07master:4fbb56acbe71: Merge commit '4adbb44ad154cec05e87de60bb827a13c0fe87df'
[05:03:49 CEST] <cone-688> ffmpeg 03James Almer 07master:bfb2e20737cb: Merge commit 'd30719e62de68975cbc7ffd318df03a183037563'
[05:21:02 CEST] <cone-688> ffmpeg 03Diego Biurrun 07master:e22c63ac74b2: ac3enc: Reshuffle some float/fixed-mode ifdefs to avoid a dummy function
[05:21:03 CEST] <cone-688> ffmpeg 03Diego Biurrun 07master:f0d3e43bd77b: ac3enc: Reshuffle functions to avoid forward declarations
[05:21:04 CEST] <cone-688> ffmpeg 03James Almer 07master:c37e8c0b7fd4: Merge commit 'e22c63ac74b2968075be8bf0d2deb1ee63b28976'
[05:21:05 CEST] <cone-688> ffmpeg 03James Almer 07master:e7ec8c181fe4: Merge commit 'f0d3e43bd77b3194a28d75884cf83083b188bf30'
[05:23:10 CEST] <cone-688> ffmpeg 03Diego Biurrun 07master:eb135516e6f6: ac3enc: Avoid unnecessary macro indirections
[05:23:11 CEST] <cone-688> ffmpeg 03James Almer 07master:19e0a67da3e7: Merge commit 'eb135516e6f61481877163bfc55a3161d4544092'
[05:27:21 CEST] <cone-688> ffmpeg 03Diego Biurrun 07master:b0f67d03c50f: ac3enc: Avoid unnecessary macro indirections
[05:30:10 CEST] <cone-688> ffmpeg 03Luca Barbato 07master:d0c84c41d33f: avconv: Fix the audio next dts computation
[05:30:11 CEST] <cone-688> ffmpeg 03Andreas Cadhalpun 07master:1762a39e09a3: mss2: only use error correction for matching block counts
[05:30:12 CEST] <cone-688> ffmpeg 03James Almer 07master:8d2c6dc35538: Merge commit 'd0c84c41d33ffd270d5f9fe0290e08341397fdee'
[05:30:13 CEST] <cone-688> ffmpeg 03James Almer 07master:f27ff5e7c3fd: Merge commit '1762a39e09a3edc27d1ef7bc50070f496b893aa4'
[05:32:49 CEST] <cone-688> ffmpeg 03James Almer 07master:45d199d5b0b7: aac_adtstoasc_bsf: validate and forward extradata if the stream is already ASC
[05:32:50 CEST] <cone-688> ffmpeg 03James Almer 07master:51d8a2572fd8: Merge commit '45d199d5b0b7f09eb9baa29929a3bd07ed46223b'
[05:48:33 CEST] <cone-688> ffmpeg 03Anton Khirnov 07master:328cd2b599bc: lavc: move encoding-related code from utils.c to a new file
[05:48:34 CEST] <cone-688> ffmpeg 03James Almer 07master:bd9057e74bcd: Merge commit '328cd2b599bc2d0d38f3c12606fa2a66eeec016e'
[06:40:13 CEST] <cone-688> ffmpeg 03Anton Khirnov 07master:3fe2a01df7f2: lavc: move decoding-related code from utils.c to a new file
[06:40:14 CEST] <cone-688> ffmpeg 03James Almer 07master:00fb745a10a1: Merge commit '3fe2a01df7f2c193805809f57b61d79607572351'
[08:02:41 CEST] <wm4> I wonder if that decode.c code move was hard...
[09:16:15 CEST] <nevcairiel> moving code  aint that bad, just have to copy-paste the same code they moved, since auto-merge doesnt w ork
[09:18:52 CEST] <wm4> depends how upstream moved it... if you can easily reproduce it, it's probably simpler
[09:23:48 CEST] <ubitux> as soon as you have code moving, it's much safer to redo the commit and diff the final files
[09:24:04 CEST] <ubitux> i also often redo their commit in their tree, to see if i end up with something different
[09:24:17 CEST] <ubitux> typically to check if they slip cosmetics in
[09:24:32 CEST] <ubitux> Anton doesn't do it much but others do
[09:24:55 CEST] <ubitux> merges are painful.
[10:08:43 CEST] <cone-686> ffmpeg 03Diego Biurrun 07master:239d02eff3ff: avisynth: Cast to the right type when loading avisynth library functions
[10:08:43 CEST] <cone-686> ffmpeg 03Clément BSsch 07master:92e532c18fee: Merge commit '239d02eff3ffe9f7d40caa21dde50fb4a0e94c24'
[10:09:48 CEST] <cone-686> ffmpeg 03Diego Biurrun 07master:3ee5f25d3731: dxva2: Adjust printf length modifiers where appropriate
[10:09:49 CEST] <cone-686> ffmpeg 03Clément BSsch 07master:e7326e2980a0: Merge commit '3ee5f25d37315b27f0e2d47aa69fc445545ee2e3'
[10:52:35 CEST] <cone-686> ffmpeg 03Diego Biurrun 07master:212c6a1d70df: mjpegdec: Check return values of functions that may fail
[10:52:36 CEST] <cone-686> ffmpeg 03Clément BSsch 07master:9c7ee37490d2: Merge commit '212c6a1d70df011b6f2a2aa02f7677503287bd00'
[10:57:57 CEST] <kierank> https://software.intel.com/en-us/blogs/2017/03/31/media-sdk-open-source-launch
[10:58:02 CEST] <kierank> are they not selling enough?
[11:01:47 CEST] <JEEB> interesting
[11:02:02 CEST] <wm4> who knows
[11:03:31 CEST] <BtbN> pobably because it#s kinda poiintless on linux, due to libva suppoting he same set of featues anyway?
[11:05:03 CEST] <wm4> the qsv encoder is supposedly better
[11:05:12 CEST] <kierank> there's a difference?
[11:05:27 CEST] <kierank> that's so confusing
[11:05:43 CEST] <BtbN> Probably just different default parameters
[11:05:49 CEST] <BtbN> it's the same silicon after all
[11:06:39 CEST] <nevcairiel> more importantly the qsv stuff does a lot of work for you that with vaapi you have to do manually (so its easy to screw it up, too)
[11:06:52 CEST] <wm4> ffmpeg does most of this automagically
[11:07:06 CEST] <nevcairiel> that is assuming this code in ffmpeg is any good
[11:07:30 CEST] <wm4> you can always use libyami
[11:07:33 CEST] <wm4> (have fun)
[11:07:34 CEST] <BtbN> with all the hwcontext stuff, you don't have to do that much yourself anymore
[11:15:42 CEST] <JEEB> wm4: lol I will probably never get over the naming of that thing. "yami" being "darkness" in .jp
[11:16:43 CEST] <wm4> lol
[11:16:59 CEST] <nevcairiel> its yet another "yet another" name =p
[11:45:27 CEST] <jkqxz> It's just the wrapper library - all of the interesting parts are hidden inside the pseudoVAAPI driver.
[11:49:42 CEST] <uau> wm4: i think your commit 4cf1f68903 ("minor simplification to error handling") has a bug
[11:49:48 CEST] <kierank> gotta have an SDK so your outsourced dev team understands
[11:49:52 CEST] <uau> "This should be equivalent to the old code, which obviously required err=0 for p->result>=0" doesn't seem true because of the loop
[11:50:15 CEST] <uau> err can be set from any thread, and p change after that
[11:50:35 CEST] <uau> what are the semantics SUPPOSED to be here?
[11:51:04 CEST] <uau> should the loop stop at the first thread that returns a frame OR error, and return that?
[11:51:22 CEST] <wm4> err will be set to the p->result of the last worker thread that had an error, so I don't understand that
[11:52:19 CEST] <uau> wm4: you first have one thread that has an error, then find another with a frame, and return a frame AND an error - is that not a problem?
[11:52:59 CEST] <wm4> hm yeah that's strange
[11:53:02 CEST] <uau> before your commit the semantics were to first return frames if any, then return error codes if any
[11:53:24 CEST] <uau> after it having a frame to return does not prevent returning error
[11:53:59 CEST] <wm4> so would you say "if(*got_picture_ptr)err=0;" would fix this?
[11:54:34 CEST] <uau> well as i asked above i'm not 100% sure what the "right" semantics are that you should "fix" it to
[11:55:31 CEST] <uau> my current best guess would be to make the loop stop at frame OR error, return that, and reset return/error for that thread to ensure it is not returned twice
[11:55:52 CEST] <uau> but i'm not 100% sure whether errors while draining could be interpreted as fatal and stop further draining
[11:56:10 CEST] <uau> if so, that might require returning valid frames first, then errors?
[11:57:36 CEST] <wm4> no, they should be returned in the correct order
[11:58:51 CEST] <uau> well then i'd say the correct fix would be to change the loop end condition and reset ->result in addition to got_frame for a thread whose result is returned
[12:00:27 CEST] <wm4> I don't know
[12:01:02 CEST] <uau> though do you really care that much about "correct order"? when there is no guaranteed correspondence of the return value to input frames anyway (at least if the codec can return with neither a frame nor an error, as such results are now skipped, and you can't know which input frames were thus skipped)
[12:01:23 CEST] <wm4> some API users rely on a fixed delay
[12:01:33 CEST] <wm4> they compute it with has_b_frames etc.
[12:01:55 CEST] <wm4> so they very much need a 1:1 correspondence between input and output
[12:02:18 CEST] <wm4> (not that I'm claiming this is not fragile...)
[12:02:26 CEST] <uau> but draining doesn't respect that
[12:02:35 CEST] <uau> the loop simply skips some frames
[12:02:56 CEST] <wm4> so should the loop exit if p->result is set?
[12:03:11 CEST] <wm4> (and equally, reset p->result to 0 if a frame could be decoded)
[12:03:40 CEST] <wm4> this is probably a good moment to say that I don't understand how frame theading works
[12:03:44 CEST] <wm4> *threading
[12:03:59 CEST] <uau> how it actually works doesn't seem too relevant here
[12:04:23 CEST] <wm4> the worker threads seem to form some sort of ring buffer
[12:04:41 CEST] <wm4> why is draining even special
[12:04:42 CEST] <uau> i don't understand what you mean by "reset p->result to 0 if a frame could be decoded" - if you mean the particular thread p which managed to decode the frame, didn't that already set p->result to an appropriate value?
[12:04:58 CEST] <wm4> I don't know if it sets it?
[12:05:41 CEST] <uau> well p->result is the result value from the corresponding decoder invocation AFAIK
[12:06:27 CEST] <uau> i'm not 100% sure about why draining needs to be special, but perhaps it's because you couldn't know how may drain packets you'd need otherwise?
[12:06:37 CEST] <uau> at least not without explicit delay assumptions
[12:07:05 CEST] <uau> as in you send a 0-sized packet, get nothing in return - do you need to send more packets to be sure you've got everything that's been buffered or not?
[12:07:46 CEST] <wm4> but then it shouldn't only check for got_frame
[12:07:51 CEST] <wm4> but also p->result
[12:08:00 CEST] <wm4> since a decoder result is either a frame or an error
[12:08:08 CEST] <wm4> only if both are 0 decoding has finished
[12:08:38 CEST] <uau> well originally it just ignored those errors
[12:09:44 CEST] <uau> which 32a5b631267 attempted to change
[12:23:21 CEST] <uau> wm4: utils.c has "if (avctx->internal->draining && !got_frame)  avctx->internal->draining_done = 1;", which doesn't look like returning errors and frames in-order would work without changes there...
[12:24:59 CEST] <wm4> that's a hack which I added for other reasons (multiple audio decoder don't get this right)
[12:26:59 CEST] <uau> what do they do then? they return one empty packet, but then start returning either bogus data or errors?
[12:27:59 CEST] <wm4> getting stuck returning errors forever
[12:28:15 CEST] <wm4> because draining on error doesn't change their state
[12:28:52 CEST] <wm4> I'm hoping that one day in the future, someone will remove this hack as "absurd hack fix from the past"
[12:29:34 CEST] <uau> well anyway that needs changes if you want pthread_frame to behave as above
[12:43:49 CEST] <wm4> hm gapless decoding in mp4 still appears to be broken
[12:44:03 CEST] <wm4> either that, or encoding
[14:33:22 CEST] <J_Darnley> I don't suppose anyone has a partial or WIP patch for this comment in swscale? "FIXME maybe do 4px/iteration on x86-64 (x86-32 wouldn't have enough regs)?"
[14:38:48 CEST] <J_Darnley> If I attempt that unrolling do I need to increase the dlt used in the loop?
[14:48:23 CEST] <J_Darnley> Rats.  I think I need a multiple of 3 in a memory lookup
[14:48:46 CEST] <nevcairiel> a+a*2 ?
[14:49:03 CEST] <J_Darnley> More like: a+b*3
[14:49:14 CEST] <nevcairiel> guess no cheat then
[14:49:20 CEST] <J_Darnley> :)
[14:49:58 CEST] <J_Darnley> yasm would do the a*3 cheat for me
[15:23:29 CEST] <J_Darnley> Well that looks better than the avx2.  Still wrong though
[15:34:04 CEST] <cone-686> ffmpeg 03Michael Niedermayer 07master:08117a401574: avcodec/h264: Check weight values to be within the specs limits.
[15:58:48 CEST] <J_Darnley> I still can't spot my mistake.
[15:59:07 CEST] <J_Darnley> https://gitlab.com/J_Darnley/ffmpeg/commit/21af6be41ec77e8bc0a58edc2f2d1e3fdbadd906
[15:59:27 CEST] <J_Darnley> Can anyone see the error in my unrolling?
[16:06:18 CEST] <kierank> J_Darnley: what does the picture look like?
[16:20:33 CEST] <J_Darnley> noisy/dirty
[16:20:53 CEST] <J_Darnley> I might be duplicating pixels
[16:28:47 CEST] <kierank> can you post a screenshot
[16:37:43 CEST] <J_Darnley> Yes.  I'm trying to find a better one that hasn't been through a low quality encoder
[16:42:57 CEST] <kierank> use the v210 720p sample
[16:43:08 CEST] <kierank> and convert it to 4020
[16:45:07 CEST] <J_Darnley> That looks fine
[16:46:42 CEST] <J_Darnley> why is it this hard to hit one function in swscale
[16:51:49 CEST] <J_Darnley> There we go.  That one looks like shit.
[16:53:31 CEST] <J_Darnley> http://imgur.com/a/Lr50s
[16:56:18 CEST] <wm4> so when will someone modernize/rewrite libswscale
[16:58:30 CEST] <kierank> J_Darnley: luma looks ok?
[16:58:50 CEST] <kierank> wm4: would you come to an swscale summit
[16:58:59 CEST] <J_Darnley> wm4: doesn't it already exist?  isn't it called zimg?
[17:00:03 CEST] <kierank> like seriously it needs people to sit down for 2 days and decide what they want
[17:00:34 CEST] <J_Darnley> kierank: No, I don't think the luma is okay
[17:00:55 CEST] <wm4> kierank: if "come to" means joining an IRC channel or a ML, sure
[17:01:09 CEST] <kierank> maybe a ML will be enough
[17:01:12 CEST] <wm4> J_Darnley: it's written in C++ and thus is hated by many ffmpeg people (?)
[17:01:28 CEST] <J_Darnley> Ah.  I guess I will hate it too then
[17:01:38 CEST] Action: kierank feels irrational hate
[17:01:43 CEST] Action: kierank judges a book by its covber
[17:01:44 CEST] <nevcairiel> a swscale replacement needs more generic converters so we can really do  any:any conversions,  zimg is probably too limited in format support
[17:02:05 CEST] <kierank> it also needs the ability to cleanly to bypass
[17:02:12 CEST] <kierank> where n -> m you implement yourself
[17:02:30 CEST] <wm4> I think zimg intents to handle obscure formats by providing the ability to "unpack" and "pack" lines of image data
[17:02:38 CEST] <wm4> but I don't know details
[17:03:02 CEST] <iive> J_Darnley: you increment pointer with mmsize in both cases 
[17:06:27 CEST] <J_Darnley> do you mean filterq?
[17:06:38 CEST] <iive> yes
[17:08:01 CEST] <iive> you process twice as much data in one loop run, so filterq and src should be incremented with double the amount.
[17:10:57 CEST] <J_Darnley> Well, I have changed that but there is no difference.
[17:12:09 CEST] <J_Darnley> I didn't think it was that because of how they are accessed with that other register
[17:13:40 CEST] <iive> J_Darnley: well, it could have been if src and dst overlap, if they don't the unrolled results were just ignored.
[17:13:59 CEST] <J_Darnley> dammit I edited the wrong file.  I better try that again
[17:14:49 CEST] <J_Darnley> still wrong
[17:15:51 CEST] <michaelni> jamrial, 4fbb56acbe711ab4c01c0207cc9dabc27f7c6477 is wrong
[17:16:11 CEST] <michaelni> i get Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:265 from it
[17:16:30 CEST] <jamrial> odd, tta fate tests pass
[17:16:58 CEST] <jamrial> feel free to revert it, or ask durandal_1707 if he can improve it instead
[17:17:08 CEST] <iive> J_Darnley: is the picture scalled in rgb32 or yuv420 color space?
[17:17:16 CEST] <michaelni> jamrial, its simply wrong for our bitreader
[17:17:34 CEST] <jamrial> michaelni: afaik, tta wasn't updated for the new bitreader in libav at the time of this commit
[17:18:16 CEST] <jamrial> michaelni: https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/tta.c;h=5532580e02239076d086a9078b5f75534db0c633;hb=4adbb44ad154cec05e87de60bb827a13c0fe87df
[17:18:26 CEST] <jamrial> so i guess they don't have that assert
[17:18:29 CEST] <iive> michaelni: are you sure tta should be moved to use get_bits_long in instead?
[17:18:51 CEST] <nevcairiel> the reader can only read 25 bits though, so if it can legimiately be 32, use get_bits_long
[17:22:50 CEST] <J_Darnley> iive: the one I showed?  I'm not sure I'll check but others are in yuv
[17:23:30 CEST] <iive> J_Darnley: it does look like yuv420
[17:26:58 CEST] <iive> J_Darnley: fltpos is an array, containing indexes, in unroll case it should be called as filterPos[4] array by the calling function.
[17:27:17 CEST] <iive> J_Darnley: another solution is just to use [0] and [1] as they should be the same
[17:28:13 CEST] <michaelni> iive, i dont know about get_bits_long() but if it would be needed a file needing it would error and it would get reported by users, this would have happened already likely as that check was there before
[17:28:56 CEST] <iive> michaelni: oh, sorry, I didn't know what the commit changes, I assumed it adds the assert.
[17:29:24 CEST] <michaelni> no it changed 25 to 32 and added a 2nd check
[17:30:15 CEST] <michaelni> ubitux, 9c7ee37490d21350ab1a2e07069284daf1943e52 breaks jpeg
[17:30:30 CEST] <J_Darnley> iive: noted
[17:30:31 CEST] <michaelni> example: ./ffmpeg_g -i ~/tickets/267/frame.jpg  -f null 
[17:30:38 CEST] <iive> J_Darnley: basically, you can do mov m8, m0 ; mov m9, m1
[17:30:43 CEST] <J_Darnley> I'm off to cook dinner so I'll check later
[17:31:33 CEST] <michaelni> ubitux, sample should be http://trac.ffmpeg.org/raw-attachment/ticket/267/frame.jpg
[17:36:00 CEST] <jamrial> michaelni: was that assert triggered by a valid file or a fuzzed one?
[17:36:39 CEST] <ubitux> michaelni: looking at it
[17:37:47 CEST] <iive> J_Darnley: ok, I'm wrong about the mov's , you need different fliter values from next srcq away, so 2*mmsize/2
[17:38:24 CEST] <michaelni> jamrial, fuzzed IIRC, i can send it privately if you want 
[17:42:07 CEST] <jamrial> michaelni: sure, but in any case that probably confirms k can't really be higher than 25 on valid files, so maybe the check should be "if (k > MIN_CACHE_BITS || unary > INT32_MAX >> k)"?
[17:42:20 CEST] <durandal_1707> michaelni: 32 should be changet back to 25
[17:42:36 CEST] <jamrial> yeah
[17:43:02 CEST] <durandal_1707> tta doesnt use long bit reader
[17:43:12 CEST] <michaelni> jamrial, agree
[17:43:22 CEST] <ubitux> michaelni: apparently it's due to tolerating a fail in mjpeg_decode_app()
[17:44:23 CEST] <ubitux> michaelni: we do not allow a problem in "com" or "dqt", but we do in "app"
[17:44:33 CEST] <ubitux> any idea why the inconsistency?
[17:44:39 CEST] <michaelni> i wonder too
[17:44:43 CEST] <ubitux> like, couldn't we still decode without "com"?
[17:44:54 CEST] <michaelni> exactly what iam thining
[17:44:58 CEST] <michaelni> thinKing
[17:47:32 CEST] <michaelni> com failures are only ENOMEM so i guess this just doesnt occur much
[17:47:38 CEST] <ubitux> ok
[17:47:41 CEST] <michaelni> so noone noticed
[17:47:56 CEST] <ubitux> i'm making a patch
[17:48:04 CEST] <michaelni> ok
[17:48:04 CEST] <ubitux> do you mind adding the sample to fate so we can add a test?
[17:49:33 CEST] <michaelni> ill upload it to  fate-suite/jpg/ticket267.jpg
[17:49:46 CEST] <ubitux> michaelni: http://b.pkh.me/0001-lavc-mjpegdec-allow-failure-while-decoding-APP.patch
[17:56:05 CEST] <cone-686> ffmpeg 03James Almer 07master:7c1566fec394: avcodec/tta: Don't try to read more than MIN_CACHE_BITS bits
[17:59:47 CEST] <michaelni> ubitux, LGTM and thx, ill have to go afk now, ill check irc later
[18:04:28 CEST] <cone-686> ffmpeg 03Clément BSsch 07master:8d94d9798a69: lavc/mjpegdec: allow failure while decoding APP
[19:04:16 CEST] <BBB> J_Darnley: nope I never tried that myself (4px/iteration on x86-64)
[19:30:08 CEST] <cone-686> ffmpeg 03Ronald S. Bultje 07master:7f05c5cea041: h264: don't re-call ff_h264_direct_ref_list_init() w/ frame-mt.
[19:30:09 CEST] <cone-686> ffmpeg 03Ronald S. Bultje 07master:2e664b9c1e73: pthread_frame: make accesses to debug field be protected by owner lock.
[19:30:26 CEST] <BBB> ubitux: ok, fate-h264 in frame-mt/tsan should be clean now
[19:30:46 CEST] <BBB> ubitux: Im unlikely to work on the remaining two issues anytime soon (mpeg4 and frame_thread_encoder)
[19:30:59 CEST] <BBB> ubitux: but maybe Ill be tickled into it at some point
[19:31:08 CEST] <BBB> if anyone else wants to work on them, be my guest
[19:58:29 CEST] <J_Darnley> what the heck.  why does the assembly look nothing like the C?
[19:58:34 CEST] <J_Darnley> is the assembly partly unrolling both loops, maybe?
[19:58:36 CEST] <ubitux> BBB: ok i'll make a new run
[20:15:20 CEST] <durandal_1707> ok to push big patch without prior review to utvideodec?
[20:17:22 CEST] <durandal_1707> ok, pushing ......
[20:23:29 CEST] <ubitux> BBB: 3288/3382 ’ 3318/3382
[20:23:32 CEST] <ubitux> no more h264 :)
[20:23:55 CEST] <BBB> \o/
[20:24:12 CEST] <BBB> durandal_1707: uhm...
[20:24:12 CEST] <ubitux> i see some h263
[20:24:18 CEST] <BBB> ubitux: h263 is mpeg4
[20:24:39 CEST] <ubitux> yep ok
[20:25:12 CEST] <ubitux> so that's the next major one to fix
[20:25:30 CEST] <JEEB> durandal_1707: what kind of change is it btw?
[20:25:36 CEST] <ubitux> how about utvideoenc?
[20:25:46 CEST] <ubitux> BBB: ^
[20:26:02 CEST] <BBB> frame_thread_encoder
[20:26:28 CEST] <BBB> I think someone else should take that, I submitted a patch but michaelni has issues with it that are not performance or technical related so I dont really care about it
[20:26:28 CEST] <ubitux> ah that patch is not pushed yet?
[20:26:32 CEST] <BBB> right
[20:26:40 CEST] <ubitux> ok
[20:27:14 CEST] <ubitux> so what's left: frame encoder, mpeg4, and... many slices?
[20:27:48 CEST] <ubitux> michaelni: would be nice to have fixes for those :)
[20:28:11 CEST] <ubitux> (slices instance running)
[20:28:31 CEST] <BBB> Ill work some on slices
[20:29:49 CEST] <ubitux> what about rv34?
[20:31:09 CEST] <durandal_1707> JEEB: gradient prediction, recently introduced
[20:31:13 CEST] <JEEB> ah, right
[20:31:29 CEST] <JEEB> yea, the guy was like "lol it's as fast as left but compresses better. I shoulda done this ages ago"
[20:33:37 CEST] <durandal_1707> i already reviewed dnxddec patches
[20:34:05 CEST] <nevcairiel> ubitux: rv34 is mpegvideo as well =p
[20:35:22 CEST] <ubitux> the race is not in the same code though :3
[20:35:24 CEST] <ubitux> but ok
[20:36:00 CEST] <ubitux> olol the race in a memcpy on that mpegvideoENC context used for decoding
[20:36:05 CEST] <ubitux> ok i'm out
[20:49:48 CEST] <cone-686> ffmpeg 03Paul B Mahol 07master:faa94a576f5f: avcodec/utvideodec: add support for gradient prediction
[20:57:47 CEST] <michaelni> BBB, makng the latency fixed at the maxiumum should have a performance impact. I would not defend the design if it wasnt for that it should be capable of better performance 
[20:58:08 CEST] <BBB> ubitux: rv34 is mpeg4
[20:58:22 CEST] <BBB> or mpegvideo, yes
[21:49:43 CEST] <cone-686> ffmpeg 03James Almer 07master:9f102653fd72: ffmpeg: use av_stream_new_side_data()
[22:20:24 CEST] <cone-686> ffmpeg 03James Almer 07master:b8f26779d615: lavf: use the new bitstream filter for extracting extradata
[22:25:07 CEST] <cone-686> ffmpeg 03James Almer 07master:e7fb6bc32d1b: avcodec/hevc_parse: ignore all non parameter set NAL units in extradata
[22:32:15 CEST] <cone-686> ffmpeg 03James Almer 07master:3f8d7342c32c: doc/libav-merge: remove line about extract_extradata_bsf usage
[22:32:52 CEST] <jamrial> ubitux: one less line in the unmerged stuff list :D
[22:33:53 CEST] <durandal_1707> atomnuker: just push that pad patch, i just dont like check of removal of out of range values
[22:35:37 CEST] <cone-686> ffmpeg 03Ricardo Constantino 07master:57c3670896c6: vf_pad: center image on padded area if negative x/y
[22:35:57 CEST] <atomnuker> durandal_1707, RiCON: pushed, ktnx
[22:41:33 CEST] <J_Darnley> oh em gee!  I've got swscale using a gather instruction.
[22:42:50 CEST] <atomnuker> J_Darnley: are you doing SIMD for 8bit to 10bit conversion?
[22:45:01 CEST] <J_Darnley> not now
[22:45:07 CEST] <J_Darnley> horizontal scaling
[22:47:05 CEST] <atomnuker> huh, cool
[22:53:07 CEST] <J_Darnley> I would like to understand what controls the filtersize parameter in swscale.
[22:53:21 CEST] <J_Darnley> Is it the scale factor, or the output width, or what?
[23:03:27 CEST] <nevcairiel> its the scale factor, but i tried to look it up s ome time ago and it was rather confusing how it works exactly
[23:23:57 CEST] <J_Darnley> :(  my use of gather seems to be ~12% slower than ssse3
[00:00:00 CEST] --- Sat Apr  8 2017