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

[burek]

[01:56] <Compn> whens that meeting again ?
[02:04] <llogan> Compn: probably 11 am your time. im guessing you're in central.
[02:19] <Compn> llogan : eastern
[02:19] <Compn> is that tomorrow ?
[03:05] <cone-856> ffmpeg.git 03James Almer 07master:79d9ed4a434e: lavu/adler32: Fix doxy group definition
[03:05] <cone-856> ffmpeg.git 03James Almer 07master:321906d3419b: lavu/crc: Fix doxy group definition
[03:05] <cone-856> ffmpeg.git 03James Almer 07master:c4f932f4d745: lavu/md5: Add doxy
[03:32] <llogan> Compn: yes
[03:33] <llogan> 16 UTC
[03:35] <michaelni> drv, any news about the amd fate box ?
[03:36] <drv> i have it running, just need to do the cron setup and register it
[03:36] <drv> i should get to it this weekend
[03:36] <michaelni> ohh, great, thx!
[03:37] <drv> should i invent new slot names? i guess 'duron' is not really accurate
[03:41] <michaelni> yes
[03:45] <xxthink> where is the meeting room?
[04:04] <llogan> xxthink: come back in 14 hours
[04:05] <Compn> so noon for me :)
[04:05] <llogan> better than my 8 am
[08:42] <xlinkz0> could I create a file with a variable GOP ?
[08:43] <xlinkz0> (h264)
[08:45] <xlinkz0> so would it work if I stream copied 100 frames with gop=50, then set CodecContext->gop to 10, write another 50 frames then set it back to 50?
[11:34] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:1ba196a10d1d: avutil/utils: check and warn about llrint() brokenness
[12:25] <divVerent> Hi, I have a libavfilter question... when I write a filter which may or may not output a frame for every given input
[12:25] <divVerent> imagine a "drop random frames" filter
[12:25] <divVerent> would it need to support request_frame too?
[12:25] <divVerent> or is filter_frame support sufficient for that
[12:26] <divVerent> I would GUESS that request_frame support is NOT needed, as vf_telecine does not do that and the telecine pattern 2:0 drops every second frame
[12:26] <divVerent> but am I right there?
[12:30] <nevcairiel> its not needed inded
[12:30] <nevcairiel> indeed
[12:30] <divVerent> when is it needed then?
[12:30] <divVerent> I see vf_fps does even some crazy fifo handling there
[12:31] <nevcairiel> if your filter generates potentially more frames than the source did
[12:31] <divVerent> ah, I see... but telecine does that
[12:31] <nevcairiel> at least thats my understanding
[12:32] <divVerent> when using the "4" pattern e.g. which duplicates every frame
[12:32] <nevcairiel> it may still be optional and just make stuff go smoother if its present
[12:57] <ubitux> divVerent: look at vf decimate
[12:57] <ubitux> mmh i have a request_frame because of the double input
[12:58] <ubitux> divVerent: iirc you just need to flag the output link with FF_LINK_FLAG_REQUEST_LOOP
[12:58] <ubitux> so request frame is called until the filter produce a frame
[13:17] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:6c4516d0413e: avcodec/vc1dec: Check source picture availability in vc1_mc_4mv_chroma4()
[14:08] <kriegerod> is debian package maintainer position still open? i have no experience of being official pkg maintainer, and i don't run deb-distros at home, but i am willing to try it
[14:14] <cehoyos> kriegerod: The position is definitely still open.
[14:14] <cehoyos> I fear that some experience with Debian packages is required (I don't know anything about such packages though).
[14:20] <divVerent> ubitux: ah, I see
[14:21] <kriegerod> i am ready to learn policies
[14:21] <divVerent> so this flag is for lazy filters, and request_frame only needs to be implemented if one can do better than the automatic loop
[14:41] <ubitux> kriegerod: see https://ffmpeg.org/trac/ffmpeg/ticket/1781
[14:44] <kriegerod> ubitux, thanks
[14:46] <kriegerod> but looks beastd is absent now
[14:48] <kriegerod> i'll send him email
[14:56] <ubitux> kriegerod: we might discuss this stuff in about an hour anyway
[14:58] <kriegerod> ubitux: you mean 16 UTC talk?
[14:59] <ubitux> yes
[14:59] <ubitux> i guess you came because of this?
[14:59] <kriegerod> ok, but it is not in a hour, but three hours
[14:59] <ubitux> ah mmh right
[15:00] <kriegerod> no, i got into irc just occasionly, to hang silently :)
[15:00] <kriegerod> and saw this issue in the channel topic
[15:01] <kriegerod> i even thought that talk is not touching me as i an very minor contributor :)
[15:08] <cehoyos> ubitux: What sets spp->qp in vf_spp.c ?
[15:09] <ubitux> qp option
[15:09] <ubitux> spp=qp=10
[15:11] <cehoyos> 0 means use the table from the decoder through av_frame_get_qp_table(), is that correct?
[15:12] <ubitux> if available, yes
[16:58] <saste> hi all
[16:58] <saste> one hour to go for the meeting
[16:59] <saste> i created the #ffmpeg-meeting channel, i invite people to join that channel if the want to participate
[17:22] <saste> http://pastie.org/8046101 <= regarding the meeting
[17:23] <saste> please read it and tell if you want to suggest something, i'll update the topic soon
[17:32] <saste> uhm too long
[17:38] <nevcairiel> 16 utc is in 20 minutes, right? :D
[17:39] <ubitux> yes
[17:41] <saste> ubitux, btw do you still volunteer as a socis mentor?
[17:41] <saste> the application deadline is in a week
[17:42] <saste> i could volunteer as admin, but i won't as mentor
[17:42] <ubitux> mmh i will likely be away soon
[17:42] <ubitux> what is the period?
[17:43] <saste> ubitux: http://sophia.estec.esa.int/socis2013/timeline
[17:44] <ubitux> mmh sounds bad
[17:44] <ubitux> i might not be able to, i'm sorry
[17:44] <saste> coding period is from august to october
[17:44] <ubitux> i might not be there in august
[17:45] <saste> allright, i'll post a mail, we will miss it if we don't have any available mentor
[17:45] <ubitux> sorry
[17:45] <saste> you don't have to be sorry
[17:56] <michaelni> "The log of the meeting should not be considered public" <--- sick
[18:01] <saste> please join the #ffmpeg-meeting channel if you want to participate to the meeting, it will start in a few minutes
[18:03] <michaelni> please explain why the secrecy and non public stuff
[18:03] <saste> michaelni, i already explained
[18:03] <michaelni> huh?
[18:03] <saste> people is more free to express their opinion if they know it won't be logged
[18:04] <saste> i'll prepare a public resume
[18:04] <saste> also i'm not enforcing any private means to keep it "secret"
[18:05] <michaelni> secrecy is the beginning of tyranny ...
[18:05] <saste> michaelni, talking of secrecy, what about privacy?
[18:05] <nevcairiel> anyone is welcome to join the meeting, i dont understand whats secret about it
[18:06] <saste> anyway i'm not personally against publishing the log if *all* the participants are ok with that at the end of it
[18:07] <ubitux> (so, reimar, nicolas, and others don't join?)
[18:07] <michaelni> if its a meeting about ffmpeg and no subject like server security or private personal stuff on the agenda i dont see why it cant be declared public to begin with
[18:08] <saste> michaelni, privacy, freedom of expression
[18:08] <ubitux> michaelni: what about infrastructure details?
[18:08] <saste> it's better if it won't be logged forever
[18:08] <ubitux> (again i'm neutral about it, but if we could start that would be nice)
[18:09] <michaelni> i dont know about infrastructure details, theres some work that needs to be done, a 4th root admin would be nice to have
[18:10] <michaelni> some of the fine details of the server like passwords sure shouldnt be pubic yes ;)
[18:10] <michaelni> but then i wouldnt type any of that in a private IRC channel either
[18:11] <ubitux> can we start the meeting, publicly and move to a "private mode" when sensible subjects are started?
[18:11] <michaelni> theres gpg for that
[18:11] <ubitux> this is starting to get a bit ridiculous
[18:11] <ubitux> also, it's a bit disappointing not to see people not from irc away :(
[18:11] <michaelni> yes and
[18:12] <michaelni> if its non public they cant even read the log
[18:13] <saste> michaelni, we'll start the discussion soon, you're free to join at anytime and discuss/flame on the public/non public thing, even if that's not the point of the meeting
[18:14] <michaelni> saste, iam happy to join if its public
[18:14] <saste> michaelni, it is public, but the log should not be published unless all participants agree
[18:16] <iive> well, if it is public, then I will join too.
[18:17] <saste> iive, please not nitpick on the definition of "public"
[18:17] <iive> what do you mean?
[18:18] <saste> iive, that it is not the time nor the place to discuss this, the meeting already started
[18:18] <saste> iive, join, but you are "morally" prevented to publish the log if someone disagrees
[18:19] <iive> sure
[18:21] <wm4> lukaszmluki: did you also work on mplayer stream_ftp maybe?
[18:22] <lukaszmluki> no
[18:22] <wm4> ok... it got improvements recently, and there are not many who'd play media directly from FTP, so I thought this might be related
[18:23] <lukaszmluki> hmm, player for mobile devices usually provides this functionality, but usually doesn;t work well
[18:24] <durandal_1707> so nobody waited for me to start secret meeting?
[18:25] <saste> durandal_1707, please join
[18:25] <durandal_1707> at #secret-meedlings?
[18:25] <saste> durandal_1707, #ffmpeg-meeting
[18:25] <Compn> durandal_1707 : its in the topic
[18:26] <durandal_1707> ah, it seems already ended....
[18:29] <Compn> not yet durandal_1707 :P
[18:45] <Compn> j-b : how did videolans crowdfunding campaign go ? (did it have one? i dont remember)
[18:48] <kierank> they raised money
[18:50] <Compn> thats good
[18:50] <Compn> what about developing side ?
[18:53] <kierank> the money went through me and I paid them in feb or so
[18:53] <kierank> after some tax issues
[18:53] <kierank> http://www.jbkempf.com/blog/post/2013/Follow-up-report-about-the-WinRT-port
[19:54] <wm4> is there a way avio inputs can report stream based metadata?
[19:54] <wm4> consider metadata embedded in shoutcast streams
[19:54] <nevcairiel> avio is too low-level for that, it just reads the bytes
[19:57] <wm4> nevcairiel: well it deals with protocols
[19:57] <wm4> like http
[19:58] <wm4> it already exports extra information like mime type, but no metadata as far as I can see
[19:59] <durandal_1707> you were actually looked into implemention of shoutcast metadata in lavf?
[20:00] <wm4> I think I want to do that
[20:00] <wm4> because MPlayer handles it
[20:01] <wm4> shoutcast can update the metadata mid-stream, so I guess it's complicated to export this information
[20:02] <nevcairiel> isnt the metadata also carried in the stream itself
[20:02] <wm4> yes
[20:03] <nevcairiel> seems easier then to extract it on a demuxing level instead of a protocol leve
[20:04] <durandal_1707> and how its storend in demuxing level?
[20:04] <nevcairiel> id3 tags, i believe
[20:04] <wm4> haha no
[20:05] <wm4> it's basically part of the protocol itself
[20:05] <wm4> http://www.smackfu.com/stuff/programming/shoutcast.html
[20:05] <nevcairiel> shoutcast is a http mp3 stream, not much more
[20:06] <wm4> the metadata is a different matter, though
[20:06] <wm4> basically, you have metadata packets every N bytes, or something
[20:06] <nevcairiel> ah, i see
[20:06] <wm4> and they are not id3
[20:07] <wm4> converting them to id3 as part of the reading process doesn't sound good either
[20:20] <nevcairiel> anyway, the protocol that reads shoutcast is jsut http, isn't it? and these metadata blocks would sitll reach the demuxer, i assume, so it should be handled there
[20:23] <wm4> nevcairiel: the metadata blocks are just messed into the stream (no proper header, maybe not even aligned on audio packets), so that'd be hard
[20:51] <kriegerod> wm4: why? demuxer is the object which reads and parses this "messed stream"
[20:52] <wm4> kriegerod: not sure if it can be done in this case, I suppose there is already some infrastructure for id3, but I'm not sure if it really covers this use case
[21:02] <ubitux> VP9 bitstream finalized mmh
[21:04] <wm4> Warning: Sorry, can not save your changes. This ticket has been modified by someone else since you started
[21:04] <wm4> oh trac...
[21:05] <wm4> can't post no matter what, have to open new tab and copy & paste the text
[21:11] <ubitux> wm4: you repeat yourself in that comment
[21:11] <wm4> oops
[21:11] <durandal_1707> ubitux: writing decoder?
[21:12] <ubitux> durandal_1707: nope
[21:12] <wm4> and in fact I deleted another part of the comment
[21:12] <ubitux> wm4: copy/paste is an old art hardly masterized
[21:12] <wm4> I blame konqueror
[21:14] <wm4> edited
[21:31] <ubitux> wm4: i like the idea of the all in one new function that would simplify apps
[21:31] <ubitux> but i think i'll leave that to saste 
[22:18] <durandal_1707> michaelni: what integer overflow for wavpack in fate?
[22:18] <Daemon404> o
[22:18] <Daemon404> let me re-run my ioc
[22:18] <Daemon404> http://fate.ffmpeg.org/history.cgi?slot=x86_64-centos-clang-ioc
[22:19] <michaelni> durandal_1707, http://fate.ffmpeg.org/report.cgi?time=20130615110958&slot=x86_64-freebsd8.2-clang2.8-ftrapv
[22:20] <durandal_1707> huh, but that one core dumped
[22:21] <michaelni> thats what ftrapv does when theres a integer overflow
[22:21] <michaelni> you have to run it locally under gdb (and probably without optimizations) to see what happens
[22:21] <durandal_1707> but why only that sample?
[22:22] <Daemon404> obviously it's related to cover art
[22:24] <durandal_1707> well overflow does happen, but with invalid bitstream
[22:25] <durandal_1707> and thus i don't see why checking for this, and fixing it...
[22:25] <Daemon404> i dont follow
[22:26] <Daemon404> why would an overflow be deemed OK if the input bitstream is not valid?
[22:26] <Daemon404> thats the entire point of e.g. fuzzing
[22:26] <Daemon404> it should be fixed
[22:27] <durandal_1707> well looks like there are bunch of other overflows possible in other places
[22:27] <Daemon404> unsurprising
[22:28] <durandal_1707> and casting everything to int64_t  will make slow decoding afaik
[22:28] <llogan> anyone know who registered ffmpegsvn on twitter?
[22:28] <Daemon404> llogan, someone who doesnt understand we use git
[22:28] <Daemon404> obviously
[22:28] <Daemon404> durandal_1707, thats true 
[22:28] <durandal_1707> Daemon404: that was from very old dark ages
[22:28] <Daemon404> http://fate.ffmpeg.org/report.cgi?time=20130615202801&slot=x86_64-centos-clang-ioc
[22:29] <Daemon404> new run of ioc
[22:29] <Daemon404> should give mroe info than "Core dumped"
[22:29] <Daemon404> or not
[22:29] <Daemon404> looks liek wavpack SIGIL'd
[22:29] <Daemon404> lol
[22:33] <durandal_1707> also could this overflow be fixed without casting?
[22:34] <nevcairiel> Daemon404: SIGIL? that seems unusual
[22:34] <Daemon404> it could be the ioc patches
[22:34] <Daemon404> when clang 3.3 comes out, it has ioc integrated
[22:34] <Daemon404> and i will switch to that
[22:36] <Daemon404> but i wonder what sort of sigil it could even be
[22:36] <Daemon404> i so rarely see them... certainly not on an i7
[22:59] <durandal_1707> nicolas added functions in af0d270aac86a0ac1eae8e, but they are never used
[23:01] <durandal_1707> correction: they are used
[23:31] <cone-159> ffmpeg.git 03Andrey Utkin 07master:194fde38349e: Document "cache" protocol
[23:32] <Compn> wm4 : so you want a high level api that lets you choose the format of the output. .. why not just use libffmpeg or some other ffmpeg lib wrapper
[23:34] <Compn> maybe i'm just trolling. it just seems like double work to create an api that ffmpeg does. duplication, unless we merge ffmpeg into a library and update ffmpeg binary to just be a frontend to the ffmpeg lib ?
[23:36] <saste> Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg | This channel is publically logged | FFmpeg 1.2 has been released | We need a volunteer Debian Package Maintainer.
[23:36] <saste> ops...
[23:42] <wm4> Compn: that was just an example... and external wrappers get outdated quickly because the ffmpeg API changes so often
[23:43] <Compn> good point
[23:48] <cone-159> ffmpeg.git 03Paul B Mahol 07master:8a79a009f9ca: lavu/utils: silence warnings about incompatible pointer types
[23:52] <durandal_1707> more and more tickets that ask questions
[23:52] <Compn> well, where would you go to find that info ?
[23:53] <Compn> mpeg specs ?
[23:53] <Compn> try reading those 1000 pages and find the answer
[23:53] <Compn> :P
[23:54] <Compn> durandal_1707 : it sounded like you didnt like how the meeting went. any ideas for next time to make it better ?
[00:00] --- Sun Jun 16 2013