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

[burek]

[00:00:14 CET] Action: Compn wonders why ffmpeg cant re-init input like mencoder for multiple files
[00:00:22 CET] <Compn> concat ... i dont like.
[00:01:41 CET] <cone-569> ffmpeg 03James Almer 07master:1d4d0ee4b02b: avutil/reverse: move the ff_reverse declaration to a separate header
[00:17:34 CET] <cone-569> ffmpeg 03Thomas Turner 07master:08fdf965c9a1: avutil/tests/audio_fifo.c: pass by reference for efficiency and change datatype to const
[00:27:28 CET] <Chloe> Compn: I don't mind doing something, I spend a lot of time on IRC anyway.
[00:55:45 CET] <cone-569> ffmpeg 03Steven Liu 07master:aa7982577c1d: cmdutils_opencl: fix resource_leak cid 1396852
[00:58:53 CET] <cone-569> ffmpeg 03Steven Liu 07master:b97e9cba0b3b: avformat/hlsenc: fix hlsenc bug at windows system
[01:00:03 CET] <cone-569> ffmpeg 03Steven Liu 07master:3222786c5ad9: avformat/hlsenc: refine the hlsenc code
[03:21:47 CET] <cone-569> ffmpeg 03James Almer 07master:5ac1dd8e2319: lossless_videodsp: move shared functions from huffyuvdsp
[03:21:48 CET] <cone-569> ffmpeg 03James Almer 07master:30c1f27299d3: huffyuvencdsp: move functions only used by huffyuv from lossless_videodsp
[03:21:49 CET] <cone-569> ffmpeg 03James Almer 07master:cf9ef839606d: huffyuvencdsp: move shared functions to a new lossless_videoencdsp context
[03:21:50 CET] <cone-569> ffmpeg 03James Almer 07master:47f212329e5d: huffyuvdsp: move functions only used by huffyuv from lossless_videodsp
[03:21:51 CET] <cone-569> ffmpeg 03James Almer 07master:6d4c9f2ade7c: lossless_videodsp: rename add_hfyu_left_pred_int16 to add_left_pred_int16
[03:21:52 CET] <cone-569> ffmpeg 03James Almer 07master:6596b34954fc: avcodec/lossless_videodsp: add missing call to ff_llviddsp_init_ppc()
[07:42:09 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170113043342&slot=x86_64-archlinux-gcc-valgrindundef
[07:42:12 CET] <ubitux> valgrind is not happy
[07:43:31 CET] <ubitux> it might be related to the upgrade of valgrind and not a recent commit
[13:14:41 CET] <Compn> atrac lossless ? oh wow another lossless codec
[13:52:22 CET] <Phidelux> Hi, is there any guide on how to port an av format demuxer from 2.8.x to 3.2.x
[13:58:17 CET] <durandal_1707> Phidelux: no
[14:02:14 CET] <Phidelux> mhh, ok thanks
[14:03:15 CET] <wm4> Phidelux: which one?
[14:03:22 CET] <wm4> all av format demuxers are in libavformat
[14:03:28 CET] <wm4> and it's very unlikely that one got removed
[14:03:29 CET] <Phidelux> my problem is that i have an old patch for 2.8.3 which adds an acs support to ffmpeg, the patch applies with some modifications on ffmpeg 3.2.2
[14:03:34 CET] <wm4> external demuxers are not possible
[14:03:48 CET] <wm4> some things probably changed internally
[14:03:54 CET] <wm4> most importantly the codecparams stuff
[14:04:16 CET] <Phidelux> yeah and exactly this is my problem, the codedc is not detected correctly
[14:07:38 CET] <Phidelux> When running ffmpeg i always get the message: parser not found for codec none, packets or times may be invalid.
[14:08:05 CET] <Phidelux> There seems to be a problem with specifying the codec id
[14:08:33 CET] <wm4> follow the deprecation warnings, fix them all
[14:34:36 CET] <durandal_1707> Phidelux: whats full name of format?
[14:35:27 CET] <Phidelux> durandal_1707: Advanced IP-Camera Stream (ACS) Header
[14:45:20 CET] <durandal_1707> Phidelux: depending on format complexity it should be trivial to port it, just convert to codecpar
[14:45:45 CET] <Phidelux> Yeah seems to work, still compiling, thanks
[14:46:28 CET] <Phidelux> ACS is a very simple format, just a static sized header packing audio and video packages 
[14:59:56 CET] <Phidelux> It now compiles successfully, however I get the error: Unable to parse option value "-1" as pixel format
[15:07:09 CET] <durandal_1707> Phidelux: is it raw video codec?
[15:07:39 CET] <Phidelux> no video codec is specified by codec id
[15:07:49 CET] <Phidelux> in my example case it is h264
[15:08:13 CET] <Phidelux> but it can also be mpeg4
[15:08:37 CET] <durandal_1707> than you give wrong data in packets perhaps?
[16:29:27 CET] <Phidelux> wm4 and durandal_1707 thanks for your help
[19:00:00 CET] <kierank> Sesse: ^
[19:00:56 CET] <Sesse> hups
[19:01:10 CET] <Sesse> probably misaligned block
[19:01:34 CET] <Sesse> ff_clear_block_sse probably assumes (undocumented) that the pointer is aligned
[19:02:37 CET] <Sesse> probably DECLARE_ALIGNED?
[19:04:20 CET] <kierank> yes
[19:05:48 CET] <Sesse> posted a patch to the bug
[19:20:24 CET] <atomnuker> michaelni: when will you make a webpage from gsoc 2017 projects/ideas? is it a bit too early?
[19:20:59 CET] <atomnuker> I have a nice idea about a project
[19:41:16 CET] <jamrial> Sesse: avcodec/blockdsp.h clearly states BlockDSPContext.clear_block needs its only param with an alignment of 16 bytes
[19:41:46 CET] <wm4> fritsch: fernetmentas Mesa patch for 10 bit vaapi works fine for mpv
[19:42:03 CET] <Sesse> jamrial: oh wow, it's within the definition
[19:42:12 CET] <Sesse> jamrial: I don't look there for documentation, sorry :-)
[19:42:24 CET] <wm4> atomnuker: make one yourself, has the nice side effect that you stop him from copying the same lame old ideas every gsoc that nobody picks up
[19:43:13 CET] <Sesse> jamrial: anyway, the patch should fix it
[19:43:13 CET] <wm4> like projects centered around libpostproc
[19:43:38 CET] <jamrial> in general, you should always look at the header defining the dsp context you want to use. that's where things like aligment are documented
[19:44:16 CET] <jamrial> Sesse: yeah, it should
[19:44:18 CET] <jamrial> send it to the ml if you can, though
[19:45:24 CET] <Sesse> done
[20:19:16 CET] <atomnuker> wm4: well I wonder how many will pick this one up
[20:20:25 CET] <wm4> only one way to know
[20:27:55 CET] <Compn> atomnuker : yes i agree start it yourself :)
[20:28:14 CET] <ubitux> BBB: wm4: afaik this warning is not supposed to happen unless there is a bug in the decoder
[20:28:27 CET] <BBB> thats true, yes
[20:28:27 CET] <ubitux> i don't mind either path
[20:28:35 CET] <wm4> could be replaced by an assert?
[20:28:36 CET] <BBB> but it can be invoked with crafted bitstreams
[20:28:40 CET] <Compn> atomnuker : yet another audio codec? :)
[20:28:43 CET] <BBB> no, assert is not a good idea IMO
[20:28:44 CET] <wm4> BBB: aw
[20:28:47 CET] <BBB> sorry
[20:29:02 CET] Action: Compn wonders why wm4 and kierank dont write down new gsoc ideas because they hate the old ideas
[20:29:16 CET] <ubitux> tell me when you guys figured out what you prefer
[20:29:46 CET] <wm4> if it's not an internal logic bug but some sort of weird corner case (?) I'm still fine with av_log inside a lock
[20:29:58 CET] <ubitux> Compn: the project needs advanced developers for architectural and very complex problems, not intern monkeys
[20:30:33 CET] <BBB> its probably ok to keep it as-is, but it does mean a totally bogus av_log callback implementation could potentially hang upon crafted input if it directly calls back into the pthread decoder
[20:30:44 CET] <BBB> if thats ok and an app bug were willing to accept, then its fine to keep it as-is
[20:30:58 CET] <ubitux> don't we already have many av_log in locked contexts?
[20:31:01 CET] <BBB> (because admittedly its only with crafted input so who cares, but then again it does hang so maybe we do care, I dont know)
[20:31:54 CET] <wm4> IMO the only sane semantics for av_log callbacks is that it must be fine with such situations
[20:32:09 CET] <BBB> if thats the case, then we can keep it as-is
[20:32:23 CET] <BBB> its probably true that anything else would be an insane semantic
[20:32:30 CET] <BBB> but then again were dealing with apps such as mplayer :X
[20:32:35 CET] <wm4> I mean you could make up insane reentrancy problems if a av_log callback e.g. called AVCodecContext API on the same context
[20:37:43 CET] <Compn> ubitux : intern monkeys write bad project ideas, "advanced developers" complain about bad project ideas. its self-fulfilling prophecy
[20:39:51 CET] <BBB> wm4: yeah, thats the thing, you never know entirely
[20:40:19 CET] <BBB> wm4: the other concern was more a performance thing, in general av_log under locks should be avoided, but if its for programming errors or stuff only, I think its ok
[20:40:30 CET] <BBB> (since it should never happen on normal operation)
[20:42:19 CET] <wm4> would be nice to have it formalized what an av_log callback can do and what not, though
[20:46:28 CET] <michaelni> atomnuker, i see you already created one, thanks
[20:49:23 CET] <wm4> Compn: if we don't have attractive project ideas we won't attract interesting developers
[20:49:40 CET] <Compn> agree
[20:49:56 CET] <Compn> wm4 : thats why i suggest you write your project ideas down on the wiki :)
[20:50:33 CET] <wm4> I'm not an interesting person so I have no interesting ideas
[20:51:20 CET] <cone-074> ffmpeg 03Steinar H. Gunderson 07master:d68d7198beca: speedhq: Align blocks variable properly.
[20:57:48 CET] <BBB> so ubitux you work for gopro now? :D
[20:58:32 CET] <ubitux> yeah i guess
[20:58:34 CET] <ubitux> :)
[20:58:38 CET] <ubitux> for a while now
[21:00:09 CET] <JEEB> coolio
[21:01:50 CET] <wm4> fascinating
[21:02:31 CET] <ubitux> wm4: BBB: so patch is ok as is, or i need to split the av_log out?
[21:03:47 CET] <BBB> no its fine
[21:03:50 CET] <BBB> just keep it
[21:04:02 CET] <BBB> if assumption is that doing what I said is a bug, then no need to adjust to it
[21:08:20 CET] <wm4> ok with me
[21:12:35 CET] Action: gnafu notes that doing what BBB says is a bug.
[21:23:05 CET] <cone-074> ffmpeg 03Paul B Mahol 07master:2eaee6e79bfb: avcodec/qdrw: skip long comment for now
[21:26:20 CET] <cone-074> ffmpeg 03Matthieu Bouron 07master:0265aec5650d: swresample/aarch64: add ff_resample_common_apply_filter_{x4,x8}_{float,s16}_neon
[21:26:21 CET] <cone-074> ffmpeg 03Matthieu Bouron 07master:e109c54a697b: swresample/arm: cosmetic fixes
[21:36:00 CET] <fritsch> wm4: jep - same for kodi
[00:00:00 CET] --- Sat Jan 14 2017