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

[burek]

[01:33:03 CEST] <atomnuker> we don't support mixed-depth formats (e.g. luma is 10 bit but chroma planes are 8), right?
[01:44:51 CEST] <nevcairiel> right
[01:45:11 CEST] <nevcairiel> i have never seen anyone try to use them, even if h264 and hevc have both supported that
[01:54:40 CEST] <BBB> Im sure something supports them
[01:54:49 CEST] <BBB> it would be utter frankenstein
[01:54:58 CEST] <BBB> its also possible with h264/hevc to get limited-range rgb
[01:55:05 CEST] <BBB> I have no idea what that means
[01:57:35 CEST] <atomnuker> I think there's a law somewhere, texas maybe, where if someone gives you limited range rgb you can shoot him
[01:58:29 CEST] <atomnuker> maybe you had to be drunk too and fire a warning shot beforehand, I'm not sure
[02:57:45 CEST] <cone-420> ffmpeg 03Michael Niedermayer 07master:d8bc198d0979: avfilter/vf_overlay: Restore shorthand option order
[04:00:40 CEST] <atomnuker> jkqxz: why does hwcontext need a million and one private and public contexts?
[04:01:05 CEST] <atomnuker> why does the AVHWFramesContext struct need refcounting at all? its a few bytes
[04:01:40 CEST] <atomnuker> I'm getting a segfault because hw_frames_ctx->data is missing and I'm trying to figure what I changed to make it segfault
[04:03:25 CEST] <atomnuker> wait, this makes no sense, there's a check to see if dst->hw_frames_ctx exists
[04:03:43 CEST] <atomnuker> and since it does exists how does ctx = (AVHWFramesContext*)dst->hw_frames_ctx->data; fail at all
[04:09:07 CEST] <atomnuker> seems like I've corrupted my memory somewhere
[04:50:00 CEST] <atomnuker> nevermind, I was casting the wrong thing in get_buffer
[09:46:44 CEST] <ubitux> rcombs: audiotoolbox_extralibs="-framework CoreFoundation -framework AudioToolbox -framework CoreMedia"
[09:46:51 CEST] <ubitux> afaict you only need -framework AudioToolbox
[09:46:58 CEST] <ubitux> i tested and it seems to work
[09:47:04 CEST] <ubitux> the framework contains all the deps
[09:47:13 CEST] <ubitux> and you end up with a binary that link to all the others
[10:14:17 CEST] <ubitux> so yeah, just tested on my branch with --disable-autodetect --enable-audiotoolbox
[10:14:24 CEST] <ubitux> this adds only -framework AudioToolbox
[10:14:43 CEST] <ubitux> this is confirmed by otool -L which raise only this framework
[10:14:51 CEST] <ubitux> and i can still decode with the _at decoders
[10:18:13 CEST] <BtbN> philipl, could you, or pretty much anyone who has some experience with the new encode/decode API, take a look at the nvenc patch to change it to the new API? It works fine when I test it, but I'd like to have another pair of eyes check my logic before I push.
[10:18:36 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/4953/
[11:04:23 CEST] <wm4> atomnuker: it's refcounted because it has shared state and further frame refs
[11:50:55 CEST] <cone-826> ffmpeg 03Paul B Mahol 07master:eea69a9f250e: avfilter/af_dcshift: add direct path
[14:41:33 CEST] <BBB> wm4: about execute3, do we know why execute1/2 are part of the public API?
[14:42:28 CEST] <BBB> wm4: I genuinely dont know, ilia just followed existing design
[14:42:29 CEST] <nevcairiel> presumably at one point you could put your own callback there
[14:42:33 CEST] <wm4> I don't
[14:42:54 CEST] <BBB> nevcairiel: apart from mplayer, do we know anyone actually using that feature and getting specific utility from it?
[14:43:22 CEST] <nevcairiel> probably not
[14:45:06 CEST] <wm4> why mplayer
[14:47:04 CEST] <BBB> wm4: everyone has this crazy uncle that shouldnt be used to justify silly behaviour; our crazy uncle is mplayer :)
[15:00:42 CEST] <BBB> ok, so, going back to the original situation
[15:00:49 CEST] <BBB> what do we do with execute3 then?
[15:06:57 CEST] <wm4> make it ff_?
[15:10:37 CEST] <BBB> I think part of the problem is that execute3 is in AVCodecContext, maybe it shouldnt be
[15:13:16 CEST] <jkqxz> AVCodecInternal?
[15:13:52 CEST] <BBB> what I mean is why do we call avcodec->execute3() instead of just calling avpriv/ff_mythread_cute_function()
[15:14:07 CEST] <BBB> again, I dont know, hence my question, but we currently do that for execute1/2
[15:14:12 CEST] <gh0st__> I think it would better to move it from AVCodecContext, because only vp9 would utilize the execute3
[15:14:59 CEST] <gh0st__> Maybe in the future we can put it in AVCodecContext when more codecs would need it.
[15:15:55 CEST] <gh0st__> I am not sure
[15:19:09 CEST] <BBB> ok, can we rewrite this so there is only changes in vp9.c?
[15:20:16 CEST] <BBB> e.g. we can remove execute3 entirely, and the mainfunc cap
[15:20:22 CEST] <gh0st__> Yes, I think for the current state of things that would the best choice, I think.
[15:20:38 CEST] <BBB> and then either add thread_execute3 as a non-static function with ff prefix and call that instead of avctx->execute3
[15:21:04 CEST] <BBB> or alternatively make thread_execute non-static with ff prefix, add thread_execute3 in vp9.c, and do it like that
[15:21:05 CEST] <gh0st__> yes
[15:21:21 CEST] <BBB> wm4: which one do you prefer?
[15:22:18 CEST] <BBB> I think the second is better, since execute3 is currently vp9-specific
[15:22:24 CEST] <BBB> shall we do that then?
[15:22:51 CEST] <wm4> maybe the latter
[15:23:33 CEST] <BBB> ok
[15:23:48 CEST] <BBB> gh0st__: that still requires the cap then, but in caps_internal instead of caps (public)
[15:24:09 CEST] <BBB> gh0st__: since otherwise pthread_slice.c doesnt know whether to allocate the main thread as one slice worker or for the main_func
[15:24:19 CEST] <BBB> but the rest should be straightforward, and it removes the need for execute2
[15:24:26 CEST] <BBB> sorry, execute3
[15:24:37 CEST] <BBB> and thus also avcodec_default_execute3
[15:25:11 CEST] <gh0st__> Sure, I think that's better.
[15:40:34 CEST] <ubitux> BBB: http://sprunge.us/MGiD 
[15:40:38 CEST] <ubitux> with the patchset
[15:40:51 CEST] <BBB> *tears in my eyes*
[15:40:54 CEST] <BBB> so beautiful
[15:40:59 CEST] <BBB> tnx!
[15:41:02 CEST] <JEEB> najs
[15:41:42 CEST] <nevcairiel> nice cleanup :)
[15:41:58 CEST] <wm4> did we get rid of the SDL dep yet
[15:42:06 CEST] <JEEB> --disable-autodetect
[15:42:10 CEST] <JEEB> and it fscks off
[15:42:21 CEST] <JEEB> "fly away~ fly away now~"
[15:44:05 CEST] <ubitux> someone needs to do it for windows btw
[15:44:10 CEST] <ubitux> for that one, i can't help
[15:44:23 CEST] <JEEB> which type of windows?
[15:44:32 CEST] <JEEB> mingw-w64 or MSVC?
[15:44:53 CEST] <ubitux> both i guess, but i could try mingw
[15:45:05 CEST] <ubitux> i have a build but didn't check if it autodetected stuff by default
[15:50:26 CEST] <mateo`> yeah, I successfuly booted an Odroid-C2 with an upstream kernel (4.13 - ArchLinux)
[15:50:40 CEST] <ubitux> atomnuker ^
[15:50:41 CEST] <mateo`> atomnuker: ^
[15:50:49 CEST] <JEEB> cool
[15:52:13 CEST] <mateo`> using the base image, you just need to pacman -S uboot-odroid-c2-mainline linux-aarch64
[15:52:17 CEST] <mateo`> then cd /boot; ./sd_fusing.sh /dev/mmcblk0
[15:53:03 CEST] <ubitux> jamrial: can you rebase you audiotoolbox patches so i can test them?
[15:53:09 CEST] <ubitux> (do you have them in a branch?)_
[15:53:31 CEST] <jamrial> ubitux: they don't apply? ok, i'll do it in a bit and push to github
[16:22:06 CEST] <philipl> BtbN: I will look
[16:35:21 CEST] <atomnuker> mateo`: oh hey they finally did it then, huh
[16:38:00 CEST] <jamrial> ubitux: https://github.com/jamrial/FFmpeg/commits/audiotoolbox it applied cleanly with git am here
[16:39:04 CEST] <jamrial> first two commits are memleak fixes in different scenarios, third is a rewrite of the bsf stuff
[16:45:39 CEST] <ubitux> jamrial: builds without warning and decode seems fine; anything i should test in particular?
[16:48:53 CEST] <flying_toaster> hi there
[16:49:22 CEST] <flying_toaster> I have an issue with ITU 35 closed caption extraction in H264 
[16:50:32 CEST] <flying_toaster> it seems the h264 codec extracts closed captions correctly with 1 thread, but I do see inversions/corrupted 708 bitstream if the h264 codec works using several threads
[16:50:56 CEST] <flying_toaster> I tried to analyze the code, but it is a bit complex
[16:51:18 CEST] <flying_toaster> any idea to solve this ?
[16:54:02 CEST] <BBB> is it stored as frame side-data?
[16:55:05 CEST] <flying_toaster> source CC is in the SEI, extracted CC is in side data, in the output AVFrame
[17:04:38 CEST] <kierank> BBB: it's probably the same thread bug i had
[17:04:51 CEST] <kierank> with fields
[17:04:55 CEST] <BBB> oh, aha
[17:07:25 CEST] <BBB> that bug is annoying& you should really fix that :-p
[17:07:44 CEST] <ubitux> tsan is still not green? :(
[17:08:07 CEST] <ubitux> meh, utvideo still yellow?
[17:08:20 CEST] <kierank> BBB: well i sent a patch
[17:08:29 CEST] <kierank> but i was told not to modify the previous thread
[17:08:32 CEST] <kierank> so I dunno how to fix
[17:08:51 CEST] <BBB> modifying the previous thread is a recipe for disaster
[17:09:02 CEST] <kierank> I emergency fixed it by forcing single thread at the time but I would like to fix it properly
[17:09:04 CEST] <BBB> its like the ground changing under you, it is the definition of a race condition :-p
[17:09:12 CEST] <kierank> perhaps a discussion for VDD
[17:09:16 CEST] <BBB> agreed
[17:12:34 CEST] <jamrial> ubitux: aac adts audio, use valgrind to look for memleak, and make sure the packets are filtered
[17:12:50 CEST] <flying_toaster> kierank : is your patch available somewhere ?
[17:12:52 CEST] <jamrial> but if audiotoolbox didn't complain about weird data guess it's being filtered alright
[17:13:16 CEST] <jamrial> unless it recently started supporting adts encapsulated frames
[17:14:03 CEST] <ubitux> valgrind is broken
[17:14:41 CEST] <ubitux> (on garbageOS)
[17:14:49 CEST] <ubitux> can't really use it
[17:14:51 CEST] <jamrial> ah
[17:15:05 CEST] <ubitux> it segfaults randomly, raise false positive etc
[17:15:25 CEST] <jamrial> ok, then as long as adts frames are decoded fine after the bsf rewrite patch then i guess it should be fine
[17:15:52 CEST] <ubitux> mmh what sample i can use for adts?
[17:16:41 CEST] <jamrial> ubitux: aac/id3v1.aac and aac/foo.aac i think, from the fate suite
[17:17:08 CEST] <jamrial> also ct_faac-adts.aac, judging by the name :p
[17:23:43 CEST] <ubitux> jamrial: http://sprunge.us/NFVj
[17:23:57 CEST] <ubitux> jamrial: pts looks different in aac/ct_faac-adts.aac 
[17:24:46 CEST] <ubitux> -c:a aac vs -c:a aac_at
[17:25:35 CEST] <jamrial> but did the output of aac_at change between pre and post patchset? that's what i care about
[17:25:53 CEST] <jamrial> if the output differs between aac and aac_at, that's something the maintainer would have to check
[17:26:59 CEST] <ubitux> no, doesn't seem to change
[17:27:59 CEST] <jamrial> ok, thanks a lot for testing :D
[17:28:05 CEST] <ubitux> np :)
[17:30:53 CEST] <J_Darnley> I hate interlacing shit.  Why can't everyone who has ever touched it just die?
[17:31:11 CEST] <ubitux> won't be enough for the files in the wild
[17:31:54 CEST] <J_Darnley> If you discover one, you are included.
[17:32:42 CEST] <ubitux> aren't you complaining because you're dealing with one currently? :-°
[17:32:42 CEST] <nevcairiel> does that include you then
[17:33:20 CEST] <J_Darnley> Yes!
[17:33:28 CEST] <J_Darnley> I wouldn't have to work on this shit anymore.
[17:33:40 CEST] <nevcairiel> but you would be dead
[17:33:54 CEST] <J_Darnley> Oh no!
[18:05:51 CEST] <cone-826> ffmpeg 03James Almer 07master:7273e234dee5: avcodec/audiotoolboxdec: always use a copy of the AVCodecContext extradata
[18:05:51 CEST] <cone-826> ffmpeg 03James Almer 07master:e49338a9c062: avcodec/audiotoolboxdec: add FF_CODEC_CAP_INIT_CLEANUP to the decoder capabilities
[18:05:53 CEST] <cone-826> ffmpeg 03James Almer 07master:3242babf64a2: avcodec/audiotoolboxdec: switch to the new generic filtering mechanism
[18:05:54 CEST] <cone-826> ffmpeg 03James Almer 07master:f4e593f7b51f: avcodec/audiotoolboxdec: use av_freep()
[20:26:10 CEST] <stripes416> .win 6
[20:26:40 CEST] <stripes416> sorry, ignore my faulty keyboarding :/
[20:28:35 CEST] <gnafu> Unacceptable.
[20:34:14 CEST] <iive> just change your password
[21:22:24 CEST] <spalpeen> hello
[21:23:12 CEST] <spalpeen> i would like to decode only a small crop of incoming stream, can someone point me to what section of code I should look at 
[21:32:59 CEST] <ubitux> so about that developer error message thing
[21:33:23 CEST] <ubitux> how about a ff_devlog or whatever that is void on CONFIG_SMALL
[21:33:30 CEST] <ubitux> and av_log at DEBUG level otherwise?
[21:33:59 CEST] <ubitux> BBB ^
[21:34:03 CEST] <BtbN> I still wonder: Is that message in question only displayed on catastrophic decode failure, or is it one of those not overly important runtime errors that just happen with slightly corrupted files?
[21:34:41 CEST] <ubitux> both i guess; the point is to help the developer identify quickly the code
[21:34:42 CEST] <BBB> ubitux: I think were over-complicating something really trivial here
[21:34:50 CEST] <BtbN> from looking at the patch it seemed like a hard error.
[21:35:07 CEST] <BtbN> In which case, why the hell would you not always print the error then? If a user comes up with such a file, it saves everyone time.
[21:35:10 CEST] <ubitux> BBB: not so sure
[21:35:40 CEST] <ubitux> there are definitely different expectations
[21:35:48 CEST] <BBB> BtbN: its what you said earlier, slightly corrupt files (e.g. from a network source) will indeed spam the stderr
[21:36:06 CEST] <BBB> I think source code pollution is at least as big an issue
[21:36:26 CEST] <BtbN> I don't see verbose debug logging as pollution
[21:36:34 CEST] <BtbN> I have _tons_ of trace logs in cuvid
[21:36:43 CEST] <BBB> not to mention the quality of his earlier log messages; hes committed 100s of these kind of patches, and the quality of the message is generally appaling
[21:36:44 CEST] <jamrial> but those are trace
[21:36:46 CEST] <BtbN> it basically gives you a full function call graph if you run it in trace mode
[21:36:50 CEST] <BBB> trace is fine; he made it a hrd error
[21:36:58 CEST] <BtbN> but all the strings are still in the code and binary
[21:36:58 CEST] <BBB> AV_LOG_ERROR is displayed to our end users
[21:37:00 CEST] <BBB> by default!
[21:37:04 CEST] <BBB> thats not the same as trace
[21:37:16 CEST] <ubitux> yes, most ppl agree this is not appropriate
[21:37:23 CEST] <ubitux> the question is what alternative we agree on
[21:37:34 CEST] <BBB> so there were multiple levels of concern from me, I can try to list them:
[21:37:34 CEST] <BtbN> Yeah, for a mostly unimportant runtime hickup, LOG_ERROR is a bit much
[21:37:37 CEST] <ubitux> i personally don't like ff_dlog
[21:37:38 CEST] <BtbN> LOG_DEBUG seems appropiate
[21:37:54 CEST] <BBB> A) the quality of the message was appaling; that needs fixing no matter what (he did that in the one patch, I hope he will continue keeping that up in subsequent patches)
[21:38:13 CEST] <BBB> B) the level of stderr spam for slightly corrupted files (e.g. network source) is an issue (on default settings)
[21:38:18 CEST] <BBB> C) the binary size
[21:38:25 CEST] <BBB> D) source code polution (and size)
[21:38:38 CEST] <BBB> D2) especially concerning stuff that is really fuzz-only
[21:38:52 CEST] <BBB> D+D2 sort of go together in my mind, but you may disagree
[21:39:01 CEST] <BBB> so, in terms of what would I be OK with:
[21:39:22 CEST] <BBB> - Im fine with errors (AV_LOG_ERROR) for stuff that happens in real life, and assists the user in resolving it
[21:39:40 CEST] <ubitux> when debugging, i agree with BtbN, having a trace is useful
[21:39:41 CEST] <BBB> for example, sps/pps errors typically mean you mis-parsed the stream as an API user or something
[21:39:58 CEST] <BBB> so it can be exceptionally helpful for everyone to get these under AV_LOG_ERROR
[21:40:14 CEST] <ubitux> we could have some kind of MS error id though
[21:40:39 CEST] <BBB> - I think for generic your file is broken, the end result will always be the same: test latest version, upload file, create ticket, ask devs for help
[21:40:47 CEST] <BBB> I dont think we need more debug than that
[21:41:03 CEST] <BtbN> Well, some debug output would still be useful for a fatal failure
[21:41:18 CEST] <BBB> useful to who?
[21:41:31 CEST] <BtbN> The dev reading the ticket and potentially not having to download the sample
[21:41:34 CEST] <BBB> to the dev? or the user?
[21:41:40 CEST] <BtbN> and to the user, as it saves time
[21:41:42 CEST] <ubitux> #define TRACE_ERR(l) av_log(l,AV_LOG_TRACE,"err @ %s #%d\n",__FILENAME__,__LINE__);
[21:41:50 CEST] <ubitux> always small binary size ^
[21:42:09 CEST] <ubitux> (fmt string is shared)
[21:42:28 CEST] <ubitux> code is not that poluted (only "TRACE_ERR(avctx)" in error paths)
[21:42:44 CEST] <BtbN> I'd put the version in there somehow
[21:42:45 CEST] <ubitux> debuggable with a command line switch
[21:42:57 CEST] <ubitux> yeah that's just an example so you get the idea
[21:43:12 CEST] <ubitux> you flag every error path with that
[21:43:17 CEST] <BBB> BtbN: version is first line of a proper ffmpeg commandline output :-p
[21:43:42 CEST] <ubitux> anyway, i'll leave the brainstorming room for tonight
[21:44:15 CEST] <BBB> and yes I know Im being an ass ATM, I think Ive given some good reasons for that: weve gone WAY overboard in the past few months in creating a new monster
[21:44:18 CEST] <BBB> we need to tame it
[21:44:33 CEST] <BBB> if Im sweet and cute about it, well go another 6 months creating a worse monster that nobody wants to deal wtih
[21:44:43 CEST] <BBB> hopefully in a week well all agree on something and it wont get worse
[21:45:00 CEST] <BBB> because seriously, the quality of the logs displayed by default to our end users was utterly appaling
[21:45:06 CEST] <BBB> and thats unacceptable
[21:45:21 CEST] <BBB> so lets improve this, and well all be happier
[21:45:30 CEST] <BBB> and then Ill apologize for being an ass for a week
[21:45:39 CEST] <BBB> sometimes a project needs an ass
[21:45:51 CEST] <BtbN> Well, the _real_ endusers won't see any messages at all. As they use ffmpeg embedded into something else they use.
[21:46:07 CEST] <BtbN> Everyone using ffmpeg directly is at least to some degree an advanced user
[21:46:42 CEST] <BBB> UI users? oh goodness, if they saw these messages, theyd instantly file bug reports that their computer was overtaken by russian hackers
[21:46:56 CEST] <BBB> (the bug reports would go to their local police office, not the software developers)
[21:47:27 CEST] <BBB> Im sorry mam, you downloaded a new video viewer and it was taken over by russians? Im not sure we can help with that mam
[21:47:48 CEST] <jamrial> "Application attempted to do an illegal operation" error popups are always a fun way to scare your aunt
[21:47:49 CEST] <BBB> but I still feel the user presentation of ffmpeg-the-tool is also important
[21:48:04 CEST] <BBB> is it -1 that was converted to permission denied?
[21:48:13 CEST] <BBB> I had a lot of permission denieds in earlier versions
[21:48:21 CEST] <iive> ubitux: I had a patch that did the same, but it replaced AVERROR, so it kind of was automatic for most usage
[21:48:41 CEST] <BBB> yes! /usr/include/sys/errno.h:#define	EPERM		1		/* Operation not permitted */
[21:48:46 CEST] <BBB> gotta love that
[21:49:08 CEST] <iive> of course, AVERROR is used on some places as constant, so I needed to change these to something else.
[21:52:16 CEST] <iive> ubitux: btw, It would be better if you have a separate function, so it could do more complicated things, like provide human-readable error codes and ignore EAGAIN, and do other more complicated logic.
[22:02:03 CEST] <kierank> wm4: are you going to vdd
[22:07:42 CEST] <wm4> kierank: no
[22:07:58 CEST] <kierank> a shame
[22:09:09 CEST] <wm4> I still don't understand the point of vdd
[22:10:15 CEST] <j-b> meeting other geeks IRL
[22:18:30 CEST] <durandal_1707> how that can be interesting?
[22:22:41 CEST] <wm4> yeah, why would you go through so much trouble just to meet other people
[22:23:16 CEST] <j-b> so much trouble?
[22:24:56 CEST] <wm4> the timing is inconvenient too: I have to spend the entire next week abroad (due to my job), and the weekend after that (same as vdd) we have elections here
[22:25:56 CEST] <BBB> aka lazy
[22:26:07 CEST] <BBB> Im flying over all the way from the US, as is compn
[22:26:21 CEST] <BBB> I believe peloverde usually also attends, hes from westcoast
[22:26:32 CEST] <BBB> you europeans talking about how much effort it is, bunch of lazies
[22:26:44 CEST] <j-b> I ain't lazy :)
[22:26:49 CEST] <BBB> youre attending
[22:26:52 CEST] <BBB> of course youre not lazy
[22:26:54 CEST] <j-b> I do IBC-VDD-FOMS-Demuxed-GSoC
[22:26:56 CEST] <BBB> non-attenders are lazy
[22:27:11 CEST] <BBB> wm4 is lazy, durandal_1707 is lazy, michaelni is lazy
[22:27:27 CEST] <j-b> I don't call anyone lazy. I understand the fear of travelling.
[22:27:31 CEST] <atomnuker> wm4: going to the us?
[22:27:32 CEST] <BBB> cehoyos is not lazy, thilo is not lazy, youre not lazy, compn is not lazy, peloverde is not lazy, atomnuker is not lazy
[22:27:47 CEST] <j-b> I just think it's a shame, because it is always nicer with an IRL beer
[22:28:29 CEST] <BBB> I appreciate how youre being such an incredible gentleman about these things
[22:28:43 CEST] <wm4> atomnuker: not quite but similarly far
[22:28:50 CEST] <atomnuker> j-b: I still remember the cone beer we had in 2015, it was very nice
[22:28:57 CEST] <wm4> j-b: it's less than fear than a big annoyance
[22:29:10 CEST] <BBB> my kids still play with the cone head we got 2 years ago
[22:29:13 CEST] <j-b> atomnuker: I am re-brewing some for FOSDEM
[22:29:17 CEST] <atomnuker> wm4: america or asia?
[22:29:23 CEST] <wm4> atomnuker: america
[22:29:54 CEST] <wm4> especially flying means waiting a shit ton being stuck somewhere
[22:31:53 CEST] <atomnuker> exactly, that's why you take the train
[22:31:54 CEST] <jkqxz> Flying is awful.  At least Paris is somewhere I can get the train to.
[22:31:55 CEST] <kierank> wm4: take the train
[22:32:01 CEST] <jkqxz> Haha.
[22:32:04 CEST] <atomnuker> city center to city center
[22:32:12 CEST] <wm4> train to paris would take half a day, literally
[22:32:39 CEST] <j-b> take a laptop, take the train, code.
[22:32:39 CEST] <wm4> trains aren't even necessarily more comfortable than planes too
[22:32:47 CEST] <wm4> but at least you don't have to wait this long
[22:32:56 CEST] <wm4> (I mean, outside of the vehicle)
[22:33:05 CEST] <atomnuker> they usually are because train companies understand why people take trains instead of planes
[22:33:19 CEST] <wm4> this security bullshit in travel by air is going too far
[22:33:36 CEST] <atomnuker> there is usually a cafe or a restaurant carrige
[22:33:46 CEST] <kierank> the eurostar cafe is nice
[22:33:48 CEST] <ubitux> BBB: i'm "lazy" too o/
[22:33:55 CEST] <BBB> booh! why?
[22:34:23 CEST] <wm4> I probably should have gone last year - that was more convenient in a number of ways
[22:34:23 CEST] <ubitux> i don't see the point either
[22:34:27 CEST] <atomnuker> kierank: food and space in business class for a few quid more is well worth it too
[22:34:36 CEST] <kierank> atomnuker: nah it was crap when i went
[22:34:44 CEST] <atomnuker> I guess I got lucky
[22:34:51 CEST] <kierank> atomnuker: on the new train perhaps it's better
[22:34:53 CEST] <kierank> i went on the old one
[22:35:10 CEST] <atomnuker> thought that was 2 years ago, can't remember if it was on an old or new train
[22:35:46 CEST] <BBB> ubitux: Ill be amenable to resolving the logging issue with michael if you and jamrial attend (you dont have to convince me, just show up and Ill resolve it)
[22:35:49 CEST] <BBB> enough reason?
[22:36:29 CEST] <ubitux> i don't care enough about that issue
[22:37:12 CEST] <kierank> https://code.facebook.com/posts/1537144479682247/finding-inter-procedural-bugs-at-scale-with-infer-static-analyzer/
[22:37:23 CEST] <BBB> Ill give you a I fix any one bug you want credit that I tend to give cehoyos every year?
[22:37:49 CEST] <kierank> fix swscla
[22:37:51 CEST] Action: kierank runs
[22:37:54 CEST] <kierank> :(
[22:38:18 CEST] <BBB> fix what specific issue?
[22:38:47 CEST] <kierank> all of it :)
[22:39:00 CEST] <BBB> hm...
[22:39:19 CEST] <wm4> you can't even get rid of the self-modifying code for MMX that is used for a broken obscure scaler only
[22:39:46 CEST] <BBB> one of my main issues with swscale is that it solves so many problems (really, it does) that at some point it becomes hard to functionally replace it without losing at least some feature or performance gap
[22:40:02 CEST] <JEEB> yea, it's really a big big smorgåsbord
[22:40:04 CEST] <JEEB> of features
[22:40:30 CEST] <BBB> thats why I wrote the colorspace filter; its not better than swscale, but it solves some issues in swscale that I personally encountered directly
[22:40:34 CEST] <wm4> I never got why libswscale does both conversion and scaling
[22:40:44 CEST] <BBB> wm4: because in most cases conversion = scaling
[22:41:04 CEST] <BBB> yuv422->yuv420 conversion is vertical chroma rescaling
[22:41:08 CEST] <wm4> not really... for e.g. yuv420p->rgb, you actually convert to 4:4:4 at some point
[22:41:09 CEST] <BtbN> It'd probably a massive performance hit to do that seperately as well
[22:41:21 CEST] <wm4> (just do it in slices or so)
[22:41:26 CEST] <BBB> BtbN: yes
[22:42:50 CEST] <BBB> anyway, you want me to work on a part of swscale? come to vdd :-p
[22:43:00 CEST] <BBB> is jamrial attending this year?
[22:47:04 CEST] <jamrial> BBB: no. too many reasons why i can't or feel uncomfortable about it
[22:47:18 CEST] <BBB> :(
[22:52:39 CEST] <atomnuker> jamrial: do you live in argentina?
[22:52:51 CEST] <jamrial> yes
[22:56:25 CEST] <atomnuker> yeah, travelling is why I'm not going to demuxed, its too far away
[22:57:14 CEST] <kierank> atomnuker: i doubt you'd like demuxed
[22:57:18 CEST] <kierank> not that i've been
[22:57:51 CEST] <atomnuker> I saw the schedule is filled with traditional talks from companies too
[22:58:09 CEST] <kierank> FOSDEM is better tbh
[22:58:12 CEST] <kierank> but not hipster enough
[22:58:38 CEST] <kierank> vdd is more technical
[22:58:49 CEST] <atomnuker> yeah, VDD and FOSDEM are the only places where multimedia people can give talks about things they've done out of interest
[23:00:51 CEST] <kierank> that reminds me i need to do something about my mpeg4video 10-bit patches
[23:06:46 CEST] <j-b> kierank: that actually exists?
[23:06:57 CEST] <kierank> yes, there are samples
[23:07:18 CEST] <j-b> oh boy.
[23:07:21 CEST] <kierank> but mpeg4video is too heavily tied into mpegvideoenc crap and divx stuff to easily put in 10-bit
[23:07:38 CEST] <JEEB> yea, mpeg-4 part 2 10bit is A Thing
[23:07:45 CEST] <JEEB> and some pro stuff seems to create it
[23:07:52 CEST] <kierank> if(a)do_a. if(b) do_b if(c) do_c
[23:07:54 CEST] <kierank> totally pointless
[23:08:57 CEST] <j-b> oh, that gives me a great idea for VDD:
[23:09:13 CEST] <j-b> a competition of the worst multimedia abomination
[23:09:20 CEST] <JEEB> MMT(P)
[23:09:29 CEST] <JEEB> I'm just thankful I don't see that anywhere
[23:09:35 CEST] <j-b> (with samples)
[23:12:50 CEST] <kierank> mmtp yeah
[23:12:52 CEST] <kierank> that's awful
[23:13:14 CEST] <kierank> i might be able to get a sample of j2k in mxf over rtp
[23:13:17 CEST] <kierank> that's also terrible
[23:13:18 CEST] <JEEB> :D
[23:13:22 CEST] <JEEB> aaa
[23:14:56 CEST] <mateo`> kierank: bonus points if the j2k stream is interlaced and stored using the separate field layout
[23:15:00 CEST] <rcombs> worst multimedia abomination?
[23:15:05 CEST] <kierank> mateo`: yup of course it is
[23:15:05 CEST] <rcombs> could be the super mario bros movie
[23:21:50 CEST] <BBB> demuxed is definitely more corporate
[23:22:18 CEST] <BBB> I think the primary reason for that is just geographical proximity to the bay area, so most people that live there with an interest in multimedia will be working for one of those big tech corps
[23:26:00 CEST] <durandal_1707> why you guys are still working this,  you should be fired already
[23:33:11 CEST] <BBB> why do you still have a job, you should be fired?
[23:33:16 CEST] <BBB> uhm
[23:33:18 CEST] <BBB> right
[23:33:46 CEST] <BtbN> Because they don't work for Oracle.
[23:50:43 CEST] <Compn> BBB : i do not think i am attending vdd this year.
[23:50:51 CEST] <BBB> ;(
[23:51:13 CEST] <Compn> i am busy this year :(
[23:51:18 CEST] <Compn> but please have fun without me 
[00:00:00 CEST] --- Thu Sep  7 2017