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

[burek]

[00:09:28 CEST] <guest> For instance, I basically just need to change a 5 to a 12 somewhere in the codebase, but I have no idea where.
[00:15:22 CEST] <jkqxz> guest:  Here: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/flacenc.c;h=3575f5391dc8b3aafcaa529586b017de6135f12d;hb=HEAD#l300>.
[00:15:27 CEST] <J_Darnley> guest: flafenc.c
[00:15:33 CEST] <J_Darnley> ha, snap
[00:15:37 CEST] <jkqxz> Heh.
[00:16:31 CEST] <guest> Thanks! I had just muddled my way through GNU find to get there, but this is much more direct! :)
[00:16:54 CEST] <J_Darnley> I'm sure you'll get complaints from people who don't have sse4 thoguh, you'l make their encodes much slower.
[00:17:34 CEST] <nevcairiel> changing a default should have a better explanation then "I like it better" though
[00:17:41 CEST] Action: J_Darnley should really dig out and finish his 32-bit sample lpc patch
[00:17:42 CEST] <nevcairiel> or you might as well not bother =p
[00:18:28 CEST] <BtbN> There are other defaults that are way more stupid. And they will won't change.
[00:19:36 CEST] <jkqxz> Does anyone have any opinion on the wrapped_avframe thing?  If I send a patch adding an AVPacket flag which has to be set at the same time for the decoder to work would anyone find that objectionable?
[00:19:43 CEST] <guest> Mmm. What other reason could their be, other than "I like it better"?
[00:19:49 CEST] <guest> *there
[00:20:00 CEST] <nevcairiel> jkqxz: sounds like an ugly hack, maybe you should just delete lavd instead and call it a day? :)
[00:21:10 CEST] <guest> J_Darnley: Oh, darn, I've never heard of this. Is this a big problem for a lot of people?
[00:21:30 CEST] <jkqxz> I think more people would object to deleting lavd.  (Maybe people I'd less like to listen to, but technically they are still people.)
[00:22:45 CEST] <atomnuker> RiCON also told me higher levels of compression render files undecodable by cheap devices
[00:23:01 CEST] <nevcairiel> guest: defaults are just that, defaults, we have options for people to set them to whatever they prefer, so personal preference really doesn't make much of an argument since you can just set it to whatever you want it to be without a code change.
[00:23:31 CEST] <nevcairiel> a better argument would be showing a performance/compression curve and picking the sweet spot in that
[00:23:41 CEST] <nevcairiel> i dont know if its 5, but its usually not the highest compression value either
[00:24:43 CEST] <guest> What is a "sweet spot" other than a spot you like the most?
[00:25:02 CEST] <nevcairiel> the most efficient
[00:25:08 CEST] <nevcairiel> best ratio of time s pent to size achieved
[00:26:29 CEST] <nevcairiel> if, for example (and I don't know how slow flacenc can really get) the highest mode takes twice as long to save an additionaly 2% over one blow that, its clearly not quite efficient to use it
[00:26:42 CEST] <nevcairiel> s/blow/below/
[00:27:51 CEST] <guest> That makes some sort of sense, but also seems to be hunting the wrong thing. For instance, if I have lots of time and little space, then it is a good deal for me to spend time to gain space.
[00:28:05 CEST] <nevcairiel> for you, sure
[00:28:15 CEST] <nevcairiel> so set the options to what you like :)
[00:28:28 CEST] <jkqxz> Define some way of measuring efficiency which you feel people should care about (and that conveniently make your preference appear best), then convince people that they are the correct ones.
[00:28:38 CEST] <guest> In this case, flac encodes so quickly for me that I would be willing to trade even more time for even more space, if possible.
[00:29:23 CEST] <guest> @atomnuker: That's troubling. I've never run into it, though. Do you know why that might be the case?
[00:31:11 CEST] <guest> jkqxz: An interesting ploy. I guess those philosophy classes I took are about to pay off!
[00:31:14 CEST] <J_Darnley> Yeah, compression level 12 prosuces non-subset files which aren't guaranteed to work with limited decoders.  That's part of the flac specification IIRC.
[00:31:24 CEST] <J_Darnley> *produces
[00:32:12 CEST] <J_Darnley> As for the number of perople with sse4, I have no idea how many that might be.
[00:32:32 CEST] <nevcairiel> its probably relatively common these days
[00:32:37 CEST] <J_Darnley> I bet few of them are encoding flac that often though.
[00:32:42 CEST] <guest> Is this related to how flac compression only goes up to 8 but you guys go up to 12?
[00:32:42 CEST] <kierank> sse4 is nehalem
[00:32:43 CEST] <atomnuker> its nonexistant
[00:32:44 CEST] <kierank> so a decade ago
[00:32:50 CEST] <nevcairiel> not sure which the last intel cpu was without it, probably some more AMDs without it
[00:33:05 CEST] <J_Darnley> guest :yes
[00:33:49 CEST] <nevcairiel> if 12 produces files which are semi out-of-spec (or using a part of the spec not universally supported), then thats definitely not a good default in any case
[00:33:49 CEST] <J_Darnley> I think if you use some of flac.exe's more advanced options you can copy what ffmpeg can do.
[00:34:40 CEST] <guest> What other compatibilities do I lose from 9 to 11?
[00:35:18 CEST] <J_Darnley> I think everything above 8 could produce non-subset files
[00:36:07 CEST] <guest> nevcairiel: this is a good point, and I am now reconsidering my whole enterprise.
[00:50:33 CEST] <guest> J_Darnley: where might I read more about ffmpeg's treatment of flac?
[00:51:38 CEST] <J_Darnley> The source code in libavcodec/flacenc.c (and maybe a little in libavformat/flacenc.c)
[00:51:49 CEST] <J_Darnley> It isn;t very descriptive though.
[00:53:11 CEST] <guest> Ah, so I would have to do detective work. No time for that, I'm afraid. Thanks anyway.
[00:53:59 CEST] <J_Darnley> For a slightly more prose style perhaps the flac website: https://xiph.org/flac/
[00:55:34 CEST] <guest> This is certainly useful to learn about flac, but not so much to learn the secrets of the ffmpeg compression levels.
[00:57:11 CEST] <J_Darnley> Well you can see how ffmpeg translates the compression_level option into actual coding parameters in the code below the line jkqxz linked to
[00:57:21 CEST] <J_Darnley> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/flacenc.c;h=3575f5391dc8b3aafcaa529586b017de6135f12d;hb=HEAD#l300
[00:57:40 CEST] <guest> Alright, thanks.
[01:13:09 CEST] <sarnex> hi, why can i not send h264 to a v4l2-format output? it looks like v4l2loopback supports h264 but ffmpeg gives me an error
[01:13:57 CEST] <sarnex> [v4l2 @ 0x94a6c0] V4L2 output device supports only a single raw video stream
[01:14:08 CEST] <sarnex> https://github.com/umlaeute/v4l2loopback/blob/master/v4l2loopback_formats.h
[02:47:20 CEST] <kepstin> sarnex: it's just not implemented on the ffmpeg side.
[02:47:53 CEST] <sarnex> kepstin: thats what i thought. i dont have the skills to do it, should i file a bug report or something somewhere?
[02:51:16 CEST] <iive> i think that trac does have "feature request"
[02:51:53 CEST] <sarnex> iive: what up, and ok ill take a look at it, thanks
[03:03:27 CEST] <sarnex> i've submitted it, thanks guys
[03:15:47 CEST] <sarnex> jamrial: thanks
[05:02:39 CEST] <cone-603> ffmpeg 03Alex Converse 07master:4d2b9ece45e5: avformat/flvdec: Set need_context_update when setting the initial extradata
[09:43:39 CEST] <JEEB> ...
[09:43:58 CEST] <JEEB> I have an MPEG-TS file that goes 15373647778 -> 6783715106 with PTS
[09:44:07 CEST] <JEEB> from one audio sample to another
[09:44:16 CEST] <JEEB> that doesn't look like your usual MPEG-TS timestamp stuff
[09:44:35 CEST] <JEEB> https://kuroko.fushizen.eu/videos/pid_switch_sample.ts
[09:44:48 CEST] <JEEB> `./ffprobe -of json -show_frames -select_streams a:0 ~/videos/pid_switch_sample.ts |less`
[09:45:03 CEST] <JEEB> you can just search for the first one and then you see it suddenly going down
[09:45:45 CEST] <JEEB> unless that really is roll-over
[09:45:50 CEST] <JEEB> but the value doesn't look like it
[09:46:26 CEST] <JEEB> checked with the java-based DVBInspector and that seemed to think the timestamps were going onwards OK at least
[09:47:11 CEST] <nevcairiel> with ts you should really be prepared for timestamp jumps in any direction
[09:48:43 CEST] <JEEB> that's true
[09:50:41 CEST] <JEEB> the SD video track that comes up in the PMT first has the same thing, it seems: 15373650296->6783718707
[09:52:09 CEST] <JEEB> I've already written code to keep the last duration and PTS around since I'm applying the changes after decoding (as decoders don't seem to care about the timestamp shenanigans), but that's kind of meh and bound to break somewhere I have a feeling :V
[10:49:50 CEST] <kierank> JEEB: you have to basically keep the timestamps strictly monotonically increasing
[11:05:06 CEST] <JEEB> kierank: yea
[11:05:40 CEST] <JEEB> that's what my logic does. if the timestamp equals or goes downwards I take the last timestamp and add the duration to it, which is not perfect but works in some cases
[11:06:32 CEST] <kierank> you need to use modular arithmetic as well
[11:06:48 CEST] <kierank> in your metric for "goes downwards"
[11:08:19 CEST] <JEEB> right.
[11:47:47 CEST] <jkqxz> wm4:  Ok, that comment is quite damning.  (The code structure all comes from the standard, so I could excuse a lot of code similarity.)
[11:51:19 CEST] <wm4> I also considered that it might come from openhevc, which might provide the hevc parts under a more liberal license, but the line my links point to includes changes in ffmpeg
[11:53:31 CEST] <jkqxz> Does anyone actually care about licensing of rockchip media libraries?
[11:53:40 CEST] <wm4> no idea
[11:54:44 CEST] <BtbN> Why does the major bump just bump the deprecation version of almost all the deprecation defines?
[11:54:45 CEST] <wm4> personally I'd probably prefer not to gate the wrapper under obscure flags, but it doesn't really matter
[11:55:08 CEST] <wm4> BtbN: because we have this shitty policy of keeping garbage for at least 2 years
[11:55:23 CEST] <BtbN> All that stuff was deprecated that late?
[11:58:47 CEST] <wm4> who knows
[12:44:08 CEST] <mobi> hi
[12:46:44 CEST] <mobi> stevenliu: Your patch doesn't fix it properly. Stream is broken
[12:47:00 CEST] <mobi> [mpegts @ 0x7fbe28296ca0] PES packet size mismatch
[13:03:14 CEST] <stevenliu> ;(
[13:04:31 CEST] <stevenliu> I play the stream have not good....  China cannot play youtube and cannot open google ....
[13:05:35 CEST] <stevenliu> Let me try some other ways ...
[13:11:45 CEST] <mobi> Then you only have to port ffurl_*, this work ok
[13:12:17 CEST] <mobi> Then you only have to back port ffurl_*, this work ok
[13:13:09 CEST] <stevenliu> I'm not sure if Derek do it have some thing to think
[13:13:18 CEST] <nevcairiel> thats not going to happen, if there is a bug, fix the bug, but dont blindly revert to old stuff that was removed for a reason
[13:13:20 CEST] <stevenliu> that looks likes merge from libav
[13:14:38 CEST] <stevenliu> I have try check the old commit you said use ffurl*, it have same problem here ...
[13:26:20 CEST] <mobi> this ist other ffplay bug
[13:26:23 CEST] <mobi> http://trac.ffmpeg.org/ticket/6486
[13:27:45 CEST] <mobi> https://pastebin.com/QVZdkJbV << with back is ok
[13:28:53 CEST] <mobi> nevcairiel: i think , this merge from avplay was blind
[13:29:01 CEST] <durandal_1707> anybody want to comment my fft convolve filter?
[13:39:11 CEST] <mobi> new ffmpeg: https://pastebin.com/WTLvKJfZ
[13:39:12 CEST] <mobi> old ffmpeg with ffurl_*:https://pastebin.com/3AC1ZiLL 
[14:07:24 CEST] <stevenliu> mobi: hello?
[14:07:33 CEST] <mobi> yes ?
[14:07:55 CEST] <stevenliu> i play use ffplay with the modify is not stop, just give warinng at terminal, is it same there?
[14:10:14 CEST] <mobi> with you patch, play dont stop but come :
[14:10:20 CEST] <mobi> [mpegts @ 0x7f7e50296ca0] PES packet size mismatch sq=    0B f=0/0   
[14:10:21 CEST] <mobi> [h264 @ 0x7f7e50cdb6c0] non-existing PPS 1 referenced=    0B f=0/0   
[14:10:23 CEST] <mobi> [h264 @ 0x7f7e50cdb6c0] decode_slice_header error
[14:10:24 CEST] <mobi> [h264 @ 0x7f7e50cdb6c0] no frame!
[14:18:15 CEST] <stevenliu> );
[14:19:19 CEST] <ubitux> can anyone enlight me on the purpose of the extralibs in configure?
[14:19:45 CEST] <ubitux> i feel like the check_lib of a given library should add the linking option if successful
[14:20:23 CEST] <ubitux> that said, when i'm looking at stuff like dxva, there is no such thing as a check_lib
[14:24:52 CEST] <cone-842> ffmpeg 03Paul B Mahol 07master:833a38dbe5b3: avfilter/vf_datascope: make it possible for output window to automatically change position
[14:33:24 CEST] <ubitux> BBB: i'm looking at the avfoundation stuff
[14:34:55 CEST] <BBB> ubitux: cool
[14:35:05 CEST] <BBB> ubitux: so I guess you didnt like my patch? ;)
[14:35:16 CEST] <BBB> ubitux: from looking at other extlib thingies, I think they actually do the same thing
[14:35:21 CEST] <ubitux> dunno, you said it didn't work
[14:35:26 CEST] <BBB> it did with last patch
[14:35:41 CEST] <BBB> but I had to change the lib checks enabled avfoundation_indev with enabled avfoundation
[14:35:48 CEST] <ubitux> my understanding is that it should look like something like this:
[14:35:48 CEST] <BBB> which seems reasonable, other extlibs do that too
[14:35:51 CEST] <ubitux> avfoundation_indev_deps="pthreads avfoundation"
[14:35:54 CEST] <ubitux> avfoundation_indev_deps_any="coregraphics applicationservices"
[14:36:02 CEST] <ubitux> and then have stuff like:
[14:36:05 CEST] <ubitux> enabled coregraphics        && check_lib coregraphics        CoreGraphics/CoreGraphics.h               CGGetActiveDisplayList -framework CoreGraphics
[14:36:07 CEST] <ubitux> enabled applicationservices && check_lib applicationservices ApplicationServices/ApplicationServices.h CGGetActiveDisplayList -framework ApplicationServices
[14:36:31 CEST] <ubitux> this expresses the expected dep tree correctly afaik
[14:36:32 CEST] <BBB> ah, interesting
[14:36:36 CEST] <BBB> yes you could do that also
[14:36:51 CEST] <ubitux> for the avfoundation dep check, afaik, we only have the header
[14:36:55 CEST] <BBB> Im not sure its really worth all that much trouble to be honest
[14:37:06 CEST] <BBB> it makes sense if were likely to use CoreGraphics for other things also
[14:37:16 CEST] <BBB> if its just a tree leaf, then its not so important how you express it
[14:37:30 CEST] <ubitux> it might be important to have consistent checks
[14:37:39 CEST] <BBB> sure
[14:37:40 CEST] <ubitux> it's enough of a mess :p
[14:37:43 CEST] <BBB> thats true
[14:37:49 CEST] <BBB> Ill test any patch you throw at me
[14:37:58 CEST] <ubitux> it takes days with several engineers to figure out what's going on
[14:38:04 CEST] <ubitux> so better not confuse the future generations
[14:38:23 CEST] <BBB> ok
[14:48:25 CEST] <wm4> can we ban cehoyos from development already?
[14:49:53 CEST] <durandal_1707> send ban request to ml and watch results
[14:53:29 CEST] <kierank> BBB: michaelni's arguments are insane
[14:53:35 CEST] <kierank> let's not clean things up because things are bad
[14:53:53 CEST] <BBB> ¯\_(Ä)_/¯
[14:54:03 CEST] <BBB> Im not reading that thread any further
[14:54:18 CEST] <BBB> Ive blocked the patch and I am happy to discuss it further in a more general setting - VDD sounds ideal to me
[14:54:35 CEST] <durandal_1707> why not let add it with ff t log?
[14:56:07 CEST] <durandal_1707> or add assert to every error log so one can trace from where in code error came...
[15:03:56 CEST] <BBB> durandal_1707: I have no objections to ff_tlog
[15:04:39 CEST] <BBB> but apparently some people prefer to send highly technical error messages (cd failed with ld/tr propane %d/%d/%d, a, b, c) to end users and think that will help them
[15:07:58 CEST] <kierank> "The messages from libavcodec are by the nature of it quite technical.
[15:07:58 CEST] <kierank> Does showing these messages to your users have any value for them at
[15:07:58 CEST] <kierank> all ?"
[15:08:00 CEST] <kierank> LOL
[15:09:54 CEST] <BBB> maybe I should indeed ignore all error messages coming from av_log and assume they are meant to be ff_tlog analogs
[15:10:11 CEST] <BBB> if that is so, then why not merge ff_tlog and av_log, add a compiler flag to get rid of av_log altogether
[15:10:15 CEST] <BBB> and just use proper return values?
[15:10:22 CEST] <BBB> Im fine with that also
[15:10:22 CEST] <wm4> error handling is pretty much fucked in ffmpeg
[15:10:36 CEST] <BBB> my users dont want to hear that cr/ld/tr failed
[15:10:45 CEST] <wm4> an API user can't know whether something is a broken file, a non-standard file, corruption, or whatever
[15:11:00 CEST] <BBB> they want to hear that your file is fucked. ask the developer for help at this website, upload the file here if its valid, and try a new release before that
[15:11:18 CEST] <BBB> (maybe reorder that statement a little)
[15:11:28 CEST] <BBB> but cr/tr/ld is not helpful to my end users
[15:11:48 CEST] <wm4> also snow has no users
[15:11:50 CEST] <wm4> literally
[15:11:58 CEST] <BBB> in most cases, wm4 is right and even the return values arent helpful since they are still mostly -1
[15:12:09 CEST] <BBB> but I also think some decoders get that right nowadays
[15:12:23 CEST] <wm4> even if they do, the result is rarely helpful
[15:12:40 CEST] <wm4> I don't think there has been a single situation where the error code has been helpful
[15:12:51 CEST] <BBB> maybe
[15:12:53 CEST] <wm4> (except explicitly defined ones like AVERROR(EAGAIN) or AVERROR_EOF)
[15:13:03 CEST] <BBB> I think the vp9 decoder can distinguish (for valid files) between:
[15:13:11 CEST] <BBB> a) your computer doesnt have enough memory, buy a new computer
[15:13:11 CEST] <BBB> or
[15:13:27 CEST] <BBB> b) your file is fucked. update to latest version or ask the developer for help by uploading the file here
[15:13:41 CEST] <wm4> I've rarely if ever seen a ENOMEM returned either
[15:13:45 CEST] <BBB> I think these are somewhat helpful and give users next steps (they can also ignore it and think the software is trash)
[15:13:52 CEST] <BBB> vp9 returns enomem in 2 places
[15:13:59 CEST] <wm4> usually you just swap to death or die of overcommit
[15:14:08 CEST] <BBB> thats true :)
[15:14:19 CEST] <BBB> enomem triggers on macosx though
[15:14:37 CEST] <BBB> it may well be fuzz-only though, hard to say for sure
[15:14:50 CEST] <BBB> I dont know where the exact real vs. fake distinction is there
[15:19:27 CEST] <ubitux> so apparently we are trying to link against either ApplicationServices or CoreGraphics
[15:19:36 CEST] <ubitux> just in order to get CGGetActiveDisplayList
[15:19:43 CEST] <wm4> and that we use for?
[15:19:51 CEST] <ubitux> but that's simply because these 2 links to a 3rd framework, quartz thing
[15:20:08 CEST] <ubitux> shouldn't we jus link to that quartz thing
[15:20:21 CEST] <ubitux> instead of probing random library that link against it?
[15:21:02 CEST] <ubitux> (i'm trying to recompose properly our actual dep tree)
[15:21:05 CEST] <ubitux> (and it's a mess)
[15:25:36 CEST] <wm4> and what do we use it for?
[15:25:41 CEST] <wm4> is it just VDA garbage?
[15:25:56 CEST] <ubitux> avfoundation
[15:25:58 CEST] <ubitux> the "device"
[15:26:45 CEST] <BBB> I feel so bad for you having to figure this out
[15:27:24 CEST] <ubitux> i'm recomposing the deps of the whole things
[15:27:37 CEST] <ubitux> we really have a ton of stuff, and the current dep are somehow completely broken
[15:28:11 CEST] <ubitux> (wrt apple things i mean)
[15:28:27 CEST] <durandal_1707> so nobody cares for my splendid filter which can do tons of stuff and lens blur
[15:28:43 CEST] <BBB> durandal_1707: I dont think I know what it does :-p
[15:29:01 CEST] <BBB> ubitux: I think people that add features on apple just care that it compiles, not that the configure dep tree is perfect :-/
[15:29:32 CEST] <ubitux> yeah, and as a result, sometimes it doesn't
[15:29:41 CEST] <ubitux> and the rest of the time it links to a bunch of garbage things
[15:29:43 CEST] <durandal_1707> BBB: you never played with fft and lens blur?
[15:29:48 CEST] <BBB> no
[15:29:51 CEST] <wm4> durandal_1707: you suck at selling it
[15:33:00 CEST] <durandal_1707> wm4: wow, thats unexpected
[15:36:08 CEST] <durandal_1707> audio counterpart is afir filter, which can do all sort of effects
[15:37:09 CEST] <ubitux> can we drop qtkit indev?
[15:37:19 CEST] <ubitux> it's deprecated by avfoundation indev
[15:37:33 CEST] <ubitux> (https://developer.apple.com/documentation/qtkit)
[15:37:40 CEST] <ubitux> > QuickTime Kit was deprecated in OS X v10.9. Use the AVFoundation framework instead.
[15:37:44 CEST] <ubitux> is this old enough?
[15:38:05 CEST] <durandal_1707> lol, never heard of qtkit
[15:39:20 CEST] <wm4> since we still "support" VDA, probably not
[15:40:11 CEST] <ubitux> can we drop vda?
[15:41:19 CEST] <wm4> IMO yes
[15:42:31 CEST] <ubitux> should we do it at the same time as the major bump?
[15:49:44 CEST] <ubitux> btw, is -framework Foundation the same as -framework CoreFoundation? 
[15:50:13 CEST] <wbs> no, Foundation is the base lib for objective C things
[15:50:29 CEST] <wbs> while CoreFoundation is the corresponding one for their C based APIs
[15:50:42 CEST] <ubitux> oh.
[15:50:46 CEST] <ubitux> ok, thanks :)
[15:51:08 CEST] <wbs> (many basic classes like strings and collections and such are toll-free bridged so you can treat a C based CFString as an NSString in objective C if you want as well)
[15:54:36 CEST] <rcombs> "toll-free bridge" has always been a funny concept to me
[15:55:14 CEST] <rcombs> it just means they're different names and APIs for interacting with the same structure
[15:56:02 CEST] <rcombs> I dunno why they give 'em separate names at all tbh
[15:56:46 CEST] <wbs> dunno if the corefoundation stuff was present at all in the original nextstep stuff, or if it was added as a compat measure when moving people over from old macos
[16:01:55 CEST] <ubitux> https://trac.ffmpeg.org/ticket/4238 ffs..
[16:20:22 CEST] <kierank> eugh, these add X threaded input are so ugly
[16:20:25 CEST] <kierank> hacking in threads
[16:31:03 CEST] <wm4> the consequence of implementing frame grabbers as demuxers, probably
[16:37:04 CEST] <kierank> implementing X as demuxers, yes
[16:37:49 CEST] Action: rcombs implements kierank as a demuxer
[17:12:47 CEST] <durandal_1707> wm4: why you dont write new lavd API?
[17:17:02 CEST] <cone-842> ffmpeg 03Clément BSsch 07master:ca7dc3ee901f: lavd: drop QTKit indev
[17:17:36 CEST] <ubitux> that was easier than expected
[17:17:42 CEST] <ubitux> should i try with vda?
[17:21:39 CEST] <durandal_1707> people should use lavf more
[17:26:13 CEST] <ubitux> so
[17:26:37 CEST] <ubitux> we link to QuartzCore to access QuartzCore/CoreImage.h
[17:26:43 CEST] <ubitux> but there is also a CoreImage framework
[17:26:57 CEST] <ubitux> why aren't we using it? what's the diff?
[17:28:03 CEST] <ubitux> ok, QuartzCore/CoreImage.h is including CoreImage/CoreImage.h
[17:28:12 CEST] <ubitux> pointless indirection i guess.
[17:30:15 CEST] <wm4> lol, nice
[17:31:17 CEST] <durandal_1707> lol vs doesnt have fft convolution or audio support
[17:31:20 CEST] <ubitux> so we probably link to QuartzCore for no reason 
[18:13:36 CEST] <sunny26> I have used value of reordered_opaque of avctx in av_frame in my custom hardware decoder. I am missing last frame of my video.
[18:13:44 CEST] <sunny26> I saw some of the example and none have used reordered_opaque in their decoder. 
[18:13:52 CEST] <sunny26> I am too much stuck and confused.
[18:14:02 CEST] <sunny26>  what should I do to make sure that my whole video plays perfectly
[18:16:29 CEST] <sunny26> Please help...
[18:18:20 CEST] <kierank> atomnuker: but but but cuda
[18:18:23 CEST] <kierank> CUDA!!!!!
[18:18:25 CEST] <kierank> oneone
[18:20:32 CEST] <JEEB> sunny26: so you've implemented something in libavcodec?
[18:21:26 CEST] <sunny26> JEEB: yes a custom decoder. Its based on the chip we use on our hardware.
[18:22:35 CEST] <sunny26> JEEB: am getting all frames in order, just missing the frame in last 1 second. I re-checked everything and I can now confirm its issue with timestamp.
[18:23:26 CEST] <sunny26> JEEB: can you please explain me how you guyz provide the av_frame the PTS (timestamp) to display it to user ?
[18:23:58 CEST] <sunny26> I am confused what to store and where to store :(
[18:28:24 CEST] <sunny26> ??
[18:39:12 CEST] <jkqxz> You record the pts from the packet as it goes into the decoder and then attach it to the corresponding frame when it goes out.
[18:39:28 CEST] <cone-842> ffmpeg 03Paul B Mahol 07master:2726b2d7e8dc: avfilter/vf_fftfilt: cache rdft contexts
[18:39:29 CEST] <cone-842> ffmpeg 03Paul B Mahol 07master:2170ca41f423: avfilter/vf_fftfilt: add support for more pixel formats
[18:40:10 CEST] <jkqxz> Decoding APIs generally have a way to carry the timestamp through so that it matches; if yours doesn't then you may need to do something else to reconstruct it on the other side.
[19:06:10 CEST] <cone-842> ffmpeg 03Paul B Mahol 07master:4705a80fb024: avfilter/vf_fftfilt: add generic timeline support
[19:33:37 CEST] <cone-842> ffmpeg 03Paul B Mahol 07master:b43cd6786246: avfilter/vf_fftfilt: make it possible to evaluate expressions per frame
[19:39:27 CEST] <wm4> clever for making some filters depend on it
[19:39:32 CEST] <wm4> making sure it can't be removed
[19:42:40 CEST] <kierank> I'm surprised the drama is about snow and not about h264 complaining on perfectly legal streams and confusing users
[19:42:44 CEST] <durandal_1707> wm4: no, minterpolate must not depend on snow
[19:42:53 CEST] <JEEB> kierank: the padded parameter set thing?
[19:42:58 CEST] <kierank> yeah
[19:45:00 CEST] <jamrial> kierank: make it verbose instead of warning or debug and push it
[19:45:33 CEST] <kierank> ok
[19:48:23 CEST] <wm4> kierank: the drama can be about whatever you like
[19:49:04 CEST] <kierank> at disneyland you can live out your imagination (tm)
[19:49:16 CEST] <durandal_1707> out of
[19:49:52 CEST] <kierank> wm4: ok now you're just trolling with that energy efficiency thing
[19:49:55 CEST] <kierank> a funny trolly
[19:50:49 CEST] <wm4> it's just the logical follow up to the post I replied to
[19:53:08 CEST] <kierank> wm4: there is no logical followup
[19:53:26 CEST] <jamrial> "carbon emissions" is a pretty silly argument in favor of a less cpu intensive approach for some functionality, yeah
[19:53:41 CEST] <jamrial> longer battery life would have been better
[19:54:01 CEST] <jamrial> that's what everyone and their dog uses when talking about efficiency
[19:55:57 CEST] <wm4> yeah, it's the real reason why anyone would care about energy use, while the rest is marketing BS
[19:58:34 CEST] <kierank> durandal_1707: at ffmpeg you can live outside of reality
[19:58:37 CEST] <kierank> not a big deal here
[20:00:12 CEST] <durandal_1707> kierank: why you telling me that?
[20:00:21 CEST] <kierank> 6:49:16 PM <"durandal_1707> out of
[20:00:25 CEST] <kierank> don't need disneyland
[20:01:21 CEST] <jamrial> also, why isn't everyone celebrating the fact we could remove a superfluous/obsolete module the same day the removal was suggested?
[20:01:41 CEST] <jkqxz> To my mind the more important thing is that not using any CPU lets you use the CPU for other things (such as the thing you're capturing).
[20:01:43 CEST] <jamrial> it's a huge progress out of the "ffmpeg doens't drop anything" moto
[20:02:56 CEST] <ubitux> jamrial: are you celebrating v4l & qtkit?
[20:03:04 CEST] <ubitux> or we dropped more i missed?
[20:03:33 CEST] <jamrial> ubitux: qtkit. v4l was disabled so it was basically removing commented out code
[20:03:45 CEST] <durandal_1707> prores, asf
[20:04:01 CEST] <ubitux> avresample :-°
[20:04:20 CEST] <jamrial> nevcairiel will be sad :p
[20:04:51 CEST] <durandal_1707> swscale
[20:04:56 CEST] <atomnuker> kierank: reality sucks
[20:05:13 CEST] <ubitux> so we still have 2 decoder and 2 encoder for prores?
[20:05:24 CEST] <durandal_1707> yes
[20:05:38 CEST] <atomnuker> durandal_1707 was too lazy to do comparisons IIRC
[20:05:50 CEST] <durandal_1707> decoder can be removed already
[20:06:46 CEST] <durandal_1707> atomnuker: decoders are similar, encoders are buggy vs correct
[20:07:43 CEST] <atomnuker> keep the correct one then, we could extend it later to be better
[20:15:59 CEST] <wm4> jamrial: because the old vdpau code is still in, we still have 3 or so prores things, and you still have to wait two years to fix API
[20:16:22 CEST] <wm4> there's lot of awful, and you can keep that all for yourself
[20:16:34 CEST] <jamrial> the prores stuff yeah, that's really lame
[20:16:51 CEST] <jamrial> but the two years deprecation period has been a thing since forever. and it's also in libav
[20:17:57 CEST] <jamrial> the upcoming bump once 3.4 is tagged will drop like 30 deprecated APIs
[20:18:53 CEST] <jamrial> i spent the last week fixing a couple depreactions that were imported from libav but weren't properly implemented, so they can now be removed without issues
[20:19:18 CEST] <jamrial> the less we complain the more time we'll have to actually work on getting rid of shit we don't need in the tree
[20:20:16 CEST] <atomnuker> when can you push it? I want to start cleaning
[20:20:19 CEST] <wm4> I'll believe it when ffserver actually disappears from the source tree
[20:20:36 CEST] <jamrial> atomnuker: after 3.4 is branched and tagged
[20:21:47 CEST] <atomnuker> when does that happen? its just a git command or two
[20:25:07 CEST] <jamrial> atomnuker: it's a lot more than that, and it should be this week or the next
[20:25:44 CEST] <BBB> so & can we remove snowenc?
[20:25:51 CEST] <BBB> that would be an incredible accomplishment
[20:26:25 CEST] <BBB> regarding native vmaf, the intention was always for the final product to be integerized, the current version is float, slow, but works and gives identical output to libvmaf
[20:26:34 CEST] <BBB> Im wondering if we should commit it as-is
[20:26:39 CEST] <BBB> what do you guys think?
[20:26:47 CEST] <BBB> work will continue, itll just be a little slow right now
[20:27:06 CEST] <BBB> (vmaf is like a not-shit psnr)
[20:27:57 CEST] <atomnuker> BBB: I like snow, I don't think it should be removed
[20:29:27 CEST] <jamrial> atomnuker: why? there are other native encoders you could use for whatever purpose you might have
[20:30:15 CEST] <jamrial> BBB: it could always be commited with the experimental flag set, if it's still considered a wip of sorts
[20:30:55 CEST] <jamrial> but if it gives identical output, it being slow isn't a reason to postpone it
[20:31:20 CEST] <jamrial> i mean, your vp9 decoder was initally pushed with no simd after all (or just one or two ssse3 functions)
[20:33:02 CEST] <BBB> fair enough
[20:33:07 CEST] <BBB> do we have experimental flags in lavfi?
[20:33:32 CEST] <jamrial> mmh, guess not...
[20:34:48 CEST] <jamrial> there's no capabilities field in AVFilter, but there's a flags_internal one
[20:35:01 CEST] <jamrial> shouldn't be hard to implement it, but probably not worth it
[20:35:18 CEST] <durandal_1707> no filter is experimental
[20:35:31 CEST] <durandal_1707> every filter is welcome
[20:42:06 CEST] <jamrial> wm4: also, now that you mention vdpau, i checked and the bump patch i sent gets rid of it
[20:42:07 CEST] <jamrial> or at least of anything inside every current vdpau FF_API_ wrapper
[20:43:23 CEST] <BtbN> that's the ancient horrible vdpau api
[20:45:19 CEST] <nevcairiel> the bump makes it entirely nonfunctional
[20:45:25 CEST] <nevcairiel> we can purge the old-old vdpau code after th at
[20:46:32 CEST] <jamrial> BtbN: yes, which is what wm4 talked about i presume
[21:44:02 CEST] <jkqxz> atomnuker:  If you use Vulkan, what if your source language for shaders?
[21:44:44 CEST] <jkqxz> Or do we check in SPIR-V files?
[21:48:25 CEST] <jkqxz> I would probably be more agreeable to Vulkan if it worked everywhere, but it totally doesn't.
[21:49:18 CEST] <jkqxz> OpenCL (probably 1.2) feels like a much more logical choice, because it has much wider hardware support (including interop with every API you think of) and a standard with a well-defined source language to use.
[21:50:30 CEST] <BtbN> Yeah, cleaning up the OpenCL support to have an actual OpenCL picture format
[21:50:38 CEST] <BtbN> Not sure if there isn't one already?
[21:50:45 CEST] <BtbN> So you can build filter chains with OpenCL
[21:51:56 CEST] <jkqxz> Some crazy idiot wrote one for libav, but it's stalled there due to lack of actual use cases.
[21:52:15 CEST] <jkqxz> If someone wants to write shaders here then it could be submitted here to use.
[21:52:17 CEST] <BtbN> OpenGL would be even wider supported
[21:52:23 CEST] <BtbN> And you can do a lot of things with GLSL shaders
[21:52:38 CEST] <jkqxz> OpenGL is a horrific thing to integrate, though, due to all the global state.
[21:52:49 CEST] <durandal_1707> its unstable
[21:53:09 CEST] <atomnuker> jkqxz: require glslang for compilation
[21:53:46 CEST] <atomnuker> shaders would be in e.g. libavfilter/vulkan/filter_name.frag/vert
[21:54:14 CEST] <BtbN> But what can vulkan do that OpenCL can't?
[21:54:21 CEST] <wm4> OpenGL, to be completely save, would either need to save/restore contexts on filter entry, or have to run on a separate thread
[21:54:50 CEST] <wm4> atomnuker: there's also this idea of making mpv's renderer a library, which then could provide GL and Vulkan
[21:54:52 CEST] <atomnuker> BtbN: are you reading my emails at all?
[21:55:10 CEST] <BtbN> There are so many mails on ffmpeg-devel, I do not read all of them, no
[21:55:14 CEST] <wm4> OpenCL probably can't do fragment shaders and rasterization, so no OpenCL
[21:55:43 CEST] <jkqxz> wm4:  I'm wondering what "save" could be a typo for there.  With OpenGL it's definitely not "sane" or "safe"...
[21:58:35 CEST] <atomnuker> BtbN: exactly what wm4 said (without rasterization its also unusable for filters) plus for anyone using vulkan it wouldn't require an opencl -> vulkan interop (something which I guarantee won't happen)
[21:59:23 CEST] <BtbN> So you want to convert from CUDA frames to Vulkan frames, and then back to CUDA frames for encoding? That sounds slowish. For this particular filter encoding with nvenc seems rare though
[21:59:25 CEST] <jkqxz> Why is it unusable for filters?  It will duplicate pretty much exactly how existing filters work on images.
[22:00:11 CEST] <jkqxz> Conversion is completely free in a proper implementation.  (Can't guarantee that Nvidia wouldn't nobble it deliberately, but you'd hope they'd see more value in not doing.)
[22:00:13 CEST] <atomnuker> jkqxz: because that's exactly why I need something with rasterization and shader support
[22:00:24 CEST] <atomnuker> I don't want to implement a full rasterizer
[22:00:29 CEST] <BtbN> jkqxz, the existing CUDA interop needs a full memcpy
[22:00:40 CEST] <BtbN> for every conversion
[22:00:42 CEST] <atomnuker> and I need it for stuff trivial in shader but hard in C
[22:01:35 CEST] <wm4> you want to do 3D rendering?
[22:02:28 CEST] <jkqxz> BtbN:  The existing CUDA interop with what?
[22:02:32 CEST] <BtbN> OpenGL
[22:02:34 CEST] <atomnuker> lol no, but for stuff like chromatic aberration a shader is just a few lines
[22:03:43 CEST] <atomnuker> (but we could do filters which require 3D like 360 video conversions)
[22:04:38 CEST] <jkqxz> BtbN:  Well that seems pretty terrible.  I assume they have some reason for doing it (maybe commercial), but it's not a problem for anyone else (with OpenCL <-> whatever, at least).
[22:05:03 CEST] <BtbN> The OpenGL interop works by giving you a CUDA pointer for an OpenGL texture
[22:05:19 CEST] <BtbN> So if you have pre-existing CUDA memory, you can't just make a texutre out of it.
[22:05:25 CEST] <BtbN> You have to create a new one, and memcpy over
[22:05:52 CEST] <jkqxz> Oh, right.  But you can render to the OpenGL texture using that pointer?
[22:06:01 CEST] <BtbN> only while it's mapped
[22:06:31 CEST] <jkqxz> Then that is the same as other stuff.  Arbitrary native things can't necessarily be mapped, but ones made with some set of known parameters can.
[22:06:54 CEST] <BtbN> With how cuvid works, you can't avoid a memcpy anyway
[22:07:05 CEST] <BtbN> So for that it doesn't matter where it copies to
[22:07:28 CEST] <BtbN> But for nvenc, I don't see a way to feed it a non CUDA input frame without an intermediate memcpy
[22:08:51 CEST] <jkqxz> What fails about mapping OpenGL -> CUDA and then give it that CUDA frame?  You don't know when you can have the frame back?
[22:09:15 CEST] <BtbN> That you'd have to drag the OpenGL texture along with the frame
[22:09:37 CEST] <BtbN> as the pointer is only valid as long as the OpenGL texture is mapped.
[22:09:45 CEST] <BtbN> And I don't think you can use the texture without unmapping it first
[22:10:46 CEST] <atomnuker> BtbN: couldn't you use the opengl texture pointer to e.g. do color conversion out of place?
[22:11:26 CEST] <BtbN> hm?
[22:12:00 CEST] <BtbN> Also, the CUDA<->Vulkan interop already half exists
[22:12:29 CEST] <BtbN> it looks a bit more manageable than the OpenGL one, from what is there so far
[22:12:41 CEST] <BtbN> https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/doc/specs/vulkan/appendices/VK_NV_external_memory.txt
[22:12:42 CEST] <atomnuker> oh, nvm, I thought this was CUDA->OpenGL, not the opposite
[22:13:01 CEST] <BtbN> Well, there is only one interop for CUDA<->OpenGL
[22:13:10 CEST] <BtbN> and that is "Get a CUdevptr for a pre-existing OpenGL texture"
[22:13:25 CEST] <BtbN> If you want to use CUDA memory as OpenGL texture, you got to cuMemcpy it in there
[22:14:24 CEST] <atomnuker> this is silly
[22:17:48 CEST] <BtbN> The Vulkan API seems to work the exact other way around
[22:17:58 CEST] <BtbN> so for getting a Vulkan Texture to CUDA, you need a memcpy
[22:30:00 CEST] <kierank> wm4: runtime cpu flag changes, wtf
[22:30:22 CEST] <kierank> there are many levels of insanity on the ml today
[22:34:44 CEST] <jkqxz> Migrate your VM from a machine with AVX to one without!  This is totally an important and common use-case that ffmpeg should add lots of complexity to support.
[22:35:48 CEST] <jamrial> jkqxz: that's not a runtime cpu flag change example :P
[22:36:08 CEST] <BtbN> atomnuker, I just now got all the mails you were talking about.
[22:36:14 CEST] <BtbN> Either the ML or my Mailserver is horribly slow
[22:36:44 CEST] <kierank> jkqxz: oh lord
[22:36:57 CEST] <jamrial> what michael means is, i think, something like calling av_cpu_force_flags() mid decoding 
[22:37:10 CEST] <nevcairiel> that wont work anyway
[22:37:16 CEST] <nevcairiel> we dont re-init DSP pointers either
[22:37:37 CEST] <jamrial> no, but new buffers will be allocated
[22:37:42 CEST] <kierank> jkqxz: what happens if the suspended process is in the middle of an avx function?
[22:37:53 CEST] <kierank> very likely to be if it is decoding h264 or whatever
[22:38:00 CEST] Action: kierank never thought of this before
[22:38:24 CEST] <BtbN> At least VMWare ESXi does not let you do that to begin with
[22:38:25 CEST] <jkqxz> You have to catch SIGILL, note where you are, undo the partial results in the function, then start it again in the non-AVX version.
[22:38:44 CEST] <jkqxz> Easy!
[22:38:45 CEST] <BtbN> If you have a group of hosts with migration, it will automatically limit the CPU features to those of the least featureful host
[22:39:14 CEST] <BtbN> Probably a good idea, otherwise you end up with various insanities
[22:49:42 CEST] <cone-842> ffmpeg 03James Almer 07master:6cadbb16e971: avcodec: add AV_HWACCEL_CODEC_CAP_EXPERIMENTAL flag
[00:00:00 CEST] --- Tue Sep  5 2017