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

[burek]

[02:46] <Daemon404> g 44
[08:48] <cone-588> ffmpeg.git 03Mickaël Raulet 07master:1912842045f2: hevc: remove disable_au option(cherry picked from commit e90b3f6753d645fec076e951a0597a5dc2d2fe31)
[08:48] <cone-588> ffmpeg.git 03Mickaël Raulet 07master:a8fafa89785b: hevc: cleaning disable field in deblocking filter(cherry picked from commit 7dd7a27ae850a51b3c9cd07046c422677398f6d5)
[08:48] <cone-588> ffmpeg.git 03Mickaël Raulet 07master:1c8de4dd949c: hevc: pretty print(cherry picked from commit 6332b3afe298b9e1060e8549aea3aa2771b43f5d)
[08:48] <cone-588> ffmpeg.git 03Mickaël Raulet 07master:c68faca68e21: hevc: fix transform_skip which is only valid for 4x4(cherry picked from commit 740e5a71e5121dbf3fabdc4fec97829c18ecc2d8)
[11:19] <durandal_1707> kierank: what 'magical' constants?
[11:19] <kierank> durandal_1707: in the olden days
[11:19] <kierank> before TEP
[11:19] <kierank> get_buffer used to be some magic numbers in ffmpeg.c
[12:44] <cptspiff> gpl violators: http://xbmc.org they use ffmpeg under gpl in signed ios binaries. https://github.com/xbmc/xbmc/pull/3437
[12:46] <durandal_1707> and why is that violation?
[12:46] <cptspiff> because you cannot modify it without resigning.
[12:47] <durandal_1707> modify what?
[12:47] <cptspiff> whatever i feel like modifying.
[12:47] <BBB> do you have a legal record showing that a judge agreed with you in US juridsdiction?
[12:47] <BBB> (i.e. precedent)
[12:47] <BBB> jury is fine also
[12:47] <cptspiff> no i don't. i only have my ethics and i left the project due to this. do what you want, i just wanted to inform.
[12:48] <BBB> that was quick
[12:48] <durandal_1707> you left FFmpeg?
[12:48] <Daemon404> BBB, well also i think apple bans GPL
[12:48] <Daemon404> which is not a legal issue
[12:48] <Daemon404> but a store issue
[12:48] <BBB> that's between them and apple, not us and them
[12:48] <Daemon404> yes
[12:48] <BBB> I agree it sucks :)
[12:48] <JEEB> was it GPLv3 that doesn't let you drm the binaries?
[12:48] <j-b> that is not true
[12:48] <j-b> It is between you and them
[12:48] <BBB> durandal_1707: I think he left xbmc
[12:49] <durandal_1707> anyway proper way to report something is via bug tracker
[12:49] <j-b> Apple considers itself like a 3rd party distributor
[12:49] <durandal_1707> but he laft us, so he left FFmpeg too
[12:49] <durandal_1707> *left this channel
[12:50] <j-b> GPL is not possible on iOS, and it is the developers who must complain
[12:50] <j-b> GPLv2 and GPLv3, for different reasons.
[12:51] <j-b> GPLv3 because of the Tivo clause, notably
[12:51] <j-b> GPLv2 because of the limitations of usage that Apple adds to it.
[12:51] <JEEB> yup
[12:52] <j-b> moreover, there are no reasons to not use LGPL version of FFmpeg
[12:52] <Daemon404> for decoding, anyway.
[12:52] <JEEB> yup
[12:53] <kierank> Daemon404: tell that to blue lucy media
[12:53] <kierank> :)
[12:53] <JEEB> or all those people who grabbed their ffmpeg config from ffdshow tryouts or LAV
[12:53] <JEEB> for whatever reason
[12:53] <Daemon404> kierank, no no their old player is deprecated!
[12:54] <kierank> Daemon404: it was funny when we were talking about their gpl violation and he walked through
[12:54] <kierank> I need someone to request a trial of blue lucy
[12:54] <kierank> to see if it still violates
[12:55] <kierank> I trolled them by requesting a trial and saying my interesting in the program was for "checking for gpl violation"
[12:55] <kierank> interest*
[12:55] <JEEB> lol
[12:55] <Daemon404> lul
[12:56] <kierank> naturally i didn't get access to the trial
[12:56] <durandal_1707> you need to donate big bucks
[12:58] <durandal_1707> is fmod() always available?
[13:48] <cone-373> ffmpeg.git 03Michael Niedermayer 07master:da30d0cec3eb: libavcodec/mpegaudio_tablegen: clip value before casting
[14:23] <Daemon404> man im smart
[14:23] <Daemon404> forgot to --amend before i send the v2
[15:26] <ubitux> BBB: did you see the emu_edge bug raised by ingo on ffmpeg-user?
[15:27] <durandal11707> http://ffmpeg.org/pipermail/ffmpeg-user/2013-October/018101.html
[15:29] <ubitux> last post give some little insight, carl replied on cvslog, dunno if you're registered
[15:29] <durandal11707> i'm not because i do not intend to receive merge spam
[15:30] <ubitux> it was for BBB obviously
[15:31] <durandal11707> but on cvs ml you receive all commits
[15:31] <ubitux> i like it personally
[15:32] <durandal11707> i don't
[16:01] <ubitux> http://voices.canonical.com/jussi.pakkanen/2012/09/25/the-code-documentation-fallacy/
[16:02] <ubitux> (old, i know)
[16:02] <ubitux> just came accross it, 'find it relevant to the project somehow
[16:03] <ubitux> (and yes i know i tend to add similar noise at times)
[16:43] <ubitux> seriously, the K&R cosmetics patch are getting more and more insane
[16:44] <ubitux> http://pastie.org/8421508  :')
[16:44] <ubitux> the 80-line break breaks almost the whole patch
[16:45] <ubitux> http://pastie.org/8421514  wtf is this non-sense split?
[16:46] <ubitux> also lol: http://pastie.org/8421515
[16:46] <Daemon404> looks like automated shit
[16:46] <ubitux> and how the hell can this be considered an improvement: http://pastie.org/8421517
[16:47] <ubitux> Daemon404: as always
[16:47] <Daemon404> also in case you missed
[16:47] <ubitux> "i'm applying the uncrustify, please review the output for me"
[16:47] <Daemon404> https://gist.github.com/dwbuiten/7101755
[16:47] <Daemon404> lots of segfaults in ffmpeg from unchecked mallocs
[16:47] <ubitux> yeah i saw you mentioning it
[16:48] <ubitux> that's pretty cool
[16:48] <ubitux> can you add it in tools/ or something with a simple Makefile?
[16:48] <Daemon404> it's extremely linux specific right now
[16:48] <Daemon404> GCC specific even
[16:48] <Daemon404> no idea if its at all portable
[16:48] <ubitux> that's why i'm suggesting tools/
[16:49] <Daemon404> right
[16:49] <Daemon404> i have a load of mem check patches to send later today too
[16:49] <Daemon404> ill do that after
[16:50] <ubitux> i can add a fate instance with that if you don't
[16:50] <ubitux> but if the file is tracked, that's simpler for me
[16:50] <Daemon404> not sure how useful hate instances are
[16:50] <Daemon404> a bunch will fail obviously
[16:50] <Daemon404> but we're only interested in some of the failures
[16:50] <Daemon404> (i.e. 139 exit codes)
[16:50] <ubitux> well if you add one i won't need to do it
[16:51] <Daemon404> i think it'd need some postprocessing after
[16:51] <Daemon404> like report generation
[16:51] <Daemon404> otherwise itll be lost in noise of normal failures (i.e. exit code 1)
[16:51] <ubitux> av_assert(0)
[16:51] <ubitux> gdb backtrace on the core
[16:51] <ubitux> too archaic i guess?
[16:52] <Daemon404> ill think about how to set up an automated page
[16:52] <Daemon404> probably just a script/cronjob on my home pc
[16:53] <ubitux> if you do, please make sure that code is available in case we need to setup another box
[16:53] <Daemon404> sure.
[16:55] <ubitux> doesn't such tool already exists btw?
[16:55] <Daemon404> probably
[16:55] <Daemon404> i googled a bit but i didnt see anything
[16:55] <Daemon404> not for posix_memalign anyway
[16:55] <Daemon404> plus i was bored.
[16:57] <nevcairiel> BBB: ubitux: i have a vp9 clip which produces a lot of "[vp9 @ 05982060] Invalid frame marker" messages and shows corruption, it seems to play OK in Chrome, interested?
[16:58] <ubitux> sure
[16:58] <ubitux> not sure i'll have a look at it soon though
[16:59] <nevcairiel> http://files.1f0.de/samples/Bad%20Meets%20Evil%20-%20Lighters%20ft.%20Bruno%20Mars-video_0.WEBM
[17:35] <ubitux> nevcairiel: works fine here
[17:35] <ubitux> how do you reproduce?
[17:36] <nevcairiel> i play the video :D
[17:36] <ubitux> ffplay?
[17:36] <ubitux> at what ts it happens?
[17:37] <ubitux> i have no problem playing with ffplay or decoding the file
[17:37] <nevcairiel> my code was 48 hours old, but i dont suppose it was fixed? guess i'll have to dig deeper first
[17:49] <ubitux> lol @ functionnal changes in K&R comits
[17:50] <Daemon404> where?
[17:50] <ubitux> at the end at least
[17:51] <nevcairiel> ubitux: i found the reason, avcodec_decode_video2 doesn't properly return the number of consumed bytes for vp9, so my code tries to call the decode function again with the remaining buffer and cause problems .. the ff* tools tend to simply ignore the return and assume the decoder decodes the full buffer :p
[17:52] <nevcairiel> if i also ignore the return, it works fine
[17:52] <Daemon404> sounds like a vp9 bug
[17:53] <nevcairiel> my guess is line 3496 in vp9.c should be "return avpkt->size;" instead
[17:53] <ubitux> nevcairiel: that should be fixed; but i though each decoder was supposed to decode a whole packet every time
[17:53] <ubitux> at least for video
[17:53] <Daemon404> thats untrue
[17:53] <Daemon404> you can have multiframe packets
[17:54] <ubitux> in video?
[17:54] <nevcairiel> yeah, some decoders support that
[17:54] <ubitux> it seems to me that we are always assuming 1 packet = 1 frame in all the code
[17:54] <nevcairiel> h264 can have a field in every packet, needing two for one frame
[17:54] <ubitux> i need such sample
[17:55] <Daemon404> basically ffmpeg ignores its own api
[17:55] <Daemon404> :P
[17:55] <nevcairiel> anyhow, i'll send a patch for this for review
[17:59] <nevcairiel> but thats what i get for implementing the API properly, headaches that ffplay cannot reproduce!
[17:59] <ubitux> yeah
[17:59] <ubitux> so now the question is
[18:00] <ubitux> do we really have even a single video decoder that relies on this behaviour?
[18:00] <nevcairiel> you can set a flag on some decoders that allow it to be fed chunked input
[18:01] <nevcairiel> ie. basically it does what the parsers do internally then
[18:01] <nevcairiel> i believe mpeg4 has that
[18:01] <nevcairiel> otherwise, i have no idea, since ffmpeg probably also ignores the return, someone would've noticed, no?
[18:07] <cone-487> ffmpeg.git 03Derek Buitenhuis 07master:692b93090443: lavfi/pthread: Avoid crashes/odd behavior caused by spurious wakeups
[18:08] <cone-487> ffmpeg.git 03Derek Buitenhuis 07master:55ae13e3deff: nut: Fix unchecked allocations
[18:14] <cone-487> ffmpeg.git 03Michael Niedermayer 07master:77ef53881867: avcodec/vcr1: Fix bitstream input size check
[18:14] <cone-487> ffmpeg.git 03Michael Niedermayer 07master:88c27193c7fd: avcodec/vcr1: print the actual size when its insufficient