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

[burek]

[00:03:11 CEST] <kierank> don't you live in hamburg?
[00:03:27 CEST] <kierank> wasn't there a vlc meeting there
[00:03:32 CEST] <kierank> at google hamburg?
[00:03:40 CEST] <nevcairiel> i do, and no idea
[00:03:47 CEST] <Daemon404> nevcairiel is the competetition
[00:03:56 CEST] <kierank> loool
[00:03:58 CEST] <kierank> yeah true
[00:04:11 CEST] <kierank> so is chrome in a way
[00:04:13 CEST] <nevcairiel> what do i care, i dont make a player
[00:04:31 CEST] <nevcairiel> well $work does, but its an entirely different target audience than vlc
[00:06:52 CEST] <Daemon404> nevcairiel, wrong. vlc's target audience: https://trac.videolan.org/vlc/ticket/35
[00:07:29 CEST] <nevcairiel> as long as they dont have a full media library and 10ft browsing interface, its not that audience =p
[00:08:21 CEST] <cone-448> ffmpeg 03Paul B Mahol 07master:2778fdbe5424: swscale: implement YA8 output
[01:27:44 CEST] <rcombs> does Benoit Fouet hang out on IRC?
[01:50:37 CEST] <kierank> erm
[02:45:23 CEST] <klaxa> okay, i have a round of patches ready and i want to send them with git send-email, but i'm afraid i will generate a lot of noise if i do it incorrectly
[02:45:47 CEST] <klaxa> i sent test emails to myself but they do not appear correctly in the thread
[02:46:10 CEST] <klaxa> does --in-reply-to require the patches to be sent to the mailing list for it to be displayed correctly?
[02:46:40 CEST] <c_14> You need the message you're replying to in your inbox.
[02:46:47 CEST] <klaxa> well it is
[02:47:18 CEST] <c_14> Are you sure the in-reply-to is correct?
[02:47:43 CEST] <klaxa> i copy pasted it, but i'll try again with it as a command line parameter, git send-email asked me for it so i figured i could also use that
[02:48:27 CEST] <klaxa> maybe you can confirm that the message id for this email https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/174937.html is 20150701141008.GA805947 at phare.normalesup.org ?
[02:49:31 CEST] <klaxa> using --in-reply-to as a command line option did not change the behavior :(
[02:49:41 CEST] <c_14> ye, that should be correct
[02:52:35 CEST] <c_14> If it's a final or close-to-final version, you could probably just resend the whole patchset as a new thread.
[03:39:45 CEST] <cone-722> ffmpeg 03wm4 07master:1316df7aa98c: lavu: add an API function to return the Libav version string
[03:39:45 CEST] <cone-722> ffmpeg 03Michael Niedermayer 07master:e15e78f391ab: Merge commit '1316df7aa98c4784f190d107206d0bb12c590b89'
[03:44:07 CEST] <jamrial> michaelni: IMO having both libavutil/ffversion.h and avversion.h is silly. we should probably choose one and get rid of the other
[03:45:45 CEST] <jamrial> or maybe moving ffversion.h to top level dir
[03:48:01 CEST] <michaelni> i didnt mere avversion.h except the cleanup code but feel free to improve/change
[03:50:45 CEST] <cone-722> ffmpeg 03Vittorio Giovara 07master:910247f1720c: lavc: Deprecate avctx.{inter,intra}_quant_bias
[03:50:46 CEST] <cone-722> ffmpeg 03Michael Niedermayer 07master:a8ab64d2f700: Merge commit '910247f1720c6aae422723c05dac6d0b19f20bec'
[03:51:40 CEST] <jamrial> michaelni: my bad, saw you merged the distclean addition but not the actual part that creates the header
[03:54:56 CEST] <jamrial> as in, saw the distclean addition, so i assumed you merged it all. didn't notice the rest wasn't there
[03:55:14 CEST] <jamrial> it's good as is, then
[03:55:48 CEST] <michaelni> good
[03:58:43 CEST] <cone-722> ffmpeg 03Alexandra Hájková 07master:9752d2e6cc9b: asfdec: prevent possible memory leak in the asf_read_metadata_obj
[03:58:44 CEST] <cone-722> ffmpeg 03Michael Niedermayer 07master:7755a5744005: Merge commit '9752d2e6cc9b9e8070ec515db8ed8374683d0856'
[04:06:01 CEST] <cone-722> ffmpeg 03Alexandra Hájková 07master:016cac75c606: asfdec: prevent the infinite loop in detect unknown_subobject
[04:06:02 CEST] <cone-722> ffmpeg 03Michael Niedermayer 07master:30ffbeb04abd: Merge commit '016cac75c6061a1c03f812ddf258b8baefe70b00'
[04:14:41 CEST] <cone-722> ffmpeg 03Andreas Cadhalpun 07master:76d4c62734fb: webp: Make sure enough bytes are available
[04:14:42 CEST] <cone-722> ffmpeg 03Andreas Cadhalpun 07master:0762152f7af6: webp: fix infinite loop in webp_decode_frame
[04:14:43 CEST] <cone-722> ffmpeg 03Michael Niedermayer 07master:3ffa38580190: Merge commit '76d4c62734fbb8a9f497712812f30ff5c27e787f'
[04:37:03 CEST] <cone-722> ffmpeg 03Luca Barbato 07master:80f955c90867: vda: Check the correct pointer for buffer allocation
[04:37:04 CEST] <cone-722> ffmpeg 03Michael Niedermayer 07master:daff49ccf3e5: Merge commit '80f955c90867561dcce769216bc497e13281eb38'
[07:31:42 CEST] <prelude2004c> hey everyone
[07:31:47 CEST] <prelude2004c> question.. i dont know if this is a bug or not
[07:31:59 CEST] <prelude2004c> i am using nginx with rtmp 
[07:32:33 CEST] <prelude2004c> when i try to publish something with ffmpeg > nginx's rtmp stream server it goes very very slow
[07:32:43 CEST] <prelude2004c> complaining about realtime not working or something
[09:03:34 CEST] <prelude2004c> looking for some help
[09:03:37 CEST] <prelude2004c> anyone around ?
[09:23:27 CEST] <durandal_1707> prelude2004c: ?
[10:08:44 CEST] <mateo`> hello there o/ i'm wondering if there is a conveniant way to get the plane width given a specific pixel format and the plane number (and not the linesize allocated by av_frame_get_buffer) ?
[10:10:02 CEST] <durandal_1707> mateo`: see filters, like vf_ssim
[10:12:13 CEST] <mateo`> durandal_1707: thanks for the reference
[10:15:31 CEST] <mateo`> durandal_1707: so it's just a matter of rshiftting the frame width with log_chroma_w ?
[10:17:39 CEST] <wm4> that's wrong
[10:17:49 CEST] <wm4> it needs to be a rounding-up rshift at least
[10:18:11 CEST] <wm4> (because the awful way ffmpeg handles cropped video, you can get odd widths with subsampled yuv)
[10:24:15 CEST] <mateo`> my goal is relatively simple i would like to be able to copy an AVFrame to disk (or a chunk of memory containing the whole frame)
[10:25:40 CEST] <mateo`> i'm looping through each plane, but i need to retreive the actual width to copy and not the linesize
[10:26:29 CEST] <nevcairiel> then just get the pixfmt descriptor, it tells you the subsampling factor
[10:26:37 CEST] <nevcairiel> and apply it to the width
[10:28:34 CEST] <durandal_1707> mateo`: filters use FF_CEIL_RSHIFT and that is correct
[10:31:44 CEST] <mateo`> nevcairiel: the subsampling factor is stored as log2_chroma_w and log2_chroma_h right ?
[10:31:55 CEST] <nevcairiel> yea
[10:34:02 CEST] <mateo`> thanks a lot for your help guys.
[10:34:45 CEST] <wm4> <mateo`> my goal is relatively simple i would like to be able to copy an AVFrame to disk (or a chunk of memory containing the whole frame) <- rawvideo encoder/muxer?
[10:38:04 CEST] <mateo`> wm4: I want to avoid to go that route since i only want to perform a color conversion using swscale to which I provide an AVFrame allocated on my side
[11:55:23 CEST] <cone-987> ffmpeg 03Paul B Mahol 07master:b74ebd09c719: avfilter/vf_lut: >8 bit depth planar yuv support
[12:48:54 CEST] <durandal_1707> wtf nv16 without any support in swscale
[13:18:48 CEST] <cone-987> ffmpeg 03Michael Niedermayer 07master:8f4cfda9721f: avutil: add missing bswap include
[13:18:49 CEST] <cone-987> ffmpeg 03Rostislav Pehlivanov 07master:8e607c747eca: aacpsy: use a different metric for the spread of a band
[13:30:06 CEST] <cone-987> ffmpeg 03Rostislav Pehlivanov 07master:57848ef3c6a1: aaccoder: fix M/S coding
[14:54:56 CEST] <kierank> durandal_1707: yes
[14:55:00 CEST] <kierank> I wrote that
[14:55:07 CEST] <kierank> because x264 accepts interleaved chroma
[16:20:18 CEST] <cone-987> ffmpeg 03Rostislav Pehlivanov 07master:9f4f5787046d: aacenc: reset marked IS and M/S bands upon frame encoding
[17:07:17 CEST] <asdf293472938748> Hi. I have some MPEG-4 Part 2 encoder hardware that I'm trying to decode with ffmpeg. It seems to be producing VLCs which the decoder doesn't recognise. Wondered if there was anyone here familiar with MPEG-4 whom I could ask some advice from?
[18:16:20 CEST] <cone-987> ffmpeg 03Michael Niedermayer 07master:d554715f673d: avcodec/jpeg2000dec: Fix decoding of subsampled multi tile images
[18:32:52 CEST] <cone-987> ffmpeg 03Michael Niedermayer 07master:9f653e6d369b: avcodec/j2kenc: Support user specified tile dimensions
[18:34:39 CEST] <cone-987> ffmpeg 03Paul B Mahol 07master:d3836b603e7e: avfilter/af_astats: export metadata
[18:34:40 CEST] <cone-987> ffmpeg 03Paul B Mahol 07master:c0d676f9773a: avfilter/af_astats: implement recalculation of stats after each X frames
[19:03:08 CEST] <cone-987> ffmpeg 03Paul B Mahol 07master:94cfb6db7d6c: avcodec/shorten: use init_get_bits8()
[19:03:09 CEST] <cone-987> ffmpeg 03Paul B Mahol 07master:866404df2d46: avfilter/vf_lut: fix oversight
[19:59:47 CEST] <durandal_1707> michaelni: just webserver or others too?
[20:00:57 CEST] <michaelni> others too, except fate server (which is seperate) and git which is on videolan
[20:13:17 CEST] <Compn> arpi hosted for a few years, dang server switch time.
[20:15:19 CEST] <Compn> humm why didnt michael's mail hit rtmpdump list
[20:15:23 CEST] <Compn> not in mod queue either
[20:18:39 CEST] <kierank> michaelni: how many RU and how much bandwidth?
[20:18:49 CEST] <kierank> or do you need hw too
[20:19:35 CEST] <j-b> michaelni: you're using mailman, right?
[20:19:48 CEST] <michaelni> j-b, yes
[20:20:00 CEST] <michaelni> kierank, we need new hw too if we have to move
[20:20:07 CEST] <kierank> specs?
[20:21:02 CEST] <michaelni> mom, i forgot some stuff must write a 2nd mail, ill also list what i know about specs
[20:21:32 CEST] <kierank> I have a LOT of servers
[20:21:35 CEST] <kierank> that are doing nothing
[20:21:36 CEST] <kierank> like 50
[20:21:42 CEST] <kierank> but they are old and probably waste electricity
[20:21:52 CEST] <Compn> we use a lot of bandwidth 
[20:22:08 CEST] <kierank> got 250meg here
[20:24:17 CEST] <Compn> dont remember how much data / month though. i've been out of the loop
[20:24:30 CEST] <michaelni> i need to subscribe to rtmpdump list it rejects my mails 
[20:26:51 CEST] <Compn> everyone is also modded  on that list so will have to approve mails manually.
[20:35:14 CEST] <nevcairiel> Daemon404: can we remove -strict -1 requirement for 422/444 x265 encoding by now?
[20:39:45 CEST] <kierank> ohohohoho
[20:39:47 CEST] <kierank> 300 cad
[20:39:48 CEST] <kierank> lool
[20:44:28 CEST] <J_Darnley> Hell, I'd spend 290 of that 300 to buy a computer that I can test on just to earn the remaining 10
[20:44:50 CEST] <nevcairiel> i have all the hardware, but why would i care
[20:47:15 CEST] <J_Darnley> it is money
[20:50:51 CEST] <nevcairiel> not enough to care
[20:53:59 CEST] <wm4> I once accidentally got a 100¬ ffmpeg bounty for implementing something which someone else happened to want
[20:54:09 CEST] <wm4> but I didn't claim it because it sounds like a pain to do so
[21:00:50 CEST] <durandal_1707> and you prefer to be anonymous
[21:12:23 CEST] <Mista_D> Upped to $500 CAD, just encoding and VPP scaling at least.
[21:18:34 CEST] <cone-987> ffmpeg 03Vittorio Giovara 07master:832129431fd5: lavu: Add version information for av_version_info()
[21:18:35 CEST] <cone-987> ffmpeg 03Michael Niedermayer 07master:d563e13a7c7d: Merge commit '832129431fd5c693b12c32a1563944c631feaf36'
[21:41:54 CEST] <wm4> what is AV_PIX_FMT_AYUV16?
[21:42:09 CEST] <wm4> is it what I think it is?
[21:42:22 CEST] <wm4> and why does it have 16 in the name?
[21:42:52 CEST] <wm4> oh, so it's packed 4:4:4 yuv with alpha and 16 bits per component
[21:42:57 CEST] <wm4> is there a 8 bit variant?
[21:42:59 CEST] <wm4> durandal_1707: ping
[21:44:03 CEST] <durandal_1707> there is also 8 bit variant.....
[21:44:22 CEST] <wm4> what's its name?
[21:44:43 CEST] <durandal_1707> ayuv
[21:46:02 CEST] <durandal_1707> maybe instead of 16 it should be 64
[21:47:20 CEST] <wm4> there's no ayuv
[21:47:33 CEST] <wm4> is it a pending patch?
[21:48:26 CEST] <cone-987> ffmpeg 03Vittorio Giovara 07master:7a5902c556d8: lavc: Disable deprectation warnings coming from options table
[21:48:27 CEST] <cone-987> ffmpeg 03Vittorio Giovara 07master:f046c3b5ac36: lavc: Move deprecation warning disabling to files including the table
[21:48:28 CEST] <cone-987> ffmpeg 03Michael Niedermayer 07master:3b03186d5679: Merge commit 'f046c3b5ac36848cce824b008e0347c621523041'
[21:48:39 CEST] <durandal_1707> what? this one?
[21:51:35 CEST] <wm4> 8 bit 4:4:4 packed
[21:53:25 CEST] <durandal_1707> no
[21:54:18 CEST] <durandal_1707> maybe yuva ones how are they put in tiffs
[23:18:49 CEST] <cone-987> ffmpeg 03Michael Niedermayer 07master:ab80d3fb3a75: swscale/output: fix null pointer dereference in yuv2ya8_2_c()
[23:44:07 CEST] <philipl> durandal_1707: the vdpau 444 formats are 8bit yuva and ayuv (or was it avuy?)
[23:44:35 CEST] <philipl> no vdpau implementation supports them yet.
[23:50:30 CEST] <durandal_1707> dunno, this one is for "apple" 
[00:00:00 CEST] --- Sat Jul  4 2015