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

[burek]

[00:29] <ezekiel> I spoke too soon - seems that one way the audio is always ahead of video, and the other way audio is always behind
[04:49] <cone-697> ffmpeg.git 03Michael Niedermayer 07master:e42028925bdd: ffmpeg: Force a first_pts of 0 for the first configuration of -async use
[04:49] <cone-697> ffmpeg.git 03Michael Niedermayer 07master:7f2ab129b19c: fate: force a first_pts=0 for the aresample test
[04:49] <cone-697> ffmpeg.git 03Michael Niedermayer 07master:35aaa306ac2d: swr: make the default of nopts for first_pts actually work
[04:49] <cone-697> ffmpeg.git 03Michael Niedermayer 07master:bb7bc3443dd9: af_biquads: memset(0) cache
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:fcd0e3235ad1: h264: Detect POC inconsistencies and try to handle them reasonably
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:cc64871bd86b: movenc: hotfix, dont store fiel for h264 / mpeg4-asp / dnxhd
[05:41] <cone-697> ffmpeg.git 03Diego Biurrun 07release/1.0:02f241d1ed10: configure: Make warnings from -Wreturn-type fatal errors
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:97a740acc587: aac: reconfigure output on pop
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:c69709571af2: doc/APIchanges: fix odd .01 versions
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:5877811b0f13: apichanges: fix date
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:3a21007e4706: apichanges: Use , instead of / to seperate multiple hashes
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:ab70fa28f665: apichanges: fix 2 wrong hashes
[05:41] <cone-697> ffmpeg.git 03Michael Niedermayer 07release/1.0:8cfd33fd3504: doc/APIchanges: List merge commit hashes and version numbers
[10:50] <ubitux> durandal_1707: Unable to open iconv context with input character encoding "cp1251"
[10:50] <ubitux> not sure how i'm supposed to disable the test if the iconv hasn't the cp1251 support
[10:54] <ubitux> i could add a specific flag in the configure using iconv -l, but that's a bit ugly
[10:58] <durandal_1707> why i cant run separate lavfi test?
[10:58] <ubitux> what do you mean?
[10:59] <durandal_1707> make fate-lavfi-lut
[11:03] <durandal_1707> why simple padding filter depends on drawutils?
[11:04] <durandal_1707> and why drawutils is designed to badly that it never cared for >8 bit colors
[11:07] <ubitux> 10:59:16 <@durandal_1707> make fate-lavfi-lut // make fate-lavfi-{crop,field,...} work here
[11:07] <ubitux> i don't see any lut test though
[11:08] <ubitux> if you're adding one, depending on where you do it, you may need to re-run configure (or add it to a list, i think that changed a while ago)
[11:54] <durandal_1707> michaelni: exr test is blocker because of missing rgba64 output
[11:54] <durandal_1707> that is stupid
[11:55] <durandal_1707> rgba64 is just rgb48 with alpha plane
[11:59] <cone-644> ffmpeg.git 03James Almer 07release/1.0:e6324ccfbd8e: latmenc: Check for LOAS sync word
[11:59] <cone-644> ffmpeg.git 03James Almer 07release/1.0:62e55034077d: lavc/bink: Chech for malloc failure
[12:12] <cone-644> ffmpeg.git 03James Almer 07release/1.1:8d3bc52acd64: latmenc: Check for LOAS sync word
[12:12] <cone-644> ffmpeg.git 03James Almer 07release/1.1:5fb5ac71488c: doc/Makefile: Fix make docclean
[12:12] <cone-644> ffmpeg.git 03James Almer 07release/1.1:d92a7870d74e: lavc/bink: Chech for malloc failure
[12:15] <durandal_1707> so alpha is just copied
[12:30] <cone-644> ffmpeg.git 03Diego Biurrun 07master:3d035d5a6a91: dsputil_alpha.h: Add missing stddef.h header to fix standalone compilation
[12:31] <cone-644> ffmpeg.git 03Michael Niedermayer 07master:11dcecfcca0e: vorbisdec: Error on bark_map_size equal to 0.
[12:31] <cone-644> ffmpeg.git 03Michael Niedermayer 07master:cb72f698fe5d: Merge commit '11dcecfcca0eca1a571792c4fa3c21fb2cfddddc'
[12:36] <cone-644> ffmpeg.git 03Luca Barbato 07master:fc386f2eea8d: vorbisdec: cosmetics
[12:36] <cone-644> ffmpeg.git 03Michael Niedermayer 07master:a0312a2e8531: Merge commit 'fc386f2eea8d93ecd4f81e1646c835d1645c56a0'
[12:57] <cone-644> ffmpeg.git 03Luca Barbato 07master:5b47c19bfda9: vorbisdec: Add missing checks
[12:57] <cone-644> ffmpeg.git 03Michael Niedermayer 07master:f7dc6aa5fecf: Merge commit '5b47c19bfda92273ae49e83db26a565afcaed80a'
[13:13] <cone-644> ffmpeg.git 03Luca Barbato 07master:23bd9ef4b209: vorbisdec: Accept 0 amplitude_bits
[13:13] <cone-644> ffmpeg.git 03Michael Niedermayer 07master:875f88318506: Merge remote-tracking branch 'qatar/master'
[13:58] <cone-644> ffmpeg.git 03Paul B Mahol 07master:eac93932b011: lavfi/geq: improve support for formats with alpha plane
[14:13] <cone-644> ffmpeg.git 03Paul B Mahol 07master:e0ccb5fa38dd: lavfi/hflip: support more formats
[14:19] <cone-644> ffmpeg.git 03Paul B Mahol 07master:b8f6912816d2: fate: update pixfmts_hflip
[14:38] <bgmarete>  Hello all. On GIT Tip, ffprobe ignore the "-ar" command line parameter while ffmpeg uses it.
[14:41] <bgmarete> Is Stefano Sabatini online?
[14:46] <ubitux> not now
[14:46] <ubitux> -ar makes no sense for ffprobe
[14:50] <bgmarete> ubitux: Why not? If you do -show_format you will frequently need "-ar"
[14:51] <ubitux> i wonder why
[14:51] <bgmarete> (Otherwise you could get the default smaple rate, for alaw files, for example (which is set at 44.1k), which is not correct.
[14:52] <bgmarete> I mean not correct for the vast majority of alaw files (which are usually telcom-grade 8k samples).
[14:53] <ubitux> mmh ok, i didn't have this in mind
[14:54] <bgmarete> In a case such as this, in  addition to mis-detecting the sample rate, ffprobe must also mis-detect the file length, giving a length that is 44.1/8 times to small. (This is all with regard to -show_format).
[14:56] <bgmarete> ubitux: Are you familiar with the code-base so that you can point me in the direction of quickly adding "-ar" to ffprobe?
[14:59] <ubitux> ffprobe.c :p
[15:03] <Compn> bgmarete : can you upload a sample of a misdetected alaw file
[15:03] <Compn> its possible we can fix, but also we can add -ar to ffprobe too
[15:04] <bgmarete> Compn: As it happens, that'
[15:04] <ubitux> afaik it's just pcm data so you can't actually detect anything
[15:05] <bgmarete> Compn: As it happens, that's rather easy.  All the asterisk ALAW samples in http://downloads.asterisk.org/pub/telephony/sounds/asterisk-core-sounds-en-alaw-current.tar.gz are mis-detected as 44.1k samples, while they are all 8k samples.
[15:07] <bgmarete> ubitux: I think that's right. Another way to look at it is this: Does the 44.1k default make sense for alaw? In any case, ffrobe does need to respect "-ar".
[15:26] <durandal_1707> isn't point of ffprobe to probe and not to need user input?
[15:27] <nevcairiel> some raw formats just need user input to work
[15:27] <nevcairiel> or it assumes defaults
[15:30] <durandal_1707> than it is easy to change defaults for alaw files
[15:31] <durandal_1707> currenly alaw files are not detected at all using extension (only "al" one works)
[15:34] <durandal_1707> michaelni: gonna help/comment  on that rgba64 patch?
[16:25] <bgmarete> durandal_1707 and others: It should work like this: "-ar" and similar flags must be allowed for raw formats for which there is no hope of detection without this hint from the user. (A similar situation, this time with regard to size and framerate, occurs for raw video). But if FFprobe detects a more reliable value, then it should override this user input (this will never happen in the case of raw formats).
[16:26] <bgmarete> durandal_1707: Changing the default does not solve the problem. There are valid alaw files with sample rate 44.1k.
[18:10] <durandal_1707> i think than printf in code should be disabled again
[18:17] <ubitux> i also agree with the macro being great to prevent from using the internal versions
[18:22] <durandal_1707> ubitux: my intentions are more evil, less people would hack on code when they found that their printf hack cant compile
[18:22] <ubitux> :D
[18:22] <ubitux> #define printf segmentation_fault
[18:38] <durandal_1707> this evil plane in lavfi is ugly
[18:40] <cone-231> ffmpeg.git 03Michael Niedermayer 07master:a960f3b91876: pmpdec: fix integer overflow
[18:40] <cone-231> ffmpeg.git 03Michael Niedermayer 07master:e6f27346b752: pmpdec: make i unsigned, avoid undefined behavior of i++
[18:40] <cone-231> ffmpeg.git 03Jean First 07master:af0e8144cd8b: ffmpeg_opt: cosmetics
[18:41] <durandal_1707> michaelni: how evil will be merged?
[18:44] <nevcairiel> "carefully"
[19:19] <durandal_1707> can we just ban morons on libav-user@ ?
[19:26] <Compn> ask lou
[19:26] <nevcairiel> sadly, stupidity is usually not reason enough to ban
[19:29] <durandal_1707> nevcairiel: :(
[19:34] <Compn> killfile those posters ? 
[20:02] <saste> durandal_1707, ubitux, michaelni: comments on the partial overlay support patch?
[20:04] <saste> it somehow affects performances, so i'd like someone to comment on it
[20:04] <durandal_1707> saste: if it works, valgrind is happy, it should be ok
[20:04] <saste> performances
[20:04] <durandal_1707> saste: at what order performance is affected?
[20:05] <saste> it loops on non overlayed pixels
[20:05] <saste> i could avoid that, but that would complicate the logic
[20:05] <durandal_1707> and how much that hurts?
[20:05] <ubitux> instead of some "continue", can't you break to save some useless loops when it goes outbound?
[20:06] <saste> since I would have to compute the non-clipped segments
[20:06] <saste> ubitux, no
[20:06] <ubitux> k
[20:06] <saste> consider an overlay image bigger than the main input
[20:08] <ubitux> if (y+i < 0 || y+i >= dst_height) continue;  here it looks like you could break if(y+i>=dst_height) (since i will only increment)
[20:08] <ubitux> and for the y+i<0 maybe start the loop later
[20:08] <ubitux> or i'm missing something?
[20:24] <durandal_1707> please avoid potato programming at all cost
[20:27] <durandal_1707> what about this auto-vectorisation? does that mean we can finally ditch all this (inline) asm code?
[20:28] <saste> durandal_1707, potato programming?
[20:31] <Compn> durandal_1707 : dont look at all of those mips optimizations ;)
[20:31] <durandal_1707> saste: extremly unreadabe/unmaintainable/unextendable/ugly code
[20:31] <durandal_1707> Compn: i had enough of swscale today
[20:32] <Compn> libav is thinking of rewriting it
[20:32] <Compn> i wonder if michaelni would be interested in splitting it up ? or if that would help durandal_1707 ?
[20:33] <durandal_1707> it is already splitted for no much gain
[20:33] <Compn> i'm guessing an indent wouldnt help either
[20:34] <Compn> just the mix of inline asm, no easy way to add formats ? and hard to decipher ?
[20:34] <durandal_1707> it is already beautifully looking only on your screen
[20:34] <Compn> i mean, what do you suggest be done to it ?
[20:34] <Compn> change inline to seperate .asm ?
[20:35] <durandal_1707> it's not about inline
[20:35] <Compn> i'm not trolling, but i want to make a bugreport out of this , once and for all :)
[20:36] <durandal_1707> it needs more structures and comments
[20:38] <michaelni> yes, also some factorization in some areas, avoid overuse of macros
[20:40] <michaelni> and various other things, it would be great if BBB would resume working on it
[20:44] <saste> ubitux, gsoc tasks to propose?
[20:44] <saste> maybe related to subtitles or filters?
[20:45] <ubitux> saste: i've been wondering about it; i don't actually want to propose an impossible task such as "subtitles in lavfi" which will require quite a big amount of work
[20:46] <ubitux> and making it a "work with other dev" thing will inspire the "dev will only give me the shit they don't want to do"
[20:46] <ubitux> i've been thinking of adding formats though
[20:46] <saste> ubitux, yes
[20:46] <saste> we lack some image formats for example
[20:46] <ubitux> like the .SUP thing (which is the bluray equivalent of VobSub afaik)
[20:47] <saste> also some work on ffserver or telecine filters would be welcome
[20:47] <saste> i don't think i'll mentor more than one task
[20:47] <ubitux> yes i can propose such stuff, but i can't really be a mentor on it
[20:48] <saste> ubitux, imho not much point in proposing projects one can't mentor
[20:48] <saste> we already have enough of them
[20:49] <ubitux> yes, that's the reason i didn't add it
[20:49] <ubitux> i can mentor the port of some filters
[20:49] <ubitux> typically, the port of eq filter
[20:51] <cone-231> ffmpeg.git 03slhck 07master:188947c32ad6: libvpx: allow 0 as min quantizer value
[20:51] <cone-231> ffmpeg.git 03slhck 07master:bfcc38ef4815: libvpx: check if CQ level is in correct bounds
[20:52] <michaelni> ubitux, iam not sure gsoc allows "work with other dev" 
[20:52] <ubitux> ok, that closes the case then
[20:53] <Compn> .sup is vobsub i think
[20:53] <Compn> er
[20:53] <Compn> i mean
[20:53] <Compn> .sup is bluray subs i think
[20:53] <michaelni> merbanan, do you want to mentor some tasks in ffmpeg gsoc ?
[20:53] <michaelni> if so dont hesitate to add them to the wiki
[20:54] <Compn> anyone interested in mentoring gotomeeting ?
[20:54] <Compn> maybe j-b knows someone ?
[20:54] <Compn> a gotomeeting decoder that is
[20:55] <ubitux> 20:53:35 <@Compn> .sup is bluray subs i think // yeah, exactly what i said
[20:55] <Compn> yeah i misread the whole thing :D
[20:55] Action: Compn brain fart
[21:00] <Skyler_> any chance I can be taken off the consulting page?  I'm getting way too many emails and don't really have the time or sanity atm
[21:02] <saste> Skyler_, send patch
[21:02] <durandal_1707> :))
[21:03] <Skyler_> :/
[21:03] <durandal_1707> i could also mentor RE gsoc task (the one noone will pick)
[21:03] <saste> Skyler_, btw who are you?
[21:04] Action: Skyler_ Jason
[21:04] <saste> ok
[21:06] <Compn> Skyler_ : i can, but who am i removing ?
[21:07] <durandal_1707> michaelni: ping on RGBA64 output, exr fate test is "blocked" because of this
[21:08] <Compn> Skyler_ : oh wheres dark_shikari ? :P
[21:10] <Compn> Skyler_ : removed. site updated
[21:10] Action: Compn afk
[21:12] <Skyler_> Thanks
[21:26] <durandal_1707> what mjpegtools filters is worth porting?
[21:28] <Compn> what filters are there to choose from ?
[21:29] <Compn> got a list ?
[21:35] <durandal_1707> nothing important that is not already in lavfi
[21:36] <saste> durandal_1707, do you have a link to a list?
[21:37] <durandal_1707> source code
[21:37] <Compn> durandal_1707 : looks like most people want deinterlacing filters
[21:38] <Compn> or ivtc i should say
[21:38] <durandal_1707> than add it as main tasl
[21:38] <durandal_1707> *task
[21:38] <saste> lavplay
[21:38] <saste> i didn't know mjpegtools had a tool named like that
[21:43] <durandal_1707> saste: i have started writing jellyfish meter avf filter
[21:44] Action: durandal_1707 wonders when vaf filter will appear
[21:49] <Compn> theres a bunch of mplayer audio filters
[21:49] <Compn> which ones are useful? pan, hrtf , volnorm , karaoke 
[21:49] <Compn> people want volume normalizer :P
[21:49] <wm4> does libavformat give any indication whether the file format may employ wrapping timestamps or timestamp resets?
[21:49] <wm4> Compn: none
[21:50] <wm4> Compn: I think lavfi can do everything by now
[21:50] <Compn> wm4 : you removed them from your fork then ?
[21:50] <wm4> no
[21:50] <Compn> ...
[21:50] <wm4> no lavfi support yet
[21:50] <wm4> waiting for the evil plan
[21:50] <wm4> but I can assure you most of the mplayer code is very low quality
[21:51] <wm4> :)
[21:51] <Compn> do you know of any video filters that should be added ?
[21:51] <Compn> to lavfi
[21:51] <wm4> uh well ffmpeg ported almost all mplayer video filters
[21:52] <wm4> other than that, they could look at the avinsynth universe
[21:52] <durandal_1707> Compn: any gimp one
[21:52] <wm4> *avisynth
[21:52] <durandal_1707> the only big/important filter left is stereo3d
[21:53] <durandal_1707> and emboss
[21:53] <durandal_1707> posterize too
[21:54] <wm4> how about a working ivtc filter
[21:54] <wm4> or a deinterlacer that's not from the previous decade
[21:55] <durandal_1707> than there almost completly unexplored field of image analysis 
[21:56] <durandal_1707> like for remote sense
[21:56] <Compn> durandal_1707 : someone was asking about a skin color smoother or something :P
[21:56] <Compn> so yeah, the ability to use gimp or photoshop filters on video would be fun
[21:58] <Compn> sony working on 4k h265 ?
[22:00] <durandal_1707> Compn: what "skin color smoother" means?
[22:01] <ubitux> 21:49:33 <@Compn> people want volume normalizer :P // i'm somehow working on it
[22:01] <ubitux> i need to get it done
[22:01] <Skyler_> 'smart blur' probably?
[22:02] <ubitux> smartblur is already ported afaik
[22:03] <Compn> durandal_1707 : no idea , probably he meant airbrushing or something 
[22:03] <durandal_1707> but shape adaptive blur isn't
[22:04] <Compn> i dont even know if people use sab/smartblur
[22:05] <Skyler_> I use it on photos at least, it's good to get rid of ISO noise
[22:05] <Skyler_> not in ffmpeg, but
[22:05] <Compn> Skyler_ : any ideas for filters we should add to lavfi ?
[22:06] <ubitux> ivtc
[22:06] <ubitux> like asked everytime we wonder
[22:06] <ubitux> (like a few minutes ago)
[22:06] <Compn> lol i know :D
[22:06] <nevcairiel> a proper adaptive ivtc with support for dynamically detecting the pattern would be neat
[22:06] <Skyler_> just add avisynth dll support ;)
[22:06] <Skyler_> then you don't need to any work
[22:07] <Skyler_> Though, I guess that's not quite enough often, since a lot of avisynth 'filters' are complicated scripts that use multiple filters and may be really hard to implement in lavfi
[22:07] <nevcairiel> avisynth api is annoying, imho
[22:07] <durandal_1707> but isn't interlacing dying?
[22:07] <nevcairiel> telecine is technically not interlacing
[22:08] <nevcairiel> you can reproduce the progressive stream perfectly
[22:09] <durandal_1707> ok so ivtc and scripting are on top of list
[22:09] <wm4> isn't the avisynth API inverse to the lavfi API (avisynth has pull, lavfi push) - or maybe I'm misunderstanding how lavfi works
[22:12] <durandal_1707> what would inverse mean? that its usability is inverse proportional of avisynth clones?
[22:12] <wm4> inverse data flow
[22:12] <durandal_1707> lavfi just lacks scripting
[00:00] --- Tue Feb 26 2013