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

[burek]

[00:00] <burek> e.g. you can make a "network share" and use it as a storage, since the speed will be big enough, considering it'll go over loopback interface anyway
[00:00] <durandal_1707> ram in sance on for writable stuff, this shouldn't be that big (also ccache is nono in that case...)
[00:00] <ubitux> saste: what is this xy normalization thing?
[00:00] <saste> NaN -> int conversion
[00:01] <saste> I'm assuming that NaN = out of the screen
[00:01] <ubitux> yes but why the alignment?
[00:02] <saste> note that indeed we could abuse this to implement enable/disable...
[00:02] <ubitux> saste: the align is to get x = 0 0 1 1 2 2 .. or similar for chroma sub sampling ?
[00:02] <saste> yes
[00:03] <ubitux> mmh won't you get 0 0 2 2 4 4 ... instead?
[00:03] <durandal_1707> i gonna push (after 24h passed) test, stop me now if you want....
[00:03] <ubitux> erm i guess that's what you want
[00:03] <ubitux> durandal_1707: what test?
[00:03] <saste> ubitux, the latter is correct
[00:03] <ubitux> ok
[00:04] <ubitux> saste: give me just a few more minutes :)
[00:04] <saste> ubitux, no hurry, i can push it tomorrow
[00:04] <durandal_1707> ubitux: the one on ml
[00:04] <ubitux> saste: i want to get done with the review before going to sleep
[00:06] <ubitux> saste: my mind is still on the enable thing
[00:06] <ubitux> could we have a generic "enable" option?
[00:07] <ubitux> i mean handling a "enable" option at avfilter level
[00:07] <ubitux> (not part of the syntax, but for each filter)
[00:07] <saste> the fact is that "enable" is different for each filter
[00:07] <saste> what is enable for null?
[00:08] <ubitux> if !enable ’ passthrough
[00:08] <ubitux> but smart passthrough for some filters which needs an update after each frame
[00:08] <ubitux> or not supported for some other filters
[00:09] <durandal_1707> how would one enable 'enable' ?
[00:09] <ubitux> i proposed to have a generic enable avoption, but it sucks for filter without avopt support
[00:09] <saste> we could create a secondary output for select, and then have a join filter
[00:10] <ubitux> saste: can you give an example of usage?
[00:10] <brimestone> hey guys, i have this file ( http://pastebin.com/uSTKiLw2 ) its generated by a ( 5DMK3 ) with avc1/H.264 (high) with 23.98 psf as FPS.. i need to add telecine to 30003/1001 or 29.97 But, i can only apply it if im sending it to a ProRes codec which is intruducing a color shift. can anyone help?
[00:10] <durandal_1707> brimestone: wrong channel, go to #ffmpeg
[00:10] <brimestone> ohh sorry.. thanks
[00:11] <ubitux> saste: select would "mark" some "ghost" frame to ignore in the filters?
[00:11] <saste> ubitux, i'm writing an example, it's difficult to get it nice
[00:12] <saste> it takes time to choose meaningful labels
[00:12] <ubitux> we also have the possibility to have a syntax+ like it was proposed already
[00:12] <ubitux> -vf foobar[enable=between(t,10,20)]=...
[00:13] <saste> so you would have: select=EXPR [yes][no]; [yes] process, [no] join
[00:13] <ubitux> but some people are going to get very mad at us
[00:13] <ubitux> oh that's fun
[00:14] <saste> join is the opposite of split, so just send in output the input of any incoming frame (from many inputs)
[00:14] <ubitux> saste: that's a pretty good idea actually
[00:14] <ubitux> (note that we have a af join already :( )
[00:15] <saste> merge is already taken as well
[00:15] <saste> mux?
[00:15] <ubitux> select=EXPR [yes][no]; [yes] process, [no] fusion
[00:15] <saste> fuse seems nice
[00:15] <nevcairiel> fusion of the nuclear kind?
[00:16] <ubitux> select=EXPR [yes][no]; [yes] process, [no] meltdown
[00:17] <ubitux> junction
[00:17] <ubitux> reduce
[00:18] <saste> framejoin
[00:18] <nevcairiel> combine
[00:18] Action: durandal_1707 opens thesaurus
[00:18] <ubitux> saste: now question: in what order are you going to join?
[00:19] <saste> ubitux, in -> out, no buffering
[00:20] <ubitux> will that work with all the avfilter crazyness of request frames?
[00:20] <saste> uhm... probably not
[00:20] <saste> in case of a select, yes
[00:21] <ubitux> what if the processing filters are doing some buffering 
[00:21] <ubitux> ?
[00:21] <ubitux> it's possible this filter will have to deal with pts
[00:22] <ubitux> otherwise you'll likely have all kind of mixed frames
[00:22] <saste> yes
[00:22] <saste> i was hoping to avoid that, but that may well be possible
[00:22] <saste> it could implement a logic similar to that of overlay
[00:22] <ubitux> anyway, if we could have such filter, even if basic, to avoid the need of an enable flag
[00:22] <ubitux> i would be very happy
[00:23] <ubitux> or you would prefer to push the overlay with the enable option anyway first?
[00:23] <saste> ubitux, i'll split the patch
[00:23] <ubitux> thx :)
[00:23] <saste> for the moment it would be useful to have a feature, let me think about it
[00:24] <ubitux> ok; i can go to sleep then
[00:24] <saste> my problem with a generic approach is that it would complicate the syntax
[00:24] <ubitux> yes
[00:24] <ubitux> i'm fine with the framejoin filter
[00:24] <ubitux> (even though i would prefer the "fusion" name)
[00:25] <saste> combine also is a good opposite of split
[00:25] <ubitux> i'm fine with any name :)
[00:25] <saste> tilps
[00:25] <ubitux> :D
[00:26] <durandal_1707> splice
[00:26] <durandal_1707> knit/link and so on
[00:27] <ubitux> splitpowminusone
[00:27] <durandal_1707> yoke
[00:27] <saste> splice sounds nice
[00:27] <saste> split/splice
[00:28] <ubitux> union
[00:28] <saste> i'm for splice, it's short, it's a verb and sounds similar to split
[00:29] <saste> so people can easily associate them
[00:29] <ubitux> do you have a usage of split & splice in the same filtergraph?
[00:29] <durandal_1707> make it configurable, so people can rename filter name at wish
[00:30] <saste> split,splice = null
[00:30] <ubitux> durandal_1707 :D
[00:30] <saste> uhm no it will duplicate frames
[00:32] <durandal_1707> uhh telecine filter is useful?
[00:32] <ubitux> yes
[00:32] <ubitux> to test ivtc algorithm
[00:33] <ubitux> and make ppl crazy
[00:33] <ubitux> so it's definitely useful
[00:33] <nevcairiel> also remember that person just here 20 minutes ago asking about telecining, even if he was in the wrong channel =p
[00:34] <durandal_1707> yes, (but people asking do not necessarily mean it is useful, good idea)
[00:34] <nevcairiel> its useful for them
[00:34] <ubitux> i guess the reason durandal_1707 is asking is because that specific person is wondering about such problem on the user channel :p
[00:34] <durandal_1707> code looks trivial to port, except each filter implements own memcpy function for some reason
[00:35] <ubitux> yes it's trivial to port
[00:35] <durandal_1707> its about colorspace issue, which seems to be completly ignored on lavfi side
[00:35] <ubitux> durandal_1707: it might even be integrated in tinterlace
[00:35] <ubitux> (just add a mode)
[00:36] <durandal_1707> eg user is doing yuvj to yuv
[00:36] <nevcairiel> i wouldn't do that, that just adds to the confusion, interlace and telecine are not the same thing
[00:36] <nevcairiel> the only thing in common is that they work somehow with fields instead of frames
[00:36] <nevcairiel> but thats it =p
[00:36] <ubitux> the only thing in common is that they interlace
[00:36] <nevcairiel> telecine is not interlacing
[00:37] <nevcairiel> telecine actually adds information to the stream, interlacing only takes away
[00:39] <durandal_1707> what information it adds? (i'm dumb noob at this interlace/telecine mojo)
[00:39] <nevcairiel> it doubles fields
[00:39] Action: durandal_1707 opens wikipedia
[00:39] <nevcairiel> every second frame gets one of its fields duplicated
[00:39] <nevcairiel> more or less
[00:40] <nevcairiel> in 24->30 telecine anyway
[00:40] <nevcairiel> if you remove that duplicate again, you get the original back, lossless operation
[00:42] <ubitux> every 5 frames 2 fields are dup
[00:44] <ubitux> 4 progressive frames -> 3 progressive frames + 2 interlaced frames
[00:47] <ubitux> anyway, 'night
[00:50] <durandal_1707> why -vf mp=telecine does nothing here ?
[00:51] <durandal_1707> i expected to see black stripes
[00:53] <durandal_1707> actually telecine produces nothing here, but just duplicates frames
[00:59] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:7775992c65e5: doc/filters: fix main/over mismatch in movie examples
[01:07] <durandal_1707> the colorspace mess would be good gsoc task
[01:11] <Compn> which mess ?
[01:11] <Compn> filter colorspace ?
[01:11] <durandal_1707> colorspace conversion thing is not automagical
[01:12] <durandal_1707> so you happen to lose colors if you are not careful....
[01:31] <durandal_1707> michaelni: native noise is faster than mp one with enabled mmx code(manually removing ifdefs)
[01:32] <Compn> what were the ifdefs there for
[01:32] <Compn> :)
[01:32] <durandal_1707> HAV_MMX
[01:32] <durandal_1707> *HAVE
[01:33] <Compn> ah
[01:33] <Compn> would it fail on non mmx cpu like 486 or arm /ppc ?
[01:33] Action: Compn afk
[01:33] <Compn> asking too many dumb questions now
[01:34] <durandal_1707> if anyone wants to port that inline asm code he/she can do it any time - there is no reason to keep mp=noise just because it have inline asm that get never compiled
[01:34] <durandal_1707> michaelni: so i would like to remove mp=noise
[01:49] <nevcairiel> interesting, that 4.7gb mov plays fine here :d
[01:51] <durandal_1707> on windows?
[02:00] <BBB-work> port the inline asm to yasm
[02:00] <BBB-work> it's not difficult, and actually teaches you a very useful skill
[02:33] <llogan> there is "ffmpeg -h encoder=foo", decoder=, filter=. any others?
[03:06] <kierank> how would you suggest to fix the mess?
[03:06] Action: kierank doesn't know
[03:15] <kierank> Compn: swscale and lavfi i guess
[03:23] <Compn> someone going to apply those vf_xyz patches ?
[03:23] <Compn> until someone else adds xyz to swscale
[03:23] <Compn> ...
[03:24] <Compn> else it will rot and no one will look at it and ffmpeg wont be used
[03:24] <Compn> for that purpose
[03:24] <Compn> we should prioritize some broadcast dcp/mxf stuff. those professionals have more money to dump for donations and new feature bounties ;P
[03:53] <kierank> Compn: ubitux's previous employer for example
[03:54] <kierank> donations are rather hard to do for accounting purposes in a company
[03:54] <kierank> even hiring of developers is avoided if possible for some organisations
[03:55] <Compn> what now
[03:56] <Compn> we get some nice companies offering money from time to time
[03:57] <kierank> tip of a massive iceberg in my experience
[03:57] <Compn> well ffmpeg has rejected it in the past, because money isnt ever good 
[03:57] <Compn> but i guess ffmpeg uses it to pay travel expenses to send devs to parties.. i mean conferences
[03:59] <kierank> you can't consider an ffmpeg donation a standard business expense
[03:59] <kierank> you'd have to pay tax on it
[04:41] <Compn> kierank : its non profit donation , no taxes iirc ?
[05:48] <NARS> hi, I would like to suggest a very small thing for ffmpeg... can anyone point me what's the best way to do it?
[05:54] <NARS> the thing is... ffmpeg can already read latm "encapsulated" aac audio, I did tried a ts with such as input and it's ok, then the code to filter latm must be already there... what I would like to suggest would be if possible add it as a bitstream filter option (similar to aac_adtstoasc)
[05:55] <NARS> so that we would be able to do 'copy' with such filter option to just convert latm to non latm without the need to fully reencode aac
[05:57] <NARS> just that... I'm not a developer but think it may be a simple thing as the code to read/handle latm but be there already..
[06:03] <burek> NARS, did you try our issue tracker?
[06:03] <burek> actually https://ffmpeg.org/trac/ffmpeg
[06:03] <NARS> it's not exactly a bug, should I?
[06:03] <burek> it can accept feature requests too
[06:03] <NARS> ah ok, ty will do it them :)
[06:04] <burek> great :) thanks :)
[06:04] <NARS> :)
[06:15] <Compn> NARS : sounds difficult and time eating for most devs
[06:15] <Compn> writing bsf isnt easy either
[06:16] <Compn> is good idea, but i dont think anyone going to work on it...
[06:16] <NARS> hmm
[06:16] <burek> btw, what is the difference between the regular filters and bsfs?
[06:16] <Compn> what filter ? you mean lavfi ?
[06:16] <burek> filters in general
[06:17] <Compn> bsf is the way the codec is encapsulated
[06:17] <Compn> or packetized
[06:18] <Compn> the audio and video filters just mess with the actual video/audio. not how the data is stored in the container
[06:18] <Compn> if that makes any sense
[06:18] <burek> hm.. i get what you say
[06:18] <burek> also on docs page it says: A bitstream filter operates on the encoded stream data, and performs bitstream level modifications without performing decoding.
[06:18] <Compn> right
[06:18] <burek> but, if the stream is already encoded (like a zip file for example)
[06:18] <burek> changing any bits in that stream would mess with any kind of crc right?
[06:18] <Compn> only the zip container crc
[06:19] <Compn> if the codec has a crc, the bsf might not affect it
[06:19] <burek> i mean, streams are usually compressed and changing the bit in the stream would most probably make it invalid for the future decoding.. that's how i see it at least
[06:20] <Compn> like if ac3 codec was stored differently between m2ts and .mkv , and you used a bsf to convert it ... it doesnt change any actual data, just how its stored
[06:20] <Compn> its a lossless conversion
[06:20] <Compn> how about that ? :)
[06:20] <burek> i thought that was the muxer's job :)
[06:21] <Compn> the muxer would just copy the m2ts packets into the mkv file. is it standard ? maybe? would other players decode it? no.
[06:21] <burek> i get approx what you (and docs) say, i just have a hard time accepting that it won't damage anything :)
[06:22] <Compn> i think we have samples with example bsf command lines, if you want to compare hex or crc :P
[06:22] <burek> yeah, i think that would help :)
[06:23] <Compn> its like if you encoded a .txt in rot13. a bsf could convert it to utf8
[06:23] <Compn> the text in the file is the same, but now has a diff encoding :)
[06:23] <burek> i see
[06:23] <burek> but in that case you would have to decode a stream, right? :)
[06:24] <Compn> you dont have to decode for bsf 
[06:24] <Compn> i mean you pasted that
[06:24] <Compn> whats the question? 
[06:24] <burek> that's the part i don't get, how does bsf change the stream, without decoding..
[06:24] <burek> how does it deal with compressed data, modifying it without affecting the decoded content
[06:25] <Compn> it changes the headers and start codes 
[06:25] <burek> oh i see
[06:25] <Compn> like a zip file has a header PKZIP
[06:25] <burek> so it doesn't touch the compressed data part
[06:25] <Compn> right
[06:25] <burek> oh that makes a lot of sense
[06:25] <burek> thanks :)
[06:26] <Compn> its hard to explain . probably i dont know the right terminology
[06:26] <NARS> but from what I could understand latm is something like just added extra headers to normal/raw aac, then such a filter would just need to drop them... but I may have wrong idea...
[06:26] <Compn> i dont know how advanced latm is to aac
[06:27] <Compn> aac has so many subsets and versions. even ffmpeg doesnt support  them all
[06:27] <NARS> also there is a windows exe over there able to convert it, but need to demux video/audio (aac latm stream), convert it, remux... would be a dream to just do something like: ffmpeg -i in.ts -vcodec copy -acodec copy -absf aac_latmtoraw out.mkv
[06:27] <NARS> :)
[06:27] <NARS> hmm
[06:28] <Compn> why are you converting ts to mkv anyhow ?
[06:28] <Compn> hardware player ?
[06:28] <NARS> yes :)
[06:29] <NARS> wdtv live
[06:29] <NARS> doesn't handle ts properly
[06:29] <NARS> doesn't support seek, pause
[06:29] <burek> NARS, if you can find an example of the same audio source in raw and latm, you could upload them so devs could see if it's a trivial task or not
[06:29] <Compn> update firmware ?
[06:29] <NARS> already reported to wd but...
[06:29] <NARS> latest one...
[06:29] <Compn> wd guys tested our sample repo against their hardware player :)
[06:30] <NARS> hmm :)
[06:30] <Compn> just for bugs tho. not for supporting stuff
[06:30] <NARS> burek: but code to handle latm must be already on ffmpeg
[06:30] <Compn> to make sure our samples didnt crash their box
[06:30] <NARS> for eg.
[06:30] <NARS> if I do:
[06:30] <burek> also, if this is your ticket: https://ffmpeg.org/trac/ffmpeg/ticket/2438
[06:30] <NARS> ffmpeg -i in.ts -vcodec copy -acodec libvo_aacenc out.mkv
[06:30] <NARS> it will work fine
[06:31] <burek> it's incomplete, they will ask you for the full command line + complete output
[06:31] <NARS> just needs to reencode whole aac again and it's no sense :)
[06:31] <burek> and probably will say "if it plays in ffmpeg/ffplay, then go to Eduis/Premiere support channels" :)
[06:31] <NARS> as I want aac, just non latm :)
[06:32] <Compn> just reencode the audio
[06:32] <Compn> punk!
[06:32] <Compn> :P
[06:32] Action: Compn gone
[06:32] <NARS> :P
[06:32] <NARS> also it shows this:
[06:32] <NARS> --
[06:32] <NARS> Output #0, matroska, to '/mnt/cache/tmp/iii-ar.mkv':
[06:32] <NARS>   Metadata:
[06:32] <NARS>     encoder         : Lavf55.1.100
[06:32] <NARS>     Stream #0:0: Video: h264 (H264 / 0x34363248), yuv420p, 720x576 [SAR 12:11 DAR 15:11], q=2-31, 25 fps, 1k tbn, 90k tbc
[06:32] <NARS>     Stream #0:1(por): Audio: aac ([255][0][0][0] / 0x00FF), 48000 Hz, stereo, s16, 128 kb/s
[06:32] <NARS> Stream mapping:
[06:32] <NARS>   Stream #0:0 -> #0:0 (copy)
[06:32] <burek> well, NARS, my point is, if you can find the same source in both raw and latm, you can prove then it's just a matter of bsf to handle the additional data/header and then someone might take that issue and develop a patch for it
[06:32] <NARS>   Stream #0:1 -> #0:1 (aac_latm -> libvo_aacenc)
[06:32] <NARS> --
[06:33] <burek> Compn :beer: :)
[06:33] <NARS> you can see it recognizes input as latm :)
[06:33] <NARS> and handles it, but only for reencoding task :)
[06:33] <burek> NARS, next time use pastebin :)
[06:33] <NARS> ok, sorry :)
[06:33] <burek> i understand what you are asking
[06:34] <burek> the only fuzzy thing left is to make sure it is possible to do it using bsf
[06:34] <burek> i.e. without reencoding
[06:34] <NARS> yes
[06:34] <burek> so, find a primer that proves it
[06:34] <burek> and you'll get your patch in couple of days
[06:34] <burek> if not the same day
[06:35] <NARS> primer?
[06:37] <burek> example
[06:37] <NARS> ah ok
[06:38] <NARS> and no, the ticked 2438 it's not from me, and not related at all
[06:57] <NARS> I did created the ticket anyway maybe someone looks at it... :)  https://ffmpeg.org/trac/ffmpeg/ticket/2439
[08:39] <arkiaz> michaelni: Hi, I am a student and would like to ask you a question regarding the GSoC 2013 project on libpostproc. Is it a right time for you?
[09:42] <kurosu> michaelni: your suggestion of unrolling further for i=1, although logical, is 489c here (compared to 482 with the patch submitted)
[09:43] <kurosu> michaelni: although Paul seems to have concerns with numerical stability; indeed the output (even for fpu=sse2) is different
[09:44] <kurosu> now, this is an autocorrelation function where the difference shouldn't accumulate, but the calling code is probably computing an inverse function out of it, so there indeed can be such an issue
[09:44] <kurosu> now, iirc, the input of that inverse function is noise iirc, and anyway fate passes
[09:44] <kurosu> *input to
[11:51] <kurosu> Ok, I'm trying to rebase again a libav branch onto ffmpeg
[11:52] <kurosu> so I ran git fetch and pull to update ffmpeg
[11:52] <kurosu> (git pull in the created branch ffmpeg-master pointing to ffmpeg/master)
[11:53] <kurosu> then I went to my libav branch, checkout -b to the new branch to rebase
[11:53] <kurosu> then ran git rebase ffmpeg-master (probably equivalent to ffmpeg/master as it has been fetched/pulled/fastfwed etc)
[11:54] <kurosu> btw ran make distclean, and checked with git status that no file seemed in the way
[11:55] <kurosu> but on rebase I have conflicts in Makefile, common.mak etc
[11:55] <kurosu> those files I don't think I have ever touched
[11:55] <kurosu> soooga, what's happening ?
[11:55] <kurosu> ubitux / michaelni: any idea about the above ?
[11:56] <kurosu> ah, autocompletion on so...
[11:57] <ubitux> is your local ffmpeg-master in sync with ffmpeg/master?
[11:57] <kurosu> oh, maybe I have pulled libav and ffmpeg hasn't yet merged the changes I have updated
[11:58] <kurosu> I haven't verified, but I have just ran git fetch ffmpeg, then git pull in it
[11:58] <kurosu> (ie fast fwd)
[11:58] <jojva> correct me if i'm wrong but isn't git pull = git fetch + git merge ?
[11:59] <kurosu> after the pull, git told me I could fast forward, which i've seen to be git pull
[11:59] <kurosu> hence what I have done; but maybe it is as you say
[12:00] <kurosu> I think it has to do with libav being on a "revision" that isn't yet merged/... by ffmpeg
[12:01] <kurosu> so I just have to wait that a kind soul such as michaelni does it
[12:02] <nevcairiel> rebasing between libav and ffmpeg can be problematic, if its only a small number of commits it can be easier to just create a new branch based on ffmpeg-master and cherry-pick your commits over
[12:04] <kurosu> that's another possibility, never used cherry picking before
[12:06] <kurosu> i guess I have to get the commits hashes from my libav-based branch, then run cherry pick on each
[12:06] <nevcairiel> indeed
[12:06] <kurosu> is there a faster or oneliner for it ?
[12:08] <nevcairiel> with a recent git version (> 1.7.2 or so), you can cherry-pick version ranges
[12:08] <cptspiff> for rev in `git rev-parse startrev..endrev`; git cherry-pick $rev; done
[12:08] <nevcairiel> nah no need for that anymore
[12:08] <kurosu> 1.8 there
[12:08] <nevcairiel> can just do git cherry-pick libav-master..yourbranch
[12:09] <cptspiff> neat didnt know.
[12:14] <kurosu> nice, worked
[12:14] <michaelni> kurosu, if i=2 is slower for you then forget it, it only gave a very small speedup on sandybridge
[12:15] <kurosu> michaelni, I could have checked disassembled code, but this looked like something that could come back anytime anyway
[12:15] <kurosu> (more a compiler issue than an algorithmic one)
[12:18] <michaelni> about rebasing, ive applied 2 patches from the patch series, that might cause minor conflicts for the earlier patches
[12:18] <kurosu> the cherry picking went smooth
[12:19] <kurosu> I think libav has commited neg_ogg dsp function, dunno if it will cause any issue when merging
[12:20] <kurosu> I have written more sse2 function seeing how it is indeed more efficient (certainly due to the 2 shifting units for integers as you've mentioned)
[12:36] <michaelni> I wonder how many people still use cpus that support SSE1 but not SSE2
[12:47] <kurosu> I know, it's more about thoroughness, and because that was the new instruction set at the time I learned x86 assembly
[12:49] <kurosu> anyway, fate-aac passed for win{32,64}x{C,sse,sse2}
[12:53] <kurosu> I'm not sure if I can use git send email with a messageid while I have rebased and potentially changed patch titles, but here's a new batch
[12:54] <nevcairiel> depends on the mail client if a different subject resumes the old thread, really
[12:58] <kurosu> I didn't use messageid so new thread, but it's probably better after a small while
[13:21] <cone-153> ffmpeg.git 03Paul B Mahol 07master:11d7bbb47a1e: fate: add coverage for background disposal in gif decoder
[13:27] <durandal_1707> anyone know VAG real address?, I already tried to contact him, but failed
[13:28] <cone-153> ffmpeg.git 03Reinhard Tartler 07master:a862c7d33682: Integrate lcov/gcov into Libav
[13:28] <cone-153> ffmpeg.git 03Michael Niedermayer 07master:84bfa8beb708: Merge commit 'a862c7d3368241e72a465ab944afa38ea62a6640'
[13:35] <cone-153> ffmpeg.git 03Christophe Gisquet 07master:f4b0d12f5b3f: x86: sbrdsp: Implement SSE neg_odd_64
[13:35] <cone-153> ffmpeg.git 03Michael Niedermayer 07master:32bac65ba0be: Merge remote-tracking branch 'qatar/master'
[13:42] <durandal_1707> looks like it's mandatory to use setpts after mp=telecine
[13:45] <durandal_1707> what about vf_phase filter ?
[13:52] <cone-153> ffmpeg.git 03Michael Niedermayer 07master:ff50b08304fe: coverage: filter /usr/include out
[13:57] <durandal_1707> huh what changed? now ffplay -f lavfi -i smptebars colors are ok
[14:08] <highgod> Hi, I want ask a quesions, if I add a opt to OpenCL context, can it be input by user? I mean, user can use command to set device, platform. and so on, thanks
[14:13] <durandal_1707> highgod: yes, that is point of lavu/opt
[14:15] <highgod> Thanks, @durandal,how can I input the command line? I have add a context to it for the log, I don't konw how to input the command line, Thankd
[14:15] <highgod> thanks
[14:15] <highgod> I want to write a simple command to test
[14:20] <highgod> is there any document to introduce it? thanks
[14:21] <durandal_1707> highgod: read source code
[14:22] <highgod> OK. thanks
[14:56] <Tjoppen> uh.. what are the flags for getting nearest neighbor scaling?
[14:57] <Tjoppen> flags=0 it seems
[14:59] <Tjoppen> flags=16 even
[15:13] <durandal_1707> hmm if i apply telecine filter and fatch result am i supposed to see same video?
[15:13] <durandal_1707> s/fatch/watch
[15:13] <nevcairiel> pretty much, just with more frames
[15:14] <durandal_1707> but i want to see some difference, is that possible?
[15:14] <nevcairiel> if you dont deinterlace the result, you should see weaving in moving parts
[15:16] <durandal_1707> moving is fine here with ffplay, so either mp=telecine does nothing (just duplicates random frame) or something insert deinterlacer
[15:16] <durandal_1707> ffplay -i input -vf "mp=telecine,setpts=N/(30000/1001*TB)"
[15:17] <nevcairiel> maybe it needs options how to telecine?
[15:17] <durandal_1707> it does not accepts any option
[15:18] <durandal_1707> the libmpcodecs code have some ifs that are not in mplayer one i think
[15:18] <nevcairiel> it indeed seems like a rather dumb filter
[15:19] <durandal_1707> many in that directory really are, the most obvious one are already removed (but they should not get into at first place .....)
[15:19] <nevcairiel> the code looks like it would do something though
[15:19] <nevcairiel> add a new frame, sometimes with a field duplicated
[15:19] <ubitux> mp=telecine seems to have no effect here
[15:19] <durandal_1707> rm -f
[15:20] <durandal_1707> does it works with mplayer?
[15:20] <ubitux> yes
[15:21] <ubitux> watch a video frame by frame with -vf telecine
[15:21] <ubitux> you'll see the effect pretty clearly
[15:21] <ubitux> if the telecine is correct i don't know though
[15:21] <durandal_1707> but yesterday user on #ffmpeg claimed that mp=telecine is very good :)))
[15:21] <ubitux> but at least it has some effect :p
[15:21] <nevcairiel> chain a ivtc behind it and see if it catches on :p
[15:21] <ubitux> durandal_1707: i haven't try with ffmpeg, just ffplay
[15:22] <ubitux> lavfi magic might be in effect
[15:23] <durandal_1707> tried with ffmpeg and -f sdl, expect it spams and is slower output is same
[15:25] <durandal_1707> lets port this nonsense and expect it will suddenly work
[15:25] <ubitux> :D
[15:26] <durandal_1707> i wonder why that user of yesterday now think about our code
[15:27] <ubitux> why/what?
[15:27] <durandal_1707> yes
[15:27] Action: ubitux "almost"© done with the ivtc doc
[15:28] <ubitux> so much pain
[15:30] <durandal_1707> when was telecine filter written in mplayer?
[15:31] <ubitux> feb 2003
[15:31] <durandal_1707> its just for (C) thing on top of file
[15:34] <durandal_1707> it it's really that trivial, i could add other modes, if i find good documentation somewhere
[15:34] <ubitux> modes for?
[15:34] <durandal_1707> telecine
[15:35] <ubitux> yeah but what would they do?
[15:35] <ubitux> you could configure the pattern but i'm not sure what else
[15:35] <durandal_1707> just to test deinterlacers(or whatever reverse process)
[15:37] <durandal_1707> are there telecine filters from *synth projects?
[15:38] <durandal_1707> code is so trivial that i think i will rewrite it and make it LPGL
[15:49] <durandal_1707> i see mplayer have tfields filter
[16:08] <ubitux> durandal_1707: native -vf fields
[16:08] <durandal_1707> ubitux: there is also field filter
[16:09] <durandal_1707> there is no native fileds
[16:09] <durandal_1707> *fields
[16:09] <ubitux> sorry, vf field yes
[16:53] <durandal_1707> hmm do i need to get two frames at same time?
[17:03] <cone-153> ffmpeg.git 03Christophe Gisquet 07master:f4ac80227b4e: sbrdsp: unroll sbr_autocorrelate_c
[17:03] <cone-153> ffmpeg.git 03Christophe Gisquet 07master:11774169ae22: sbrdsp: unroll and use integer operations
[17:18] <durandal_1707> hmm i think i will go for telecine removal because current telecine is crap and useless, i will write another (NIH here) heavily based on divVerent
[17:18] <durandal_1707> one from vf_dlopen
[17:34] <kierank> what is vf_dlopen?
[17:36] <durandal_1707> kierank: see https://github.com/mpv-player/mpv/tree/master/TOOLS/vf_dlopen
[17:36] <kierank> oh it's mplayer
[17:42] <saste> michaelni, can you comment on noise removal patch?
[17:43] <saste> also if you could give an explanation of the fact that it seems slower than native, it would be nice
[17:49] <michaelni> saste, ill investigate why noise behaves like this
[17:49] <saste> michaelni, thanks
[17:52] <durandal_1707> mp use myriads of slices
[17:57] <cehoyos> durandal_1707: The mp=telecine filter works fine here, since there is at least one user using it, I would prefer to keep it until ported.
[17:58] <durandal_1707> cehoyos: huh, but how?
[17:59] <cehoyos> You have to set pts with setpts (since the filter only supports contant frame rate, there is no real disadvantage afaict)
[17:59] <durandal_1707> i set it already ...
[17:59] <durandal_1707> cehoyos: so if you have working command line....
[17:59] <cehoyos> I just tested it with a random sample, output looks like expected...
[18:00] <durandal_1707> with ffplay?
[18:02] <cehoyos> I don't know how ffplay could use telecine ?
[18:02] <durandal_1707> i tried with ffmpeg too
[18:04] <cehoyos> Sorry, I tried an installed version, the filter was recently broken, I will open a ticket.
[18:07] <durandal_1707> cehoyos: latest release version works?
[18:09] <cehoyos> 1.1 works, I did not test 1.2 yet, bisecting atm
[18:19] <cehoyos> Regression since a05a44e (not really a surprise, is it?)
[18:19] <ubitux> i guess that's my fault then
[18:20] <nevcairiel> yeah you should've deleted mp instead of porting it :)
[18:20] <ubitux> i haven't ported it
[18:20] <ubitux> i've broke it
[18:23] <cehoyos> nevcairiel: Do you still have a dvb (mpegts) sample that fails with program detection?
[18:24] <cehoyos> Yuvi. Did you receive my email? gas-preprocessor needs an update.
[18:25] <cone-153> ffmpeg.git 03Michael Niedermayer 07master:21f4fc2e400e: avfilter/vf_mp: fix x86 cpu caps
[18:29] <nevcairiel> cehoyos: haven't tried latest HEAD yet, let me check
[18:32] <durandal_1707> repeat after me: libavfilter/libmpcodecs must die
[18:34] <nevcairiel> cehoyos: indeed i do
[18:35] <cehoyos> nevcairiel: Would you mind providing the sample?
[18:37] <nevcairiel> https://docs.google.com/file/d/0Bzo8vvjNtaZ5VDlDSnN0MFozdTQ/edit?usp=sharing
[18:37] <nevcairiel> i tried cutting it before, but somehow that broke it
[18:37] <nevcairiel> so go nuts!
[18:38] <nevcairiel> it has one audio stream that in current git head is in no program, before the regression it was
[18:39] <cehoyos> Did you try cutting it to 100MB (my samples had to be around this size to show the original bug)?
[18:39] <durandal_1707> wow VAG give me link to sample
[18:40] <nevcairiel> cehoyos: yes, in a 100mb sample it still works fine
[18:40] <nevcairiel> no idea why, but it does
[18:41] <nevcairiel> maybe its something at the end of the file which breaks it, when it seeks there to determine the duration
[18:42] <cehoyos> Just so I understand correctly; 100MB is not enough?
[18:42] <nevcairiel> yes
[18:42] <nevcairiel> the first 100 at least not
[18:43] <cehoyos> I am already >200 and still cannot reproduce: Will continue downloading
[18:49] <cehoyos> What is VAG?
[18:53] <durandal_1707> s/what/who
[18:56] <michaelni> ubitux, your coverage page isnt linked from ffmpeg.org or am i missing it ?
[18:57] <ubitux> it isn't
[19:03] <cehoyos> nevcairiel, michaelni: Ticket 2441 opened with the missing sample from ticket 2186
[19:35] <nevcairiel> cehoyos: which part of the file did you cut to make it fail?
[19:37] <nevcairiel> at least it also shows the problem when watching it, the stream assignment changes mid-stream from the finnish to the english track
[19:39] <ubitux> anyone has some >8 bits depth samples lying around?
[19:39] <ubitux> (yuv-like)
[19:39] <nevcairiel> h264 ok?
[19:39] <ubitux> sure
[19:40] <nevcairiel> http://files.1f0.de/samples/H.264-10bit-sample-railgun.mkv
[19:41] <ubitux> thx!
[19:41] <ubitux> animes \o/
[19:41] <nevcairiel> its really the only stuff that uses 10-bit in the consumer world :p
[19:42] <durandal_1707> bbbbluray?
[19:42] <nevcairiel> bluray is 8bit only
[19:43] <ubitux> does it uses the whole bit depth?
[19:43] <durandal_1707> but your monitor can use, say 5.5 depth
[19:44] <ubitux> durandal_1707: we need >8 bit support in vf histogram!
[19:44] <nevcairiel> my monitor has a 10bit panel, tyvm :P
[19:44] <durandal_1707> give me 256x256 width display first
[19:45] <ubitux> :(
[19:45] <durandal_1707> ubitux: i fail to see how addition few pixels will help see obvious issues
[19:47] <durandal_1707> its not that hard, you unlock width for > 8 bit and than just allocate 'width' array size and increase index in each....
[19:49] <durandal_1707> that's for levels mode, other modes like waveform need 2^(9-16) width/height window
[19:52] <durandal_1707> of course if you do not care for such behaviour you could do some kind of aproximation....
[19:52] <durandal_1707> s/behaviour/detail
[19:56] <kierank> nevcairiel: yes but the sources are 8-bit so it's not "really" 10-bit as such
[19:57] <michaelni> durandal_1707, ok if i fix RAND_MAX ?
[19:57] <nevcairiel> kierank: true, however since its lossy encoding i figure there will be useful bits in the 2 extra bits after decoding
[19:57] <kierank> yup
[19:58] <michaelni> durandal_1707, RAND_MAX is the primary cause of the pink pixels
[19:58] <ubitux> btw
[19:58] <ubitux> someone should do something about the ubuntu ppa
[19:58] <durandal_1707> michaelni: i dunno what you want to fix, but if it improves output, sure
[19:58] <ubitux> it's still distributing 0.10...
[19:58] <ubitux> (and nothing more recent)
[19:58] <michaelni> durandal_1707, RAND_MAX is for random() or something av_lfg() has different max
[19:59] <durandal_1707> michaelni: i think i replaced, but i cant remmember
[20:00] <durandal_1707> michaelni: anyway i'm really blind for quality of noise
[20:01] <michaelni> maybe RAND_MAX is also a different value on your platform
[20:01] <michaelni> one that happens to be corerct for lfg
[20:03] <durandal_1707> /usr/include/stdlib.h:#define   RAND_MAX        0x7fffffff
[20:07] <cone-153> ffmpeg.git 03Michael Niedermayer 07master:62447248f3e5: vf_noise: remove low quality mode
[20:07] <cone-153> ffmpeg.git 03Michael Niedermayer 07master:28943c4d31a5: vf_noise: Fix av_lfg_get() maximum value
[20:11] Action: ubitux is too lazy to re-read the pages of doc he's written
[20:12] <durandal_1707> brace yourself
[20:13] Action: ubitux looks ridiculous with wonderbra
[20:14] <ubitux> hey this doc is not that bad.
[20:38] <ubitux> i'm going to push "lavf/http: use a more compatible default user agent." unless someone object
[20:40] <ubitux> also, comments on libquvi ?
[20:40] <ubitux> i'll push it in 3 days if no one raise a hammer
[20:41] <kurosu> http://www.youtube.com/watch?v=1AvULw1mfJA <- that ?
[20:43] <ubitux> sounds reasonable
[20:46] <arkiaz> michaelni: Hi, I am a student and I would like to ask you a question regarding on the GSoC project you mentor. Is it right time for you?
[20:50] <michaelni> arkiaz, sure, what question ?
[20:55] <arkiaz> michaelni: Hi, I am interested in the project you mentor, "Postproc optimizations ". I have some experience with SSE optimization. But I am new to ffmpeg project. So do you think experiance with ffmpeg code is a criterion to apply for your project?
[20:59] <michaelni> normally not but it all depends on if theres someone else who is more qualified and how many slots we will have, and of course the qualification task, ...
[21:01] <ubitux> ...and if we are selected :p
[21:01] <kierank> wow the tfm patch is actually readable
[21:01] <arkiaz> michaelni: OK. next question is, what kind of coding do you use for inline assembly used. I used to work with Visual C++ 2010 and you can see a sample code I wrote before : https://github.com/abidrahmank/MyRoughWork/blob/master/cpp/euclidean_asm.asm#L113 . The style used in ffmpeg is different. 
[21:02] <arkiaz> michaelni: Sorry, i meant coding style.
[21:03] <ubitux> arkiaz: yasm syntax
[21:03] <ubitux> look at the ./libavcodec/x86/*.asm files
[21:04] <arkiaz> ubitux: thank you. I think I am using MASM syntax. Hope their difference is only in style !!
[21:05] <ubitux> we use a lot of macro helpers from the x264 projects
[21:05] <ubitux> it's likely some abstractions will differ
[21:05] <ubitux> but you have a large bunch of references files all around the code base
[21:06] <michaelni> arkiaz, i dont think you need emms in euclidean_SSE
[21:07] <arkiaz> michaelni: since I don't use any floating point calculation ?
[21:07] <nevcairiel> since you dont use the mmx registers
[21:08] <arkiaz> nevcairiel: sorry, I thought emms is used to shift coprocessor to floating point state.
[21:08] <michaelni> EMMS = Empty MMx State IIRC
[21:09] <michaelni> but i might misremember what it stands for :)
[21:09] <nevcairiel> no, its used to clear the floating point registers, which get re-used for 64-bit SIMD (MMX and SSE1)
[21:10] <nevcairiel> but the mmx registers are called "mm0" etc, "xmm0" are the 128-bit sse registers
[21:10] <nevcairiel> dont need emms
[21:12] <arkiaz> michaelni: Since I am new to ffmpeg code base, can you recommend me any function which I can start working with for qualification task?
[21:12] <kierank> ubitux: i thought tivtc was gpl?
[21:13] <ubitux> kierank: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/141346.html
[21:13] <kierank> oh sorry
[21:13] <ubitux> no worry :)
[21:14] <kierank> i look forward to trying that patch out at some point
[21:14] <kierank> and simding it
[21:14] <ubitux> yep
[21:14] <ubitux> decimate is a good candidate for simd as well
[21:15] <cone-153> ffmpeg.git 03Clément BSsch 07master:1fabd9503558: lavf/http: use a more compatible default user agent.
[21:15] <nevcairiel> whoever invented DTS CDs needs to suffer in that special place in hell
[21:16] <nevcairiel> properly supporting .wav files which contain DTS masquerading as PCM was already silly enough, but now people find it humorous to put that into lossless compression like FLAC o.O
[21:16] <arkiaz> nevcairiel: michaelni : You are right, I don't need it for SSE. 
[21:17] <kierank> nevcairiel: lol
[21:17] <nevcairiel> i wonder if the file actually got bigger doing that
[21:18] <arkiaz> michaelni: ubitux : Since I am new to ffmpeg code base, can you recommend me any function which I can start working with for qualification task?
[21:18] <michaelni> the x1 deblock filter maybe
[21:20] <michaelni> its quite a bit simpler than the normal deblock filter
[21:21] <michaelni> but vertX1Filter() alone is maybe to simple/easy 
[21:23] <arkiaz> michaelni: I am sorry, did you mean this one : https://github.com/FFmpeg/FFmpeg/blob/master/libpostproc/postprocess_template.c#L2540?
[21:27] <michaelni> arkiaz, thats do_a_deblock() converting that to AVX2/SSE2 should be ok as qualification
[21:27] <michaelni> AVX2/SSE2 in yasm syntax that is
[21:28] <arkiaz> michaelni: looking for vertX1Filter() turns up this : https://github.com/FFmpeg/FFmpeg/blob/master/libpostproc/postprocess_template.c#L407 ?
[21:29] <michaelni> yes but vertX1Filter is too simple alone, 
[21:29] <ubitux> michaelni: so how did you merge lcov/gcov?
[21:30] <ubitux> our version is dropped?
[21:30] <michaelni> arkiaz, if you want to work on vertX1Filter then you could also do the horizontal X1 one
[21:30] <michaelni> but theres no asm at all for that i think
[21:30] <michaelni> ubitux i droped --enable-coverage yes
[21:30] <michaelni> should we emulate that somehow ?
[21:30] <arkiaz> michaelni: ok. let me have a look on it.
[21:31] <ubitux> michaelni: it's ok, i can update my fate instance
[21:31] <ubitux> michaelni: but OTOH the version from libav has problems...
[21:31] <michaelni> arkiaz, horizontal means vertical asm + transpose in reality probably
[21:31] <ubitux> michaelni: also, there are still some coverage bits, such as coverage-html
[21:32] <michaelni> ubitux, i left the clean stuff intentionally so people updating dont end with dirt left in their tree
[21:32] <ubitux> i think the sed will be required too
[21:32] <michaelni> ubitux, i already merged that 
[21:32] <ubitux> oh you keep it
[21:32] <ubitux> great, you're awesome :)
[21:37] <arkiaz> michaelni: is vertx1filter() a convolution of 8x8 with 3x3 ?
[21:39] <michaelni> arkiaz, you can look at the C code in the #else below the asm to see what it does
[21:39] <arkiaz> ok
[21:40] <ubitux> coverage fixed.
[21:41] <michaelni> ubitux, is there a link to it on the webpage ?
[21:41] <michaelni> we should add one if no
[21:41] <arkiaz> michaelni: thank you for your help. I will work on it and get back to you. 
[21:41] <ubitux> michaelni: as i said, there isn't :p
[21:41] <michaelni> arkiaz, ok, good luck
[21:42] <ubitux> michaelni: you can also make coverage.ffmpeg.org or similar to the ip
[21:42] <ubitux> i can add a vhost
[21:42] <michaelni> ubitux, i cant, arpi can
[21:43] <michaelni> i can mail him, what IP should it be ?
[21:43] <ubitux> 176.9.142.132 i guess
[21:48] <michaelni> mail sent
[21:55] <ubitux> seems to work already
[21:55] <ubitux> michaelni: can you confirm?
[21:55] <nevcairiel> works for me
[21:55] <ubitux> great
[21:56] <michaelni> ubitux, yeah seems working :)
[22:10] <ubitux> michaelni: so, how are we going to add a coverage entry in the menu without exploding the width?
[22:10] <ubitux> we should have added a web gsoc :p
[22:12] <michaelni> thats more something for gci
[23:17] <durandal_1707> i have telecine filter almost working
[23:18] <durandal_1707> i only need to get this pts working
[23:19] <durandal_1707> because mpv use doubles which means afaik: that 2 is 2 seconds in stream
[23:24] <ubitux> durandal_1707: i've done some pts adjustement in decimate
[23:25] <ubitux> it's likely very similar
[23:28] <durandal_1707> i dont see anything, you can try filter in telecine branch
[23:30] <ubitux> in the new decimate filter
[23:31] <ubitux> https://github.com/ubitux/FFmpeg/commit/267face1c9e97046104c95d3a4fba03f364f311e#L3R359
[23:31] <durandal_1707> yes i take looked at it (on ml)
[23:32] <ubitux> fps & ts_unit thing
[23:34] <durandal_1707> well filter set pts from input pts
[23:37] <durandal_1707> it some code that reinit filter when big pts change happen
[23:38] <durandal_1707> and big pts change happen well because is broken (...)
[23:38] <durandal_1707> i just replaced double with int64_t which is plain wrong...
[00:00] --- Sun Apr  7 2013