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

[burek]

[00:00:08 CET] <nevcairiel> if this is a one time thing, might be better to just use the ALLYES macro directly there?
[00:01:08 CET] <nevcairiel> $(call ALLYES, $(call ENCDEC2...) CRYPTO_PROTOCOL)
[00:23:58 CET] <rcombs> nevcairiel: I was doing that at first but it ends up a really long macro chain
[00:23:59 CET] <rcombs> nevcairiel: and you can't call ENCDEC2 in the middle of an ALLYES call
[00:23:59 CET] <rcombs> so I figure this might be useful for ~something~ else in the future
[00:24:25 CET] <nevcairiel> why not
[00:26:00 CET] <rcombs> ALLYES expects a list of CONFIG_<x> names
[02:59:37 CET] <cone-333> ffmpeg 03Michael Niedermayer 07master:07225fa74f2c: avcodec/opusdec: Fix extra samples read index
[02:59:37 CET] <cone-333> ffmpeg 03Kieran Kunhya 07master:b3e5f15b95f0: opusdec: Don't run vector_fmul_scalar on zero length arrays
[03:59:28 CET] <jamrial> atomnuker: ubsan complains about overreads in fate-aac-ltp-encode
[03:59:52 CET] <jamrial> atomnuker: http://fate.ffmpeg.org/report.cgi?time=20151026151841&slot=x86_64-archlinux-gcc-ubsan
[04:40:16 CET] <atomnuker> Daemon404: "tests/aac: Add bitexact flags to AAC LTP Encode test"
[04:40:29 CET] <atomnuker> why?
[04:49:15 CET] <cone-333> ffmpeg 03Rostislav Pehlivanov 07master:e6f99520aa07: FATE: Slightly increase thresholds on prediction AAC encoding tests
[04:49:46 CET] <atomnuker> when did they start failing, I could have sworn they were fine around last week
[04:50:19 CET] <atomnuker> no, I was sure they were fine, I always stare at FATE for a few hours after I push
[05:50:50 CET] <cone-333> ffmpeg 03James Almer 07master:d897d4c12de8: x86/vf_w3fdif: use aligned loads in w3fdif_complex_high
[07:25:12 CET] <cone-333> ffmpeg 03Timothy Gu 07master:9b40ce5a4548: avcodec: srtdec: Reindent
[07:25:13 CET] <cone-333> ffmpeg 03Timothy Gu 07master:87d55092611f: avfilter: Reindent
[07:25:14 CET] <cone-333> ffmpeg 03Timothy Gu 07master:852c4b3d42c7: drawutils: Reindent
[07:25:15 CET] <cone-333> ffmpeg 03Timothy Gu 07master:b9cd3e1add3a: srtenc: Reindent
[07:47:59 CET] <Timothy_Gu> atomnuker: 06:34 < michaelni> maybe 9->10 results in a difference in bit allocation
[07:48:02 CET] <Timothy_Gu> 06:34 <@ubitux> i doubt ident would affect stddev & psnr :p
[07:48:04 CET] <Timothy_Gu> 06:35 < michaelni> as its one byte longer
[07:48:05 CET] <Timothy_Gu> 06:40 <@ubitux> indeed, if i remove put_bitstream_info(s, LIBAVCODEC_IDENT), it fixes fate
[07:48:09 CET] <Timothy_Gu> 06:35 < michaelni> but just guessing
[07:48:11 CET] <Timothy_Gu> [...]
[07:49:52 CET] <Timothy_Gu> (they were referring to https://github.com/FFmpeg/FFmpeg/commit/035ae3c0096f6c0a3f199d331ed4094ff5beafd1 which makes the IDENT one byte longer)
[08:38:43 CET] <atomnuker> ffs, now clang on darwin reports a failure on the LTP test because it's off by 4.32 units
[08:39:03 CET] <atomnuker> is the core really that tricky to compile?
[08:39:27 CET] <atomnuker> it might be better off just making the inner loop a separate function
[08:39:45 CET] <atomnuker> s/core/code
[08:43:27 CET] <cone-333> ffmpeg 03Rostislav Pehlivanov 07master:af71c73fb42f: FATE: Increase FUZZ value on AAC LTP encoding test
[08:45:13 CET] <atomnuker> yet on my machine both Clang and GCC produce the same PSNR result
[09:25:06 CET] <nevcairiel> atomnuker: the reason they started failing is apparently that the encoder ident got one byte longer which slightly changed bit allocations
[09:25:22 CET] <nevcairiel> thats why bitexact was added, it disables the ident
[10:27:22 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:31741aecbf99: avcodec: disallow hwaccel with frame threads
[10:27:38 CET] <nevcairiel> in before more feedback about that commit in the next day than the last week it was up for review =p
[10:32:48 CET] <wm4> of course
[10:32:56 CET] <wm4> and everyone will hate you!
[10:34:35 CET] <j-b> +1
[12:21:09 CET] <cone-333> ffmpeg 03AppChecker 07master:8199908fdf9b: fix: assigning instead of comparing
[12:21:10 CET] <cone-333> ffmpeg 03Kyle Swanson 07master:15d8b6512552: doc/filters.texi: ebur128 grammar fix
[12:23:20 CET] <nevcairiel> now automated tools are contributing? :p
[12:42:13 CET] <cone-333> ffmpeg 03Vittorio Giovara 07master:dca23ffbc756: lavc: Deprecate AVPicture structure and related functions
[12:42:14 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:0bcb17d44e3c: Merge commit 'dca23ffbc7568c9af5c5fbaa86e6a0761ecae50c'
[12:42:43 CET] <cone-333> ffmpeg 03Martin Storsjö 07master:e02dcdf6bb68: rtsp: Allow $ as interleaved packet indicator before a complete response header
[12:42:44 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:12e95d156ae9: Merge commit 'e02dcdf6bb6835ef4b49986b85a67efcb3495a7f'
[12:49:01 CET] <cone-333> ffmpeg 03Martin Storsjö 07master:5ea5a24eb706: movenc: Honor flush requests with delay_moov, when some tracks lack samples
[12:49:02 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:368e5216464f: Merge commit '5ea5a24eb70646a9061b85af407fcbb5dd4f89fd'
[12:49:22 CET] <cone-333> ffmpeg 03Luca Barbato 07master:1ec72c6c68db: libx264: Make sure the extradata are padded
[12:49:23 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:e7a57d4873e1: Merge commit '1ec72c6c68dbc78bf4ebb6f06c13316dc488bdfa'
[12:54:36 CET] <cone-333> ffmpeg 03Luca Barbato 07master:22f4d9c303ed: img2enc: Make sure the images are atomically written
[12:54:37 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:7daac50067cb: Merge commit '22f4d9c303ede1a240538fd105c97047db40dc86'
[12:59:09 CET] <cone-333> ffmpeg 03Luca Barbato 07master:18f9308e6a96: mpjpeg: Cope with multipart lacking the initial CRLF
[12:59:10 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:b95b8e5a2269: Merge commit '18f9308e6a96bbeb034ee5213a6d41e0b6c2ae74'
[13:41:51 CET] <cone-333> ffmpeg 03Martin Storsjö 07release/2.8:3f3e12c76812: rtsp: Allow $ as interleaved packet indicator before a complete response header
[13:42:11 CET] <cone-333> ffmpeg 03Paul B Mahol 07master:a66243a2014c: avformat/aiff: add ADP4 DVI ADPCM support
[13:50:44 CET] <Compn> so many pcm codecs
[13:51:29 CET] <cone-333> ffmpeg 03Arttu Ylä-Outinen 07master:233d2fa04431: kvazaar: Add libkvazaar HEVC encoder
[13:51:30 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:8dde5dc05ae2: Merge commit '233d2fa0443197df12b4f7823d591dad964149b3'
[14:01:00 CET] <Daemon404> atomnuker, it only fails on SOME machines
[14:01:04 CET] <Daemon404> without the bitexact flag
[14:01:41 CET] <cone-333> ffmpeg 03Vittorio Giovara 07master:533a6198505e: innoHeim/Rsupport Screen Capture Codec decoder
[14:01:42 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:8b3228a329bb: Merge commit '533a6198505edd1379e1cd722852350ae4a85acc'
[14:01:56 CET] <cone-333> ffmpeg 03Michael Niedermayer 07master:f0a88d4d2a74: mpegvideo_enc: Factor new_picture unref out
[14:01:57 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:1174eb2f1015: Merge commit 'f0a88d4d2a74534460f4a8b79c448bd5890dbd41'
[14:02:13 CET] <cone-333> ffmpeg 03Michael Niedermayer 07master:27eeee76b254: mpegvideo_enc: Merge ifs with identical conditions
[14:02:14 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:a4b5ada36bec: Merge commit '27eeee76b2546fd313808997b3d07ba9cce94551'
[14:05:06 CET] <JEEB> not using bitexact reminds me of certain conversions being different on diff arches :)
[14:05:09 CET] <JEEB> *archs
[14:06:09 CET] <cone-333> ffmpeg 03Alexis Ballier 07master:447b5b278c68: mpegvideo_enc: Fix encoding videos with less frames than the delay of the encoder
[14:06:10 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:0a830b95d597: Merge commit '447b5b278c689b21bbb7b5747c8773145cbd9448'
[14:07:02 CET] <cone-333> ffmpeg 03Vittorio Giovara 07master:3c5cf2a31b4b: screenpresso: Drop parameter change check
[14:07:03 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:564eabeebb1e: Merge commit '3c5cf2a31b4b29a8e4282cbe6a3f0617c14698b8'
[14:07:23 CET] <cone-333> ffmpeg 03Vittorio Giovara 07master:fe66671bd5f4: cmdutils: Check for and report the correct codec capability
[14:07:24 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:fe41f28c3a43: Merge commit 'fe66671bd5f446f8d0a9c70968ba8fe891efe028'
[14:07:39 CET] <cone-333> ffmpeg 03Tom Butterworth 07master:9f5d6f460cee: hap: Set avctx.bits_per_coded_sample
[14:07:39 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:af7c7037150d: Merge commit '9f5d6f460ceeda8b4ac29b3249a49e275b64c706'
[14:08:29 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:9cbae3a7d57b: roqvideodec: use av_frame_copy
[14:08:31 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:5fe157857136: Merge commit '9cbae3a7d57bd2b862c37fd8123bd1fba680e801'
[14:10:59 CET] <cone-333> ffmpeg 03Luca Barbato 07master:f0ca6ffa0ae5: avprobe: Unref the packet once it is used
[14:11:00 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:fe3c22e0c00b: Merge commit 'f0ca6ffa0ae5d5564516ee7a18aa1e234751444a'
[14:15:49 CET] <cone-333> ffmpeg 03Luca Barbato 07master:a5d42043093a: avformat: Always return ref-counted AVPacket
[14:15:50 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:856b19d5935b: Merge commit 'a5d42043093a39636a1f4021a37dd9c612479f6f'
[14:22:51 CET] <mateo`> is it correct to call ff_get_format from the decoder's init function where i'm actually initializing the decoder. Also I can't specify a software pixel format when calling the function because the decoder will take this decision after it has been configured, i'm about to use AV_PIX_FMT_NONE as second choice; can it be an issue regarding the api ?
[14:26:24 CET] <mateo`> On an another side, i will declare a public AVMediaCodecContext that will only hold a reference to a surface created by the user but i won't allow the user to create the codec itself. Is that an issue ? I've looked at other implementations videotoolbox/qsv and it looks like the public struct let the user creates the session and the other required parameters but i don't think it's useful in the
[14:26:26 CET] <mateo`> mediacodec case
[14:33:38 CET] <cone-333> ffmpeg 03Luca Barbato 07master:ce70f28a1732: avpacket: Replace av_free_packet with av_packet_unref
[14:33:39 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:7f5af80ba42b: Merge commit 'ce70f28a1732c74a9cd7fec2d56178750bd6e457'
[14:38:43 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:c2f861ca42fa: Replace remaining occurances of av_free_packet with av_packet_unref
[14:59:17 CET] <wm4> mateo`: you should be able to call ff_get_format at any point at init or after it
[14:59:51 CET] <wm4> I don't understand the other questions
[15:00:01 CET] <wm4> what would AV_PIX_FMT_NONE do here?
[15:02:14 CET] <mateo`> before I configure the decoder, i need to call ff_get_format to retreive the hwaccel from where I will look if the user has provided a surface which will be used to configure the decoder
[15:02:34 CET] <mateo`> however it is not mandatory as the decoder can output cpu buffers
[15:03:36 CET] <mateo`> If no surface is provided by the user, the decoder will output cpu buffers. The decoder decide the pixel format it will use only after it has been configurer
[15:04:45 CET] <wm4> this should be decided by whether ff_get_format returns a sw surface
[15:07:00 CET] <mateo`> so i will pass AV_PIX_FMT_MEDIACODEC to ff_get_format, but i don't know which other sw pix fmt to pass to it since i don't have that information yet
[15:08:12 CET] <wm4> then do it when you know this
[15:10:16 CET] <mateo`> i will only have that information when the decoder is configured, and if you want to use a surface as output you need to pass it to the configure function
[15:31:06 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:75c3e54d1cb0: asfdec: fix FATE seek test
[15:43:57 CET] <cone-333> ffmpeg 03Hendrik Leppkes 07master:6255bf3d0d2e: mpegts: Fix FATE seek test
[15:54:30 CET] <nevcairiel> my fate is being weird
[15:54:35 CET] <nevcairiel> at first it doesnt find those problems there
[15:54:42 CET] <nevcairiel> now it bugs out on two tests which have no reason to bug out
[15:54:44 CET] <nevcairiel> :(
[15:56:35 CET] <durandal_1707> which one?
[15:57:14 CET] <nevcairiel> lavf-ffm and lavf-mxf_opatom
[15:57:20 CET] <nevcairiel> i did a full clean and rebuild right now
[15:57:21 CET] <nevcairiel> lets see
[15:58:10 CET] <nevcairiel> hm nope still happening, but some online fate systems that already build those dont complain
[15:58:13 CET] <nevcairiel> i'm so confused
[16:08:49 CET] <nevcairiel> anyother full rebuild and it passed
[16:08:53 CET] <nevcairiel> i should give up for today
[16:08:56 CET] <nevcairiel> all is weird
[17:11:03 CET] <Daemon404> [FFmpeg-devel] [PATCH 1/1] avcodec/png: read and write stereo3d frame side data information
[17:11:06 CET] <Daemon404> vlc support men
[17:11:06 CET] <Daemon404> er
[17:11:09 CET] <Daemon404> s/men/when/
[18:13:01 CET] <Compn> the vf_stereo serialization patch has an ifdef test, is this normal or debug code that should be removed? i dont remember the policy...
[18:22:00 CET] <nevcairiel> #ifdef TEST is quite normal, it used to compile the testing tools
[18:36:39 CET] <Compn> ok then thanks
[18:47:00 CET] <oldtimer> Hi everyone!
[18:47:05 CET] <oldtimer> Just a quick question: Does anyone know of a video format supporting "ping-pong" playback?       (play forward until end, then reverse play order and play backwards, and forward again, etc.)
[18:48:43 CET] <nevcairiel> files are generally not very well s uited for reading backwards, but you could do it with any format that is only key frames and has a full index to address every frame independently
[18:49:59 CET] <Daemon404> i would just encode all the frames twice and loop it
[18:50:04 CET] <Daemon404> or keep them in memory
[18:50:05 CET] <flux> I don't know if many very formats have the concept of infinite looping built in
[18:50:07 CET] Action: Daemon404 is lazy
[18:50:15 CET] <flux> well, actually I think most any doesn't :-)
[18:50:20 CET] <flux> maybe gifs.
[18:50:48 CET] <flux> so probably you could generate an ISO MPEG4 file that does that, ie. indeces the frames back and forth, but I don't think ffmpeg can do that out-of-the-box :). but the infinite looping remains, needs to be done outside the format.
[18:51:02 CET] <oldtimer> mh. Do any formats come to mind which tell a player to loop - at least?
[18:51:35 CET] <durandal_1707> yes, many but no backward
[18:51:58 CET] <oldtimer> format name dropping - just a few..?
[18:52:09 CET] <Daemon404> oldtimer, perhaps this is an XY problem
[18:52:11 CET] <Daemon404> what is your end goal here
[18:52:55 CET] <oldtimer> I'd like to find a good start, then dig into the specs to see how they implement their "loop trigger"
[18:52:57 CET] <durandal_1707> oldtimer: they are audio only, ...
[18:53:39 CET] <oldtimer> I had only GIF coming to mind, but an audio format telling players too loop? which one?
[18:54:23 CET] <durandal_1707> BRSTM among many
[18:55:33 CET] <Daemon404> it really depends what your end goal is
[18:55:39 CET] <Daemon404> which "player"
[18:55:40 CET] <Daemon404> etc
[18:56:29 CET] <oldtimer> BRSTM, Binary Revolution Stream??, that's so obscure I've never heard of it (and the Internets doesn't know it either... rigbht? docs?)
[18:57:08 CET] <jamrial> oldtimer: it's a video game audio format. most implement loop
[18:57:31 CET] <oldtimer> specs anywhere to be found?
[18:57:59 CET] Action: Daemon404 still thinks this is an XY problem
[18:58:23 CET] <durandal_1707> brawl music something
[18:59:47 CET] <durandal_1707> afaik there is creator somewhere
[19:02:04 CET] <durandal_1707> anyone for libsequencer
[19:02:07 CET] <durandal_1707> ?
[19:02:18 CET] <Daemon404> maybe atomnuker 
[19:02:31 CET] <kierank> durandal_1707: oh god
[19:02:34 CET] <kierank> not this again
[19:02:56 CET] <oldtimer> I'll go and investigate audio formats - thanks guys -  and'll do a bit of meditation about the X of my XY problem ;)
[19:02:58 CET] <durandal_1707> why?
[19:05:14 CET] <jamrial> oldtimer: http://wiibrew.org/wiki/BRSTM_file
[19:05:37 CET] <Daemon404> i would not advocate using anythign adpcm based
[19:05:42 CET] <jamrial> not exactly an official spec, though
[19:05:59 CET] <oldtimer> ah! thanks. (reading...)
[19:06:17 CET] <TD-Linux> oh no this is the old wii adpcm format
[19:06:32 CET] <Compn> flux : there are i think zero players that can even play files backwards... maybe some video editors.
[19:06:49 CET] <Daemon404> this is why i asked what his end goal is
[19:06:55 CET] <Daemon404> e.g. browsers can loop mp4s with a bit of js.
[19:06:57 CET] <TD-Linux> maybe I can add a loop flag to daala. it will be its killer feature.
[19:07:03 CET] <Compn> lol
[19:07:19 CET] <TD-Linux> Daemon404, you don't even need js, loop="true" in the <video> element
[19:07:23 CET] <Compn> videodj software maybe..
[19:07:44 CET] <kierank> time for the big one, fuzzing h264 with alf
[19:07:46 CET] <kierank> afl*
[19:07:50 CET] <kierank> mp2 seemed reasonable
[19:08:52 CET] <jamrial> oldtimer: also http://wiibrew.org/wiki/AST_file
[19:09:52 CET] <jamrial> it's not mentioned there, but the element in offset 0xE is the loop flag, and the one in 0x1C is "loop end"
[19:10:03 CET] <TD-Linux> the wii formats are in adpcm because there is dedicated hardware to stream ADPCM off the disk to the audio hardware
[19:10:24 CET] <TD-Linux> you wouldn't want to burn all that CPU decoding ADPCM
[19:11:16 CET] <durandal_1707> but that was in old days wham CPU where slow
[19:11:28 CET] <Daemon404> TD-Linux, ah 
[19:11:28 CET] <oldtimer> ah, of course, looping is mostly not whole file only but also in/out-marks - forgot about that - as in sampling software, so you have an attack and release...
[19:11:48 CET] <TD-Linux> Daemon404, also only at 32000hz sample rate
[19:14:18 CET] <jamrial> current gen of consoles instead said "fuck it, we have 50gb of blu ray space, so lets ship PCM audio" to save CPU cycles, since the APUs they feature are lacking
[19:15:35 CET] <jamrial> the result? NBA 2k14 weighs ~7gb. NBA 2k15 weighs ~37gb
[19:16:04 CET] <atomnuker> and to think 10 years ago there were soundcards that shipped with 64 megs of RAM for audio files
[19:16:04 CET] <durandal_1707> lol
[19:16:32 CET] <jamrial> I have one of those!
[19:16:32 CET] <atomnuker> (only Quake 4 and Doom 3 ever used that additional memory and IIRC it was still not enough)
[19:16:35 CET] <jamrial> Creative X-Fi
[19:17:01 CET] <atomnuker> do you turn the Crystalizer on? you know, to make bits out of nowhere and make 16 sound like 24 bits
[19:17:14 CET] <atomnuker> they marketed the hell out of it
[19:17:32 CET] <jamrial> No, i use ASIO or Wasapi with bitexact output enabled when i listen to audio
[19:17:55 CET] <atomnuker> yeah, I wouldn't trust what creative do
[19:17:58 CET] <oldtimer> thanks for some pointers.. I'm off.
[19:18:23 CET] <atomnuker> I think X-fi had some problems with resampling everything to 48000 khz, or maybe it was the Audigy 2
[19:18:59 CET] <jamrial> i bought it for hardware accel audio on games (DirectSound, OpenAL). Unfortunately Vista showed up and killed that for DirectSound
[19:19:17 CET] <atomnuker> ALchemy?
[19:19:27 CET] <jamrial> Then the Xbox 360 showed up with XAudio2, and nobody used OpenAL anymore
[19:19:33 CET] <jamrial> Tried it, way too buggy
[19:19:53 CET] <jamrial> With Anno 1404 i'd get all kinds of random sounds coming from the speakers
[19:20:32 CET] <atomnuker> it worked for Diablo 2, which is the only thing I really tried it with when I had my Audigy 2
[19:20:40 CET] <atomnuker> and System Shock 2
[19:22:59 CET] <TD-Linux> jamrial, actually I think the reason PCM audio is so common is because game devs usually roll their own everything, and including libraries in the weird SDKs is hard
[19:24:02 CET] <kierank> halo had vorbis audio
[19:25:04 CET] <TD-Linux> yeah most games that cared were vorbis, because it is free and supports gapless looping. also stb_vorbis helped the popularity
[19:25:37 CET] <TD-Linux> *games that care, it's still the most common format for PC titles
[19:27:07 CET] <durandal_1707> but really there is bunch of sequenced formats and no library to rule them all
[19:38:28 CET] <kierank> boom h264 crashes found
[19:38:36 CET] <kierank> 16 mins in
[19:38:39 CET] <kierank> a new record
[19:40:24 CET] <durandal_1707> you use how many frames and resolution?
[19:40:40 CET] <kierank> some cif file
[19:40:47 CET] <kierank> and cut it at 500kB
[19:40:51 CET] <kierank> and afl
[19:42:00 CET] <kierank> interestingly can't reproduce
[19:42:53 CET] <durandal_1707> yes, I used AFL for ffv1 and fvl a little
[19:43:18 CET] <durandal_1707> Run under valgrind?
[19:46:07 CET] <kierank> might be because of afl memory limit
[19:46:14 CET] <kierank> lemme change to 1gb max
[19:49:55 CET] <kierank> durandal_1707: do you use threading as well
[19:50:00 CET] <kierank> in afl?
[19:51:13 CET] <durandal_1707> No, I disable it, but that will obviously hide some bugs
[19:51:52 CET] <durandal_1707> I mean both in AFL and ffmpeg
[19:52:13 CET] <kierank> ok
[19:54:29 CET] <durandal_1707> but you should really try to AFL with asan
[19:56:29 CET] <kierank> can't say i've ever got asan to work
[20:11:57 CET] <kierank> BBB: can you publish your slides somewhere from vdd
[20:12:19 CET] <BBB> I thought I blogged them?
[20:12:33 CET] <BBB> https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/
[20:13:23 CET] <kierank> the other slides
[20:17:23 CET] <kierank> 1200k fps, 1200k tbn, 1200k tbc
[20:17:24 CET] <kierank> lol
[20:18:44 CET] <BBB> either your content is highly professional, or your tool is somewhat questionable
[20:23:01 CET] <kierank> more trashed files
[20:28:24 CET] <Lectem> hi, just to make sure, sending a mail for a patch using a git clone is ok even if I dont attach the patch ? as long as I give the commit url
[20:32:12 CET] <kierank> Lectem: eh?
[20:32:28 CET] <kierank> git format-patch or git-send-email
[20:34:40 CET] <Lectem> ok, cause the website stated "Committing changes to a git clone, for example on github.com or gitorious.org. And asking us to merge these changes." so at first I thought Pull Requests were accepted, but then saw that most of them were ignored
[20:35:26 CET] <BtbN> Whatever the one merging your changes is fine with.
[20:37:59 CET] <Lectem> ok thanks
[20:38:52 CET] <Lectem> there's a patch I'm really sure of submiting or not, involving new versions of msys2
[20:39:05 CET] <Lectem> the configure script doesnt recognize the uname
[20:40:50 CET] <Lectem> I was thinking of adding it https://github.com/FFmpeg/FFmpeg/blob/master/configure#L4413 and https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3356
[20:40:54 CET] <Lectem> will it be enough?
[20:41:42 CET] <Lectem> (I mean, that worked for me but I'm not sure if its the right approach)
[20:43:01 CET] <Daemon404> adding which
[20:43:18 CET] <Daemon404> if the uname is 'msys*', youre compiling from the wrong shell
[20:44:14 CET] <Lectem> well msys2/bin is in my path so I usually just need cmd
[20:44:50 CET] <Lectem> is it expected that we'd use the mingw* shell instead?
[20:45:07 CET] <Daemon404> msys2 has 3 shell launches
[20:45:16 CET] <Daemon404> the one called 'msys2 shell' is for compiling /for/ msys2
[20:45:27 CET] <Daemon404> which is a special compiler, and shouldnt be used
[20:45:59 CET] <Daemon404> https://www.dropbox.com/s/ms43ca12c48tbhf/shells.png?dl=0
[20:46:02 CET] <Daemon404> ^ dont use the top one
[20:47:56 CET] <cone-333> ffmpeg 03Michael Niedermayer 07master:9ec2b9fce188: avformat/img2enc: Disable rename&atomic writing for non file protocol and split planes
[20:49:45 CET] <Lectem> well i'm just using the windows cmd prompt + path with msys64/usr/bin 
[20:49:49 CET] <Lectem> might be the reason
[20:50:05 CET] <Daemon404> that is not supported by msys, and not supposed to work 
[20:50:26 CET] <Lectem> oh, my bad then
[20:50:37 CET] <Lectem> I used to have this setup running just fine with the basic msys
[20:52:29 CET] <Lectem> thanks anyway
[21:10:57 CET] <nevcairiel> Lectem: you can make that work again by exporting the MSYSTEM env variable, and setting it to MINGW32
[21:11:22 CET] <Daemon404> i wouldnt encourage such use myself.
[21:11:55 CET] <nevcairiel> i do that because their shell scripts suck ass
[21:12:02 CET] <nevcairiel> (and really thats all their scripts do)
[21:23:45 CET] <Timothy_Gu> what's the difference between time base and 1/frame rate?
[21:23:59 CET] <nevcairiel> they dont have to be related at all
[21:24:19 CET] <nevcairiel> MPEG-TS always has a 1/90000 time base, but can hold any number of frame rates
[21:25:05 CET] <iive> mpeg-ts have 3 clocks, one of the is system or wall-time clock.
[21:39:49 CET] <cone-333> ffmpeg 03Michael Niedermayer 07master:1b82a0052ce1: avformat/img2enc: Fix img2enc atomic implementation to work with split planes
[22:53:15 CET] <cone-333> ffmpeg 03Andreas Cadhalpun 07master:eaa6bade377a: avcodec: install avdct.h as public header
[22:53:31 CET] <Timothy_Gu> huh I'm confused then. What is time base in general?
[22:53:52 CET] <kierank> it's a scale in which timestamps are represented
[22:54:14 CET] <nevcairiel> indeed
[22:54:33 CET] <nevcairiel> if it was 1/1, then 1 would be 1 second, 2 would be 2 seconds, etc
[22:54:42 CET] <nevcairiel> f its 1/1000, then 1 is 1 millisecond
[22:54:44 CET] <nevcairiel> and so on
[22:55:08 CET] <nevcairiel> it defines the scale and precision of the timestamps
[22:55:32 CET] <nevcairiel> in some formats its a static value, like mpeg-ts where its always 1/90000, other formats allow setting it
[00:00:00 CET] --- Wed Oct 28 2015