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

[burek]

[00:58:56 CET] <Timothy_1u> michaelni_: thoughts on adding a logo to https://github.com/FFmpeg ?
[01:37:04 CET] <michaelni_> Timothy_1u, sounds like a good idea, should i add one? which one ?
[01:40:46 CET] <pippin> does it make sense to only expose bit_rate and bit_rate_tolerance or some other small set of properties for generic codec configuration?
[01:42:30 CET] <pippin> wondering if a somewhat generic frame-sink node in dataflow based thing would then end up having decent defaults for the various codecs
[03:45:43 CET] <Timothy_1u> michaelni_: let's use this one: https://cloud.githubusercontent.com/assets/1538624/11433124/dfdb41f6-946d-11e5-959f-b4b5a5da4c26.png
[03:46:02 CET] <Timothy_1u> You know how to change it right?
[03:46:33 CET] <Timothy_1u> https://github.com/organizations/FFmpeg/settings/profile
[03:56:26 CET] <michaelni_> Timothy_1u, changed
[03:58:07 CET] <Timothy_1u> cool thx
[04:34:33 CET] <kylophone> Working on another filter. Is there a good way to detect whether or not the current frame is the final frame of the stream?
[09:49:52 CET] <bove> which is the default rescale algorithm in swscale?
[09:53:48 CET] <ubitux> SWScaler AVOptions:
[09:53:50 CET] <ubitux>   -sws_flags         <flags>      E..V.... scaler flags (default bicubic)
[09:58:00 CET] <JEEB> I recommend you try out zscale btw
[09:58:21 CET] <JEEB> you need the zimg library for it, but it should give in many cases a much better result
[09:58:38 CET] <JEEB> (although I still need to fix the fact that the libavfilter thing doesn't propagate colorimetry to the encoder it seems)
[10:15:03 CET] <mateo`> Hello o/, I'm looking at extracting the exif information from a jpeg file without decoding. The problem is that the metadata is actually stored in the decoded frame metadata. It seems there is no current way to put those metadata at the stream level and it feels wrong to put them at the AVCodecContext level.
[10:16:23 CET] <wm4> well, libavformat could just parse it, I suppose
[10:16:24 CET] <mateo`> One solution would be to let the jpeg parse extract the exif data, put it in the avpacket side data, and export a public function to parse it
[10:16:32 CET] <mateo`> or libavformat yes
[10:20:53 CET] <nevcairiel> dont we have formatcontext metadata for such things, the place id3 etc also ends up
[10:22:20 CET] <mateo`> I'm still a bit undecided whether it's a good idea to have this feature in ffmpeg (ie: extracting exif without decoding) as there are libraries that already do that, what do you think ?
[10:23:35 CET] <mateo`> If it's done in libavformat, it would imply that the metadata will possibly change for every frame
[14:05:38 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:a1f6b05f5228: avcodec/cabac_functions: Fix "left shift of negative value -31767"
[14:05:38 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:8000d484b83a: avcodec/cabac: Check initial cabac decoder state
[14:11:50 CET] <nevcairiel_> People that argue by attacking the other sides rhetoric instead of actually presenting arguments should be banned from development processes
[14:14:28 CET] <wm4> I'm sorry for being an asshole
[14:16:25 CET] <kierank> I don't see why this magic api can't just give you the choice of whether to use a thread or not
[14:16:43 CET] <kierank> nicolas idea that threading is not the solution for I/O is insane
[14:17:35 CET] <wm4> well, it's true that the kind of people who tried figuring out how to do thousands of connections on a single web server concluded that the right answer is thread pools with many async connections on each thread
[14:18:44 CET] <kierank> yes
[14:18:53 CET] <kierank> exactly
[14:19:15 CET] <wm4> which means whatever it processes actually needs an async API, not something blocking
[14:19:33 CET] <wm4> which is surely what he meant#
[14:19:44 CET] <wm4> (and I don't remember why we were even talking about this)
[14:19:51 CET] <kierank> you do still need separate threads for things like udp capture
[14:20:15 CET] <kierank> but as long as you don't do too much you can put them all in a single source thread
[14:40:54 CET] <cone-149> ffmpeg 03Michael Niedermayer 07release/2.8:24c504bd0a7c: avcodec/cabac_functions: Fix "left shift of negative value -31767"
[14:40:55 CET] <cone-149> ffmpeg 03Michael Niedermayer 07release/2.8:4c718691ea32: avcodec/cabac: Check initial cabac decoder state
[14:40:56 CET] <cone-149> ffmpeg 03Michael Niedermayer 07release/2.8:a353cc44a654: Update for 2.8.3
[14:58:52 CET] <Daemon404> giant thread time again apparently
[14:58:57 CET] Action: Daemon404 doesnt read
[15:17:02 CET] <cone-149> ffmpeg 03James Almer 07release/2.8:644296e736ee: avutil/softfloat: use abort() instead of av_assert0(0)
[15:32:11 CET] <atomnuker> making the aac encoder init threadsafe might be messy
[15:32:35 CET] <atomnuker> ff_aac_tableinit is shared between the decoder and encoder
[15:33:14 CET] <atomnuker> so using both the decoder and encoder at the same time (transcoding) will still call it twice
[15:33:22 CET] <Daemon404> eh?
[15:33:37 CET] <Daemon404> just share the var used by ff_thread_once
[15:33:55 CET] <atomnuker> yeah, I know
[15:35:05 CET] <atomnuker> I'd just prefer not to but oh well
[15:35:18 CET] <Daemon404> it's not any worse than sharing a table
[15:49:27 CET] <durandal_170> what's up with network today?
[15:50:49 CET] <Daemon404> freenode maybe getting ddosed
[15:50:52 CET] <Daemon404> as per usual
[15:51:35 CET] <cone-149> ffmpeg 03Michael Niedermayer 07n2.8.3:HEAD: avcodec/cabac: Check initial cabac decoder state
[15:55:34 CET] <wm4> ddos
[15:57:27 CET] <cone-149> ffmpeg 03Rostislav Pehlivanov 07master:3d62e7a30fa5: aacenc: make threadsafe
[16:01:21 CET] <cone-149> ffmpeg 03Rostislav Pehlivanov 07master:222545cc7e09: aactab.h: update and correct comment
[16:05:30 CET] <wm4> -mquin- [Global Notice] We are again experiencing connectivity problems to some servers due to DDoS attacks. Please bear with us while we ride it out. 
[16:13:45 CET] <J_Darnley> Apparently it is "Email Free Friday" here.  I better send some to counter that.
[16:34:12 CET] <atomnuker> ubitux: "sorry to notice only now; maybe add a static?" < huh?
[16:34:34 CET] <atomnuker> exp2_lut is within a function
[16:34:56 CET] <ubitux> and?
[16:35:04 CET] <ubitux> btw, your latest commit broke build
[16:35:07 CET] <ubitux> + * Tables in this file are shared by the AAC decoders and encoder */
[16:35:09 CET] <ubitux> +*/
[16:35:15 CET] <ubitux> double */, breaks build
[16:36:10 CET] <ubitux> atomnuker: i suppose that with static it will end up in ro memory, while without it might be copied on the stack or sth (to be checked)
[16:36:25 CET] <atomnuker> shit...
[16:38:08 CET] <cone-149> ffmpeg 03Rostislav Pehlivanov 07master:591fbd629ef5: aactab.h: fix comment
[16:39:15 CET] <ubitux> thx
[16:41:13 CET] <atomnuker> oh btw, I do remember doing comparisons between having small tables defined as consts in the function and as static const variables within a file
[16:41:45 CET] <atomnuker> the asm gcc generated looked better when the tables were inside the functions
[16:42:35 CET] <atomnuker> though it was a file with a single function so you'd think it wouldn't change anything
[16:47:13 CET] <ubitux> atomnuker: http://b.pkh.me/nostatic-static.html
[16:50:36 CET] <ubitux> so indeed, stack gets "enlarged" of 0x1070 and it seems somehow memcpyed
[16:50:44 CET] <ubitux> if your table is not static
[16:51:08 CET] <ubitux> btw, if someone knows a better way of diffing assembly, i'm all ear
[16:51:41 CET] <ubitux> i will ignore anyone suggesting IDA
[16:53:41 CET] <atomnuker> I thought compilers would be smart enough to know to optimize that out
[16:53:51 CET] Action: atomnuker should stop thinking compilers have ESP
[17:26:13 CET] <funman> ubitux: there are objdump beautifiers, not sure if they'd make diff look better though
[18:39:55 CET] <Timothy_1u> mpv has a twitter account?
[18:44:15 CET] <wm4> it does?
[18:45:16 CET] <Timothy_1u> lol
[18:45:17 CET] <Timothy_1u> https://twitter.com/mpv_player
[18:49:08 CET] <J_Darnley> You don't exist or you're just a spammer if you don't have a Twatter account.
[18:54:51 CET] <cone-149> ffmpeg 03Rostislav Pehlivanov 07master:ec0719264cb9: aac: temporarily un-share aac_table_init AVOnce variable
[19:14:48 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:ef9f7bbfa473: avcodec/hevc: Check entry_point_offsets
[19:24:30 CET] <cone-149> ffmpeg 03Ganesh Ajjanagadde 07master:8453095f3eb8: avcodec/aac_tablegen: make exp2_lut static
[19:35:44 CET] <wm4> atomnuker: what do you mean by initializing the table twice?
[19:36:12 CET] <nevcairiel> both aacenc and aacdec init the same table
[19:36:39 CET] <wm4> so a race condition of the kind init_once is supposed to prevent?
[19:36:41 CET] <nevcairiel> but that can be improved with careful fixing
[19:37:01 CET] <nevcairiel> shouldnt really hurt, init twice is usually safe, as long as the data isnt volatile
[19:37:17 CET] <nevcairiel> and it can be fixed with more careful pthread_once use
[19:40:04 CET] <Daemon404> [14:33] <@Daemon404> just share the var used by ff_thread_once
[20:54:20 CET] <ubitux> funman: do you know any?
[21:13:43 CET] <nevcairiel> Daemon404: thats what he did, and it was wrong =p
[21:16:40 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:75422280fbcd: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_decode*()
[21:16:41 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:feb3f39614b8: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_encode*()
[21:56:22 CET] <funman> ubitux: no, i know there was one somewhere on rockbox website but couldn't find it again
[22:26:44 CET] <cone-149> ffmpeg 03Rostislav Pehlivanov 07master:6b407551588b: aacenc: fix broken build with hardcoded tables
[22:36:34 CET] <Timothy_1u> nevcairiel: something weird happening with http://fatebeta.ffmpeg.org/log/x86_32-msvc14-dll-windows-native/20151127205634/test
[22:37:04 CET] <Timothy_1u> libavdevice/avdevice.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x308
[22:37:07 CET] <Timothy_1u> /c/Dev/ffmpeg/fate/x86_32-msvc2015-shared/src/tests/api/Makefile:17: recipe for target 'tests/api/api-flac-test.exe' failed
[22:39:11 CET] <fritsch> libavdevice/avdevice.dll <- 0 byte by chance?
[23:56:21 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:d5028f61e44b: avcodec/hevc_cabac: Fix multiple integer overflows
[23:56:22 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:36205501ba2f: avcodec/pthread_slice: Allow calling ff_alloc_entries() multiple times to readjust the entry count
[23:56:23 CET] <cone-149> ffmpeg 03Michael Niedermayer 07master:d85aa7611521: avcodec/hevc: allocate entries unconditionally
[00:00:00 CET] --- Sat Nov 28 2015