[00:03] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:cb52d6da0a9c: avcodec/bink: fix seeking to frame 0 [00:06] <llogan> version.sh gives a weird revision number on a shallow repo that got "git pull"-ed [00:06] <llogan> N-57649-gcc0e47b (normal) vs N-38493-gcc0e47b [00:54] <llogan> ooops..forgot to set as "wish" [01:01] <BBB> ubitux: --cpu-used=0 deals correctly with it yes [01:01] <BBB> ubitux: other values I don't know [01:02] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/1.2:fd8af7510991: avcodec/bink: fix seeking to frame 0 [01:02] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/2.0:beb28bc55dc7: avcodec/bink: fix seeking to frame 0 [01:02] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/2.1:1cd5797f8ec8: avcodec/bink: fix seeking to frame 0 [01:52] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:b73900b8a6c0: avformat/http: fix cookies [01:55] <cone-863> ffmpeg.git 03Michael Niedermayer 07release/2.1:d8be5bda1b96: avformat/http: fix cookies [02:33] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:2b1056e4e27b: avformat/thp: fix variable types to avoid overflows [02:33] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:6c4b87d3d6ae: avformat/thp: force moving forward [06:53] <Persanker> Hi [06:53] <Persanker> Is there anybody? [06:54] <Persanker> I have a question of using a function. [06:55] <Persanker> Can anyone help me? [07:27] <Persanker> hi [10:13] <cone-709> ffmpeg.git 03Mickaël Raulet 07master:7c8b65f688ea: hevc: add partial support for interlaced(cherry picked from commit 44b592ae6d323445c076ef3ec966ebf9daa8bccf) [10:14] <nevcairiel> nooo, not interlaceeeed [10:15] <Paranoialmaniac> interlaced should die [10:18] <Paranoialmaniac> this commit is only affected as sei? [10:18] <nevcairiel> afaik, hevc doesnt have special interlaced coding, only info signaling [10:19] <ubitux> haha [10:19] <Paranoialmaniac> hevc interlaced is implemented as a pair of top and bottom field coded pictures like avc [10:19] <Paranoialmaniac> no mbaff. but there is paff [10:23] <Paranoialmaniac> i like the idea which signals interlaced only but i dislike paff coding. so i dislike hevc :P [10:24] <mraulet> nevcairiel, yes [10:24] <mraulet> it is not yet finished the implementation I did [10:25] <mraulet> it is parsing but not deinterlacing yet [10:25] <Paranoialmaniac> deinterlacing?? [10:25] <mraulet> when I try abc with field only it got a deinterlaced yuv [10:26] <Paranoialmaniac> deinterlacing is a task of post processor. not a decoder task [10:26] <mraulet> in hevc I am outputting 2 fields [10:26] <mraulet> true [10:26] <mraulet> but I am not able to activate it yet [10:27] <Paranoialmaniac> well, libavcodec h264 decoder always waits for completion of frame even if field coded [10:29] <Paranoialmaniac> :O i didn't notice that my hevc parser patch is already in [10:30] <mraulet> it is yes [10:30] <mraulet> I haven't checked if you did further modifications [10:31] <mraulet> was busy with standardisation [10:35] <ubitux> http://git.libav.org/?p=libav.git;a=commitdiff;h=293fe6da01b6cb2f85c6551553e... ’ http://lists.libav.org/pipermail/libav-devel/2013-October/052569.html ’ http://lists.libav.org/pipermail/libav-devel/2013-October/052591.html [10:35] <ubitux> it never ends :') [10:36] <ubitux> they can't even make up their mind with the style [10:36] <nevcairiel> haha the latest patch now undoes vertical alignment added in the earlier commit, so funny [10:36] <ubitux> yeah :D [10:37] <nevcairiel> wonder if i should post that on the ML :P [10:37] <ubitux> nevcairiel: should i? [10:38] <nevcairiel> sounds like a good opportunity to troll their re-styling :p [10:38] <durandal_1707> ubitux: we should make documentary [10:41] <ubitux> i'm not sure 3 people are enough yet for cosmetics [10:41] <ubitux> they need a 4th one [10:43] <saste> K&R is hard [10:43] <saste> it takes many attempts [10:43] <nevcairiel> the worst part is the obsession with 80 characters [10:44] <nevcairiel> take http://lists.libav.org/pipermail/libav-devel/2013-October/052569.html for example [10:44] <nevcairiel> the last two hunks dont make anything better [10:44] <nevcairiel> worse even, imho [10:45] <ubitux> consider yourself lucky the script (or luca?) didn't break after the first coma too [10:45] <ubitux> like it often happens, as i pointed out last time [10:45] <durandal_1707> K&R is final state of mind [10:52] <mateo`> i wonder if they plan to add a git hook to call indent ... [10:53] <ubitux> i'm pretty that's the final utopy [10:53] <ubitux> when everything is "consistent" [10:53] <ubitux> but given they can't even make their mind on the style on a single trivial files [10:53] <ubitux> i doubt it will happen soon [10:53] <ubitux> they will just fuck up the blame/history [10:53] <ubitux> and readability sometimes [10:54] <ubitux> (and introduces functional changes and bugs at times) [10:57] <durandal_1707> but michaelni still like to merge such changes [10:58] <nevcairiel> if you dont, merging actual functional changes later is a pain [11:00] <durandal_1707> finding later changes needs pain killers [11:21] <cone-709> ffmpeg.git 03Michael Niedermayer 07master:fa6fa2162b73: avcodec/cabac: support UNCHECKED_BITSTREAM_READER = 0 [11:26] <ubitux> wm4: "eventually, probably" ;) [11:27] <ubitux> wm4: basically, a probable "wish" afaiu, with nothing really planed [11:28] <wm4> well I just found a bug in my own code because of this [11:28] <wm4> and I'd consider myself an experienced API user [11:28] <wm4> so I'll use my failure as proof that the API "fucking sucks" [11:28] <nevcairiel> better then face your own faults, i'm sure [11:28] <nevcairiel> :P [11:29] <av500> wm4: which one? [11:29] <wm4> providing a single, supported way would fix the API [11:29] <wm4> av500: avcodec_alloc_frame vs. av_frame_alloc, also refcounting [11:29] <BBB> lol @ ununchecked cabac [11:29] <BBB> didn't I implement that years ago and doesn't that include all assembly etc.? [11:29] <av500> wm4: ah [12:25] <ubitux> wm4: maybe someone should write a paper about moving from the old to the new api [12:25] <ubitux> :p [12:26] <wm4> how about not giving a fuck [12:26] <av500> i'd rather we break the new API [12:26] <wm4> it seems every API user just has to go through the pain [12:26] <wm4> like a ritual [12:27] <wm4> like the klingon initialization rite [12:27] <wm4> just that it happens every 6 monthd [12:27] <wm4> *months [12:27] <wm4> to confirm that he is a worthy API users [12:28] <av500> its the API "tax" [12:28] <ubitux> wm4: i'm still wondering what your point is, or what you want :D [12:29] <wm4> ubitux: op confusing differences between refcounted and "old" API... which is possible to accomplish [12:29] <wm4> at least as soon as the deprecated get_buffer is removed [12:30] <ubitux> op=me? [12:30] <ubitux> i think everyone is confused about the old2new api anyway [12:30] <wm4> s/op/no/ (how did this happen)= [12:30] <ubitux> ah [12:52] <durandal_1707> so instead of fixing/improving example we troll about api [12:53] <wm4> sorry I don't think it's reasonable to have both avcodec_free_frame and av_frame_free and have them do completely different things [12:54] <wm4> perhaps not _really_ the problem of the example [12:55] <durandal_1707> wm4: yes i find it confusing too [12:55] <wm4> but why make users (possibly) use them [12:56] <durandal_1707> and have 2 different paths is pain [12:57] <saste> someone has to explain what i gain from saving users pain (in change of my own pain) [12:57] <saste> since i get nothing from users anyway [12:58] <saste> ah i forgot, i do it for the public good [12:58] <durandal_1707> you are doing something wrong.... [12:59] <wm4> saste: you can spare yourself hour long discussions on IRC about bad APIs [13:34] <ubitux> wm4: so, can i use new api without ref counting? [13:35] <wm4> not sure... [13:35] <nevcairiel> anton claims you can, i still have my doubts [13:35] <ubitux> (aka without the need to set the option or unref the frame after decode) [13:35] <ubitux> ok i'll try then [13:35] <wm4> you still have to unref the frame before decode though [13:35] <wm4> or it'll leak [13:35] <wm4> not sure why this has to be this way, but whatever [13:35] <ubitux> before? [13:35] <ubitux> dafuck [13:36] <wm4> yes decode will just memset the AVFrame, essentially [13:36] <nevcairiel> if refcounting is off, you should only need to free the frame once when you shutdown [13:36] <ubitux> ok let me try then [13:36] <nevcairiel> it stores the buffers internally to free them on the next call, iirc [13:36] <wm4> so before decode you still need: if(refcounting_enabled)av_frame_unref(frame); [13:37] <ubitux> gonna improve the example to make multiple new api modes [13:37] <ubitux> yay, gonna love it [13:37] <nevcairiel> well with refcounting you need to free it between decode calls, indeed [13:37] <nevcairiel> thats really the only big difference [13:37] <wm4> hm maybe av_frame_unref is ok even if refcounting is disabled, but that's questionable [13:38] <nevcairiel> should be OK, but should be a void operation [13:38] <nevcairiel> short of clearing all the other fields [13:38] <nevcairiel> if antons theory is right, anyway [13:38] Action: nevcairiel is not convinced yet [13:39] <wm4> anyway, my point is: would decode unref the frame automatically, you wouldn't have to care about this [13:39] <nevcairiel> you mean even with refcounting? [13:39] <wm4> yes [13:40] <wm4> and then, when get_buffer is removed, refcounting could be enabled by default [13:40] <nevcairiel> some users of the old api allocated a new frame for evey decode call, which would then still leak [13:40] <nevcairiel> so it would be inconsistent still [13:40] <wm4> then user wouldn't have to care about refcounting, and could just use the av_frame_ref functions when he needs it [13:40] <wm4> hm [13:43] <cone-709> ffmpeg.git 03Diego Biurrun 07master:c7f25d4c7f65: build: Ensure that strip commands are run silently [13:43] <cone-709> ffmpeg.git 03Michael Niedermayer 07master:532ca12300f1: Merge remote-tracking branch 'qatar/master' [13:46] <ubitux> it seems to work [13:46] <ubitux> mmh well [13:47] <ubitux> i was trying fate-samples/lossless-audio/luckynight-partial.shn but it doesnt decode well with the example [13:49] <ubitux> maybe that's just the end though [13:55] <ubitux> wm4, nevcairiel, http://pastie.org/pastes/8445428/text [13:55] <ubitux> with that patch: http://b.pkh.me/0001-doc-examples-demuxing-show-how-to-use-the-reference-.pa... [13:57] <ubitux> so, it seems ok [13:57] <wm4> what's that lock manager bit? [13:57] <ubitux> no idea [13:58] <wm4> also in the default lock manager code it's strange that create doesn't allocate, while destroy does allocate [13:58] <wm4> oh well [13:59] <nevcairiel> the default lock manager code was rather weird [13:59] <nevcairiel> with its volatile variable [13:59] <nevcairiel> not sure why thats there [14:05] <ubitux> so anyway [14:05] <ubitux> who's gonna fix the filtering_{audio,video}.c examples now? :) [14:07] <wm4> are they broken? [14:07] <durandal_1707> something broke? [14:08] <wm4> they look ok on a quick look [14:15] <ubitux> wm4: they are broken [14:15] <ubitux> they crash out of the box [14:15] <ubitux> or leak, or both, can't remember [14:21] <ubitux> also, those examples don't handle multiple decode per packet [14:23] <wm4> that's needed for audio only [14:36] <cone-709> ffmpeg.git 03Carl Eugen Hoyos 07master:e4b0a77021a2: libavfilter/decimate: Add pts of first frame to all frames. [14:36] <cone-709> ffmpeg.git 03Michael Niedermayer 07master:045214e3d981: Merge remote-tracking branch 'cehoyos/master' [14:36] <durandal_1707> f&*() [14:37] <cone-709> ffmpeg.git 03Paul B Mahol 07master:49287bbfd322: doc/filters: add few more examples for blend filter [14:38] Action: durandal_1707 #ffmpeg You're not a channel operator [17:19] <wm4> ubitux: do you know/care about dvdsubdec? I have a file here where lavc returns duration=0, while the duration is correct with mplayer's dvd sub decoder [17:20] <ubitux> i did some changes to it recently but i wouldn't say i know about it [17:20] <ubitux> but yeah feel free to share [17:21] <wm4> sample: http://www1.datafilehost.com/d/9b99a2 (first subtitle event is affected, you can see it appear for 1 frame in ffplay) [17:24] <ubitux> Invalid file ID. [17:25] <wm4> try this: http://www1.datafilehost.com/d/9b99a2bf [17:25] <wm4> right, I missed two characters [17:26] <wm4> looking further into thus, mplayer's spudec.c has an additional mysterious chunk of code that does alternative reading of end timestamp, which appears to be missing from lavc [17:26] <ubitux> no idx? [17:26] <ubitux> erm yeah sure no idx. [17:26] <wm4> it's a normal mpeg stream [17:27] <wm4> from a DVD [17:28] <wm4> av_dlog(NULL, "unrecognised subpicture command 0x%x\n", cmd); <- should perhaps not be a dlog [17:28] <ubitux> agree [17:28] <ubitux> i won't have time to look at it soon though [17:29] <ubitux> i'll probably open a ticket, unless you don't feel lazy [17:29] <wm4> I'm trying to debug it, if I give up and have no patch, I'll open a ticket [17:46] <wm4> hm actually, the mplayer sub decoder doesn't determine a duration either [17:46] <wm4> but at least you know that the duration is unknown [17:56] <wm4> ubitux: yeah, never mind, at most it's a ffplay bug and a shortcoming of the subtitle API [17:56] <ubitux> yeah ffplay doesn't support well the bitmap subs [17:56] <ubitux> :P [17:57] <wm4> actually [17:57] <wm4> the duration of these subtitle packets seems to be set to 0 [17:57] <wm4> hm [17:58] <wm4> "Duration of this packet in AVStream->time_base units, 0 if unknown." [17:58] <wm4> so... what if the duration is _actually_ 0? [17:59] <wm4> and yes there are subtitles that use duration==0 if the sub shouldn't be shown at all [18:19] <durandal_1707> safari can play vp8? [18:21] <{V}> durandal_1707, maybe this is helpful: http://caniuse.com/webm [18:24] <durandal_1707> i have same strange issues with h264 and seeking [18:37] <wm4> why does vf_copy exist? [18:42] <beastd> "Add copy filter, useful for testing the avfilter_draw_slice() copy code." [18:45] <wm4> lol [18:45] <wm4> draw_slice is gone [18:46] <beastd> wm4: that seems what was the original reason. maybe it also serves as a starting point for writing a completely new filter from scratch. [18:47] <saste> well it was still useful, to test a few reference copy issues [18:50] Action: durandal_1707 blames libmpcodecs [18:51] Action: beastd assumes durandal_1707 does random blaming [18:52] <saste> ffmpeg -i input -v:c copy -t 10 foo.mp4 => silly bug of the day [18:52] Action: durandal_1707 blames beastd for libmpcodecs [18:53] Action: saste blames durandal_1707 who blames beastd for libmpcodecs [18:54] Action: durandal_1707 blames saste for copy filter [18:54] Action: beastd starts another blame game [18:54] Action: durandal_1707 blames everyone who stopped writing filters [18:55] Action: saste blames filters, people should use vapoursynth instead [18:55] Action: durandal_1707 bans saste [18:57] <durandal_1707> setpts='PTS*25*90',fps=24 eats memory [19:08] <wm4> ubitux: I think your vobsub fixes didn't make it into the release branches [19:08] <ubitux> not all of them indeed [19:09] <ubitux> since i had no review and the changes were not trivial [19:09] <ubitux> i didn't want to backport them immediately [19:09] <ubitux> (and indeed a nasty bug was spotted later) [19:12] <durandal_1707> how you can do slide transition with lavfi - you can't [19:14] <wm4> vf_powerpoint [19:15] <ubitux> wm4: http://trac.ffmpeg.org/ticket/1985 [19:15] <durandal_1707> would ffmpeg sponsor scripting filter? [19:16] <wm4> oh my [19:18] <durandal_1707> there is open bug for converting doc/xls... [19:19] <mark4o> it would be cool if the concat filter supported transitions though [19:20] <durandal_1707> there are alfread filters that do transitions [19:21] <durandal_1707> adding transitions inside concat would be big clusterfuck [19:21] <mark4o> alfread filter? [19:21] <wm4> just use vapoursynth [19:22] <wm4> transitions would be easy to script with it [19:22] <durandal_1707> i will kick anyone who mentions it again [19:23] <ubitux> haha [20:08] <durandal_1707> michaelni: why is HEVCLocalContext allocated when it can be inside context? [20:13] <durandal_1707> btw why hevc does not use ONLY_IF_THREADS_ENABLED [20:17] <cone-792> ffmpeg.git 03Carl Eugen Hoyos 07master:5ab1efb9d0dc: Fix a crash on oom when decoding hevc. [20:32] <durandal_1707> git log [20:32] <durandal_1707> stupid shell [20:33] <ubitux> that's not a shell durandal_1707 [20:33] <ubitux> this is the irc window [20:33] <durandal_1707> want to be my shell? [20:34] Action: ubitux : command not found: want [20:34] <durandal_1707> /deop ubitux [20:34] <ubitux> :( [20:35] <Compn> ehe [20:35] <durandal_1707> why you take everything so serious? [20:48] <cone-792> ffmpeg.git 03Compn 07master:6173b0fea71a: aacdec: fix small comment, update decoder features comment [20:49] <Compn> cone is fast :D [20:52] <durandal11707> this commit was not approved [21:09] <Compn> durandal11707 : michael reviewed part of it on -cvslog [21:09] <Compn> it was [21:09] <Compn> pre-approved! [21:25] <smarter> https://trac.ffmpeg.org/ is broken? [21:26] <JEEB> yup, the http side of things seems to work tho [21:27] <llogan> it's back [21:37] <llogan> did anyone get the exact error message referring to the database? [21:41] <cone-792> ffmpeg.git 03Marton Balint 07master:e1573d714746: MAINTAINERS: add myself as libzvbi-teletextdec maintainer [21:43] <smarter> llogan: here: http://pastebin.com/24wmhnhb [21:45] <ubitux> beastd ^ [21:45] <beastd> smarter: hmm, ok. thanks. [00:00] --- Fri Nov 1 2013