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

[burek]

[00:04:48 CEST] <J_Darnley> Well... that is all modes but 2 and 3 finished
[00:05:22 CEST] <J_Darnley> I will look again at trying to make the preprocessor unroll a bubble sort loop correctly
[00:06:49 CEST] <J_Darnley> Other than that I need to: try building avx2 versions, double check my register uses, and mark which are x86_64 only
[01:26:17 CEST] <J_Darnley> Oh god I'm an idiot!  The loop was correct.  I was just storing the wrong register.
[01:26:23 CEST] Action: J_Darnley facepalms
[01:34:23 CEST] <J_Darnley> ha ha ha
[01:34:30 CEST] <J_Darnley> 43.1x speedup
[01:53:08 CEST] <jamrial> J_Darnley: mode2/3?
[01:53:55 CEST] <J_Darnley> 2, 3, 4
[01:55:04 CEST] <jamrial> so qsort() is awfully slow then? :p
[01:55:34 CEST] <J_Darnley> yeah one call to it per pixel, then it calls the comparison function many times
[01:56:39 CEST] <J_Darnley> Where I just unroll two loops to make 28 swaps or 84 instructions
[02:13:05 CEST] <J_Darnley> and before I forget I pushed all the working code to my gitlab repo: https://gitlab.com/J_Darnley/ffmpeg
[02:14:26 CEST] <cone-051> ffmpeg 03Ivan Uskov 07master:5985316fba3b: libavcodec/qsvenc.c: improving handling for return codes of MFXVideoENCODE_EncodeFrameAsync
[02:25:33 CEST] <jamrial> J_Darnley: rebase the branch with current master to get the fate tests durandal_1707 added
[02:25:49 CEST] <jamrial> the test for mode 8 is failing with your asm
[02:31:02 CEST] <cone-051> ffmpeg 03Luca Barbato 07master:461b45efd048: lavc: Add nvenc.h to the skipheader
[02:31:03 CEST] <cone-051> ffmpeg 03Michael Niedermayer 07master:60c6959b6bf8: Merge commit '461b45efd04859b2672238bc8a6ecab9e9a14948'
[02:31:10 CEST] <J_Darnley> damn
[02:32:20 CEST] <jamrial> ah, you're clipping as words
[02:32:41 CEST] <jamrial> durandal_1707 changed it from uint16 to uint8 before pushing. you're using the first patch he submitted to the ml
[02:35:04 CEST] <J_Darnley> wait a minute...
[02:36:28 CEST] <J_Darnley> the source he's working from doesn't clip to bytes there
[02:37:28 CEST] <J_Darnley> that clip to words doesn't get written to a pixel so it doesn't matter about its range
[02:37:31 CEST] <durandal_1707> it is for 16bit input afaik
[02:39:35 CEST] <J_Darnley> then what does it for for 8bit?
[02:41:05 CEST] <J_Darnley> uh
[02:41:09 CEST] <J_Darnley> then what does it do for 8bit?
[02:41:44 CEST] <durandal_1707> I think vs one operates in 16 bit only, need to check....
[02:42:39 CEST] <J_Darnley> what!?
[02:47:31 CEST] <durandal_1707> maybe clipping to 8bit doesn't make sense?
[02:49:17 CEST] <J_Darnley> I don't know.  A different port I have here does clip 0..255
[02:50:16 CEST] <J_Darnley> rgtools from here http://forum.doom9.org/showthread.php?t=169832
[02:59:38 CEST] <durandal_1707> as I understand clipping to 0xff is not needed
[03:03:34 CEST] <J_Darnley> I don't know what is supposed to be "correct"
[03:03:59 CEST] <J_Darnley> perhaps I see what the original AVS removegrain does.
[03:06:39 CEST] <J_Darnley> omfg
[03:06:54 CEST] <J_Darnley> how can anyone manage code that looks like this?
[03:08:49 CEST] <durandal_1707> I will change uint8 to uint16, the vs one works with both depths. So probably we could too...
[03:12:01 CEST] <J_Darnley> I hate to make you change it back but it looks like this one is full of saturated, byte-sized additions and subtractions
[03:14:50 CEST] <J_Darnley> meh, just follow the source you want
[03:16:29 CEST] <J_Darnley> Having seen and complained about this source I should make sure mine is legible
[03:16:54 CEST] <J_Darnley> oh well,  I'll see what needs doing in the morning
[03:16:57 CEST] <J_Darnley> good night
[03:17:55 CEST] <durandal_1707> there is another mode that clips to 0xff instead of 0xffff I will check do I need to change that one too...
[03:53:58 CEST] <cone-051> ffmpeg 03Vittorio Giovara 07master:67c884eb07c7: libvpx: Add the library header
[03:53:59 CEST] <cone-051> ffmpeg 03Michael Niedermayer 07master:033dc39c561f: Merge commit '67c884eb07c7e9f2cb72bb8d447d945e5ac8cac7'
[04:38:51 CEST] <cone-051> ffmpeg 03Michael Niedermayer 07master:7b404c94f38e: avcodec/libopenh264enc: Do not truncate frame rate
[06:50:11 CEST] <Zeranoe> How come postprocess.h is included with cmdutils even if the build is being compiled as LGPL3?
[06:53:06 CEST] <Zeranoe> By mistake perhaps?
[08:44:54 CEST] <nevcairiel> headers dont hurt
[08:49:11 CEST] <rcombs> the header itself is GPL
[08:49:50 CEST] <rcombs> according to the header's header
[08:50:16 CEST] <rcombs> probably not a problem for most cases but I could see wanting to leave it out to avoid legal applesauce
[09:09:00 CEST] <Taniey> ffmpeg filter tblend ,how can I make video have a fade in or out effect?
[09:09:38 CEST] <Taniey> or have another filter can realize this effect
[10:20:09 CEST] <ubitux> JEEBsv: if(x),y,0 ’ x*y?
[10:20:55 CEST] <JEEBsv> yeah, but can't that theoretically match up against other resolutions that happen to have the same amount of luma samples?
[10:21:09 CEST] <ubitux> so if(if(eq(iw,WIDTH),eq(ih,HEIGHT),0),ih-GARBAGE_HEIGHT,ih) becomes if(eq(iw,WIDTH)*eq(ih,HEIGHT),ih-GARBAGE_HEIGHT,ih unless i'm mistaken
[10:21:14 CEST] <ubitux> which you can simplify further
[10:21:32 CEST] <JEEBsv> oh
[10:21:40 CEST] <JEEBsv> * in there
[10:22:01 CEST] <ubitux> doing something like ih-eq(iw,WIDTH)*eq(ih,HEIGHT)*GARBAGE_HEIGHT maybe
[10:22:30 CEST] <ubitux> i'd say the first expression can be simplified to this
[10:22:36 CEST] <ubitux> (but didn't test)
[10:22:38 CEST] <JEEBsv> that looks good
[10:22:40 CEST] <JEEBsv> I'll test
[10:22:49 CEST] <ubitux> btw, you don't need to escape with \
[10:22:58 CEST] <JEEBsv> it seems like I need to
[10:23:03 CEST] <JEEBsv> I got parse errors without
[10:23:04 CEST] <ubitux> just do "crop='...'"
[10:23:07 CEST] <JEEBsv> oh
[10:23:35 CEST] <ubitux> "crop=out_h='...':y='...'"
[10:23:52 CEST] <JEEBsv> so when passing it as an arg the arg would be "crop=out_h='shizzle'" ?
[10:24:09 CEST] <JEEBsv> anyways, I'll test. thanks
[10:24:10 CEST] <ubitux> if you want to put special characters like , or : yes
[11:24:01 CEST] <durandal_1707> do we have hevc to anex b bitstream filter?
[11:27:16 CEST] <wm4> Libav has a patch
[11:27:33 CEST] <wm4> rcombs wrote one too, but AFAIK it wasn't merged
[11:46:54 CEST] <dhiru> hi! how do I pass some data from "mov.c" (demuxer) to a bitstream filter?
[11:48:21 CEST] <dhiru> bitstream filters have access to AVCodecContext objects. if only I could access this object from mov.c, my problem will solve itself ;)
[11:49:10 CEST] <nevcairiel> These components are decoupled for a reason
[11:50:36 CEST] <dhiru> nevcairiel, true. in my case, I have to handle obfuscation of the audio blocks. the problem is that the bitstream filters can't access the file itself.
[11:52:32 CEST] <dhiru> if I handle the crypto part in mov.c (which I can, easily), then the subsequent bitsream filter doesn't have access to the crypto data (which resides on mov.c context now)
[11:52:41 CEST] <dhiru> s/resides on/resides in
[11:53:32 CEST] <wm4> what bitstream filter is it, and why is it separate?
[11:55:21 CEST] <dhiru> I wrote the bitstream filter, and keeping the filter separate seemed liked a good idea (initially)
[11:55:52 CEST] <wm4> what does the filter do?
[11:57:09 CEST] <dhiru> it unobfuscates the audio bytestream (the underlying bytestream is protected using some crypto)
[11:57:39 CEST] <dhiru> in my earlier code, all the crypto was handling externally, and then I passed the keys to the bitstream filter
[11:57:56 CEST] <dhiru> now I would like to move the crypto part into ffmpeg itself :)
[11:58:07 CEST] <wm4> rcombs: you may find this interesting http://lists.libav.org/pipermail/libav-devel/2015-July/070559.html
[12:34:57 CEST] <dhiru> wm4, can I drop the bitstream filter idea completely, and instead move the audio bytestream deobfuscation directly into mov.c?
[12:35:47 CEST] <wm4> dhiru: we don't know your code or what exactly you're trying to do
[12:36:53 CEST] <dhiru> wm4, I am writing ffmpeg code to handle playback of .mp4 files which use custom obfuscation of audio bytestream.
[12:38:11 CEST] <nevcairiel> if its custom anyway, just shove it into the demuxer
[12:40:31 CEST] <dhiru> nevcairiel, will do!
[12:41:10 CEST] <dhiru> one day, I will be able to publish this code, and then we can argue where the code actually belongs ;)
[12:51:19 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:ae55fc82a840: avfilter/vf_removegrain: clip to uint16 instead to uint8
[13:23:40 CEST] <dhiru> in a bitstream filter, it is really simple to see the audio data by using the "buf" and "buf_size" arguments to the filter. where do I intercept this data when I am in "mov.c". "mov_read_packet" seems to be the place but it's hard to see what is going on :)
[14:08:46 CEST] <J_Darnley> durandal_1707: since you pushed the change I'm going to rebase my branch
[14:19:02 CEST] <durandal_1707> J_Darnley: how hard would it be to extend it to 16 bit?
[14:19:26 CEST] <J_Darnley> My assembly?  Not too hard but quite a bit of work.
[14:20:21 CEST] <J_Darnley> I would probably end up duplicating the code like with yadif.
[14:21:12 CEST] <J_Darnley> Although I have wanted to look at writing some size independent macros
[14:35:10 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:e71ca21f3084: avcodec/motion_est_template: Fix undefined behavior in small_diamond_search()
[15:09:54 CEST] <D404|Ghetto> profile is not a parseable x265 param
[15:31:57 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:7ef6656b1e5b: avcodec/utils: use a minimum 32pixel width in  avcodec_align_dimensions2() for H.264
[15:33:41 CEST] <AstralStorm> hello, suppose I have an AAC bitstream encoder and decoder and want to put it into an already built version of ffmpeg
[15:34:03 CEST] <AstralStorm> I see potentially either implementing AVCodec or AVBitStreamFilter
[15:34:51 CEST] <AstralStorm> which one of those should I do? also, how do I disable or make lower priority the ffmpeg built-in decoder?
[15:35:45 CEST] <BtbN> you can't add encoders without recompiling
[15:36:14 CEST] <AstralStorm> huh? why? av_codec_register is there
[15:36:51 CEST] <AstralStorm> *avcodec_register
[15:37:06 CEST] <BtbN> you don't have access to most libav* internal stuff, and how do you intend to make ffmpeg call those?
[15:37:19 CEST] <AstralStorm> this is external API
[15:37:25 CEST] <AstralStorm> the structure is public too
[15:37:45 CEST] <BtbN> I never heard of a runtime registered out-of-lavc encoder/decoder.
[15:37:53 CEST] <BtbN> And i'm quite sure that's not supported.
[15:38:18 CEST] <AstralStorm> what about HWAccel then?
[15:38:33 CEST] <AstralStorm> (yes, potentially I can rebuild that ffmpeg, I'd rather not)
[15:38:46 CEST] <BtbN> You want to use those with the ffmpeg command line tool, or what do you even want to do?
[15:39:37 CEST] <AstralStorm> no, libavcodec is used within an application
[15:39:46 CEST] <nevcairiel> ffmpeg is generally not deisgned for incoporating new encoders or decoders at runtime
[15:40:03 CEST] <AstralStorm> and I need to use a proprietary encoder/decoder with a suitable license
[15:40:24 CEST] <AstralStorm> (which is also a wrapper to hardware accelerator)
[15:40:51 CEST] <AstralStorm> hmmh, oh well, worst case I can use libavformat to mux by hand
[15:40:56 CEST] <AstralStorm> less fun though.
[15:41:12 CEST] <BtbN> Or put the encoder into libavcodec and send a patch
[15:41:31 CEST] <AstralStorm> cannot, sorry. wrong license.
[15:41:34 CEST] <nevcairiel> or dont send a patch and just build the avcodec with the patch =p
[15:41:49 CEST] <AstralStorm> also cannot, sorry, wrong license :D
[15:42:05 CEST] <BtbN> Well, there is nvenc and mfx in there, which aren't exactly open-source compatible. So they make ffmpeg non-free when enabled.
[15:42:22 CEST] <BtbN> same for a bunch of other stuff
[15:42:40 CEST] <nevcairiel> well its not our problem, its really yours, avcodec cannot really accept external encoders, and if you cannot put a wrapper into avcodec directly and built it that way, you cannot use avcodec
[15:42:43 CEST] <AstralStorm> ah, they dynamically link their thing, right?
[15:43:27 CEST] <nevcairiel> In any case, what you do locally to your avcodec is noones business, you can build it using the non-free license and include any closed source modules you need
[15:43:29 CEST] <AstralStorm> hmm, darn, headers are copywrong too
[15:43:36 CEST] <nevcairiel> there is one limitation on that: you cannot distribute this
[15:43:49 CEST] <AstralStorm> exactly, that is a serious limitation
[15:44:11 CEST] <AstralStorm> hmmh. manual muxing it is
[15:44:25 CEST] <BtbN> well, your own code is under the same limitation then.
[15:44:37 CEST] <AstralStorm> no, it's not, it's specifically distributed under a license
[15:45:24 CEST] <kierank> Compn: http://www.phoronix.com/scan.php?page=news_item&px=NSA-KDBUS-Credentials&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Phoronix+%28Phoronix%29
[15:45:37 CEST] <j-b> BtbN: mfx is non-free?
[15:45:39 CEST] <AstralStorm> thanks, I'll still have a crack at doing the libavcodec avcodec_register shenanigans
[15:46:04 CEST] <durandal_1707> people distribute various stuff with lavc see license violators list on trac
[15:46:09 CEST] <BtbN> j-b, i can't download it without registering at intel, so i has at least something strange going on.
[15:46:42 CEST] <nevcairiel> that doesnt really tell you anything about the license
[15:46:53 CEST] <j-b> BtbN: sorry, but I think you are mistaken.
[15:47:09 CEST] <BtbN> Did they fix it?
[15:47:22 CEST] <D404|Ghetto> having to register has no bearing on its license
[15:47:35 CEST] <AstralStorm> hmm, technically.... I could wrap the proprietary thing in my own BSD wrapper
[15:47:41 CEST] <nevcairiel> why is github so horribly slow today
[15:48:42 CEST] <AstralStorm> as in, said wrapper would provide libavcodec APIs and be dynamically linked in
[15:48:56 CEST] <nevcairiel> BtbN: the mfx headers at least seem to be under BSD
[15:49:38 CEST] <__gb__> BtbN, if your codec does not need/rely on lavc internals, you can obviously register any encoder/decoder you want, manually, from within your application
[15:50:26 CEST] <__gb__> automatic selection could be challenging, but if you want to integrate your codec, you would likely use it explicitly anyway
[15:50:41 CEST] <BtbN> __gb__, yes, of course you can do that. But i have never seen that beeing done and I don't think it's a well tested and supported method.
[15:53:11 CEST] <AstralStorm> exactly, I don't need any internals at all
[15:53:46 CEST] <AstralStorm> suppose I go the "build in with wrapper" route - should I go with AVHWAccel?
[15:54:21 CEST] <__gb__> BtbN, https://github.com/gbeauchesne/mvt_tools/blob/master/src/gen_ref_h264_avc.c (JM) for instance
[15:54:29 CEST] <AstralStorm> or is that for video only?
[15:54:42 CEST] <__gb__> that's for video decode only
[15:54:47 CEST] <BtbN> __gb__, github doesn't want to cooperate right now
[15:55:51 CEST] <AstralStorm> yeah, it's sort of broken now
[15:56:01 CEST] <BtbN> Not only sort of
[15:56:05 CEST] <BtbN> All i get is "Unicorn!"
[15:56:25 CEST] <AstralStorm> read: their backend is broken
[15:57:00 CEST] <AstralStorm> now the page itself is dead too, heh
[15:57:04 CEST] <AstralStorm> must be something major
[15:57:51 CEST] <D404|Ghetto> https://status.github.com/
[15:58:17 CEST] <nevcairiel> hehe 2 minutes ago that still said "small number of repositories"
[15:59:34 CEST] <J_Darnley> What a shame that git isn't a distributed service.
[15:59:46 CEST] <TimNich> ;)
[16:00:06 CEST] <nevcairiel> its not that we're complaining that the repo is unavailable, but the web browsing of the same :p
[16:03:58 CEST] <__gb__> someone disconnects their cables or "black box" from major sites? :)
[16:04:22 CEST] <__gb__> "software glitch" aka "network connectivity issue" at united airlines
[16:04:30 CEST] <__gb__> some computer issue at NYSE
[16:04:37 CEST] <AstralStorm> chinese.
[16:04:53 CEST] <J_Darnley> OMG  It has finally happened!  It is the cyber Pearl Harbor!
[16:04:58 CEST] <AstralStorm> didn't like the reports about their market failing
[16:08:32 CEST] <__gb__> were people really surprised by a market failing by "only" 30% after +150% over a year? really?
[16:12:18 CEST] <__gb__> 16:10 CEST
[16:12:18 CEST] <__gb__> Everything operating normally. 
[16:24:16 CEST] <cone-616> ffmpeg 03Andreas Cadhalpun 07master:3526a120f929: snow: remove an obsolete av_assert2
[16:34:09 CEST] <dhiru> I finally have a patched "mov.c" which is able to unobfuscate the bytestream. now, the underlying .mp4 file contains a picture (mjpeg?), and if I don't use the "-vn" flag, then I see a lot of "Delay between the first packet and last packet in the muxing queue is 10031020 > 10000000: forcing output" messages. is there something I can do to avoid such messages?
[16:37:20 CEST] <wm4> <__gb__> BtbN, https://github.com/gbeauchesne/mvt_tools/blob/master/src/gen_ref_h264_avc.c (JM) for instance <- this uses internal API
[16:42:28 CEST] <__gb__> it has been a long time since I haven't built against system ffmpeg, so this probably broke :)
[16:42:35 CEST] <__gb__> wm4, what internal API do you see in there?
[16:44:30 CEST] <wm4>     /*****************************************************************
[16:44:30 CEST] <wm4>      * No fields below this line are part of the public API. They
[16:44:30 CEST] <wm4>      * may not be used outside of libavcodec and can be changed and
[16:44:30 CEST] <wm4>      * removed at will.
[16:44:30 CEST] <wm4>      * New public fields should be added right above.
[16:44:31 CEST] <wm4>      *****************************************************************
[16:44:39 CEST] <wm4> but apparently this wall is not visible enough
[16:45:01 CEST] <wm4> this is above AVCodec.encode2/decode and other fields
[16:45:29 CEST] <wm4> you can NOT add any decoders, encoders, filters, demuxers, or muxers to FFmpeg with public API
[16:46:09 CEST] <wm4> the only thing the "codec registration" achieves is making ffmpeg not library-safe due to global, mutable, unprotected state
[16:55:29 CEST] <durandal_1707> thanks to name that shall not be spoken
[16:56:51 CEST] <kierank> max
[16:56:57 CEST] <kierank> that's the name
[16:57:52 CEST] <durandal_1707> Mighty Max
[17:00:12 CEST] <kierank> magic mike
[19:02:01 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:b1e242bc5656: avcodec/g2meet: Check R/G/B values in epic_decode_pixel_pred()
[19:02:02 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:47d077337a62: avcodec/utils: Document 32 min for h264 width
[19:02:46 CEST] <Vonor> hi
[19:06:22 CEST] <Vonor> trying to build a static ffmpeg version. host system is gentoo. host system hast latest freetype installed through package manager (with useflag static-libs). I'm using latest ffmpeg package from the ffmpeg page (2.7.1). This is my configure line: http://pastebin.com/emLqhu3i and this is the error I get in config.log: http://pastebin.com/30C2bWMT
[19:06:35 CEST] <Vonor> would anyone have an idea?
[19:07:30 CEST] <J_Darnley> Something is linked to libpng
[19:07:56 CEST] <J_Darnley> try adding --extra-ldflags=-lpng
[19:08:51 CEST] <J_Darnley> Also, why the heck is your configure line so ling?
[19:09:21 CEST] <Vonor> J_Darnley, added it. looks like the same error to me: http://pastebin.com/hDAe5q2F
[19:09:46 CEST] <J_Darnley> you can combine various --enable-* and --disable-* by using commas
[19:09:51 CEST] <J_Darnley> --disable-amd3dnow --disable-amd3dnowext --disable-altivec --disable-avx --disable-ssse3 --disable-neon makes no sense
[19:10:44 CEST] <J_Darnley> -lpng needs to go after whichever library needs it
[19:11:20 CEST] <J_Darnley> And I wonder why pkg-config isn't reporting the dependency correctly
[19:11:31 CEST] <J_Darnley> And I wonder why this is on ffmpeg-devel
[19:11:47 CEST] <Vonor> J_Darnley, to be honest. a former colleague of mine did compile the ffmpeg binary for us before. he made this configure line. so i actually have no idea why he made it the way it is.
[19:12:28 CEST] <J_Darnley> start with ./configure
[19:12:42 CEST] <J_Darnley> then add the --enable-* options you need for third-pary libraries
[19:16:41 CEST] <Vonor> trying that right now
[19:28:04 CEST] <J_Darnley> Vonor: I just realised that I mean --extra-libs (or something) rather than --extra-ldflags
[19:28:10 CEST] <J_Darnley> sorry about that.
[19:29:08 CEST] <Vonor> i already have extra-libs="-static" can i merge it together or will i have to do two --extra-libs?
[19:29:37 CEST] <J_Darnley> like any other option that needs a space: "-static -lpng"
[19:29:59 CEST] <J_Darnley> but that is probably the cause of your problems.  You need to tell pkg-config that you want static libraries.
[19:31:21 CEST] <Vonor> how do i do that?
[19:31:26 CEST] <J_Darnley> No idea
[19:31:32 CEST] <J_Darnley> I dislike pkg-config
[19:32:04 CEST] <c_14> --pkg-config-flags="--static"
[19:34:19 CEST] <Vonor> J_Darnley, you were right. telling pkg-config that i want static fixed the issue
[19:34:27 CEST] <Vonor> c_14: thanks a lot for that :)
[19:34:41 CEST] <J_Darnley> Sorry for the wild goose chase
[19:34:55 CEST] <J_Darnley> but I still suggest you cleanup that configure line
[19:35:59 CEST] <Vonor> i just took out the parts you mentioned above that make no sense.
[19:39:08 CEST] <Vonor> J_Darnley, of course I thank you a lot too.
[19:41:00 CEST] <J_Darnley> np
[19:41:39 CEST] <durandal_1707> cehoyos: maybe those green stuff at top are 2bits of 10bits data, to confirm real 10 bit sample is needed
[19:41:47 CEST] <Vonor> i might have an idea where all these options came from. my former colleague might have taken the actual config line the gentoo portage package uses internally (in regards to his make.conf settings) and then he added the static stuff he needed
[20:11:31 CEST] <cehoyos> thardin: I sent an ugly mxf patch, please comment!
[20:11:59 CEST] <cehoyos> durandal_1707: The green stuff is required for Avid 1:1, see (just a moment)
[20:13:14 CEST] <cehoyos> 36cbdc95393117d36885c9ba06f0df62f50cc46c
[20:14:57 CEST] <cehoyos> thread.gmane.org/gmane.comp.video.ffmpeg.issues/8596/ (warning: gmane is broken for issues)
[20:17:21 CEST] <cehoyos> michaelni: Is the libavcodec part of "Raise max channels to 64" not ok?
[20:18:43 CEST] <cehoyos> wbs: Are you interested in reviewing a rtp patch? http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175348.html
[20:22:36 CEST] <michaelni> cehoyos, i think nicolas should take a look at the 63vs64 max stuff, he worked on related code. if he doesnt remember / see any problem then it should be ok
[20:22:51 CEST] <cehoyos> Thank you!
[20:23:25 CEST] <BtbN> 63 seems like a quite specific number
[20:25:08 CEST] <cehoyos> See 192f1984
[20:26:23 CEST] <thardin> cehoyos: boozing, but i'll take a look in the morning
[20:26:39 CEST] <cehoyos> Tomorrow is definitely soon enough!
[20:27:30 CEST] <thardin> unless i can find it on my phone
[20:28:30 CEST] <cehoyos> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175386.html
[20:31:08 CEST] <thardin> hm
[20:32:45 CEST] <thardin> can't judge atm i fear :p
[20:33:10 CEST] <cehoyos> When support for AVup was added years ago, no new decoder was added but rawvideo checks for AVup to throw away the "empty" third of the image.
[20:33:38 CEST] <cehoyos> In theory, this solution would allow to remux to mov.
[20:33:51 CEST] <cehoyos> (I don't think it's implemented but it wouldn't be too difficult)
[20:34:49 CEST] <cehoyos> The frame is much larger (in bytes) than necessary and is "bottom-aligned", ie the top of the frame is full of zeros if the codec_tag is not set.
[20:56:51 CEST] <cone-616> ffmpeg 03Alexandra Hájková 07master:872fab4a3df4: asfdec: Fix reading from the pipe
[20:56:52 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:72527d9c54a9: Merge commit '872fab4a3df48e7e6484333ee2228c684e319634'
[21:24:33 CEST] <Compn> kierank : nothing to worry about if dbus is a backdoor into your system , right? :)
[21:30:06 CEST] <cone-616> ffmpeg 03Andreas Cadhalpun 07master:05cc8c8e4b70: hevc: check slice address length
[22:03:01 CEST] <durandal_1707> cehoyos: it is not fully green there is pixel of lime
[22:10:50 CEST] <cehoyos> I see 0000 except for two bytes
[22:26:55 CEST] <cehoyos> Is there anybody who is able to use HttpFS Hadoop?
[22:29:24 CEST] <BBB> michaelni: ty
[23:04:15 CEST] <philipl> cehoyos: What do you mean by 'use'?
[23:21:02 CEST] <cehoyos> philipl: I think I don't even know what it is except that you upload files: Can you do that (==can you test if files are accepted)?
[23:21:21 CEST] <cehoyos> The reason is ticket 4512, the OP disappeared
[23:22:02 CEST] <philipl> I'd be hugely surprised if it worked. hdfs has weird semantics.
[23:22:19 CEST] <philipl> Got to be honest, this is pretty much the last place I'd expect to see hadoop come up :-)
[23:23:19 CEST] <philipl> Can you even stream flv?
[23:23:22 CEST] <cehoyos> You mean you don't think it works at all with FFmpeg? The OP wrote that it works fine, except if pipe output is used. I believe it may be possible to fix that.
[23:23:36 CEST] <philipl> Well, uploading a file will work, obviously.
[23:24:22 CEST] <cehoyos> The way I understood the ticket was that invalid files are rejected: Or do I just misunderstand?
[23:24:44 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:d759f7f1d080: avcodec/j2kenc: remove unused variable
[23:24:49 CEST] <philipl> Summary of the bug:
[23:24:49 CEST] <philipl> FFmpeg write flv to stdin,and send data to curl by pipe.
[23:24:49 CEST] <philipl> When press "q",ffmpeg report error:
[23:24:49 CEST] <philipl> [flv @ 029fab20] Failed to update header with correct duration.
[23:24:50 CEST] <philipl> [flv @ 029fab20] Failed to update header with correct filesize.
[23:24:58 CEST] <philipl> That says "flv cannot be piped" to me.
[23:25:03 CEST] <philipl> It has to seek back to re-write the header.
[23:25:09 CEST] <philipl> So the user is doing something impossible.
[23:25:28 CEST] <cehoyos> I don't think it is impossible.
[23:25:38 CEST] <cehoyos> Could you test the files I attached?
[23:25:56 CEST] <philipl> Why do you think it is not impossible. Just like mp4 is not streamable.
[23:26:12 CEST] <philipl> If you have to update a header at the end, then the target must be seekable.
[23:26:18 CEST] <philipl> And a pipe is not seekable.
[23:26:26 CEST] <philipl> He'd fail if he was piping to a file or /dev/null.
[23:26:33 CEST] <philipl> nothing to do with httpfs
[23:26:36 CEST] <cehoyos> FFmpeg plays the files that are produced with a pipe.
[23:26:45 CEST] <philipl> They might be broken but playable, yes.
[23:26:53 CEST] <philipl> but that's not what he was complaining about.
[23:26:56 CEST] <cehoyos> Imo it is not that unlikely that the only reason it fails is the duration set to "0".
[23:26:58 CEST] <philipl> He said it shows those two errors.
[23:27:06 CEST] <cehoyos> (The same is true for wav and WMP.)
[23:27:21 CEST] <cehoyos> He didn't test the samples I attached
[23:27:34 CEST] <cehoyos> (Or actually he wrote: They work but didn't tell which ones)
[23:27:40 CEST] <philipl> So, unless there's something I missed, all he was reporting was the two header update errors.
[23:27:40 CEST] <cehoyos> They are all made with pipe output.
[23:27:44 CEST] <philipl> He did not say the upload failed.
[23:27:49 CEST] <philipl> He did not say the file was unplayable.
[23:28:24 CEST] <cehoyos> That's why I also attached one file that is unchanged: I agree it is possible he only wanted to report that he saw a warning.
[23:28:33 CEST] <philipl> I think that's all he wanted to do.
[23:28:37 CEST] <cehoyos> But I would like to clarify before the ticket gets closed.
[23:28:40 CEST] <philipl> Sure.
[23:28:44 CEST] <philipl> Well, onl he can answer that.
[23:28:50 CEST] <philipl> Files will obviously upload just fine.
[23:28:54 CEST] <cehoyos> So you aren't able to test, unfortunately?
[23:29:05 CEST] <philipl> I can test, but it's meaningless. A file is a file.
[23:29:58 CEST] <cehoyos> You mean this filesystem has nothing to do with flv?
[23:30:09 CEST] <philipl> No.
[23:30:11 CEST] <cehoyos> Then why did he mention it at all?
[23:30:28 CEST] <philipl> HDFS is a distributed filesystem and 'httpfs' a REST web gateway to it.
[23:30:29 CEST] <cehoyos> (Sorry: No, it has nothing to do with flv, or no, you are wrong, it has something to do with flv?)
[23:30:46 CEST] <philipl> So all he's doing is streaming a file to it, as far as it is concerned.
[23:31:08 CEST] <cehoyos> But what does "FFmpeg write flv to HttpFS(Hadoop) failed" means then?
[23:31:22 CEST] <philipl> It means that's the operation he was attempting when he saw the errors.
[23:31:22 CEST] <cehoyos> That he saw an error although it did not fail?
[23:31:25 CEST] <philipl> Yes.
[23:31:32 CEST] <cehoyos> Ok, thanks.
[23:31:38 CEST] <philipl> That's what his description said. "When I pressed q, I saw some errors"
[23:31:41 CEST] <cehoyos> I spend quite some time with this issue;-(
[23:31:54 CEST] <philipl> Sorry. If I'd have known, I could have said all this at the time.
[23:32:31 CEST] <philipl> Anyway, someone trying to store streaming flvs on HDFS is probably crazy.
[23:32:36 CEST] <cehoyos> Don't worry!
[23:32:36 CEST] <philipl> (broken flvs at that)
[23:32:57 CEST] <cehoyos> I am not so sure they are broken, this is just metadata missing (or wrong)...
[23:33:40 CEST] <philipl> Well, that's one kind of broken. :-)
[23:43:42 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:8fca37d5f874: avfilter/vf_ssim: Mark constant tables as const
[00:00:00 CEST] --- Sat Jul 11 2015