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

[burek]

[00:40] <jamrial> so there were distros using 2.3 and 2.4 after all
[01:04] <cone-902> ffmpeg.git 03Moritz Barsnick 07master:754f4957d7a7: configure: use use_pkg_config() instead of check_pkg_config() for libsmbclient
[02:25] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:e86df0206f06: avdevice/xcbgrab: check xcb_query_pointer_reply_t pointer before use
[02:34] <koda> michaelni: WTF
[02:34] <koda> The default is left unchanged at enabled
[02:34] <koda> We can change the default if people prefer but i do not want to do that
[02:34] <koda> in a merge.
[02:34] <koda> thats the exact opposite!!!
[02:35] <koda> michaelni: you shouldnt change the a patch beahaviour in a merge
[02:35] <koda> its _quite_ annoying, please revert as soon as possible
[02:36] <koda> michaelni: also i was FREAKING HERE, why couldnt you discuss this stuff before doing that!!!!
[02:40] <michaelni> koda, FFmpeg supported XMP before that merge and that was enabled by default, while the libav side has it disabled by default, i had to pick one of the 2. Also others have stated their preferrance of it being disabled so i intended to disable it already but just hadnt yet done, will do it soon.
[02:41] <koda> michaelni: i do not care about politcs, if you merge a patch, merge it fully and then change its behaviour in a separate commit please
[02:41] <koda> if *at all*
[02:41] <koda> and possibly get the author involved
[02:52] <BBB> so much eergy wasted in anger&
[02:53] <jamrial> koda: that's double the work, it was never done that way, and hasn't really generated many issues so far
[02:54] <jamrial> and in the few cases it did, a revert was requested/suggested, or a patch doing the revert was posted to the ml
[02:57] <michaelni> koda, posted a patch to ffmpeg-devel, ill push it when there are no objections on the ml
[04:03] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:9e561410c08e: avformat/utils: Pass the next pts/dts to compute_pkt_fields() when available
[04:03] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:dd70470d7275: avformat/utils: Compute the current pts of mpeg1/2 I/P frames from the next frame when available
[04:48] <rcombs> ~and the thread goes on~
[05:12] <cone-902> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:f95cfff07765: ffserver_config: check strchr() return for NULL
[05:12] <cone-902> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:b28d5877826c: ffserver_config: improve error/warning messages
[05:12] <cone-902> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:b4c69b7ea8c0: ffserver_config: break lines at 80 chars
[05:12] <cone-902> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:720dffb843aa: ffserver_config: reflow add_codec()
[06:23] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:a5e5959d5286: avformat/utils: fix calculating the absolute difference of timestamps
[06:29] <visiot> can anyone help me on pcr repetition error
[06:30] <visiot>  my network analyzer is continously saying pcr repition error
[07:37] <ubitux> 02:41:03 < koda> michaelni: i do not care about politcs, if you merge a patch, merge it fully and then change its behaviour in a separate commit please // the commit is left verbatim thanks to the merge, and the merge itself is another commit where changes can be documented and explained
[09:02] <arwa> what is the next filter you want me to work on, once uspp is wrapped up?
[09:03] <ubitux> kierank: still no opinion on ilpack?
[09:04] <kierank> ubitux: i plan to sort it out this week
[09:04] <ubitux> thx
[09:04] <kierank> and add chroma placement to vf_scale
[09:04] <kierank> ubitux: it's not hard, arwa could do it
[09:05] <ubitux> explain it to her then please, i have no idea what it's about :)
[09:05] <kierank> arwa: hello
[09:05] <ubitux> (arwa: btw, since you're almost done with uspp, can you take the opportunity to fix the style?)
[09:06] <arwa> hello :D
[09:07] <arwa> do you mean fix the coding style in uspp?
[09:07] <ubitux> yes, the random space shuffling
[09:07] <ubitux> like, make it consistent
[09:07] <ubitux> even the original code is more consistent in its spacing :p
[09:07] <ubitux> (since you mix the common coding style from spp with the one from michael)
[09:08] <arwa> okay.
[09:08] <arwa> I will fix it :)
[09:08] <ubitux> thanks
[09:11] <ubitux> arwa: i think you can remove the hack to "avoid crash for Y8 coulourspace"
[09:11] <ubitux> it looks related to mplayer somehow
[09:11] <arwa> okay cool :)
[09:11] <arwa> and the fixmes?
[09:13] <ubitux> about the "init per MB qscale stuff" FIXME michaelni could probably tell you
[09:13] <ubitux> about the "optimize" one, you can drop it
[09:14] <ubitux> btw, since the filter depends on a specific codec... you should probably make the filter select the snow codec in the configure
[09:14] <ubitux> or put it as dep
[09:15] <ubitux> look around line 2560 in the configure
[09:16] <ubitux> arwa: so did you compare the output with -vf uspp and -vf mp=uspp? did you check if valgrind wasn't complaining?
[09:18] <arwa> what do you mean by dep?
[09:19] <ubitux> setting either uspp_filter_select or uspp_filter_deps in the configure; people more familiar with the build system can tell you which to set
[09:19] <arwa> when i am doing make ffmpeg, i am getting this warning - warning: ‘avcodec_encode_video’ is deprecated (declared at ./libavcodec/avcodec.h:4481) [-Wdeprecated-declarations]
[09:20] <arwa> valgrind is also working fine.
[09:20] <ubitux> if you look at the doxy in libavcodec/avcodec.h, it says "@deprecated use avcodec_encode_video2() instead."
[09:21] <ubitux> so you should probably switch to it, if possible
[09:21] <arwa> i will try doing that
[09:37] <kierank> arwa: basically vf_scale has an interlaced mode
[09:37] <kierank> but in interlaced 4:2:0 chroma is sited differently
[09:37] <kierank> vf_scale needs to take that into account and pass the correct chroma flags to swscale
[09:38] <arwa> okay
[09:40] <arwa> so what do i need to do?
[09:40] <kierank> Page 22 has a good explanation
[09:40] <kierank> https://dl.dropboxusercontent.com/u/2701213/Specs/T-REC-H.264-201003-I%21%21PDF-E.pdf
[09:40] <kierank> Page 22 as written in the document
[09:41] <kierank> you'll need to understand what vf_scale is doing in interlaced mode
[09:41] <kierank> which is basically scaling each field
[09:42] <kierank> and then you'll need to make sure the sws context is setup with the correct chroma positioning if the input or output (or both) is 4:2:0
[09:43] <arwa> okay. 
[09:43] <arwa> i will go through the pdf
[09:45] <j-b> 'lo
[10:51] <rcombs> is git.videolan.org acting up for anyone else?
[10:52] <j-b> rcombs: for everyone
[10:52] <j-b> rcombs: it will be back in 2 minutes
[10:52] <rcombs> OK, cool
[11:00] <tyr>  Setting default value for video max rate = 512000. Use NoDefaults to disable it.
[11:00] <tyr> how to solve this problem 
[11:00] <rcombs> and back up :)
[11:04] <tyr> ?
[11:09] <arwa> can anyone help me with avcodec_encode_video2? one of its arguments is avpacket, and i  am not getting how to deal with it.
[11:10] <kierank> ubitux: 
[11:10] <kierank> 10:09 AM <arwa> can anyone help me with avcodec_encode_video2? one of its arguments is avpacket, and i  am not getting how to deal with it.
[11:10] <kierank> maybe you know
[11:10] <Mavrik> Hmm, there's a bug in configure script in 2.5: sdp.c:(.text+0x22cb): undefined reference to `ff_isom_write_hvcc' ... SDP muxer uses a HEVC utils function which isn't enabled together
[11:10] <Mavrik> Does anyone know enough about ffmpeg build system to see where I can start looking into it? :)
[11:11] <ubitux> arwa: i would guess you need to AVPacket pkt = {.data = ..., .size = ...}
[11:11] <BtbN> Well, basicaly everything is in the configure script, Mavrik 
[11:11] <ubitux> arwa: but i don't know how the allocation of the data is handled
[11:11] <arwa> okay
[11:12] <ubitux> like, in the filter i mean
[11:12] <ubitux> yeah right so basically it allocates the outbuf
[11:13] <ubitux> you can try doing .data=outbuf and .size=outbuf_size
[11:13] <ubitux> and see how it goes
[11:13] <ubitux> but you probably could be smarter in the allocation
[11:13] <ubitux> (like using av_alloc_packet or something like that)
[11:13] <arwa> okay i will try
[11:20] <arwa> It is working :)
[11:21] <arwa> but i am getting this - [snow @ 0x4f7df00] Provided packet is too small, needs to be 34.
[11:57] <cone-141> ffmpeg.git 03Dave Rice 07master:3c01039e0bc7: mov: further expand the list of parsed metadata tags
[11:57] <cone-141> ffmpeg.git 03Michael Niedermayer 07master:99bf26fc6b17: Merge commit '3c01039e0bc7d269900e15551f8171c4328a0223'
[12:08] <cone-141> ffmpeg.git 03Martin Storsjö 07master:f963f80399de: arm: Use .data.rel.ro for const data with relocations
[12:08] <cone-141> ffmpeg.git 03Michael Niedermayer 07master:16e65419ed3e: Merge commit 'f963f80399deb1a2b44c1bac3af7123e8a0c9e46'
[12:22] <cone-141> ffmpeg.git 03Martin Storsjö 07master:780cd20b00a6: aarch64: Use .data.rel.ro for const data with relocations
[12:22] <cone-141> ffmpeg.git 03Michael Niedermayer 07master:92d47e2aa391: Merge commit '780cd20b00a69e26bbfffbb8eec16fbe999ea793'
[12:55] <koda> jamrial: ubitux: i do not care if its double the work or if its left verbatim or whatever, its incredibly silly to change things in a merge commit
[12:55] <koda> it makes bisecting almost impossibile and creates unnecessry change
[12:56] <koda> and this is a one line change so its easy to spot, what if the change is spread across multiple changes block
[12:56] <koda> its a policy i do not like and i am surprised you tolerate so easily
[12:58] <ubitux> bisecting is working fine, and we have tools for that
[12:58] <ubitux> we don't "tolerate" it
[12:58] <ubitux> we *want* it
[12:58] <ubitux> it's important to keep the commit as is, and only the merge can do that
[12:58] <ubitux> i also like to see how merges are done
[12:59] <ubitux> like what differs between libav and ffmpeg and what has been changed
[12:59] <ubitux> this is the exact purpose of a merge commit
[12:59] <koda> no, the merge commit change already so many lines, adding changed lines make reading the merge even more difficult
[12:59] <koda> to read
[12:59] <wm4> to be fair, git was never meant to keep two different but similar projects in sync
[12:59] <koda> you merge as is, then you change behaviour on top!
[12:59] <ubitux> you can't merge as is
[12:59] <ubitux> unless you create a broken state
[13:00] <nevcairiel> a merge shouldnt start  re-writing the original patch, but if changes are required to get the original change to work at all, then it needs to be inside the merge commit
[13:00] <ubitux> and in this case the current behaviour needed to be kept
[13:00] <koda> this was no such case as reported, it was a behaviour change
[13:00] <koda> which got rejcted without discussing it for
[13:00] <koda> only because some people complained its being restored
[13:01] <ubitux> ffmpeg behaviour was exporting by default
[13:01] <koda> so what
[13:01] <ubitux> so michael kept that behaviour by changing the default in the merge, and notified about it
[13:01] <ubitux> which is sane.
[13:01] <koda> yeah he shouldnt have
[13:01] <ubitux> and what we want
[13:01] <koda> no its not
[13:01] <koda> no its what youre stuck with
[13:01] <ubitux> there is a need for discussion to change the behaviour
[13:01] <ubitux> not to keep it
[13:01] <koda> maybe mergeing from a project with completely different design goals and decision isnt the best of ideas
[13:02] <koda> since this case is going to come up over and over
[13:02] <ubitux> that is not your problem
[13:02] <wm4> do you want ffmpeg to stop merging libav work?
[13:02] <koda> ubitux: how its not my problem???
[13:02] <wm4> or do you want mini to switch to cherry-picking
[13:02] <wm4> koda: wut
[13:02] <ubitux> koda: not a single byte of your commit is changed
[13:02] <ubitux> the merge is ffmpeg specific and has changes ffmpeg specific
[13:03] <wm4> koda: last I checked you hated ffmpeg
[13:03] <koda> ubitux: but in the end the behaviour i had intendted/needed is no more there
[13:03] <koda> wm4: i never said that
[13:03] <ubitux> yes because that's a different project?
[13:03] <ubitux> the change from your commit is under Michael's name
[13:03] <nevcairiel> and how would that be different if there was a dedicated commit to just change that? end result is the same, its changed :p
[13:04] <koda> ubitux: on the surface yes, in practice its a downstream library as many others
[13:04] <koda> nevcairiel: that it was easier to spot
[13:04] <wm4> I have to admit the merging makes copyright attribution perfectly clear
[13:04] <ubitux> we are going to document the behaviour change
[13:04] <ubitux> but we can't make a behaviour change like this
[13:04] <koda> no you are going to keep the flag disabled
[13:04] <koda> because its the sane thing to do
[13:05] <ubitux> no we are going to disable it
[13:05] <koda> no you are not
[13:05] <ubitux> because current behaviour was to export it since months
[13:06] <ubitux> and now we discuss the behaviour change of disabling it
[13:06] <koda> and so what?? ony because it was like that in the past doesnot mean it should remain like that
[13:06] <koda> and not having touched the flag would have prevented this discussion
[13:06] <ubitux> it's fine to change it, we just need to document it
[13:06] <koda> nor the future dicsussion about mergring it or not
[13:06] <ubitux> except it would have change current ffmpeg behaviour
[13:07] <ubitux> so we can't do that without a bump and documenting it
[13:07] <ubitux> which we are probably going to do
[13:07] <koda> the behaviour is going to be changed anyway
[13:07] <ubitux> well there is a patch to discuss it
[13:07] <ubitux> we intend to, but nothing decided yet
[13:07] <koda> yes, a patch that could have been avoided
[13:07] <ubitux> no?
[13:07] <koda> if things were done in the clear
[13:08] <nevcairiel> avoided by just merging your decision without discussion on ffmpegs side, right? :p
[13:09] <wm4> so let me get this straight
[13:09] <ubitux> koda: it's important to send patchs to change behaviours...
[13:09] <wm4> this is about xmp export
[13:09] <wm4> ffmpeg supported it ages ago?
[13:09] <ubitux> yes, and exported it
[13:09] <wm4> and exported it by default?
[13:09] <ubitux> yes
[13:09] <wm4> and now koda cherry-picked this to Libav
[13:09] <ubitux> that's why the merge commit change the default to keep this behaviour
[13:09] <wm4> and changed the default (to not exporting)
[13:09] <ubitux> yes
[13:09] <wm4> and ffmpeg merged it back (fucking comedy)
[13:09] <wm4> and kept its default
[13:09] <wm4> and now koda (Libav dev) is complaining
[13:09] <wm4> WHAT
[13:09] <wm4> THE
[13:09] <wm4> FUCK
[13:10] <wm4> koda: how does this make any sense
[13:10] <koda> wm4: my only complaint was that it was done in a merge commit without discussion before
[13:11] <nevcairiel> keeping the current default doesnt require a discussion
[13:11] <nevcairiel> changing it does
[13:12] <wm4> koda: why should there be a discussion
[13:16] <koda> wm4: because the behaviour intented in the patch is changed, and makes reading changes more difficult, since a merge commit already lists a lot of changes its not the case to add more in my view
[13:16] <ubitux> 13:09:57 <+wm4> WHAT
[13:16] <ubitux> oups
[13:16] <ubitux> > the behaviour intented in the patch is changed
[13:16] <ubitux> in another commit.
[13:16] <wm4> koda: well, as you heard, making the change separate is technically not possible
[13:17] <wm4> that is, separate, and not a merge commit
[13:17] <wm4> you can either do it the way it's currently done, or as cherry-pick
[13:18] <nevcairiel> we should rather complain about cherry-picking and changing the default in the original patch, as libav would've done in this situation, because that totally obfuscates the origin and intention of the change
[13:18] <ubitux> keeping the behaviour in the merge commit makes sure that it's not changed in between 2 successive commit
[13:19] <ubitux> and the merge commit is necessary anyway for integration with keeping original commit verbatim
[13:19] <ubitux> as a result you're supposed to look at the merge commit anyway
[13:19] <ubitux> the point of the "merge" is integration
[13:19] <ubitux> and such integration must keep current behaviour whenever possible
[13:20] <koda> ubitux: imho the discussion should have just been before merging an email from michaelni hey i am about to merge this code, what behaviour should be the default? discuss
[13:20] <wm4> also, I think not exporting this info by default makes no sense
[13:20] <ubitux> koda: no.
[13:20] <wm4> this is ffmpeg.c's fault
[13:20] <koda> not decide single handedly what goes in and out
[13:20] <ubitux> koda: "i merged this commit and behaviour changed: we need discussion if we want to change it"
[13:20] <wm4> koda: he sometimes does this for important changes
[13:21] <wm4> koda: but normally, these merges attempt to minimize the negative impact on ffmpeg
[13:21] <ubitux> and current behaviour *was kept* (sorry)
[13:21] <wm4> koda: now imagine you have a tool that uses ffmpeg and does something with the xmp data
[13:21] <wm4> koda: what do you think would happen if the default would suddenly change to "not export"
[13:28] <koda> wm4: i dont question changing the default or keeping it, i just dont like the fact that such decision was done in a merge commit (first) with no discussion before (second)
[13:28] <koda> but the point has been made clear, so lets move on
[13:34] <ubitux> the point has been made clear that the correct things were made
[13:37] <koda> ubitux: not the correct thing, the ffmpeg way of doing thing
[13:37] <koda> it could be right or wrong depending on the point of view
[13:37] <ubitux> no
[13:37] <ubitux> it's not opinion, it's a technical matter here
[13:38] <koda> yes
[13:38] <koda> its a technical opinion
[13:38] <koda> but still opinion
[13:47] <kierank> koda: no decision was made
[13:47] <kierank> they parsed xmp before and they parse it after
[13:47] <koda> kierank: is this your definition of lets move on?
[13:48] <kierank> sorry i didn't see that bit
[14:09] <rcombs> I'm of the opinion that there are two valid arguments to be made here, but nothing that anyone needs to be angry about
[15:55] <cbsrobot_> not taking sides on any project or person, I support the fact to merge the patch, keep the current behavior of ffmpeg and write a comment about it for people to discuss  
[15:56] <cbsrobot_> but one problem remains: if you transcode a file with a *lot* of metadata and you cannot see it on the terminal, the size of the file will still be huge
[15:57] <cbsrobot_> so maybe it would be a better option to truncate the metadata after a few lines and just print the remaining size of it
[16:10] <koda> cbsrobot_: you have a lot of memory allocated for that data, and its not human readable imho its better not to export it at all
[16:12] <cbsrobot_> koda: I agree, but from a user perspective, how do you know the xmp metadata is there and taking lots of space ?
[16:13] <koda> a normal user does not even know what xmp is, a custom application may always enable it all the times and write its own dumping routines for it
[16:26] <wm4> koda: to normal users, mp4 metadata will contain a load of crap
[16:27] <wm4> like "major_brand" etc.
[17:09] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:308429e124b9: avformat/wavenc: check return value of strftime()
[17:45] <ubitux> arwa: "for(i = 0 ; i < 3 ; i++) {" ’ "for (i = 0; i < 3; i++) {"
[17:45] <ubitux> if you fix the style, do it correctly :)
[17:45] <ubitux> you did it wrong in amny other places
[17:45] <arwa> okay
[17:45] <ubitux> many*
[17:46] <ubitux> i let you figure it out on your own, look at vf_spp.c for reference
[17:49] <arwa> okay :)
[18:18] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:041c6109da20: avformat/utils: replace impossible condition by av_assert0() in ff_gen_search()
[18:18] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:20cb3fab3f15: avformat/utils: change assert to av_assert0()
[19:46] <llogan> what's with these Indian guys posting image attachments of themselves(?) on trac?
[19:53] <llogan> anyway, deleted
[19:57] <ubitux> ffmpeg's trac is the new indian social website?
[20:00] <llogan> then he must not like women
[20:01] <llogan> ...dating site...
[20:05] <koda> llogan: ffmpeg -> freakingly fast meeting place (for) eny gender ;)
[20:05] <koda> *every* also works
[20:05] Action: koda loves acronyms
[20:05] <ubitux> tell saste to add it to his signatures
[20:07] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:2d0117f816b9: avformat/crypto: fix key vs iv typo
[20:08] <llogan> is "koda" an acronym?
[20:08] <koda> what is *not* an acronym :p
[20:23] <llogan> i like this description of AV_LOG_PANIC: "Something went really wrong and we will crash now." Like a polite, calm valet.
[20:49] <cone-22> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.2.11': unknown revision or path not in the working tree.
[20:49] <cone-22> Use '--' to separate paths from revisions
[20:49] <cone-22> refs/tags/n2.2.11:HEAD: avformat/crypto: fix key vs iv typo
[20:56] <ubitux> heh report on uspp
[21:49] <cone-22> ffmpeg.git 03Martin Storsjö 07master:fccfc22d1f30: libavformat: Build hevc.o when building the RTP muxer
[21:49] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:6ef9d1b21629: Merge commit 'fccfc22d1f304aef42a0b960e4c1d55ce67107f5'
[23:43] <cone-22> ffmpeg.git 03Carl Eugen Hoyos 07master:01ab761b46c5: Allow mov musing if the ac3 parser was disabled.
[23:56] <llogan> kierank: how much does it cost?
[23:56] <kierank> dunno, the sales guy hasn't told me yet and I don't think he will any more
[23:57] <llogan> heh
[23:57] <kierank> this is getting a bit boring now
[23:57] <kierank> the story is the same - low to mid range product written in eastern europe or india
[23:57] <kierank> and a small european/american sales team
[23:57] <llogan> let's start a business
[00:00] --- Wed Dec 10 2014