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

[burek]

[00:06:42 CET] <jkqxz> philipl:  That file works for me on Skylake GT3 with 1.8.3 libva/i965.
[00:07:42 CET] <jkqxz> (With command line as above to make a single H.264 frame out of it.)
[00:08:16 CET] <jkqxz> Do you have a log?
[00:08:39 CET] <jkqxz> That might show more, since it is a 4:4:0 file.
[00:11:26 CET] <jkqxz> <https://0x0.st/sTCN.log> if the comparison helps you.
[00:12:18 CET] <philipl> will be a while before i can check but i will.
[00:17:16 CET] <nevcairiel> having a 4:4:0 jpeg that has 422 in the name sure sounds like a fun way to get confused :D
[00:21:09 CET] <jkqxz> Sure, no hurry.  It would be nice to resolve this sort of problem before pushing.
[00:21:35 CET] <jkqxz> nevcairiel:  It's 422-transpose.
[00:21:40 CET] <jkqxz> Intel even calls it 422V.
[00:37:08 CET] <atomnuker> peloverde: you might want to take a look at ^^
[00:38:16 CET] <nevcairiel> so is there even any valid ssr file  anywhere? =p
[00:39:31 CET] <atomnuker> sure, the thread has 2
[00:40:32 CET] <nevcairiel> all that complained about missing SSR support are basically invalid, since they use the gain control without the SSR audio object type
[00:41:37 CET] <peloverde> 99% of the time the SSR error happens because of bitstream desync
[00:43:49 CET] <peloverde> patch looks conceptually okay, I'd dump the stack array and skip_bits all the fields to make this less usable as an attack vector
[00:46:13 CET] <nevcairiel> the bit reads are pretty narrow and every possible value has a defined place in the array, not sure what could go wrong, but yeah outside of those few needed for further parsing, there isnt exactly a need to store them y et
[03:08:40 CET] <peloverde> Is the metadata that libavformat puts by default into rtmp streams expected to be interpreted by libavformat as subtitles?
[03:15:24 CET] <Compn> depends on the format
[03:15:35 CET] <Compn> :P
[04:43:14 CET] <philipl> jkqxz: http://paste.ubuntu.com/p/8f2SwW9sDj/
[04:43:18 CET] <philipl> What can I say?
[04:44:07 CET] <philipl> ARGH
[04:44:22 CET] <philipl> Stupid - was using the system ffmpeg and not the one I built.
[04:44:23 CET] <philipl> :-(
[04:45:13 CET] <philipl> jkqxz: works great now...
[04:46:51 CET] <philipl> (My primary machine is nvidia only, so I don't always remember how the intel one is configured)
[06:00:49 CET] Action: rcombs merges upstream
[06:00:50 CET] <rcombs> uh-oh
[06:01:04 CET] <rcombs> >dynamic codec registration removed
[06:01:08 CET] <rcombs> tfw I was using that
[06:02:55 CET] <rcombs> also lol @ this whole av_codec_iterate thing
[06:03:31 CET] <rcombs> why does it take a void*, as if one day it could ever be anything other than an int without having a free function
[06:03:37 CET] <rcombs> erm, void**
[08:39:21 CET] <nevcairiel> if you internally still had a linked list, it could be the AVCodec*
[08:39:56 CET] <nevcairiel> the point of that design was to at least allow both an array and a linked list as the possible implementations
[08:40:44 CET] <rcombs> I guess so
[08:41:35 CET] <rcombs> in the end, I'm adding a dynamically-registered-codecs array, and dispatching to that one in the iterate function when i >= (number of codecs in the main array)
[08:44:41 CET] <wm4> or you could just reserve static space
[08:45:18 CET] <gagandeep> kierank: i am having dificulty joining the mailing list
[08:45:39 CET] <rcombs> wm4: I guess that would work
[08:46:38 CET] <gagandeep> kierank: when i click on submit details filled on the page, it gives an error 
[08:49:39 CET] <gagandeep> guys i am having a problem joining the mailing list of ffmpeg-devel
[08:53:30 CET] <gagandeep> on clicking the subscribe button, it gives the page with the message "you must get the form before submitting it"
[08:57:41 CET] <wm4> gagandeep: did you enter your email address, and a password (including correct confirmation)?
[10:13:21 CET] <bogdanc> @kierank do you think both cineform bugs are actually the same issue? because outputing the given sample of the "interlaced output" to bmp still has the last 8 bottom pixels bugged
[10:51:08 CET] <bogdanc> i think it's something wrong with the Wavelet Transforms
[10:51:33 CET] <gagandeep> wm4: yeah, my email address is correctly entered and this time i left the password fields blank
[10:52:22 CET] <wm4> gagandeep: so you're subscribed now?
[10:54:26 CET] <gagandeep> wm4: after clicking the subscribe button, a new html page is generated saying 'subscription results: You must GET the form before submitting it'
[10:54:59 CET] <wm4> huh
[10:55:11 CET] <wm4> maybe ask one of the mailing list admins then... Compn, llogan
[10:55:59 CET] <nevcairiel> also perhaps try a different browser and/or disabling any script/ad blockers
[10:58:33 CET] <gagandeep> navcairiel: i have tried firefox and chrome, i don't think i was able to subscribe in any of my attempts as i have not recieved any mail confirmations from ffmpeg
[11:00:21 CET] <wm4> just tried it, seemed successful
[11:00:27 CET] <wm4> still waiting for the confirmation email
[11:00:58 CET] <wm4> and got it
[11:03:17 CET] <nevcairiel> i can only assume that something is causing the validation to fail, some browser addon that strips referes, or some weird network thing that causes requests to come from different  addresses, or something
[11:03:57 CET] <gagandeep> a'right i will look into it
[11:13:22 CET] <gagandeep> wm4: https://imgur.com/a/K8W1I
[11:13:34 CET] <gagandeep> wm4: it is the screenshot i am getting
[11:13:52 CET] <gagandeep> i have now mailed it also to the admin of mailing list
[11:13:53 CET] <wm4> I didn't get that screen, so something is going wrong there
[11:15:49 CET] <gagandeep> wm4: is there a certain condition on password creation?
[11:16:26 CET] <wm4> no, I didn't enter one and it generated one for me
[11:18:24 CET] <gagandeep> i have also tried subscribing by just entering my email.
[11:19:30 CET] <gagandeep> and also tried to resend password, hoping that if my mail had been already registered but, the resend password also didn't work so i definitely am not on the mailing list
[11:22:12 CET] <durandal_1707> Compn: what you did?
[11:22:48 CET] <gagandeep> wm4: are there activites going on the mailing list regarding gsoc?
[11:23:22 CET] <gagandeep> because i most probably am missing important information by not being on it.
[11:24:00 CET] <wm4> I don't see much, but you can always look at the archives
[11:24:14 CET] <wm4> e.g. http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/thread.html
[11:25:36 CET] <gagandeep> thanks, i also think that there are only patch related mails
[12:28:04 CET] <jkqxz> philipl:  Ouch, but that's a good answer (it's not all broken, yay!).
[12:29:14 CET] <JEEB> 725
[12:29:24 CET] <jkqxz> It doesn't look like anyone else has any interest, so if nothing else happens I'll push later today.
[12:29:34 CET] <wm4> interest in what?
[12:29:47 CET] <jkqxz> JPEG hwaccel.
[12:30:05 CET] <nevcairiel> jpeg hwaccel is just not very interesting, personally i even consider it a huge waste of time, and maybe even bytes!
[12:30:07 CET] <wm4> the only thing that looks potentially worrisome is format selection
[12:31:01 CET] <wm4> the cleverness might bite someone in the back
[12:31:06 CET] <wm4> but it's probably OK
[12:31:18 CET] <jkqxz> It has some cute uses with webcams (4K webcam works sensibly in non-streamcopy mode).
[12:32:30 CET] <wm4> yeah, sort of like mpeg2 hwdec sometimes helps
[12:33:24 CET] <wbs> or just for getting the decoded data right in the right formats for further processing
[12:39:29 CET] <jdarnley> Can someone tell me why vp8 and vp9 decoders (and some others) are still enabled when I use --disable-decoders --enable-decoder=dirac,rawvideo?
[12:39:52 CET] <wm4> jdarnley: probably hwaccels pulling them in
[12:40:17 CET] <wm4> hwaccels are auto-detected and then pull in decoders they depend on, at least that was a problem in the past
[12:40:23 CET] <jdarnley> right, many of those are still on
[12:40:24 CET] <wm4> you can disable autodetection completely
[12:42:04 CET] <jdarnley> I won't go that far
[12:42:08 CET] <jdarnley> --disable-hwaccels was enough
[12:43:57 CET] <jdarnley> that's better
[15:55:49 CET] <Compn> wm4 : erm, next time pls ask him for his email address
[15:56:06 CET] <Compn> durandal_1707 : next time please ask him for his email address
[15:56:09 CET] <Compn> makes subscribing easier
[15:56:37 CET] <Compn> i dont think my email is listed in the right spot for a ffmpeg-devel-admin mail to appear in my inbox
[15:57:14 CET] <wm4> well obviously whatever condition fails the registration to fail should be fixed
[15:57:48 CET] <Compn> did he check his mail spam dir ?
[15:58:21 CET] <Compn> and you tested and recieved the confirmation email, so it is working
[15:58:47 CET] <wm4> the page displayed after trying to register was different too
[15:59:47 CET] Action: Compn tries to subscribe
[16:00:00 CET] <Compn> ffmpeg-devel Subscription results page looks the same 
[16:00:24 CET] <Compn> ffmpeg-devel subscription email came in inbox
[16:00:29 CET] <Compn> works4me
[16:00:59 CET] <wm4> for me too
[16:01:02 CET] <Compn> used this page to subscribe http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[16:01:52 CET] <Compn> oh
[16:01:58 CET] <Compn> what web browser was he using ? 
[16:02:25 CET] <Compn> i ran into a person using some ancient lynx / elinks in #mplayer a few weeks ago who said trac didnt work in lynx/links
[16:02:39 CET] Action: Compn facepalms
[16:03:28 CET] <Compn> he posted a firefox screenshot
[16:03:32 CET] <Compn> well thats a pickle .
[16:03:41 CET] <Compn> gagan did i mean
[16:04:16 CET] <Compn> and said he tried chrome
[16:05:50 CET] <Compn> nevcairiel : the ffmpeg-devel subscribe form works without referers, just tested. 
[16:05:56 CET] <relaxed> elinks works here
[16:06:16 CET] <Compn> nevcairiel : also without javascript.
[16:06:46 CET] <relaxed> my elinks has javascript support, though
[16:06:57 CET] <nevcairiel> Compn: well it has to do some weird check on the server side
[16:07:00 CET] <Compn> i disable javascript in my old opera browser ehe
[16:08:23 CET] <Compn> nevcairiel : it was like his web browser was sending a http get in the wrong order. but he was using both chrome and firefox so 
[16:08:34 CET] <Compn> i'm kind of out of ideas without digging into the logs
[16:09:23 CET] <Compn> probably it was a hiccup on the server but i'm not sure either
[16:18:19 CET] <philipl> jkqxz: cool. push any time :-)
[18:58:22 CET] <daddesio> join #ffmpeg
[18:58:24 CET] <daddesio> whoops
[19:57:22 CET] <wm4> <lrusak> ldts, wm4: what do you think the best path forward for v4l2m2m is? using the AV_PIX_FMT_DRM_PRIME? or should I possibly pursue other avenues such as using the v4l2 userptrs or dmabuf and then create my own buffers <- I think it'd make most sense to make it use the drm hwcontext, but not sure
[19:57:36 CET] <wm4> also ping jkqxz
[20:01:16 CET] <ldts> I think using DRM_PRIME would make it a better ffmpeg citizen...using dmabuf and userptrs is better documented and easier to integrate IMHO. But lrusak already had something working so it is better if we build on it
[20:10:24 CET] <wm4> ldts: I'm wondering what exactly the differences and pros/cons are
[20:10:36 CET] <wm4> using DRM_PRIME sounds like the most flexible option to me
[20:15:05 CET] <lrusak> sounds good
[20:15:14 CET] <lrusak> I just need to figure out how to not break the cmdline utilities
[20:19:09 CET] <ldts> from the maintenance perspective, using AV_PIX_FMT_DRM_PRIME requires more ffmpeg domain knowledge (where as using dmabuf can be done with just some v4l2 generic expertise); I could have done dmabuf months ago but jkqxz disagreed (I think it was because what I was planing to implement was not a generic solution  that other clients could adopt); then right about that time DRM_PRIME was merged...so it makes sense
[20:19:09 CET] <ldts> that v4l2_m2m follows the more generic way of handling this use case
[21:05:14 CET] <wm4> am I wrong in my "discussion" with michaelni 
[21:05:25 CET] <wm4> actually I expect nobody cares or read that thread
[21:06:05 CET] <JEEB> I tried to read some of it
[21:06:29 CET] <JEEB> I must say that my client started showing the quoting wrong at some point so at that point I decided I'd do something less productive for a while
[21:06:37 CET] <JEEB> and I haven't gone back to it yet
[21:06:52 CET] <wbs> something less productive? now that's a feat :P
[21:07:02 CET] <JEEB> procrastination!
[21:13:48 CET] <atomnuker> yeah, I'm reading the thread
[21:43:48 CET] <_jamrial> wm4: turns out there's a helper for packet lists in lavf/utils.c, but it's not shared
[21:46:37 CET] <wm4> ah
[21:46:47 CET] <wm4> I think that might be what I remembered
[22:14:58 CET] Action: thardin commits the heinous crime of suggesting we stop NIH:ing mxfdec
[22:15:20 CET] <JEEB> thardin: welcome to the club :)
[22:15:31 CET] <JEEB> I've been wondering how easy/hard it would be to just link against libmxf
[22:15:45 CET] <JEEB> the thing's so darn complicated I don't think it really makes sense to try and duplicate the effort
[22:15:52 CET] <thardin> bmxlib I think it's called? or whatever. the b one
[22:16:06 CET] <JEEB> well yea, whichever was part of the project taht had the C API
[22:16:08 CET] <JEEB> I think?
[22:16:13 CET] <wm4> NIHing makes sense if you can do better and are ready to put in the effort
[22:16:26 CET] <nevcairiel> for mxf none of those conditions are true
[22:16:33 CET] <wm4> apparently
[22:16:35 CET] <JEEB> ayup
[22:16:49 CET] <thardin> it's BSD so we could just include it
[22:16:53 CET] <thardin> like a subtree merge if they use git
[22:16:54 CET] <JEEB> true
[22:17:10 CET] <nevcairiel> we dont like such shenanigans, just include it like any external library
[22:17:13 CET] <JEEB> yea
[22:17:43 CET] <durandal_1707> no
[22:17:50 CET] <durandal_1707> bad idea
[22:17:56 CET] <durandal_1707> dont do it
[22:18:08 CET] <JEEB> you don't care about MXF anyways :P
[22:18:23 CET] <durandal_1707> i do care
[22:18:23 CET] <wm4> yeah, and if want to make modifications to it that upstream doesn't accept or whatever, it should be a proper fork in its own git repo
[22:18:42 CET] <thardin> it would require downstream link that lib of course. but I expect maintainers smart enough to be able to add the appropriate --enable flag
[22:18:54 CET] <thardin> err packagers
[22:18:55 CET] <JEEB> yup
[22:19:06 CET] <durandal_1707> just add wrapper if want
[22:19:14 CET] <JEEB> that's what we're discussing
[22:19:16 CET] <JEEB> if you didn't notice
[22:19:18 CET] <thardin> durandal_1707: of course
[22:19:41 CET] <thardin> then put effort like support streaming playback from tape or whatever into that lib instead
[22:20:13 CET] <thardin> I'm susprised I got that KAG thing wrong
[22:20:35 CET] <thardin> one has to pour over every paragraph several times to reach enlightenment
[22:20:43 CET] <thardin> every paragraph of the spec
[22:20:45 CET] <thardin> specs
[22:21:00 CET] <thardin> because of course there's not only one
[22:21:12 CET] <durandal_1707> thats whole point of it
[22:21:16 CET] <wm4> one of those standards designed to drain consulting fees?
[22:21:24 CET] <thardin> wm4: indeed
[22:21:31 CET] <JEEB> wm4: yup
[22:22:05 CET] <thardin> not that there aren't some neat things in it
[22:24:17 CET] <cone-576> ffmpeg 03Mark Thompson 07master:265135298821: cbs: Allocate the context inside the init function
[22:24:18 CET] <cone-576> ffmpeg 03Mark Thompson 07master:d28eb0e34d80: Merge commit '2651352988212531038326c44754ece1728c4a3b'
[22:25:59 CET] <thardin> of course I can happily leave it to someone else to extract consulting fees for trying to polish it
[22:26:29 CET] <nevcairiel> seems totally warranted for a format like mxf which is only every going to get used commercially =p
[22:27:44 CET] <atomnuker> I am never ever buying another crappy arm board, an odroid c2 completely freezes if I link ffmpeg.c or even think about running a torrent client
[22:28:06 CET] <nevcairiel> why would you buy something that you describe as crappy anyway
[22:28:35 CET] <nevcairiel> i use a pi3 for that, and while its not the fastests, it works reliably for me
[22:28:36 CET] <atomnuker> I expected it to run properly, especially as it had all drivers fully upstreamed
[22:28:50 CET] <atomnuker> might just be archlinux arm messing up
[22:29:13 CET] <atomnuker> yeah, its probably that, another one I have has an uptime of months handling sshfs
[22:29:28 CET] <jkqxz> My XU4 dies instantly to libx264 and occasionally from compiling.  I think it's browning out in that case, limiting the CPU clock to 1GHz fixes it.
[22:29:28 CET] <nevcairiel> i run debian on it
[22:29:46 CET] <nevcairiel> power delivery concerns are often a problem
[22:30:02 CET] <nevcairiel> sometimes switching out the psu can already help
[22:30:46 CET] <thardin> I wonder why maksym doesn't just maintain his own fork instead of insisting on trying to get the gpl circumvention thing in
[22:31:45 CET] <nevcairiel> i personally like dynamic loading, it makes for more portable binaries, but if stuff is still nonfree anyway that doesnt really help you, because you cant distribute shit anyway =p
[22:32:19 CET] <thardin> uhm, what? just static link in that case
[22:33:08 CET] <nevcairiel> not everything can or should really do that
[22:33:23 CET] <cone-576> ffmpeg 03Mark Thompson 07master:1d12a545ce82: cbs: Add an explicit type for coded bitstream unit types
[22:33:24 CET] <cone-576> ffmpeg 03Mark Thompson 07master:cacb47633c04: Merge commit '1d12a545ce828eaf4fb37295400008ea37635ab8'
[22:33:27 CET] <nevcairiel> especially if its some big vendor sdk, they may not ship static libs
[22:33:45 CET] <thardin> ah, the old It Depends
[22:34:21 CET] <nevcairiel> or some graphics hardware stuff that comes with the driver, cant link against nvidia libraries on every system, they might use another gpu :D
[22:34:45 CET] <thardin> of course, but then you're using system libs
[22:34:59 CET] <nevcairiel> yeah thats a gpl exception anyway
[22:35:35 CET] <thardin> portability is somewhat theoretical of course
[22:36:48 CET] <cone-576> ffmpeg 03Mark Thompson 07master:254e728d207c: cbs: Minor comment fixes / cosmetics
[22:36:49 CET] <cone-576> ffmpeg 03Mark Thompson 07master:7dc8752e614a: Merge commit '254e728d207c173a3714e6a01c9d68fcb3af8b73'
[22:37:12 CET] <thardin> come to think of it, how the hell does the loader know what do load?
[22:37:35 CET] <thardin> the interdependence of different libraries on different versions can get exceedingly hairy
[22:38:03 CET] <thardin> I know glibc doesn't some clever thing
[22:38:18 CET] <jkqxz> Does ffmpeg guarantee that av_malloc() and friends will not return NULL when the size is zero?
[22:40:42 CET] <wm4>     if(!ptr && !size) {
[22:40:42 CET] <wm4>         size = 1;
[22:40:43 CET] <wm4>         ptr= av_malloc(1);
[22:40:43 CET] <wm4>     }
[22:40:45 CET] <wm4> apparently
[22:41:04 CET] <jkqxz> Yeah, I'm just finding that.  The other tine doesn't have it.
[22:41:29 CET] <jkqxz> Seems to come from 5a36783bc4a1887a67dbfe5ec7198903f35a46b1: "Fix all malloc(0) issues".
[22:41:56 CET] <wm4> also I'm disturbed that this calls itself recursively (not a real problem, but makes it harder to reason about)
[22:42:13 CET] <cone-576> ffmpeg 03Lou Logan 07master:d09368a40844: doc/ffmpeg: document -dn option
[22:42:58 CET] <wm4> yeah the old code looks better in that regard
[22:45:49 CET] <jkqxz> So kindof, but it still seems a bit naughty.  (The docs don't mention it at all.)
[22:46:02 CET] <jkqxz> I guess I'll merge the change avoiding it.
[22:47:37 CET] <cone-576> ffmpeg 03Jun Zhao 07master:c8e135ea9225: vaapi_encode: Allocate slice structures and parameter buffers dynamically
[22:47:38 CET] <cone-576> ffmpeg 03Mark Thompson 07master:fe1fb48e2bd1: Merge commit 'c8e135ea9225137050a6315fd9ba9c0f242c90b6'
[22:50:43 CET] <wm4> yeah the doxygen should definitely mention it
[22:52:06 CET] <cone-576> ffmpeg 03Mark Thompson 07master:216c44dfc172: vaapi_encode: Destroy output buffer pool before VA context
[22:52:07 CET] <cone-576> ffmpeg 03Mark Thompson 07master:9e3e9a37289c: Merge commit '216c44dfc17252ec0681dcb0bbeeb45a9d14eca7'
[22:54:24 CET] <cone-576> ffmpeg 03Mark Thompson 07master:67eb2b16daa7: vaapi_h265: Mark unused entries in RefPicList[01] as explicitly invalid
[22:54:25 CET] <cone-576> ffmpeg 03Mark Thompson 07master:f082dcab7cdf: Merge commit '67eb2b16daa77f6ba3e04a28ca18e53193723b7f'
[22:55:02 CET] <cone-576> ffmpeg 03Mark Thompson 07master:a3daecd63752: cbs: Demote the "decomposition unimplemented" warning
[22:55:03 CET] <cone-576> ffmpeg 03Mark Thompson 07master:1325ac4c93f2: Merge commit 'a3daecd6375279d9fdb863ac9db3545a33e97651'
[22:56:56 CET] <thardin> if only ffmpeg was written in ada, where you can have contracts on such things
[23:03:52 CET] <cone-576> ffmpeg 03Mark Thompson 07master:0e4c166cdd64: cbs_h2645: Remove active ps references when it is replaced
[23:03:53 CET] <cone-576> ffmpeg 03Mark Thompson 07master:af3727e2399d: Merge commit '0e4c166cdd6446522a085dd9731967d09ac71f72'
[23:10:57 CET] <cone-576> ffmpeg 03Mark Thompson 07master:13ca5d34ba5c: cbs_h264: Add hack for pic_timing with no active SPS
[23:10:58 CET] <cone-576> ffmpeg 03Mark Thompson 07master:b656fa710a34: Merge commit '13ca5d34ba5c473211daaae0a101123bcaada3e6'
[23:11:34 CET] <thardin> time to do a practice push with that documentation patch I mailed in a few days ago
[23:11:42 CET] <thardin> or, fate first
[23:26:28 CET] <philipl> durandal_1707: I've sent a new patch series for my colour range change. I dropped the new option type and copied your option definition instead.
[23:26:38 CET] <philipl> Hopefully we can get this in and then build from there.
[23:26:43 CET] <cone-576> ffmpeg 03Mark Thompson 07master:ce5870a3a8f2: cbs: Refcount all the things!
[23:26:44 CET] <cone-576> ffmpeg 03Mark Thompson 07master:0cc8e34a94c8: Merge commit 'ce5870a3a8f2b10668ee4f04c2ae0287f66f31b2'
[23:27:10 CET] <durandal_1707> great
[23:28:35 CET] <cone-576> ffmpeg 03Mark Thompson 07master:a2ca8ed903b4: cbs_h264: Add utility functions to insert/delete SEI messages
[23:28:36 CET] <cone-576> ffmpeg 03Mark Thompson 07master:77eba7bd9935: Merge commit 'a2ca8ed903b435446031a8a0792ca535e6ee2913'
[23:29:48 CET] <thardin> hum, what is the ssh url?
[23:30:46 CET] <jkqxz> For git?  "git at source.ffmpeg.org:ffmpeg"
[23:31:05 CET] <thardin> yeah
[23:32:31 CET] <thardin> WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
[23:32:33 CET] <thardin> hmm
[23:33:35 CET] <jkqxz> I bet SOMEONE IS DOING SOMETHING NASTY!
[23:34:34 CET] <thardin> nasssssty
[23:34:53 CET] <thardin> I'm going to go with trust on first use
[23:35:02 CET] <jamrial> thardin: do a --dry-run first to make sure you're not pushing undesirable and hard to kill things like tags and branches
[23:35:25 CET] <thardin> yes, michaelni told gave me that tip already
[23:35:43 CET] <jamrial> ok
[23:37:36 CET] <cone-576> ffmpeg 03Mark Thompson 07master:69062d0f9b6a: h264_metadata: Use common SEI addition function
[23:37:37 CET] <cone-576> ffmpeg 03Mark Thompson 07master:fd76e7be70c1: Merge commit '69062d0f9b6aef5d9d9b8c9c9b5cfb23037caddb'
[23:39:30 CET] <cone-576> ffmpeg 03Tomas Härdin 07master:41317da32592: Add -vf scale example for making pixels square
[23:39:35 CET] <thardin> woop
[23:40:39 CET] <atomnuker> peloverde: can you push the SSR patch or should I?
[23:40:44 CET] <cone-576> ffmpeg 03Mark Thompson 07master:78fa0b9033c0: h264_metadata: Always add the SEI user data to the first access unit
[23:40:45 CET] <cone-576> ffmpeg 03Mark Thompson 07master:7386b4ff3950: Merge commit '78fa0b9033c0834c049e2aedf71a8c613fed87ab'
[23:41:13 CET] <peloverde> atomnuker: You can push now, or I can push tonight when I get home
[23:42:49 CET] <cone-576> ffmpeg 03Mark Thompson 07master:7157d959264f: cbs_h264: Move slice_group_id array out of PPS structure
[23:42:50 CET] <cone-576> ffmpeg 03Mark Thompson 07master:ab6edb173b36: Merge commit '7157d959264f3729da463725c6faa580d9394d19'
[23:47:07 CET] <thebombzen> I think there's a bug with the afade filter
[23:47:59 CET] <thebombzen> ah nvm I'm a dunce, I didn't escape the :s
[23:49:17 CET] <atomnuker> peloverde: ah k, push whenever you can
[23:51:29 CET] <jdarnley> thardin: the git server's ssh key was changed at one point
[23:51:35 CET] <jdarnley> In the summer I think it was.
[23:51:56 CET] <thardin> alright
[23:53:52 CET] <cone-576> ffmpeg 03Mark Thompson 07master:eccc03c8fbc6: cbs_h264: Add support for filler NAL units
[23:53:53 CET] <cone-576> ffmpeg 03Mark Thompson 07master:fbeac5356c69: Merge commit 'eccc03c8fbc603a0a3257df66f0705f74fe2581a'
[23:58:13 CET] <cone-576> ffmpeg 03Mark Thompson 07master:6d5a6dde5301: h264_metadata: Add option to delete filler data
[23:58:14 CET] <cone-576> ffmpeg 03Mark Thompson 07master:ecb3d6edc3b7: Merge commit '6d5a6dde5301c81e221a37b3f39bb03149492b98'
[23:58:33 CET] <kierank> when will cbs_h264 replace the existing  h264 code?
[00:00:00 CET] --- Thu Feb 22 2018