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

[burek]

[02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:dbac849c4db9: avcodec/lagarith: Optimize FRAME_SOLID_RGBA
[02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:2c1613ac94d0: avcodec/cfhd: Move peak_table() and difference_coding() calls after the existing coefficient count check
[02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:77429b4217bd: avcodec/cfhd: Use the actual count instead of the expected in peak_table()
[02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:78d4b6bd43fc: avformat/nsvdec: Do not parse multiple NSVf
[03:39:12 CEST] <BBB> jamrial: have you changed your mind about VDD? I dont know how to beg you, please consider coming
[03:39:23 CEST] <BBB> I fly from far also, its not great but its not that bad
[03:39:37 CEST] <BBB> so do several others
[03:40:23 CEST] <jamrial> BBB: it's not the distance, it's just something too overwhelming for me
[03:40:52 CEST] <BBB> youthink well swarm you like flies and eat you?
[03:41:41 CEST] <jamrial> no, my insecurities will :p
[03:41:53 CEST] <BBB> youre not the only geek there, everyone is
[03:42:10 CEST] <BBB> geek isnt even forbidden by the CoC, because its a fact
[03:42:48 CEST] <BBB> this is probably hard to imagine if youdont attend more often, but its really quite fun, even if you dontknow anyone or dont quite know what to expect
[03:43:23 CEST] <BBB> most of us are not there to troll, just to meet face-to-face and be able to discuss some items with everyone in the same timezone and nobody being able to randomly afk for whatever reason
[03:43:34 CEST] <BBB> it really does help to have everyoe present and read facial expressions
[03:43:56 CEST] <BBB> jb pays for everything, and its fun, please consider it
[03:43:58 CEST] <BBB> were not terrible
[03:44:09 CEST] <BBB> we need more not-terrible, even pleasant, people
[03:45:28 CEST] <jamrial> i know
[03:48:26 CEST] <atomnuker> overwhelming? I too used to feel like that just thinking of travelling to an unknown big city
[03:48:31 CEST] <BBB> and if you need some time alone, dont forget that paris is one of the most beautiful cities in europe
[03:48:39 CEST] <BBB> you can always sneak out for a bit and enjoy the city
[03:48:56 CEST] <BBB> (<secret> FREE PARIS TRIP !!! </secret>)
[05:26:59 CEST] <rcombs> should I go to that
[06:16:19 CEST] <Compn> rcombs : its interesting
[06:16:51 CEST] <Compn> i'd guess a few of us have crippling anxiety
[06:18:16 CEST] <atomnuker> yeah, getting on a single bad flight surrounded by kids is enough to make anyone have axiety issues before flying
[06:19:18 CEST] <Compn> i was on a 9 hour flight sitting beside a nanny and 4 kids who were told to scowl at me until they fell asleep, at which point the nanny spent the remainder of the flight talking loudly on the phone
[06:19:29 CEST] <Compn> so yeah that was a lot of fun 
[06:22:32 CEST] <rcombs> I don't really have problems with travel; I do it often enough
[06:24:19 CEST] <Compn> paris is fun though
[06:34:01 CEST] <atomnuker> if you go north of Gare du Nord (which you have to to get a useful metro line) you'll almost believe you're in Brick Lane or New Cross
[08:52:43 CEST] <JEEB> heh, low bit rate data streams are "fun" in MPEG-TS with FFmpeg since they can cause the probing just go on and on if you happen to press that "probe stream" API :)
[08:53:41 CEST] <JEEB> with a file it's a no brainer since you get to the EOF rather quickly
[11:16:25 CEST] <JEEB> alright, limited the H.264 breakage sample to 10MiB
[11:16:59 CEST] <JEEB> (some GOPs decode'able, and then the issue hits, which continues to the following GOPs)
[11:17:23 CEST] <JEEB> (although looking at the header tracing it should only be 12 packets that are borked)
[11:23:11 CEST] <JEEB> https://kuroko.fushizen.eu/samples/2018-08-17-h264_decoder_borks.cut.ts
[12:25:34 CEST] Action: JEEB wonders where to start with the H.264 decoder
[12:27:20 CEST] <JEEB> it should be getting new PPS/SPS and whatever reference count containing stuff, but it seems to always be lacking some refs
[12:28:43 CEST] <JEEB> http://up-cat.net/p/071386c4
[12:28:52 CEST] <JEEB> the "default" it outputs seems to be somewhat high int-wise, too :D
[12:56:07 CEST] <JEEB> hmm
[12:56:14 CEST] <JEEB> h264_fill_mbaff_ref_list stops getting called
[12:58:19 CEST] <JEEB> http://up-cat.net/p/b1472463 and those Perkele1/2 logs stop showing up
[12:58:29 CEST] <JEEB> while before that they were getting called
[13:12:16 CEST] <JEEB> wait, did the stream just randomly switch from MBAFF to PAFF...
[13:25:42 CEST] <kierank> JEEB: that's allowed
[13:31:31 CEST] <JEEB> yea
[13:31:43 CEST] <JEEB> it's just that something's going awry regarding refs
[13:31:47 CEST] <JEEB> in the decoder
[13:34:36 CEST] <kierank> doesn't suprise me
[13:34:51 CEST] <kierank> I'd like to build a "super-fate" at work around this kind of thing
[14:00:08 CEST] <gh0st__> I have tested SIMD optimizations on a Ryzen 5 cpu with checkasm --bench and it seems that in most cases there are no speed benefits for avx2 instruction set or worse it is even slower than:ssse3, avx... Is this because of the half throughput that Ryzen 5's avx2 has compared to intel cpus?
[14:00:49 CEST] <Gramner> gh0st__: ryzen only have 128-bit SIMD, so avx2 generally doesn't make things faster
[14:03:07 CEST] <gh0st__> Well, that's unfortunate.
[14:05:13 CEST] <gh0st__> Then the question is: if it doesn't speed things, then why did they introduced avx2 in their chips?
[14:05:23 CEST] <nevcairiel> tick in the feature list
[14:05:58 CEST] <Gramner> it's useful if you only want to write avx2 and not bother with older code, that's about it
[14:06:33 CEST] <gh0st__> Alright, then I hope we will see 256-bit SIMD on zen2 I guess.
[14:06:50 CEST] <Gramner> possibly
[14:06:57 CEST] <Gramner> or zen3. or 4. or 5.
[14:07:06 CEST] <Gramner> it'll get implemented eventually
[14:16:02 CEST] <January> jkqxz: jamrial said you had a patch for h264_metadata_bsf which allowed adding multi-field data in sei?
[14:24:13 CEST] <jkqxz> January:  For captions?  I have <https://github.com/fhvwy/FFmpeg/commits/cbs>, but it doesn't have any special handling for fields.
[18:11:15 CEST] <kierank> durandal_1707: bug last night was -1 * (x >> n) != ((-x) >> n)
[18:11:19 CEST] <kierank> I found reference implementation
[19:11:06 CEST] <durandal_1707> kierank: so block 2 is also finished and only P frames are left?
[19:11:26 CEST] <kierank> I am not doing p-frames
[19:11:31 CEST] <kierank> no samples exist for real
[19:11:39 CEST] <kierank> and too much mpegvideo mess to integrate 10-bit
[19:11:56 CEST] <kierank> don't know about block_type 2 actually
[19:12:01 CEST] <kierank> reference implementation doesn't actually follow spec
[19:12:43 CEST] <kierank> block[width*(height-1-i)+j] = current
[19:12:48 CEST] <kierank> that's what reference implementation does
[19:12:55 CEST] <kierank> where j from 0 to width
[19:12:58 CEST] <kierank> so it's not right to left at all
[19:53:37 CEST] <kierank> durandal_1707: there is still weird dot under the 6, must be idct related
[22:11:03 CEST] <durandal_1707> converted all gotos from prosumer decoder
[23:06:25 CEST] <durandal_1707> j-b: is my imm4 patch log message ok?
[23:06:37 CEST] <j-b> durandal_1707: sorry, I was AFK quite a bit
[23:06:46 CEST] <j-b> I'm still catching up with mails
[23:15:57 CEST] <j-b> durandal_1707: LGTM
[23:16:24 CEST] <j-b> durandal_1707: doesn't this patch require a version bump?
[23:16:45 CEST] <j-b> (minor or revision, I don't remember, when adding a CODEC_ID)
[23:17:02 CEST] <durandal_1707> j-b: i will add it before pushing
[23:19:01 CEST] <atomnuker> I think its a minor bump
[23:19:14 CEST] <atomnuker> and put something in the changelog if you haven't
[23:20:02 CEST] <j-b> good point
[23:20:13 CEST] <j-b> (also, really cool)
[23:20:52 CEST] <durandal_1707> j-b: i think there is >100 special CCTV codecs
[23:21:00 CEST] <j-b> probable.
[23:21:04 CEST] <j-b> Geox crap too
[23:27:00 CEST] <j-b> what is prosumer?
[23:28:22 CEST] <j-b> ah yes, BT20
[23:30:24 CEST] <durandal_1707> j-b: 1999 era
[23:30:48 CEST] <j-b> durandal_1707: tbh, your BT20 is harder to read than your IMM4 one
[23:30:53 CEST] <j-b> +code
[23:34:38 CEST] <durandal_1707> j-b: yes, because code uses 16bit integers a lot, it can be further simplified too
[23:35:26 CEST] <j-b> probably
[23:36:23 CEST] <j-b> all the if ((((b >> 8) & 0xFFu) != 0x80u) || (b & 0xFFu)) { and so on
[00:00:00 CEST] --- Tue Aug 21 2018