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

[burek]

[00:49:08 CET] <cone-128> ffmpeg 03Marton Balint 07master:67bef4cffa69: avcodec/aactab: do not use floats for constants
[00:52:37 CET] <cone-128> ffmpeg 03Michael Niedermayer 07master:652173f63f02: avcodec/pthread_frame: Remove unused variable
[01:02:40 CET] <cone-128> ffmpeg 03Marton Balint 07master:a740263d7e7b: avutil/dict: do not realloc entries when deleting a non-existing item
[01:02:41 CET] <cone-128> ffmpeg 03Marton Balint 07master:c3c7a879baea: avutil/dict: add warning to docs about invalidating existing entries when adding a new entry
[09:16:40 CET] <cone-567> ffmpeg 03Paul B Mahol 07master:a68d4bf2356b: avfilter/vf_waveform: add forgotten color and acolor filter to switch case
[09:33:06 CET] <j-b> 'morning
[10:36:36 CET] <cone-567> ffmpeg 03Matthieu Bouron 07master:31fe3c4d23aa: lavc/mediacodec: fix codec_name leak
[10:36:37 CET] <cone-567> ffmpeg 03Matthieu Bouron 07master:03a6ed83b029: lavc/mediacodec: remove stray empty lines
[11:42:10 CET] <nevcairiel> ubitux: all your x86_64 fate systems seem to have turned yellow recently, something weird is up there
[11:43:05 CET] <ubitux> dammit
[11:43:20 CET] <nevcairiel> not sure if a change caused this, i didnt see anything obviouss
[11:43:22 CET] <nevcairiel> -s
[12:35:35 CET] <ubitux> nevcairiel: it's weird, it seems the file checksum is fine
[12:35:37 CET] <ubitux> d29d3e2c9d05cfb6d1d7c9ed08a83838  fate/fate-suite/aac/er_eld2000np_48_ep0.mp4
[13:17:00 CET] <nevcairiel> ubitux: and for the s16?
[13:26:44 CET] <ubitux> nevcairiel: ah yeah, indeed...
[13:27:23 CET] <ubitux> yeah one bitflip again
[13:27:25 CET] <ubitux> i don't like this
[13:27:35 CET] <nevcairiel> you sit under a funnel for cosmetic rays or something?
[13:27:41 CET] <nevcairiel> cosmic*
[13:28:08 CET] <ubitux> dunno :(
[13:37:13 CET] <rcombs> comic rays
[14:28:23 CET] <Daemon404> xmen joke could have been made, but i wasnt
[14:28:25 CET] <Daemon404> im dissappointed
[14:28:27 CET] <Daemon404> s/ss/s/
[14:33:45 CET] <Daemon404> so uh
[14:33:50 CET] <Daemon404> what do we need a 64bit PRNG for
[14:41:11 CET] <kierank> aac stuff I guess
[14:42:41 CET] <atomnuker> well, AAC just requires the random numbers to be only somewhat random
[14:43:06 CET] <atomnuker> you could probably replace the random numbers with just a static table of somewhat random numbers
[14:43:30 CET] <atomnuker> and that probably won't really change much in terms of the output quality
[14:43:56 CET] <atomnuker> though an integer RNG might be useful for some things I have in mind
[14:44:18 CET] <Daemon404> we do have one. but it is not 64bit
[14:44:55 CET] <atomnuker> yeah, a 32 bit one would be enough
[14:45:17 CET] <nevcairiel> what does it use them for? noise generation?
[14:45:25 CET] <nevcairiel> (aac that is)
[14:46:03 CET] <Daemon404> all the uses outside of crypto i found in the DB ae for noise/encoding
[14:46:14 CET] <Daemon404> and some coding stuff
[14:46:29 CET] <Daemon404> the rest are all for fate tests
[15:20:29 CET] <rcombs> if it's just for testing and doesn't need to be properly cryptographically secure (can't imagine why we'd need the latter internally), just stick together 2 32-bit randoms and call it a day
[15:21:35 CET] <Daemon404> rcombs, we use it in some stuff like aes
[15:21:44 CET] <Daemon404> maybe for hls or rtmpe
[15:21:46 CET] <Daemon404> or something
[15:21:58 CET] <Daemon404> i dont know how 'important' those are
[15:22:08 CET] <rcombs> Daemon404: do we actually generate AES keys for any purpose other than testing, though?
[15:22:20 CET] <Daemon404> good point
[15:22:28 CET] <Daemon404> we have a lot of avoptions for passing in keys
[15:22:52 CET] <Daemon404> i think it's mostly a case of "university student implements papers"
[15:24:18 CET] <rcombs> I mean, we also use GCRY_WEAK_RANDOM when generating RTMPE keys
[15:24:32 CET] <rcombs> but I don't think anyone actually gives a shit about RTMP crypto being strong
[15:25:07 CET] <rcombs> it's pretty much just for show
[16:11:44 CET] <wm4> lol
[16:14:10 CET] <kierank> fair point
[16:24:11 CET] Action: Compn runs
[16:27:04 CET] <wm4> since when were you into comedy Compn 
[16:28:57 CET] <BtbN> what even is this report
[16:29:32 CET] <BtbN> Kind of raises the general question what --help should provide.
[16:29:49 CET] <BtbN> A short summary of how to do basic thing, or a full, searchable documentation
[16:29:52 CET] <BtbN> +s
[16:30:55 CET] <wm4> ffmpeg/ffplay/ffprobe -help is definitely extremely useless
[16:31:05 CET] <wm4> it would be more helpful to output nothing at all
[16:31:17 CET] <jkqxz> ffplay does suggest that it is grouped (offers the '-h topic' etc. options) like ffmpeg is, but doesn't actually support that and always dumps everything.
[16:31:48 CET] <rcombs> step 1: install mpv 
[16:32:00 CET] <rcombs> step 2: https://mpv.io/manual/master/
[16:32:08 CET] <rcombs> afaik ffplay is an API example
[16:32:24 CET] <Daemon404> i should hope not.
[16:33:20 CET] <JEEB> lol
[16:33:28 CET] <JEEB> well it's a proof of concept simple playback thingy
[16:33:32 CET] <rcombs> well that's how I think of it :3
[16:33:56 CET] <wm4> it's sometimes useful for testing
[16:34:08 CET] <cone-141> ffmpeg 03Michael Niedermayer 07master:7eedad946c30: avcodec/mediacodec_sw_buffer: remove redundant article
[16:34:20 CET] <rcombs> and, like, if something works in ffplay and not in mpv then you can be reasonably sure it's an mpv bug and not a lavf/lavc one
[16:34:59 CET] <rcombs> but if you're actually using it as a media player for non-test purposes I dunno what you're thinking
[16:36:28 CET] <rcombs> jkqxz: btw, I'd expect a CoreImage hwcontext would be a useful thing
[16:37:01 CET] <wm4> why would it need a hwctx? maybe a framectx at worst
[16:37:41 CET] <rcombs> I guess I need to read up more on the relevant APIs
[16:38:46 CET] <rcombs> but having lavfi be able to handle CoreImage formats well`
[16:39:42 CET] <rcombs> things get a little bit awkward around conversions between CoreImage (which lavfi would need) and CoreVideo (which lavc would need) objects (which should largely be "rewrap a GPU surface handle")
[16:39:45 CET] <wm4> on OSX you can use hardware surfaces without silly device contexts
[16:40:22 CET] <wm4> aren't they both CVPixelBufferRef?
[16:41:02 CET] <jkqxz> From the description it looked like it wanted a format and associated hwframes propagation.  Unclear on the device part, but the current API requires one to assocuate the hwframes with.
[16:41:21 CET] <rcombs> nah, gotta convert between CV* and CIImage
[16:42:00 CET] <rcombs> `[CIImage imageWithCVPixelBuffer:&]`
[16:42:08 CET] <rcombs> (oh did I mention the filtering is all obj-c)
[16:42:42 CET] <rcombs> (probably less annoying than trying to do C++ work in lav* though)
[16:42:43 CET] <jkqxz> The commentary in the associated bug does suggest it might want devices somehow to make the multi-GPU case work nicely, though there might be transparent magic already handling it.
[16:43:27 CET] <rcombs> as I understand it, coreimage/corevideo involves a _lot_ of transparent magic
[16:44:50 CET] <rcombs> like, applying a filter apparently produces a "promise" wrapped in a CIImage, which isn't "resolved" (i.e. filters all actually applied) until you do something with it that gets directly at the pixel data (or pass it to VT or whatever else)
[16:45:19 CET] <eduarte_> hello
[16:45:38 CET] <rcombs> and then the system figures out the most efficient path underneath it all
[16:45:49 CET] <eduarte_> may i ask a question here ?
[16:46:13 CET] <durandal_170> ask, don't ask to ask
[16:47:08 CET] <rcombs> I've never seen a channel where people weren't OK with asking questions, but _were_ OK with asking if it's OK to ask a question
[16:48:32 CET] <eduarte_> :D maybe its a dumb question tho,,,, I am trying to cut a video with ffmpeg, cutting it down to 30 milliseconds, tho the result always have more than 32 centiseconds, and always different sizes
[16:48:58 CET] <thardin> use a video editor to edit video
[16:48:59 CET] <eduarte_> is that influenced by the video quallity ? how can that be happening ?
[16:49:20 CET] <wm4> eduarte_: #ffmpeg
[17:48:46 CET] <cone-141> ffmpeg 03Martin Vignali 07master:69638517d159: lavf/segment: add increment_tc option
[17:53:02 CET] <cone-141> ffmpeg 03Stefano Sabatini 07master:7725210e715d: lavf/segment: change type of increment_tc to BOOL
[19:31:41 CET] <thardin> the hell.. I'm coding 720p webm at 3 fps
[19:32:05 CET] <thardin> oh, vp9
[19:32:56 CET] <thardin> vp8 runs considerably faster. sort of
[20:14:32 CET] <ethe> I'm not sure a JACK outdev would actually ever work, rate limiting the output, so that it doesnt sound distorted in JACK would result in the need for massive (or possibly infinite) buffers, and requiring -re isn't really a viable solution (not that it even works with -re due to the buffers not being able to stay full)
[20:23:58 CET] <TD-Linux> thardin, also try setting -speed higher
[20:24:20 CET] <TD-Linux> but yeah it's like using x264 in 2005 :)
[20:25:23 CET] <nevcairiel> ethe: how is it different to any other realtime outputs
[20:27:02 CET] <Daemon404> TD-Linux, in 2005, x264 had working ratecontrol, im pretty sure
[20:27:06 CET] <Daemon404> libvpx is further back :D
[20:27:41 CET] <wbs> doesn't libvpx-vp9 default to exhaustive search unless you set speed higher?
[20:27:50 CET] <llogan> nobody actually knows how to use it
[20:28:00 CET] <Daemon404> wbs, wut?
[20:28:05 CET] <TD-Linux> wbs, no, it doesn't
[20:28:13 CET] <Daemon404> llogan, so it's modeled after our mpeg4 encoder then
[20:28:15 CET] Action: Daemon404 runs
[20:28:16 CET] <TD-Linux> you're thinking of -best
[20:28:40 CET] <wbs> TD-Linux: hmm, ok
[20:29:02 CET] <TD-Linux> Daemon404, and it's true about the rate control.
[20:29:06 CET] <Daemon404> ;p
[20:29:12 CET] <TD-Linux> the closest thing to x264 CRF is 2-pass VBR in libvpx
[20:29:57 CET] <TD-Linux> which is quite counterintuitive
[20:30:44 CET] <nevcairiel> i suppose it sort-of makes sense
[20:32:01 CET] <nevcairiel> but it would be nice if there was a decent 1-pass RC as well ;)
[20:32:41 CET] <TD-Linux> xiphmont is writing one, we'll see how it goes.
[20:33:13 CET] <Daemon404> hopefully better than theora's
[20:33:14 CET] Action: Daemon404 runs
[20:36:27 CET] <TD-Linux> Daemon404, well it's based on Theora's rate control :^)
[20:36:47 CET] <Daemon404> oh dear.
[20:37:37 CET] <TD-Linux> though I don't think theora's rate control was that bad. though releasing libtheora 1.2 would help
[20:37:46 CET] <BBB> why bother
[20:37:50 CET] <BBB> its theora...
[20:37:58 CET] <BBB> lets release a new version of a vp3 encoder"
[20:38:15 CET] <TD-Linux> BBB, people still use it. but yeah that's why no one has released it yet :)
[20:38:28 CET] <BBB> people still use ffmpegs mpegvideo encoder
[20:38:52 CET] <BBB> I would go one step further; if they still use libtheora to this day, quality is probably the last thing they care about
[20:39:01 CET] <BBB> or rate control
[20:39:02 CET] <Daemon404> TD-Linux, last i tested was like 10 years ago using ffmpeg2theora
[20:39:05 CET] <Daemon404> for your reference.
[20:39:38 CET] <Daemon404> BBB, you cant even use the freedom excuse now :P
[20:40:10 CET] <BBB> its good that they merged all these scattered efforts into one project
[20:40:23 CET] <BBB> I hope it goes somewhere
[20:40:35 CET] <Daemon404> yes and that was called vpx... or was it daala...
[20:40:38 CET] <Daemon404> oops.
[20:40:47 CET] <nevcairiel> open-something-alliance?
[20:40:57 CET] <TD-Linux> alliance for open media
[20:41:10 CET] <TD-Linux> it's ok, I can't remember it half the time either
[20:41:10 CET] <Daemon404> i still have my skeptical hat on for that
[20:41:16 CET] <Daemon404> alliances formed by tech corps are uh...
[20:41:16 CET] <Daemon404> :)
[20:44:14 CET] <TD-Linux> Daemon404, you were about to say "super fun and a great time" right?
[20:44:45 CET] <TD-Linux> this is much better than one company dropping codecs over a wall, though.
[20:45:18 CET] <Daemon404> well uh... lemme know when that stops happening
[20:45:33 CET] Action: Daemon404 stares at multiple codebases
[20:50:07 CET] <TD-Linux> Daemon404, there is a "central" codebase now, currently on the webm infrastructure, which is basically libvpx with a bunch of stuff deleted
[20:50:23 CET] <Daemon404> ic
[20:52:16 CET] <TD-Linux> on a related note, for an external video codec, do you prefer a x264-style struct interface or a AVOption/opusctl style interface?
[20:52:42 CET] <Daemon404> ive never used opusctl
[20:52:53 CET] <Daemon404> but the struct style is a PITA
[20:53:04 CET] <nevcairiel> a stable string-based interface is usually easier for ABI/API compat
[20:53:10 CET] <Daemon404> thats why we have x264-params, which sets stuff via x264_param_parse
[20:53:20 CET] <Daemon404> structs are an abi abi mightmare
[20:53:24 CET] <TD-Linux> opusctl is ioctl-style in that it uses constants not strings
[20:53:29 CET] <Daemon404> and also means you have to set everything manual
[20:53:31 CET] <nevcairiel> we had to break x265 compat several times until we finally used a string interface for them
[20:53:34 CET] <TD-Linux> but it's the same idea
[20:53:45 CET] <wm4> Daemon404: it's interesting that MS seems to go pretty well with structs in its API
[20:53:57 CET] <Daemon404> wm4, ms understands ABI
[20:54:01 CET] <wm4> they just never try to extend structs (these days)
[20:54:04 CET] <Daemon404> also it has some stuff to bend over backwards
[20:54:08 CET] <Daemon404> also COM
[20:54:23 CET] <wm4> yes, ISomeStuff5
[20:54:30 CET] <wm4> which derives from ISomeStuff4
[20:54:35 CET] <Daemon404> iirc they have special code to pack structs in special ways for certain apis
[20:54:35 CET] <wm4> and adds 1 or 2 methods
[20:54:38 CET] <Daemon404> or something
[20:54:43 CET] <nevcairiel> MS has some flexible structs, which then typically have a size member as the first element in the struct, where the size defines the specific version of the struct you work with
[20:54:55 CET] <wm4> nevcairiel: that seems to be an old convention
[20:55:05 CET] <nevcairiel> (ie. those structs typically just grow, never change existing stuff)
[20:55:09 CET] <wm4> haven't seen it in newer APIs
[20:55:24 CET] <Daemon404> i personally abhor setting options in structs
[20:55:25 CET] <nevcairiel> guess they just define stable structs these days
[20:55:46 CET] <Daemon404> some apis make it very hard to know in between which calls to set stuff, or when accessing them is ok
[20:55:55 CET] <Daemon404> i wonder whose api does that?
[20:55:58 CET] <Daemon404> it is a myster.
[20:55:59 CET] <Daemon404> y
[20:56:26 CET] <TD-Linux> ok. libvpx currently has both styles of APIs, I wanted to delete one and now I know which :)
[20:57:02 CET] <wm4> Daemon404: it scares me that Libav is in favor of adding public fields instead of accessors
[20:57:52 CET] Action: Daemon404 puts fingers in ears, sings
[21:13:45 CET] <dinux5> I get the following error while testing mlp encoder :
[21:13:48 CET] <dinux5> Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[21:14:04 CET] <dinux5> what should I do ?
[21:17:10 CET] <ethe> nevcairiel: not sure really, which are the other realtime outputs, maybe I just havent done enough research
[21:19:22 CET] <ethe> oh right.
[21:19:49 CET] <ethe> nevcairiel: it's different because it *requires* a buffer, it sends data based on callback functions
[22:17:20 CET] <thardin> my ffmpeg has no -speed
[22:17:25 CET] <thardin> perhaps I should pull and recompile
[22:18:03 CET] <Daemon404> he was probably talking about the tool from libvpx
[22:19:44 CET] <nevcairiel> ffmpeg libvpx should have -speed, although it takes numbers, not tokens
[22:19:52 CET] <nevcairiel> (and its a deprecated alias for cpu-used)
[22:38:08 CET] <llogan> ffmbc is on github so the commits can now be publicly viewed. not sure how long it has been there
[22:39:19 CET] <durandal_1707> who still cares about ffmbc?
[22:41:25 CET] <thardin> hasn't ffmbc always been public? as in the source being available
[22:42:04 CET] <llogan> IIRC just the source with no vcs
[22:42:22 CET] <llogan> maybe i'm wrong. can't remember anymore.
[22:46:26 CET] <wm4> wasn't ffmbc a problem because incompatible license
[22:46:38 CET] <JEEB> yah, ffmbc's own stuff is GPL
[22:46:45 CET] <nevcairiel> it uses the lgpl clause to  upgrade to gpl
[22:47:15 CET] <nevcairiel> i had an argument with a neckbeard once how that option only adds freedom
[22:48:11 CET] <JEEB> :D
[22:53:15 CET] <iive> this entirely depends on your definition of what free means :)
[22:59:08 CET] Action: Daemon404 things of Freedom Isn't Free
[22:59:11 CET] <Daemon404> thinks
[00:00:00 CET] --- Wed Mar 16 2016