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

[burek]

[01:44:57 CET] <cone-650> ffmpeg 03Lou Logan 07master:11817c3316d9: doc/indevs: document libdc1394 options
[01:58:36 CET] <cone-650> ffmpeg 03Lauri Kasanen 07master:1046cba24be4: swscale/output: VSX-optimize nbps yuv2plane1
[04:08:35 CET] <cone-650> ffmpeg 03James Almer 07master:0e833f615b59: avcodec/libdav1d: add support for 12bit streams
[12:51:18 CET] <durandal_1707> how to reset frame number in encoder AVCodecContext?
[12:51:41 CET] <durandal_1707> from outside, via avformat_*
[17:09:53 CET] <durandal_1707> ubitux: currently gif encoding via image2 muxer is broken, i fixed it on top of my patch by adding user option to encoder - there is no way to signal from muxer to encoder that instead?
[17:11:43 CET] <ubitux> no idea
[17:47:47 CET] <ubitux> durandal_1707: that duplicated offsetting logic is ugly
[17:48:11 CET] <ubitux> i'd rather have the offsetting computation factored-out in a function and re-used
[17:48:22 CET] <ubitux> (patch 2/6)
[17:53:36 CET] <durandal_1707> ubitux: i do not see how
[18:28:31 CET] <JEEB> > The x32 subarchitecture may be removed
[18:28:34 CET] Action: JEEB claps
[18:30:19 CET] <atomnuker> good riddance
[18:32:56 CET] <iive> JEEB, macosx ?
[18:33:05 CET] <JEEB> linux kernel
[18:33:13 CET] <JEEB> x32 wasn't really a thing elsewhere I thought?
[18:33:32 CET] <iive> is that the 32bit code executed in 64bit mode?
[18:33:46 CET] <JEEB> > it runs the processor in the 64-bit mode, but uses 32-bit pointers and arithmetic. The idea is to get the advantages of x86-64 without the extra memory usage that goes along with it.
[18:34:07 CET] <JEEB> except it came so late to the party nobody really cared about the overhead :P
[18:34:15 CET] <JEEB> https://sites.google.com/site/x32abi/
[18:34:27 CET] <iive> yeh. it never took off.
[18:51:42 CET] <ePirat> JEEB, iirc apple does it for its new watch or something
[19:43:16 CET] <durandal_1707> atomnuker: why are you against fixing that serious bug in opus encoder?
[19:49:00 CET] <atomnuker> its not a serious bug
[19:49:43 CET] <atomnuker> there might be a small difference but we still decode the testvectors correctly (according to one interpretation)
[19:50:16 CET] <atomnuker> to begin with checking for that bug would involve checking the entire celt part of the decoder against the reference
[19:50:40 CET] <nevcairiel> he said encoder
[19:50:42 CET] <durandal_1707> ENCODER
[19:51:08 CET] <atomnuker> ah
[20:10:16 CET] <atomnuker> why the hell is the afq adding the overlap into remaining_samples on init?
[20:11:32 CET] <durandal_1707> you coded it that way?
[20:13:19 CET] <atomnuker> no, it was justing ruggles, who went to vimeo never to be heard from again
[20:13:59 CET] <durandal_1707> atomnuker: where is that code?
[20:14:01 CET] <atomnuker> I think its a hack to adjust the delay (and hence the timestamps), and it wasn't taken into account the very first frame might be null and the encoder might depend on the afq
[20:14:08 CET] <atomnuker> audio_frame_queue.c
[20:33:01 CET] <atomnuker> grr, I'd rather not touch anything related to afq or rely on its proper initialization to check whether to flush, as that'll nullify its error-detection logic
[20:33:34 CET] <atomnuker> I'll do it via the encoder state
[21:10:00 CET] <cone-980> ffmpeg 03Rostislav Pehlivanov 07master:83db1efd42bd: opusenc: fix infinite loop if flushing encoder upon init
[22:38:00 CET] <thardin> duckduckgo bought on2's old duck.com
[22:40:30 CET] <JEEB> classic level domain :)
[22:41:38 CET] <gnafu> Time to update all my bookmarks.
[23:54:52 CET] <cone-980> ffmpeg 03Carl Eugen Hoyos 07master:32601fb82117: lavfi/signalstats: Cast the return value of AV_RN16() to int.
[00:00:00 CET] --- Thu Dec 13 2018