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

[burek]

[01:01:07 CET] <cone-572> ffmpeg 03Michael Niedermayer 07master:c66498980301: fate: simplify filter-pp tests
[01:01:07 CET] <cone-572> ffmpeg 03Michael Niedermayer 07master:4ae7c3709958: fate: Use a variable QP input for fate-filter-pp
[01:15:07 CET] <cone-572> ffmpeg 03Anton Khirnov 07master:b04d009b0e1a: qsv: rename to qsvdec
[01:15:08 CET] <cone-572> ffmpeg 03Michael Niedermayer 07master:151ae8ea5b54: Merge commit 'b04d009b0e1a34b717f3d3bbf407aef0c742aff1'
[01:25:13 CET] <cone-572> ffmpeg 03Anton Khirnov 07master:d0a63d8b9896: qsvdec: split off some code that will be shared with the encoder
[01:25:14 CET] <cone-572> ffmpeg 03Michael Niedermayer 07master:b12eacb3837c: Merge commit 'd0a63d8b989647ffdb5f40da8e1feaffe1a8e791'
[01:32:43 CET] <cone-572> ffmpeg 03Anton Khirnov 07master:9ba27c2348d2: qsvdec: add 'decode' to the non-static function names
[01:32:44 CET] <cone-572> ffmpeg 03Michael Niedermayer 07master:d985976e54ae: Merge commit '9ba27c2348d26000257e891e40a72facb0d916be'
[01:41:59 CET] <cone-572> ffmpeg 03Anton Khirnov 07master:72b7441a10f5: lavc: add Intel libmfx-based H.264 encoder
[01:42:00 CET] <cone-572> ffmpeg 03Michael Niedermayer 07master:0a731e45964c: Merge commit '72b7441a10f578a1d0be7083d8f5adf6a01921c2'
[02:01:44 CET] <cone-572> ffmpeg 03Tucker DiNapoli 07master:303c3dada243: postproc: Removed unecessary if/else branch when getting QP.
[03:25:18 CET] <cone-572> ffmpeg 03Lukasz Marek 07master:56b7aa213882: doc/examples: add directory listing example
[04:28:04 CET] <Zeranoe> If FFmpeg was written in C++, would there be limitations that are not present in C?
[05:27:26 CET] <Timothy_Gu> http://insight-labs.org/?p=1682
[06:07:26 CET] <rcombs> Zeranoe: yeah, no named initializers for structs
[06:50:14 CET] <pross> Zeranoe: abi interoperability. urgh.
[10:58:47 CET] <j-b> good morning
[11:36:29 CET] <cone-181> ffmpeg 03Michael Niedermayer 07master:048b6331e079: avcodec/qsv_internal: Fix project name
[11:36:30 CET] <cone-181> ffmpeg 03Marton Balint 07master:625bd463cde8: af_channelmap: fix number of channels
[12:25:48 CET] <cone-181> ffmpeg 03James Cowgill 07release/2.6:7439ed2f398d: mips/float_dsp: fix vector_fmul_window_mips on mips64
[12:25:49 CET] <cone-181> ffmpeg 03Michael Niedermayer 07release/2.6:f3deed98ec40: avcodec/dnxhddec: Check that the frame is interlaced before using cur_field
[12:25:50 CET] <cone-181> ffmpeg 03Michael Niedermayer 07release/2.6:c3be71001cdd: avcodec/dnxhddec: Reset is_444 if format is not 444
[12:25:51 CET] <cone-181> ffmpeg 03Anton Khirnov 07release/2.6:e9eb9839bd4c: hevc: make the crop sizes unsigned (cherry picked from commit c929659bdd7d2d5848ea52e685a3164c7b901bb0)
[12:25:52 CET] <cone-181> ffmpeg 03Michael Niedermayer 07release/2.6:87e2a689a884: avcodec/hevc_ps: Check cropping parameters more correctly
[12:25:53 CET] <cone-181> ffmpeg 03Michael Niedermayer 07release/2.6:dfce316c12d8: avcodec/msrledec: restructure msrle_decode_pal4() based on the line number instead of the pixel pointer
[12:25:54 CET] <cone-181> ffmpeg 03Michael Niedermayer 07release/2.6:6a4d1325e200: avformat/rmdec: fix support for 0 sized mdpr
[12:25:55 CET] <cone-181> ffmpeg 03Micah Galizia 07release/2.6:eebd161e761f: avformat/hls: store cookies returned in HLS key response
[12:25:56 CET] <cone-181> ffmpeg 03Micah Galizia 07release/2.6:f2abcdedfe9d: avformat/hls: refactor repeated HLS option updates
[12:25:57 CET] <cone-181> ffmpeg 03Micah Galizia 07release/2.6:f90c9bbbca32: avformat/http: replace cookies with updated values instead of appending forever
[15:45:52 CET] <cone-004> ffmpeg 03Michael Niedermayer 07master:a8fb8f611229: avfilter/vf_qp: split expression parsing out of loop
[15:45:53 CET] <cone-004> ffmpeg 03Michael Niedermayer 07master:2856634c6798: vfilter/vf_qp: Support evaluating expression per MB
[15:45:54 CET] <cone-004> ffmpeg 03Michael Niedermayer 07master:68bcc64f74aa: fate/filter-video: Use qp filter to generate non constant qp array for more throughout testing of the pp filter
[17:08:18 CET] <wm4> I wonder what this apng guy is supposed to do
[17:09:47 CET] <wm4> he's not even in the qualification list
[17:14:32 CET] <jamrial> his email has a .moe tdl
[17:16:14 CET] <jamrial> but yes, i guess the task mentor should either add him to the qualification list, or ask him to do it himself
[17:30:01 CET] <cone-004> ffmpeg 03Donny Yang 07master:5904d039ce78: png: Use av_freep() instead of av_free()
[17:30:02 CET] <cone-004> ffmpeg 03Donny Yang 07master:fe57514f8a66: png: Minor whitespace change and added missing comment
[17:35:46 CET] <rcombs> I should route emails for my moe domains
[19:01:52 CET] <himangi> michaelni: hi
[19:38:50 CET] <michaelni> himangi, hi
[19:44:47 CET] <himangi> michaelni: I was just working on feedback on some old libav patches.. should I send a single patch to both libav-deval and ffmpeg-devel? The files are not exactly the same..
[19:52:02 CET] <cone-004> ffmpeg 03Carl Eugen Hoyos 07master:dcac15a84c8f: lavc/dnxhd: Fix pix_fmt change.
[19:53:10 CET] <michaelni> himangi, the patch should apply cleanly to ffmpeg and should be tested, i dont know if that can be done with a single patch
[19:53:51 CET] <himangi> michaelni: no that can't.. which means I'll have to rework each patch :(
[19:54:18 CET] <wm4> just send it to Libav
[19:54:33 CET] <wm4> that's the least work required from a contributor point of view
[19:54:47 CET] <wm4> (if you actually want that patch in everywhere)
[20:01:39 CET] <cone-004> ffmpeg 03Carl Eugen Hoyos 07release/2.6:8bd7bf1a3cb4: lavc/dnxhd: Fix pix_fmt change.
[20:12:52 CET] <jamrial> is that why your mmal patchset is on libav-devel only?
[20:17:09 CET] <michaelni> wm4, this is very wrong and hostile
[20:17:37 CET] <michaelni> its important that patches get reviewed on ffmpeg devel and tested against ffmpeg
[20:20:35 CET] <wm4> michaelni: you expect contributors to write, test and send patches twice, that's also hostile
[20:21:24 CET] <wm4> and if there's something wrong, it's automatic merging of anything without extra testing (like that avisynth disaster recently)
[20:23:28 CET] <michaelni> wm4, i did test the avisynth code it worked but only on linux because i tested only on linux, that shows why its important that patches are tested against ffmpeg by the author if at all possible
[20:34:14 CET] <iive> wm4: you don't think that merging libav code into ffmpeg is an fully automated process, that no ffmpeg developer have to do manually, do you?
[20:38:16 CET] <kierank> It's also important not to merge crap
[20:39:12 CET] <iive> well, I do think that the time to stop merging libav is getting closer and closer.
[20:41:23 CET] <jamrial> how so?
[20:46:38 CET] <kierank> See above conversation
[20:47:12 CET] <kierank> Anyhow if someone goes and forks FFmpeg don't say that nobody said anything
[20:47:19 CET] <kierank> Because we do every week
[20:49:09 CET] <durandal_1707> where?
[20:50:09 CET] <kierank> wm4 just did
[20:52:00 CET] <wm4> huh
[21:03:11 CET] <kierank> I'm saying that many people have complained about the poor merge policy in ffmpeg
[21:03:32 CET] <kierank> So don't be surprised if theres a fork
[21:05:34 CET] <iive> forking is easy. merging is harder.
[21:12:41 CET] <j-b> m
[21:26:38 CET] <durandal_1707> link?
[21:26:52 CET] <michaelni> If someone has suggestions to improve something in FFmpeg, it would be best to post them to the mailing list. 
[21:43:51 CET] <kierank> durandal_1707: see ffmpeg-devel irc log
[21:49:10 CET] <durandal_1707> I see nothing special in logs
[22:14:14 CET] <kierank> grep Daemon404, myself, wm4 and others
[22:14:19 CET] <kierank> 24bit wmalossess
[22:14:20 CET] <kierank> flv
[22:14:21 CET] <kierank> etc
[22:15:44 CET] <jamrial> the wmalossless wasn't about merges, but about a patch of doubtful quality being applied
[22:17:27 CET] <kierank> splitting hairs...
[22:22:32 CET] <jamrial> IMO it's different. the libav merges went through the whole libav review process and potential bikeshedding, whereas the wmall and flv patches were big changes that made it into the tree with little to no reviews
[22:22:44 CET] <wm4> Libav review process is a bit too strict (and maybe not even appropriate anymore), but ffmpeg seems too lax
[22:23:00 CET] <jamrial> the latter is a valid complain, the former not so much. and the only person i saw complaining a lot about the libav merges was Koda
[22:24:49 CET] <michaelni> I really would like to see more people review patches on ffmpeg-devel. If there was someone who would maintain wmalossless for example and review all patches to it that would not hurt
[22:25:54 CET] <michaelni> also bad patches can be reverted if a bad patch got applied, theres no reason to be bitter about it, just post a patch that reverts it and explain why its better reveted
[22:29:50 CET] <michaelni> also anyone wants to review the 4 trivial patches i just posted ?
[22:30:46 CET] <wm4> michaelni: didn't you do like 20 of these without review before?
[22:32:10 CET] <michaelni> wm4, i did, but i was wondering now if someone wants to review them
[22:32:14 CET] <michaelni> so i posted these
[22:32:28 CET] <iive> reviewing patches is not an easy task and it weight quite an responsibility. If only one person reviews all patches, he also gets all the blame for any problem they cause.
[22:40:45 CET] <iive> anyway, if somebody wants things done differently, it would be good idea to explicitly and clearly state what and how do they want the things changed.
[22:41:20 CET] <iive> complaining and blaming are not exactly constructive.
[22:44:06 CET] <iive> So let me start. I do not think that it helps ffmpeg when some people recommend to contributors to send patches exclusively to libav.
[22:44:48 CET] <iive> Libav works as bottleneck. it review process is slow, they even forget patches and discourage people.
[22:45:55 CET] <iive> it's quite common that they rush to review a contribution one it's been merged into ffmpeg.
[22:46:32 CET] <wm4> examples?
[22:46:59 CET] <iive> h265 is probably the biggest example.
[22:47:32 CET] <iive> there was a recent dca... and few others i can't recall atm.
[22:47:52 CET] <wm4> h265 was developed on the Libav side
[22:48:01 CET] <wm4> ffmpeg rogue-merged it (without reviews, I think?)
[22:48:07 CET] <nevcairiel> qh265 was developed independently really
[22:48:55 CET] <wm4> from what I've seen it was on a stripped Libav fork, and Libav initiated the process of merging it back
[22:48:59 CET] <iive> wm4:  yes, for that reason libav complaining that ffmpeg merges a lot of "code that is not ready" is quite regular talking point.
[22:49:02 CET] <jamrial> your atmos patch was in limbo for like half a year, for example
[22:49:30 CET] <wm4> anyway, it's the same old story
[22:49:35 CET] <wm4> fork politics
[22:49:55 CET] <iive> the truth is that h265 have been ready for merging for almost a year.
[22:50:22 CET] <iive> and yes, it was libav project.
[22:51:07 CET] <iive> well, You see, merging code that is not ready is common complain here.
[22:51:29 CET] <iive> and the solution always seems to be demanding more review and slowing things down.
[22:54:50 CET] <iive> wm4: well, I rise this topic specifically for you, because of the things you said 3 hours ago.
[22:55:53 CET] <wm4> well, definitely reviewing Libav merged stuff would help?
[22:56:18 CET] <wm4> instead of letting it merge by michaelni "in the background", specifically pick Libav patches, review them, apply them as any other patch
[22:57:10 CET] <nevcairiel> noone has the man power to do that, it would end up the same way as libav is today, too many things that dont get merged because not enough people review and apply them
[22:57:33 CET] <wm4> probably.... this is also why ffmpeg survived libav
[22:57:53 CET] <iive> ffmpeg and libav codebase is starting to diverge. This makes merges harder and harder. It would be better that contributors take the load for their contributions.
[22:58:05 CET] <jamrial> every commit gets merged if anything for metadata (hash references in commit messages). stuff that can't or should not be actually applied to the tree is discarded as part of the commit merge
[22:58:45 CET] <jamrial> in more than one case some dev asked michaelni to not "merge" something that would change a previous behaviour on ffmpeg. cehoyos comes to mind
[22:58:53 CET] <jamrial> or simply asked to be reverted
[23:01:24 CET] <cone-004> ffmpeg 03Michael Niedermayer 07master:6a3833e1411e: ffmpeg_opt: Do not overwrite output if there is no input
[23:04:52 CET] <pross> whats the definition of 'not ready' for merge?
[23:05:57 CET] <pross> security? bugs? partial implementation? stylistic concerns (whitespace nonsense)?
[23:06:53 CET] <iive> basically, code that is not perfect.
[23:11:02 CET] <pross> great, let them be perfect.
[23:11:45 CET] <iive> my point exactly :)
[23:11:46 CET] <wm4> in the h265 case, Libav was actively working on working out some details, AFAIR
[23:11:53 CET] <wm4> when ffmpeg merged it to be first
[23:13:12 CET] <iive> well, h265 had surprisingly small number of issues after ffmpeg merge and they got sorted out quite quickly.
[23:13:51 CET] <iive> and you can work on details indefinitely.
[23:14:04 CET] <pross> isn;t that what master:HEAD is for?
[23:14:25 CET] <iive> yes
[23:18:27 CET] <wm4> iive: that's a very weak and "stretchy" argument, you could say that about anything
[23:18:41 CET] <iive> h265 developers also had time to write SIMD optimization. yes, intrinsic, but simd.
[23:19:27 CET] <iive> you should be well aware that's literally the last thing to do in a codec.
[23:20:17 CET] <iive> well, of course it is stretchy,  there are many shades of gray, but you have to cut the line somewhere.
[23:22:46 CET] <wm4> here the line was Libav was almost done when ffmpeg (well, michaelni) suddenly merged it, probably using the Libav patches as base, not the openhevc ones
[23:23:06 CET] <wm4> and intrinsics are still pretty different from asm
[23:23:19 CET] <iive> wm4: actually h265 developers came to this channel.
[23:23:22 CET] <wm4> AFAIK there are still some important bits that are faster in openhevc than in libav/ffmpeg
[23:23:29 CET] <iive> and I think they helped in the merge too.
[23:25:05 CET] <wm4> maybe he did, but the point is that most cleanup work was (probably) done by Libav
[23:25:29 CET] <wm4> ffmpeg could have waited until Libav was done, but no, ffmpeg HAD to have h265 before Libav
[23:25:51 CET] <iive> the point is, that is wasn't worth the wait
[23:26:01 CET] <wm4> how do you even know
[23:26:06 CET] <wm4> (or claim to know)
[23:26:38 CET] <wm4> it also doesn't change anything about what I said
[23:26:43 CET] <wm4> anyway, pointless discussion
[23:27:05 CET] <iive> not really
[23:27:41 CET] <iive> you see, this is the whole point. How long does it take to iron out the last few details until the work is complete?
[23:28:09 CET] <iive> openh265 have been in perfectly working state for over a year.
[23:28:12 CET] <wm4> yeah, why not duplicate all the effort
[23:28:27 CET] <wm4> but they also did things not accepted in ffmpeg/libav
[23:28:39 CET] <iive> intrinsics
[23:28:40 CET] <wm4> you don't deny that there was a huge cleanup on merge, do you
[23:30:46 CET] <iive> ffmpeg or libav? don't really remember.
[23:34:36 CET] <iive> wm4:  duplicating the effort...
[23:34:40 CET] <wm4> meanwhile, what the heck are they thinking in that .zip thread
[23:34:57 CET] <wm4> something about escaping to avoid clashes with local files (which makes no sense)
[23:35:12 CET] <wm4> iive: what
[23:36:36 CET] <iive> about dup... imagine a scenario where contributor have the option of sending a single patch to libav, that patch would take 6 months to pass all review, or
[23:36:50 CET] <BtbN> Still not a fan of that zip thing, i don't think that belongs into ffmpeg.
[23:37:48 CET] <iive> he could send patches to both ffmpeg and lib, where ffmpeg would merge it the 2 weeks, and in worst case request some fixes after another week.
[23:38:22 CET] <iive> do you think that getting your code merged faster, warrant making more effort?
[23:38:25 CET] <wm4> actually I've had this in ffmpeg too
[23:38:39 CET] <wm4> I had a patch that was in limbo for 6 months until someone else needed it
[23:38:56 CET] <wm4> (I didn't care too much about it though)
[23:42:26 CET] <iive> somebody mentioned above your atmos patch, is that it?
[23:43:48 CET] <wm4> the atmos patch was nevcairiel's
[23:43:57 CET] <wm4> and that one was slow on the Libav side
[23:47:50 CET] <iive> i think there was a rule that if nobody objected to a patch for a few days, the developer is free to push it on his own.
[23:47:57 CET] <iive> aren't ffmpeg developer?
[23:48:04 CET] <iive> aren't you ...
[23:49:09 CET] <wm4> I don't know, I probably have push access
[23:57:23 CET] <iive> well, i think it is kind of polite to not push other people's patches, just in case they are working on improvement or something.
[00:00:00 CET] --- Sun Mar 29 2015