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

[burek]

[00:12] <durandal_1707> Compn: make it real!
[00:14] <durandal_1707> ubitux: gonna join g+?
[00:15] <ubitux> no i don't have a g+ account
[00:15] <Compn> i've burned my g--gle accounts
[00:15] <Compn> got one email left
[00:15] <Compn> which i guess i should delete too
[00:16] <Compn> company tasted evil in china and never went back
[00:20] <wm4> ubitux: if you have a google account, you have a g+ account
[00:21] <ubitux> no
[00:21] <Compn> you can delete your g+ account 
[00:21] <ubitux> i enabled it once and disabled it a few days later
[00:21] <Compn> yea ^ same 
[00:24] <durandal_1707> ubitux: but you could post all new thing on ffmpeg community there
[00:24] <ubitux> i don't trust those services, and i don't need them
[00:28] <durandal_1707> new release comming when?
[00:29] <durandal_1707> and what's next filter of the week?
[00:29] <saste> durandal_1707, you have a pending filter iirc
[00:29] <durandal_1707> me? no waaay...
[00:33] <durandal_1707> still waiting for mergeplanes syntax
[01:16] <cone-159> ffmpeg.git 03James Almer 07master:b6249acae696: lavu/hash: Add support for SHA-2 512
[01:16] <cone-159> ffmpeg.git 03James Almer 07master:1bb005ce54d1: lavf/md5enc: Use AV_HASH_MAX_SIZE
[01:16] <cone-159> ffmpeg.git 03James Almer 07master:99b8cd0c81c4: lavu: Add RIPEMD hashing
[01:16] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:359af6a7c74a: Merge branch 'crypto' of https://github.com/jamrial/FFmpeg
[09:59] <cone-609> ffmpeg.git 03Hendrik Leppkes 07master:8962da9ec367: rawdec: allocate a buffer in the appropriate size in the copy case.
[13:03] <cone-609> ffmpeg.git 03James Almer 07master:4a0d603072a5: lavu/hash: Add support for RIPEMD
[13:03] <cone-609> ffmpeg.git 03James Almer 07master:3e17eec60730: lavu/adler32: Fix doxy group definition, take two
[15:09] <ubitux> https://www.shadertoy.com/view/ldf3DN
[15:10] <ubitux> michaelni: why is mandelbrot source so big? ;)
[15:10] <ubitux> (related: http://www.iquilezles.org/blog/?p=2217)
[15:11] <michaelni> ubitux, its so big because it has to run in realtime
[15:12] <cehoyos> michaelni: Is lbipostproc's deringing filter supposed to work with -fstack-protector-all ?
[15:13] <michaelni> ubitux, http://guru.multimedia.cx/wp-content/mand2.c
[15:13] <ubitux> michaelni: much better ;)
[15:13] <cehoyos> If configured with --extra-cflags=-fstack-protector-all, the following line crashes immediately: ffmpeg -f lavfi -i testsrc -vf pp=dr -f null - 
[15:13] <ubitux> reminds me of the x11 mandelbrot from gavare (ioccc winner a few years ago)
[15:14] <cehoyos> Should I open a ticket or is this expected behaviour?
[15:17] <michaelni> cehoyos, you have to look at the code where it crashes
[15:18] <cehoyos> This is SSE2-dering() in libpostproc/postproc_template.c
[15:19] <michaelni> does it also crash with pure C and where does it crash and why?
[15:22] <cehoyos> (It only crashes with -fstack-protector-all) Pure C also crashes, but runs in valgrind showing an incountable amount of different messages
[15:22] <cehoyos> MMX, MMX2, SSE all crash like SSE2
[15:22] <cehoyos> It crashes on the exit of the function which is - iiuc - what -fstack-protector does
[15:23] <ubitux> cehoyos: SSE use the same template as MMX
[15:23] <ubitux> iirc
[15:23] <ubitux> it's basically the same assembler
[15:25] <cehoyos> Correction: It does not crash with MMX-only, with C-only, it crashes in libswscale (will have to check again)
[15:28] <cehoyos> gdb reports the cash in __asm__ volatile() for MMX2 and SSE2 (there is no SSE version)
[15:32] <cehoyos> michaelni: Is the fact that it works with MMX but crashes with MMX2 and SSE2 already a sufficient indicator for a bug?
[15:35] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:3b8617429014: avcodec/jpeg2000dec: move bpno check to a earlier place
[15:36] <michaelni> cehoyos, full uncut otput from gdb missing
[15:41] <cehoyos> gdb shows the crash in line 1094 of postproc_template.c which is the line containing "asm volatile", the crash happens in the additional code that -fstack-protector adds
[15:42] <michaelni> cehoyos, closed, please reopen when you can provide full uncut gdb output
[15:52] <iive> gdb should provide the instruction and you can disassemble portion of it.
[15:52] <iive> i mean, disassemble portion of the code around the instruction.
[15:55] <cehoyos> iive: The crash does not happen within FFmpeg's code
[15:57] <cehoyos> I just don't know if the corrupt stack may be expected for some (optimization) reason
[15:58] <iive> stupid me... of course the stack protector identifies the corruption post-factum
[15:58] <michaelni> cehoyos, the code looks miscompiled
[16:00] <cehoyos> michaelni: I honestly don't know -fstack-protector does, but I would expect it to "miscompile" code by some standards.
[16:01] <iive>  michaelni do you mean the asm block?
[16:01] <iive> it won't be the first gcc to do that.
[16:02] <michaelni> iive it uses rsp as general purpose register
[16:02] <cehoyos> iive: This is with different gcc versions (but I will now test more versions)
[16:02] <iive> it uses the stack pointer as general register?
[16:02] <iive> wow
[16:09] <cehoyos> beastd: Kiregerod wants the Debian job, did he get in contact with you?
[16:09] <beastd> not yet
[16:10] <cehoyos> I just realized that the packager job was removed from the topic, was that on purpose?
[16:10] <beastd> i just saw the mails from yesterday on the ml
[16:12] <beastd> i have a huge backlog of mails because i didn't feel well very often this month...
[16:12] <michaelni> cehoyos, no, the packager job should stay until apt-get install ffmpeg works
[16:12] <saste> Compn, what's your name? (I need it for my meeting report)
[16:13] <beastd> mail from andrey on ffmpeg devel sounds good and it is appreciated
[16:13] <beastd> he is not here right now, isn't he?
[16:14] <saste> same for wm4, does someone remember his r-l name?
[16:18] <cehoyos> So he did introduce himself?
[17:21] <saste> http://pastie.org/private/bsbgstmx3rswjtbw0qbaeg
[17:21] <saste> ^^ please comment on this if you assisted the meeting yesterday
[17:23] <saste> assisted->attended
[17:26] <ubitux> saste: missing wtv requests (https://ffmpeg.org/trac/ffmpeg/report/11)
[17:27] <ubitux> saste: "HLS/RTMP issues" ’ "playlist design (see HLS option passing)" and move "RTMP" into ffserver entry
[17:30] <ubitux> saste: you might want to mention G+ account in the last p, so Paul will be happy
[17:30] <ubitux> no other comment from me
[17:38] <beastd> saste: "the team actually composed by" <--  s/actually/currently/ 
[17:49] <BBB> saste: I think the end of point 1 is not true
[17:50] <BBB> saste: specifically, the suing of license violators does not require a legal entity of any sort - this can just be done on personal title
[17:50] <BBB> saste: (FYI)
[18:05] <saste> BBB: I mentioned that "The prosecution can be led by any copyright holder."
[18:05] <saste> but I reworded and moved the note about the legal entity
[18:05] <saste> ubitux: ffserver != RTMP issues
[18:05] <saste> also wtv is mentioned just once in the log
[18:06] <ubitux> saste: when i mentioned rtmp yesterday, it was about having the support in ffserver
[18:06] <ubitux> iirc ffserver only has http and rtsp outputs
[18:13] <ubitux> is it ok to use AVFMTCTX_NOHEADER and still set one stream in the header parsing callback?
[18:13] <ubitux> (assuming some other streams could be added later)
[18:14] <ubitux> or do i need create that one stream in the first read packet call?
[18:26] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:78d2d1e0270c: postprocess_template: put rsp on the clobber list to prevent gcc from using it in "q"
[18:27] <michaelni> ubitux, is ok
[18:28] <ubitux> ok, cool
[18:28] <ubitux> thx
[18:28] <cehoyos> Thank you Michael
[18:43] <Compn> saste : i identify with 'compn' now. trying to keep my real name off the internet as much as possible ...
[18:47] <Compn> which is annoying , since libav's git uses my real name
[18:47] <saste> Compn, that's problematic in case of license tracking
[18:47] <saste> if you can't be tracked on the log, basically there is no way to contact you
[18:47] <saste> especially after many years
[18:47] <Daemon404> it makes j-b sad
[18:47] <Compn> but my real name isnt on the internet to find
[18:48] <Compn> so that wont help anyways
[18:48] <Compn> i've even started killing off 'compn' ...
[18:48] <Daemon404> did you a kill a guy or something7
[18:48] <Daemon404> s/7//
[18:48] <Daemon404> i mean.. you know...
[18:48] <Daemon404> detroit.
[18:48] <Compn> saste : well i dont program , so looking for me license info isnt important either
[18:49] <saste> Compn, every single line may count
[18:49] <Compn> i give full licenseship of all of my commits to michael / public domain then
[18:49] <saste> basically with our system we have the guarantee that changing license is impossible
[18:50] <cehoyos> That is mostly correct.
[18:50] <Compn> j-b relicensed parts of videolan
[18:50] <Compn> which is equally difficult task...
[18:50] <Compn> with equal number of contributors
[18:50] <j-b> Daemon404: indeed. Make me sad
[18:50] <Compn> it can be done!
[18:51] <Compn> Daemon404 : no. didnt kill anyone. just not into being a public person on the internet
[18:51] <j-b> Daemon404: but I accept now anonymous contributions, with videolan at videolan email
[18:51] <Daemon404> j-b, via CLA?
[18:51] <Compn> ffmpeg has anonymous contributors as well
[18:51] <BBB> elvis!
[18:51] <Daemon404> wait, a cla is useless in france
[18:51] <Daemon404> i think
[18:51] <Daemon404> nevermind
[18:52] <saste> Compn, removing your real-life name from the report
[18:52] <Compn> thx
[18:53] <j-b> Daemon404: indeed :)
[18:54] <j-b> Daemon404: using the videolan at videolan email automatically means you give away your patrimonial rights
[18:54] <Daemon404> right
[18:54] <Compn> is that in a eula somewhere ?
[18:54] <BBB> has anyone started a vp9 decoder?
[18:54] <Daemon404> BBB, i dont think so
[18:54] <Compn> are there vp9 samples ?
[18:55] <Daemon404> the people who did vp8 are all idle
[18:55] <Compn> BBB : ask kostya
[18:55] <Daemon404> i did see the vp9 bitstream was finalized
[18:55] <BBB> Daemon404: I'm not idle
[18:55] <Compn> q kshishkov
[18:55] <Daemon404> BBB, well, you're busy with libvpx
[18:55] <BBB> I was
[18:55] <BBB> it's done now
[18:56] <Compn> i guess libvpx couldnt just use ffmpeg internals, due to license
[18:56] <Daemon404> it wouldnt even be easy to
[18:56] <BBB> anyone wanna learn some serious video coding and make a vp9 decoder? I can try to provide serious assistane
[18:56] <Compn> to rip out accelerated funcs ?
[18:56] <BBB> "using ffmpeg internals" is a lot harder than it sounds anyway
[18:56] <Daemon404> lol
[18:56] <Daemon404> yes
[18:57] <Compn> BBB : what purpose to get internal vp9? just speed boost and instantly get more vp9 tools ?
[18:57] <BBB> look, you want a fast decoder that is using ffmpeg internals, then you probably want it to live in ffmpeg
[18:57] <Daemon404> two independant impls are always a good thing
[18:57] <BBB> Compn: I think having multiple decoders helps to establish a spec
[18:57] <Daemon404> always.
[18:57] <BBB> yeah
[18:57] <Compn> ah
[18:57] <BBB> ideally more than two
[18:57] <Compn> fair enough 
[18:57] <BBB> libvpx, ffvp9, hardware impls, someone will probably write one in javascript
[18:57] <BBB> etc.
[18:58] <Daemon404> nobody writes that in js
[18:58] <Daemon404> they just compile to js
[18:58] <Daemon404> and say they wrote it
[18:58] <BBB> true
[18:58] <BBB> anyway
[18:58] <BBB> anyone want to learn serious video coding?
[18:58] <Compn> BBB : if you want to make a news entry on ffmpeg.org about wanting someone to work on vp9 , i could commit such entry.
[18:58] <BBB> nah
[18:58] <Daemon404> BBB, you should propose it as a SOCIS project perhaps
[18:58] <BBB> I don't like news entries, I'm looking for people idling here who are looking to get started but don't know where to go
[18:59] <BBB> socis (or gsoc) is too short
[18:59] <BBB> or I just do it myself
[18:59] <Daemon404> right...
[18:59] <BBB> but then nobody learns anything
[18:59] <BBB> the nice thing is to be able to teach something new to someone, so we expand knowledge and code coverage
[18:59] <Daemon404> i would volunteer if it were a different time.. but im uprooting myself and moving to england within the next month
[18:59] <Compn> yes thats a good idea , teaching new codec devs :)
[18:59] <BBB> exactly
[18:59] <Compn> Daemon404 : have fun in england
[18:59] <Daemon404> the english dont have fun
[18:59] <Daemon404> they have rain
[19:00] <BBB> english can code all day long
[19:00] <BBB> as opposed to ny'ers, who have fun stuff to do in their life
[19:00] <Daemon404> i just got back from NYC
[19:00] <BBB> oh rly - I was there just now also
[19:00] <BBB> flew back yesterday night
[19:00] <Daemon404> lulz
[19:00] <Daemon404> i flew backthe day before
[19:00] <Daemon404> after 2 weeks
[19:01] <BBB> awh, should've met up
[19:01] <BBB> ohwell
[19:01] <Daemon404> my office is even right by google
[19:01] <Daemon404> :P
[19:01] <BBB> vimeo?
[19:01] <Daemon404> yea
[19:01] <BBB> oh cool
[19:01] <BBB> yeah I was there wed, should've asked around
[19:01] <BBB> sorry
[19:01] <Daemon404> np
[19:01] <Compn> is google going to buy vimeo ?
[19:02] <Daemon404> that wouldnt even make sense
[19:02] <Daemon404> also vimeo is already owned b a Big Corp
[19:02] <Daemon404> by*
[19:02] <Compn> they've bought a ton of techs already
[19:02] <Compn> oh ok
[19:02] <Compn> s/techs/startups
[19:02] <Daemon404> instead i just get google 'engineering managers' trying to ocnvince me to move to california
[19:02] <BBB> Daemon404: are you in the same building?
[19:03] <Daemon404> as google? no
[19:03] Action: BBB maps
[19:03] <Daemon404> http://en.wikipedia.org/wiki/IAC_Building
[19:04] <ubitux> a few months ago i would have say yes for the vp9 decoder :p
[19:04] <ubitux> but now it's a bit late, i won't have time to work on this properly
[19:04] <BBB> ah 11th ave
[19:04] <BBB> ok
[19:05] <BBB> ubitux: is that fixable busy?
[19:05] <ubitux> not really
[19:06] <BBB> job? or life?
[19:06] <ubitux> job
[19:06] <ubitux> (and life soon)
[19:07] <Daemon404>  am unbusy by mid-aug, but thats a ways away (and i lack some serious understanding of much theory related to lossy video coding)
[19:07] <BBB> you don't need theory
[19:07] <BBB> you're not going to implement and design vp10
[19:07] <ubitux> how much time will be necessary for a decoder?
[19:07] <BBB> you just need to be able to code
[19:08] <BBB> time... I'd say about a month fulltime for an experienced developer, maybe a little more since you might have a minor initial learning curve
[19:08] <Compn> BBB : how long did it take vp8 / libvpx completition ?
[19:08] <ubitux> i can find ~15 days in august
[19:08] <ubitux> but that's all
[19:08] <BBB> I might be able to do this in august...
[19:08] <BBB> I took the whole month off ;)
[19:08] <ubitux> haha :)
[19:09] <saste> BBB: i might have time for that as well in august
[19:09] <BBB> Daemon404: mid-aug work for you?
[19:09] <BBB> good, we have people. ok, let's do aug then
[19:09] <Daemon404> it should... i am settled by aug 5th
[19:09] <Daemon404> in englad
[19:09] <Daemon404> england even
[19:09] <BBB> ubitux: you should know thierry's thing is still open, if the job thing is a discussable thing
[19:09] Action: Daemon404 should use this as an excuse to finally read The H264 Book to prepare himself
[19:09] <BBB> lmk
[19:10] <BBB> just read the vp8 source code. vp9 isn't that different
[19:10] <JEEB> Daemon404, haha -- I'm glad I'm not the only one who's only halfway through that one
[19:10] <ubitux> BBB: yes but i found a job :)
[19:10] <ubitux> btw, speaking of vp*, anyone to look at the vp8 race?
[19:10] <Daemon404> JEEB, the book is OK but still meh
[19:10] <ubitux> it fails very often
[19:10] <Daemon404> like every DSP book ever
[19:10] <Daemon404> it is super vague on some stuff
[19:11] <Daemon404> ... which i usually ask prunedtree to fill in for me
[19:11] <Daemon404> cue wall of text.
[19:11] <BBB> ubitux: send me an email and I'll queue it up for mondya
[19:11] <ubitux> ok :)
[19:11] <BBB> ubitux: details of what commandline to reproduce, what file/test, how many threads, and link to the fate log
[19:11] <BBB> I've fixed a couple before, shouldn't be impossible to fix this also
[19:12] <saste> http://pastie.org/private/2kqot60vvveluudz14pc9g
[19:12] <BBB> does it always fail in the same way?
[19:12] <saste> ^^ new version of the report
[19:12] <saste> please comment, i will post it in a few hours
[19:12] <Daemon404> "- mpegts/H.264 muxing/timestamp issues"
[19:12] <Daemon404> i feel like this isnt even fixable with the way lavf is
[19:13] <Daemon404> currently
[19:13] <ubitux> BBB: i see two failures in the history, on 2 different tests
[19:13] <ubitux> BBB: http://fate.ffmpeg.org/report.cgi?time=20130615103557&slot=x86_64-archlinux-gcc-threads-2 http://fate.ffmpeg.org/report.cgi?time=20130605102318&slot=x86_64-archlinux-gcc-threads-2
[19:13] <Compn> saste : btw good resume on the meeting
[19:14] <Daemon404> twitter eh
[19:14] <Daemon404> wouldnt it just be a daily stream of "API X is not deprecated / broke"
[19:14] Action: Daemon404 runs
[19:14] <Daemon404> s/not/now/
[19:15] <ubitux> Daemon404: "long term projects" :)
[19:18] <BBB> ubitux: ok, so same failure (frame 29 md5 03.. -> 8e)
[19:18] <BBB> on test 10
[19:18] <BBB> email me that so I don't forget
[19:18] <BBB> I'll look monday
[19:18] <BBB> that sounds relatively easy
[19:18] <ubitux> yes i'll do that in a moment
[19:19] <BBB> ty
[19:19] Action: BBB goes off
[19:19] <BBB> bbl
[19:39] <saste> cehoyos, please mention the git hash when you close a ticket
[19:39] <saste> it will save some pain in the future
[19:40] <ubitux> +1
[20:58] <cone-609> ffmpeg.git 03Paul B Mahol 07master:9ea7ff795519: tta: read ape tags last
[20:58] <cone-609> ffmpeg.git 03Paul B Mahol 07master:e997afdfc61e: lavf: show APIC for tta files too
[22:46] <cone-609> ffmpeg.git 03Luca Barbato 07master:5d21ca45591b: h264_mp4toannexb_bsf: K&R formatting cosmetics
[22:46] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:46a5003a4a69: Merge commit '5d21ca45591bb1c1d2265f8ed972d18c563f145e'
[22:48] Action: durandal_1707 runs uncrustify on whole tree
[22:49] <ubitux> :)
[22:49] <ubitux> make sure you break stuff, and don't make code looks better
[22:49] <durandal_1707> but uncrustify should not break code...
[22:49] Action: ubitux #define durandal_1707 
[22:51] <durandal_1707> #define ubitux panic("uncrustify me")
[22:51] <ubitux> :)
[22:59] <cone-609> ffmpeg.git 03Luca Barbato 07master:8d929afd2560: h264_mp4toannexb_bsf: factor out extradata parsing
[22:59] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:0a5d22a195b2: Merge commit '8d929afd256069aa881f2bf58ef9f0ffce2d6b7e'
[23:11] <cone-609> ffmpeg.git 03Luca Barbato 07master:9e80eda26d06: h264_mp4toannexb_bsf: return a padded buffer
[23:11] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:9f91e7deecc1: Merge commit '9e80eda26d06c7c48dbec5dfe643c857c62c0ee7'
[23:24] <cone-609> ffmpeg.git 03Luca Barbato 07master:f776899a17dc: bitstream: K&R formatting cosmetics
[23:24] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:9265bae3567c: Merge commit 'f776899a17dce32ad7fb9231d98f15558f37cc3f'
[23:35] <cone-609> ffmpeg.git 03Luca Barbato 07master:f80b60ad5994: bitstream: forward error values and drop few abort()
[23:35] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:301522f521f0: Merge commit 'f80b60ad59945dae32bb26a4e239ed94b0e92fa3'
[23:43] <cone-609> ffmpeg.git 03Luca Barbato 07master:afc8685395e7: avf: split off format register and lookup function
[23:43] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:4a522eff0065: Merge commit 'afc8685395e775fe0f2a1698b683aea4afd124af'
[23:50] <cone-609> ffmpeg.git 03Luca Barbato 07master:ec7c51c7868d: avf: move ff_http_match_no_proxy to network
[23:51] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:84f77f84234e: Merge commit 'ec7c51c7868d3ccc66b5cc38bf126258b94f086c'
[23:57] <cone-609> ffmpeg.git 03Luca Barbato 07master:508998f7d5cc: avf: move riff tags accessors where they belong
[23:57] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:bbdef6185020: Merge commit '508998f7d5cc61c7ac7b049813b47adc24c6e282'
[00:00] --- Mon Jun 17 2013