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

[burek]

[01:04:10 CEST] <michaelni> rcombs, ubitux if i should apply any srtdec patch, then please tell me, i didnt follow the discussion
[01:30:49 CEST] <rcombs> michaelni: I sent a new one to fix the unknown case, but I'm not sure if anybody's reviewed it yet
[01:34:56 CEST] <michaelni> rcombs, ok, ill wait, but ping me if noone reviews then ill take a look
[01:53:56 CEST] <cone-545> ffmpeg 03Zhang Rui 07master:f477a3f5abc1: avformat/async: support filling with a background thread.
[02:03:46 CEST] <cone-545> ffmpeg 03Luca Barbato 07master:fc5686839921: cosmetics: Reformat checkasm tests
[02:03:47 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:b1861f18b6e3: Merge commit 'fc56868399213d3e9be19bdebeb64df233b39a7e'
[02:19:27 CEST] <krieger-od> Sorry for spamming, guys. Here's request for paid help with H264 http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175796.html . Urgent for me.
[02:21:20 CEST] <Compn> krieger-od : is ok, we like paid work :)
[02:22:38 CEST] <cone-545> ffmpeg 03Janne Grunau 07master:256ef1984489: h264: arm: use intra pred8x8 functions only for chroma_format_idc <= 1
[02:22:38 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:c0894e628814: Merge commit '256ef19844892c6cf8e0386e3287bae970ec6320'
[02:31:07 CEST] <cone-545> ffmpeg 03Henrik Gramner 07master:6cc4d3e9a982: checkasm: exit with status 0 instead of 1 if there are no tests to perform
[02:31:08 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:cb33f8d0f48b: checkasm: Give macro a body to avoid potential unexpected syntax issues
[02:31:09 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:78274b19f163: Merge commit '6cc4d3e9a982e926494f4b919d9733fe29774acf'
[02:31:10 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:3ad30d1bc061: Merge commit 'cb33f8d0f48b1e9d642ca1cbea142dcbedd08a27'
[02:38:55 CEST] <cone-545> ffmpeg 03Janne Grunau 07master:82e6ac85ff9a: checkasm: test all architectures with optimisations
[02:38:56 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:e6b01480e563: Merge commit '82e6ac85ff9aa7631b8c01521b3d6b5ca0bc8014'
[03:07:57 CEST] <michaelni> krieger-od, the sizes of the frames look a bit odd, one would expect IDR frames to be bigger than the following P frames
[03:08:12 CEST] <michaelni> that would be for normal encoded content
[03:08:36 CEST] <michaelni> but then test_main.h264 is not "normal" content either
[03:10:49 CEST] <michaelni> the bigger frames contain a 00 00 01 B0 and dont end in a 00 00 while the smaller frames end in 00 00
[03:14:08 CEST] <michaelni> decoding fr.joined.h264 shows "NAL 16/5 at 12442/21952 length 9509", that looks like it shouldnt be there
[03:14:45 CEST] <michaelni> also it might be that you need to pass these frames through the startcode escaping code but i dont think that the main problem
[03:17:11 CEST] <michaelni> also you can use -ec 0 when decoding to avoid the error concealment
[03:17:42 CEST] <michaelni> and -debug 1 / -debug 257 when decoding might print usefull info
[03:18:34 CEST] <cone-545> ffmpeg 03Janne Grunau 07master:c9f8cfb6d9b3: fate: add checkasm target
[03:18:35 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:9010be252e57: Merge commit 'c9f8cfb6d9b34f3c51f1b7152c4dc3f2f8724dc4'
[03:38:12 CEST] <krieger-od> michaelni: thanks for interest. According to sizes, i think keyframes are ones with index (i*4 + 1). vlc_00 is not a keyframe, but vlc_01 is. I don't know what is in vlc_00..
[04:27:49 CEST] <BBB> michaelni: I dont think it was mplayer that caused the fork :)
[04:50:09 CEST] <jamrial> nevcairiel: sf is still down but the mirror for msys2 works now
[05:07:32 CEST] <cone-545> ffmpeg 03Ganesh Ajjanagadde 07master:f6870495e158: avformat: increase first_frames threshold for mp3,ac3
[05:23:29 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:f8e4d37983f8: avcodec/hevc_ps: Also print depth in failure path of map_pixel_format()
[08:23:01 CEST] <ubitux> michaelni: haven't looked yet
[08:33:07 CEST] <durandal_1707> what?
[10:59:46 CEST] <cone-937> ffmpeg 03Michael Niedermayer 07master:2927b61c559f: avfilter/af_dynaudnorm: Use av_frame_get_channels()
[10:59:46 CEST] <cone-937> ffmpeg 03Michael Niedermayer 07master:129785b5e8ab: avutil/frame: Update AVFrame docs library references
[12:09:14 CEST] <cone-937> ffmpeg 03Michael Niedermayer 07master:3197c0aa87a3: avcodec/rv34: Clear pointers in ff_rv34_decode_init_thread_copy()
[13:29:14 CEST] <cone-937> ffmpeg 03Michael Niedermayer 07master:a194298954e9: avformat/movenc: Drop redundant bit exact field from context
[14:13:39 CEST] <suom1> Hello, are you guys still in need of hosting? :)
[14:15:49 CEST] <J_Darnley> last I heard was there there are a few separate offers
[14:16:19 CEST] <J_Darnley> wait for michaelni to reply or send an email
[14:16:44 CEST] <J_Darnley> in the meantime you can see the public discussion on the ffmpeg-devel list
[14:16:50 CEST] <suom1> Well if they do not fall through DreamHack (www.dreamhack.se) is happy to help! :) 
[14:18:08 CEST] <suom1> We use ffmepg so much so would be stupid of us not to help if needed :) 
[14:18:27 CEST] <BBB> Compn: nobody can guarantee that any person will be around for any amount of time in the future
[14:19:08 CEST] <BBB> Compn: besides, you could say I was evil around fork time
[14:19:42 CEST] <J_Darnley> suom1: if you haven't seen the discussion: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175048.html
[14:20:44 CEST] <BBB> isnt dreamhack that gaming thing?
[14:20:48 CEST] <suom1> yep :) 
[14:20:55 CEST] <suom1> Worlds largest LAN :) 
[14:21:04 CEST] <suom1> But we do a lot of esport productions nowdays :) 
[14:21:11 CEST] <BBB> right, thats what I meant
[14:21:17 CEST] <BBB> you guys use ffmpeg for recording or so?
[14:21:22 CEST] <BBB> (or streaming?)
[14:21:23 CEST] <suom1> for example at the moment in Valencia :) 
[14:21:27 CEST] <suom1> yeah :)
[14:21:51 CEST] <BBB> cool
[14:24:39 CEST] <kierank> suom1: do you know jonas bengsson?
[14:25:40 CEST] <suom1> kierank: sure :)
[14:25:53 CEST] <suom1> he works for twitch nowdays tho, but a good friend of mine.
[14:29:27 CEST] <justinfront> Hi really offtopic question I am trying to write an opensource encoder for gif from scratch and getting stuck on encoding gif's bigger than about 90x90, I have the basics working, I am wondering if anyone in here might know about gif encoding since I know ffmpeg is all about encoding and decoding, anyone willing to take a look and give me some pointers?  
[14:31:21 CEST] <justinfront> It's probably not in a language you have used before.
[14:31:21 CEST] <suom1> michaelni: let me know if hosting is needed, we can solve it for the project :) 
[14:37:27 CEST] <kierank> suom1: I think dream hack connectivity might not be good enough =p
[14:37:35 CEST] <suom1> it should be :D 
[14:37:38 CEST] <suom1> hopefully :D 
[14:39:07 CEST] <justinfront> Is it ok to post the github I don't want to spam if you think no one would be interested but kind of stuck and thought that this channel might be full of experts.
[14:41:08 CEST] <phh> justinfront: what language ?
[14:41:18 CEST] <justinfront> haxe
[14:42:38 CEST] <justinfront> so potentially the code would work in a range of languages
[14:46:53 CEST] <justinfront> at moment testing in neko, but once it's working fully should be feasible to tweak it to run in js, php, c#, java, c++, python, flash.
[14:53:52 CEST] <J_Darnley> justinfront: I don't know how many can specifically help you with your problem it doesn't hurt to tell us more.
[14:54:18 CEST] <J_Darnley> Like: what exactly fails when you try to encode a 91x91 image?
[14:55:29 CEST] <justinfront> This is a gif randomly generated 90x90 any bigger and I get single color pixels https://raw.githubusercontent.com/Justinfront/BitsAndBytes/master/bin/test.gif  the 90x90 is probably approximate and depends 
[14:56:09 CEST] <justinfront> This is my writter https://github.com/Justinfront/BitsAndBytes/blob/master/gif/Writer.hx
[14:56:47 CEST] <justinfront> width and height are hardcoded at the top.
[14:57:31 CEST] <justinfront> This is my current LZW loop which is probably a bit nieve https://github.com/Justinfront/BitsAndBytes/blob/master/gif/output/Lzw.hx
[14:58:07 CEST] <J_Darnley> I would suggest encoding a specific pattern so you can see whether anything works right
[14:58:18 CEST] <justinfront> pixel blocks get written here https://github.com/Justinfront/BitsAndBytes/blob/master/gif/output/PixelBlocks.hx
[14:58:18 CEST] <J_Darnley> and then what size are all these "var" variables?
[14:59:08 CEST] <justinfront> I know it writes correctly at least with simple 10x10 four color sample eg: https://github.com/Justinfront/BitsAndBytes/blob/master/src/TestGif.hx
[15:00:24 CEST] <justinfront> this image is from the tutorial I was following.  Currently it outputs correctly if I amend the pixel dimensions and this line https://github.com/Justinfront/BitsAndBytes/blob/master/gif/Writer.hx#L47
[15:01:18 CEST] <justinfront> haxe is fully typed but infered
[15:01:26 CEST] <justinfront> 90 would be int
[15:02:12 CEST] <justinfront> 90.0 would be float
[15:02:24 CEST] <justinfront> Int and Float I mean
[15:05:07 CEST] <justinfront> If anyone wants to try the code I can talk through setup.  I was following these tutorials. http://www.matthewflickinger.com/lab/whatsinagif/bits_and_bytes.asp
[15:05:43 CEST] <justinfront> the TestGif.hx is the image in the tutorial.
[15:06:26 CEST] <J_Darnley> I can't make heads or tails of this, and I know nothing about gif encoding so good luck.
[15:12:40 CEST] <justinfront> well basically you just use an integer for every color, then you encode that array using a modified LZW algorithm.   So you store repeated patterns in a dictonary with an integer for each pattern. The integers are encoded as binary using minimal bits and you tell it when you have had to increase the number of bits for storage as the number needed to be as binary increases.  These are stored...
[15:12:42 CEST] <justinfront> ...as subblocks as explained on second page of tutorial http://www.matthewflickinger.com/lab/whatsinagif/lzw_image_data.asp
[15:18:58 CEST] <J_Darnley> Can't you just write it in C?
[15:21:29 CEST] <justinfront> I don't code c :) plus with haxe I can potentially use it in a range of places ( js, c etc.... ) I have a pathfinding library I wanted to created animated gif from it. Wrapping gif encoding in Haxe prob is not hard but once it's in Haxe it's only nominally a bit slower but it starts to work anywhere.
[15:33:44 CEST] <justinfront> I mean to say if I just wrap a gif c++ encoder to use with Haxe it would only work for c++ not js.  But if I code it in Haxe then should be feasible for it to work in js as well.
[15:35:08 CEST] <phh> you can compile c++ to js
[15:37:21 CEST] <justinfront> well for general code haxe is a much faster language to develop in.
[15:37:44 CEST] <phh> and slower to execute
[15:39:01 CEST] <phh> and since you'll NIH, you'll always have bug, while you could just write a binding from a standard gif library
[15:42:10 CEST] <phh> (though the argument "I want to learn" is acceptable enough for me)
[15:45:49 CEST] <justinfront> There is currently a haxe gif decoder I needed an encoder I don't find it easy or flexible wrapping solutions for multiple targets, there is currently png and jpeg encode and decoders so seemed sensible to attempt a gif encoder. 
[15:47:47 CEST] <phh> isn't there an llvm target to haxe ?
[15:47:53 CEST] <justinfront> https://github.com/HaxeFoundation/format/tree/master/format   some of the encoders and decoders are limited.  
[15:48:13 CEST] <justinfront> in targets
[15:48:26 CEST] <justinfront> I think there was an attempt at a llvm
[15:49:24 CEST] <justinfront> https://github.com/PeyTy/Native  there is one here but I doubt if it's very usable
[15:51:23 CEST] <justinfront> https://github.com/waneck/haxe-genc  but that creates c and is still in progress. 
[15:52:31 CEST] <justinfront> I was hoping there might be an expert on gif format, was not coming here to promote my fav language :)
[15:52:36 CEST] <phh> i meant compile TO haxe
[15:52:37 CEST] <phh> not from
[15:53:03 CEST] <justinfront> there is a transpiler for go to haxe
[15:53:29 CEST] <J_Darnley> justinfront: sorry if we gave you that impressions.  I didn't think you were here to shill haxe.
[15:53:37 CEST] <justinfront> https://tardisgo.github.io/
[15:54:48 CEST] <justinfront> sure Darnley just if someone is asking me lots of questions on haxe I don't want the channel to feel I am going off topic or anything beyond my quest to get somewhere with gif's
[15:56:33 CEST] <justinfront> some irc channels are really relaxed about off topic stuff others not so much so just not wanting to be clear that on my reason for being here.
[15:56:54 CEST] <justinfront> oops I got me sentence wrong. 
[15:57:30 CEST] <justinfront> think I am going to resort to analysing byte codes of other encoders and mine!
[15:59:06 CEST] <phh> i'd rather say add logs to any decoder and understand what the decoder is complaining about
[16:00:56 CEST] <justinfront> It just outputs a single color after so many pixels in images I open. So there is something I need to change so readers can understand it.
[16:01:30 CEST] <justinfront> probably reaching a limit on subblocks per section or something
[16:02:01 CEST] <J_Darnley> It does sound like some value is overflowing
[16:25:03 CEST] <michaelni> suom1, yes, we still need some hosting+server that everyone is happy with, see ffmpeg-devel ML
[16:28:34 CEST] <suom1> michaelni: i have read the thread, however I am not sure exactly whats needed :) 
[16:30:56 CEST] <michaelni> well, i think primarely something everyone is happy with, a neutral hoster/provider, long term and robust solution, in a country that is not too hostile to free multimedia software
[16:31:22 CEST] <suom1> Ok, I guess its best if I answer in that thread then :) 
[16:31:50 CEST] <suom1> And we will see what people think :)
[16:32:21 CEST] <michaelni> yes, the actual hw we would need in terms of specs is probably nothing special, 64gb 4tb 500mbps was quoted but thats probably way above what we actually need
[16:33:05 CEST] <michaelni> our average traffic based on the last weeks was IIRC 100gbyte per day
[16:33:34 CEST] <suom1> bandwidth isnt a problem :) 
[16:33:51 CEST] <michaelni> our previous server had 16gb ram and that wasnt a problem but 64 would be nice for virtualization
[16:35:00 CEST] <suom1> okey :)
[16:51:49 CEST] <suom1> email sent :) 
[18:06:37 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07master:1c5b712c0a64: avcodec/diracdec: Check for hpel_base allocation failure
[18:08:09 CEST] <durandal_1707> yet another audio filter is complete
[19:38:06 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07master:a84f0e8d8f29: avcodec/vp8: Fix null pointer dereference in ff_vp8_decode_free()
[19:38:07 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07master:599d746e0731: avcodec/vp8: Check buffer size in vp8_decode_frame_header()
[20:11:06 CEST] <Compn> suom1 : i like your offer at dreamhack, although i cant speak for the project.
[20:14:05 CEST] <Compn> BBB : yes well i never heard anything from janne about libav/ffmpeg after that, except for him saying he would not help git after mpcodecs was committed (i think?). i just dont want to be hosted by someone who still has strong feelings about it
[20:14:25 CEST] <Compn> which is what mans, diego and atilla all had when they were admins
[20:15:12 CEST] <Compn> also dont want ffmpeg drama to ruin videolan :P
[20:15:35 CEST] <Compn> we're a fiesty bunch...
[20:24:37 CEST] <D404|Ghetto> 20:15 < Compn> also dont want ffmpeg drama to ruin videolan :P <-- it has plenty of its own for now
[20:24:40 CEST] <D404|Ghetto> iirc.
[20:24:45 CEST] <D404|Ghetto> we can fll it up later
[20:31:22 CEST] <suom1> :)
[20:40:40 CEST] <j-b> D404|Ghetto: like?
[20:41:07 CEST] <cone-487> ffmpeg 03Paul B Mahol 07master:e03cb1e115b4: fate: add test for mergeplanes filter
[20:46:13 CEST] <cone-487> ffmpeg 03Rob Sykes 07release/2.7:d403242a289a: swresample: soxr implementation for swr_get_out_samples()
[20:46:14 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:e40688ed807f: swr: Remember previously set int_sample_format from user
[20:46:15 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:12aa4220dd1f: swscale/rgb2rgb_template: Disable shuffle_bytes_2103_c on big endian
[20:46:16 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:2af2c7ecff2c: swscale/rgb2rgb_template: Implement shuffle_bytes_0321_c and fix shuffle_bytes_2103_c on BE
[20:46:17 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:f5c880cecb19: swscale/rgb2rgb_template: Fix signedness of v in shuffle_bytes_2103_c()
[20:46:18 CEST] <cone-487> ffmpeg 03Sebastien Zwickert 07release/2.7:ce3a8c983f6e: vda: unlock the pixel buffer base address.
[20:46:19 CEST] <cone-487> ffmpeg 03James Almer 07release/2.7:3f06023bd248: swscale/x86/rgb2rgb_template: fix signedness of v in shuffle_bytes_2103_{mmx,mmxext}
[20:46:20 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:483a02e25f7b: ffmpeg: Do not use the data/size of a bitstream filter after failure
[20:46:21 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:d1f8eaf3d2b0: swscale/swscale_unscaled: Fix rounding difference with RGBA output between little and big endian
[20:46:22 CEST] <cone-487> ffmpeg 03Andreas Cadhalpun 07release/2.7:254fabe758a4: wmavoice: limit wmavoice_decode_packet return value to packet size
[20:46:23 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:e84d17c7c991: avcodec/pngdec: Only allow one IHDR chunk
[20:46:24 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:be54d1f1043e: avcodec/pngdec: Require a IHDR chunk before fctl
[20:46:25 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:cccb06b09573: avcodec/pngdec: Copy IHDR & plte state from last thread
[20:46:26 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:f775a92054a4: avcodec/pngdec: Check values before updating context in decode_fctl_chunk()
[20:46:27 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:a9c3b588af74: avcodec/mjpegdec: Fix small picture upscale
[20:46:28 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:0afb004d3cc4: avcodec/h264_refs: discard mismatching references
[20:46:29 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:51782e86903c: avfilter/vf_transpose: Fix rounding error
[20:46:30 CEST] <cone-487> ffmpeg 03James Zern 07release/2.7:662714abbe40: vp9/update_prob: prevent out of bounds table read
[20:46:31 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:65aac419e53a: avcodec/h264_slice: Use w/h from the AVFrame instead of mb_w/h
[20:46:32 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:e740506d31e7: avcodec/aacsbr: check that the element type matches before applying SBR
[20:46:33 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:bbcf6f5c6200: avcodec/aacsbr: Assert that bs_num_env is positive
[20:46:34 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:ac91bfe08653: avcodec/rawenc: Use ff_alloc_packet() instead of ff_alloc_packet2()
[20:46:35 CEST] <cone-487> ffmpeg 03Chris Watkins 07release/2.7:151554e1eb86: Put a space between string literals and macros.
[20:46:36 CEST] <cone-487> ffmpeg 03Andreas Cadhalpun 07release/2.7:1ec0541ae05b: wmalosslessdec: avoid reading 0 bits with get_bits
[20:46:37 CEST] <cone-487> ffmpeg 03Andreas Cadhalpun 07release/2.7:c001472226c7: wmalosslessdec: reset frame->nb_samples on packet loss
[20:46:38 CEST] <cone-487> ffmpeg 03Chris Watkins 07release/2.7:2a6f2cd8486f: oggparsedirac: check return value of init_get_bits
[20:46:39 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:88fa3243ddf3: avcodec/mpegvideo: Clear pointers in ff_mpv_common_init()
[20:46:40 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:0df814cf9731: avcodec/utils: use a minimum 32pixel width in  avcodec_align_dimensions2() for H.264
[20:46:41 CEST] <cone-487> ffmpeg 03Anton Khirnov 07release/2.7:7db809a373f0: bytestream2: set the reader to the end when reading more than available
[20:46:42 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:264eb0074f3b: avcodec/alac: Clear pointers in allocate_buffers()
[20:46:43 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:237751eb257f: avcodec/sanm: Reset sizes in destroy_buffers()
[20:46:44 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:6e53134f9892: avcodec/pthread_frame: check avctx on deallocation
[20:46:45 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:441ef87ea8e0: ffmpeg: Fix cleanup with ost = NULL
[20:46:46 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:a18e8d82de87: ffmpeg: Fix crash with ost->last_frame allocation failure
[20:46:47 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:a066b2ceddc6: avformat/mov: Fix deallocation when MOVStreamContext failed to allocate
[20:46:48 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:2e7bd0f725c8: ffmpeg: Fix cleanup after failed allocation of output_files
[20:46:49 CEST] <cone-487> ffmpeg 03Zhang Rui 07release/2.7:a330aca126eb: avutil/fifo: Fix the case where func() returns less bytes than requested in av_fifo_generic_write()
[20:46:50 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:1cbd7b08f661: swscale/utils: Clear pix buffers
[20:46:51 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:73ebc4046e77: avcodec/pthread_frame: clear priv_data, avoid stale pointer in error case
[20:46:52 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:e693af81b7f4: avfilter/af_aresample: Check ff_all_* for allocation failures
[20:46:53 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:05684cee424a: avcodec/rv34: Clear pointers in ff_rv34_decode_init_thread_copy()
[20:46:54 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:f00f799833af: avcodec/diracdec: Check for hpel_base allocation failure
[20:46:55 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:9c655d2a57d4: avcodec/vp8: Fix null pointer dereference in ff_vp8_decode_free()
[20:46:56 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:08337cca05e6: avcodec/vp8: Check buffer size in vp8_decode_frame_header()
[20:53:39 CEST] <cone-487> ffmpeg 03Paul B Mahol 07master:efd4e5fe6820: avfilter/vf_blend: implement 16bit support
[21:07:39 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07release/2.7:4a6ac71742e0: Update for FFmpeg 2.7.2
[21:22:13 CEST] <durandal_1707> libmpcodecs have been removed
[21:37:43 CEST] <BBB> yes thank goodness
[21:38:11 CEST] <BtbN> time for libgstcodecs!
[21:40:24 CEST] <cone-487> ffmpeg 03Ganesh Ajjanagadde 07master:e3e4f1752c1c: doc/developer: add url for sample files
[21:52:01 CEST] <BBB> BtbN: gstreamer has no codecs, for patent reasons
[21:52:04 CEST] <BBB> or so?
[21:52:16 CEST] <BBB> it always links to external libraries for codecs anyway
[21:52:37 CEST] <BtbN> It has plenty of interesting codecs that aren't available somewhere else
[21:52:40 CEST] <BtbN> like the vaapi encoders
[21:53:58 CEST] <BBB> right but theyre hw codecs, so theyd take tons of effort to add
[21:54:03 CEST] <BBB> might just as well do it natively then
[21:54:28 CEST] <BtbN> That's why it has to be wrapped!
[21:57:02 CEST] <Compn> gst wrapper would be accepted i think if someone sent patch :P
[21:57:04 CEST] <BBB> I mean the wrapping would take tons of effort
[21:57:15 CEST] <Compn> also be nice to have binary codec loader in ffmpeg ;)
[22:00:09 CEST] <BtbN> a wine based dshow wrapper!
[22:02:53 CEST] <durandal_1707> Compn: neva
[22:03:57 CEST] <durandal_1707> michaelni: what was that stalled gbrp16 output?
[22:06:02 CEST] <durandal_1707> swscale need to do everything internally with floats or it will die
[22:08:20 CEST] <durandal_1707> wm4: when you will relicense vapoursynth filter?
[22:08:52 CEST] <michaelni> adding support for floats could be done
[22:09:59 CEST] <michaelni> dont remember about gbrp16
[22:10:54 CEST] <durandal_1707> but it appears as lot of work
[22:11:47 CEST] <wm4> durandal_1707: should I? nobody has asked yet
[22:12:24 CEST] <jamrial> http://pastebin.com/fR2U3dM1 good job ICC
[22:12:30 CEST] <michaelni> floats should be alot easier than the existing fixed point code as no overflow / preission tuning is needed
[22:25:12 CEST] <durandal_1707> wm4: count me as one who asked
[22:36:26 CEST] <ubitux> jamrial: lol
[22:36:42 CEST] <BBB> jamrial: sweet
[22:36:44 CEST] <ubitux> icc managed to put 2 bswap in the 6 one
[22:36:55 CEST] <ubitux> 64*
[22:37:36 CEST] <BBB> I bet this is non-inlined also
[22:37:59 CEST] <BBB> since it actually goes from abi register 0 (edi) to return (eax), which could be skipped for a inline version
[22:38:14 CEST] <BBB> (so gcc would go from 2 to 1 instr)
[22:39:47 CEST] <ubitux> jamrial: to its defense, there is no optimized !gcc for x86
[22:39:50 CEST] <philipl> BtbN: But we have QSV as our vaapi encoder wrapper of choice :-)
[22:39:56 CEST] <ubitux> jamrial: how does gcc managed to optimize the c version?
[22:43:58 CEST] <BtbN> philipl, still not exactly a fan of that
[22:47:22 CEST] <philipl> Well, at least QSV is already a sunk cost from the windows side.
[22:48:11 CEST] <jamrial> ubitux: guess it realized that all those shifts + ors from av_bswap*() ultimately meant a 32 or 64 bit bswap
[22:48:12 CEST] <BtbN> I still haven't managed to propperly setup that lib though
[22:48:38 CEST] <philipl> I've never tried.
[22:48:39 CEST] <jamrial> gcc 4.4 and older generate similar code as ICC, so it's a relatively recent optimization
[22:49:26 CEST] <jamrial> for that matter, https://gcc.godbolt.org/
[22:49:28 CEST] <jamrial> really fun to play with
[22:52:12 CEST] <jamrial> BBB: yeah, neither was inlined
[22:52:37 CEST] <J_Darnley> I think I used that once (or something like it) and it bitched about -march=i686 not being a valid x86 option
[22:53:11 CEST] <jamrial> the gcc compilers it provides all target x86_64
[22:53:17 CEST] <jamrial> i686 is not a valid target for it
[22:53:26 CEST] <jamrial> use -m32 if you want x86_32 code
[22:53:31 CEST] <durandal_1707> anyone have time to do something for me?
[22:53:58 CEST] <J_Darnley> It probably wasn't that then.  It said x86 not x86_64
[22:57:37 CEST] <durandal_1707> does tblend crash for you on smp?
[22:58:47 CEST] <jamrial> can you give a sample command line to test that?
[23:00:51 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07master:a9c1545a33c5: avformat/mpegtsenc: support storing PAT/PMT per frame
[23:00:52 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07master:34da54fd1aeb: avformat/mpegtsenc: Support a user specified PAT/PMT period
[23:01:19 CEST] <durandal_1707> J_Darnley: Just add -vf tblend for start
[23:01:34 CEST] <J_Darnley> wrong j<tab>
[23:03:05 CEST] <Compn> rip jdilla
[23:03:43 CEST] <jamrial> durandal_1707: doens't crash for me. one thread or two threads give the same output as well
[23:05:56 CEST] <durandal_1707> jamrial: and -vf tblend=all_mode=difference128
[23:06:42 CEST] <jamrial> same
[23:12:50 CEST] <Compn> why arent we just hardcoding the asm instead of using C code then if icc/gcc cant optimize it ?
[23:13:04 CEST] <Compn> or this is already done with yasm... but is it done for everything?
[23:13:36 CEST] <Compn> depends on cpu , but why not just have .asm for all cpus... maybe too bloated?
[23:13:42 CEST] <Compn> too many dumb questions, better hide
[23:16:28 CEST] <jamrial> Compn: we could add icc optimized versions using _bswap and _bswap64 (intel intrinsics that don't need any special header inclusion)
[23:16:40 CEST] <jamrial> or make it use the inline asm version in the x86 folder
[23:18:17 CEST] <J_Darnley> I thought bswap was one of ffmpeg's inline functions so you don't want to call a function just to run 1 instruction
[23:18:39 CEST] <jamrial> it is, av_bswap
[23:34:02 CEST] <cone-487> ffmpeg 03Michael Niedermayer 07master:b5e716ae1322: avformat/mpegtsenc: Add sdt_period, similar to pat_period
[23:47:07 CEST] <cone-487> ffmpeg 03Paul B Mahol 07master:5c7f708683ac: fate: add tblend filter test
[23:47:08 CEST] <cone-487> ffmpeg 03Paul B Mahol 07master:9a829a2b6a7a: avfilter/vf_blend: unbreak tblend
[23:48:17 CEST] <durandal_1707> shit
[23:49:09 CEST] <durandal_1707> guess fate will become yellow
[23:52:17 CEST] <wm4> lol
[00:00:00 CEST] --- Sun Jul 19 2015