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

[burek]

[00:17] <BBB> ubitux: sort of& I mean it had to be done at some point
[00:17] <BBB> michaelni: sure, if you can squash thatd be great
[00:19] <michaelni> BBB, i can squash all, what should the commit message be for the result ?
[00:20] <BBB> 32bit and sse2 support for vp9 inverse transform assembly?
[00:20] <BBB> maybe with a vp9/x86: prefix
[00:46] <ac_slater> hey all. I'm really confused on the configure script in relation to libstagefright_h264. Does libavcodec/libstagefright.cpp actually get built? I just don't understand the autotools stuff for it
[00:46] <ac_slater> I have an improved version of that file but I can't really figure out how to make it work with the buildsystem
[00:51] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:4efdb29c75ba: avformat/dv: Use av_freep() to avoid leaving stale pointers in memory
[00:51] <cone-864> ffmpeg.git 03Ronald S. Bultje 07master:fd77fbb39006: vp9/x86: 32bit and sse2 support for vp9 inverse transform assembly
[00:51] <michaelni> BBB, squashed and pushed, thanks
[00:52] <BBB> yay
[00:52] <cehoyos> michaelni: Ticket 3686 was a regression, should I backport or would you prefer to wait?
[00:53] <cehoyos> ubitux: Do you have more comments about "Set the default for --shlibdir to --libdir"? I didn't understand your email...
[00:54] <michaelni> cehoyos, ive backported it locally already i think
[00:54] <cehoyos> Should be 2.2, 2.3, 2.4 and 2.5
[01:15] <timothy_gu> ac_slater: FFmpeg doesn't use autotools. It only gets built when 1. `--enable-libstagefright-h264` is passed, and 2. its existence is confirmed.
[01:16] <timothy_gu> ac_slater: See https://github.com/FFmpeg/FFmpeg/blob/master/configure#L4904-4906
[01:16] <ac_slater> timothy_gu: my mistake.
[01:17] <ac_slater> timothy_gu: right. I have no idea what that means. I see the require_cpp function... I trace that and never see it's output to any logs or anything. I dont know what the line(s) you referenced are supposed to produce
[01:18] <timothy_gu> ac_slater: did you build with --enable-libstagefright-h264
[01:18] <timothy_gu> ?
[01:18] <ac_slater> timothy_gu: yea
[01:18] <ac_slater> timothy_gu: and I have the required headers and libs
[01:18] <ac_slater> (and NDK, etc)
[01:18] <cehoyos> "grep -i stagef config.h"
[01:18] <timothy_gu> ac_slater: Can you post the config.log onto pastebin or something like that?
[01:19] <ac_slater> timothy_gu: yup one sec
[01:19] <cehoyos> grep CONFIG_LIBSTAGEFRIGHT_H264 config.h
[01:20] <ac_slater> cehoyos: yup, recompiling... one sec
[01:20] <cehoyos> No!
[01:20] <cehoyos> Just run "grep CONFIG_LIBSTAGEFRIGHT_H264 config.h"
[01:20] <cehoyos> Two lines
[01:21] <timothy_gu> No, config.h and config.log should be there after you *CONFIGURE* it. No need for recompiling.
[01:21] <timothy_gu> ac_slater: ^^
[01:21] <ac_slater> I meant configure
[01:21] <ac_slater> cehoyos: I have LIBSTAGEFRIGHT_H264 1 ... but _DECODER 0
[01:21] <ac_slater> hmm
[01:21] <ac_slater> that would probably be the issue
[01:22] <cehoyos> Then I believe you did not ".-/configure --enable-libstage..." but something more compilicated that you should only use once the simple configure line works.
[01:22] <cehoyos> There is a user-help channel and a user-help mailing list bzw
[01:22] <cehoyos> btw
[01:23] <ac_slater> cehoyos: they really only reply to the ffmpeg command line too help... never building or library stuff
[01:23] <timothy_gu> cehoyos: he's trying to develop something inside FFmpeg, so no.
[01:23] <cehoyos> That is unlikely because configure issues are much, much easier to answer
[01:23] <cehoyos> (And I try to answer - nearly - every question)
[01:23] <ac_slater> I should note I had to patch the configure script since 'libstagefright_h264' isnt a library, it should be 'libstagefright' ... pasting this
[01:24] <cehoyos> timothy_gu: Just running ./configure --enable-libstage... will work
[01:24] <ac_slater> cehoyos: well no since I have to do cross-prefix, etc
[01:24] <cehoyos> And afaict, you cannot get support as soon as you patch configure, sorry
[01:24] <timothy_gu> ac_slater: OK just post your patch and your config.log so we all can see what you are talking about
[01:25] <cehoyos> You can: Report an issue about configure on -users or send a patch to fix an issue to -devel
[01:25] <ac_slater> timothy_gu: yea workin on it. One sec. (I also patched out the so lib names... kinda nasty)
[01:25] <ac_slater> cehoyos: right, and I will once I get something that works
[01:34] <cehoyos> michaelni: I pushed the mxf memleak patch to github, should I also commit the shlibdir configure patch?
[01:35] <ac_slater> alright ... timothy_gu cehoyos  ... configure patch .. let g:netrw_dirhistmax  =10
[01:35] <ac_slater> let g:netrw_dirhist_cnt =3
[01:35] <ac_slater> let g:netrw_dirhist_1='/home/anthony/code/pixnet/zynq/old-streamer/rtsp_app'
[01:35] <ac_slater> let g:netrw_dirhist_2='/usr/share/cdm/themes'
[01:35] <ac_slater> let g:netrw_dirhist_3='/home/anthony/code/misc'
[01:35] <ac_slater> oops
[01:35] <ac_slater> onesec
[01:35] <ac_slater> goddam vim
[01:36] <ac_slater> http://paste.debian.net/136594/ ... configure patch
[01:36] <ac_slater> and ... config.log    https://bpaste.net/show/43d01e4023ae
[01:37] <ac_slater> timothy_gu: ^ cehoyos ^ 
[01:39] <cehoyos> Did you provide config.log for the patched or the unpatched configure run?
[01:39] <ac_slater> patched
[01:40] <cehoyos> So to summarize (please correct me if I am wrong): You provided a patch that cannot be applied (I suspect at least on some platforms the first hunk is simple wrong) but no information why it would be necessary.
[01:40] <cehoyos> Or am I wrong?
[01:42] <ac_slater> cehoyos: I guess I should have been more accurate in my claims. Here is the deal. The patched version of configure allows configure to succeed - since, libstagefright_h264 isnt really a thing (assuming that is something being searched for). 
[01:42] <cehoyos> ac_slater: Let me try it differently: I do believe that libstagefright wasn't tested for some time and this could be considered our fault.
[01:43] <ac_slater> cehoyos: could be. I just dont know if the ffmpeg build process actually builds the thing
[01:43] <cehoyos> But as long as we don't receive bug reports ("I tried x and expected y but received z"), it is unlikely to get fixed.
[01:43] <ac_slater> cehoyos: agreed. Im in the 'determine if this is a user error' stager
[01:43] <ac_slater> stage * 
[01:43] <ac_slater> I full plan to fix this
[01:43] <ac_slater> fully * 
[01:44] <cehoyos> And sending (or posting) patches that are not meant to be applied and that we cannot test will not help.
[01:44] <ac_slater> cehoyos: I see. 
[01:44] <cehoyos> Instead please run a minimal configure line with --enable-libstage and run the grep command and / or report your issue.
[01:45] <cehoyos> This will help finding an issue, even if we don't have a libstagefright toolchain
[01:45] <ac_slater> cehoyos: gotcha. That makes sense
[01:46] <cehoyos> And please excuse me if you consider my tone not very helpful: It is late here and I am trying to commit patches (and you remind me that we don't test libstagefright which is as said our fault imo).
[01:47] <ac_slater> cehoyos: it is true that I my approach was a little unorganized - I was surprised to actually get a response.
[01:47] <ac_slater> thanks for the help cehoyos and timothy_gu 
[01:49] <ac_slater> cehoyos: so currently, just `./configure --disable-yasm --enable-libstagefright-h264` fails with ERROR: libstagefright_h264 not found ... that is the fix my patch does.. I should say `diff` and it's not really ready to be applied - it was for demonstration 
[01:49] <cehoyos> The second hunk should be unneeded iirc, either you have to specify target-os or there is a specific option, sorry, I don't remember and I don't have an Android toolchain but it shouldn't be difficult.
[01:50] <cehoyos> And the third hunk is just wrong: It has to be "enabled libstagefright_h264 && require..."
[01:50] <ac_slater> the third hunk is the real reason to show you that
[01:50] <cehoyos> You should never use --disable-yasm unless you have a very specific reason (like a performance test).
[01:50] <ac_slater> cehoyos: which is what I'm doing
[01:51] <cehoyos> No.
[01:51] <ac_slater> cehoyos: part of it, anyway
[01:51] <cehoyos> (Afaict)
[01:51] <ac_slater> cehoyos: alright, so, ill get yasm and try again
[01:51] <cehoyos> But I don't think that there is any platform where "--disable-yasm --enable-libstagefright-h264" makes any sense whatsoever.
[01:52] <ac_slater> I dont want to argue, but it makes sense to me - mostly since stagefright is simply a wrapper - it does no format/codec operations itself
[01:53] <cehoyos> What is yuor host platform and for which platform do you want to build?
[01:53] <ac_slater> eitherway, just `./configure --enable-libstagefright-h264` fails with the same error. I came here mainly for that reason. Host = x86, Target ARMv7
[01:53] <cehoyos> Since yasm does not work for arm, --disable-yasm makes no sense in your configure line.
[01:54] <Daemon404> ... it's sounds more like you are not cross compiling correctly.
[01:54] <ac_slater> I see what you mean
[01:54] <ac_slater> Daemon404: the libraries (libavcodec, etc) are being cross compiled
[01:54] <cehoyos> I believe libstagefright does not exist for x86 so --enable-libstagefright alone is supposed to fail.
[01:54] <ac_slater> cehoyos: which is why I started with the script in the ffmpeg tree `./tools/build_libstagefright` ... I started there. 
[01:55] <ac_slater> .. and realized it's fetching is broken
[01:55] <ac_slater> so I retrieved the proper toolchain/requirements and started doing the compilation myself (with similar configure flags)
[01:55] <ac_slater> its* 
[01:55] <cehoyos> Now we are back at "yes, this is our fault but nobody complained so far".
[01:56] <cehoyos> Can't you patch tools/build... to fetch the correct things?
[01:56] <ac_slater> cehoyos: maybe ;) And ill fix it. I just need to know what the hell the configure script/buildsystem is actually doing with the libavcodec/libstagefright.cpp file
[01:56] <cehoyos> My suggestion is that you simply don't look (in no way whatsoever) at configure but only at the script in tools
[01:56] <ac_slater> cehoyos: technically no, some of the sources are not available or mirrored anywhere ... and they require you to pull libs from an actual android device
[01:58] <Daemon404> i think i see one problem
[01:58] <Daemon404> --target-os=linux <-- wrong
[01:58] <Daemon404> use =android
[01:59] <ac_slater> Daemon404 -_-
[01:59] <Daemon404> which also makes your configure patch unneeded
[01:59] <ac_slater> Daemon404: haha, trying that now
[01:59] <cehoyos> Sounds correct to me (the change)
[02:01] <ac_slater> I didnt know android was a target
[02:01] <Daemon404> yeah, configure is not very verbos about targets.
[02:01] <ac_slater> "unknown OS 'android'"
[02:01] <ac_slater> It must be my fault now.
[02:02] <ac_slater> I'm targeting ffmpeg 2.2
[02:02] <cehoyos> Which makes absolutely no sense.
[02:02] <Daemon404> oh
[02:02] <Daemon404> configure in HEAD has that.
[02:02] <ac_slater> I see it
[02:03] <ac_slater> I wonder if I can just plop it in
[02:08] <ac_slater> seems like it... still cant find libstagefright_h264 though
[02:08] <ac_slater> I still dont know what that means
[02:09] <ac_slater> ie - what is it looking for
[02:10] <Daemon404> ... is it even in your sysroot
[02:11] <ac_slater> Daemon404: yea
[02:11] <ac_slater> Daemon404: well, I guess  that's the question there. 
[02:13] <ac_slater> Daemon404: I have those headers in my sysroot, the libs it should be linking to (according to the line 4904) in my sysroot. I just cant tell if `libstagefright_h264` is a name for a rule, a library name, or ?
[02:13] <Daemon404> that config.log doesnt show it even checking for it
[02:13] <ac_slater> oh my new one does ... 
[02:13] <ac_slater> (with the HEAD's configure)
[02:14] <BBB> michaelni: one more patch for mc (sse2 support) on https://github.com/rbultje/ffmpeg/commits/vp9-32bit
[02:14] <ac_slater> Daemon404: I see the problem
[02:14] Action: Daemon404 wonders if it is related to stdc++
[02:15] <ac_slater> Daemon404: actually, the heades in android's frameworks have changed so much since the ffmpeg wrapper was written
[02:15] <Daemon404> not shocking
[02:15] <Daemon404> google is VERY bad at compat
[02:22] <ac_slater> Daemon404: it's just hard to need *some* of the source tree
[02:23] <ac_slater> apparently the only way to do this properly is to take the libs off of a running device/emulator ... and get the headers from a FULL source tree (18GB)
[02:23] <ac_slater> (since I'm linking with things I cant get source for, stagefright uses OMX and some of those libs are closed source)
[02:25] <ac_slater>  /rant
[02:31] <cone-864> ffmpeg.git 03Carl Eugen Hoyos 07master:27bdfd29f14a: lavf/mxfdec: Factorize mxf_read_close().
[02:31] <cone-864> ffmpeg.git 03Carl Eugen Hoyos 07master:4373a25d94db: lavf/mxfdec: Fix memleaks reading corrupt files.
[02:31] <ac_slater> great ... the binder header is no longer public API. :( 
[02:42] <timothy_gu> ac_slater: is there a deprecation notice somewhere
[02:44] <cone-864> ffmpeg.git 03Ronald S. Bultje 07master:cae893f692bf: vp9/x86: sse2 MC assembly.
[02:44] <ac_slater> timothy_gu: yea I saw it. I'm going to still proceed to fix this since most devices that run android I'm using still have some stable binder api.
[02:45] <timothy_gu> ac_slater: no I was asking _if_ there is any deprecation notice for the Binder API
[02:46] <ac_slater> oh, my mistake. I cant find the notice, but Binder isnt listed under STABLE-APIS.txt in the android NDK
[02:51] <cehoyos> Daemon404: Do you have a "Digital Cinema Distribution Master" tiff?
[02:52] <Daemon404> no
[02:52] <Daemon404> i dont work with such files
[02:53] <cehoyos> kierank: Do you have one?
[02:59] <timothy_gu> ac_slater: This might be helpful if you are building the sources: https://android.googlesource.com/platform/frameworks/av/ Also, for the Binder API, a Googler said it's not stable, but obviously poeple are still using it: https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/1QmVRrNckfM
[03:03] <cone-864> ffmpeg.git 03Carl Eugen Hoyos 07master:4fa42e04ed48: configure: Set the default for --shlibdir to --libdir.
[03:07] <ac_slater> timothy_gu: in order to build the libavcodec/libstagefright.cpp ... we need frameworks/av,frameworks/native,system_core, and libraries from the device... I just found out I think I need more
[03:10] <ac_slater> timothy_gu: ... and android/libhardware
[03:11] <jamrial> BBB: thanks! my old K10 went from 28fps to 55fps on a 1080p sample thanks to the sse2 mc patch :p
[03:16] <timothy_gu> ac_slater: ya they used to be in only two repo. Please reportback if you do succeed in compiling it, first time in ~2 years.
[03:16] <timothy_gu> jamrial: Definitely RELEASE_NOTES material.
[03:16] <jamrial> BBB: ffplay can play it now without framedrops and without maxing both cores. amazing how much a difference these functions make
[03:16] <timothy_gu> BBB: ^^
[03:17] <jamrial> timothy_gu: sure
[03:37] <BBB> jamrial: yeah, mc is basically the main cpu eater
[03:38] <BBB> jamrial: I think mc is first and idct is second
[03:38] <BBB> main item left right now is loopfilter, although Ill probably do intra pred first
[03:38] <BBB> but good to hear its useful :)
[03:41] <jamrial> yeah
[03:41] <jamrial> ffvp9 is now almost two times faster than libvpx-vp9 on pre ssse3 machines
[05:32] <cone-864> ffmpeg.git 03wm4 07master:a400edbb6d00: lavu/frame: fix malloc error path in av_frame_copy_props()
[07:34] <arwa> error: undefined reference to 'MM_FIX_0_382683433'
[07:34] <arwa> Can anyone help me out with this error?
[07:44] <anshul_mahe> isn't it defined in libavfilter/libmpcodecs/vf_fspp.c
[07:48] <anshul__> I was trying to implement scte_35 message cue, I want to give user signal that yes this is the right time to put your advertisement's 
[07:50] <anshul__> I was thinking to give option in decoder, that will take the library name and calls the function given in that library to notify the user
[07:51] <anshul__> its not there in ffmpeg that we take library name from user, so I was looking for opinion of all, does this sound good and if bad please some other idea
[07:56] <anshul__> or should I ask for text file where he has kept all the advertisements video list, and when some scte-35 message of insert comes, pick order wise from text file provided by user to putthe video from there 
[08:51] <anshul_mahe> I have another option of writing to an xml file, that can be used by the other program for scte-35
[09:09] <visiot> how can i change pcr using ffmpeg
[09:09] <visiot> i'm trying "ffmpeg -pcr_period 40 ", but this argument is not reponding back
[09:11] <visiot>  right now ffmpeg documentation says defaault pcr_time is 20ms , iwant to change it
[09:58] <ubitux> visiot: -pcr_period is a muxer option, so it belongs as output option
[10:12] <visiot> ubitux: can u explain about it more
[10:13] <ubitux> man ffmpeg, and look where the output option belongs in the command line (see the first thing: the synopsis)
[10:13] <visiot> ubitux: in which scenario i can use pcr_period
[10:13] <visiot> but on ffmpeg documentation theer's only 1 line
[10:15] <visiot> ubituxi used this option at  output but ffmpeg return with unrecognized option
[10:15] <visiot> ubitux: used this option at  output but ffmpeg return with unrecognized option
[12:02] <Compn> not enough space sounds like grep error message :p
[12:17] <cone-78> ffmpeg.git 03Luca Barbato 07master:bcbdeb318e08: asvenc: Forward the error instead of asserting on it
[12:17] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:0c7733904e54: Merge commit 'bcbdeb318e0828cf00b458885ffa1e1596c85d06'
[12:36] <wm4> ubitux: I still don't quite get it... wasn't the plan to use AVFrame for subtitles at some point because of glorious lavfi?
[12:39] <ubitux> yes we could do that
[12:40] <ubitux> would you prefer that?
[12:40] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:5a82ad644f28: svq1dec: Unbreak the scratch buffer allocation
[12:40] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:d2f9b9da0362: Merge commit '5a82ad644f281701eb22e0359fd732fac67aafa4'
[12:40] <ubitux> i could basically dump the AVSubtitle stuff into AVFrame
[12:40] <ubitux> but i'm not sure how much people will like it
[12:40] <ubitux> but yeah that's a different approach
[12:41] <ubitux> but typically you have different issues
[12:41] <ubitux> the subtitles are really nasty
[12:42] <ubitux> typically, with AVFrame, given certain parameters, you can guess the final size
[12:42] <ubitux> and can get a buffer
[12:42] <ubitux> with subtitles you can't do that
[12:42] <ubitux> the size of each rect can be totally random
[12:43] <wm4> I think I'm fine with AVSubtitle; I'm just asking because I totally expect someone else will later change the API again to coerce it into AVFrame
[12:43] <ubitux> there are advantages and drawbakcs
[12:43] <ubitux> but i took the AVSubtitle path
[12:44] <ubitux> i tried to discuss that topic several times in the past
[12:44] <wm4> ok
[12:44] <wm4> I know
[12:44] <ubitux> but no one came up with arguments for one side or another
[12:44] <wm4> if we stick with the decision, it's fine
[12:45] <ubitux> we'll probably have to mirror a few functions for AVSubtitle vs AVFrame
[12:45] <ubitux> (in lavfi)
[12:46] <wm4> refcounted subtitles?
[12:48] <ubitux> yeah we don't have this
[12:48] <ubitux> i need to add fields to AVSubtitle for that :p
[12:59] <nevcairiel> for subtitles it would be an even more interesting feature though, as subtitles are used for many video frames, can overlap, are often passed to a rendering thread for blending later ... etc :D
[12:59] <nevcairiel> i wonder how i implemented that
[12:59] <nevcairiel> i bet i copied the rects
[12:59] <nevcairiel> since i only do dvd bitmap subs
[13:22] <cone-78> ffmpeg.git 03Thiago Santos 07master:bab8d7376523: vaapi: wrap codec specific functions in appropiate #ifs
[13:22] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:228fded03622: Merge commit 'bab8d73765238bfeea7a8dfd454f40ac213b3d22'
[13:29] <wm4> nevcairiel: in libass we're also thinking about adding refcounting (but of course nothing ever happens)
[13:54] <cone-78> ffmpeg.git 03Julien Ramseier 07release/2.4:864c0c50eb0e: avconv: Use the mpeg12 private option scan_offset
[13:55] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.4:5ceae49caf08: Merge commit '864c0c50eb0e7a112b20007459b0cb94b61cb8d3' into release/2.4
[14:06] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:e631872f13b6: configure: create the tests directory like the doc directory
[15:13] <Elirips> Hello. Where can I see for what version the doc on https://ffmpeg.org/ffmpeg.html is? I have here various versions of ffmpeg, some have parameters not that are mentioned in the doc, others do. Where can I match this up?
[15:14] <nevcairiel> the page is always for the latest version, it has no guarantees for completeness though
[15:16] <Elirips> nevcairiel: thank you. 
[15:19] <Elirips> Any chance to build ffmpeg 2.5 on debian wheezy? Any chance to backport it? Any hints?
[15:23] <koda> Elirips: whats the problem with the current debian lavc provider?
[15:24] <nevcairiel> koda: other than being butt-old?
[15:24] <nevcairiel> wheezy is on 0.8 afterall
[15:24] <koda> omg
[15:24] <Elirips> koda: On wheezy-backports there is ffmpeg 1.2 in it, which has no -f hls and thats what I need
[15:24] <Elirips> So I need a 2.5, but I'll just try the static builds
[15:25] <cone-78> ffmpeg.git 03Rong Yan 07release/2.5:968e733b2e9f: avcodec/ppc/vc1dsp_altivec: add POWER LE support to vc1_inv_trans_8x4_altivec()
[15:25] <cone-78> ffmpeg.git 03Rong Yan 07release/2.5:aac467ae174b: avcodec/ppc/vp8dsp_altivec.c: POWER LE support put_vp8_epel_h_altivec_core() put_vp8_epel_v_altivec_core() put_vp8_pixels16_altivec() add marcos GET_PIXHL() GET_OUTER() LOAD_HL()
[15:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:91f88eab32b5: MAINTAINERS: add 2.5
[15:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:3bcd1daad799: doc/examples/transcoding: check encoder before using it
[15:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:aa24dd487f1a: avcodec/mpegaudiodec_template: only allocate fdsp when its used
[15:25] <cone-78> ffmpeg.git 03Piotr Fusik 07release/2.5:542332e523cd: doc/examples/filtering_video: fix frame rate
[15:25] <cone-78> ffmpeg.git 03wm4 07release/2.5:f7b536665706: avformat/matroskadec: fix handling of recursive SeekHead elements
[15:25] <cone-78> ffmpeg.git 03Rong Yan 07release/2.5:6ec5a199ea77: avcodec/ppc/vp3dsp_altivec: POWER LE support to vp3_idct_add_altivec()
[15:25] <cone-78> ffmpeg.git 03Moritz Barsnick 07release/2.5:d5af3fb1c53e: configure: use use_pkg_config() instead of check_pkg_config() for libsmbclient
[15:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:0103bc67fdd5: avformat/crypto: fix key vs iv typo
[15:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:0e4efad93c1d: avformat/flvdec: fix potential use of uninitialized variables
[15:25] <cone-78> ffmpeg.git 03Rob Sykes 07release/2.5:9783d5bfda33: swresample/soxr_resample: fix error handling
[15:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:13244abcd3db: avformat/aviobuf: Check that avio_seek() target is non negative
[15:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:3b3a3c3d448e: avformat/utils: Do not update programs streams from program-less streams in update_wrap_reference()
[15:25] <cone-78> ffmpeg.git 03wm4 07release/2.5:135c733125e3: lavu/frame: fix malloc error path in av_frame_copy_props()
[15:40] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:5e26152ee496: Update for FFmpeg 2.5.1
[15:52] <Elirips> If I set a -hls_time of 10 seconds, I get 10 seconds segements as long as the input-source delivers 25 fps. As soon as the input-source brings only 5fps, I get 50 seconds segments. Why?
[15:55] <nevcairiel> maybe it doesnt provide a keyframe to split on?
[16:01] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:51b193214dea: avformat/avidec: Use av_freep() to avoid leaving stale pointers in memory
[16:01] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:89f0feadc2b3: avformat/assenc: Use av_freep() to avoid leaving stale pointers in memory
[16:01] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:c116befc92d2: avformat/xmv: use av_freep() to avoid leaving stale extradata pointer
[16:01] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:0051e3c23335: avformat/rtpdec_mpeg4: Use av_freep() to avoid leaving stale extradata pointer
[16:01] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:480cd822b3da: avformat/flic: se av_freep() to avoid leaving stale extradata pointer
[16:02] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:ae658efef86b: avformat/xmv: Check return code of ff_alloc_extradata()
[16:21] <michaelni> BBB, the msvc fate client doesnt like the new vp9 asm: http://fate.ffmpeg.org/log.cgi?time=20141215060653&log=compile&slot=x86_32-msvc12-windows-native
[16:22] <michaelni> c:/Dev/ffmpeg/fate/x86_32-msvc2013/src/libavcodec/x86/vp9itxfm.asm:2667: error: undefined symbol `r7' (first use)
[16:44] <nevcairiel> hm, say I want to implement a low-pass audio filter, does ffmpeg have anything useful i could borrow/use? :d a lavfi filter, perhabs?
[16:46] <nevcairiel> ah there it is
[17:13] <Elirips> Hm, is there any use-case where the -hls_time parameter actually does have any influence on the generated segment-lengths at all?
[17:57] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:c1d9283b1e4b: doc/ffplay: remove duplicate threads option, this is documented in codecs.*
[18:58] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:1307c11ce623: avcodec/avdct: support >8bit per sample dcts
[18:58] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:838aa08d753f: avfilter/vf_spp: support 10bit per sample
[19:20] <akira4> ubitux,I tried implementing a basic input device for dvd and this is the output : http://pastebin.com/MiDWb632
[19:21] <akira4> What exactly is the difference between an INOUTDEV and INDEV (that is in alldevices.c) ?
[19:22] <Daemon404> one can output too
[19:24] <akira4> and OUTDEV?
[19:24] <Daemon404> just output
[19:27] <akira4> hmm. So then an INDEV wouldn't output any packets/data right?
[19:27] <Daemon404> i assume not
[19:27] <Daemon404> im not avdevice expert
[19:27] <Daemon404> no*
[19:31] <akira4> cool. thanks. I'm guessing that the DVD device that I'm trying to write will be an INOUTDEV then. 
[19:31] <kierank> sigh ffmpeg is becoming emacs :(
[19:33] <Daemon404> you only just noticed?
[19:34] <kierank> well dvds clearly operate at a higher level to ffmpeg
[19:34] <kierank> in something that the rest of the world calls a player
[19:35] <Daemon404> yes.
[20:06] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:9887e7df9b89: Changelog: Add 10bit spp
[20:06] <cone-78> ffmpeg.git 03Nicolas George 07master:acbc2ed26ab6: lavf/concatdec: handle NOPTS start_time.
[21:19] <cone-78> ffmpeg.git 03Vittorio Giovara 07master:b2bece5e9a4d: hevc: always clip luma_log2_weight_denom
[21:19] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:241943d3a2ac: Merge commit 'b2bece5e9a4dd96142962c6798e187c77b88bbfa'
[21:19] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:b799ec7e0b34: avcodec/hevc: Print an error if luma_log2_weight_denom is out of range
[21:26] <cone-78> ffmpeg.git 03Vittorio Giovara 07master:63fcedcf0124: mpegvideo: remove unused function declaration
[21:26] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:0a3ffcfc8224: Merge commit '63fcedcf01247f15b72c0d1f959bb3b612853ba8'
[21:34] <cone-78> ffmpeg.git 03Vittorio Giovara 07master:d75190aa9320: mpegvideo: move REBASE_PICTURE where it is used
[21:34] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:38c3ffbd55de: Merge commit 'd75190aa93206c02cb4f18a66d2c927d6a0198e1'
[21:45] <ubitux> Daemon404: INDEV <=> demuxer, OUTDEV <=> muxer, afaik :p
[21:53] <cone-78> ffmpeg.git 03Xiaohan Wang 07master:490a3ebf3682: matroskadec: Fix read-after-free in matroska_read_seek()
[21:53] <cone-78> ffmpeg.git 03Luca Barbato 07master:4690e01c3aaf: prores: Evaluate all the quantizers
[21:53] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:71df932b2237: Merge commit '490a3ebf36821b81f73e34ad3f554cb523dd2682'
[21:53] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:41915d0b86c6: Merge commit '4690e01c3aaf495c87127e5dc74aa347197dbc0b'
[21:53] <ubitux> kierank: no, it's useful in ffmpeg
[21:53] <ubitux> like... really useful.
[21:54] <ubitux> it's one of the main reason people still stick with mencoder
[21:54] <ubitux> also, being able to extract subtitles from dvd and remux them into something else is definitely something worth adding
[21:54] <ubitux> anyway, ripping dvd with ffmpeg is definitely something people would want
[21:55] <ubitux> and you don't want it at ffmpeg level since you also want it in ffplay or ffprobe
[21:55] <ubitux> so i'm sorry but not, it doesn't belong at "player" level.
[21:56] <nevcairiel> proper dvd support quite certainly belongs on a player level, since its much more complex than "just" demuxing one stream
[21:56] <ubitux> yes, the interactive menu will be at player level, sure
[21:56] <ubitux> and we won't support this
[22:12] <cone-78> ffmpeg.git 03Luca Barbato 07master:3c27275c1309: tiff: Check the check_size() return value and forward it
[22:12] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:07b4d4b1a282: Merge commit '3c27275c1309190f2d6ed69140b67d014215b6c9'
[22:16] <ac_slater> timothy_gu: phew finally got that libstagefright stuff working.
[22:28] <cone-78> ffmpeg.git 03Vittorio Giovara 07master:10d4c5e55e5b: tiff: set the correct return value when check_size() fails
[22:28] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:4cffcbc809d2: Merge commit '10d4c5e55e5b23e165aa4c7723073ebe2c2e7da0'
[22:50] <nevcairiel> ahaha, typical libav, rewriting a patch just for the sake of rewriting so they can change authorship
[22:52] <Daemon404> nevcairiel, from the GNU book of authorship
[22:52] <nevcairiel> its your fault
[22:52] <Daemon404> i only troll
[22:57] <nevcairiel> and they wonder why we dont just --cc them
[22:57] <Daemon404> i dont think anyone wonders that
[23:26] <pross> nevcairiel: why do they do that?
[23:30] <Daemon404> in this case it was because 'wm4' is not a real name
[23:30] <Daemon404> for copyright purposes
[23:37] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:4f1923a91b8c: avcodec/tiffenc: Consistently use ADD_ENTRY1()
[23:37] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:d2f9aefbde5b: ffmpeg: Check for subtitle_out malloc failure
[23:38] <iive> so nobody knows the real name of wm4?!
[23:42] Action: pross wm4: command not found
[23:43] <rcombs> http://puu.sh/dwfLs/709dbc3ed8.png
[23:49] <pross> mmm, git supports utf8 author names
[23:50] <Daemon404> of course it does
[23:53] <cone-78> ffmpeg.git 03Michael Niedermayer 07release/2.5:2c01dd2ea5e3: Update Changelog for 2.5.1
[23:54] <ubitux> http://www.elementaltechnologies.com/resources/4k-test-sequences oh, fun :)
[00:00] --- Tue Dec 16 2014