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

[burek]

[00:22:31 CET] <BBB> nevcairiel: I have problems with that argument; lets say that 9/10 buffers is indeed small, and one (mv) is not; now, lets say that I have a hypothetical frame that has all side data fields
[00:22:37 CET] <BBB> nevcairiel: the size of the small ones is irrelevant
[00:22:41 CET] <BBB> nevcairiel: its the big one that matters
[00:22:52 CET] <BBB> nevcairiel: and so even if only one is big, its already worth it
[00:52:44 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:93f453836306: postproc/postprocess_template: split loop in 2 (block groups of 4, blocks)
[00:52:45 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:fc90d1502a54: bpostproc/postprocess_template: drop avoidable #ifdef
[00:52:46 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:330113b0328e: postproc/postprocess_template: Remove dead code and comments
[00:52:47 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:2a9b9579aba5: postproc/postprocess_template: Move QP initialization down
[00:52:48 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:d9e3fe8c22cb: postproc/postprocess_template: split first part of block loop
[00:52:49 CET] <cone-527> ffmpeg 03Michael Niedermayer 07master:83020f897829: postproc/postprocess_template: split 2nd blockgroup loop out
[04:49:23 CET] <jamrial> nevcairiel: ping
[10:07:22 CET] <j-b> 'morning
[10:11:40 CET] <durandal_1707> 'day
[11:17:44 CET] <av500> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg10698.html
[11:20:35 CET] <j-b> legal attack is the correct option, now.
[11:21:23 CET] <av500> sue a chinese company!!! go go go
[11:21:33 CET] <j-b> no.
[11:21:48 CET] <j-b> People using their chip and shipping CedarX 2.0
[11:21:57 CET] <j-b> way easier
[11:22:11 CET] <nevcairiel> I wonder why they even bother obfuscating things, sueing those asian companies is way hard
[11:22:24 CET] <nevcairiel> but yeah, finding a western-world customer and sueing them might be more fuin
[11:22:26 CET] <nevcairiel> -i
[11:23:26 CET] <av500> allwinner is doomed anyway
[11:23:44 CET] <av500> MTK has 3G, RK has intel
[11:23:48 CET] <av500> AW has nothing
[11:26:11 CET] <wm4> I've kept wondering what this sunxi thing is
[11:26:23 CET] <wm4> all I know of it is that someone made a half-broken vdpau driver for it
[12:10:32 CET] <nevcairiel> someone really wants to run x265 on a RPi2, that poor small device, its going to melt :(
[12:10:46 CET] <nevcairiel> actually, he didnt even say 2
[12:10:53 CET] <nevcairiel> thats even worse!
[12:13:26 CET] <JEEBsv> yeah, rpi2 would have neon
[12:13:28 CET] <JEEBsv> löl
[12:56:06 CET] <kierank> neon will make all the difference
[13:18:36 CET] <cone-136> ffmpeg 03Timothy Gu 07master:641ef7d4f7cc: doc/fate: better formatting
[13:49:08 CET] <ninten> durandal_1707,  in frame_data top level payload their is one field named num_bytes_diff_float can you please tell what is the exact use of it !!
[13:49:29 CET] <ninten> durandal_1707,  regarding ALS
[14:06:59 CET] <durandal_1707> ninten: pastebin source
[14:14:17 CET] <ninten> durandal_1707,  http://pastebin.com/efZS9bp2
[14:29:02 CET] <durandal_1707> ninten: look where is it used in source code
[16:22:42 CET] <cone-136> ffmpeg 03Hendrik Leppkes 07master:cf1fba0fb83b: dxva2_h264: fix slice offset in long slice structs
[16:22:43 CET] <cone-136> ffmpeg 03Hendrik Leppkes 07master:aba3030a5593: vaapi_h264: fix slice data offset
[17:21:26 CET] <cone-136> ffmpeg 03Timothy Gu 07master:ecba41bfd3a1: doc: More semantic markup using @samp and @var where appropriate
[17:29:33 CET] <cone-136> ffmpeg 03Timothy Gu 07master:c3d0edd406d1: doc: Use @lisp where appropriate
[18:41:19 CET] <BBB> wm4: so how much would you want small side-data to be non-refcounted?
[18:41:49 CET] <BBB> wm4: the thing is that even ffmpeg and ffplay will induce the copies already, so I really think copying is a bad idea overall regardless of size
[18:42:03 CET] <BBB> e.g. every decoder that has reference frames uses av_frame_ref()
[18:42:27 CET] <wm4> good question
[18:48:50 CET] <nevcairiel> but  like one-byte values, or one-int values, a copy of that is still cheaper than a refcount increase
[18:49:37 CET] <Daemon404> i would think side-data like MVs is an extreme edge case
[18:49:39 CET] <Daemon404> (and dubiously useful)
[18:51:25 CET] <wm4> yeah
[18:51:53 CET] <wm4> copying the data is probably fast enough
[18:54:54 CET] <nevcairiel> jamrial: you pinged last night?
[18:56:17 CET] <jamrial> nevcairiel: yeah
[18:56:31 CET] <jamrial> can you test this? http://pastebin.com/szQVj1nn
[18:56:47 CET] <jamrial> try the core flag
[18:56:57 CET] <nevcairiel> i thought about adding the flags, but i didnt really see the usefulness
[18:57:00 CET] <Newbourne_> Hello, I am having trouble converting RGB AVFrame to YUV AVFrame. This is the best reference I have found to my problem. Are there any additional references to handling YUV frames?
[18:57:07 CET] <Newbourne_> http://stackoverflow.com/questions/21938674/ffmpeg-rgb-to-yuv-conversion-loses-color-and-scale
[18:57:11 CET] <jamrial> not sure if it's a bug in lavc, but it's not working as intended
[18:57:26 CET] <nevcairiel> maybe it sets them after codec open?
[18:57:27 CET] <cone-136> ffmpeg 03Michael Niedermayer 07master:744c9b49a5a6: avutil/frame: Add some very basic documentation for AVFrameSideData
[18:57:29 CET] <nevcairiel> that would be too late
[18:58:06 CET] <jamrial> as in, i do ffmpeg -libdcadec_flags core -i input... but it doesn't set the flag until too late, so it still detects a dts-ma file as such instead of as core
[19:00:22 CET] <jamrial> like so http://pastebin.com/UQaL7xHg which ruins the output
[19:00:52 CET] <jamrial> i'd expect the flag to be set on time. i assume this is a bug on lavc then?
[19:00:56 CET] <nevcairiel> oh
[19:01:09 CET] <nevcairiel> i figure the probing of the audio stream is still done with the internal dca decoder
[19:01:56 CET] <nevcairiel> or the probing just doesnt get flags set, which is also possible
[19:02:36 CET] <tuckerD> I'm trying to rewrite some prefetching code in libpostproc, and I was wondering If it's ok to use the gcc __builtin_prefetch function (protected by a #if AV_GCC_VERSION_AT_LEAST)
[19:02:41 CET] <jamrial> yeah, if i hardcode the dcadec_context_create() call with the core only flag the probe is then correct
[19:03:02 CET] <nevcairiel> obviously the flag does reach the decoder in time at some point
[19:03:08 CET] <nevcairiel> since it switches the layout
[19:03:16 CET] <nevcairiel> but not for file probing, it seems
[19:03:20 CET] <jamrial> wouldn't this affect every decoder then?
[19:03:27 CET] <nevcairiel> every decoder that takes flags
[19:03:30 CET] <nevcairiel> its not that common
[19:03:59 CET] <nevcairiel> (and that changes these parameters)
[19:04:16 CET] <nevcairiel> you could try built-in dca with -disable_xch 1
[19:04:21 CET] <nevcairiel> it should show the same behaviour
[19:04:26 CET] <nevcairiel> or -disable_xll
[19:05:01 CET] <jamrial> then it should be fixed :p
[19:05:18 CET] <nevcairiel> probably
[19:05:55 CET] <nevcairiel> but i'm still not convinced the flags are a good idea, at least not all of them
[19:06:21 CET] <nevcairiel> native_layout is just going to produce broken audio, synth_x96 is not useful for anyone either
[19:06:22 CET] <jamrial> yeah, regarding usefulness of these flags, the core only flag is interesting
[19:07:02 CET] <nevcairiel> i suppose someone might want the bitexact flag, but it should make it clear that its not required for bitexact xll decoding
[19:07:41 CET] <jamrial> it's useful for regression tests, but the dcadec author said the audio quality is somewhat worse
[19:07:48 CET] <jamrial> and we don't do regression tests on external libs afaik
[19:07:54 CET] <nevcairiel> the difference is probably minimal
[19:08:42 CET] <nevcairiel> he uses those flags internally to decode the core bitexact when doing xll decoding, so the residuals match up properly
[19:08:53 CET] <nevcairiel> guess he figured no harm in just exposing it as well
[19:11:42 CET] <jamrial> the bitexact flag should probably be used by checking avctx->flags & CODEC_FLAG_BITEXACT, and since the only other useful flag out of these is the core only, maybe adding a single option called force_core or such would suffice
[19:11:54 CET] <jamrial> still, no point in adding anything until the above bug is fixed
[19:12:10 CET] <nevcairiel> well API users can still use them
[19:12:31 CET] <nevcairiel> of course it screws over transcoding into any format that needs to know channel/samplerate before hand
[19:14:24 CET] <nevcairiel> speaking of, the dca_parser always sets the avctx->sample_rate to the core sample rate, causing similar issues
[19:14:35 CET] <nevcairiel> i just removed that part, but no idea what it might break :d
[19:39:48 CET] <cone-136> ffmpeg 03Michael Niedermayer 07master:67ceb42d394b: avfilter/vf_stereo3d: Change enum to int, which is accessed via AVOption as int
[19:42:27 CET] <wm4> I wonder if a patch for preferring libdcadec over the internal codec would be accepted
[19:43:02 CET] <wm4> you'd save a lot of projects patching ffmpeg or messing with codec creation for this
[19:47:23 CET] <nevcairiel> the only way to do that right now is to simply move the codec registration, but that seems rather ugly
[19:49:06 CET] <wm4> clearly external libs should just moved up
[19:59:44 CET] <jamrial> wm4: not really. it would force the usage of some decoder libraries that are not better than the internal decoder
[20:02:03 CET] <wm4> jamrial: then why would the user enable them?
[20:03:35 CET] <jamrial> some decoders get compiled by default by simply enabling the library (like libfdk-aac, libvpx and such)
[20:03:40 CET] <jamrial> 99.99% of the cases said library is enabled for the encoder
[20:03:57 CET] <jamrial> and you really don't want libvpx to decode vp9
[20:23:07 CET] <BBB> Daemon404: well Im playing with it so Id like it to be omgfast
[20:23:22 CET] <BBB> what are examples of 1-byte side-data that youd prefer to not be refcounted?
[20:42:17 CET] <cone-136> ffmpeg 03Martin Storsjö 07master:e0046bc9c961: movenc: Write the make and model metadata keys for mov style files
[20:42:18 CET] <cone-136> ffmpeg 03Michael Niedermayer 07master:ad3c5ff347a8: Merge commit 'e0046bc9c96150fa06146ace9093f06857dd7b23'
[22:23:48 CET] <cone-136> ffmpeg 03Mark Reid 07master:001b28b0211b: libavformat/mxfenc: add container duration and package name to primer pack
[23:51:04 CET] <kierank> av500: http://www.cnx-software.com/2015/03/23/allwinner-cedarx-media-codec-library-gpl-lgpl-compliance-update/
[23:51:05 CET] <kierank> wtf
[23:51:11 CET] <kierank> "This way we have Binary<->LGPLed open source code<->GPL libraries"
[23:53:04 CET] <philipl> Don't worry, we're totally infringing the licence now, but we'll totally sort that out. We promise.
[23:58:41 CET] <iive> i liked the bit about chinese developers not using version control systems...
[00:00:00 CET] --- Tue Mar 24 2015