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

[burek]

[00:12:33 CEST] <kierank> durandal_170: maybel
[00:12:49 CEST] <kierank> https://github.com/kierank/dveo-linux-master/blob/master/Examples/SDIVIDEO/rp219.c
[00:13:01 CEST] <kierank> dunno if it's correct though
[12:11:28 CEST] <durandal_1707> kierank: qctools have scoop
[12:30:20 CEST] <ubitux> http://blitiri.com.ar/p/libfiu/
[14:34:31 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:c64f01227ff6: swscale/swscale: Document param[0..1]
[14:34:31 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:16df02fd2e5b: avcodec/snowenc: Avoid use of deprecated me_method
[14:34:40 CEST] <kierank> durandal_1707: thanks
[14:40:33 CEST] <kierank> durandal_1707: i sent you the spec, right?
[14:41:46 CEST] <durandal_1707> I have hd spec where numbers are
[14:43:07 CEST] <durandal_1707> and the code you linked have diffference  by 1 sometimes for hd version
[14:43:13 CEST] <kierank> I don't understand your 75% grey number
[14:44:12 CEST] <kierank> the comment is wrong I think
[14:44:15 CEST] <kierank> it should be 75% white
[14:44:36 CEST] <durandal_1707> probably
[14:46:35 CEST] <BBB> michaelni: so now that param is documented...
[14:46:46 CEST] <BBB> michaelni: can we deprecate it and use properly named private options for each scaler?
[14:47:00 CEST] <BBB> michaelni: just like we do for codec-specific options in libavcodec or demuxer-specific options in libavformat
[14:47:26 CEST] <BBB> michaelni: next thing, someone will add an option called specialvalue to AVCodecContext and avcodec_open3()
[14:47:45 CEST] <BBB> (same for the flags I guess, thats a mixed back of all kind of stuff)
[14:48:39 CEST] <wm4> BBB: well the swscale API is very redundant
[14:48:49 CEST] <wm4> you don't always need to use the weirder "older" functions
[14:49:03 CEST] <wm4> I think alloc_context + av_set_opt gives you almost all swscale features
[14:49:15 CEST] <BBB> last time I checked, param was only exposed as param
[14:49:22 CEST] <BBB> there was no other (more useful) way to set them
[14:49:39 CEST] <wm4> you can set it with av_set_opt
[14:49:42 CEST] <wm4> at least now
[14:50:03 CEST] <wm4> (param0 and param1)
[14:50:11 CEST] <BBB> what are the opts called?
[14:51:23 CEST] <BBB> param0 and param1"
[14:51:26 CEST] <BBB> and their docs are even better
[14:51:29 CEST] <BBB> scaled param 0
[14:51:40 CEST] <BBB> so, lets deprecate them
[14:51:44 CEST] <BBB> and use useful names
[14:51:47 CEST] <wm4> avoption docs are usually very poor
[14:52:12 CEST] <BBB> theres bad opensource projects in the world
[14:52:15 CEST] <BBB> lets be just like them
[14:52:34 CEST] <BBB> Id like to move to become better :)
[14:55:30 CEST] <ubitux> it would be nice to fix the sws flags yes
[14:55:50 CEST] <ubitux> many are exclusive
[14:56:01 CEST] <wm4> currently it sounds like we're moving towards more compatibility, to other awesome OSS projects which happen to depend on us
[14:56:02 CEST] <ubitux> like scaling algorithm
[14:56:24 CEST] <ubitux> there is also a mess related to dithering
[14:57:09 CEST] <ubitux> maybe it's fixed though
[15:01:15 CEST] <michaelni> BBB, yes param[] should be replaced by named private options, the param[]stuff is really old and predates AVOption & AV*
[15:01:25 CEST] <BBB> right
[15:01:53 CEST] <BBB> I know param[] predates a lot of stuff and so I know why it was added
[15:02:07 CEST] <BBB> I think now is a good time to reconsider param[] conceptually and get rid of it
[15:02:45 CEST] <michaelni> yes
[15:13:24 CEST] <BBB> I really conceptually like the avframe to avframe sws api idea
[15:13:42 CEST] <BBB> I can see theres some issues, but for many users this would be great
[15:14:16 CEST] <BBB> esp. because it can hide complexity without losing information
[15:14:35 CEST] <BBB> e.g. lets say I have a frame that happens to be bt709 and all I care about is rescaling it from 1920x1080 to 1280x720
[15:15:01 CEST] <BBB> I can just set the resolution in the target frame, and leave everything else unset, and the api can fill it for optimal conversion (which means keeping it same as original)
[15:15:06 CEST] <BBB> and it all just works, no information was lost
[15:15:10 CEST] <BBB> but it was super-easy for the user
[15:17:25 CEST] <BBB> wm4: and no, lets not be more compatible with old api, old api thats bad should die. transition periods of 2 years are more than enough
[15:18:28 CEST] <wm4> not for dbian trollol
[15:18:36 CEST] <BBB> so object to his patches
[15:18:43 CEST] <BBB> I supported your objections and indicated why
[15:19:01 CEST] <BBB> debian carries per-projec tpatches already
[15:19:09 CEST] <BBB> these patches are super-trivial to generate
[15:19:20 CEST] <BBB> he can either have patches that re-introduce old api on his support roll
[15:19:24 CEST] <BBB> or he can patch the downstreams
[15:19:30 CEST] <BBB> in our tree, the code will be gone
[15:19:37 CEST] <BBB> 2 years is more than enough
[15:19:54 CEST] <BBB> esp. for easily-sedable changes
[15:19:56 CEST] <nevcairiel> unfortunately there seem to be some people that agree with him
[15:20:40 CEST] <wm4> maybe we should use the argument that this will discourage future changes
[15:20:47 CEST] <nevcairiel> and some even obstruse ideas like "just lets keep the broken code and not fix it, not even security issues, if they use it, their faul"
[15:20:48 CEST] <wm4> but they might like this...
[15:21:45 CEST] <BBB> imagine that 5 years from now, swscale param0 is still there
[15:21:48 CEST] <BBB> I would be moritifed
[15:21:58 CEST] <BBB> mortified*
[15:22:42 CEST] <BBB> I already proposed that I will help him generate patches for the downstreams
[15:23:01 CEST] <BBB> if he prefers to keep patches in debians ffmpeg version to reintroduce the old (deleted) apis, thats fine with me also
[15:23:08 CEST] <BBB> andreas can choose which of these two he prefers
[15:23:20 CEST] <BBB> 2 years is enough, really
[15:23:32 CEST] <nevcairiel> I don't really mind that much if we keep an alias for an existing function one version longer or something, but some stuff is particularly convoluted to support (like get_buffer/release_buffer), and should just go
[15:25:08 CEST] <nevcairiel> and some things are known to just be broken, like the old deinterlacer. Admittedly using lavfi to access yadif as a replacement is quite some effort, but still
[15:25:25 CEST] <BBB> do you want me to put up replacement code?
[15:25:38 CEST] <BBB> I think example code is easier for people if they can just copy it
[15:25:58 CEST] <BBB> (my first lavfi took forever also; however, now I just copy the same code all over and its ok)
[15:26:18 CEST] <BBB> if we give people copypasteable yadif replacement code, theyll be much happier for us to delete av_deinterlace
[15:29:11 CEST] <nevcairiel> sure, such things will probably make some people happy
[15:29:14 CEST] <nevcairiel> not andreas though
[15:30:58 CEST] <BBB> is andreas on irc?
[15:31:42 CEST] <nevcairiel> i think he was occasionally
[15:31:47 CEST] <nevcairiel> not a regular though
[15:34:52 CEST] <iive> projects that use ffmpeg libs hate to change their code... even when it is trivial.
[15:35:38 CEST] <wm4> well it's not like we want to torture these projects for nothing
[15:35:43 CEST] <nevcairiel> everyone likes a stable API, but stable shouldnt become stale
[15:35:46 CEST] <iive> it might look prettier on ffmpeg side, but an application might be forced to ifdef its way into supporting both new and old api, in order to support larger range of distributions.
[15:36:01 CEST] <wm4> iive: trust me, I've done enough of this
[15:36:18 CEST] <wm4> supporting a relatively large range of releases, both FFmpeg and Libav
[15:36:43 CEST] <wm4> (usually the latest release of each, and their git versions)
[15:36:58 CEST] <wm4> and I can confirm that renames are very annoying
[15:37:07 CEST] <wm4> but you can survive it
[15:37:08 CEST] <nevcairiel> latest release and git should usually have the same available API, if you dont use deprecated things
[15:37:20 CEST] <wm4> it's not that simple
[15:37:27 CEST] <wm4> Libav releases are usually old
[15:37:46 CEST] <wm4> and git often likes to deprecate and trash the deprecated thing at the same time
[15:37:48 CEST] <nevcairiel> well "new" functions may not be available
[15:38:30 CEST] <nevcairiel> thats something I've always found a bit hypocritical, lets keep the function or struct member around, but just make it stop working
[15:38:36 CEST] <nevcairiel> that way apps can still link against it
[15:38:41 CEST] <nevcairiel> but working, who cares
[15:38:42 CEST] <nevcairiel> :D
[15:38:56 CEST] <wm4> yeah, that's a bit strange
[15:39:26 CEST] <wm4> so I'm in favor of making at least 1 release that contains both the reprecated functionality (still working), and the new replacement
[15:39:38 CEST] <wm4> this makes updating your code relatively painless
[15:39:46 CEST] <BBB> wait, Im not suggesting to not have compat periods
[15:39:50 CEST] <BBB> Im saying 2 years is enough
[15:39:52 CEST] <wm4> yeah
[15:39:53 CEST] <BBB> 2 years really is totally enough
[15:39:55 CEST] <nevcairiel> big changes should hopefully get rarer in the future anyway
[15:40:03 CEST] <nevcairiel> most renames for namespacing have been done
[15:40:09 CEST] <wm4> I really don't know what's going on with the debian guy
[15:40:14 CEST] <wm4> I mean, it's 2 years!
[15:40:18 CEST] <nevcairiel> its even longer
[15:40:24 CEST] <nevcairiel> those are 2011/2012 things
[15:40:33 CEST] <nevcairiel> (the ones libav suggested to drop)
[15:40:58 CEST] <BBB> some of them were pushed fw several times already
[15:41:03 CEST] <wm4> btw. is there any project that uses av_reverse?
[15:41:03 CEST] <BBB> they should die
[15:41:11 CEST] <nevcairiel> wm4: if any, then mplayer
[15:42:09 CEST] <nevcairiel> if there were many users of it, someone may have complained already that its not exported in msvc builds
[15:42:13 CEST] Action: kierank uses av_reverse
[15:43:15 CEST] <iive> nevcairiel: libmpcodecs/dec_teletext.c is the only use in mplayer
[15:43:38 CEST] <iive> but i've never heard of anybody compiling mplayer with msvc
[15:44:31 CEST] <wm4> and mplayer still prefers the in-tree ffmpeg "copy" instead of dynamic linking
[15:44:58 CEST] <nevcairiel> well of course, because all the private symbols they use are hidden in dynamic links =p
[15:45:17 CEST] <BBB> bbl
[15:46:16 CEST] <wm4> you can build it with shared ffmpeg now, but it still accesses some non-public fields in ffmpeg structs
[15:46:28 CEST] <wm4> unless they fixed that meanwhile
[16:07:32 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:b7faa9d314f2: swscale/alphablend: support packed pixel formats
[16:07:33 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:f28ba31b1b18: swscale/alphablend: Fix big endian formats on LE
[16:54:18 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:87100e828a59: swscale/alphablend: Factor target computation out of the loops
[17:29:56 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:c5ebeaa3085b: swscale/alphablend: Support SWS_ALPHA_BLEND_CHECKERBOARD
[17:46:09 CEST] <durandal_1707> ubitux: can you comment showfreqs?  How to display bigger fft size on smaller width?
[18:14:15 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:0f9d46b70d2a: swscale/alphablend: Support chroma subsampling
[19:17:44 CEST] <michaelni> nevcairiel, can you review ivans qsv patches ? (he said he will be away for 2 weeks from 11th, so might make sense to give him some feedback before he leaves)
[19:41:57 CEST] <philipl> Well, all that work and the vdpau wmv3 playback is pretty dodgy. Anything that's no vc-1 seems to exhibit glitches while the software decoder is fine.
[19:42:26 CEST] <philipl> Now I need to work out if that's just the hardware not really supporting non-Advanced content poorly or the integration is bad :-/
[19:53:58 CEST] <durandal_170> showspectrum should be called showspectogram
[20:03:15 CEST] <nevcairiel> philipl: works mostly fine with dxva2
[20:03:22 CEST] <nevcairiel> michaelni: i'll have a look later
[20:07:03 CEST] <michaelni> nevcairiel, thanks!
[20:10:08 CEST] <wm4> I hope that email was "spicy" enough
[20:20:58 CEST] <philipl> nevcairiel: http://samples.ffmpeg.org/V-codecs/WMV9/halo2_wmp9_WMV3+audio0x162.wmv
[20:21:07 CEST] <philipl> Does that play correctly on dxva2? It's a disaster on vdpau
[20:23:27 CEST] <nevcairiel> i cant try right now, will check later
[20:23:54 CEST] <Compn> a lot of these files maybe broken, incorrect or just created by mencoder... so dont trust them to be valid at any rate :P
[20:24:20 CEST] <Compn> i bet nvidia/ati hate our samples ;D
[20:24:51 CEST] <philipl> Maybe so. Mind you, I have an nvidia purevideo marketing video in wmv that doesn't play right :-)
[20:24:56 CEST] <philipl> Not sure if it came from them in wmv though
[20:25:03 CEST] <Compn> fair enough
[20:25:47 CEST] <Compn> probably decodes with binary codec though
[20:26:04 CEST] <philipl> decodes fine with our decoder.
[20:53:08 CEST] <BBB> where do you guys want me to put yadif examples as drop-in replacement for avpicture_deinterlace()?
[20:53:33 CEST] <BBB> Id like to put this somewhere so we can point users to it and put an end to any discussion about removing avpicture_deinterlace()
[20:53:38 CEST] <BBB> I want that crap gone
[20:53:52 CEST] <ubitux> durandal_170: maybe tmr
[20:53:58 CEST] <ubitux> remind me then
[20:54:23 CEST] <ubitux> BBB: yadif is already auto inserted by ffmpeg when doing -deinterlace
[20:55:13 CEST] <ubitux> BBB: grep do_deinterlace -A15 ffmpeg_filter.c
[20:58:36 CEST] <cone-402> ffmpeg 03hSÇ 07master:7fbafd0b1bfb: avcodec: loongson optimize h264qpel with mmi v1
[21:00:18 CEST] <wm4> man I wonder how Libav ever managed to switch audio decoder to planar output
[21:00:20 CEST] <BBB> ubitux: I mean api, not ffmpeg.c
[21:00:24 CEST] <wm4> because that was a huge change
[21:01:04 CEST] <BBB> ubitux: I have some local code that replaces avpicture_deinterlace() with libavfilter code, and would like to put it somewhere for documentation/example purposes and so we can link to it on stackoverflow/mailinglist/irc
[21:01:06 CEST] <ubitux> BBB: lavfi api is quite more than calling avpicture_deinterlace; pasting the code of that function instead of using the lavfi api is probably a better solution :D
[21:01:21 CEST] <BBB> I know, thats exactly the idea
[21:01:28 CEST] <ubitux> doc/examples already contains a filtering_video.c example
[21:01:30 CEST] <BBB> I want to put this code somewhere so people can copy paste it into their project
[21:01:40 CEST] <BBB> super-lazy
[21:02:21 CEST] <ubitux> BBB: just link to the file at an old revision
[21:02:42 CEST] <jamrial> philipl: using "ffmpeg -hwaccel dxva2" with that sample i get garbage
[21:02:58 CEST] <BBB> http://pastebin.com/YyN19RG6
[21:03:26 CEST] <BBB> the interesting code is line 101-102 and line 217-218
[21:03:31 CEST] <jamrial> philipl: it also gives me the warnings "Old WMV3 version detected, some frames may be decoded incorrectly" and "Reserved bit is not implemented" during decoding
[21:03:47 CEST] <ubitux> BBB: you can just link to http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/imgconvert.c;h=dc67560742ae1c741b5ef13e2e5460f2061cc5a1;hb=HEAD#l409
[21:03:53 CEST] <ubitux> and be done with it
[21:04:36 CEST] <jamrial> philipl: this is with an AMD HD7950, so not Nvidia if that's what you were looking for
[21:04:45 CEST] <ubitux> i don't think moving all that code in doc/examples is really a good example of using ffmpeg api
[21:04:54 CEST] <ubitux> it's a c tutorial example
[21:05:00 CEST] <BBB> Ill keep it on pastebin then
[21:58:02 CEST] <nevcairiel> philipl: jamrial: if it issues that warning, then its not a compliant stream and thus expected failure
[22:05:21 CEST] <jamrial> nevcairiel: mpc-hc (which uses lavfilters) doesn't try to use dxva2 with this video. did it detect it wasn't compliant, or lavfilters doesn't support wmv3 dxva2 at all?
[22:07:04 CEST] <jamrial> hmm, just tried some (alledgedly) sane wmv3 videos and it's the same with those, so i guess it's not supported
[22:07:07 CEST] <jamrial> VC-1 videos in contrast do work with dxva2
[22:07:21 CEST] <nevcairiel> wmv3 works in general
[22:07:24 CEST] <nevcairiel> not on amd though
[22:07:36 CEST] <nevcairiel> amds vc-1 dxva decoder doesnt so wmv3 for some reason
[22:07:41 CEST] <nevcairiel> at least on some models
[22:07:50 CEST] <nevcairiel> but noone cares enough about wmv3 for me to build a model list
[22:08:40 CEST] <jamrial> haha, true enough
[22:10:36 CEST] <iive> wmv3 have flags in its headers that indicate some legacy features
[22:10:50 CEST] <iive> the other programs might detect those.
[22:54:21 CEST] <philipl> Yeah, the software decoder plays that video just fine
[22:54:48 CEST] <philipl> jamrial: likely failing for the same reason vdpau failed - the mis-ordered profile matching
[22:54:54 CEST] <philipl> unless dxva2 doesn't try to profile match
[22:55:11 CEST] <nevcairiel> there is only a condition in place to drop complex profile
[22:55:21 CEST] <nevcairiel> anyway, not in the dxva2 ffmepg code anyway
[22:55:26 CEST] <nevcairiel> its left to the user code
[22:55:58 CEST] <nevcairiel> its a much too complex topic to handle that in avcodec, as dxva2 itself doesnt expose any info whats supported
[22:57:37 CEST] <nevcairiel> .. and because of reasons, my own code doesnt do a profile check in get_format, but after avcodec_open2 returns
[22:57:41 CEST] <nevcairiel> so it works :d
[23:31:49 CEST] <philipl> Heh. fair enough. Well, I'm reasonably certainly I've done what I can here.
[23:58:00 CEST] <wm4> nevcairiel: I just copy&pasted your ffmpeg code btw.
[23:58:19 CEST] <wm4> I'd say this code is plenty of boilerplate-ish
[00:00:00 CEST] --- Mon Aug 10 2015