[02:20] <cone-924> ffmpeg.git 03Luca Barbato 07master:db9d39b4b5e5: avformat: Report the duration analysis reached [02:20] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:85e1368f57a6: Merge commit 'db9d39b4b5e5a3c20aeecf787ddeadd88f4906cf' [02:28] <cone-924> ffmpeg.git 03Luca Barbato 07master:390acbea0697: configure: Provide --pkg-config-flags [02:28] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:3a05d7a9e583: Merge commit '390acbea0697a60300f249602dbf701e04274693' [02:41] <cone-924> ffmpeg.git 03Luca Barbato 07master:55a215ba63d9: http: Return meaningful error codes [02:41] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:03fd80dcb1f8: Merge commit '55a215ba63d9fa79cd7ee265ee2e777ee86b200c' [02:44] <cone-924> ffmpeg.git 03Luca Barbato 07master:78b21c1d7177: http: Drop doxy comments [02:44] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:b752d02f42bb: Merge commit '78b21c1d7177e1d61ad3c9225f67699da089aa7c' [02:50] <cone-924> ffmpeg.git 03Luca Barbato 07master:7a2fddb44801: http: K&R formatting cosmetics [02:50] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:df41cbee85c8: Merge commit '7a2fddb4480121712df560cf619c1c3566cae3ff' [02:58] <cone-924> ffmpeg.git 03Luca Barbato 07master:4ff99ab3d7d5: http: Refactor process_line [02:58] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:21d4c571fabe: Merge commit '4ff99ab3d7d5576e99e6b8a411b4a44500ed88fa' [03:25] <cone-924> ffmpeg.git 03Luca Barbato 07master:8075c3d8bb1f: http: Add support reading ICY metadata [03:25] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:ca2369cdee0d: Merge commit '8075c3d8bb1f6aade0cc7c5c40db9bc1bcd84cab' [03:29] <Guest52893> hello, just to try this irc. [03:38] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:e58c85b06868: http: Export Content-Type information [03:38] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:c03af3ac1c4c: Merge commit 'e58c85b0686892960042232e51c77168b264838a' [03:40] <yanrong> s [03:42] <hightallyht> hi yanrong [03:55] <cone-924> ffmpeg.git 03Clément BSsch 07master:ddfc98906373: http: Support setting custom User-Agent [03:55] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:f36da16ede52: Merge commit 'ddfc98906373d1f17f6205cedd14c68d7a75995f' [04:28] <cone-924> ffmpeg.git 03Anssi Hannula 07master:2ec33d271272: http: Add support for selecting a request range [04:28] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:76a939d0e58c: Merge commit '2ec33d27127251bbc45e1f88e60691ad59cf2319' [04:37] <cone-924> ffmpeg.git 03Anssi Hannula 07master:ab76d9f628ad: http: Always allow no-op seek [04:37] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:1cc9468289b2: Merge commit 'ab76d9f628ad46e1d3bbf26c5bf1f87083f239ab' [04:51] <cone-924> ffmpeg.git 03Alessandro Ghedini 07master:fe568b3d27ca: http: Improve options descriptions [04:52] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:0d487654ea85: Merge commit 'fe568b3d27ca2c5cca3878b2a7a3a968e605aec4' [04:58] <cone-924> ffmpeg.git 03Clément BSsch 07master:2572d07c1f0a: http: Allow setting a Content-Type for POST requests [04:58] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:cd25412f5984: Merge remote-tracking branch 'qatar/master' [05:18] <cone-924> ffmpeg.git 03Michael Niedermayer 07master:1f36ebf63a8d: avformat: revert %c changes from d92024f18fa3d69937cb2575f3a8bf973df02430 [09:10] <ubitux> > FreeType can now use the HarfBuzz library [09:10] <ubitux> mmh [09:10] <av500> ah harfbuzz [09:10] <av500> arabic all the things! [09:11] <ubitux> http://sourceforge.net/projects/freetype/files/freetype2/2.5.3/ [12:32] <cone-365> ffmpeg.git 03Carl Eugen Hoyos 07master:54bbe3e2a645: Revert "Allow stream-copying grayscale mov files." [12:32] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:3ddf76ee070d: Merge remote-tracking branch 'cehoyos/master' [13:01] <J_Darnley> If git send-email says "5.1.0 <y> invalid address" as its last line, is that en error from the smtp server? [13:05] <J_Darnley> Nevermind. The emails were sent when I tried again [13:19] <cone-365> ffmpeg.git 03Stephen Hutchinson 07master:5336cd6374c7: doc/general.texi: Adjust the notes on AviSynth [13:19] <cone-365> ffmpeg.git 03Bryce McLeod 07master:581957cd8618: avformat/movenc: rescale when copying duration to timecode track [13:21] Action: durandal11707 awesome, now just to add mt frame audio encoder [13:22] <durandal11707> wm4: is tak seeking really that slow? [13:22] <wm4> durandal11707: not slow, but imprecise [13:22] <wm4> I think it'll even output wrong timestamps after seeking [13:23] <durandal11707> that is because duration is usually set in header every ~15th frame [13:24] <wm4> it's probably hopeless to try to seek correctly, and the only way is creating an index in advance [13:24] <durandal11707> but it actually should never change, so maybe i need to set flag or something... [13:25] <durandal11707> wrong timestamps do not happen always... [13:32] <durandal11707> it just seems that parser context is lost when seeking [13:33] <durandal11707> so, creating index in advance by some way is right solution [13:33] <nevcairiel> the parser is flushed, not sure how much of the data survives that? [13:33] <durandal11707> but lavf should already do that... [13:33] <nevcairiel> it doesn't do that in advance, only in areas you already played [13:34] <durandal11707> but for areas not played it should parse all packets up until it finds such timestamp [13:35] <durandal11707> so perhaps index does not have duration set by parser... [13:36] <durandal11707> so parser is run once to seek and again to play... or i'm speaking shit [13:39] <durandal11707> but anyway, mpv should for duration of frame use decoder samples and not stuff reported by lavf/whatever [13:44] <wm4> what's that about duration? [13:44] <wm4> I never use packet/frame duration, except for subtitles [13:50] <cone-365> ffmpeg.git 03Fred Rothganger 07master:3f3229cd109f: avformat: extracting NTP timestamp from RTCP [13:51] <ubitux> wm4: speaking of subtitles, i don't know if it's a bug in ffmpeg, but when 2 events appear at the same time i have the 2 one appear on top of the first [13:52] <ubitux> is that due to libass? mpv internal? bug in ffmpeg? [13:52] <ubitux> iirc we sort them by timestamps, then by position, so it shouldn't have happened [13:52] <ubitux> (it was a .srt file) [13:52] <ubitux> s/2 one/2nd one/ [13:53] <wm4> probably libass [13:53] <wm4> seems logical that the 2nd appears top, because well, the 1st takes the normal place, and the 2nd has to put where there's still place [13:54] <ubitux> yeah right [13:54] <ubitux> couldn't it be changed? [13:55] <ubitux> i mean, it's extremely confusing when it happens :) [13:55] <wm4> one could manually merge events that happen at the same time [13:55] <wm4> with what format did this happen? [13:55] <ubitux> srt [13:56] <ubitux> wm4: it's hard to merge properly [13:56] <ubitux> it would work with easy formats such as srt [13:56] <wm4> I don't think I really want to touch the libass collision logic [13:56] <ubitux> but it won't with all the other [13:56] <wm4> and it'd probably be wrong for ASS [13:57] <wm4> usually srt uses multi line events for multi line events [13:57] <ubitux> could you insert them backward for event at the ssame time? [13:57] <wm4> I don't think srt is even supposed to be overlapping (but then it's a wishy washy half-standard) [13:57] <wm4> yes [13:58] <wm4> ubitux: can I get a sample? [13:58] <ubitux> sure [13:59] <ubitux> wm4: just the srt? [13:59] <wm4> yes [14:04] <ubitux> wm4: http://b.pkh.me/Shokuzai.E05.720p.HDTV.x264.AAC-YYeTs.srt [14:04] <ubitux> grep -- '-->' Shokuzai.E05.720p.HDTV.x264.AAC-YYeTs.srt > a [14:04] <ubitux> grep -- '-->' Shokuzai.E05.720p.HDTV.x264.AAC-YYeTs.srt|uniq > b [14:05] <ubitux> diff -u a b [14:05] <ubitux> you'll get the different ts where that happens [14:05] <wm4> so they're just successive; maybe libavformat could do this automatically [14:06] <ubitux> as i said, yes we could merge them [14:07] <ubitux> but that won't be a generic solution for all the formats [14:07] <wm4> that is why srt could set a flag or call a function to do it [14:07] <ubitux> it will happen in others, where it's not obviously possible to merge [14:07] <ubitux> why don't you just swap the order of rendering? [14:08] <ubitux> i'm pretty sure i can found (or craft since i'm evil) for a format where we can't merge them [14:08] <ubitux> and where the order would matter [14:14] <wm4> that's why I said to merge in srt only [14:14] <wm4> and swapping the order of rendering? I'm just passing packets to the decoder [14:14] <bove> Has anyone been looking at integrating >8bit depths to vf_lut.c? [14:22] <durandal11707> wm4: when i seek tak in mpv it shows ??? for some short time, because packets are missing duration [14:25] <wm4> durandal11707: did you mean ffplay (not mpv) and packet timestamps (not duration)? [14:26] <ubitux> wm4: i suppose that if the subtitles decoders were outputing valid "ass" (so properly "ass ordered") that would help? [14:26] <wm4> ubitux: probably [14:26] <ubitux> oh well that ass insanity [14:26] <ubitux> i just forgot i don't want to touch it [14:27] <ubitux> bove: http://trac.ffmpeg.org/ticket/2475 [14:27] <wm4> but really, the best way would probably be merging them in the demuxer, since srt normally does not have overlapping events, and other subtitle renderers/converters will also have problems with that [14:28] <ubitux> i guess i'll add a method to lavf/subtitles.c [14:28] <ubitux> to auto merge on request [14:28] <ubitux> for "compatible" formats [14:29] <ubitux> wm4: now, what if the duration is different? [14:30] <bove> ubitux: Thanks. I'll put it on my todo list then ... [14:30] <wm4> ubitux: don't merge [14:30] <ubitux> wm4: and so i'll have the exact problem [14:30] <ubitux> +same [14:37] <ubitux> well that will work for simple case anyway [14:40] <ubitux> that's actually pretty trivial to do [14:41] <wm4> also send a hitman to the ones who produced the subs [14:41] <ubitux> :) [14:42] <ubitux> i've seen much worse [14:43] <ubitux> ok so not even compiled but i guess something like that would do the trick http://pastie.org/8911390 [14:44] <wm4> that's all? [14:44] <ubitux> with a ';' at the end tyes [14:45] <ubitux> we already have the merge logic available [14:45] <wm4> sounds like this is the way to go [14:45] <ubitux> until i found samples with different duration& [14:45] <ubitux> or misordered [14:51] <durandal11707> wm4: mpv, not ffplay. and timestamps displays ??? when seeking in mpv [14:53] <wm4> I don't remember having code that prints "???", but I don't have a tak sample right now [14:53] <wm4> though IMO the first after a seek really should have a timestamp [14:53] <ubitux> wm4: i guess it's missing a \n though.. [14:54] <wm4> does ffmpeg have a coding style document? I'm finding not anything obvious in doc/ [14:54] <durandal11707> wm4: but you had one? [14:54] <durandal11707> wm4: send code to libav ml [14:55] <ubitux> wm4: developers.{texi,html} [14:55] <durandal11707> general coding style should be: keep coding style already present in file - do not add your own [14:55] <wm4> ubitux: thanks [14:55] <ubitux> wm4: http://ffmpeg.org/developer.html [14:55] Action: wm4 going to steal it [14:57] <durandal11707> last time i compiled mpv (before configure change/removal/whatever) it displayed ??? or nothing iirc [14:57] <wm4> durandal11707: sample? (also this should probably go into the mpv channel) [14:59] <durandal11707> but iirc you complained about tak here, so you had sample or? [15:03] <ubitux> wm4: actually, it will probably break stuff [15:03] <ubitux> guess what: for ass tag used in srt :D [15:04] <ubitux> if you have a srt even with something like "{\a9}bla\nfoo" and then merge it with the following which has no alignment [15:04] <ubitux> but that's insane anyway [15:10] <wm4> I guess you'Re right [15:11] <ubitux> anyway, ugly hack that works for me http://pastie.org/8911440 [15:29] <wm4> hm [15:30] <wm4> if we don't find a better and more correct way, we should probably go with this... but fact is that some subtitle formats seem to want one ordering, while other formats prefer something different [15:30] <wm4> I'd be inclined to say "fuck it" and go with this hack [15:30] <ubitux> that is only for srt [15:30] <ubitux> ordered ones [15:30] <ubitux> and with matching durations [15:30] <ubitux> pretty limited case but work for the use case i had [15:32] <wm4> there's no spec for srt, so you can only guess [15:33] <ubitux> there is no spec so everyone generate shit and call it srt :) [15:34] <wm4> e.g. the mplayer code doesn't allow overlaps at all, and it just throws away the first line [15:34] <wm4> and it seemed to work for them for years [15:44] <ubitux> (w & ~15) + ((w & 15) ? 16 : 0) [15:44] <ubitux> anything simpler in mind? [15:45] <nevcairiel> isnt that just FFALIN(w, 16)? [15:45] <nevcairiel> ALIGN* [15:45] <ubitux> mmh indeed [15:46] <ubitux> so (w + 15) & ~15 heh. [16:00] <Eventh> :q [16:22] <plepere> in ASM, is there a fast way to copy from an adress to another ? I have function that just does dst[x]=src[x] [16:23] <thardin> rep movsd or somesuch? [16:24] <thardin> copies 4 bytes at a time [16:26] <ubitux> plepere: read 128b, write 128b? [16:39] <nevcairiel> yeah if its aligned you can just use movdqa [16:44] <iive> just use memcpy. I don't think that ffmpeg have its own accelerated memcpy, but gcc might produce simd code for it, given the right alignment of glibc, gcc, options, planets and stars... [16:45] <nevcairiel> yeah if its just C code, use memcpy, many c runtimes have vectorized variants for it [16:45] <nevcairiel> if its fixed size, 64 or 128 byte or something, you can also use AV_COPY64 macros [16:52] <wm4> glibc does have simd code [16:53] <wm4> but according to some tests, it's not even much faster than a naive rep movsd loop [16:53] <wm4> (on never CPUs) [16:54] <nevcairiel> i only know that even a manual movdqa loop isnt faster then memcpy, on msvcrt anyway [17:07] <jnvsor> I noticed that ffmpeg supports flac but it's not in the codec docs or the `./configure -h` - is it just baked in by default? [17:07] <JEEB> there is a libavcodec encoder for flac, yes [17:08] <av500> how does it sound? [17:08] <nevcairiel> configure -h only lists external libraries [17:08] <av500> as bad as the AAC one? [17:08] <kierank> av500: sounds lossy [17:08] <kierank> we need to get neil young in [17:08] <kierank> he'll sort it out [17:08] <av500> +1 [17:08] <JEEB> :D [17:08] <jnvsor> What, flac? [17:08] <nevcairiel> don't listen to them trolls [17:09] <nevcairiel> they're just making fun of pono [17:09] <av500> flac is not good enough, you also need zero feedback [17:09] <nevcairiel> he found quite a bunch of fools to pay up though [17:09] <nevcairiel> 1.5mil now [17:09] <av500> sure [17:10] <av500> at that rate, he can also make a ubuntu phone soon [17:10] <nevcairiel> what i find more baffeling though is the design of that player [17:10] <av500> the design I like [17:10] <jnvsor> I'm confused, I think I've stumbled into a conversation halfway through [17:11] <av500> no [17:11] <wm4> pono? [17:11] <av500> https://www.kickstarter.com/projects/1003614822/ponomusic-where-your-soul-re... [17:12] <nevcairiel> my boss seems to like the initiative, but maybe thats because he is about the same age as neil not-so-young [17:12] <jnvsor> So flac is lossless and pono is a triangle ipod? Gotcha [17:12] <av500> the age when your hearing maxes out at 12khz :) [17:13] <wm4> pretty annoying shape and colore [17:13] <av500> beauty is in the eye of the beholder [17:14] <av500> pono is a flacPod [17:14] <wm4> what if my eye is the most objective eye? [17:14] <av500> wm4: then stick a pono into it [17:14] <wm4> ow [17:14] <nevcairiel> just get the black one, not so annoying color [17:14] <nevcairiel> didnt i read something about their own special blend of audio format earlier [17:14] <nevcairiel> kickstarter claims they use flac [17:14] <av500> yes [17:15] <av500> yes, I think they changed rethoric [17:15] <av500> maybe they realised ppl will call out the BS [17:15] <wm4> so not yet another lossless audio codec? :( [17:17] <av500> https://plus.google.com/u/0/+VladimirPantelic/posts/J3aM2xYHaCb [17:17] <nevcairiel> but they must be throwing some drm on top of it, you know, cant have flac highres audio without protection! [17:17] <av500> this link to the older article about "special sauce" [17:17] <av500> nevcairiel: seems DRM is gone now too [17:17] <nevcairiel> the RIAA will not let that happen :p [17:17] <av500> they do [17:18] <av500> you get music sans DRM these days, no? [17:19] <nevcairiel> i suppose it depends how this service is setup, buying individual albums vs. subscription access to the entire library [17:20] <wm4> ah lol there's talk about flac etc. not being good enough [17:21] <ubitux> let's rar+zip it [17:21] <wm4> repeat 10 times for better compression [17:23] <av500> yes [17:23] <av500> its neil young! [17:23] <av500> just believe! [17:24] <thardin> feels like hipster bait [17:24] <ubitux> so they are able to reach the same size as flac but at 192kHz? [17:24] <ubitux> (basically a codec decoding flac and upsampling) [17:24] <nevcairiel> flac with sbr? [17:26] <thardin> I'm not seeing much technical information scrubbing through the video. just feels [17:29] <thardin> maybe they'll get more nicely mastered tracks [21:03] <cone-365> ffmpeg.git 03Martin Storsjö 07master:e77a2ea95058: http: Declare more parameters as const where possible [21:03] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:ad341b3bc65e: update doc/APIchanges [21:03] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:7e6c6c45ec7c: Merge commit 'e77a2ea9505863e50bf013706f66bf8b7325e524' [21:36] <cone-365> ffmpeg.git 03Diego Biurrun 07master:b3c6ee199e75: configure: Group toolchain options together in help output [21:36] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:aa175983a196: Merge commit 'b3c6ee199e75bbad2908253f11e871500dd38531' [21:43] <cone-365> ffmpeg.git 03Vittorio Giovara 07master:b4e355c89e23: copy_block: K&R formatting cosmetics [21:43] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:990f956ce66b: Merge commit 'b4e355c89e23664b8dac26936bf3fa7e7bc2110f' [21:52] <cone-365> ffmpeg.git 03Luca Barbato 07master:aa807425395c: configure: Support older version of openjpeg1 [21:52] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:58b8d268d971: Merge commit 'aa807425395caa17a85ed2833133278e8bd44a76' [22:15] <cone-365> ffmpeg.git 03Janne Grunau 07master:5a7f382a5d33: armv6: vp8: use explicit labels in motion compensation asm [22:15] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:e5920425b02b: Merge commit '5a7f382a5d33d9a26890affe6c8c5070a48dfc22' [23:21] <cone-365> ffmpeg.git 03Martin Storsjö 07master:d15c536123a4: doc: Point to the correct, actually maintained gas-preprocessor repo [23:21] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:835f41376da1: Merge commit 'd15c536123a44362ace6299c391a492c90b83fc7' [23:21] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:675a66a93bf8: doc: switch github urls to https [23:21] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:98eb99d20bf5: tools/build_libstagefright: switch git urls to https [23:21] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:b5c6b23acd6f: doc/platform: mention that yuvis gas-preprocessor is currently missing some changes [23:30] <cone-365> ffmpeg.git 03Alessandro Ghedini 07master:6998a9f4c4e0: http: Properly initialize icy headers string [23:30] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:11ed7ec092d3: Merge remote-tracking branch 'qatar/master' [23:38] <wm4> what does all_channel_counts on buffersink do again? Libav doesn't have it [23:39] <nevcairiel> its apparently a boolean flag that tells it to accept any input channel counts [23:39] <nevcairiel> instead of just the list of supported ones [23:39] <wm4> and what if neither is set? [23:40] <nevcairiel> chaos ensues? [23:40] <wm4> in that case it seems not to call ff_set_common_channel_layouts(), whatever that means in the end [23:40] <nevcairiel> never used lavfi for audio [00:00] --- Thu Mar 13 2014