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

[burek]

[00:24] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:341bd6ec6a8f: avfilter/vf_uspp: use av_malloc_array()
[00:24] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:3d00ba2688f6: swscale/yuv2rgb: fix width % 8 != 0 and rgb/bgr8 output
[00:42] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:3848512d4820: swscale/yuv2rgb: Fix width % 4 != 0 with bgr4/rgb4
[00:42] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:3a2bed1f9ebc: swscale/yuv2rgb: Fix width % 4 != 0 with bgr4_byte/rgb4_byte
[01:49] <llogan> anyone want any benchmarks or whatever on a Xeon E5-2680 v2 @ 2.80GHz?
[03:21] <jamrial> binutils 2.25 is out
[03:22] <jamrial> about time it happened
[03:28] <Daemon404> oh so i can finally build a binutils release with gcc 4.9?
[03:28] <Daemon404> lulz
[03:29] <aetasx> is www.gnu.org down for you guys?
[03:31] <Daemon404> http://www.downforeveryoneorjustme.com/gnu.org
[03:34] <aetasx> wouldn't expect something like that to actually be down
[03:34] <Daemon404> i dunno
[03:35] <Daemon404> usually you end up hearing it ran off a pentium 2 in some guy's basement
[03:50] <Comsn> well 
[03:50] <Comsn> this is usually when sites go down for maint
[03:50] <Comsn> end of the year, during holidays when people are off work...
[03:51] <Daemon404> Comsn, you'd think GNU would be on eastern time though
[03:51] <Daemon404> also i cant tell if you are Compn in disguise or not
[12:21] <arwa> I was running make ffmpeg, and my system suddenly switched off. Now, I am getting errors while running the same command. 
[12:21] <arwa> error: libavcodec/ac3enc.c:2484: error: undefined reference to 'ff_me_cmp_init' 
[12:21] <arwa> What should I do?
[12:26] <kierank> make distclean
[12:38] <wm4> ffmpeg's build system often messes up incremental compilation on updates
[12:57] <cone-985> ffmpeg.git 03Reimar Döffinger 07master:bed78064f4a8: tableprint_vlc.h: Should not be checked by checkheaders.
[13:18] <BBB> wm4: not for me
[13:19] <BBB> (it used to do that a lot, years ago, but not anymore since then)
[13:20] <wm4> had this just some time ago
[13:20] <wm4> usually I just wipe the build dir though
[13:20] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:82d1abc44c5e: avformat/seek: use av_freep() to avoid leaving stale pointers in memory
[13:20] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:ef05af82b275: avformat/rtpproto: Use av_freep() to avoid leaving stale pointers in memory
[13:20] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:3f56224a9a83: avformat/rtpdec_mpeg4: Use av_freep() to avoid leaving stale pointers in memory
[13:20] <JEEBsv> yeah, easier to distclean/rm
[13:20] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:96dce6f7ceaa: avformat/seek: move the cur variable into the loop
[13:20] <nevcairiel> Depends on the changes pulled in
[13:21] <nevcairiel> But yeah it happens sometimes
[13:31] <arwa> thanks :)
[13:43] <kierank> ubitux , arwa, michaelni : sent the ilace replacement patch you asked for
[13:43] <kierank> but needs double checking
[13:47] <kierank> also my next question is: can libavfilter support a custom allocator?
[13:49] <nevcairiel> Don't think so, no
[13:49] <nevcairiel> Not at this time anyway
[13:50] <kierank> bugger
[13:50] <wm4> kierank: what for?
[13:50] <kierank> so I can filter straight into hardware
[13:50] <wm4> and that memcpy kills you?
[13:51] <wm4> I think internally it would allow for it
[13:51] <kierank> it's at the top of the profiler, yes
[13:51] <wm4> I faintly remember how mplayer attempted to connect it to its own direct rendering
[13:51] <wm4> though that API isn't public anymore
[13:52] <nevcairiel> Currently, the only way to hook up custom buffers is a codec context, which is only used by the decoders unfortunately
[13:53] <wm4> might be nice to have an API for this... and to use this API to also make lavfi allocate out of a memory pool
[13:53] <nevcairiel> Not sure if there even is a central lavfi way to even get it in somehow
[13:53] <wm4> (well I guess this API would be a single callback)
[14:01] <wm4> kierank: so does this mean this vf_ilpack filter is not needed?
[14:09] <aetasx> hey guys, I was reading this: https://gcc.gnu.org/ml/gcc-help/2003-08/msg00128.html   Think there's any reason it wouldn't work against ffmpeg?
[14:11] <wm4> ffmpeg keeps all codecs etc. in a big list, so no
[14:12] <aetasx> yeah but considering the list is built on configuration and use ifdefs to actually add them in
[14:14] <wm4> then the disabled codecs aren't even built
[14:14] <aetasx> as long as there are references to the data and functions in the code, they won't be removed
[14:16] <wm4> but there aren't
[14:16] <aetasx> if its a static build, then how is ffmpeg supposed to call functions it has no references to?
[14:16] <wm4> the amount of code dropped would probably be minimal, or handled by the linker already
[14:17] <aetasx> Im more interested in the libs that get included in
[14:36] <kierank> wm4: in principle yes
[14:37] <anshul_mahe> is there already any macro to define max int size
[14:38] <wm4> anshul_mahe: INTMAX_MAX?
[14:38] <wm4> anshul_mahe: in what context?
[14:39] <anshul_mahe> I want a unsigned variable to be define at its max value
[14:40] <wm4> UINT_MAX?
[14:40] <wm4> or just (unsigned type)-1
[14:42] <anshul_mahe> wm4: thanks
[14:52] <allengates> how can compile ffmpeg(vs2013) with non optimization just like debug configuration in visual studio?
[14:55] <nevcairiel> You cannot
[14:55] <nevcairiel> FFmpeg cannot be built globally without optimization
[14:56] <compn> allengates : i guess what nevcairiel is saying is try to build it in mingw with debug, and then you can make gdb backtrace...
[14:57] <nevcairiel> No compn
[14:57] <compn> no? --disable-asm and all that ?
[14:57] <compn> he means cpu optimizations
[14:57] <nevcairiel> GCC builds have the same limitation. You cannot build it without optimizations
[14:58] <compn> you can build it without cpu optimizations , people do it frequently to test c-version of code
[14:58] <nevcairiel> That's absolutely not what he wants
[14:59] <nevcairiel> You can already turn those off with a command line switch when running FFmpeg, no need to build without them
[15:00] <wm4> ffmpeg requires the compiler to perform dead code optimization
[15:00] <wm4> it's a retarded "simplification"
[15:00] <anshul_mahe> isnt --disable-optimizations flag work well
[15:00] <nevcairiel> Which many compilers don't have a dedicated switch for, so you need to enable a basic level of all sorts of optimizations
[15:02] <compn> allengates : so you want --disable-optimizations
[15:02] <compn> and ask in #ffmpeg , this is an #ffmpeg question 
[15:02] <nevcairiel> That doesn't change anything
[15:02] <compn> i think...
[15:03] <nevcairiel> Please stop spreading info you have no clue about :P
[15:03] <nevcairiel> You cannot disable optimizations in a MSVC build, period.
[15:04] <nevcairiel> What you can do is disable optimizations in select pieces of code while you're working on it with compiler pragmas
[15:04] <nevcairiel> But not globally
[15:05] <anshul_mahe> I was just asking, I have not done lot of work in windows msvc
[15:06] <nevcairiel> Like wm4 said, you need dead code elimination to work, or builds will fail. Full debug builds do not perform DCE.
[15:07] <wm4> it does stuff like: if(HAVE_X86)some_x86_function();
[15:07] <nevcairiel> So what I usually do is simply turn off optimizations for the file I work on with a pragma
[15:07] <wm4> HAVE_X86 will be 0 on platforms other than x86, so this code compiles on platforms that don't implement some_x86_function()
[15:08] <nevcairiel> #pragma optimization("", off)
[15:08] <nevcairiel> iirx
[15:08] <wm4> if dead code elimination is off, the compiler will emit a reference to some_x86_function() anyway
[15:08] <nevcairiel> iirc*
[15:08] <wm4> there's also such a pragma for gcc
[15:09] <anshul_mahe> sry it would be guesssing rather asking, if i reread my comment
[15:09] <nevcairiel> If this particular file needs DCE (which many luckily don't), I just comment out that part:D
[15:13] <cone-985> ffmpeg.git 03Clément BSsch 07master:f6950a077cd4: avfilter/showwaves: use INT16_MAX instead of a self defined macro
[15:13] <cone-985> ffmpeg.git 03Clément BSsch 07master:ecafde6606a5: avfilter/showwaves: fix height range for cline mode
[15:14] <allengates> what I want is make all O3 O2 O2 to O0
[15:14] <allengates> I can do that in mingw and linux
[15:15] <allengates> I am now want to build under visual studio just like O0 under linux gcc.
[15:16] <allengates> because I need single step and all local vars's values, I am studying ffmpeg's source code.
[15:17] <anshul_mahe> for studying why not linux or mingw?
[15:17] <wm4> allengates: read what we wrote
[15:18] <allengates> ok
[15:20] <ubitux> kierank: thank you :)
[15:20] <kierank> ubitux: it's wrong i think still
[15:20] <wm4> the mysteries of interlacing
[15:34] <arwa> I did git pull --rebase. All of the unmerged commits got deleted. Is there any way to get it back?
[15:42] <wm4> arwa: git reflog
[15:42] <wm4> arwa: the first column shows the commit hash, you can pass it to git log or git branch
[15:43] <wm4> but you still have to find out manually which was the last good one
[15:43] <wm4> also I wonder if git pull --rebase has measures to recover from a botched rebase, but I don't know
[15:51] <anshul_mahe> where is logic of reading 33 bit pts from pes packet defined, i want to read 33 bit pts offset 
[15:52] <anshul_mahe> in scte-35 impementation
[15:52] <anshul_mahe> if there is not, should i use bitstream for 32 bit one time and 1 bit next
[15:56] <anshul_mahe> ohh, i got get_bits64 it wil work fine 4 me
[15:57] <kierank> iirc in the ts demux it's done without get_bits
[15:57] <kierank> but i forget
[15:58] <kierank> ff_parse_pes_pts
[16:02] <anshul_mahe> kierank: I did forgot about those null bits(guard bits) in between pes pts, because of which i was thinking to use same function for pts offset in pts
[16:03] <anshul_mahe> get_bits64 looks fine for my case 
[16:04] <arwa> Okay, thanks! but the files are missing :/
[16:06] <kierank> anshul_mahe: what are you going to do with the scte35 data?
[16:15] <beastd> arwa: files should not be missing. were they committed before? if they weren't git doesn't touch them. if they were just added to the index, git pull --rebase should have aborted and told you to commit or stash your changes.
[16:20] <beastd> "git stash list" will show you if you have stashed something. with "git show stash@{n}" you can look at your stashed stuff.
[16:21] <kierank> would be nice if http://www.ffmpeg.org/doxygen/1.1/vf__ilpack_8c_source.html explained where they hell the filter coeffs come from
[16:23] <anshul_mahe> kierank:in ffmpeg I will make an xml file, which will act as feed back to the program who is providing audio and video to ffmpeg
[16:23] <wm4> kierank: haha, you have some expectations
[16:24] <wm4> kierank: vf_ilpack was added by Rich Felker, he's on freenode under the nick dalias
[16:24] <wm4> kierank: maybe you can ask him
[16:25] <kierank> well they are wrong coefficient
[16:25] <kierank> s
[16:25] <kierank> afaik
[16:30] <kierank> anshul_mahe: why can't you just export the data as a packet
[16:30] <kierank> instead of that horrid hack
[16:42] <anshul__> kierank: with this way, it would be easy to solve https://trac.ffmpeg.org/ticket/3356
[16:42] <cone-985> ffmpeg.git 03Arwa Arif 07master:bdc4db0ee356: lavfi: port mp=fspp to a native libavfilter filter
[16:42] <cone-985> ffmpeg.git 03Stefano Sabatini 07master:a51c78c65d59: lavfi/mp: drop mp=fspp filter
[16:44] <saste> arwa, what's next? :-)
[16:44] <arwa> I have already written the pp7 code
[16:44] <saste> arwa, good
[16:45] <arwa> I have tested it with mp=pp7 also, its giving same ouput.
[16:45] <compn> arwa : you're working too hard
[16:45] <compn> :)
[16:45] <saste> then there is the chroma interlacing stuff with kierank I suppose
[16:45] <compn> ffmpeg xmas present, mp filters all removed :P
[16:45] <arwa> :)
[16:46] <saste> arwa: then PP filters comparison
[16:46] <saste> but you can choose the order you prefer, or work on several tasks at the same time
[16:46] <saste> probably for PP you can edit a wiki page
[16:47] <arwa> Okay, I will edit the wiki page along with the chroma interlacing.
[16:47] <saste> ideally you should come with a loq-quality compressed test image and show how the various filters improves the output
[16:47] <saste> *low-quality
[16:48] <arwa> Yeah, I was going through one of the sites - http://www.compression.ru/video/deblocking/index_en.html
[16:48] <saste> also testing how the various PP filters differ in term of speed would be nice
[16:48] <arwa> Should I follow this pattern?
[16:48] <arwa> How do I test in terms of speed?
[16:49] <saste> arwa, ffmpeg -benchmark -i ... -vf pp=... out
[16:50] <arwa> Also, I am all confused with git!  I did git pull --rebase, and all of my files are deleted!
[16:50] <arwa> okay, thanks :)
[16:50] <saste> arwa, about git, that shouldn't happen
[16:51] <saste> arwa, anyway git is hard to tame, so that's a bit expected
[16:51] <saste> I suggest you to work on a topic branch, for example
[16:51] <saste> git checkout -b port-mp-pp7-filter
[16:51] <saste> then you work on that branch
[16:52] <saste> when you have to rebase you do:
[16:52] <saste> git co master
[16:52] <saste> git pull --rebase
[16:52] <saste> git co BRANCH
[16:52] <saste> git pull rebase
[16:52] <saste> usually I don't expect you should find many conflicts
[16:52] <saste> the only often conflicting file is version.h
[16:53] <saste> so I usually just edit it when I'm ready to commit
[16:53] <beastd> saste, arwa: I find it a bit hard too believe that the files vanished. maybe someone can paste my 2 messages from before.
[16:54] <arwa> okay, thanks :)
[16:55] <arwa> Well, actually, I tried a lot of commands :P
[16:55] <arwa> Maybe that's why the files are missing.
[16:55] <saste> arwa, also, we have doc/git-howto.texi
[16:55] <saste> we miss to cover the case when there are conflicts to handle
[16:59] <anshul_mahe> kierank: are u Krieger?
[16:59] <arwa> Right now, should I make the delete mp = fspp patch? or should I first try to resolve the version error?
[16:59] <compn> kierank is kieran k.
[17:01] <wm4> arwa: as long as you committed the files at some point, they won't be gone, unless you use some of the aggressive gc commands, or wipe the .git dir
[17:01] <arwa> I deleted files from .git . :/
[17:02] <arwa> But that was what I read from internet!
[17:02] <wm4> there's lots of dumb stuff written on the internet
[17:03] <wm4> arwa: where do they suggest to delete files from .git?
[17:03] <arwa> rebase-merge I guess
[17:04] <wm4> I mean, git rarely deletes something
[17:04] <wm4> git rebase rewrites commit, right?
[17:04] <wm4> but it actually creates new commits based on old commits
[17:04] <wm4> and the old commits are never deleted
[17:04] <wm4> (well, they are deleted, if they are unreferenced and older than 2 weeks, or whatever is the default time limit)
[17:05] <wm4> so if you lost important data, and if you actually committed it at some point, you should be able to find it again with "git reflog"
[17:06] <wm4> although "git reflog" isn't the most user-friendly thing either (you basically have to search it manually...)
[17:06] <arwa> I tried that too!
[17:08] <arwa> Its all getting messed up :/
[17:08] <beastd> wm4: iirc expiration is more than a month by default. 90 days or so
[17:09] <arwa> I am thinking of cloning the repo again, and starting afresh.
[17:10] <kierank> anshul_mahe: yes but stream switching is something that a higher level program should do
[17:11] <kierank> michaelni: see pg15 of the mpeg-2 spec
[17:13] <kierank> anyway the offsets should probably just be made positive
[17:13] <anshul_mahe> kierank: I am not switching stream i am just transcoding it to xml, in hls case writing that info in m3u8 file
[17:15] <anshul_mahe> kierank: I dont have any refrence transcoder, which handle this stuff, I am just referring scte-67 for this
[17:15] <kierank> ok
[17:15] <anshul_mahe> kierank: if you have seen this working somewhere, guide me what should I do 
[17:16] <kierank> well fundamentally the problem is you cant put the kitchen sink into ffmpeg and expect it to be clean
[17:18] <kierank> michaelni: ping
[17:19] <anshul_mahe> I dont understand gurbish,can you give me some hint why you feel so bad about it, what would be the problem that would be coused by it 
[17:20] <wm4> arwa: IMO the safest is to work in a branch, without ever merging or rebasing with master (or only doing that if you must)
[17:21] <michaelni> kierank, pg15 of the mpeg2 spec i have well its a word document rendered in libreoffice but that page is basically empty
[17:21] <kierank> michaelni: what is the swscale luma grid measured relative to?
[17:21] <kierank> is a luma sample located at 0, 255, etc
[17:21] <kierank> ?
[17:22] <kierank> michaelni: figure 6-3?
[17:28] <michaelni> i think luma would be at 0
[17:28] <kierank> and the next sample?
[17:28] <michaelni> next luma at 256 i think
[17:30] <kierank> ok
[17:30] <michaelni> yes 6-3 is there, i know that one, its also in mpeg4
[17:30] <kierank> so you see how the chroma of the first temporal field is different
[17:31] <kierank> so the sws_ctx has to be the correct one
[17:31] <wm4> arwa: also, before you do something "risky" like rebasing or merging, always commit everything (don't forget to "git add" new files), and maybe "remember" the current commit by using "git branch" to create a new branch (or just write down the commit hash)
[17:31] <kierank> (yes also the -64 should be a +192)
[17:31] <wm4> arwa: then it'll be easy to go back to the old state
[17:36] <michaelni> kierank,  the field with (link->h+1)/2 must always be the top/upper field because with odd height frames the lower can never have 1 line more than the upper
[17:37] <michaelni> i suspect the code is correct before the 2nd hunk but i might be missing something
[17:37] <kierank> michaelni: you are mixing and matching top/upper/lower so it's unclear
[17:38] <kierank> all that matters is first field and second field
[17:38] <michaelni> scale->isws[0] is the top field, (link->h+1)/2 is the top field
[17:38] <thardin> god jul!
[17:38] <kierank> michaelni: no 
[17:39] <kierank> line[0] could legitimately be the bottom field
[17:40] <michaelni> not in ffmpeg
[17:40] <michaelni> nor libavcodec
[17:40] <michaelni> well, if you crop yes it could
[17:41] <michaelni> or if the image is vertically flipped
[17:42] <kierank> ok if line[0] is restricted to be the top field (this is good but not documented...)
[17:42] <kierank> then yes the code needs changing
[17:45] <michaelni> well i guess it is that way when output from the decoder, filters like crop/flip could change that and ideally we should keep track of that when it has been changed
[17:47] <kierank> ok, i don't care much for bff anyway
[17:50] Action: Daemon404 is confused why there is a way to flag tff/bff in the ctx if output is always tff
[17:50] <michaelni> top_field_first is for the temporal ordering of the 2 fields
[17:51] <kierank> Daemon404: encoders need to know
[17:51] <Daemon404> michaelni, oh temporal
[17:51] <kierank> Daemon404: i thought it was the same as you thought
[17:51] <kierank> data layout
[17:52] <kierank> also i might send a patch for progressive chroma to be in the centre
[17:52] <kierank> and i'll get all the videophiles complaining at e
[17:52] <kierank> me
[17:52] <michaelni> line[0] is always spatially above lone[1] so frame can easily be displayed on a progressive display
[18:05] <BBB> you know what would be really awesome?
[18:06] <BBB> some yasm macro to interleave the output of other macros
[18:06] <BBB> like lets say I have a 10-instruction macro and I can it twice
[18:06] <BBB> now its non-interleaved
[18:06] <BBB> I want to interleave it
[18:06] <BBB> pengvado: is that possible?
[18:06] <BBB> (s/can/call/)
[18:22] <kierank> ok so vf_iilpack is right
[18:22] <kierank> and avisynth is wrong
[18:25] <BBB> ubitux: I shaved ~30 cycles off filter16 with one change (see github)
[18:26] <BBB> that was pretty sweet
[19:18] <ubitux> BBB: oh cool
[19:19] <ubitux> BBB: and yeah the auto interleaving macros would be nice
[19:45] <cone-985> ffmpeg.git 03James Almer 07master:b94e85453e90: avfilter/vf_fspp: add missing inline asm guards
[22:41] <canbal> When I transcode an aac file in a loop using fdk-aac decoder and encoder, I start getting a delay at the beginning (0 pcm samples) and size of the file expands. This doesnt happen with native ffmpeg decoder + faac. It still happens with fdk-aac-dec+faac or aacdec+fdk-aac-enc. Is this a bug, or am I missing something?
[22:52] <nevcairiel> Its quite possible some delay thing isn't handled properly.
[22:53] <nevcairiel> For decoding, I would advice yo always stick to the native decoder
[22:57] <canbal> nevcairiel: Im suspecting a delay issue as well but I dont understand the aac technology enough to dig down into fdk-aac codebase
[00:00] --- Thu Dec 25 2014