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

[burek]

[00:37] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:f9158b01d0f3: swresample/resample: Limit filter length
[00:38] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:a5290cb1ac04: swresample/dither: use av_malloc_array()
[00:38] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:5027f39712fd: swresample/resample: use av_malloc_array() where appropriate
[02:45] <cone-616> ffmpeg.git 03Carl Eugen Hoyos 07master:7fcb4f6c51f4: Fix compilation with --disable-everything --enable-decoder=rawvideo.
[02:45] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:e36aaeca3a30: avfilter/vf_colormatrix: fix memleak on error
[02:45] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:b1763205457f: Merge remote-tracking branch 'cehoyos/master'
[14:39] <ubitux> is st->codec always set after avformat_{open_input,find_stream_info}?
[14:39] <ubitux> like.. even for unknown streams?
[14:51] <wm4> ubitux: isn't there an unknown codec id value for such things
[14:52] <ubitux> probably :)
[14:52] <wm4> do audio encoders accept an arbitrary frame size?
[14:52] <wm4> the transcoding.c example seems to imply that
[14:52] <nevcairiel> those that dont should be using the audio frame queue to buffer stuff
[14:52] <wm4> I thought you'd need to write a frame according to the frame size of the codec
[14:53] <wm4> ok
[14:53] <nevcairiel> ubitux: st->codec is always set, since its just the AVCodecContext, st->codec->codec may be NULL however
[14:54] <ubitux> ok
[15:08] <ubitux> wm4: "The code was basically ported from mpv's loadfile.c at 929793be7"
[15:09] <ubitux> that's why it's the same list as mpv, i guess :p
[15:15] <tmartiro> Hi everybody
[15:16] <tmartiro> how can I compile ffmpeg.c as a library
[15:16] <tmartiro> and export the function main
[15:16] <nevcairiel> its not designed for this, so you can't
[15:17] <wm4> ubitux: he didn't keep the comment about the possibly bogus mime type, though
[15:17] <nevcairiel> why not simply call the ffmpeg executable instead
[15:17] <ubitux> wm4: ah, ok; i didnt compare, feel free to raise sticks
[15:19] <tmartiro> thanks
[15:53] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:9b467d3cd593: examples/transcoding: use av_malloc_array()
[15:53] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:c8a1f10cf486: avcodec/ac3enc_float: use av_malloc_array()
[15:53] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:53487268e555: cmdutils: use av_mallocz_array()
[16:24] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:e4c180c05ac9: avcodec/a64multienc: use av_malloc(z)_array()
[16:24] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:33c9bb943b67: avcodec/avpacket: use av_malloc_array()
[16:24] <cone-318> ffmpeg.git 03Michael Niedermayer 07master:e20e854ca056: vcodec/bitstream: use av_malloc_array()
[16:47] <Daemon404> sws: filterSize 208 is too large, try less extreme scaling or increase MAX_FILTER_SIZE and recompile
[16:47] <Daemon404> sws: initFilter failed
[16:47] <Daemon404> what the shit?
[16:47] <nevcairiel> what kind of resize did you try?
[16:47] <Daemon404> 5000x5000 image to 1920x1920
[16:48] <ubitux> i opened a ticket for that a while ago
[16:48] <Daemon404> thing is
[16:48] <Daemon404> ffms2 uses swscale
[16:48] <Daemon404> and doesnt do this
[16:48] <Daemon404> maybe it uses less 
[16:48] <Daemon404> "extreme" params
[16:48] <nevcairiel> might depends on the scaling algorithm selected as well
[16:49] <Daemon404>     swsctx = sws_getCachedContext(NULL, ctx->yuv->width, ctx->yuv->height,
[16:49] <Daemon404>                                   ctx->avctx->pix_fmt, ctx->dest->width,
[16:49] <Daemon404>                                   ctx->dest->height, ctx->dest->format,
[16:49] <Daemon404>                                   SWS_BICUBIC | SWS_FULL_CHR_H_INT |
[16:49] <Daemon404>                                   SWS_FULL_CHR_H_INP | SWS_ACCURATE_RND |
[16:49] <Plorkyeran> or any of the 20 undocumented magic flags
[16:49] <Daemon404>                                   SWS_BITEXACT, NULL, NULL, NULL);
[16:49] <ubitux> http://trac.ffmpeg.org/ticket/3170
[16:49] <Daemon404> i should remove bitexact
[16:49] <Daemon404> coworker put that there
[16:49] <nevcairiel> its probably because of full chroma or something :)
[16:49] <Daemon404> nevcairiel, the "dont look like shit" option?
[16:49] <Daemon404> ;)
[16:49] <Daemon404> anyway ffms2 uses it too
[16:50] <Daemon404> i see
[16:50] <Daemon404> so basically im fucked
[16:50] <Daemon404> any other image sclaing libs that are ok?
[16:51] <nevcairiel> could do what the error tells you to do
[16:51] <Daemon404> nevcairiel, the other issue is that there is no way ro pragmatically detect this
[16:51] <Daemon404> its printed om stderr
[16:51] <nevcairiel> increase the define and recompile :p
[16:52] <nevcairiel> thats just error reporting in C, there is never a real good way to know what exactly is going wrong
[16:52] <Daemon404> swscale is especially bad
[16:52] <nevcairiel> unless you read textual error messages smewhere
[16:52] <Plorkyeran> just gotta parse av_log output obv
[16:52] <Daemon404> it has no error code
[16:52] <Daemon404> period
[16:52] <Daemon404> just returns NULL
[16:52] <Daemon404> and pritns to stderr
[16:52] <nevcairiel> like EINVAL would tell you more
[16:53] <Daemon404> heh
[16:53] <Daemon404> does fmtconv have an api?
[16:53] <Daemon404> or any good resizing libs?
[16:54] <nevcairiel> weird thing is, my MAX_FILTER_SIZE in sws is 256, how is your 208 too big
[16:54] <Plorkyeran> fmtconv doesn't even have a non-vcxproj build system
[16:54] <nevcairiel> wonder if it was changed recently
[16:54] <Daemon404> Plorkyeran, olol
[16:54] <Daemon404> i thought gimp had some resizing lib
[16:54] <Daemon404> or was that just for colorspace conv
[16:54] <Plorkyeran> imagemagick obv :v:
[16:55] <Daemon404> imagemagick is just about the worst option
[16:55] <Daemon404> im better off writing my own bicubic resize
[16:56] <nevcairiel> oh its accurate rounding, that makes  it fail
[16:56] <Plorkyeran> I'm confused by fmtconv
[16:56] <Plorkyeran> he put a ton of work into writing a high-quality scaler library
[16:56] <Plorkyeran> but won't put in the effort to make it actually usable
[16:57] <Daemon404> Plorkyeran, i know right?
[16:57] <Daemon404> i mean
[16:57] <Daemon404> in theory i COULD use the C api
[16:57] <Daemon404> ofr vs
[16:57] <Daemon404> of*
[16:58] <Daemon404> or implement a dumb loader
[16:58] <Daemon404> but thats retarded.
[16:58] <nevcairiel> strip the accurate_rnd flag, use sws, go grab a few beers to forget about the evil you d id
[16:58] <Plorkyeran> I'd be more inclined to just fork and add an API
[16:59] <Plorkyeran> and actually package it so other people can use it
[16:59] <Daemon404> Plorkyeran, yeah but nobody can mainta8n it except him
[16:59] <Daemon404> with his templated intrinsics mess
[16:59] <nevcairiel> another non-programmer building plugins?
[17:00] <nevcairiel> (which would also explain why no build system or api)
[17:00] <Plorkyeran> as long as you don't touch the actual conversion stuff and he doesn't decide to redesign everything then updating it with new code dumps wouldn't be an issue
[17:01] <Plorkyeran> real goal is to get it to a state where someone who could write it but doesn't want to starts using it
[17:01] <Plorkyeran> and then gets tricked into taking over maintence
[17:08] <Daemon404> lu
[17:08] <Daemon404> lul
[17:15] <Compn> Daemon404 : whats gstreamer use to scale 
[17:18] <Daemon404> Compn, looks like their own thing.
[17:19] <Compn> nevcairiel : but all those books and classes said anyone could write a wrapper and make libraries! :P
[17:20] <Compn> Daemon404 : can look at how mplayer uses swscale bwahaha
[17:20] <Daemon404> same limitations
[17:20] <Compn> whats the problem again ?
[17:20] <Compn> i mean, your problem
[17:21] <Compn> oh it fails
[17:21] <Daemon404> swscale cnat handle large images.
[17:21] <Daemon404> with a high scaling ratio
[17:21] <Compn> what about increase max_filter_size ?
[17:21] <Daemon404> that's a hack
[17:21] <Compn> its an arbitrary limit
[17:21] <Compn> which i've fought against 
[17:21] <Daemon404> surely it must be there for a reason
[17:21] <Daemon404> michaelni, ^
[17:21] <Compn> because it may or may not slow things down . not even sure anyone did a benchmark
[17:21] <nevcairiel> memory concerns
[17:21] <Compn> Daemon404 : NO, THERE IS NO REASON
[17:21] <Compn> i can assure you of this
[17:21] <Compn> 200%
[17:22] <Daemon404> nevcairiel, so i dont go an allocate 900gb?
[17:22] <Compn> no
[17:22] <nevcairiel> all it does is define the size of some pre-defiined  optimization tables
[17:22] <Compn> memory concerns on your p233 mmx cpu
[17:22] <nevcairiel> which are now at 4xMAX_FILTER_SIZE
[17:22] <Compn> theres literally no reason for any limits in sws
[17:22] <Compn> :)
[17:22] <nevcairiel> ie 1024 elements :p
[17:22] <Daemon404> nevcairiel, im not sure what these "memory concerns" are
[17:22] <Daemon404> they dotn seem veyr valid
[17:23] <nevcairiel> sws is from the stone age
[17:23] <nevcairiel> memory was a concern
[17:23] <nevcairiel> :D
[17:23] <Daemon404> ... lol
[17:23] <Compn> p233 days we needed our memory
[17:23] <Compn> and we didnt have 5000x5000 video :P
[17:23] <Compn> so its time to update the limits...
[17:23] <j-b> 8096 plz
[17:23] <Compn> 14k imo
[17:24] <Daemon404> Compn, why have limits?
[17:24] <Daemon404> thats my question?
[17:24] <Compn> Daemon404 : that too
[17:24] <Compn> just because no one wants to fuzz test it
[17:24] <Daemon404> why should the library say i cant
[17:24] <Daemon404> im the damn api user!
[17:24] <Compn> Daemon404 : why not fuzz test it for us
[17:24] <Compn> remove limit, fuzz it
[17:24] <Compn> benchmarks too
[17:24] <Daemon404> why would it need fuzz testing for memory limtis
[17:24] <Daemon404> [16:24] <@Compn> benchmarks too <-- working > notworking
[17:24] <Compn> dont want to OOM ?
[17:24] <Daemon404> benchmark done,.
[17:24] <Compn> lol
[17:25] <Daemon404> [16:24] <@Compn> dont want to OOM ? <-- this is not the responsibiltiy of a resizing lib
[17:25] <Daemon404> its the user
[17:25] <Compn> well you dont want to slow down 1080 playback .... :P
[17:25] <Daemon404> if i wanna pass it 9000gb of rgba data
[17:25] <Daemon404> i will
[17:25] <Compn> Daemon404 : i'm in agreement with ya
[17:25] <Daemon404> Compn, why would it slow down existing stuff
[17:25] <Daemon404> it's a limit
[17:25] <Daemon404> i.e. upper bounds
[17:25] <Compn> because magic
[17:26] <Daemon404> or is this for some macro's magic tables
[17:26] <Daemon404> that with grow N times in size
[17:26] <Compn> could be. i dunno
[17:26] <Compn> it allocates some stuff
[17:26] <Compn> iirc
[17:26] <Daemon404> i see
[17:26] <Daemon404> so it's yet another swscale "design" feature
[17:26] <Compn> thats why the limit
[17:26] <Daemon404> i love those.
[17:27] <Compn> well you see we get complaints when our sizes (1024k per frame or something) are too big
[17:27] <Compn> or 1024b , i try to ignore such things
[17:27] <Daemon404> certainly a problem on embedded devices
[17:27] <Compn> true
[17:27] <Daemon404> but its 2014
[17:28] <Daemon404> and 4k is a thing
[17:28] <Compn> we are crippled by embedded of course
[17:28] <Compn> which is why i suggested runtime limits
[17:28] <Compn> if arm > cripple
[17:28] <Compn> if cluster > unlimit
[17:28] <Daemon404> i think it might be kind of hard to modify sws's api to set it
[17:29] <nevcairiel> hm i cant figure out how the filter size is even calculated, none of the calculations make sense to reach such a high value of 208 for such a downscale
[17:29] <nevcairiel> basically its filterSize = 1+ factor * srcW / dstW
[17:29] <nevcairiel> factor is 4 for bicubic
[17:31] <Compn> nevcairiel : would it make sense to have a better error message ? or just fix the limit ?
[17:32] <Daemon404> also
[17:32] <Daemon404> i dont forsee it getting "better" with teh advent of 4k
[17:32] <Daemon404> only much, much worse
[17:32] <Compn> limits ?
[17:32] <Daemon404> yes
[17:33] <Compn> or you mean resolution stopping from getting larger ?
[17:33] <Daemon404> swscale limits
[17:33] <Compn> obviously, we are on exponential resolution now
[17:33] <Compn> bigger screens means we will get bigger res
[17:33] <Compn> also raw video processing 
[17:33] <Compn> but those guys just recompile and stay quiet
[17:34] <Compn> are you recompiling yet ?
[17:34] <Daemon404> i would rather not have to patch swscale
[17:35] <Plorkyeran> should at least be a configure option or something
[17:35] <Compn> submit patch to -devel with rfc 
[17:35] <Compn> should get fixed within this month
[17:35] <Daemon404> Compn, well see
[17:35] <Daemon404> i want to hear michaelni's opniion
[17:35] <Daemon404> as it is his code
[17:36] <Compn> wonder if fabrice started the limit code
[17:37] <Compn> oh nevermind, only michael has copyright there
[17:37] <Compn> i had no idea :)
[17:40] <Daemon404> Plorkyeran, any idea just how much slower fmtconv is than swscale?
[17:40] <Plorkyeran> no
[17:40] <Plorkyeran> other than "probably a lot"
[17:40] <Daemon404> yeah
[17:41] <Plorkyeran> iirc it's significantly slower than avs's scalers
[17:41] <Daemon404> latency matters here
[17:41] <Daemon404> unfortunately
[17:42] <Compn> Daemon404 : that MAX_FILTER_SIZE was at least in code from 2003... and has been unchanged since
[17:42] <Compn> the 256 limit i mean
[17:42] <nevcairiel> i'm still not sure why you hit the limit with your downscale
[17:43] <Compn> 208 is less than 256
[17:43] <nevcairiel> i would probably have to step through the code to find out
[17:43] <nevcairiel> if you use accurate_rnd, the limit is reduced to 170
[17:43] <nevcairiel> why, i dont know
[17:43] <Compn> are you outputting to the right colorspace bt701 or whatnot ?
[17:43] <nevcairiel> but 208 seems way too high
[17:44] <nevcairiel> 208 pixels input for a 5000->1920 downscale?
[17:44] <nevcairiel> that would make more sense for a 5000->192 downscale
[17:46] <Daemon404> Compn, this is also doing a yuv420p->rgba  conversion
[17:46] <nevcairiel> usually those that failed tried to create tiny thumbnails
[17:46] <Daemon404> but thats irrelevant
[17:46] <nevcairiel> ie 1920 -> 16
[17:47] <Daemon404> i have no idea
[17:48] <nevcairiel> wonder if there isnt a bug somewhere
[17:49] <Daemon404> nevcairiel, aha
[17:49] <Daemon404> i am doing a 100x100 thumb too
[17:49] <Daemon404> that triggers it
[17:49] <nevcairiel> that makes more sense
[17:50] <nevcairiel> you could strip accurate_rnd from the thumb, that gives you a bit more headroom on the scaling
[17:50] <nevcairiel> no solution of course
[17:50] <Daemon404> yea
[17:50] <Plorkyeran> maybe make the thumb from the downscaled version rather than the original?
[17:50] <nevcairiel> or that
[17:51] <Daemon404> thats still no solution
[17:51] <nevcairiel> a "solution" is to rewrite all those parts that rely on a maximum filter size
[17:52] <wm4> you still can hope for avscale
[17:52] Action: wm4 hides
[17:52] <nevcairiel> as if thats ever going to get finished
[17:52] <Plorkyeran> s/finished/started/
[17:52] <nevcairiel> starting stuff is easy
[17:53] <nevcairiel> but implementing a scaling library that can do any<->any like sws
[17:53] <Daemon404> nevcairiel, i am seriously considering using vapoutsynth's C api to load fmtconv
[17:53] <Daemon404> this is sad.
[17:53] <wm4> (except sws actually can't)
[17:54] <nevcairiel> wm4: its good enough, it can take nearly everything as input, and all of the things you care about as output..
[17:54] <nevcairiel> that it butchers chroma in the process or is just ugly on the inside is of no importance :p
[17:54] <Daemon404> (dithering sucks too)
[17:54] <wm4> btw. is anyone of the opinion that libavcodec should automatically use libswscale/libavresample, if the library user doesn't support a specific format?
[17:55] <Daemon404> i think swscale could also be less of a mess if it didnt have 900 pack/unpack formats
[17:55] <nevcairiel> i have never really bothered to check how well it dithers
[17:55] <nevcairiel> most of the directshow formats I support dont have a av pixel format entry, so i have to mangle them myself anyway
[17:57] <Daemon404> michaelni, do you oppose a runtime settable option?
[17:57] <Daemon404> api call or otherwise
[17:58] <wm4> IMO swscale should just handle everything, as long as the image sizes are valid
[17:58] <wm4> and memory allocation doesn't fail
[17:58] <wm4> I think swscale used to crash on these cases instead of failing on init (?)
[17:59] <nevcairiel> probably
[18:00] <wm4> because I remember complaining about this too
[18:01] <michaelni> Daemon404, if theres no real world speedloss and it works then sure runtime settable is better
[18:01] <Daemon404> michaelni, it would be set in an API call
[18:02] <Daemon404> well id rather swscale handle it itself
[18:02] <michaelni> it should not be needed to be set at all
[18:02] <Daemon404> but... thats not so fun
[18:02] <Daemon404> yeah
[18:02] <Daemon404> im not very familiar with that code myself
[18:02] <Daemon404> or what its used for
[18:03] <Daemon404> hmm
[18:04] <michaelni> also i think there are some offsets in the asm that need some change if you change the max filter size
[18:04] <Daemon404> oh lovely...
[18:08] <Daemon404> so basically its a LOT of work to move it to runtime settable
[18:08] <michaelni> yes i think so 
[18:08] <Daemon404> hrm.
[18:09] <Daemon404> configure-time would be pretty easy (Config.asm and pals)
[18:09] <Daemon404> but thats sitlll ugly and bad
[18:09] <nevcairiel> if you can find all the spots which need changing in asm, it doesnt seem that terrible
[18:09] <nevcairiel> instead of an array in the struct, its just a pointer and needs an extra deref
[18:09] <Daemon404> nevcairiel, runtime settable means the asm has to take an new param
[18:10] <Daemon404> or new struct member
[18:10] <Daemon404> my asm sucks :)
[18:10] <Daemon404> especially ppc asm
[18:28] <Zeranoe> Will 2.2.1 support the newer x265 API? http://ffmpeg.zeranoe.com/blog/?p=279
[18:28] <nevcairiel> I think it was decided to not try to backport  the weekly  API fixes to the release branch
[18:30] <nevcairiel> libx265 API is changing way too fast right now
[18:30] <Daemon404> i could have avoided some
[18:30] <Daemon404> like Rodeo pointed out
[18:30] <Daemon404> by using x265_param_parse for e.g. SAR
[18:31] <nevcairiel> no reason the semantic of that isnt changing at some point, and thats a silent breakage then
[18:31] <nevcairiel> but sure
[18:31] <nevcairiel> but not all could be avoided, the recent header repeat thing not for example
[18:32] <Zeranoe> So 2.2.1 will use the same API as 2.2?
[18:33] <JEEB> yes
[18:34] <JEEB> basically you could consider pushing libx265 into an ffmpeg release being somewhat too quick (since you only get support for a single API during that release)
[18:34] <Zeranoe> I'm really wondering if x265 is worth all the trouble 
[18:35] <JEEB> I'd just use the cli encoder at this point to be honest. Having support for the current API in master is OK, but it's not gonna be much useful in the release due to the amount of changes in the API
[18:36] <wm4> <Zeranoe> So 2.2.1 will use the same API as 2.2? <- the same ffmpeg API... the code itself could still be fixed to deal with API breaks of dependencies
[18:37] <JEEB> but then you'd break building that release branch with an older version
[18:37] <JEEB> which used to work
[18:37] <JEEB> I think a release should be relatively stable regarding those things
[18:39] <nevcairiel> wm4: for the fast moving x265 target, it was kinda decided to not bother
[18:40] <nevcairiel> because they are typically not backwards compatible
[18:40] <nevcairiel> so its not only a "break", but requires a new major version
[18:41] <srcreigh> Can someone help me over in #ffmpeg? I'm using ffmpeg libs and avpicture_free is segfaulting. Sorry to be offtopic
[18:48] <cone-291> ffmpeg.git 03Michael Niedermayer 07master:f6759d9ad4a8: swscale/x86/swscale_template: loose hardcoded dstw_offset
[19:09] <cone-291> ffmpeg.git 03Michael Niedermayer 07master:955d7e26b644: swscale/swscale_internal: make the offset strings update themselfs when the MAX_FILTER_SIZE is changed
[20:28] -:#ffmpeg-devel- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[20:56] <cone-291> ffmpeg.git 03Michael Niedermayer 07master:2fcef4a04470: swscale/swscale_internal: remove obsolete warning
[20:56] <cone-291> ffmpeg.git 03Schenk, Michael 07master:358f9ae6390a: configure: AVI demux needs exif
[23:07] <cone-291> ffmpeg.git 03Anshul Maheshwari 07master:5b30f2759267: rtspcodes: don't check for >0 on error codes macro
[23:49] <wm4> ubitux: why is there an ass and a subtitles filter?
[23:51] <ubitux> ass was there in the first place, and it has the benefit of not using lavf
[23:51] <ubitux> the content of the file is directly sent to libass
[23:51] <ubitux> iirc.
[23:52] <ubitux> ...so i guess it's less error prone, and recommended when you're using external ass subs
[23:53] <llogan> subtitles file name must be specified. would be a nice feature to allow users to specify a stream
[23:56] <ubitux> don't want to add subtitles support in lavfi instead?
[23:56] <wm4> this would require overcoming some bullshit
[23:56] <wm4> like thinking you need a generic catch-all data structures to represent formatted subtitles
[00:00] --- Wed Apr  9 2014