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

[burek]

[00:00:16 CEST] <llogan> does it have to be actually comitted for the student to get paid?
[00:00:25 CEST] <Daemon404> im not sure
[00:00:41 CEST] <wm4> wow lukasz is even only backup mentor
[00:00:57 CEST] <wm4> (or maybe it was changed later)
[00:02:19 CEST] <wm4> it requires an implementation for http, but http doesn't even have a protocol for it (except webdav)
[00:02:58 CEST] <Daemon404> yeah.
[00:03:01 CEST] <nevcairiel> move and delete for http? what kind of weird task is that?
[00:03:38 CEST] <nevcairiel> or file lists at that, HTTP doesnt do that either
[00:04:37 CEST] <wm4> you could parse html
[00:04:38 CEST] <Daemon404> there is DELETE
[00:04:42 CEST] <Daemon404> i guess.
[00:05:12 CEST] <wm4> I believe we've complained more than once about this gsoc project, even before it was accepted
[00:05:33 CEST] <wm4> and now it can't be unfucked
[00:05:42 CEST] <llogan> should have just taken the initiative and deleted it
[00:05:48 CEST] <wm4> what will we do next time, wiki edit war?
[00:05:57 CEST] <nevcairiel> well its hidden somewhere at the bottom of the list of unmentored projects, I guess we didnt expect someone to actually pick that
[00:06:31 CEST] <Daemon404> llogan, deleting someone's entry they want to mentor is a good way to start flamewar
[00:06:35 CEST] <Daemon404> s
[00:06:41 CEST] <Daemon404> i attempted to stop it with words. failed.
[00:06:56 CEST] <nevcairiel> equal flamewars =p
[00:07:03 CEST] <Daemon404> mayhaps
[00:07:11 CEST] <wm4> michaelni: how did this project even get accepted?
[00:07:21 CEST] <llogan> i think the problem stems from the unlikely idea that we would have actually been picked for GSoC
[00:07:24 CEST] <wm4> it doesn't even have an available backup mentor
[00:07:56 CEST] <wm4> michaelni: maybe you can ask google whether he can change the project?
[00:08:22 CEST] <Daemon404> i seem to recall google got pissed at x264 for that, wm4
[00:08:22 CEST] <nevcairiel> He may have picked the project because its a somewhat known project, but doesnt require special skills
[00:08:24 CEST] <Daemon404> during GCI
[00:08:36 CEST] <nevcairiel> ie. its not a video or audio project
[00:08:54 CEST] <llogan> ah, it was flotsam from 2014 gsoc ideas
[00:08:55 CEST] <wm4> nevcairiel: there are other tasks that don't require special knowledge
[00:09:05 CEST] <wm4> and he actually has proven that he has some C and git skills
[00:09:18 CEST] <Daemon404> oh look
[00:09:26 CEST] <Daemon404> i found kierank arguing on the private ffmpeg-mentors list
[00:09:27 CEST] <Daemon404> with lukasz
[00:09:33 CEST] <Daemon404> about how this project shouldnt accepted
[00:09:44 CEST] <wm4> too bad it's private (is it?)
[00:09:52 CEST] <Daemon404> it is i think
[00:10:37 CEST] <Daemon404> oh yes all the people jumped on him
[00:10:38 CEST] <Daemon404> 1 sec
[00:15:33 CEST] <Daemon404> wm4, https://www.dropbox.com/sh/4bth65yr8r6prx0/AABu7besBHEPu3vmVoccIa8Pa?dl=0
[00:18:15 CEST] <Compn> Daemon404 : you're still mad about  smb support? 
[00:18:17 CEST] <Compn> muh smb
[00:20:51 CEST] <wm4> Daemon404: thanks
[00:21:57 CEST] <Daemon404> i would probably so much happier if i took the route most companies take
[00:22:01 CEST] <Daemon404> to internally fork or patch ffmpeg
[00:22:11 CEST] <Daemon404> i wonder why i subject myself to this
[00:22:17 CEST] Action: Daemon404 bets nevcairiel is happier with his fork
[00:22:18 CEST] <Compn> baptiste did it
[00:22:29 CEST] <nevcairiel> Daemon404: still have to kinda care what happens to upstream
[00:22:30 CEST] <wm4> because merging upstream is bothersome
[00:22:37 CEST] <Daemon404> Compn, baptiste is paying for it now
[00:22:41 CEST] <nevcairiel> with git its not too bad wm4
[00:22:42 CEST] <Daemon404> his fork is rotting
[00:22:50 CEST] <nevcairiel> i have my ~200 patches or so that I regularly rebase
[00:23:11 CEST] <nevcairiel> (although ~50 of those or are just the mkv demux replacement)
[00:23:12 CEST] Action: Compn wonders how many devs Daemon404 has scared off
[00:23:17 CEST] <Daemon404> 0
[00:23:24 CEST] <Compn> luckaz?
[00:23:30 CEST] <Daemon404> he didnt get scared off
[00:23:32 CEST] <Daemon404> he had a piss-fit
[00:23:34 CEST] <Daemon404> and ragequit
[00:23:35 CEST] <Compn> lukasz*
[00:23:36 CEST] <Compn> ragequit
[00:23:41 CEST] <nevcairiel> the ffmpeg $work uses only has 2 patches right now =p
[00:23:43 CEST] Action: Compn wonders how many devs Daemon404 has made ragequit
[00:23:49 CEST] <Daemon404> afaik, just him
[00:23:51 CEST] <Compn> k
[00:23:54 CEST] <Daemon404> and that wasnt solely me.
[00:24:02 CEST] <Compn> i dont doubt wm4 was a party :P
[00:24:03 CEST] <Compn> ehe
[00:24:09 CEST] <Daemon404> and i dont think anything of value was lost
[00:24:09 CEST] <Daemon404> >.>
[00:24:11 CEST] <wm4> ?
[00:25:10 CEST] <Compn> oh i thought i didnt reply to the smb thread
[00:25:13 CEST] <Compn> but it appears i did .
[00:25:26 CEST] <Compn> ah yes my googletv with no shell. how useful that is.
[00:25:42 CEST] <Compn> also kodi/xbmc not ported to gtv for api reasons
[00:26:11 CEST] Action: Compn crawls back under his rock
[00:26:24 CEST] <Daemon404> nevcairiel, i think it would be better for me if i stopped caring about the libs...
[00:26:31 CEST] <Daemon404> just update my api usage
[00:26:37 CEST] <Daemon404> and let libavgarbagedump build up
[00:26:41 CEST] <Daemon404> as long as it links.
[00:27:01 CEST] <wm4> whatm you don't appreciate the opencl support?
[00:27:11 CEST] <wm4> s/m/,/
[00:27:17 CEST] <Daemon404> opencl unsharp mask is very important 
[00:28:19 CEST] <Compn> you just wait.... universal opencl is right around the corner! in the year 2020! 
[00:28:26 CEST] <Compn> pffft
[00:29:17 CEST] <Compn> i would like to see a diff (or just summary diff) that removes all "things Daemon404 does not like" from ffmpeg. it would be interesting.
[00:29:31 CEST] <Daemon404> rm -rf libavdevice
[00:30:06 CEST] <Compn> as i dont use any of that, i agree.
[00:30:12 CEST] <Daemon404> Compn, you do understand there is such a thing as software design right?
[00:30:17 CEST] <wm4> for a start, I'd kill all deprecated APIs
[00:30:32 CEST] <Compn> but people do like to screen record and capture tv devices...
[00:30:36 CEST] <wm4> and then I'd stab elenril to finish his work
[00:30:44 CEST] <Daemon404> Compn, sure, but it doesnt belong where it is
[00:30:50 CEST] <Daemon404> and tehre are better libraries and tools.
[00:30:58 CEST] <Compn> Daemon404 : i agree with you and you still mad :(
[00:31:02 CEST] <Daemon404> you wouldnt put a pickerel inside a tasty cake
[00:31:07 CEST] <Daemon404> same idea.
[00:31:13 CEST] <jamrial> Daemon404: many people can program, not many people can design
[00:31:16 CEST] <jamrial> so things happen
[00:32:30 CEST] <Compn> i still dont get how libavdevice affects you negatively though
[00:32:31 CEST] <Daemon404> jamrial, some people would have you believe you should only review the code
[00:32:40 CEST] <Daemon404> if someone took the time to code it, it should be merged, of course.
[00:32:49 CEST] <Daemon404> review of the idea itself or design is discourage.
[00:32:51 CEST] <Daemon404> d
[00:33:23 CEST] <Daemon404> does this sink need a 16-arm rotation dildo?
[00:33:25 CEST] <Daemon404> probably not.
[00:33:29 CEST] <Daemon404> but someone may find it useful.
[00:33:31 CEST] <Daemon404> better add it.
[00:33:40 CEST] <Daemon404> /rant
[00:33:42 CEST] <Compn> ffmpeg* we have all the dildos.
[00:34:19 CEST] <Compn> its first to 1million LOC really
[00:34:25 CEST] Action: Compn awaits the day
[00:34:30 CEST] Action: Daemon404 cools his thrusters/buffers
[00:34:32 CEST] <Daemon404> too much rant for one day
[00:34:51 CEST] Action: Daemon404 has probably offened too many people today for his quota
[00:35:00 CEST] <gnafu> Daemon404: And that'
[00:35:04 CEST] <gnafu> s saying something!
[00:35:08 CEST] <gnafu> ;-)
[00:35:40 CEST] <wm4> anyway, I still wish we could give this guy something reasonable to work on, so that I don't have to feel like the asshole I am
[00:35:56 CEST] <Daemon404> no need to feel like an asshole
[00:36:01 CEST] <Daemon404> i took that burden for you
[00:36:07 CEST] <wm4> heh
[00:37:13 CEST] <Daemon404> come to think of it.
[00:37:28 CEST] <Daemon404> didnt i scare away that guy who wrote a 2nd (or 3rd?) dts-hd ma decoder?
[00:37:38 CEST] <Daemon404> maybe it's best i restrain myself from replying.
[00:38:09 CEST] <wm4> you mean foox86, or the guy who wrote the recent ffmpeg patches?
[00:38:13 CEST] <Daemon404> no
[00:38:17 CEST] <Daemon404> the other guy.
[00:38:17 CEST] <nevcairiel> the other guy
[00:38:20 CEST] <nevcairiel> what was his name
[00:38:23 CEST] <wm4> there was one? oh
[00:38:42 CEST] <nevcairiel> marcus johnson?
[00:38:46 CEST] <Daemon404> yeah.
[00:38:59 CEST] <nevcairiel> he recently appeared on the dcadec issue tracker and wanted to contribute a missing feature
[00:39:03 CEST] <nevcairiel> i wonder if that ever happens
[00:39:03 CEST] <wm4> ah, I think I remember
[00:39:31 CEST] Action: Daemon404 is probably too much of an aggressive asshole to send mails to new contribs
[00:39:59 CEST] <nevcairiel> we honestly dont need a 3rd incomplete decoder though
[00:40:10 CEST] <nevcairiel> the avcodec decoder is already broken enough
[00:40:46 CEST] <nevcairiel> i'm just happy that dcadec seems to be coming along quite nicely
[00:40:59 CEST] <Daemon404> has it been fuzzed/
[00:41:09 CEST] <nevcairiel> dunno
[00:41:22 CEST] <Daemon404> i'd be wary of setting it as the default dts decoder unless it has
[00:41:42 CEST] <nevcairiel> cant be worse than the half finished dca-xll thing we have now
[00:41:45 CEST] <Compn> muh 1000 fuzzed bugs
[00:41:54 CEST] <Daemon404> 1000 is too low
[00:42:01 CEST] <Daemon404> j00ru disapproves
[00:42:06 CEST] <nevcairiel> but if you were to fuzz it and report crashes to the author, he would probably fix them rather quickly
[00:42:14 CEST] <nevcairiel> he usually reacted quite quickly
[00:42:27 CEST] <nevcairiel> i think jamrial reported some  usan results and whatnot
[00:42:38 CEST] <Daemon404> he seemed to port from D to C in record time
[00:42:40 CEST] <Daemon404> initially
[00:43:00 CEST] <Compn> i dont get why we dont just track each function and then set assertion upper and lower bounds. but thats because i'm not a programmer
[00:43:26 CEST] <wm4> oh, I remember my first rwaction, it was basically "wow you did something nobody did, too bad it's useless because it's in FUCKING USELESS D" (dramatization)
[00:43:36 CEST] <wm4> and then he ported it to C
[00:43:58 CEST] <Daemon404> and you felt like a dick?
[00:44:10 CEST] <nevcairiel> isnt D a OO language? sounds like he must've re-written lots of it
[00:44:13 CEST] <jamrial> trolling worked in that case
[00:44:35 CEST] <wm4> Daemon404: of course, but whatever
[00:44:49 CEST] <Daemon404> also
[00:44:50 CEST] <wm4> nevcairiel: yes, still pretty C/C++-like though
[00:45:00 CEST] <Daemon404> i really should not send angry mails at 10+ PM
[00:45:05 CEST] <Daemon404> bad idea is bad.
[00:45:07 CEST] <nevcairiel> nonsense
[00:45:19 CEST] <nevcairiel> you should not send angry mails when shitfaced, but late is fine!
[00:45:37 CEST] <Daemon404> but then i may be left hanging till the next day ;)
[00:46:22 CEST] <Daemon404> ruins a nigth and my morn
[00:47:55 CEST] <wm4> I can confirm that trolling at night is not ideal
[00:48:18 CEST] <baptiste> Daemon404, you're full of shit
[00:48:33 CEST] <nevcairiel> i think we established that earlier
[00:49:01 CEST] <Compn> oh snap. its on
[00:50:33 CEST] <wm4> more like time to go to sleep
[00:51:31 CEST] <Daemon404> baptiste, eh, you get lots of requests quite often for mainline features
[00:51:40 CEST] <Daemon404> which are nontrivial to backport
[00:51:45 CEST] <Daemon404> that is what i refer to.
[00:53:53 CEST] <baptiste> you could say zlib is rotting as well
[00:54:22 CEST] <Daemon404> zlib doesn't have something it wad forked off of, which people, with regularity, show up to ask for thinsg from
[00:54:27 CEST] <Daemon404> s/wad/was/
[00:55:05 CEST] <Compn> quick Daemon404 , use this http://video.stackexchange.com/questions/14727/what-is-the-difference-between-ffmpeg-and-ffmbc-now
[00:55:07 CEST] <Compn> :P
[00:55:16 CEST] <Daemon404> i dont read stackexchange
[00:56:32 CEST] <Daemon404> zlib also doesnt lack tons of CVEs which have been patched elsewhere, as well
[00:56:41 CEST] <Daemon404> CVE patches*
[00:57:04 CEST] <baptiste> yes but I'm not sure how that's relevant to the rotting factor, I was using zlib as a reference for software with a stable release more than 2 years old
[00:57:19 CEST] <baptiste> but used quite a bit
[00:57:33 CEST] <Daemon404> a stable release is one thing
[00:57:52 CEST] <cone-309> ffmpeg 03Vittorio Giovara 07master:5c018ee18895: DirectDraw Surface image decoder
[00:57:53 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:ff68b83968cb: Merge commit '5c018ee18895f88e9e1d2174059dcdd48bf872d2'
[00:57:54 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:21d2e3d602dc: avcodec/dds: Fix palettes on big endian
[00:57:54 CEST] <Daemon404> but zlib tends to e.g. patch security issues
[00:57:59 CEST] <Daemon404> when they arise
[00:58:25 CEST] <Daemon404> baptiste, the problem i see is that ffmbc waited too long to rebase
[00:58:38 CEST] <Daemon404> making it pretty damn hard now if one wanted to cut a new stable release from it
[00:59:06 CEST] <Daemon404> so it's kind of stuck without some requested things.
[01:00:16 CEST] <baptiste> possibly, I think my biggest question is do I need to get the 75% cruft for the 25% amazing things that went in lately ?
[01:00:56 CEST] <baptiste> I can backport the hevc decoder, most filters and multi frame encoding
[01:03:26 CEST] <Daemon404> backporting may be a bit harder due to reference counting
[01:03:33 CEST] <Daemon404> (i would argue reference counting is major, but i dont think you intend ffmbc to be used via API)
[01:04:19 CEST] <Daemon404> i, personally, and not comfortable using something large, with a lot of CVEs filed, maintained by a single person
[01:04:27 CEST] <Daemon404> not in a prod env, anyway.
[01:10:01 CEST] <baptiste> anybody reasonable runs ffmpeg in a sandbox :)
[01:10:17 CEST] <baptiste> the problem being all the CVEs not filed
[01:10:23 CEST] <Daemon404> well yes
[01:10:46 CEST] <Daemon404> the bus factor would still make me uncomfortable, though
[01:10:51 CEST] <baptiste> with docker, it's very straigthforward these days
[01:11:04 CEST] <Daemon404> docker isnt exactly 100% sandboxed
[01:11:08 CEST] <Daemon404> just mostly.
[01:11:12 CEST] <Daemon404> (i do use it)
[01:13:11 CEST] <baptiste> well bus factor is an issue, if work is important it will be picked up, I've seen bus factor happening in companies, and they always survive :)
[01:13:38 CEST] <Compn> Daemon404 : then whats your opinion of ffmpeg, maintained by one person.. (ohhhhhhhh)
[01:13:56 CEST] <Daemon404> Compn, a lot of work done by one person, but there are multiple people
[01:14:02 CEST] <Daemon404> and a very active mailing list full of people
[01:14:15 CEST] <Daemon404> some of whom understand the internals quite well.
[01:16:14 CEST] <Daemon404> i couldnt use ffmbc anyway
[01:16:19 CEST] <Daemon404> it oesnt fit my usecase at all
[01:16:34 CEST] <Daemon404> s/case/cases/
[01:17:20 CEST] <baptiste> it's specialized on purpose :)
[01:17:57 CEST] <Daemon404> fyi, one thing i see request a lot is audio filters
[01:18:00 CEST] <Daemon404> for ffmb.
[01:18:05 CEST] <Daemon404> probably the most common thing
[01:18:31 CEST] <Daemon404> i dont think ffmbc imported lib**resample
[01:19:41 CEST] <baptiste> good point
[01:21:21 CEST] <Daemon404> wm4, the student seems like a reasonable person
[01:44:49 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:2de6d13622bc: Changelog: Move HAP to the correct section
[01:49:53 CEST] <BBB>  durandal_1707 ty for the db values (thats what I mainly use, so Im very happy with it now)
[01:55:23 CEST] <Daemon404> a reasonable mail from reynaldo.
[01:55:39 CEST] <Daemon404> night e-mailing is bad for me (and others around me).
[01:56:12 CEST] Action: Daemon404 sleep 28800
[01:56:33 CEST] <BBB> g'nite
[01:57:01 CEST] <Daemon404> nite.
[02:00:35 CEST] <BBB> durandal_1707: and for stupidity sake, lets say I just wanted to reproduce tiny_ssim, would it be ffmpeg -i file.mkv -filter_complex movie=ref.y4m[main];[main][ref]ssim=stats_file=/dev/stdout[out] -f null -nostats -v error -?
[02:00:48 CEST] <BBB> (and then I guess tail -1 to get just the summary line)
[02:17:19 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:8575d960fea6: tests/fate/image: also run fate-sgi for the fate-image target
[03:36:05 CEST] <cone-309> ffmpeg 03Stephan Vedder 07master:b368428fc0b5: avformat/electronicarts: Fixed ea_probe function to accept vp6a videos
[03:53:44 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:b64e70436e9c: avformat/mpegts: Use STREAM_TYPE_PRIVATE_DATA instead of 6
[05:21:34 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:7a4b8817fe34: avcodec/texturedsp: Add protective () to RGBA() macro
[05:21:35 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:abb833c5681b: swscale/rgb2rgb_template: Implement shuffle_bytes_0321_c and fix shuffle_bytes_2103_c on BE
[05:21:36 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:760435801822: swscale/rgb2rgb_template: Fix signedness of v in shuffle_bytes_2103_c()
[07:26:04 CEST] <cone-309> ffmpeg 03Niklesh 07master:813b2f0da3a7: movtextdec.c: Improve upon dynarrays and text_to_ass
[07:27:33 CEST] <rcombs> ubitux: sorry I missed you the other day; around now?
[09:20:31 CEST] <cone-309> ffmpeg 03Sebastien Zwickert 07master:c06fdacc3dc7: vda: unlock the pixel buffer base address.
[10:57:32 CEST] <nevcairiel> kierank: i dont suppose you have CEA 861.3 swimming around somewhere?
[11:00:06 CEST] <kierank> No idea what that is
[11:00:19 CEST] <nevcairiel> HDR metadata spec
[11:00:27 CEST] <nevcairiel> but i guess thats a no then :D
[11:48:12 CEST] Action: __gb__ wouldn't be swimming in one of the CEA pool :)
[11:48:16 CEST] <__gb__> (joke)
[11:49:01 CEST] <__gb__> nevcairiel, I will likely push a one-liner that fixes all the issues on my side -- don't know if you had a chance to test long-mode on ancient HW
[11:51:48 CEST] <nevcairiel> I don't have any such hardware anymore
[11:52:07 CEST] <nevcairiel> the oldest intel gpu i have is ivy
[11:55:46 CEST] <nevcairiel> i'll try to remember this if someone ever complains
[12:10:13 CEST] <wm4> spell checkers... in lavu...
[12:10:37 CEST] <nevcairiel> the concept that ffmpeg doesn't actually have to have all the features in the world is lost on some people
[12:12:22 CEST] <j-b> I request an emailer
[12:19:41 CEST] <Daemon404> ...
[12:19:48 CEST] <Daemon404> i am not going to reply to mr nicholas geoerge
[12:19:52 CEST] <Daemon404> that would only end badly.
[12:19:59 CEST] <nevcairiel> wait a few hours, then do it
[12:20:04 CEST] <Daemon404> no
[12:20:06 CEST] <nevcairiel> :D
[12:20:10 CEST] <Daemon404> history shows the man cannot be reasoned with
[12:20:14 CEST] <Daemon404> it is akin to arguing with a wall
[12:28:06 CEST] <wm4> fuck
[12:28:08 CEST] <wm4> I replied
[12:28:16 CEST] <wm4> and I will be accused of trolling
[12:28:25 CEST] <wm4> although I'm pretty sure I'm not
[12:31:57 CEST] <Daemon404> i think that's the least inflamatory mail i've ever read from you.
[12:34:01 CEST] <Daemon404> ^ kierank 
[12:34:28 CEST] <wm4> what's Y416, or do I not want to know?
[12:35:00 CEST] <BtbN> 16 bit stuff i think
[12:35:08 CEST] <nevcairiel> Y416 is very simple
[12:35:09 CEST] <wm4> "Packed, 4:4:4, 16-bit"
[12:35:16 CEST] <nevcairiel> its just AVYU
[12:35:18 CEST] <wm4> just 3*16bit?
[12:35:25 CEST] <wm4> ok, 4*16bit
[12:35:28 CEST] <wm4> sounds reasonable
[12:35:36 CEST] <Daemon404> well
[12:35:48 CEST] <Daemon404> i dont regard different packings as "colorspaces"
[12:35:51 CEST] <Daemon404> ;)
[13:00:40 CEST] <durandal_1707> BBB: you do not need to use tail and set file for ssim filter you only read stdout at end just like tiny_ssim 
[13:01:45 CEST] <Daemon404> shoulsnt it set metadata too?
[13:03:03 CEST] <durandal_1707> for last one it can't as that doesn't belong to frame metadata
[13:03:38 CEST] <durandal_1707> there needs to be some global metadata
[13:04:15 CEST] <Daemon404> theres no way to return global metrics? :/
[13:04:35 CEST] <Daemon404> i guess the call app cpuld calculate
[13:04:39 CEST] <Daemon404> calling*
[13:24:09 CEST] <efesto> Hi all
[13:24:21 CEST] <efesto> quesion about licensing
[13:24:28 CEST] <efesto> is any available for answers ?
[13:25:02 CEST] <efesto> I would like to understand if it's possible to include a library in ffmpeg
[13:35:33 CEST] <BBB> Daemon404: Id rather have a stupid app (think bash script)
[13:35:38 CEST] <BBB> like, something really stupid
[13:36:44 CEST] <durandal_1707> efesto: what library?
[13:39:44 CEST] <cone-309> ffmpeg 03Gwenole Beauchesne 07master:88325c2e0b63: vaapi_h264: fix RefPicList[] field flags.
[13:47:03 CEST] <efesto> Durandal_1707, I would like to evaluate the option of using OpenImageIO for the image reading
[13:48:18 CEST] <efesto> https://github.com/OpenImageIO/oiio
[13:53:24 CEST] <cone-309> ffmpeg 03Gwenole Beauchesne 07release/2.7:071d7f4e179a: vaapi_h264: fix RefPicList[] field flags.
[13:54:02 CEST] <[-T-]> gwenole, are you aound ?
[14:05:56 CEST] <__gb__> hi [-T-], sometimes, yes
[14:08:25 CEST] <[-T-]> cool
[14:08:55 CEST] <[-T-]> I saw you commit on vaapi
[14:09:06 CEST] <[-T-]> what about QSV, whould you be interested in working on it ?
[14:10:10 CEST] <BtbN> QSV is basicaly windows only
[14:10:43 CEST] <[-T-]> nooooo
[14:10:46 CEST] <[-T-]> it's not, at all :)
[14:11:38 CEST] <[-T-]> I do QSV h264 encoding in tvheadend using libav
[14:11:40 CEST] <[-T-]> it works great ...
[14:11:42 CEST] <[-T-]> https://software.intel.com/sites/default/files/Intel_Media_Developers_Guide_0.pdf
[14:11:45 CEST] <[-T-]> this is the API
[14:11:54 CEST] <nevcairiel> dont you need to buy that expensive linux SDK to even be able to run it on linuix
[14:11:58 CEST] <[-T-]> no
[14:12:00 CEST] <BtbN> yes
[14:12:05 CEST] <__gb__> there is a community edition available
[14:12:06 CEST] <[-T-]> there is a community release
[14:12:08 CEST] <__gb__> or soon to be available
[14:12:09 CEST] <[-T-]> free of charge
[14:12:26 CEST] <[-T-]> i use it and it works
[14:12:41 CEST] <[-T-]> MediaServerStudioEssentials2015R5.tar.gz
[14:12:55 CEST] <Daemon404> how does it differ from the paid one
[14:13:04 CEST] <BtbN> propably not allowed for commercial use
[14:13:06 CEST] <__gb__> no Intel Premier Support and that's it
[14:13:12 CEST] <[-T-]> yes, no support
[14:13:23 CEST] <BtbN> But iirc the QSV stuff on linux is another layer on top of libva
[14:13:24 CEST] <[-T-]> but it includes all the libs/patches + the mfx dipatcher
[14:13:34 CEST] <[-T-]> yes, it uses libva
[14:13:45 CEST] <[-T-]> what's the problem ?
[14:13:47 CEST] <Daemon404> the one thing i remember from my time working at intel: fuck libva
[14:14:01 CEST] <__gb__> BtbN, well, + another driver that does more things -- but the gaps should reduce :)
[14:14:22 CEST] <[-T-]> at the end, it works great for me
[14:14:36 CEST] <[-T-]> the encoding is fully accelerated
[14:14:47 CEST] <BtbN> I tried adding a libva based encoder to ffmpeg, but the libva encoding api is too painfull, i couldn't figure out how to do most stuff
[14:14:47 CEST] <nevcairiel> this whole discussion is lacking a point
[14:14:50 CEST] <Daemon404> last i checked, qsv encoding lacked some, uh, basic things
[14:14:54 CEST] <Daemon404> like workign ratecontrol
[14:14:57 CEST] <[-T-]> you need this change to use their dispatcher: https://trac.ffmpeg.org/ticket/4659#ticket
[14:15:25 CEST] <Daemon404> nevcairiel, true.
[14:15:29 CEST] <[-T-]> well I ask the encoder to use 1Mbit/s
[14:15:30 CEST] <[-T-]> and it does
[14:15:47 CEST] <[-T-]> what do you mean, it's lacking a point ?
[14:16:59 CEST] <[-T-]> BtbN: but the qsv encoder actually 'partially' works
[14:17:06 CEST] <[-T-]> at least with basic settings
[14:17:35 CEST] <[-T-]> and there are some patches aound to make the decoding work on libav
[14:17:58 CEST] <[-T-]> (for handbrake)
[14:18:01 CEST] <BtbN> libva decoding works fine in ffmpeg, for quite a while
[14:18:07 CEST] <BtbN> even the cli tool supports it now
[14:18:46 CEST] <__gb__> BtbN, you merged the ffmpeg parts, or is still in your branch?
[14:18:57 CEST] <[-T-]> can the decoded frames be reused ?
[14:19:14 CEST] <BtbN> Nothing mergeable, just trying to understand how to use the api.
[14:19:26 CEST] <BtbN> the most puzzling part is that you aparently have to generate large parts of the NAL bitstream yourself
[14:19:29 CEST] <__gb__> I meant for the cli part, not the encoding part :)
[14:20:02 CEST] <[-T-]> BtbN: if you have a patch I could try ...
[14:20:27 CEST] <BtbN> should work via the -hwaccel option, __gb__ 
[14:20:49 CEST] <[-T-]> h264_vaapi right ?
[14:21:06 CEST] <BtbN> no.
[14:21:23 CEST] <nevcairiel> we dont have CLI vaapi support, only vdpau, afaik
[14:21:39 CEST] <BtbN> oh, vda, not vaapi
[14:21:42 CEST] <BtbN> that's the mac thing iirc
[14:21:46 CEST] <nevcairiel> yes
[14:22:02 CEST] <BtbN> No, still missing then. Can be used through vdpau though
[14:22:07 CEST] <BtbN> there's a wrapper
[14:22:34 CEST] <[-T-]> so no vaapi decoding ?
[14:22:46 CEST] <BtbN> Install the vdpau wrapper and use that.
[14:23:08 CEST] <[-T-]> vdpau wrapper to do vaapi decoding ?
[14:23:20 CEST] <[-T-]> you mean the nvidia wrapper to do intel hw decoding ?
[14:27:22 CEST] <[-T-]> VDPAU hwaccel works by the way, even to do transcoding in tvheadend
[14:32:50 CEST] <durandal_1707> efesto: isn't it bsd licensed?
[14:33:33 CEST] <efesto> possibly
[14:33:42 CEST] <efesto> let me check
[14:34:08 CEST] <BtbN> vdpau can't do transcoding
[14:34:14 CEST] <efesto> Modified BSD License
[14:35:52 CEST] <efesto> I suppose that as long as the LGPL of ffmpeg is respected (releasing the sources) should not be a problem right ?
[14:36:41 CEST] <[-T-]> BtbN: it can decode the frames
[14:36:51 CEST] <[-T-]> and you can reencode them
[14:37:47 CEST] <[-T-]> i succesfully tested with tvheadend, decoding the frames with vdpau and reencode them with QSV
[14:38:14 CEST] <[-T-]> it takes 20% of CPU for a HD channel, from 1080i to 720p 1Mbit/s, on a core i7 4790k
[14:38:31 CEST] <[-T-]> the 20% are scaling, deinterlacign and probably a bit a memcpy
[14:38:55 CEST] <[-T-]> without vdpau, it takes aroun 35%cpu
[14:39:08 CEST] <BtbN> hwencoded 1Mbit/s 720p30 isn't realy a pleasant experience though
[14:39:29 CEST] <[-T-]> for a phone it's quite ok
[14:39:40 CEST] <BtbN> 480p would look better.
[14:39:57 CEST] <BtbN> lower resolution has less impact than the encoding artifacts on a higher one
[14:40:47 CEST] <[-T-]> yes .. but it's blurry
[14:41:20 CEST] <[-T-]> but anyway :)
[14:41:48 CEST] <[-T-]> with QSV, it's possible to do a full transcoding, including decoding/scaling/deint (and many more VPP) and encoding
[14:41:52 CEST] <[-T-]> it would be soooo great
[14:43:41 CEST] <BtbN> Well, use windows then, or get a nvidia card.
[14:43:46 CEST] <BtbN> Everything is ready there
[14:44:02 CEST] <BtbN> also, ffmpeg is not capable of a full hardware transcoding chain
[14:44:16 CEST] <BtbN> there will allways be a reasonable bit of cpu usage
[14:57:10 CEST] <[-T-]> BtbN: switching to windows does not seem to be the best solution ;) and i don't want to use vdpau because it wakes up my big ass GPU from sleep mode
[14:57:29 CEST] <[-T-]> everything is ready under windows for offline transcoding yes
[14:57:37 CEST] <[-T-]> i want live tv transcoding with tvheadend ...
[14:57:54 CEST] <BtbN> ffmpeg on windows supports dxva for decoding, and qsv and nvenc for encoding
[14:57:56 CEST] <[-T-]> but anyway, i don't get why it would be an issue to add proper QSV support in libav ?
[14:58:10 CEST] <[-T-]> ah ok
[14:58:20 CEST] <[-T-]> but tvheadend is linux only ...
[14:58:27 CEST] <[-T-]> and my server as well
[14:59:11 CEST] <BtbN> because there is(maybe soon was) no SDK available
[14:59:29 CEST] <BtbN> And i'm not realy a fan of an SDK that wraps over libva with some closed-source changes
[14:59:37 CEST] <BtbN> there already was something like that, libyami
[14:59:52 CEST] <BtbN> there even was a patch on the ml i think, it was rejected, because too many layers
[15:00:03 CEST] <[-T-]> there is an SDK now :) with open source examples 
[15:00:12 CEST] <BtbN> The SDK itself isn't open source
[15:00:20 CEST] <[-T-]> but I get you point about libva...
[15:00:29 CEST] <[-T-]> the SDK is only partially opensource yes :/
[15:00:44 CEST] <[-T-]> the is one library that is closed source
[15:00:45 CEST] <BtbN> And i don't expect it to be packaged
[15:00:54 CEST] <[-T-]> but so is nvidia nvenc
[15:01:24 CEST] <[-T-]> and QSV support is already partially inside ffmpeg
[15:01:29 CEST] <wm4> amazing how much they hate open source, and how much we're trying to please them anyway
[15:01:32 CEST] <[-T-]> so either you completely remove it
[15:01:39 CEST] <[-T-]> or improve it
[15:01:44 CEST] <[-T-]> don't you think ?
[15:02:11 CEST] <[-T-]> wm4: yes it's a shame, but at least they made a step forward
[15:03:36 CEST] <[-T-]> the only 2 binary only files are libmfxhw64.so and iHD_drv_video.so
[15:04:58 CEST] <BtbN> it also comes with a personal libva iirc
[15:06:25 CEST] <[-T-]> sources are included
[15:08:25 CEST] <BtbN> Great, nvenc at least just comes with the binary nvidia driver and is packaged that way...
[15:09:29 CEST] <BtbN> I realy wonder what's up with the hw encoder interface in libva. Instead of fixing it, it gets wrapped, multiple times
[15:09:38 CEST] <[-T-]> actually, it just comes with libva-1.3.1.tar.bz2 and a small patch
[15:09:43 CEST] <[-T-]> that you don't have to use
[15:09:58 CEST] <Daemon404> BtbN, thats the enterprise way of coding
[15:10:03 CEST] <Daemon404> every problem is solved with abstraction
[15:11:42 CEST] <[-T-]> that said, as QSV is already partially in, would you be against new additions ?
[15:11:55 CEST] <[-T-]> like proper decoding and video post processing ?
[15:12:32 CEST] <BtbN> QSV is targeted at the windows implementation, it just happens to work with the wrapper on linux
[15:19:49 CEST] <BtbN> __gb__, is that new community SDK available somewhere already?
[15:20:53 CEST] <Daemon404> https://software.intel.com/en-us/intel-media-server-studio
[15:20:55 CEST] <Daemon404> i think it's in this>
[15:21:02 CEST] <Daemon404> intel is never very clear where things are.
[15:21:11 CEST] <BtbN> isn't that the old paid one?
[15:21:24 CEST] <Daemon404> there is a community edition listed
[15:21:32 CEST] <BtbN> hm, wants me to register
[15:21:38 CEST] <Daemon404> of course.
[15:21:40 CEST] <Daemon404> BigCorps
[15:21:52 CEST] <BtbN> So no distribution packages for it, great.
[15:22:03 CEST] <Daemon404> :D
[15:22:16 CEST] <BtbN> And also no interest from me, as i don't feel like registering.
[15:23:38 CEST] <BtbN> oh, there's also a HEVC de and encoder in there
[15:23:46 CEST] <BtbN> but only in the 4000$ version
[15:23:47 CEST] <Daemon404> only on select hw
[15:25:44 CEST] <__gb__> unless the server reminded about my public IP, there is a link to directly download the community edition (wget'able) -- you should try yourself :)
[15:27:07 CEST] <__gb__> no specific license key received by e-mail, so it would probably work as is
[15:27:25 CEST] <__gb__> no tried yet, still download for the next hour
[15:33:39 CEST] <[-T-]> BtbN: hold one, i ll host it for you
[15:34:21 CEST] <BtbN> I want to package it for gentoo, that's not realy possible if you have to register for it
[15:38:23 CEST] <__gb__> I think registration is requested as a means to acknowledge the license terms to the proprietary parts
[15:38:35 CEST] <__gb__> how is this done for amd & nvidia drivers on the gentoo side?
[15:38:48 CEST] <[-T-]> any idea where i could host the file ?
[15:39:15 CEST] <BtbN> __gb__, https://developer.nvidia.com/nvidia-video-codec-sdk
[15:39:24 CEST] <BtbN> The download link says "Agree and Download SDK for Windows and Linux"
[15:39:41 CEST] <BtbN> and points straight to the zip file
[15:40:11 CEST] <BtbN> The SDK is kinda strange though, important api headers and libs are hidden within examples
[15:40:15 CEST] <__gb__> so, on the gentoo side, the user is given a chance to read through the license terms and continue on if ok?
[15:41:05 CEST] <BtbN> Yes, ebuilds have the ACCEPT_LICENSE system. Unless someone puts a * there, which indicates he doesn't care about licenses, he'll have to accept the license.
[15:41:26 CEST] <BtbN> But i'll only put it in my personal overlay for the time beeing anyway
[15:47:07 CEST] <[-T-]> https://mega.nz/#!nt0AkApB!2tgaY0O-aQBDimPBf4XsNqslZLAOeHO8z0fzKOAO6SY
[15:47:09 CEST] <[-T-]> here it is
[15:50:38 CEST] <__gb__> [-T-], don't do that, and if you look/guess well, there is a wget'able link that doesn't require registration
[15:51:43 CEST] <__gb__> BtbN, please follow the conventional process, though point taken, I will talk to a few people to know when this can be improved
[15:52:41 CEST] <BtbN> [-T-], i'd take the file down, just to be safe.
[15:54:03 CEST] <BtbN> __gb__, ok, i'm quite short on time at the moment anyway
[15:54:51 CEST] <[-T-]> ok ok sorry
[15:55:19 CEST] <[-T-]> done
[16:37:29 CEST] <philipl> nevcairiel: Around? Can I convince you to look at the vdpau/hevc patch on the list?
[17:12:40 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:9f997acdd003: avcodec/texturedspenc: Add () to protect macro / argument evaluation order
[17:23:09 CEST] <BBB> durandal_1707: I think separate filters is fine, as long as its trivial (maybe give examples) to combine the two filters for people that want both ssim as well as psnr
[17:23:16 CEST] <BBB> durandal_1707: (like, I wouldnt know how to do that)
[17:24:58 CEST] <durandal_1707> note that numbers are slightly different between filter and tiny_ssim
[17:25:58 CEST] <durandal_1707> filter one is from libvpx
[17:35:04 CEST] <BBB> oh, hm...
[17:35:10 CEST] <BBB> I think you want to use the ones from tiny_ssim
[17:35:28 CEST] <BBB> loren wrote it and I trust him to do something sane
[17:35:38 CEST] <BBB> how far apart are they?
[17:43:45 CEST] <ubitux> BBB: ffmpeg -i a.mkv -i b.mkv -lavfi ssim=bla.log -f null -
[17:43:49 CEST] <ubitux> doesn't work?
[17:44:30 CEST] <BBB> oh
[17:44:34 CEST] <BBB> I didnt know that worked
[17:44:46 CEST] <BBB> (Im not familiar with the syntax at all :) )
[17:45:43 CEST] <ubitux> -lavfi is an alias to -filter_complex (idr if there are slight differences, but if so probably few)
[17:46:07 CEST] <BBB> ah cool
[17:46:08 CEST] <BBB> very nice
[17:46:24 CEST] <ubitux> so it guesses the number of inputs at least
[17:46:27 CEST] <ubitux> iirc
[17:47:32 CEST] <rcombs> ubitux: *poke*
[17:48:03 CEST] <ubitux> rcombs: hey :)
[17:48:05 CEST] <ubitux> sorry :)
[17:48:14 CEST] <rcombs> IRC handshake complete; proceeding with payload
[17:48:27 CEST] <Daemon404> kinky
[17:48:32 CEST] <ubitux> @_@
[17:48:35 CEST] <durandal_1707> BBB: but tiny_ssim is not lgpl
[17:48:38 CEST] <rcombs> ubitux: so, right now ass_split sends \h through unchanged as \h, and {comments} through as {comments}
[17:49:04 CEST] <BBB> durandal_1707: oh
[17:49:05 CEST] <BBB> hm
[17:49:10 CEST] <rcombs> ubitux: this is quite strange for e.g. WebVTT, which supports neither of those constructs, and would result in the literal strings "\h" and "{comments}" being displayed onscreen
[17:49:18 CEST] <Daemon404> xiph's is more liberally licenses
[17:49:20 CEST] <Daemon404> but slow.
[17:49:20 CEST] <BBB> durandal_1707: loren wrote it, I think, maybe ask him?
[17:50:00 CEST] <ubitux> rcombs: ah, undesirable
[17:50:09 CEST] <rcombs> ubitux: the FATE test for this (which involves demuxing an SRT) seems to explicitly expect this behavior
[17:50:12 CEST] <BBB> durandal_1707: you know what, just ignore me then. Im sure its fine if the values are similar'ish
[17:50:32 CEST] <BBB> gnafu wont be seen for 2 weeks <evil grin>
[17:51:28 CEST] <rcombs> ubitux: see e.g. line 155 of fate-suite/sub/SubRip_capability_tester.srt
[17:52:32 CEST] <ubitux> rcombs: this is in srt
[17:52:45 CEST] <ubitux> if you have {foo} in a srt, you want to display it
[17:52:54 CEST] <ubitux> if you have {foo} in a .ass you don't want to display it
[17:53:02 CEST] <rcombs> ass_split doesn't know the difference
[17:54:10 CEST] <rcombs> and are non-breaking spaces actually expressed as "\h" in SRT? Like, do players support that?
[17:54:53 CEST] <rcombs> (WebVTT certainly doesn't, and that's the fate test that's failing on me right now [with my patch that adjusts ass_split to assume input is ASS and output is not-ASS])
[17:55:09 CEST] <rcombs> see https://gist.github.com/fafe6d4026d6e01aa98f
[17:55:59 CEST] <ubitux> wait, just one at a time
[17:56:01 CEST] <ubitux> first the { }
[17:56:10 CEST] <rcombs> sure
[17:56:32 CEST] <ubitux> in vtt <-> srt, if you have { } it should stay as is in the output
[17:56:43 CEST] <rcombs> seems reasonable
[17:56:52 CEST] <rcombs> but then again, same applies to {\}
[17:57:09 CEST] <ubitux> if you have { } in the .ass, it should disappear or call a special callback for the srt/vtt enc
[17:57:27 CEST] <ubitux> same way, \{ \} in ass should become { } in ass/vtt
[17:57:36 CEST] <ubitux> do we agree with that?
[17:57:38 CEST] <rcombs> no
[17:57:45 CEST] <rcombs> there is no way to escape {}s in ass
[17:58:07 CEST] <ubitux> i thought i made that possible
[17:58:13 CEST] <ubitux> so you can't display {hello} in ASS?
[17:58:15 CEST] <rcombs> nope
[17:58:36 CEST] <ubitux> well then less work to do
[17:58:45 CEST] <ubitux> what if you have { } in srt
[17:58:54 CEST] <ubitux> how should it be converted to ass?
[17:59:05 CEST] <rcombs> that's the tricky part
[17:59:09 CEST] <rcombs> it kinda depends on the player
[17:59:50 CEST] <rcombs> some players (VSFilter or some ass_split-based stuff) will display ASS tags in SRT
[18:00:06 CEST] <rcombs> I think VSFilter also parses MicroDVD color codes in SRT
[18:00:14 CEST] <rcombs> there's no real spec for what the "right" behavior there is
[18:01:39 CEST] <durandal_1707> pengvado: is it ok to relicense tiny_ssim to lgpl?
[18:02:28 CEST] <ubitux> rcombs: ok well; so what behaviour is not correct currently in your opinion regarding {} convertion?
[18:02:53 CEST] <rcombs> biggest thing is that {comments} in ASS are passed through as text
[18:03:03 CEST] <ubitux> alright
[18:03:10 CEST] <ubitux> should we introduce a "comment" callback then?
[18:03:13 CEST] <ubitux> just like other markups?
[18:03:53 CEST] <rcombs> it's kinda dicey
[18:03:54 CEST] <wm4> rcombs: yes to MicroDVD
[18:04:00 CEST] <wm4> and there are srt subs with microdvd tags
[18:04:11 CEST] <rcombs> because you can have comments and tags in the same {block}
[18:04:32 CEST] <ubitux> rcombs: well, the decoder needs to handle that :)
[18:04:43 CEST] <rcombs> ubitux: also, apparently libass does allow {} to be escaped, but VSFilter does not
[18:04:54 CEST] <ubitux> yes i added the code in libass for that :p
[18:05:43 CEST] <rcombs> kinda sketchy
[18:08:14 CEST] <rcombs> probably the safest thing to do would be to treat anything unknown inside a {} as an unknown tag, and pass it to the encoder as such
[18:08:52 CEST] <wm4> rcombs: yes, it is sketchy... it breaks existing subs
[18:09:09 CEST] <rcombs> :/
[18:09:31 CEST] <rcombs> has anyone ever actually wanted to use {}s literally in subtitles?
[18:09:53 CEST] <wm4> also see https://code.google.com/p/xy-vsfilter/issues/detail?id=149
[18:10:39 CEST] <rcombs> that first comment
[18:10:40 CEST] <rcombs> > rare
[18:10:48 CEST] <rcombs> was that rare at some point?
[18:11:06 CEST] <wm4> *shrug*
[18:15:54 CEST] <Plorkyeran> the "rare" case would be a comment with \ before it
[18:16:28 CEST] <Plorkyeran> which almost certainly is basically nonexistent
[18:16:48 CEST] <rcombs> wm4: you said it broke existing subs?
[18:17:14 CEST] <rcombs> (I'd also say "this seems surprising" if I hadn't been wrong about that on every other occasion)
[18:17:21 CEST] <wm4> I had one such a case
[18:17:25 CEST] <wm4> not sure if I can find it
[18:17:31 CEST] <wm4> (does anyone have a regexp handy)
[18:17:50 CEST] <rcombs> '\\\{'?
[18:21:12 CEST] <wm4> seems like gstreamer is much better at generating subtly broken files than ffmpeg
[18:22:05 CEST] <rcombs> kek
[18:23:02 CEST] <wm4> `Dialogue: 0,0:08:45.10,0:08:46.60,Blackboard,,0000,0000,0000,,{\an8\fs22\frz1\fnJanieHmkBold\c&HCCD3CF&\pos(434,4)}Your vote changes the future of the country\NNational debt {\fnYen\fs12}\{\fnJanieHmkBold\fs22}550,000,000,000,000`
[18:23:08 CEST] <wm4> is this it?
[18:26:02 CEST] <rcombs> oh hah
[18:26:14 CEST] <rcombs> I forgot about that particular bit of Windows idiocy
[18:26:28 CEST] <rcombs> putting ¥ on \
[18:26:37 CEST] <Plorkyeran> w
[18:26:44 CEST] <Plorkyeran> that one's totally my fault isn't it
[18:27:16 CEST] <rcombs> blame VSFilter for not having decent escape mechanisms to begin with
[18:28:06 CEST] <Plorkyeran> well I mean my fault as in I typeset that and used a font where \ was a yen character rather than an actual yen character for some reason
[18:29:06 CEST] <rcombs> oh hah
[18:29:16 CEST] <rcombs> well yeah that's on you then :P
[18:29:40 CEST] <cone-309> ffmpeg 03James Almer 07master:910eeab48026: swscale/x86/rgb2rgb_template: add missing xmm clobbers
[18:29:41 CEST] <cone-309> ffmpeg 03James Almer 07master:0c15f2f158e1: swscale/x86/rgb2rgb_template: don't call emms on sse2/avx functions
[18:29:42 CEST] <cone-309> ffmpeg 03James Almer 07master:e22edbfd4132: swscale/x86/rgb2rgb_template: fix signedness of v in shuffle_bytes_2103_{mmx,mmxext}
[19:24:28 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:0416b5e0330c: avcodec/jpeg2000dwt: Replace /2 by >>1
[19:38:13 CEST] <wm4> michaelni: why didn't you just make i unsigned?
[19:41:06 CEST] <michaelni> some of the computation that involve it can be negative
[19:46:51 CEST] <wm4> wouldn't >> be UB on them
[19:54:22 CEST] <BBB> thats <<
[19:54:29 CEST] <BBB> see e.g. 27191b82de0b28ead9b3dcce5aaf1933087fd5fb
[19:56:31 CEST] <wm4> C is hard
[20:03:58 CEST] <cone-309> ffmpeg 03Rodger Combs 07master:94a43dcff1ea: lavf/brstm: add FATE tests for BFSTM and BCSTM files
[22:25:38 CEST] <rcombs> welp, looks like I need to write (or get someone to write) hevc_mp4toannexb
[22:26:00 CEST] <rcombs> though it seems like it'd be better to have that be handled at the muxer level, instead of requiring a filter?
[22:27:08 CEST] <JEEBsv> wouldn't that be quite similar to the avc one?
[22:27:22 CEST] <JEEBsv> I mean, they have added some parameter set types, but otherwise it should be quite similar
[22:27:26 CEST] <JEEBsv> since both use NALs
[22:28:06 CEST] <rcombs> yeah
[22:28:28 CEST] <rcombs> I don't really get why it's a bsf for avc
[22:29:02 CEST] <rcombs> the inverse conversion is handled by some demuxers
[22:29:16 CEST] <rcombs> erm, muxers
[22:29:33 CEST] <rcombs> (matroska and mov)
[00:00:00 CEST] --- Wed Jun 24 2015