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

[burek]

[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-rediscovers-music
[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