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

[burek]

[00:00:19 CEST] <durandal_1707> jamrial: from ducker, duck is also audacity effect
[00:01:03 CEST] <jamrial> ah
[00:01:08 CEST] <jamrial> well, if more people recognize what the filter does with that name then go for it :p
[00:53:13 CEST] <cone-170> ffmpeg 03Steve Lhomme 07master:a54e720e0289: configure: force -nologo- when detecting MSVC
[00:53:13 CEST] <cone-170> ffmpeg 03Michael Niedermayer 07master:da8b70b810bb: Merge commit 'a54e720e0289433d6bc3f7ba0a37fa5cabfaeea9'
[04:41:19 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:5da90d7ec3a3: avcodec/hapdec: Check that there is sufficient input data
[10:03:35 CEST] <durandal_1707> if nobody minds I will push areverse and sidechaincompress filters
[10:12:12 CEST] <nevcairiel> man the gst-ffmpeg code is so ugly
[10:12:16 CEST] <nevcairiel> no wonder gstreamer sucks
[10:15:29 CEST] <wm4> link?
[10:15:38 CEST] <wm4> (not easy to track that down with all those plugins)
[10:15:43 CEST] <nevcairiel> http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/tree/ext/libav/gstavauddec.c
[10:15:48 CEST] <nevcairiel> they did use the api wr ong
[10:15:53 CEST] <nevcairiel> but they fixed it a month ago
[10:16:00 CEST] <nevcairiel> avframe on the stack, no free call, ever
[10:16:20 CEST] <BtbN> Their vaapi code is also very "interesting".
[10:16:38 CEST] <BtbN> I wasn't able to understand how it works within a full evening of reading through it.
[10:17:07 CEST] <wm4> there's decidedly too much G in that code
[10:18:28 CEST] <nevcairiel> i wish there was a way to have the compiler throw a big fat warning when avframe is used on the stack
[10:18:57 CEST] <wm4> you could just add something at the end of AVFrame that makes it not stack allocatable
[10:19:12 CEST] <wm4> but it'd have to be ifdeffed out for libavutil internal use
[10:26:25 CEST] <nevcairiel> avutil doesnt use it on the stack either, does it? The closest it comes is using the deref operator to copy all its contents
[10:29:08 CEST] <wm4> hm, my standard C idea doesn't work anyway (using flexible array members or what is was called)
[10:33:28 CEST] <wm4> hm, you could add a trailing array that is SIZE_MAX/2 big
[10:33:42 CEST] <wm4> gcc accepts this, but will error if you allocate that on the stack
[10:34:07 CEST] <wm4> but clang won't
[11:17:40 CEST] <rcombs> break API; add accessors; move struct private
[11:18:18 CEST] <nevcairiel> accessors are so annoying
[13:03:11 CEST] <cone-609> ffmpeg 03Ivan Uskov 07master:c90dbc67ed6b: libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.
[13:13:56 CEST] <cone-609> ffmpeg 03Ivan Uskov 07master:0b159e3b65d5: libavcodec/qsvdec_h264.c: packet buffering has been removed since qsvdec.c does maintain own data buffering now.
[13:19:18 CEST] <nevcairiel> hm who was it that was working on the braindead get_key method in ffmpeg.c for vs2015 some time ago?
[13:19:27 CEST] <nevcairiel> i should get better long term storage in my brain
[13:22:44 CEST] <AlicanC> I need detailed information on filters. I think the online docs are generated from .texi files in doc/. How are .texi files are made? By hand or is there something that generates them from the source code?
[13:23:47 CEST] <AlicanC> By "detailed information", I mean for programmatic usage.
[13:25:59 CEST] <wm4> read the source code
[13:26:13 CEST] <wm4> the texi files are manually edited and usually contain general information
[13:32:22 CEST] <kierank> nevcairiel: "no codecs for which we're GUARANTEED to have better alternatives"
[13:32:23 CEST] <kierank> wtf
[13:32:32 CEST] <nevcairiel> wat
[13:32:32 CEST] <kierank> in gstreamer
[13:32:37 CEST] <nevcairiel> oh
[13:33:07 CEST] <nevcairiel> i wonder if these dedicated decoding libs are actually better
[13:33:10 CEST] <nevcairiel> or just gst nonsense
[13:45:58 CEST] <wm4> maybe ask BBB 
[13:48:47 CEST] <iive> they have their own alternatives for every codec in ffmpeg?!
[13:50:55 CEST] Action: J_Darnley suggests that they just ripped codecs out of libavcodec and call them "alternatives"
[14:17:05 CEST] <durandal_1707> hmm, they have own vp9?
[14:17:35 CEST] <cone-609> ffmpeg 03Paul B Mahol 07master:591741b51d4f: avfilter: add areverse filter
[14:17:36 CEST] <cone-609> ffmpeg 03Paul B Mahol 07master:44fb00866f9b: avfilter: rename vf_reverse.c to f_reverse.c
[14:18:58 CEST] <kierank> durandal_1707: libvpx i sassume
[14:36:36 CEST] <BBB> wm4: ?
[14:36:38 CEST] <BBB> what?
[14:37:32 CEST] <wm4> see gstreamer discussion above
[14:37:42 CEST] <wm4> <nevcairiel> i wonder if these dedicated decoding libs are actually better
[14:37:42 CEST] <wm4> <nevcairiel> or just gst nonsense
[14:38:06 CEST] <BBB> dedicated decoding libs?
[14:38:08 CEST] <BBB> like what
[14:38:18 CEST] <BBB> libvpx instead of ffvp9 and dehevc instead of ffhevc?
[14:38:38 CEST] <ubitux> huge flood of "Past duration 0.673149 too large" (growing)
[14:38:38 CEST] <BBB> libabcxyz instead of ffabcxyz?
[14:38:46 CEST] <ubitux> when transcoding from mp4 to webm
[14:38:49 CEST] <ubitux> known prb?
[14:39:01 CEST] <ubitux> after 1 sec it disappears
[14:39:36 CEST] <BBB> wm4: got more info? I would have to look into it, right now I can only guess
[14:40:23 CEST] <wm4> we were guessing based on the contents of this file http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/tree/ext/libav/gstavauddec.c
[14:40:32 CEST] <wm4> it says "no codecs for which we're GUARANTEED to have better alternatives" somewhere
[14:40:46 CEST] <nevcairiel> There must be some reason they somehow prefer all these external libs over avcodec
[14:40:58 CEST] <nevcairiel> Although stupidity is a reason I would accept
[14:41:19 CEST] <BBB> ah I see
[14:41:28 CEST] <BBB> so, they have this thing called gst-plugins-xyz
[14:41:35 CEST] <BBB> where xyz is base, good, bad, ugly, ffmpeg, etc.
[14:41:44 CEST] <BBB> youre assumed to have base and good installed
[14:41:48 CEST] <BBB> without them, nothing works
[14:42:08 CEST] <BBB> they guarantee that good/base are patent-unencumbered, free (lgpl or better) and high quality
[14:42:13 CEST] <BBB> whatever that means
[14:42:25 CEST] <nevcairiel> Like any of these codecs is patent free
[14:42:32 CEST] <BBB> so, they apparently claim that the performance of these decoders is also better than anything ffmpeg/libav could ever provide
[14:43:02 CEST] <BBB> (I dont know if they measured it, likely they didn't)
[14:43:08 CEST] <BBB> (but maybe they did)
[14:43:19 CEST] <BBB> so they likely claim libvorbis > ffvorbis
[14:43:23 CEST] <BBB> etc.
[14:43:54 CEST] <BBB> if you disagree, you could consider putting out decoder performance stats that show otherwise, I dont know how our audio codecs compare to theirs
[14:44:14 CEST] <kierank> opus should be faster in ffmpeg
[14:44:16 CEST] <BBB> for subtitles, they likely wrote their own which actually are integrated in the rest of the framework
[14:44:16 CEST] <nevcairiel> Clearly for encoding that's true, but decoding the ff codecs tend to beat the external libs eventually
[14:44:25 CEST] <BBB> kierank: opus is not in that list
[14:44:38 CEST] <BBB> nevcairiel: wed have to show numbers, blind claims dont help anyone
[14:45:04 CEST] <BBB> we showed ffvp9>libvpx and ffvp8>libvpx
[14:45:12 CEST] <BBB> wed have to show that ffvorbis>libvorbis
[14:45:56 CEST] <BBB> for subtitles I have no idea, it tends to not be limiting, so they might just want to use base plugins and not do effort integrating ext plugins, if you see what I mean
[14:46:09 CEST] <BBB> since theyre unlikely to be patent-encumbered and performance doesnt matter much
[14:47:14 CEST] <BBB> but from the ranking it looks like they prefer ext libs anyway
[14:47:21 CEST] <BBB>       default:
[14:47:22 CEST] <BBB>         rank = GST_RANK_MARGINAL;
[14:47:45 CEST] <BBB> that seems like in most cases itd use ext libs if installed (e.g. libvpx over ffvp9, etc.), which is not good for users
[14:47:47 CEST] <BBB> but what do I know
[14:50:13 CEST] <BBB> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/vpx/plugin.c -> all libvpx plugins are primary
[15:00:28 CEST] <wm4> did they make the same mistake as dshow, and allow plugins to "take over"?
[15:00:38 CEST] <wm4> because they specify their own prioritx
[15:00:39 CEST] <wm4> *y
[15:05:50 CEST] <mateo`> BBB: maybe this is something that could discussed with them, i've been working on the project quite a bit and i've never heard such claim
[15:16:54 CEST] <BBB> wm4: yes
[15:17:12 CEST] <BBB> wm4: although in this case they create the plugins themselves so its not as much of a viral-y issue
[15:17:21 CEST] <BBB> mateo`: what kind of claim?
[15:37:30 CEST] <BBB> mateo`: also note that they use libav
[15:39:26 CEST] <mateo`> BBB: that external libs are > lavc
[15:40:20 CEST] <Daemon404> for which?
[15:40:21 CEST] <mateo`> BBB: they use libav when you build locally gst-plugins-libav, but you can make it build with the system libs which are usually ffmpeg on most distros
[15:40:39 CEST] <Daemon404> i bet they still claim shit like libdca is better
[15:40:40 CEST] <Daemon404> or libmad
[15:41:07 CEST] <mateo`> Daemon404: what i said is that i've never heard such claim
[15:41:12 CEST] <BBB> Daemon404: they do
[15:41:18 CEST] <Daemon404> mateo`, o
[15:41:18 CEST] <BBB> mateo`: the plugin ranking is higher
[15:41:36 CEST] <BBB> that defines which resource will be used for automatic decoding, which is 99% of all cases (e.g. decodebin, playbin, etc.)
[15:41:46 CEST] <mateo`> BBB: i know
[15:41:46 CEST] <BBB> nobody manually changes these things
[15:41:55 CEST] <Daemon404> anyway, afaict the only reason gst exists these days is so big corps and consultants can do stuff with it
[15:41:58 CEST] <BBB> so if mad priority > ff priority, it will use mad for decoding
[15:41:59 CEST] <BBB> mad is primary
[15:42:01 CEST] <Daemon404> and have proprietary (terrible) plugins
[15:42:01 CEST] <BBB> ff is marginal
[15:42:05 CEST] <BBB> so it uses mad, not ff
[15:42:10 CEST] <mateo`> BBB: all i say is that this is something that can be discussed
[15:42:13 CEST] <BBB> which is bad for users if ff is actually better
[15:42:37 CEST] <BBB> mateo`: ok& so who do we discuss this with? I mean, Im not a political dude, I just code
[15:43:59 CEST] <mateo`> BBB: maybe i can (i'm not a political dude either), i can at least ask why it is done like that
[15:44:56 CEST] <Daemon404> $5 says you get an unsubstantiated claim that external lib is better
[15:45:09 CEST] <BBB> mateo`: sgtm, tnx
[15:45:36 CEST] <BBB> mateo`: Id give an example of ffvp8 or ffvp9 being substantially faster than libvpx, yet their priority being lower
[15:46:05 CEST] <BBB> (since for that we have sufficiently much evidence)
[16:09:14 CEST] <cone-609> ffmpeg 03Paul B Mahol 07master:f0489a35c034: avutil: add ayuv64le and ayuv64be packed pixel format
[16:09:15 CEST] <cone-609> ffmpeg 03Paul B Mahol 07master:052f64ecb2f1: swscale: ayuv64le input support
[16:09:16 CEST] <cone-609> ffmpeg 03Paul B Mahol 07master:3cb8eee6f7bf: swscale: ayuv64le output support
[17:00:39 CEST] <ubitux> is it safe to change avctx->skip_frame in the middle of the decoding?
[17:00:49 CEST] <ubitux> i mean is it supposed to be supported?
[17:00:56 CEST] <ubitux> (without re-opening)
[17:01:35 CEST] <ubitux> (between 2 decode calls)
[17:03:27 CEST] <wm4> ubitux: mplayer and mpv do it
[17:03:44 CEST] <ubitux> ah? in case of lagging?
[17:03:59 CEST] <wm4> yeah, for changing framedrop mode at runtime
[17:04:09 CEST] <ubitux> great, exactly what i was willing to do
[17:04:16 CEST] <ubitux> and so no codec re-open?
[17:04:26 CEST] <wm4> whether it works as intended with multihtreading and all is a different question
[17:04:30 CEST] <wm4> yes, no reopening
[17:04:57 CEST] <ubitux> ok
[17:05:05 CEST] <ubitux> thanks :)
[17:05:16 CEST] <ubitux> just curious, what do you decide to drop?
[17:05:31 CEST] <wm4> a really bad heuristic
[17:05:38 CEST] <wm4> which never works well
[17:06:15 CEST] <ubitux> seems you decide to drop nonref, ok
[17:06:35 CEST] <wm4> that's probably the only thing that doesn't cause corruption
[17:20:50 CEST] <durandal_1707> does anybody used framerate filter from ffmbc?
[17:22:42 CEST] <Compnn> whats it do ?
[17:22:50 CEST] <Compnn> drop / duplicate ?
[17:47:45 CEST] <cone-609> ffmpeg 03Michael Niedermayer 07master:daf6bce71be9: avcodec/dvdec: Retry decoding seemingly damaged MBs while skiping likely damaged parts
[18:00:13 CEST] <durandal_1707> Compnn: it duplicates drop but also blends
[18:00:53 CEST] <durandal_1707> I ported it to New API but it is not working properly
[18:06:27 CEST] <TimNich> durandal_1707:  is that the oneMArk Himsley wrote?
[18:06:50 CEST] <durandal_1707> Yes
[18:07:22 CEST] <TimNich> I might use it if it worked properly ;)
[18:12:15 CEST] <TimNich> What about it is not working properly?
[18:14:21 CEST] <durandal_1707> it picks wrong frame to duplicate, goes into past too much dunno why...
[18:17:11 CEST] <TimNich> ISTR there is something different about the framerate handling in ffmbc. I had different behavour using another filter becasue of that.
[18:25:02 CEST] <durandal_1707> what filter?
[18:26:12 CEST] <kierank> durandal_1707: email mark and ask :)
[18:26:48 CEST] <TimNich> I think the w3dif or maybe tinterlace, or a combination
[18:28:21 CEST] <TimNich> Mark ahd a filter set that d-ineterlaced. scaled then reinterlaced which worked in bmc but mot mpeg
[18:28:30 CEST] <TimNich> *mbc
[18:30:03 CEST] <TimNich> ffmbc set the framrate to double then back again somewhere  int efilter chain, but ffmpeg didnt
[18:30:18 CEST] <TimNich> might be irreleveant oc
[19:01:23 CEST] <durandal_1707> actually it was bug in patch
[19:12:37 CEST] <philipl> BtbN: gstreamer and vaapi seems like a match made in complexity heaven.
[19:12:55 CEST] <philipl> All I know is it's a great way to burn a ton of CPU doing hardware decoding.
[19:15:44 CEST] <j-b> Paul, can your framerate filter to frame-doubling?
[19:22:58 CEST] <durandal_1707> j-b: it can do this, also adds blending frames, and it's mark himsley one ,not mine
[19:23:27 CEST] <j-b> your patch :)
[19:23:45 CEST] <j-b> durandal_1707: are you aware of SVP?
[19:25:09 CEST] <durandal_1707> What?
[19:26:05 CEST] <j-b> http://www.svp-team.com/
[19:29:25 CEST] <durandal_1707> yes I heard of it but didn't looked at their code
[19:29:56 CEST] <j-b> but technically, we could do the same, with your filter, right?
[19:32:03 CEST] <TimNich> Marks filter is more basic. its just a frame blend % eise based on agjacent frames.
[19:33:47 CEST] <TimNich> gooder video had a motion vector frame interpolatot that worked realy well. You could super slo mo and every frame was different even on something like a 40:1 slow down
[19:35:53 CEST] <TimNich> There is alos another GPL one whose name escapes me that I built q while back.https://github.com/slowmoVideo/slowmoVideo/wiki
[19:36:10 CEST] <JEEB> mpv also has one in their video renderer
[19:38:08 CEST] <j-b> the important part is to do frame-doubling
[19:54:52 CEST] Action: michaelni has some unfinished frame interpolation code too, i should update it to HEAD and post it i guess
[19:55:40 CEST] <TimNich> A really good MV interpolator for frame rate conversion would be a useful tool. Commercial variants licences have too many 0 on the end.
[19:57:14 CEST] <michaelni> what i have currently works for some parts of scenes quite nice but for others breaks down really bad, its not really finished
[19:59:15 CEST] <TimNich> Certainly its non trivial, did you look at SlomoVideo? it uses ffmpeg itself
[19:59:36 CEST] <j-b> Well, for vlc, I see request of SVP-like every other day
[19:59:45 CEST] <j-b> and they just want doubling or quadrupling
[20:00:02 CEST] <TimNich> Well that would be a start
[20:03:24 CEST] <nevcairiel> Those things are all terrible, but for some reason users still want them, no matter the strong image artifacts
[20:03:41 CEST] <michaelni> TimNich, didnt look at SlomoVideo, i probably should
[20:05:41 CEST] Action: TimNich is going to brave the multiple accidents between here and home
[20:11:20 CEST] <cone-609> ffmpeg 03Steve Lhomme 07master:c9edbe4af901: use a wrapper script to call MS link.exe to avoid mixing with /usr/bin/link.exe
[20:11:21 CEST] <cone-609> ffmpeg 03Steve Lhomme 07master:58ed7b632842: use a wrapper script to call MS link.exe to avoid mixing with /usr/bin/link.exe
[20:11:22 CEST] <cone-609> ffmpeg 03Michael Niedermayer 07master:dae79a185fa5: Merge commit 'c9edbe4af901e9bc9f05a62319637f9760df9a4a'
[20:12:14 CEST] <BBB> am I the only one who finds it confusing to often find two commits of the same thing in our tree?
[20:12:25 CEST] <BBB> (I suppose one is from ffmpeg and one is from the libav merge?)
[20:12:41 CEST] <nevcairiel> Yes
[20:13:18 CEST] <nevcairiel> Sometimes I don't understand why it isn't just merged, but instead committed separately before
[20:14:32 CEST] <BBB> cant we just skip the merge if we already have the same patch?
[20:14:42 CEST] <BBB> like in git rebase you have a skip option
[20:14:58 CEST] <BBB> like forget about this one and then its just forgotten in the rebase, as if it never existed
[20:15:01 CEST] <BBB> cant merge do that too?
[20:15:27 CEST] <jamrial> BBB, nevcairiel: afaik, it's to keep the sha1 values of commits from the libav side working on ours as well
[20:16:03 CEST] <jamrial> so if you read an old email mentioning commit abcdef12 from libav, it will work if you check for it in the ffmpeg tree
[20:20:38 CEST] <wm4> BBB: IMO it would be better to cherry-pick
[20:21:03 CEST] <wm4> but maybe mini doesn't want to be accused of "manipulating" Libav patches or something
[20:21:09 CEST] <BBB> j-b: can I come to disney just in the afternoon?
[20:21:23 CEST] <wm4> (which is justified, because kindergarten fights between the 2 projects)
[20:21:27 CEST] <BBB> j-b: (I dont know how that would work logistically, but I dont think I can do morning)
[20:21:44 CEST] <BBB> wm4: :D
[20:27:29 CEST] <nevcairiel> jamrial: how would simply merging it without a separate commit on our side break that
[20:28:56 CEST] <jamrial> what do you mean with separate patch? what looks like a duplicate, or the "merge" commit?
[20:30:26 CEST] <jamrial> if the former, that'd be because the patch was commited to ffmeg first, then on libav and merged (like when someone sends the patch to both ml)
[20:31:59 CEST] <nevcairiel> yes, exactly, why would it be commited first if its known to be merged a second later
[20:32:04 CEST] <nevcairiel> its just extra noise
[20:32:08 CEST] <nevcairiel> but thats just me
[20:44:09 CEST] <ubitux> about frame interpolation thing, remember that we can export MVs from codecs now, and use them in filters
[20:44:23 CEST] <ubitux> that might be useful as "fast & ugly" option 
[20:46:35 CEST] <kierank> SVP is batshit insane
[20:46:38 CEST] <jamrial> ubitux: not sure if you noticed it but your fate clients haven't run for like three days
[20:46:42 CEST] <kierank> why not upscale all your videos to 4k as well
[20:47:01 CEST] <ubitux> jamrial: oh damn haven't noticed; will have a look, thx
[20:47:28 CEST] <ubitux> the thread instance seems in a dead lock.
[20:48:20 CEST] <ubitux> anyway, should be fixed, hopefully
[20:48:37 CEST] <jamrial> cool
[20:49:55 CEST] <ubitux> kierank: how is it insane?
[20:50:11 CEST] <kierank> it's watching computer generated data
[20:50:28 CEST] <kierank> and is not what the director (who may well be stupid) intended
[20:50:36 CEST] <kierank> could change the colours too
[20:50:41 CEST] <ubitux> there are many use cases you know
[20:51:00 CEST] <ubitux> like simulating a cheap slowmo on your vacation exploits
[20:51:09 CEST] <ubitux> taken on a dumb phone
[20:51:22 CEST] <nevcairiel> thats not what people want it for though
[20:51:37 CEST] <ubitux> > many use cases
[20:51:39 CEST] <ubitux> ;)
[20:52:27 CEST] <ubitux> can be used the other way around, by dropping and interpolating to avoid lag effect
[20:52:45 CEST] <ubitux> playing with speed is something many users fancy
[20:53:10 CEST] <ubitux> might be more relevant to look @ http://slowmovideo.granjow.net/ though
[21:28:33 CEST] <cone-609> ffmpeg 03James Almer 07master:ede590c84d73: avcodec/aacsbr: add missing header include
[21:34:31 CEST] <durandal_1707> ubitux: I already talked privately about diff filter
[21:35:02 CEST] <ubitux> oh ok
[21:35:06 CEST] <ubitux> so that was a rage quit?
[21:38:50 CEST] <wm4> lol
[21:39:03 CEST] <wm4> could be, but doesn't have to
[22:16:57 CEST] <cone-609> ffmpeg 03Hendrik Leppkes 07master:0c0cd34f9c7d: configure: fix LARGEADDRESSAWARE flag with MSVC
[22:58:28 CEST] <cone-609> ffmpeg 03Shivraj Patil 07master:e21b090bfb7b: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 intra functions
[00:00:00 CEST] --- Sat Jul 25 2015