Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2017

1 participants
60 discussions

ffmpeg-devel.log.20170904
by burek 05 Sep '17

05 Sep '17

[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=3575f…>. [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=3575f… [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/appen… [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

1 0

ffmpeg.log.20170904
by burek 05 Sep '17

05 Sep '17

[00:03:01 CEST] <relaxed> anybody here have an aarch64 system up and running? [00:33:44 CEST] <sarnex> hi, im trying to output raw x11grab data into a v4l2loopback device. i get an error that v4l2loopback only supports raw video, but looking at the v4l2loopback page, there is a video format for h264 and hevc and others. am i missing something here? [00:34:10 CEST] <sarnex> pixel format i mean [00:54:49 CEST] <relaxed> sarnex: did you try, ffmpeg -i input -f v4l2 -y /dev/video0 [00:55:06 CEST] <sarnex> relaxed: i need to use x11grab as input, my output is v4l2 [00:55:17 CEST] <sarnex> oh sorry i mistread [00:55:19 CEST] <sarnex> one sec [00:56:05 CEST] <relaxed> is this reverse webrtc? [00:56:22 CEST] <sarnex> same error [00:56:31 CEST] <sarnex> relaxed: yeah basically i need to create a fake webcam of my screen [00:56:46 CEST] <relaxed> pastebin the command and all output [00:56:48 CEST] <sarnex> because skype screen share is nonexistant now i have to use another service which uses webrtc [00:57:10 CEST] <sarnex> relaxed: https://pastebin.com/raw/xtiB14GT [00:58:00 CEST] <relaxed> oh, I think you have to have the v4l loopback device loaded via the kernel [00:58:09 CEST] <sarnex> yep i have it loaded [00:58:13 CEST] <relaxed> have you done that? [00:58:16 CEST] <relaxed> ok [00:58:16 CEST] <sarnex> otherwise /dev/video0 doesnt exist [00:58:22 CEST] <acos> Hmmm [00:58:54 CEST] <relaxed> you didn't post the command [00:59:02 CEST] <sarnex> sorry [00:59:36 CEST] <sarnex> relaxed: https://pastebin.com/raw/xcDHTV1k [01:00:17 CEST] <relaxed> omit "-vcodec libx264 -pix_fmt yuv420p -threads 16" [01:00:37 CEST] <relaxed> you can't send h264 to the loopback device [01:00:50 CEST] <sarnex> right, im asking why that is because it looks like the loopback device supports it [01:00:51 CEST] <relaxed> webrtc will handle the encoding [01:01:10 CEST] <sarnex> for example https://github.com/umlaeute/v4l2loopback/blob/master/v4l2loopback_formats.h [01:05:42 CEST] <relaxed> what does the software reading /dev/video0 expect ? [01:06:02 CEST] <sarnex> im not sure, but i dont understand why it errors [01:06:17 CEST] <sarnex> if webrtc expects raw thats fine [01:08:58 CEST] <relaxed> you can send anything to /dev/video0, just use -f <format or container> -y /dev/video0 [01:09:24 CEST] <sarnex> if i use h264 for the format ffmpeg gives me an error telling me its not supported [01:09:46 CEST] <sarnex> -y has no effect [01:10:01 CEST] <relaxed> then send it raw by omitting "-vcodec libx264 -pix_fmt yuv420p -threads 16" [01:10:33 CEST] <sarnex> yeah im not trying to get it to work, i understand that raw works, im wondering why i cant send h264 when it looks like the output supports it [01:10:58 CEST] <sarnex> maybe this is better for #ffmpeg-devel [01:12:03 CEST] <ZexaronS> hello [01:12:17 CEST] <ZexaronS> does ffmpeg support m4s ? [01:12:28 CEST] <JEEB> that's just fragmented ISOBMFF [01:12:29 CEST] <ZexaronS> the segments streaming [01:12:54 CEST] <JEEB> if you want specifically DASH with segments and separated initialization segments, then just set output file name to .mpd and -f dash [01:13:03 CEST] <JEEB> in other words, yes [01:13:04 CEST] <ZexaronS> Trying to put them together [01:13:52 CEST] <ZexaronS> Not sure if it's dash, it's not youtube, the magic bits start with 4sidx [01:15:24 CEST] <JEEB> that's ISOBMFF [01:15:34 CEST] <ZexaronS> oh ok [01:15:36 CEST] <JEEB> (in colloquial talk "mp4") [01:15:58 CEST] <JEEB> ("ISO Base Media File Format") [01:16:55 CEST] <ZexaronS> but it doesn't look like a simple concat will work in this case ? [01:17:15 CEST] <ZexaronS> I've seen other fragmented video before, which can be playable, first time coming across this [01:18:18 CEST] <JEEB> fragmented isobmff should be concat'able in quite a few cases. just concat the start segment first ("initialization segment"), and then the rest [01:18:42 CEST] <JEEB> only problem could be clear key encryption or DRM [01:18:52 CEST] <ZexaronS> actually i need to output as m4a or the raw audio codec, since this is the audio I need to merge with video which I was able to get with an utility, audio wasn't detected auto so I had to manually pull the segments myself [01:19:05 CEST] <ZexaronS> Oh no this is free, it's not paid content [01:19:35 CEST] <ZexaronS> but pretty much everything is moving to fragmented streaming these days [01:20:16 CEST] <JEEB> because it lets them utilize the already available CDN resources for HTTP, mostly [01:20:23 CEST] <JEEB> as in, infrastructure [01:21:12 CEST] <ZexaronS> the init segment states it is a mp4a audio, but no info on codec [01:23:56 CEST] <JEEB> ffprobe can tell you the details since it contains the initialization data :P I would probably do it after I concat a few of the data fragments after it, though [01:24:01 CEST] <JEEB> just in case [01:24:10 CEST] <JEEB> since audio doesn't really require as much initialization data [01:24:31 CEST] <JEEB> (compared to the parameter sets etc in AVC/HEVC) [01:26:09 CEST] <ZexaronS> JEEB: actually I want the other way around, put segments to one file, the -f dash thing is not what I want... confusion sorry [01:27:18 CEST] <JEEB> yes, my answers were if you wanted to output m4s which is what most people who ask like that want :P [01:27:51 CEST] <JEEB> and in theory you could feed the files to FFmpeg as one stream of bytes, but it will not currently read the manifest and do it automatically [01:28:13 CEST] <JEEB> and if you're gonna just feed the bytes to it you might as well just concatenate the segments yourself [01:28:14 CEST] <ZexaronS> is the -v 40 still the max loglevel or should -loglevel verbose work, because I heard -loglevel verbose might not catch everything ... but I don't want debug level either [01:28:21 CEST] <ZexaronS> sorry if I jumped the topic a bit [01:28:26 CEST] <JEEB> don't use the numbers [01:28:31 CEST] <JEEB> the log levels are documented in help [01:28:40 CEST] <JEEB> and I've always used -v NAME [01:28:45 CEST] <JEEB> never -loglevel [01:29:04 CEST] <JEEB> but they might be doing the same thing [01:29:21 CEST] <JEEB> yea, they map to the same thing [01:30:06 CEST] <JEEB> here, have the listing http://up-cat.net/p/24daca75 [01:30:27 CEST] <ZexaronS> JEEB: What does feeding the bytes mean, and what does "yourself" mean ... sorry, when talking concatenate I'm talking about the -concat thing, but then concat must be doing something to figure out, it's just just appending data as if I would copy paste hex from all files to one [01:31:02 CEST] <JEEB> what I'm talking about is that the segments should be just concat'able without FFmpeg being anywhere [01:31:16 CEST] <JEEB> cat init.m4s file1.m4s file2.m4s etc [01:32:01 CEST] <ZexaronS> oh if that's the case then much easier ... but im on windows heh need to find an utility for that, probably already have one but never needed the feature [01:32:58 CEST] <JEEB> copy /b seems to do something similar :P [01:33:05 CEST] <ZexaronS> seems like it yeah [01:33:37 CEST] <JEEB> just remember to put the initialization segment first and it should already be readable by ffprobe [01:33:49 CEST] <JEEB> then after you get the first segment in, it should show some decoded audio [01:37:02 CEST] <ZexaronS> uh it didn't work well without /b, outputed like 1.2 MB, but with /b it's not working either, it's the right size that's expected, but MPC-HC can't play it [01:37:19 CEST] <ZexaronS> plus, from the looks if it, im not sure if it was going alphabetical order [01:37:29 CEST] <ZexaronS> it could be broken even if it did play [01:37:40 CEST] <JEEB> yea, if you didn't specify the file names :P [01:38:03 CEST] <ZexaronS> well ofcourse because there's 1500 of them [01:38:12 CEST] <ZexaronS> so i have to use a list or *.m4s [01:38:18 CEST] <JEEB> scripting, ho [01:38:26 CEST] <JEEB> that's why I said you should just put the audio stream's initialization segment first, then a single audio fragment [01:38:31 CEST] <JEEB> that way you could have checked it [01:38:41 CEST] <JEEB> with both ffprobe and if something was weird, with ffmpeg etc [01:38:43 CEST] <JEEB> :P [01:39:14 CEST] <ZexaronS> well, I'm used to doing fiddly diddly stuff manually that can take hours but need to figure out something here [01:40:15 CEST] <ZexaronS> I was using excel to generate the iterated URL links, pasted results to Sheet2, exported to TXT, put that into a downloader, i could do the same to segment-1, segment-2, export that as .txt and find somethign that accepts a list then [01:40:17 CEST] <JEEB> that's why I'm fucking telling you to start with the audio stream's init segment [01:40:22 CEST] <JEEB> and then single audio fragment [01:40:22 CEST] <JEEB> :V [01:40:30 CEST] <JEEB> that way you can test if the shit works [01:40:40 CEST] <ZexaronS> What does this init segment look like? [01:40:42 CEST] <JEEB> if that works, then you can start working on your further concatenation [01:40:52 CEST] <JEEB> it's marked in the DASH xml manifest as such [01:41:10 CEST] <ZexaronS> there's no DASH xml manifest [01:41:25 CEST] <JEEB> where there has to be something to control the player :P [01:41:26 CEST] <ZexaronS> there's only master.json with a list of segments filenames [01:41:35 CEST] <JEEB> also if this is something usually used then just fucking use youtube-dl [01:41:39 CEST] <JEEB> which supports most of them fucking sites [01:41:48 CEST] <ZexaronS> Oh, I'm not controlling any player, I'm pulling from remote [01:41:56 CEST] <JEEB> I *know* [01:42:06 CEST] <ZexaronS> It doesn't work, because it doesn't detect audio links [01:42:15 CEST] <JEEB> youtube-dl? [01:42:29 CEST] <ZexaronS> I got it down without having to deal with fragments, but video only [01:42:56 CEST] <JEEB> anyways, I mean the motherfucking thing be it json or XML should have the initialization segment info *somewhere*, otherwise the motherfucking thing wouldn't be playable [01:43:23 CEST] <ZexaronS> Indeed it might work with youtube-dl, but I'm way not experienced with it yet, I simply got the fragments down to be on the safe side while I take days/weeks to figure out youtube-dl [01:43:23 CEST] <JEEB> it's possible for the first segment to be an init segment as well, but I generally don't see it being used [01:43:33 CEST] <JEEB> uhh [01:43:48 CEST] <ZexaronS> Yes there is an init_segment part and it's gibberish ... I tried to put it in URL but it said bad requesr or 404 [01:43:52 CEST] <ZexaronS> request* [01:44:12 CEST] <JEEB> youtube-dl is literally `youtube-dl -F "URL"` to list all available formats (default is the highest quality shit), and `youtube-dl "URL" to dwnload that` [01:44:15 CEST] <ZexaronS> the init_segment name is a very long string "ifdhsidsdsds8d//dsd7cd7dxxcsx7dc" [01:44:40 CEST] <JEEB> it will save both you and me time if you just use motherfucking youtube-dl if it supports your fucking site [01:45:39 CEST] <ZexaronS> I did tried all day, well, after a few attemtps i didn't bang my head on the wall ofcourse so I want another path, I'll try again [01:45:55 CEST] <ZexaronS> I went another path* [01:46:17 CEST] <JEEB> just make sure you have the newest youtube-dl, they release pretty often (and smetimes the sites change and that hasn't been yet updated to the app) [01:46:23 CEST] <JEEB> in which case oyu go report an issue to them [01:46:34 CEST] <JEEB> because I don't want to start telling you how to do base64 etc to get the init segment from that custom JSON shit, you know. it's not worth my fucking time if there [01:47:11 CEST] <JEEB> esp. if youtube-dl supports that fucking site [01:48:46 CEST] <ZexaronS> The first time I tried youtube-dl a couple of times in morning I didn't yet know as much, I didn't tried pointing to the master.json, doesn't work with only base url (cannot send HEAD request) [01:49:02 CEST] <JEEB> youtube-dl generally takes in the normal URLs [01:49:07 CEST] <JEEB> as in, what the browser would access [01:49:34 CEST] <JEEB> then it accesses where needed to get the required information [01:50:05 CEST] <ZexaronS> yeah the base url simply reports "not found" but it is actually connecting to a server, it's not a browser error, it's some server response [01:51:37 CEST] <ZexaronS> okay i pointed it to master.json and it had same HEAD error and said "treating it as a generic webpage" extracging .. so it just downloaded master.json [01:52:06 CEST] <ZexaronS> it said 403 Forbidden when trying to send HEAD request [01:57:00 CEST] <ZexaronS> Okay i'll move this talk to youtube-dl but ... I tried all known url combinations and it's either 404 or 403, it does report the segment-1, but that's just one segment, it's not detecting the full thing [02:59:45 CEST] <ZexaronS> JEEB: finally solved this thing omg it was a circus for an hour, I think I reinstalled python 3 times, did a buch of stuff, this worked https://github.com/alexeygrigorev/vimeo-download - I had to physicaly remove the video part def# from the script so it would just handle URL, I don't know what the script does yet, but it seems to be recoding the m4s audios to a mp3 file with ftypiso5 mp41, codec is AAC as expected, .mp3 might just [02:59:46 CEST] <ZexaronS> be script bug [03:00:25 CEST] <ZexaronS> but the point is, the audio is in one file ... it's being generated while segments are downloading and it works playable fine, MISSION SUCCESS this was one big day 3 AM asta lavista baby [04:22:19 CEST] <ZexaronS> python is ridicolous, doesn't work if I run batch file, but it works if I paste the whole same command into an already open CMD, python probably is one of the most weird things ever for windows, it's just not meant to be on windows [04:22:37 CEST] <ZexaronS> spent 30 minutes figuring this out, annoying as crap [04:23:04 CEST] <ZexaronS> I lose so much time when i have to deal with python, the whole thing has been POS as long as I know it [04:36:59 CEST] <acos> Rip. ZexaronS sounds like it's not in the path variable. [04:37:32 CEST] <ZexaronS> actually i was using the direct "C:program files -...exe" the whole time [04:37:39 CEST] <ZexaronS> it pust out some error in module [04:38:15 CEST] <ZexaronS> it runs and throws some traceback error on "resp.json" that the script is using [04:38:55 CEST] <acos> Ooooo. Never used python [04:38:58 CEST] <ZexaronS> jsondecoder error [04:42:27 CEST] <ZexaronS> https://pastebin.com/RCUceGGJ [05:46:26 CEST] <cryptodechange> Finally getting around to encoding IVTC dvd stuff [05:46:39 CEST] <cryptodechange> using -vf fieldmatch,yadif=deint=interlaced,decimate, I get [05:46:50 CEST] <cryptodechange> [Parsed_fieldmatch_0 @ 0x493d220] Frame #274 at 9.142 is still interlaced [05:46:55 CEST] <cryptodechange> every now and then [05:55:02 CEST] <cryptodechange> doing some googling, it seems that's what yadif is there for? to deinterlace any leftovers? [08:38:10 CEST] <mozzarella> guys [08:38:16 CEST] <mozzarella> is there anyone using windows in here? [08:38:37 CEST] <dystopia_> yep [08:39:41 CEST] <mozzarella> dystopia_: with mpv I can move forward/backward in a video, of one minute using the top and bottom arrow keys, and 5 seconds using the left and right arrow keys, is there anything like that with windows media player? [08:40:27 CEST] <dystopia_> i havent used windows media player in over a decade [08:40:40 CEST] <dystopia_> i use media player classic [08:40:46 CEST] <mozzarella> does it still exist? is it the default player on windows 10? [08:40:51 CEST] <dystopia_> im sure windows media player has shortcuts though [08:41:01 CEST] <mozzarella> what's that [08:41:02 CEST] <dystopia_> no, you have to install it [08:41:07 CEST] <mozzarella> is that the one using the old gui [08:41:20 CEST] <dystopia_> https://mpc-hc.org/ [08:41:41 CEST] <mozzarella> how do you watch videos on windows 10, then? [08:42:18 CEST] <dystopia_> im on windows 7 and use media player classic [08:42:27 CEST] <dystopia_> it also workd on 10 or any other version of windows [08:43:18 CEST] <dystopia_> windows media player was a bloated mess the last time i looked at it [08:43:23 CEST] <dystopia_> which was probably in win xp [08:43:30 CEST] <dystopia_> i doubt it has improved since [11:55:53 CEST] <next> Hey. I need to encode a video with rounded edges, which team does this? https://s26.postimg.org/6phtyllah/image.png [12:07:03 CEST] <sagax> hi all! [12:07:24 CEST] <sagax> how to convert x264 video to best images? [12:07:51 CEST] <sagax> Stream #0:0: Video: h264 (Main), yuv420p, 1920x1080, 24.17 fps, 24 tbr, 1200k tbn, 48 tbc [12:12:21 CEST] <klaxa> next: maybe you can use a transparent image with rounded corners as an overlay filter [12:12:35 CEST] <klaxa> sagax: what are "best images"? [12:14:09 CEST] <sagax> like as this ffmpeg -i video.h264 output_%d.jpg but with best quality to image [12:14:15 CEST] <klaxa> use png [12:14:57 CEST] <sagax> to divide into frames [12:15:38 CEST] <sagax> with minimum frame size as possible with best quality [12:15:49 CEST] <klaxa> use png and then use a png optimizer [12:16:31 CEST] <klaxa> png is lossless, so the frames will be pixel-perfect [12:19:41 CEST] <sagax> ok, thanks, but how to divide to frame? [12:19:50 CEST] <sagax> frames* [12:20:19 CEST] <klaxa> it will output every frame as a single png [12:20:32 CEST] <klaxa> is that not what you want? [12:21:00 CEST] <mannasty> anyone here [13:22:02 CEST] <velix> Is there a secure way to create an MP4 without audio? I've often seen players go insane without audio. [13:22:30 CEST] <velix> maybe just with silence at lowest AAC compression rate? [13:22:36 CEST] <velix> eehe lowest AAC bitrate [13:25:03 CEST] <DHE> avfilter anullsrc can generate a silent audio stream which you can compress at low bitrate [13:27:16 CEST] <velix> DHE: thanks. What's the lowest bitrate allowed in internal AAC encoder? [13:30:02 CEST] <velix> How do I use anullsrc correctly? I tried -af [13:30:20 CEST] <DHE> -filter_complex anullsrc[silence] -map [silence] -map [0:v] [13:30:31 CEST] <velix> oops thx [13:30:54 CEST] <DHE> oops, -map 0:v (no [braces]) [13:31:16 CEST] <velix> DHE: thx [13:32:10 CEST] <velix> DHE: can I set =48000:mono ? [13:33:03 CEST] <velix> DHE: maybe -i anullsrc=r=48000 ? [13:33:33 CEST] <velix> ah anullsrc=r=48000:cl=mono ? [13:43:35 CEST] <velix> That's my complete line: ffmpeg -y -hide_banner -i "mov\01.mp4" -vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2" -c:v libx264 -crf 23 -preset fast -framerate 25 -pix_fmt yuv420p -filter_complex anullsrc=r=11025:cl=mono[silence] -map [silence] -map 0:v -c:a aac -b:a 1k -ac 1 01.mkv [13:44:15 CEST] <velix> illarbox/Letterbox to 720p + silence [13:44:22 CEST] <velix> pillarbox [13:45:57 CEST] <velix> Interesting, there seems to be a problem. It's stuck at Frame 2371 and encodes it since about 4 minutes now. [13:46:16 CEST] <velix> the speed increses to 300x [13:46:20 CEST] <velix> now it's 303 [13:46:41 CEST] <velix> now 400 [13:47:41 CEST] <velix> It doesn't like silence as it seems. [14:11:25 CEST] <velix> Seems to be a bug. [14:14:24 CEST] <Nacht> Cropping and scaling video so it fits on instagram (1080x1350) makes me feel so dirty [14:16:05 CEST] <velix> Nacht: as long as the images aren't dirty, Instagram will accept it ;) [14:16:16 CEST] <Nacht> I just hate vertical video :/ [14:16:44 CEST] <velix> Nacht: People are taller than wider, why use widescreen then. I don't care about the people around my girlfriend. [14:31:28 CEST] <velix> Yeah, found a bug. [14:31:54 CEST] <velix> "-filter_complex anullsrc" runs endless when not adding -shortest [14:38:48 CEST] <durandal_1707> velix: thats not bug [14:39:07 CEST] <velix> durandal_1707: but it's not an expected behavior. [14:40:07 CEST] <durandal_1707> velix: really? for what? [14:40:31 CEST] <velix> durandal_1707: Actually, I would expect it to stop, after the video has been processed. Just like a normal filter. [14:41:14 CEST] <durandal_1707> use shortest [14:41:26 CEST] <durandal_1707> anullsrc never endds [14:42:47 CEST] <velix> durandal_1707: yeah, works fine with -shortest. [14:51:51 CEST] <velix> durandal_1707: Do you like my line for pillar- and letterbox? ffmpeg -y -hide_banner -i "mov\01.mp4" -vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2" -c:v libx264 -crf 23 -preset fast -framerate 25 -pix_fmt yuv420p -filter_complex anullsrc=r=11025:cl=mono[silence] -map [silence] -map 0:v -c:a aac -b:a 1k -ac 1 -shortest 01.mkv [14:53:37 CEST] <durandal_1707> its fine from quick look [14:54:17 CEST] <velix> durandal_1707: Also works nice. I love ffmpeg [15:05:37 CEST] <velix> Hmm, shouldn't this work? I'm getting a big file, but I can see the png only. [15:05:37 CEST] <velix> ffmpeg -i "concat:01.png|01.mkv" -c copy output_video.mp4 [15:09:52 CEST] <velix> need concat filter as it seems [15:11:44 CEST] <velix> also doesn't work: ffmpeg -loop 1 -framerate 25 -t 3 -i 01.png -t 3 -f lavfi -i aevalsrc=0 -i 01.mkv -filter_complex '[0:0] [1:0] [2:0] [2:1] concat=n=2:v=1:a=1' -movflags faststart 01.mp4 [15:21:31 CEST] <velix> Got it: ffmpeg -r 25 -loop 1 -t 3 -i 01.png -i 01.mkv -f lavfi -t 3 -i aevalsrc=0 -filter_complex "[0:v] [2:a] [1:v] [1:a] concat=n=2:v=1:a=1 [v] [a]" -c:v libx264 -c:a aac -map "[v]" -map "[a]" 01.mp4 [15:22:00 CEST] <velix> nah, this reencodes anything :( [15:24:51 CEST] <velix> Is this even possible? [15:25:39 CEST] <velix> Do I need to convert the image to video firsT? [15:27:36 CEST] <durandal_1707> yes, concat demuxer wotks only with same codecs [15:28:21 CEST] <velix> durandal_1707: okay [15:30:42 CEST] <velix> durandal_1707: ffmpeg -i 01.png -loop 1 -framerate 25 -t 3 -c:v libx264 -crf 23 -preset fast -framerate 25 -pix_fmt yuv420p -filter_complex anullsrc=r=11025:cl=mono[silence] -map [silence] -map 0:v -c:a aac -b:a 8k -ac 1 -shortest 01_title.mkv [15:30:55 CEST] <velix> durandal_1707: this doesn't create a three second video :( [15:31:55 CEST] <velix> durandal_1707: DONT ANSWER - found the bug [15:32:01 CEST] <velix> eeh my failure [15:32:31 CEST] <durandal_1707> yeah, try loop filter to loop single images [15:34:51 CEST] <velix> durandal_1707: the order was wrong ;) [15:40:55 CEST] <velix> durandal_1707: when concating two mkvs with same codec to MP4, why does it do a reeconde? [15:41:55 CEST] <velix> oh hell, I need concat demuxer [15:42:02 CEST] <durandal_1707> velix: yes [15:42:23 CEST] <velix> durandal_1707: does this work on file level only? (input.txt) [15:43:35 CEST] <durandal_1707> read documentation [15:44:11 CEST] <velix> :( [15:44:12 CEST] <velix> ok [16:49:37 CEST] <Eldarko> Alloha! Could anyone give me a link to an explanation of ffmpeg writing files with timestamp in a future? [16:50:29 CEST] <Eldarko> i mean EXT-X-PROGRAM-DATE-TIME [17:41:44 CEST] <Eldarko> Oh, i got disconnected. Did anyone answer my question about time in ffmpeg-generated playlist? [17:42:40 CEST] <c_14> No, but you might want to read the hls spec [17:45:06 CEST] <c_14> https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3… [17:45:09 CEST] <Eldarko> I did read it multiple times, can you specify spec page or something? [17:45:55 CEST] <c_14> the one I just linked [17:46:10 CEST] <JEEB> (the link contains a reference to a section) [17:50:49 CEST] <Eldarko> Yep, thank you, except it does not help ) we have a same hls_time set for every instance, and on some cameras segment length in ±19seconds [17:51:08 CEST] <Eldarko> is* [17:53:16 CEST] <Eldarko> so instead of target time of 10 seconds we get from 13-19 seconds segments [18:03:35 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. can anyone please help ? [18:04:36 CEST] <sunny26> I saw some of the example and none have used reordered_opaque in their decoder. [18:05:05 CEST] <sunny26> I am too much stuck and confused. [18:05:23 CEST] <sunny26> what should I do to make sure that my whole video plays perfectly [18:05:33 CEST] <sunny26> Please help... [18:08:14 CEST] <JEEB> sunny26: if you are developing a decoder module within avcodec then you should poke the -devel channel. [18:37:13 CEST] <next> <next> Hey. I need to encode a video with rounded edges, which team does this? https://s26.postimg.org/6phtyllah/image.png [18:37:13 CEST] <next> <sagax> hi all! [18:43:03 CEST] <kepstin> next: not sure what you're asking [18:43:16 CEST] <kepstin> next: what do you mean by "team"? [18:44:36 CEST] <next> How to make the edges of video rounded? ffmpeg -i test.mkv ???? [18:45:52 CEST] <kepstin> next: you'll have to describe better what you want to do. What does your input look like? What do you want the output to look like? [18:47:16 CEST] <kepstin> the picture you posted looks like a telecine of a misaligned film [18:50:56 CEST] <next> http://pix.toile-libre.org/upload/original/1504543822.png [18:52:50 CEST] <next> How to make edges round? [18:53:05 CEST] <kepstin> the edges are already round in that picture... [18:53:31 CEST] <next> This is an example of what I need. [18:54:07 CEST] <alqemyst> Hi, does anybody has experience with nvenc and cuvid? My kernel is breaking after some uptime. All suggestion are more than welcome. [18:54:30 CEST] <c3-Win> next: that's called loading your footage into a video editor and applying an effect... or you could create an overlay image and see if ffmpeg will apply it the way you want to. [18:54:35 CEST] <BtbN> "your kernel is breaking"? [18:54:38 CEST] <kepstin> oh, so you have a rectangular video source, and you want to apply a rounded corner film effect to it? [18:54:39 CEST] <BtbN> Update it and the driver I'd say. [18:55:23 CEST] <next> <c3-Win> ???? [18:55:32 CEST] <alqemyst> I'm using latest nvidia driver 384.69 and latest cuda toolkit with Debian Jessie stock kernel [18:55:34 CEST] <kepstin> next: the easiest way to do that with ffmpeg is to make a transparent png the same size as your video frame with black to mask out the corners, then use the overlay filter to draw it over the frame. [18:57:04 CEST] <next> <kepstin> All right. Is this the simplest solution? [18:58:11 CEST] <next> Thenks kepstin. [18:58:12 CEST] <alqemyst> this is what I mean by "breaking" [18:58:24 CEST] <kepstin> using ffmpeg, i think so. If you're using a pro video editing suite they might just have a vignette effect you can apply [18:58:28 CEST] <alqemyst> Sep 3 13:32:06 test-pc kernel: [2241066.865607] general protection fault: 0000 [#1] SMP [18:58:40 CEST] <alqemyst> Sep 3 13:32:06 test-pc kernel: [2241066.866195] CPU: 4 PID: 5939 Comm: ffmpeg Tainted: P O 3.16.0-4-amd64 #1 Debian 3.16.43-2+deb8u2 [18:58:58 CEST] <alqemyst> Sep 3 13:32:06 test-pc kernel: [2241067.031444] Fixing recursive fault but reboot is needed! [18:59:01 CEST] <next> kepstin ffmpeg [18:59:19 CEST] <alqemyst> after that system is unusable without hard reset [19:02:33 CEST] <BtbN> The CUDA toolkit does not matter. It's not used. [19:02:58 CEST] <BtbN> Looks like a driver bug to me [19:03:07 CEST] <BtbN> Or a system instability. [19:03:54 CEST] <alqemyst> it is latest ffmpeg cloned [19:04:06 CEST] <BtbN> ffmpeg has no influence at that low level. [19:04:18 CEST] <BtbN> If it hangs/crashes your Kernel, that's on the driver. [19:04:37 CEST] <alqemyst> what I noticed is when I'm using cuvid decoder it happends [19:04:44 CEST] <alqemyst> also libnpp [19:04:56 CEST] <alqemyst> nvenc works perfectly all the way [19:06:01 CEST] <alqemyst> when this message occurs in syslog, ffmpeg process goes into zombie state, it can't be killed [19:06:23 CEST] <alqemyst> only hard reset will help [19:06:44 CEST] <alqemyst> maybe I could try newer kernel? [19:07:39 CEST] <BtbN> An older one would probably be more likely to help. [19:11:13 CEST] <alqemyst> do you know which kernel version works best with nvidia, if this matters at all [19:15:05 CEST] <BtbN> Whatever doesn't crash I guess [19:15:38 CEST] <alqemyst> thanks [19:40:50 CEST] <ChocolateArmpits> next you should look into avisynth or maybe vapoursynth, generally any programmatic video processing happens easier there [19:43:18 CEST] <durandal_1707> vs and avs is crap [20:02:14 CEST] <ChocolateArmpits> what a brave statement [20:04:16 CEST] <durandal_1707> it even overlay cant do properly [20:11:17 CEST] <ChocolateArmpits> Is there something hard about extracting alpha? [20:19:29 CEST] <durandal_1707> ChocolateArmpits: no, its very slow [20:20:22 CEST] <ChocolateArmpits> unthreaded avisynth is, multithreaded totally not [20:22:51 CEST] <durandal_1707> mt have nothing to do with overlay [20:23:20 CEST] <durandal_1707> it builds mask for whole frame [20:38:44 CEST] <apus> hi, i'm trying to understand how ffmpeg with nvidia hardware acceleration is supposed to work. i found this https://developer.nvidia.com/ffmpeg there is the following command: ffmpeg -hwaccel cuvid -c:v h264_cuvid -i <input.mp4> -vf scale_npp=1280:720 -c:v h264_nvenc <output.mp4> -c:v is present twice, does the first with -hwaccel mean, that both decoding and encoding is hardware accelerated and otherwise only encoding would be hardware [20:38:46 CEST] <apus> accelerated? [21:02:17 CEST] <kepstin> apus: yes, many ffmpeg options have meaning based on their position. options before the input file apply to the input/decoder and options before the output file apply to the output/encoder [21:03:37 CEST] <apus> kepstin: thank you! [21:19:06 CEST] <apus> if transcoding a h264 encoded video to hevc using hevc_nvenc i can't use crf afaik. online i found the following suggestion: -c:v hevc_nvenc -preset llhq -rc:v vbr_minqp -qmin:v 19 -qmax:v 21 -b:v 2500k -maxrate:v 5000k -profile:v main the original bitrate was 5500kb/s. this produced 5400kb/s and the video file was not really smaller in the end. are there suggestions how i should set the bitrate/options relative to the input file in x264 to get [21:19:07 CEST] <apus> the "best" quality/size result? [21:20:05 CEST] <BtbN> crf is a libx264 specific thing. [21:20:34 CEST] <BtbN> also, transcoding h264 to hevc with hevc_nvenc is a highly questionable effort [21:20:53 CEST] <BtbN> the input h264 is most likely going to look better at the same bitrate [21:21:10 CEST] <kepstin> yeah, if the source h264 was done with good software encoder like x264. [21:22:23 CEST] <apus> is hevc_nvenc not as good as the non-hardware accelerated version? [21:24:05 CEST] <furq> if by that you mean x265 then no, it isn't [21:24:13 CEST] <furq> it's not even as good as x264 really [21:28:01 CEST] <BtbN> nvenc is not only hardware accelerated. It's a pure hardware encoder. [21:28:05 CEST] <BtbN> They are bad, but fast. [21:28:15 CEST] <apus> i have mts files from a video camera that i need to heavily compress. therefore i thought of hevc. as it takes quite a while to transcode i thought of using hardware acceleration. any suggestions? [21:28:42 CEST] <apus> is there a hardware accelerated version, that is "good" and a bit faster than the pure software version? [21:28:46 CEST] <BtbN> no [21:29:08 CEST] <BtbN> If you want quality, x264 or x265 it is. [21:30:17 CEST] <apus> ok, thank you all for your help! [21:38:44 CEST] <PornBlog> can ffmpeg output a delta-sigma modulated signal? [21:39:58 CEST] <durandal_1707> PornBlog: what signal? [21:40:12 CEST] <PornBlog> audio [21:41:04 CEST] <PornBlog> delta-sigma modulated NTSC would be quite impressive, tho [21:41:32 CEST] <PornBlog> (but I don't think I have the storage for that) [21:44:15 CEST] <durandal_1707> PornBlog: i still have no slightest idea is what you want [21:44:30 CEST] <PornBlog> https://en.wikipedia.org/wiki/Delta-sigma_modulation [21:45:15 CEST] <PornBlog> I wanna take 44.1kHz unsigned 8-bit PCM audio and output 441kHz 1-bit delta-sigma audio [21:46:35 CEST] <durandal_1707> it would still be digital? [21:46:47 CEST] <PornBlog> yes, delta-sigma is digital [21:47:12 CEST] <PornBlog> but that lets me shove it straight into my arduino, and then straight into an H-bridge, and then straight into a speaker [21:47:51 CEST] <PornBlog> ... with some low-pass filtering [21:48:12 CEST] <PornBlog> in other words I get to make my own hi-fi speaker [22:35:20 CEST] <kepstin> ffmpeg has some "decoders" for DSD, a delta-sigma modulation format, but I don't think it has any encoders. [23:01:40 CEST] <grublet> isn't DSD typically like, 2.6MHz sampling? [23:01:43 CEST] <grublet> something like that [23:24:21 CEST] <truexfan81> does ffmpeg master not have the dering filter listed here https://ffmpeg.org/ffmpeg-filters.html ? "[ffmpeg] No such filter: 'dering'" [23:25:50 CEST] <BtbN> I don't see a dering filter listed on that page either. [23:26:33 CEST] <truexfan81> i went to that page, hit ctrl+f typed in dering, its the 8th result [23:26:47 CEST] <BtbN> That's a parameter to another filter, not a filter. [23:27:28 CEST] <BtbN> Bit of a special case though, as it's for the libpostproc filter. [23:30:30 CEST] <truexfan81> works, thanks [23:39:52 CEST] <Soni> grublet: remember to compare bitrate not samplerate [23:44:53 CEST] <markmedes2> Friends subtitle burning is not working. ffmpeg version 3.3.3. command ffmpeg -i guay.jpg -i audio.mp3 -r 1 -c:a copy -vf subtitles=zurda.srt output5.avi [23:45:07 CEST] <markmedes2> any ideas? [23:50:23 CEST] <markmedes2> it burns the very first subtitle but stays stuck with it, won't move to the next [23:56:27 CEST] <klaxa> markmedes2: does it encode more than one frame? [23:56:35 CEST] <markmedes2> yes [23:57:30 CEST] <markmedes2> it encodes the whole video, but the subtitle is stuck at the first entry [23:57:42 CEST] <klaxa> can you try adding -loop 1 before -i guay.jpg and use -shortest ? [23:58:03 CEST] <markmedes2> yep, I tried that, but it will loop forever [23:58:09 CEST] <markmedes2> ah [23:58:10 CEST] <markmedes2> ok [23:58:14 CEST] <markmedes2> shortest, didn't see that [00:00:00 CEST] --- Tue Sep 5 2017

1 0

ffmpeg-devel.log.20170903
by burek 04 Sep '17

04 Sep '17

[00:04:47 CEST] <BtbN> hm, yeah. This timestamp interpolation is going to barf on itself when the timebase has the dts/pts increment by one per frame. [00:26:43 CEST] <BtbN> Yeah, that's exactly what's happening. I guess I can't modify the timebase from within an encoder? [00:27:18 CEST] <nevcairiel> technically you might get away with that, but its probably not quite nice [00:27:47 CEST] <BtbN> Not sure what else to do. The alternative is to just disable support for interlaced encoding. [00:28:33 CEST] <BtbN> "Most notably, H.264 and MPEG-2 specify time_base as half of frame duration" from avcodec.h [00:28:43 CEST] <BtbN> Why is my timebase 100/2997 then? [00:28:59 CEST] <BtbN> should be 100/5994 [00:30:44 CEST] <jkqxz> What is the timebase if you encode libx264? [00:30:59 CEST] <BtbN> That the timebase the encoder init function gets passed [00:31:03 CEST] <BtbN> So I suppose the same? [00:31:05 CEST] <jkqxz> (Where would 100/2997 even come from anyway? Is that 1001/30000 with some weird rounding applied?) [00:31:14 CEST] <BtbN> From the input file [00:31:19 CEST] <iive> yes [00:31:53 CEST] <BtbN> I like how nvenc sees that, and goes "nope" on it, and writes 1001/60000 into the SPS [00:32:09 CEST] <jkqxz> Shouldn't libx264 going to have exactly the same problem, then? Since it presumably works, maybe look at that. [00:32:23 CEST] <nevcairiel> x264 encodes mbaff, which doesnt have that particular issue [00:32:25 CEST] <BtbN> libx264 does not use field mode interlacing [00:33:17 CEST] <jkqxz> Huh, oh. MPEG-2 then? [00:33:34 CEST] <BtbN> no? [00:33:48 CEST] <BtbN> It just encodes the two fields as seperate pictures [00:34:27 CEST] <BtbN> NV_ENC_CAPS_SUPPORT_FIELD_ENCODING can also output: 2 : Interlaced frame encoding and field mode encoding are both supported. [00:34:31 CEST] <BtbN> Which would be MBAFF [00:34:49 CEST] <BtbN> So far I have yet to see a card/driver where mode 2 is supported [00:35:01 CEST] <BtbN> But I could just bump it to 2, set interlace mode to MBAFF, and be done with it... [00:35:41 CEST] <jkqxz> Wouldn't the two separate pictures in MPEG-2 need the 60000/1001fps timestamps, though? [00:36:05 CEST] <BtbN> No idea where you are getting mpeg-2 from [00:36:26 CEST] <nevcairiel> "another codec that has interlaced fields" [00:36:38 CEST] <jkqxz> And which doesn't have frame coding of interlaced fields. [00:37:51 CEST] <BtbN> They would, probably [00:38:06 CEST] <BtbN> But I'm not sure if the mpeg-2 encoder even supports interlaced encoding to begin with [00:38:13 CEST] <nevcairiel> it does [00:38:32 CEST] <iive> software mpeg2 encoder does support interlace [00:38:50 CEST] <BtbN> I really wonder why ticks_per_frame is 1 for this. The input and output is h264. It really should be 2. [00:40:42 CEST] <nevcairiel> probably because noone sets it? :p [00:40:42 CEST] <BtbN> h264_decode_init hard-sets it to 2. [00:43:06 CEST] <BtbN> This almose needs a new encoder capability [00:43:20 CEST] <BtbN> that signals that ticks_per_frame has to be >1 [00:51:02 CEST] <kierank> eh? [00:51:09 CEST] <kierank> ffmpeg doesn't support field encoding [00:51:12 CEST] <kierank> it's irrelevant [00:51:19 CEST] <kierank> just normalise [00:51:27 CEST] <BtbN> hm? [00:51:38 CEST] <BtbN> How would it not support it? [00:51:48 CEST] <kierank> ffmpeg doesn't have a concept of a field picture alone [00:51:58 CEST] <kierank> it has two fields and you encode each separately [00:52:11 CEST] <BtbN> nvenc handles that internally [00:52:20 CEST] <BtbN> you give it a normal interleaved frame. And two pictures come out [00:52:26 CEST] <kierank> so timebase is in frames per second [00:52:30 CEST] <kierank> so it should double internally [00:52:36 CEST] <kierank> like x264 [00:52:46 CEST] <BtbN> it does. The timebase it writes into the sps is doubled [00:52:58 CEST] <kierank> so this is not a bug [00:53:11 CEST] <BtbN> It is, because the container timestamps are not doubled [00:53:16 CEST] <BtbN> And I don't see a way to achive that [00:53:32 CEST] <kierank> yadif and similar do the same [00:53:41 CEST] <kierank> so the encoder needs to double the timebase [00:53:42 CEST] <BtbN> filters can modify the time_base though [00:53:48 CEST] <BtbN> encoders can't [00:54:06 CEST] <kierank> then the encoder can just output both fields as NALs concatenated or something [00:54:13 CEST] <kierank> would break vfr but who cares about interlaced vfr [00:54:19 CEST] <BtbN> That results in broken files that skip every second field in playback [00:54:29 CEST] <BtbN> that's how it works right now [00:54:44 CEST] <kierank> probably violates some container specs, true [00:54:50 CEST] <kierank> about one AU per packet [00:55:35 CEST] <BtbN> wonder what happens if I just set every other pts/dts to NOPTS [00:59:37 CEST] <BtbN> at least no errors anymore [00:59:45 CEST] <BBB> jya: yes, vp8 can have alpha channel [00:59:51 CEST] <BBB> jya: it works same as vp9 with alpha [01:00:09 CEST] <BtbN> I can't decipher the mpeg* encoder though. It does support interlaced encoding for mpeg2. No idea how it solves that particular problem though. [01:02:03 CEST] <BtbN> "Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" [01:02:16 CEST] <BtbN> it works, but it's unhappy about it [01:02:50 CEST] <JEEB> yea, I kind of wonder if both AVFrames and AVPackets should have the time base on them as well [01:03:32 CEST] <JEEB> that way you could just use the frame/packet and rescale the timestamps according to your following component and off you go [01:03:57 CEST] <BtbN> time_base + ticks_per_frame [01:04:06 CEST] <BtbN> or just the timebase I suppose is enough [01:04:22 CEST] <JEEB> having a duration is of course also nice [01:04:42 CEST] <BtbN> They do have a duration [01:04:44 CEST] <JEEB> but having the time_base would help tremendously [01:04:49 CEST] <JEEB> yea, packets do [01:05:09 CEST] <BtbN> If the packets had their own time_base, that would eliminate that problem. [01:05:19 CEST] <JEEB> yup [01:05:22 CEST] <BtbN> The encoder could just multiply the output timebase [01:05:48 CEST] <JEEB> yup [01:06:47 CEST] <BtbN> That would be quite an API break though, hm [01:06:52 CEST] <JEEB> yup [01:07:12 CEST] <JEEB> but personally it does make sense to have AVFrames and AVPackets contain their own time_base [01:07:21 CEST] <JEEB> so you don't have to remember where you just got that thing from [01:07:32 CEST] <JEEB> was it your demuxer, decoder, filter chain or encoder [01:08:00 CEST] <BtbN> what confuses me right now is, that if I just halve the time_base in the encoder init [01:08:09 CEST] <BtbN> the encoder suddenly gets double the amount of frames as input?! [01:08:15 CEST] <BtbN> From the same input file [01:08:26 CEST] <BtbN> So they are still incremented by 1 [01:09:02 CEST] <BtbN> something must decide that it has to duplicate frames [01:13:39 CEST] <BtbN> For now, the best bet is to just NOPTS if interlaced [01:14:01 CEST] <JEEB> not nice, but if the rest of the framework handles that... [01:22:58 CEST] <BtbN> The muxer uses a way larger timebase [01:23:07 CEST] <BtbN> so it can easily make up intermediate timestamps [01:23:11 CEST] <atomnuker> jkqxz: awesome patchset, this will be useful [01:23:48 CEST] <atomnuker> right now you can't capture stuff on wayland well [01:24:08 CEST] <jkqxz> Does it work on Wayland? I didn't try there at all. [01:24:47 CEST] <atomnuker> it probably does if it can capture VTs [01:27:33 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/1b24471c0c5b59dd0529a586b1b957d4e3ec2… that's what I came up with. [01:27:46 CEST] <BtbN> Everything looks reasonably to me. Except for the time_base things [09:56:58 CEST] <cone-859> ffmpeg 03Clément BSsch 07master:b4b1285fa1b6: lavd: drop disabled v4l code [11:31:14 CEST] <LongChair> could anyone help me to gigure out something. I am working on an hwdec that uses a Lib being Apache 2. hence if --enable-gpl is used it should also fail if --enable-version3 is not specified. [11:33:15 CEST] <LongChair> if i add the hwdec to EXTERNAL_LIBRARY_VERSION3_LIST it will work properly with --enable-gpl & --enable-version3 [11:33:30 CEST] <LongChair> but it won't allow to build it without --enable-gpl [11:33:30 CEST] <BtbN> I don't think that constraint is neccesary [11:34:13 CEST] <LongChair> i'm not familiar with licensing stuff, that but i got that comment in the ML on my patch [11:34:42 CEST] <BtbN> LGPL is rather relaxed in terms of linking against external stuff. [11:35:28 CEST] <LongChair> possibly, i really don't have a clue :) [11:35:30 CEST] <BtbN> And I think the GPL2 incompatiblity with Apache2.0 is only for including code? [11:35:42 CEST] <BtbN> Linking should still be fine. But not a licensing expert either [11:36:16 CEST] <nevcairiel> linking and including are the same to gpl, afaik [11:37:07 CEST] <LongChair> Anyways, i'd like it to be working both with --enable-gpl and --enable-version3, but adding it to EXTERNAL_LIBRARY_VERSION3_LIST will not allow to build it even without -enable-gpl [11:37:33 CEST] <LongChair> anyone would have a clue on what's required to get both cases work properly ? [11:38:08 CEST] <BtbN> I don't think that case exists yet [11:39:20 CEST] <LongChair> i tried to add it to both EXTERNAL_LIBRARY_VERSION3_LIST and HWACCEL_LIBRARY_LIST, but that still fails with "rkmpp is version3 and --enable-version3 is not specified." [11:40:44 CEST] <BtbN> well, it's not wrong? [11:41:21 CEST] <BtbN> you need either an lgpl build, a nonfree build, or a build with gpl3 [11:41:31 CEST] <BtbN> the only case that fails is a gpl2 build [11:46:05 CEST] <kurosu> jkqxz, btw, tested your h264_metadata cbs for editing wonky streams (ts->mkv + cutting and weird encoding): obviously worked [11:46:05 CEST] <LongChair> our build doesn't have any specific flags aside --disable-version3 [11:46:17 CEST] <LongChair> so that would be a gpl2 build ? [11:47:03 CEST] <kurosu> jkqxz, I had 1 or 2 streams with multiple sps (afaik, or stream so damaged that wrong detection), some of them damaged apparently [11:47:30 CEST] <kurosu> consequently, some errors printed, but before the editing, and after, the files were still playing correctly [11:51:20 CEST] <BtbN> the default is lgpl2 I think. [11:53:16 CEST] <LongChair> and that is not compatible with Apache 2 ? [12:00:42 CEST] <BtbN> Pretty sure LGPL is fine with linking to whatever [13:04:58 CEST] <cone-859> ffmpeg 03Leo Izen 07master:dda1c23c20d7: doc/filters.texi: Add default values to vf_vaguedenoiser options [13:20:24 CEST] <cone-859> ffmpeg 03Paul B Mahol 07master:f19e4118e9ca: avfilter/vf_subtitles: enable processing of alpha channel [13:39:41 CEST] <cone-859> ffmpeg 03Paul B Mahol 07master:06ed3768c88c: avfilter/vf_displace: remove useless requirement that SAR matches between input streams [13:51:08 CEST] <BBB> ubitux: any ideas on how to debug the avfoundation_indev -> avfoundation entry? Do I need to debug enabled and figure out why it returns true? Or is this a known/expected thing? [13:51:43 CEST] <BBB> ubitux: the issue I have is that with avfoundation_indev_deps=avfoundation; enabled avfoundation is false, but enabled avfoundation_indev is true (which to me seems wrong and unexpected, but maybe Im stupid) [13:54:13 CEST] <BBB> ubitux: where / how are dependencies like that resolved? I see functions like check_deps but Im deep in stuff I dont understand here [13:56:21 CEST] <ubitux> BBB: careful with the states, it's not only enabled vs disabled [13:56:25 CEST] <ubitux> you also have "unset" [13:56:37 CEST] <ubitux> so ! enabled doesn't mean disabled [13:56:43 CEST] <BBB> is it possible check_deps isnt called on avfoundation because its not in any list? [13:56:53 CEST] <BBB> like the lists on top, hw_list, ext_lib_list, etc. [13:56:56 CEST] <ubitux> for debug, you can check a the config.log, or maybe sh -x ./configure [13:57:24 CEST] <ubitux> check_deps is indeed what's call to solve the tree [13:57:32 CEST] <ubitux> it happens around the end of the script [13:57:58 CEST] <ubitux> BBB: yeah, might be [13:59:09 CEST] <BBB> thats easy to test [13:59:12 CEST] <BBB> hackyhack [13:59:22 CEST] <BBB> I dont know which list to add avfoundation_indev to or where it should be [13:59:32 CEST] <BBB> I thought all components were automatically added by parsing the relevant lists? [14:01:18 CEST] <BBB> is the issue check_deps is run after the check for coregraphics? [14:02:59 CEST] <BBB> or is the issue that checklib <component> bla bla should add LIBS to <component>_extralibs instead of the global EXTRALIBS? depending on whether the component is finally enabled? [14:06:44 CEST] <BBB> check_deps already includes the check but is evaluated too late [14:06:53 CEST] <BBB> the coregraphics check is done before check_deps [14:06:54 CEST] <BBB> so... [14:07:05 CEST] <BBB> we need to make sure the etxralibs isnt updated until the component is strictly enabled, or so [14:07:12 CEST] <ubitux> avfoundation_indev is not supposed to be in a list [14:07:13 CEST] <BBB> and I would expect check_lib <comp> to do that already [14:07:14 CEST] <BBB> but thats failing [14:07:18 CEST] <ubitux> avfoundation should be though [14:07:33 CEST] <BBB> avfoundation is in the list of autodetect disable thingies [14:10:01 CEST] <ubitux> speaking of extralibs, i'm confused at why they are set like this [14:10:13 CEST] <ubitux> typically, when a check_lib succeed, the extralibs are added [14:10:17 CEST] <ubitux> otherwise they aren't [14:10:25 CEST] <ubitux> maybe i'm missing something though [14:10:29 CEST] <ubitux> i have to go [14:10:31 CEST] <ubitux> bbl [14:10:46 CEST] <ubitux> ah! [14:10:48 CEST] <ubitux> i know [14:10:56 CEST] <ubitux> BBB: check the "requested" list [14:11:10 CEST] <ubitux> requesting a lib removes its enable/disable state [14:11:30 CEST] <ubitux> though, i think i'm doing an enable weak after that [14:11:38 CEST] <ubitux> make sure it's in those list. [14:11:49 CEST] <ubitux> anyway, bbl [14:19:44 CEST] <cone-859> ffmpeg 03Paul B Mahol 07master:e6e58de03d60: avfilter/vf_displace: add mirror edge mode [14:21:29 CEST] <BBB> requested [14:21:29 CEST] <BBB> aha [14:21:35 CEST] <BBB> is that for avfoundation or avfoundation_indev? [14:21:51 CEST] <ubitux> avfoundation [14:22:09 CEST] <ubitux> every enabled thing by the user becomes "requested" [14:22:22 CEST] <ubitux> so that if it's not found, it errors out [14:22:38 CEST] <ubitux> it's what i called "the damned fourth state" [14:47:22 CEST] <BBB> ubitux: I dont think I understand, sorry [14:47:31 CEST] <BBB> I dont know what the requested list is [14:47:50 CEST] <BBB> if its EXTERNAL_AUTODETECT_LIBRARY_LIST, then yes, avfoundation is in there [14:52:27 CEST] <BBB> ubitux: going from what other extlibs are doing, I think Ill just change enabled avfoundation_indev to enabled avfoundation, that should fix it [14:52:34 CEST] <BBB> its just something thats not possible yet [14:53:53 CEST] <BBB> https://pastebin.com/5GS1YJ5H [15:09:49 CEST] <ubitux> "enabled videotoolbox && check_lib coreservices" mmh [16:02:02 CEST] <BBB> ubitux: otherwise coreservices is enabled by default, which we obviously dont want [16:02:09 CEST] <BBB> ubitux: and the only user is ffmpeg_videotoolbox.c [16:02:13 CEST] <BBB> ubitux: so it seemed appropriate [16:05:29 CEST] <BBB> and otool -L shows no dependencies other than basic system stuff now, so it seems to work [20:08:07 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:05b1c606870c: doc/filters: add one more blend example [20:08:07 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:8b193e553055: doc/filters: add missing '' for blend example [20:43:50 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:f3c0f34f53c2: avfilter/vf_datascope: add timeline support to pixscope and oscilloscope [20:52:49 CEST] <durandal_1707> just merge all the libs once for all [23:39:17 CEST] <guest> Hello all. I'd like to suggest that the default flac compression level be set to its maximum possible value, 12. This has always been the right trade-off of space and time for me. [23:40:04 CEST] <atomnuker> send a patch [23:42:15 CEST] <guest> I'll do that if I must, but I'd prefer to avoid it because it would be a lot of hassle for me to get set-up in order to make this small change. [00:00:00 CEST] --- Mon Sep 4 2017

1 0

ffmpeg.log.20170903
by burek 04 Sep '17

04 Sep '17

[01:30:16 CEST] <BtbN> alexpigment, https://github.com/BtbN/FFmpeg this should "work". But it's a hack, and not a proper fix. With the current state of the ffmpeg APIs, I don't see an apropiate fix. [01:38:23 CEST] <commanderkeen`> with filtergraphs should i create one for video and a separate one for audio? [01:38:36 CEST] <c_14> you can only have one filtergraph [01:39:29 CEST] <commanderkeen`> so have a single filtergraph that takes in the decoded audio and video [01:39:54 CEST] <JEEB> if you are using the APIs you can have as many as you want [01:39:55 CEST] <commanderkeen`> so that would mean to have a video sink and audio sink on the filter graph? [01:40:14 CEST] <JEEB> you have the buffersrc and the sink [01:40:26 CEST] <JEEB> as the start/end points [01:40:33 CEST] <JEEB> for each of the filtering chains you're handling [01:41:15 CEST] <commanderkeen`> i think i understand [01:41:56 CEST] <commanderkeen`> i think i will try to have separate filtergraphs and encode then mux the streams togethe [03:11:21 CEST] <alexpigment> BtbN: I keep thinking you're "done" with looking into this, and you keep surprising me :) [03:11:51 CEST] <alexpigment> I'll be hanging out with the wife for the rest of the night, but I'll make a note to check this out tomorrow [03:12:11 CEST] <alexpigment> Your work is greatly appreciated - "hack" or not [10:36:38 CEST] <thebombzen> I'm looking for somewhat sane settings for vaguedenoiser at denoising anime [10:36:43 CEST] <thebombzen> the default does not look good [10:37:03 CEST] <thebombzen> also, the manpage does not list the default settings, which is frustrating [10:56:49 CEST] <durandal_1707> thebombzen: ffmpeg -h filter=vaguedenoiser [10:57:02 CEST] <thebombzen> I just poked around vaguedenoiser.c to find them [10:57:12 CEST] <thebombzen> I'm about to send a patch that adds them to doc/filters.texi [11:02:39 CEST] <thebombzen> durandal_1707: alright, send the patch. But that being said, do you have suggestions for good values? the default ones do not work well [11:03:34 CEST] <durandal_1707> depends on noise type [11:15:52 CEST] <thebombzen> hm, this is hard, I'll stick with hqdn3d [11:17:27 CEST] <durandal_1707> thebombzen: hqdn3d is for poor people [11:23:52 CEST] <thebombzen> durandal_1707: well it works and it's fast and it doesn't require me to configure it /shrug [11:24:34 CEST] <durandal_1707> thebombzen: it blurs and learn to ask google [11:29:01 CEST] <ozgurk> hi, how can i encode lpcm for digital preservation in matroska? i use -c:v ffv1 -level 3 -g 1 -slicecrc 1 -slices 16 for video, but what should i use for lpcm for digital preservation? thanks [11:37:39 CEST] <ritsuka> you can leave it as pcm, or use flac or another lossless codec [11:53:27 CEST] <ozgurk> thanks ritsuka, but if i want to use lpcm, which pcm format should i use? also which endianness? does it make sense for pcm? [11:54:48 CEST] <ozgurk> i want it to pass the conformance checking of mediaconch - http://www.preforma-project.eu/mediaconch.html [11:58:05 CEST] <ritsuka> whatever you prefer, mkv supports both endianess and signed/float pcm [12:00:02 CEST] <AliD> Hello again. [12:00:42 CEST] <AliD> I created standalone ndk toolchain for compiling. [12:01:41 CEST] <AliD> Now I want to compile mp3lame sources to libraries and use them to compile ffmpeg as executable binary for Android. [12:02:39 CEST] <AliD> I tested ways on the network but all fails for me. [12:02:46 CEST] <AliD> No idea? [12:15:59 CEST] <AliD1> No Idea? [13:59:16 CEST] <blap> "my car broke! why?" [15:10:03 CEST] <doslas> Nacht [15:10:11 CEST] <doslas> Hi [15:10:44 CEST] <doslas> every thing is work by your script [15:11:44 CEST] <doslas> Thank you for help me [15:32:48 CEST] <BullHorn> hello, i need help. i used to have .bat files the included all the commands needed to take an .mkv source in d:\video, convert it to .mp4 and place it in f:\video, all by typing 'covert 1 2' (1 being the source in d:\video and 2 being the output for f:\video) [15:33:06 CEST] <BullHorn> but somehow they disappared (maybe antivirus or malwarebytes deleted it i dont even) [15:35:30 CEST] <durandal_1707> backup backup backup [15:36:17 CEST] <BullHorn> yeah i do backup most things [15:36:48 CEST] <BullHorn> this is the one thing i didnt - and i only had it like in the root of cmd where i didnt have to cd.. anywhere or without adding it to the PATH ;x [15:47:50 CEST] <realies> any ideas what could http://www.videosmaller.com/ be using to squash videos without visual degradation? [15:49:43 CEST] <realies> getting some -70 to -80% filesize on certain files [15:51:01 CEST] <BtbN> any transcoder with non-shit settings [15:51:41 CEST] <BtbN> "Reduce size of MP4 videos captured with your Android or iPhone." It's not hard to reduce the high bitrate of phones hardware encoders. [15:51:47 CEST] <ritsuka> it uses ffmpeg with quite standard settings [15:52:09 CEST] <BtbN> it seems highly dubious though [15:52:21 CEST] <BtbN> Why would they offer a service that is highly CPU intensive and thus expensive for free? [15:52:45 CEST] <realies> BtbN, it works fine though, no idea at all [15:52:53 CEST] <realies> maybe they need some huge amounts of video for something? [15:52:57 CEST] <BtbN> But they now have your video. [15:53:29 CEST] <realies> ritsuka, how did you know? [15:53:45 CEST] <ritsuka> I used it to convert a small video [15:53:52 CEST] <realies> oh, metadata? [15:53:53 CEST] <ritsuka> and inspected the result [15:54:22 CEST] <realies> can read or guess the parameters from the inspection? [15:54:29 CEST] <realies> (trying to reproduce) [15:54:42 CEST] <BullHorn> i kinda remember it [15:54:43 CEST] <BullHorn> it was like [15:54:54 CEST] <ritsuka> it's just x264 with a super high rf [15:55:04 CEST] <BullHorn> ffmpeg -i D:\%1.mkv -c copy -copyts F:\%2.mp4 [15:55:05 CEST] <BullHorn> or something [15:55:09 CEST] <BullHorn> im not sure about hte syntax though [15:56:33 CEST] <BullHorn> yes thats it lol [15:56:35 CEST] <BullHorn> it works :D [15:56:46 CEST] <realies> ritsuka, crf? [15:57:13 CEST] <BullHorn> %1 and onwards allows you to input names, so i do 'convert myinputvideohere shortoutputnamelol' and it works [15:57:50 CEST] <BullHorn> ok but now its missing a thing - my video has 2 audio tracks, -c copy -copyts only copies the first track [15:57:56 CEST] <BullHorn> whats the thing to make it copy all audio tracks [16:01:09 CEST] <BullHorn> ty guys [16:02:34 CEST] <realies> ritsuka, this seems like a cool read about it http://williamyaps.blogspot.bg/2017/01/ffmpeg-encoding-h264-decrease-size.h… [16:03:06 CEST] <BtbN> it's 100% impossible to do it without quality loss though [16:03:14 CEST] <BtbN> even if you encode to a higher bitrate, it will degrade [16:04:17 CEST] <realies> BtbN, talking about the subjective perception [16:32:59 CEST] <graphitemaster> actually, you sure they're using their CPU for that [16:33:11 CEST] <graphitemaster> like, their hardware [16:33:27 CEST] <graphitemaster> maybe they just compiled ffmpeg with emscripten and it's doing all the encoding in your browser :P [16:33:52 CEST] <graphitemaster> ah no, you have to upload the video :( [16:37:44 CEST] <BtbN> you'll have a hard time running a h264 encoder via JavaScript [16:38:02 CEST] <bencoh> :] [16:38:32 CEST] <bencoh> I wonder how it'd perform though [16:39:02 CEST] <BtbN> poorly [16:39:09 CEST] <graphitemaster> with webassembly, and how they now have simd instructions and webworkers which are sort of like threads [16:39:10 CEST] <BtbN> It's mostly fast on PCs because of handwritten assembly [16:39:17 CEST] <graphitemaster> I imagine you can get pretty damn close [16:39:26 CEST] <BtbN> no, you wouldn't even get remotely close [16:39:44 CEST] <graphitemaster> well, close to native speed for the reference C code, not the handwritten assembly in ffmpeg [16:39:54 CEST] <bencoh> s/ffmpeg/x264/ in that case [16:40:00 CEST] <BtbN> Build ffmpeg and x264 without yasm, and then halve the speed you get from that, and you might have something to hope for [16:40:44 CEST] <graphitemaster> I iamgine it would be more like ffmpeg/x264 without yasm at two 3rd's the speed [16:42:01 CEST] <graphitemaster> what is more interesting is how they already have propsals for webapis for encoding video in the works anyways [16:42:22 CEST] <graphitemaster> so you can just ignore emscripten compiled ffmpeg/x264 and use the webapi which will prolly just be what ever the platform has [16:42:33 CEST] <graphitemaster> which will likely be optimized (and potentially hardware accelerated, e.g nvenc) [16:44:12 CEST] <klaxa> javascript was a mistake [18:05:39 CEST] <ZexaronS> hello [18:05:50 CEST] <ZexaronS> any benefit for ffmpeg to use C++ ? [18:06:07 CEST] <ZexaronS> perf [18:15:17 CEST] <JEEB> you don't magically get perf out of writing stuff in C++ instead of C [18:18:58 CEST] <ZexaronS> i'm looking at some of the nvenc vs x265 discussions, and the people that know around these sectors say that GPU encoders are proprietary ASICs, and that have much less options than x264, why don't they make an ASIC that runs x264/x265 on the GPU then ? [18:19:26 CEST] <ZexaronS> what's the point of making a totally different encoder, just make a x264/x265 version in HW , no ? [18:19:36 CEST] <furq> good luck with that [18:20:46 CEST] <ZexaronS> Once I found the details, the whole thing is a bit meh, features are low, and it's not even the same encoder so it's not GPU accelerated, it's not the same encoder it's something else [18:21:09 CEST] <JEEB> well, you'd have to design the hardware to do all those things. which is why hw encoders don't start off of some sw encoder [18:21:31 CEST] <JEEB> they generally start building their hw off of some FPGA design and then move it to an immutable ASIC in the end [18:21:36 CEST] <ZexaronS> It's not helping x265 by just having a GPU, and secondly, the VCE/NVENC is an engine on the GPU, does it even use the whole GPU or just the ASIC part ? [18:22:00 CEST] <JEEB> the ASIC in general handles all the actual video coding since the GPU is not good at what you really require for image compression [18:22:13 CEST] <JEEB> the GPU part can be used for stuff that happens with raw video like scaling or deinterlacing [18:22:22 CEST] <JEEB> as in, normal image processing [18:22:52 CEST] <JEEB> for a video format to be actually implementable on the GPU itself you'd have to build the video format from the ground up to be massively threadable [18:23:00 CEST] <JEEB> ATi did that once in around 2007-8 [18:23:13 CEST] <JEEB> let's just say that the format could not give comparable compression [18:23:49 CEST] <ZexaronS> Indeed the markeing monikers are a load of bunk, it's an ASIC inside the GPU, and the GPU only helps minor with some filters and basic stuff, hardly GPU driver, I guess the term "accelerated" is the lawyer-sneaky picked one to mean that it's only "helping a little bit" not actually running [18:24:00 CEST] <JEEB> because generally the more you thread something in a way that doesn't require too much synchronization (= having to stop the thing) [18:24:09 CEST] <ZexaronS> GPU driven* [18:24:15 CEST] <JEEB> you cannot utilize as much data that would help you compress the thing [18:24:21 CEST] <JEEB> thus the end result is that you get specialized ASICs [18:24:26 CEST] <JEEB> that are just doing the job at speed X [18:25:23 CEST] <furq> i don't think i've ever seen nvidia refer to nvenc as "gpu accelerated" [18:25:33 CEST] <JEEB> also with x265 it would help if people cared about that encoder more :P it just lacks a proper community around it like x264 had. [18:25:39 CEST] <JEEB> (or libvpx) [18:25:44 CEST] <furq> but then it's rare to see nvidia refer to nvenc at all [18:25:47 CEST] <ZexaronS> Then what we need is a separate ASIC card that is comparable to a GPU in horsepower, then that would be proper HW driven, this is more like a tack-on right now, like a supercharger on a car, it's not really a different engine, right ? [18:26:00 CEST] <furq> it is a completely different engine [18:26:06 CEST] <furq> it's just not a very good one compared to a cpu [18:26:38 CEST] <JEEB> well, ASIC is a system made for specific thing so it's not really a general purpose computational unit :P [18:26:56 CEST] <JEEB> you can think of it as a black box that you feed things and get things out of it [18:27:02 CEST] <ZexaronS> Well, I meant, we build an dedicated ASIC video encoder card that's as big as a GPU and built from the ground up to be better than anything on any CPU [18:27:10 CEST] <furq> who's "we" [18:27:41 CEST] <JEEB> I would still see actual effort put into SW encoders as much more bang for the buck thing [18:28:00 CEST] <furq> there are already cards/boxes that do that [18:28:07 CEST] <furq> but they're not really for consumer use [18:28:23 CEST] <JEEB> sure, but they're not really generally better except when the SW alternatives suck dong [18:28:24 CEST] <furq> and also i assume they're not better than x264 [18:28:29 CEST] <ZexaronS> Well make it for consumer use then, what's the problem [18:28:33 CEST] <furq> the price [18:28:54 CEST] <ZexaronS> Well if people want so much profit out of it then, there's your problem [18:29:00 CEST] <furq> nvenc is just a nice thing to tack onto a gpu so that people can stream themselves playing league of mobas [18:29:20 CEST] <JEEB> ZexaronS: hardware design and manufacture costs a lot. if you're a niche thing, even more [18:29:22 CEST] <furq> it's not really intended for anything more than that [18:29:37 CEST] <ZexaronS> If the chinese or the taiwanese want to be losers and can't do anything then if I get rich I'll do a better job :p [18:29:53 CEST] <JEEB> so in general we're not limited by the CPUs anyways at this point [18:29:59 CEST] <JEEB> the encoders could be massively optimized to be honest :P [18:30:00 CEST] <ZexaronS> I would do it with a "break even" policy, no profit needed [18:30:11 CEST] <ZexaronS> So the price wouldn't be that high [18:30:49 CEST] <ZexaronS> JEEB: I guess x265 people are spinning wheels, why the hell is the thing proprietary [18:30:58 CEST] <ZexaronS> afaik ... maybe it's not [18:31:03 CEST] <JEEB> it's not proprietary, fully open source [18:31:11 CEST] <JEEB> the problem is the lack of community around it [18:31:13 CEST] <JEEB> I tried in '13 [18:31:19 CEST] <JEEB> but in the end it's a one-company show [18:31:29 CEST] <JEEB> x264 was much more community driven [18:32:18 CEST] <JEEB> generally the more use cases you try to accomodate on some level, the better the result gets in the end as long as they're not destroying the capabilities in another use case for another [18:32:42 CEST] <JEEB> Google's libvpx (the VPx series reference software) encoder is another prime example of a single vendor thing [18:32:54 CEST] <JEEB> it doesn't help how great your video/audio format is if the implementations are wee-wee [18:33:09 CEST] <ZexaronS> The masses out there just glued to their web streaming screens, completely forgoteen about offline video, John Carmack complained how everyone just wants to watch streaming video and talked how crappy the video is, watching proper VR in 4K is simply not going to look good in web streaming because sites automatically recode and imagine HDR and WCG on top, we will be talking in gigabytes as per standard [18:33:34 CEST] <JEEB> (granted, x265 is still one of the best HEVC encoders - which of course just tells about the quality of the competition) [18:34:01 CEST] <redrabbit> x265 is available under the terms of the open source GNU GPL 2 license. Source code is available on https://bitbucket.org/multicoreware/x265. [18:34:04 CEST] <redrabbit> x265 is also available under a commercial license to companies who wish to distribute x265 without the copyleft restrictions that the GPL v2 license imposes. For commercial licensing questions, please contact our licensing team (license @ x265.com) [18:34:21 CEST] <furq> that's true of x264 as well [18:34:34 CEST] <atomnuker> but x264 only offered lgpl and not commerical [18:34:50 CEST] <ZexaronS> I maybe mistaken for H265 licensing thing [18:35:01 CEST] <atomnuker> so companies who wanted to modify it sill had no choice but to release the modifications [18:35:29 CEST] <JEEB> atomnuker: x264 LLC's secondary license as far as i know is commercial (But you still have to present changes to libx264 to x264 LLC) [18:35:38 CEST] <JEEB> so it's GPL and commercial [18:35:47 CEST] <JEEB> they don't have to give those changes out outside of x264 LLC [18:36:12 CEST] <JEEB> which basically means people on #x264dev , who then every now and then poke people if some of those changes look sane [18:36:21 CEST] <ZexaronS> I think I had a discussion on that also, these big international standards groups simply write some blueprint but don't build anything, so much money going to CERN but they can't make one video codec, sort of MEH [18:36:34 CEST] <furq> why would cern make a video codec [18:36:53 CEST] <JEEB> well the standard body's idea is to create the format and reference implementations that they can test things with :P [18:37:18 CEST] <JEEB> the HEVC reference is called "HM" [18:37:23 CEST] <JEEB> it has both decoder and encoder [18:37:28 CEST] <ZexaronS> There's thousands of scientists working on so many theories and making things that never really do much outside the labs, but can't make one video codec :( [18:38:06 CEST] <JEEB> redrabbit: MCW got the license to the x265 name by giving the library out as open source in addition to their corporate license. which is kind of nice. [18:38:12 CEST] <Mavrik> JEEB, what do pro shops use to encode HEVC? [18:38:17 CEST] <Mavrik> e.g. broadcasters and stuff? [18:38:28 CEST] <JEEB> broadcasters at least in 2014 had expensive hw stuff that was awful [18:38:42 CEST] <JEEB> I checked the .jp test broadcasts back in the day [18:38:46 CEST] <JEEB> 40 megabits and looked like ass [18:38:51 CEST] <redrabbit> good AVC > bad HEVC [18:39:01 CEST] <JEEB> that's the thing about implementations :P [18:39:10 CEST] <furq> b-but...but i read hevc is 50% more efficient! [18:39:34 CEST] <ZexaronS> the ISO/IEC standards thing makes up a standard that supposably governments will use in library/national archives and cable broadcast etc ... right, wrong lol, they make up a standard without the tool to make a video that's compatible with the standard [18:39:34 CEST] <furq> that's why i reencoded all my x264 rips with nvenc in 1-pass mode at half the bitrate [18:39:38 CEST] <JEEB> Mavrik: nowadays I've seen a lot of x265 for blu-ray related things although I bet sony etc have their own proprietary solutions around [18:39:51 CEST] <JEEB> ZexaronS: I've noted the HM reference software X times by now [18:39:52 CEST] <Mavrik> mhm, I always wondered what the content providers used [18:39:52 CEST] <redrabbit> furq: sounds neat. lol [18:40:14 CEST] <JEEB> Mavrik: amazon and netflix either use x265 or that crappily named SW thing [18:40:16 CEST] <furq> i have genuinely had to tell people not to do that [18:40:24 CEST] <Mavrik> For H.264 I've only mostly met x264 and the mainconcept encoder [18:40:24 CEST] <furq> so i can only imagine there are people out there who have done it without asking first [18:40:30 CEST] <Mavrik> For H.265 I had no idea [18:40:43 CEST] <ZexaronS> JEEB: Reference encoder is most probably not used in practise so much is it? [18:40:51 CEST] <JEEB> ZexaronS: it's often used as the base [18:41:00 CEST] <ZexaronS> They're not updating regularly imo [18:41:08 CEST] <Mavrik> How active is libx265 development anyway? [18:41:24 CEST] <ZexaronS> Not supporting new CPU instructions, etc, I'd assume [18:41:31 CEST] <furq> ZexaronS: how does that not constitute people using the standard [18:41:33 CEST] <JEEB> MCW is selling it so libx265 is relatively active [18:41:48 CEST] <JEEB> ZexaronS: the idea of the reference software is not to create a fully optimized solution [18:41:54 CEST] <furq> the standard is the bitstream [18:42:05 CEST] <JEEB> a lot of the optimizations aren't about just hitting it with more SIMD [18:42:09 CEST] <furq> quite a few people are using h264 bitstreams [18:42:16 CEST] <furq> as many as 100 people are using it these days [18:42:24 CEST] <ZexaronS> JEEB: Yes, I mean, I disagree with that idea, I'd skip the reference and focus on fully optimized solution [18:42:28 CEST] <JEEB> because encoder optimization is mostly about "where can we skip X,Y,Z to make this faster but not lose too much quality against the perfect way of doing it" [18:42:46 CEST] <ZexaronS> oh then that's another story [18:42:59 CEST] <ZexaronS> but hey I never meant that kind of optimizations, those are cheats [18:43:06 CEST] <JEEB> reference encoder generally needs to prove things [18:43:11 CEST] <Mavrik> Best optimizations are cheats :P [18:43:26 CEST] <furq> cheating kicks ass [18:43:29 CEST] <ZexaronS> optimizing without breaking off the accuracy/quality, not the fake optimization [18:43:30 CEST] <JEEB> so that a certain way of coding improves compression by X% etc with a speed loss of Y% without skipping [18:43:51 CEST] <furq> if you think that's "fake optimisation" then you're going to fucking hate x264 [18:43:55 CEST] <JEEB> yea :D [18:44:13 CEST] <JEEB> the whole point of non-reference encoders is getting as close as possible to the reference result without doing the full computations [18:44:26 CEST] <ZexaronS> well, facepalm [18:44:41 CEST] <JEEB> and there's a fuckload of research on these things [18:45:11 CEST] <JEEB> also the HEVC reference implementation is getting updated rather well :P [18:45:11 CEST] <JEEB> https://hevc.hhi.fraunhofer.de/trac/hevc/browser [18:45:16 CEST] <JEEB> last update was 6 days ago I see [18:45:29 CEST] <JEEB> and they have releases every couple of months [18:45:55 CEST] <ZexaronS> So pretty much every video out there is most probably not really up to par with standard 100%, it's some 95% ish ? [18:46:07 CEST] <JEEB> no, the standard doesn't define how you encode something [18:46:28 CEST] <JEEB> the standard defines the way of decoding something [18:46:49 CEST] <JEEB> as long as what you output fits that specification, it's valid HEVC or AVC or MPEG-4 Part 2 or MPEG-2 Video [18:47:30 CEST] <JEEB> which is why the hardware encoder manufacturers first of all just do the minimal amount of work to get their encoder thing to output valid <next format in line> with their previous gen encoder [18:47:34 CEST] <ZexaronS> Well then it's funny how the standard "H264" specifies the computations, but then nobody uses them, so it's like ... everything's off, in practise, so what's the point of a glossy standard sitting in ISO/IEC offices, "see boys and girls this is H265" ... that statement doesn't really hold true for most videos out there then [18:48:02 CEST] <JEEB> no, the specification is for the video format. you don't have to use all of the bells and whistles in it to create a valid file [18:48:11 CEST] <furq> the reference encoder isn't part of the standard [18:48:13 CEST] <JEEB> I'd recommend you actually go read the specification since that's freely available [18:48:17 CEST] <ZexaronS> Oh that yes I get the file metadata thing [18:48:25 CEST] <furq> the standard defines the bitstream format [18:48:35 CEST] <JEEB> and the features you use have to be decode'able as per the standard [18:48:36 CEST] <furq> the reference encoder is just some tool that creates a compliant bitstream [18:48:43 CEST] <Mavrik> Yeah, it's like standard defining the letters... but not how you put them together into poetry :P [18:48:57 CEST] <furq> it's as correct or otherwise as any other encoder [18:49:37 CEST] <JEEB> and having the specification *is* important because otherwise you end up with reference implementation bugs = standard behavior [18:49:44 CEST] <ZexaronS> furq, reference encoder isn't part of the standard ... I guess I need a second facepalm, but who invented this way of doing things, never realized [18:49:50 CEST] <JEEB> which is what both VP8,9 had [18:50:11 CEST] <Mavrik> Yuck. How does libvpx/VP9 compare to libx265 these days? [18:50:12 CEST] <furq> creating video encoders is quite difficult [18:50:22 CEST] <furq> i've heard it can take up to 8 hours of work [18:50:39 CEST] <JEEB> Mavrik: it's still not on par methinks. which is why a certain ex-googler is selling an encoder b2b [18:50:40 CEST] <ZexaronS> furq: It seems to me that the people who invented these weren't computer people nor were part of the 90ies and played any video games, these are some random mathematicians and physicists put together from various EU countries imo [18:50:49 CEST] <furq> if you insisted that no video standard be released without an encoder of comparable quality to x264 then we'd still be using h.262 [18:50:51 CEST] <ZexaronS> it's like they're on another planet [18:51:02 CEST] <Mavrik> JEEB, libvpx not on par with libx265 or the other way? [18:51:09 CEST] <JEEB> yea, that way [18:51:14 CEST] <JEEB> IIRC the psychovisuals are even worse [18:51:27 CEST] <furq> don't forget the rate control and the multithreading [18:51:34 CEST] <Mavrik> blah [18:51:34 CEST] <JEEB> yea, that's just icing on the cake [18:51:49 CEST] <Mavrik> Does HEVC demand player support for 4:4:4 yet? Or is 4:2:0 still the only one mandayory? [18:52:04 CEST] <JEEB> HEVC spec only specifies profiles [18:52:14 CEST] <JEEB> and most media formats then specify formats X,y [18:52:18 CEST] <JEEB> *profiles [18:52:33 CEST] <JEEB> so yes, effectively right now 4:2:0 is what you get :P [18:52:35 CEST] <Mavrik> Hmm, HEVC Main is 4:2:0 only it seems [18:52:36 CEST] <redrabbit> mpeg2 is still widely used to satellite tv [18:52:39 CEST] <redrabbit> to my horror [18:52:56 CEST] <ZexaronS> Well, when WCG and HDR hit, all this codecs/players need some big update anyway [18:52:57 CEST] <JEEB> Mavrik: at least main 10 is now a generally supported thing [18:52:59 CEST] <Mavrik> redrabbit, yeah, my clients encode boatload of MPEG2/MP2 from satellites to H.264 for broadcast [18:53:02 CEST] <redrabbit> i beleive AVC still have some lifespan ahead of it [18:53:14 CEST] <Mavrik> mhm, still 4:2:0 only though it seems [18:53:20 CEST] <JEEB> yes, 4:2:0 only [18:53:24 CEST] <JEEB> with main/main 10 [18:53:30 CEST] <Mavrik> With HEVC/VP9 mess, HDR standard mess... the new codec world looks kinda worse than just keeping to H.264 :P [18:53:44 CEST] <JEEB> it's not like you can ignore the HDR mess with H.264 [18:53:49 CEST] <JEEB> it's an additional metadata mess [18:53:55 CEST] <JEEB> (and colorspace conversion mess) [18:54:22 CEST] <redrabbit> too bad you cant use VP9 in a .TS [18:54:26 CEST] <JEEB> you can I think [18:54:32 CEST] <JEEB> not 100% sure, though [18:54:39 CEST] <JEEB> I remember opus went through standardization [18:54:41 CEST] <ZexaronS> Yeah this is the thing, none of these codecs are actually built for archival/enthusiast consumers like us, it's either for the corporate web streaming nobleman or the enointed broadcast royalty, but nothing for us pesants [18:54:42 CEST] <Mavrik> Hmm, is HDR H.264 a thing in the wild? [18:54:44 CEST] <furq> is any large broadcaster using h264 for sd yet [18:54:51 CEST] <furq> i know none of the ones here are [18:54:57 CEST] <Mavrik> ZexaronS, yeah, but it still hits consumers [18:54:57 CEST] <redrabbit> well with my software (dvbviewer) there is no way to use either VP9 or OPUS with a .TS [18:55:08 CEST] <Mavrik> ZexaronS, e.g. how do I know my TV will play HDR YouTube and Netflix and BBC? [18:55:14 CEST] <redrabbit> it does relies on ffmpeg but there must be internal limitations [18:55:23 CEST] <JEEB> redrabbit: at least opus got implemented some time ago [18:55:25 CEST] <Mavrik> (Getting a TV that can DISPLAY HDR is hard enough with widespread lying) [18:55:37 CEST] <JEEB> redrabbit: so you can both mux and demux opus from/to MPEG-TS [18:55:46 CEST] <redrabbit> yep opus should work with TS but it didnt, so i use AAC [18:55:56 CEST] <JEEB> that's not an FFmpeg problem then [18:55:59 CEST] <furq> vp9 works in ffmpeg if nothing else [18:56:05 CEST] <redrabbit> it probably dvbviewer [18:56:09 CEST] <redrabbit> yeah [18:56:15 CEST] <JEEB> most likely dvbviewer demuxes by itself [18:56:19 CEST] <JEEB> because lavf mpegts is awful [18:56:27 CEST] <JEEB> and that demuxing logic has no support for opus [18:57:10 CEST] <redrabbit> interesting, i had no idea why [18:57:13 CEST] <JEEB> Mavrik: even if it gave better results it's not being used because of lack of ASIC support [18:57:31 CEST] <redrabbit> how does AAC compares to OPUS [18:57:41 CEST] <Mavrik> mhm, can't seem to track down what Netflix / Amazon use [18:57:41 CEST] <redrabbit> around 128k / stereo [18:57:47 CEST] <Mavrik> I'm guessing HEVC / AAC ? [18:57:54 CEST] <Mavrik> HEVC / DD I mean [18:58:12 CEST] <furq> h264 and dd for 1080p, hevc and dd for 4k [18:58:13 CEST] <JEEB> amazon and netflix use HEVC for 10bit due to the ASIC thing, although 10bit VP9 is becoming a thing too [18:58:13 CEST] <furq> iirc [18:58:30 CEST] <JEEB> f.ex. my TV can play 10bit VP9 (profile 9.2 or whatever) [18:58:31 CEST] <redrabbit> i use AVC / AAC or HEVC / ACC but usually i just copy the audio instead of transcoding it if there is bw available [18:58:38 CEST] <Mavrik> Yeah, although Sony just said that my TV won't support HDR YouTube -_- [18:58:39 CEST] <furq> only itunes uses aac for their downloads afaik [18:58:40 CEST] <Mavrik> Thankyou mediatek [18:58:53 CEST] <JEEB> Mavrik: not like I'd trust the tone mapping in hardware anyways, lol [18:58:57 CEST] <Mavrik> :P [18:59:01 CEST] <Mavrik> It's pretty tho :P [18:59:01 CEST] <JEEB> that's probably the most FFFUUU thing in HDR playback [18:59:13 CEST] <Mavrik> I'll probably just buy shieldTV at some point [18:59:15 CEST] <JEEB> because there is no standardized way of tone mapping [18:59:23 CEST] <Mavrik> Although the AndroidTV on my Sony keeps up surprisingly wel [18:59:26 CEST] <JEEB> so everything can say they do it correctly [18:59:41 CEST] <JEEB> Mavrik: hmm, I wonder if it would be worth it to try out mpv-android on that thing :D [18:59:48 CEST] <Mavrik> Well, my TVs default settings are so color saturated that nothing looks real anyway :P [19:00:07 CEST] <JEEB> although the interface currently sucks for lean-back things [19:00:17 CEST] <JEEB> and the store won't likely let you install the app due to that [19:00:20 CEST] <Mavrik> I'm getting like 90% CPU usage just transcoding DTS to DD on-the-fly [19:00:23 CEST] <Mavrik> So I'd say no :P [19:00:35 CEST] <JEEB> mediacodec would get used for hw decoding [19:00:45 CEST] <JEEB> then you get the decoded YCbCr [19:00:53 CEST] <JEEB> and shove it into an opengl pipe line [19:00:53 CEST] <JEEB> :) [19:01:03 CEST] <ZexaronS> And youtube is just so funny with their 4K 3D videos, where 4K is for the whole 3D video, so it's still looks like crap ... these are the early years it's still pretty much useless [19:01:04 CEST] <JEEB> slower than dumb overlay of course [19:11:16 CEST] <ZexaronS> Some successor to MPEG2TS has to come, with HDR,WCG, archival features which will be good for various govts too so their interest makes it alive [19:11:42 CEST] <ZexaronS> and no interlaced/werid frame rates, and subsampling stuff, full blown quality [19:11:43 CEST] <atomnuker> ZexaronS: mpegts sucks and anyone using it sucks and everything that follows it would suck [19:11:59 CEST] <furq> check this out: mpeg4ts [19:13:36 CEST] <ZexaronS> actually I meant that the format is updated but it has capability to be used as transport or storage, without having to be tagged with "TS" on the outside [19:14:03 CEST] <BtbN> what? [19:14:06 CEST] <ZexaronS> and the codec used internally would be made for hiqh quality, not streaming [19:14:20 CEST] <BtbN> the container and the codec are entirely independend [19:14:31 CEST] <ZexaronS> the streaming moniker used by companies implies that the actual quality has been sacrificed [19:14:33 CEST] <BtbN> put something lossless in there and you have your high quality [19:14:47 CEST] <ZexaronS> you can stream anything without any loss if you really want to [19:15:09 CEST] <BtbN> If everyone has 50MBit/s for a 1080p stream, sure [19:16:11 CEST] <ZexaronS> Well but I don't expect the .ts format to support the newer HDR/WCG codecs that's what I meant, a new version of MPEG format which would be one big format without the profile cluterness [19:16:29 CEST] <atomnuker> matroska supports everything and you can stream it and you have archival features likes crc [19:16:46 CEST] <ZexaronS> crc? jeez, SHA-1 at least [19:16:56 CEST] <JEEB> you do understand that the colorspace metadata in the video format as opposed to the container format? [19:17:04 CEST] <JEEB> *is in [19:17:32 CEST] <BtbN> mpeg-ts has no profiles [19:17:42 CEST] <BtbN> you seem to be confused about what a container and a codec is. [19:18:11 CEST] <atomnuker> ZexaronS: seems like it supports sha with 160bit keys [19:19:02 CEST] <BtbN> sha has no keys oO [19:19:07 CEST] <atomnuker> though only for extradata [19:19:25 CEST] <ZexaronS> I'm talking about both, but first I'm talking about that MPEG(whatever is the lates) Container would get a new modern version, and it would be a profileless one just like MPEG-TS, but it would have all kinds the bells and whistles for super-high-quality and archival purposes as well as a transport feature, and you wouldn't need a separate "SuperMPEG" and "SuperMPEG-TS" containers [19:19:49 CEST] <BtbN> the container is not invovled with the quality in any way [19:20:06 CEST] <ZexaronS> It would have features that i can't even think of right now [19:20:15 CEST] <BtbN> must be very important features then [19:20:40 CEST] <furq> so uh [19:20:53 CEST] <furq> you're saying that there should be a separate container to mpegts so that you don't need a separate container to mpegts [19:21:36 CEST] <ZexaronS> The container it self could have some things that it would verify the video stream, so if you analyze the file, you wouldn't need to pipe the whole video through, the encoder would put it in a special place and that special place has to be supported by the container [19:22:06 CEST] <ZexaronS> it could also have redundancy [19:22:39 CEST] <ZexaronS> for the important metadata [19:23:12 CEST] <ritsuka> I hope that with all these HDR formats people will start to finally tag their file, 99% of the video out there has got no colorspace metadata, and so one player display it and another another guess the wrong colorspace& so fun [19:23:24 CEST] <BtbN> fec is applied on top of the container. [19:23:33 CEST] <ZexaronS> MediaInfo dev doesn't want to report bitrate in AAC for MP4 files because it would take full analysis of the whole video I think ... not sure if MP4 but I can find the threat [19:24:03 CEST] <BtbN> "the bitrate" is a rather useless information anyway, as it's mostly variable [19:24:07 CEST] <ritsuka> nope, it's very easy to calculate the bitrate in mp4 [19:24:21 CEST] <ZexaronS> The new container whould have requirement to put all that metadata from video/audio streams into the container's metadata, so apps like MediaInfo would have much less trobule [19:24:35 CEST] <BtbN> Sounds pointless to me [19:24:36 CEST] <relaxed> more containers! [19:24:40 CEST] <BtbN> containers already store tons of metadata [19:24:41 CEST] <ZexaronS> It's not MP4 then, it's probably MKV i think then [19:26:22 CEST] <ZexaronS> Here it is: https://sourceforge.net/p/mediainfo/feature-requests/154/ [19:26:44 CEST] <ZexaronS> https://sourceforge.net/p/mediainfo/feature-requests/154/#f91d [19:27:06 CEST] <ZexaronS> ... > Currently, I didn't find a solution without having to parse the whole file (which may be long, too long) [19:27:21 CEST] <ZexaronS> And last in 2016 still no solution [19:27:32 CEST] <BtbN> and why would that be so gravely important? [19:27:41 CEST] <BtbN> The bitrate is not overly relevant for anything [19:27:58 CEST] <BtbN> you can already write arbitrary metadata into most if not all containers [19:28:30 CEST] <ZexaronS> For me audio is very important, I have many times spent extra time/effort to get best audio and extract and add it to the video, many times I picked 720p over 1080p except keeping the best audio [19:28:54 CEST] <BtbN> and the bitrate being only an estimate affects the presence of audio in what way exactly? [19:29:16 CEST] <ZexaronS> But see, this hacky way, I want it to be properly supported, so it's clean, fast, runs great and stable, solid for 20-30 years, the goal is archival [19:29:25 CEST] <BtbN> But supported why? [19:29:28 CEST] <BtbN> Absolutely nothing needs it [19:29:35 CEST] <ZexaronS> I need it [19:29:41 CEST] <BtbN> why? [19:29:59 CEST] <ZexaronS> This may be a small thing, but this is only one I could think of right now [19:30:17 CEST] <ZexaronS> Because I'm not relying on the corporate web streaming services, I'm dumping everything offline [19:30:37 CEST] <ZexaronS> Youtube already started their censor bot [19:30:52 CEST] <ZexaronS> a week ago [19:31:25 CEST] <ZexaronS> Google has none of my interests in mind, so, screw them, taking things in my own hands [19:31:56 CEST] <BtbN> are you drunk or something? [19:33:15 CEST] <ZexaronS> Ehm, it was on drudge just a few days ago https://twitter.com/DRUDGE_REPORT/status/903786180482920448 [19:33:28 CEST] <ZexaronS> https://www.thesun.co.uk/tech/4372177/youtube-accused-of-censorship-over-co… [19:34:35 CEST] <ZexaronS> That's what the whole AI is for, not for anything good [20:25:28 CEST] <alexpigment> BtbN: I checked out your change for interlaced nvenc [20:25:52 CEST] <alexpigment> MediaInfo reports the frame rate as 29.97 now, but the interlacing is visually not correct [20:25:59 CEST] <alexpigment> I believe the frame alignment is wrong [20:26:04 CEST] <BtbN> it looks perfect to me in WMP [20:26:11 CEST] <BtbN> exactly like in the input file [20:26:20 CEST] <alexpigment> I just copied nvenc.c and nvenc.h [20:26:24 CEST] <alexpigment> Were there changes elsewhwere? [20:26:35 CEST] <BtbN> yes [20:26:47 CEST] <alexpigment> Ok, that's probably the problem [20:27:01 CEST] <BtbN> it shouldn't even compile if you just copied those two [20:27:58 CEST] <alexpigment> I didn't see any errors; I'm using a build script (Windows Build Helpers on linux), so maybe it works a little different [20:28:10 CEST] <alexpigment> at any rate, I'll try and download your whole source and go from there [20:28:59 CEST] <BtbN> https://btbn.de/public/out_test5.mp4 [20:29:25 CEST] <alexpigment> yep, that looks perfect [20:29:53 CEST] <BtbN> I suppose it might compile. But should error when you try to encode something interlaced. [20:30:09 CEST] <alexpigment> But actually, it's still reporting 59.94fps in MediaInfo [20:30:17 CEST] <alexpigment> not sure if that's a problem for compatibility elsewhere [20:30:52 CEST] <BtbN> MediaInfo is plain wrong there [20:30:55 CEST] <alexpigment> I guess I'll have to break out my collection of Blu-ray players :) [20:31:06 CEST] <BtbN> it seems like it doesn't often have to deal with field mode interlaced content [20:31:07 CEST] <alexpigment> I have about 20 different models to test with [20:31:21 CEST] <BtbN> the in-bitstream "fps" is per picture [20:31:32 CEST] <BtbN> and with field mode interlaced encoding, there is two pictures per frame [20:32:02 CEST] <BtbN> So it being 60 fps is correct [20:32:05 CEST] <alexpigment> Is field mode just "not MBAFF"? [20:32:20 CEST] <BtbN> MBAFF is one interleaved picture per frame [20:32:21 CEST] <alexpigment> or is there another nuance to field mode that is different [20:32:27 CEST] <BtbN> field mode is two seperate pictures, in seperate slices [20:32:59 CEST] <BtbN> so the picture-rate is doubled with field mode [20:33:09 CEST] <alexpigment> Here's my question: [20:33:47 CEST] <BtbN> keep in mind that this solution is a hack. It working depends entirely on the container timestamps and the muxer being able to make up proper intermediate timestamps. [20:33:49 CEST] <alexpigment> If I have an AVCHD video from a camera that reports "Scan type, store method: separate fields", is that the same thing as "field mode" to you? [20:33:55 CEST] <BtbN> As I'm just sending out every second frame without a timestamp [20:34:03 CEST] <BtbN> Yes [20:34:16 CEST] <BtbN> every second packet [20:34:22 CEST] <alexpigment> OK, I have lots of those videos that report their frame rate as 29.97 in mediainfo [20:34:33 CEST] <BtbN> They violate the spec then [20:34:41 CEST] <BtbN> The sample you gave me also violates it [20:34:43 CEST] <alexpigment> So really all I'm saying is that the two are not mutually exclusive in mediainfo [20:35:14 CEST] <alexpigment> I suppose so. It's just the standard for most AVCHD recording modes on consumer/prosumer cameras to be 29.97 and field mode [20:35:20 CEST] <alexpigment> As reported in MediaInfo [20:35:28 CEST] <BtbN> The FPS is still 29.97 [20:35:38 CEST] <BtbN> the value in the bitstream just plain does not refer to the fps [20:36:23 CEST] <alexpigment> Right. I'm really just giving you a different perspective to your assumption that MediaInfo is usually wrong for field mode interlaced content [20:36:59 CEST] <alexpigment> Again, the sample you provided a second ago looks good in WMP. I just have to do testing on a bunch of players to make sure the discrepancy of the FPS shown in MediaInfo has no impact on hardware compatibility [20:37:04 CEST] <BtbN> I am positive that the test output has the fps and timebase correctly set [20:37:20 CEST] <BtbN> nvenc even bothers to fix the framerate [20:37:22 CEST] <alexpigment> I'm not doubting you on this [20:37:31 CEST] <BtbN> it's not 2997/100. It's 30000/1001 [20:38:04 CEST] <alexpigment> Yeah, 2997/100 is a weird one for sure :) [20:38:29 CEST] <BtbN> It's some encoder having bad rounding [20:40:20 CEST] <alexpigment> Out of curiosity, do you plan on submitting your 'hack' to master? [20:40:43 CEST] <BtbN> no [20:40:46 CEST] <ZexaronS> alexpigment: did you try ffprobe to see if it's different to mediainfo ? [20:41:47 CEST] <ZexaronS> Also if you can provide details I'd put a ticket to mediainfo if you don't want to take time/effort [20:41:50 CEST] <alexpigment> ZexaronS: not yet. there was also a discrepancy between the two. However, I did get ffprobe to read 59.94 through some combination of demuxing and remuxing the other day. I'm not sure the same thing would happen after BtbN's most recent change [20:42:13 CEST] <ZexaronS> change of what? [20:42:18 CEST] <BtbN> if there was raw h264 somewhere in that chain, the framerate is messed up anyway [20:42:23 CEST] <ZexaronS> I wasn't tuned in this discussion [20:42:45 CEST] <alexpigment> ZexaronS: this file that BtbN created is the file in question: https://btbn.de/public/out_test5.mp4 [20:43:27 CEST] <alexpigment> I can't 100% say that MediaInfo is "wrong" here, but they may be pulling the frame rate from a different method than other players [20:43:58 CEST] <BtbN> the framerate is clearly not that. So it's wrong. [20:44:01 CEST] <alexpigment> Hence why I need to test and make sure that certain hardware doesn't also read in that method and try to deinterlace based on the wrong frame rate [20:44:16 CEST] <BtbN> The framerate is also 100% irrelevant. [20:44:22 CEST] <BtbN> The timestamps are what matters. [20:44:47 CEST] <alexpigment> BtbN: I'm not doubting you. I don't care about what's right/wrong. I care about universal compatibility. I can't go to LG and say "hey fix this Blu-ray player you made in 2010 and sold to millions of people" [20:46:00 CEST] <alexpigment> And while I trust your assumption, I also know how hardware generally works. They have bugs for things that they don't commonly deal with [20:48:20 CEST] <JEEB> just stop guessing things and actually try the output on the thing you think might be failing with it [20:48:38 CEST] <JEEB> there is no such thing as universal compatibility anyways, you have to put a limit somewhere on how dumb something is [20:49:44 CEST] <JEEB> so if you care about some hardware and think it's gonna fail, just test it instead of trying to make decisions based on information presented to you by chinese whispers that you do not understand what they are based upon [20:50:29 CEST] <alexpigment> JEEB: did you miss the part where I said I'm going to test on hardware? [20:50:50 CEST] <alexpigment> Unlike you guys, I *do* have a test bank of around 20 players [20:51:02 CEST] <JEEB> yes because your last two lines or so were talking of what I commented upon [20:51:21 CEST] <JEEB> and yes, look down upon people. great way of making people motivated to help you. [20:51:25 CEST] <alexpigment> Ok, well *I'm going to test hardware compatibility* [20:51:34 CEST] <JEEB> you don't know what we work with or how we test things [20:51:50 CEST] <alexpigment> You're right. I'm making a bad assumption [20:51:58 CEST] <alexpigment> I apologize [20:52:14 CEST] <alexpigment> You just came at me as if I was just giving idle speculation [20:52:24 CEST] <JEEB> well you base on random numbers output from mediainfo mostly [20:52:30 CEST] <JEEB> which I know can be misleading [20:52:39 CEST] <alexpigment> I agree with that [20:52:41 CEST] <JEEB> the only way to know what exactly comes out of mediainfo is to read the source [20:52:52 CEST] <JEEB> since it doesn't always tell you what something actually means [20:52:52 CEST] <alexpigment> But if MediaInfo sees it wrong, there's a chance that some hardware can play it wrong [20:52:57 CEST] <alexpigment> So I need to test on hardware [20:53:03 CEST] <alexpigment> Which I will be doing [20:53:58 CEST] <alexpigment> If there's an issue, I'll report back. Otherwise, I believe BtbN's hack will work perfectly fine on those players [21:02:51 CEST] <alexpigment> BtbN: I'm not sure if this is any clue here, but if you take your file out_test5.mp4 and then transcode it to progressive via yadif=1, it becomes 120fps [21:03:22 CEST] <durandal_1707> thats normal [21:03:29 CEST] <alexpigment> Handbrake also doesn't deinterlace it properly; I think they use yadif as well [21:03:46 CEST] <alexpigment> durandal_1707: how so? [21:04:02 CEST] <durandal_1707> it outputs fields [21:04:07 CEST] <alexpigment> right [21:04:22 CEST] <alexpigment> there should be 59.94 fields that get turned into 59.94 frames [21:04:30 CEST] <alexpigment> (per second, of course) [21:05:38 CEST] <durandal_1707> whats is fps of original videeo? [21:06:07 CEST] <alexpigment> Well, that's the question of interest here [21:06:15 CEST] <alexpigment> It's supposed to be 29.97 interlaced [21:06:42 CEST] <alexpigment> MediaInfo reports it as 59.94fps interlaced, but BtbN thinks that MediaInfo is just reporting it wrong (which may be very true) [21:06:53 CEST] <alexpigment> But Yadif is also apparently reading it wrong if that's true [21:06:54 CEST] <durandal_1707> but whats reported by ffmpeg [21:07:12 CEST] <Nosomy> yadif=0, desinterlace in "original" video fps [21:07:23 CEST] <Nosomy> yadif=1, makes in double [21:07:30 CEST] <alexpigment> Right [21:07:38 CEST] <alexpigment> 59.94fps interlaced doesn't exist though [21:07:49 CEST] <alexpigment> Or at least, it's not a standard for video [21:08:20 CEST] <alexpigment> ffmpeg does report it as 59.94fps though [21:08:33 CEST] <Nosomy> 60000/1001 fps exist in intelaced, but is uncommon [21:08:51 CEST] <alexpigment> It's not a standard though, to my knowledge [21:09:04 CEST] <JEEB> why not check how the ffmpeg demuxer / decoder that you're using handles it and if it's really outputting 120 Hz progressive out (because the deinterlacer will double the time base but the actual timestamps of the output don't need to be on each possible picture of that [21:09:51 CEST] <alexpigment> Pardon my ignorance, but I'm not entirely sure how to test for that [21:10:01 CEST] <alexpigment> I'm using yadif as my roundabout way to test that [21:10:18 CEST] <JEEB> ffprobe -show_frames -of json input.file (and then pipe into less or a file for browsing) [21:10:34 CEST] <JEEB> also there was a parameter for ffprobe to limit the thing to the video track [21:11:13 CEST] <JEEB> -of json is just so it can be parsed more easily by various things, but as long as you get the timestamps of the decoded frames *somehow* that should be enough [21:11:52 CEST] <JEEB> -select_streams v:0 it seems :P [21:12:07 CEST] <JEEB> picks the first video track only (if the file has audio etc) [21:13:08 CEST] <alexpigment> that spits out a lot of data [21:13:22 CEST] <alexpigment> I'm not sure how to gather the info you're talking about based on what I'm seeing [21:13:43 CEST] <JEEB> that's why I told you to either pipe it to less or output to file [21:13:52 CEST] <JEEB> first ~four frames should be enough [21:13:57 CEST] <JEEB> there might be a parameter to limit it to that [21:14:03 CEST] <alexpigment> yeah, I've got it in a text file [21:14:12 CEST] <alexpigment> I guess just derive it from the time stamps? [21:14:20 CEST] <JEEB> post the first five or so frames onto a pastebin or so and link here [21:14:34 CEST] <JEEB> I *think* show_frames should actually decode the stuff [21:14:46 CEST] <alexpigment> https://pastebin.com/8eqV5EAg [21:15:54 CEST] <JEEB> ok, so +400 per picture [21:16:05 CEST] <JEEB> now do -show_streams which should show the time_base [21:16:14 CEST] <JEEB> (you can derive it from the _time things but yunno) [21:16:40 CEST] <BtbN> It's entirely possible ffmpeg just does not support field mode interlacing. It's a hack after all. [21:16:50 CEST] <BtbN> Nobody ever did that before to my knowledge. [21:17:06 CEST] <BtbN> So I wouldn't be surprised if it things the two fields are actual frames. [21:17:09 CEST] <alexpigment> https://pastebin.com/EJZfXhVc [21:17:11 CEST] <JEEB> uhh, I'm pretty sure FFmpeg's AVC decoder should be tested with that, but I don't know after that :) [21:17:15 CEST] <JEEB> as in, yadif could have issues [21:17:28 CEST] <BtbN> JEEB, for decoding, yes. But not producing it. [21:17:42 CEST] <BtbN> As in, every AVPacket is expected to contain a frame. Not a field. [21:17:59 CEST] <JEEB> well yea, that definition isn't exactly true [21:18:17 CEST] <JEEB> but as you have seen there's cracks here and there [21:18:31 CEST] <alexpigment> fwiw, here are some AVCHD samples from cameras: https://www.shedworx.com/shedworx-samples [21:18:35 CEST] <alexpigment> i.e. the second video [21:18:42 CEST] <BtbN> The hack is to just split the bitstream on the slice boundaries. [21:18:44 CEST] <alexpigment> that's probably a good point of reference [21:18:48 CEST] <BtbN> And output two packets per input frame [21:18:50 CEST] <JEEB> anyways, 1/11988 is the time_base for that stream 0 [21:19:20 CEST] <JEEB> given that the PTS goes up 400 [21:19:24 CEST] <JEEB> per picture [21:19:31 CEST] <JEEB> and we expect that to be static [21:19:42 CEST] <JEEB> >>> 11988/400 [21:19:43 CEST] <JEEB> 29.97 [21:19:53 CEST] <JEEB> so yea, the decoders are outputting that correctly :P [21:19:56 CEST] <Nosomy> >Canon HG10, NTSC 60i mode [21:20:07 CEST] <Nosomy> exotic. [21:20:52 CEST] <alexpigment> Nosomy: those sexy fences ;) [21:21:33 CEST] <JEEB> alexpigment: anyways, looking at what the FFmpeg decoder gives out the time base is 1/11988, but the pictures are output with proper timestamps to give you 30000/1001 or so per second [21:22:59 CEST] <alexpigment> JEEB: does that seem concercerning for compatibility, then? [21:23:13 CEST] <alexpigment> I'm comparing other non-MBAFF streams in yadif and they come out as 59.94fps [21:23:34 CEST] <JEEB> the time base is a bit weird, but nope? are you sure yadif is actually pushing out double the pictures? [21:23:39 CEST] <alexpigment> yes [21:23:41 CEST] <alexpigment> yadif=1 [21:23:44 CEST] <JEEB> ... [21:23:48 CEST] <JEEB> that's not what I meant [21:23:58 CEST] <alexpigment> and then the output file is ~120fps and then doesn't work in WMP [21:24:20 CEST] <alexpigment> presumably because I'm on Windows 7 and it doesn't handle 120fps correctly via DXVA2 [21:24:32 CEST] <JEEB> there can be various reasons why it doesn't work in WMP, to be honest. so I would like you to output a few frames of that thing and check the things we just did with the input [21:24:47 CEST] <alexpigment> K [21:24:50 CEST] <JEEB> that way we can see if yadif did a dumb thing or not [21:24:55 CEST] <JEEB> instead of playing the guessing game [21:25:42 CEST] <durandal_1707> settb filter [21:26:19 CEST] <BtbN> Can I require that to be used from within an encoder? [21:26:34 CEST] <alexpigment> deinterlaced: https://pastebin.com/CuArWGic [21:26:53 CEST] <JEEB> can we get a -show_streams as well? [21:26:59 CEST] <JEEB> which shows the time base [21:27:07 CEST] <alexpigment> https://pastebin.com/qHYMcn7u [21:27:12 CEST] <JEEB> danke [21:27:21 CEST] <BtbN> durandal_1707, settb can't increase the ticks_per_frame it seems [21:27:34 CEST] <JEEB> ok, so the time base got duplicated as expected from yadif 1001/240000 [21:27:41 CEST] <JEEB> now for the actual time stamps [21:28:06 CEST] <durandal_1707> BtbN: whats that? [21:28:26 CEST] <JEEB> or wait no, actual time_base is 1/120000 [21:28:26 CEST] <BtbN> it's what determines the fps [21:28:36 CEST] <JEEB> fuck, I always end up grabbing the codec_time_base first :P [21:29:20 CEST] <JEEB> ok, yea. seems like yadif did a dumb [21:29:46 CEST] <durandal_1707> what dumb? [21:29:48 CEST] <JEEB> the decoded time stamps were properly 30000/1001 for two-fields-in-one pack (most likely the AVC decoder does that) [21:30:20 CEST] <JEEB> durandal_1707: it got interlaced "frames" at 30000/1001 but with a weird time_base [21:30:31 CEST] <BtbN> the original file is already misdetected by ffmpeg as 60fps though, while it actually is only 30 but interlaced [21:30:32 CEST] <JEEB> so the end result seems to have been 120000/1001 [21:30:51 CEST] <JEEB> BtbN: "misdetection" doesn't really matter since the decoder seems to output correct timestamps [21:31:05 CEST] <JEEB> we got +400 for each pts [21:31:18 CEST] <JEEB> and the time base was 1/11988 [21:31:24 CEST] <BtbN> it's probably messed up container data, due to my hack to create that file [21:32:03 CEST] <JEEB> possibly, but the timestamps seem correct [21:32:08 CEST] <JEEB> so either ffmpeg.c or yadif did a dumb :) [21:32:23 CEST] <JEEB> decoding wise the AVC decoder did the right thing at least [21:33:28 CEST] <BtbN> I wish there way a way to modify the timebase from an encoder [21:34:08 CEST] <JEEB> AVPackets having their own time_base would be gut [21:34:37 CEST] <JEEB> then you could init the muxer with that [00:00:00 CEST] --- Mon Sep 4 2017

1 0

ffmpeg-devel.log.20170902
by burek 03 Sep '17

03 Sep '17

[00:01:43 CEST] <durandal_170> atomnuker: some kind of multiply blend [00:03:30 CEST] <atomnuker> oh [00:03:45 CEST] <atomnuker> something to do with complex -> real maybe? [00:19:13 CEST] <durandal_170> atomnuker: i now know how to get each quadrant intact [00:21:48 CEST] <atomnuker> cool, so you got it working? [00:22:30 CEST] <durandal_170> atomnuker: no, i wonder why i cant get them in one go [00:51:01 CEST] <durandal_1707> i think i could put other half of frame into im, what that will do? [00:59:27 CEST] <thardin> https://www.youtube.com/watch?v=Sx4BVGPkdzk [00:59:53 CEST] <thardin> derp, wrong channel [00:59:57 CEST] <thardin> well, still relevant of course [01:01:31 CEST] <thardin> for there may lurk centrists everywhere that need their political radar calibrated for these times [01:02:21 CEST] <durandal_1707> hard times [01:02:36 CEST] <thardin> hard, like bepis [01:15:38 CEST] <atomnuker> rcombs: so what's left to do with the flac pic embedding patch? [01:15:54 CEST] <rcombs> uhhh [01:16:01 CEST] <rcombs> there might've been an error handling thing [01:16:48 CEST] <atomnuker> I know someone who would know [01:16:52 CEST] Action: atomnuker summons jamrial [01:25:33 CEST] <jamrial> i replied to the latest version mentioning what was left to do [01:31:50 CEST] <iive> thardin: I like that video. I've picked up most of these things, but it is nice to see them all in one place. [02:07:19 CEST] <thardin> yes [02:15:15 CEST] <thardin> yikes, it's late [02:32:10 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:498e07daa18c: avformat/hls: Fix DoS due to infinite loop [02:32:10 CEST] <cone-223> ffmpeg 03Yi and *®() 07release/2.8:6904464301bb: avformat/asfdec: Fix DoS due to lack of eof check [02:32:10 CEST] <cone-223> ffmpeg 03Yi and *®() 07release/2.8:c70fdd994808: avformat/cinedec: Fix DoS due to lack of eof check [02:32:10 CEST] <cone-223> ffmpeg 03Yi and *®() 07release/2.8:1720050ae6eb: avformat/rl2: Fix DoS due to lack of eof check [02:32:10 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:6b004e23d7fc: avformat/mvdec: Fix DoS due to lack of eof check [02:32:11 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:2ff2402c65dc: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate() [02:32:11 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:1a5b9b3b8eb5: avcodec/hevc_ps: Fix undefined shift in pcm code [02:32:12 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:74429912dcd7: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered() [02:32:12 CEST] <cone-223> ffmpeg 03Yi(SÑ) 07release/2.8:5b3986023bbf: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop. [02:32:13 CEST] <cone-223> ffmpeg 03Yi(SÑ) 07release/2.8:accf7d34a882: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array() [02:32:14 CEST] <cone-223> ffmpeg 03Yi(SÑ) 07release/2.8:d68602650766: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack() [02:32:15 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:7f0359f05e32: Changelog: Update [02:57:52 CEST] <cone-223> ffmpeg 03James Almer 07n2.8.13:HEAD: avcodec/internal: move FF_QSCALE_TYPE defines from avcodec.h [03:12:50 CEST] <rpw> how can I retrieve the SwsFilter src and dst vars used to init an SwsContent? [11:34:56 CEST] <durandal_170> atomnuker: got it working with NxN images, broken with MxN images [13:21:43 CEST] <durandal_170> atomnuker: dunno with what to pad edges of NxM matrix when doing 2d fft [13:28:07 CEST] <BtbN> Is there some easy way to hand-edit h264 bitstream? [13:29:19 CEST] <durandal_170> yes, hex editor [13:30:45 CEST] <BtbN> How would I possibly fine a few single bit values with a plain hex editor? [13:30:49 CEST] <BtbN> *find [13:32:14 CEST] <durandal_170> there are editors with search funcionality afaik [13:36:27 CEST] <BtbN> The only one I found was 300¬ [13:40:26 CEST] <Blubberbub> hexdump + grep? [13:41:06 CEST] <durandal_170> do you really neeed searching by bits and not by hex? [13:41:19 CEST] <BtbN> The SPS is a bitstream [13:41:26 CEST] <BtbN> I definitely need to find the right bits [13:41:34 CEST] <durandal_170> how many of them? [13:41:35 CEST] <BtbN> and their position changes, depending on how some other bits are set or not set [13:41:47 CEST] <BtbN> I want to edit the timing_info in the VUI [13:42:11 CEST] <durandal_170> write bitstream filter :) [13:42:13 CEST] <BtbN> which is two 32bit unsigned values [13:42:27 CEST] <jkqxz> Already exists. h264_metadata, tick_rate option: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215070.html>. [13:48:04 CEST] <BtbN> git am does not like that at all, weird [13:48:46 CEST] <BtbN> oh, it needs WAY more patches [13:59:34 CEST] <durandal_170> atomnuker: see this line: https://github.com/richardpl/FFmpeg/blob/8815496c60d52a5af4bfd12eadc1a9cd1d… [13:59:54 CEST] <durandal_170> with what to fill that, its only active for MxN case [14:02:29 CEST] <durandal_170> hm, i got idea [14:06:56 CEST] <ubitux> any objection to the autodetect patchset? [14:07:10 CEST] <ubitux> it's been 3days (+previous version of the patchset) [14:26:00 CEST] <wm4> just push it [14:30:34 CEST] <JEEB> the change seems pretty good, I just haven't been able to build with the patch [14:30:52 CEST] <JEEB> which I think I'm going to fix now :3 [14:31:02 CEST] <ubitux> i'm not sure how to interpret that 2nd part of your sentence [14:31:28 CEST] <ubitux> "i still didn't manage to get your patch working, LGTM" [14:31:41 CEST] <nevcairiel> sounds more like "i just didnt test it" [14:31:48 CEST] <JEEB> no, more like "I didn't have the time to get the patch and build with it" [14:31:56 CEST] <JEEB> which is something I'm going to fix now :P [14:32:01 CEST] <ubitux> :) [14:32:17 CEST] <JEEB> btw, since it's a patch set - do you have a remote I can pull them from :D [14:32:30 CEST] <JEEB> or do I just curl them from patchwork [14:32:31 CEST] <JEEB> :3 [14:32:43 CEST] <JEEB> (if you have a remote I can fetch them from with git that'd be simpler) [14:33:10 CEST] <ubitux> git remote add ubitux git@github.com:ubitux/FFmpeg [14:33:15 CEST] <ubitux> git fetch ubitux [14:33:19 CEST] <JEEB> merci [14:33:19 CEST] <ubitux> git checkout autodetect [14:34:51 CEST] <JEEB> merged to current master (only thing conflicting was Changelog and that was simple) [14:35:57 CEST] <nevcairiel> i really like the --disable-autodetect option, so thanks for that :) [14:36:00 CEST] <JEEB> yea [14:36:19 CEST] <JEEB> the iconv is the thing nicholas commented about wrt stdlib I guess? [14:36:34 CEST] <ubitux> nevcairiel: np [14:36:41 CEST] <ubitux> JEEB: yep, see the comment on the patchset [14:36:46 CEST] <ubitux> s/comment/first mail/ [14:36:49 CEST] <JEEB> yea [14:37:28 CEST] <ubitux> just updated the tree rebased on master [14:37:58 CEST] <JEEB> also darn it, you had mentioned the github tree in the quoted part of your mail :) [14:38:03 CEST] Action: JEEB is blind [14:38:10 CEST] <ubitux> :) [14:44:37 CEST] <BtbN> discovery of the day: Setting a nonsensical framerate for testing to nvenc, when in interlaced encoding mode, crashes the driver [14:44:52 CEST] <BtbN> It really does not like 65k fps it seems [14:57:46 CEST] <JEEB> ubitux: added my useless +1 to the thread ;) [14:58:09 CEST] <ubitux> great, thanks [14:58:23 CEST] <ubitux> i'll give it maybe half an hour to 1h and push [15:28:56 CEST] <kurosu> jkqxz, btw, what's the status of your (cbs) patchset ? [15:29:52 CEST] <kurosu> (waiting reviews I guess) [15:32:04 CEST] <jkqxz> Michael made some useful comments; there are some new changes on the libav list, once they go through I'll merge and send a new set. [15:48:09 CEST] <BtbN> Any h264 expert here? How essential is the picture timing SEI for interlaced content. It seems to contain the information about the field order, so it seems important to me? [15:48:35 CEST] <nevcairiel> field order can also be derived through other means [15:48:52 CEST] <nevcairiel> at least in PAFF [15:49:05 CEST] <nevcairiel> (ie. field coded) [15:51:42 CEST] <BtbN> Yeah, that's what nvenc does. One Picture-Slice per field. So it encodes them as seperate "frames" I guess [15:51:54 CEST] <BtbN> If you ask it to do MBAFF, it fails to initialize [15:52:00 CEST] <jkqxz> It is required if pic_struct_present_flag is 1 (see D.2.3). [15:52:19 CEST] <BtbN> It does set that to 0 if the timing SEI is disabled [15:52:21 CEST] <nevcairiel> in paff you can derive the field order from the POC i believe [15:52:21 CEST] <BtbN> and to 1 if you enable it [15:52:33 CEST] <nevcairiel> but its probably better to just emit the SEI if it can do that [15:52:40 CEST] <jkqxz> If you set pic_struct_present_flag to 0 then there are some fixed rules for how the pic_struct is worked out. [15:53:18 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/0d49f7df3104085075316cce18e9fcc4a299d… the patch is rather trivial [15:53:27 CEST] <BtbN> I guess it won't hurt to just enable it [15:53:38 CEST] <nevcairiel> i would just make it output that all the time [15:54:15 CEST] <BtbN> for some weird reason strict CBR is tied to it [15:54:37 CEST] <BtbN> Like, if you enable that SEI, it will emit filler data to reach the target bitrate in CBR mode [15:54:41 CEST] <BtbN> without that SEI, it won't [15:58:12 CEST] <jkqxz> The HRD conformance definition depends on the SEI timing messages. [15:58:20 CEST] <jkqxz> So it's probably a consequence of that. [15:59:59 CEST] <BtbN> hm, I suppose it can safely be emited though. It's enabled for CBR anyway. [16:00:53 CEST] <jkqxz> Yeah, most things just ignore them. The one painful case is RTP transport, when they end up increasing the packet rate. [16:01:05 CEST] <jkqxz> Because of how the packetisation works. [16:03:09 CEST] <BtbN> Currently trying to figure out why interlaced output with nvenc is subtly broken in some player. [16:03:12 CEST] <BtbN> Namely in WMP [16:04:01 CEST] <nevcairiel> define subtly [16:04:22 CEST] <nevcairiel> the MS h264 decoder is usually not bad as long as you stay within its supported profiles [16:05:12 CEST] <BtbN> It looks like it's stuttering. [16:05:18 CEST] <BtbN> Like, 30 FPS instead of 60 [16:05:42 CEST] <BtbN> If I encode with libx264, everything is fine. Encoding with nvenc produces that stuttering [16:06:13 CEST] <BtbN> The biggest difference is that the libx264 and the original sample use MBAFF. And nvenc uses seperate fields [16:06:28 CEST] <BtbN> And that nvenc wasn't outputting timing SEIs. Which it is now [16:06:33 CEST] <BtbN> but still unsmooth [16:07:09 CEST] <nevcairiel> are the timestamps proper then for the separate fields? [16:07:41 CEST] <BtbN> That's a good question. Are there even timestamps in the h264 bitstream? [16:08:45 CEST] <nevcairiel> kind of, but thats not what I was referring to, its still the encoders job to make proper encoded timestamps, especially if you handle field-coded interlaced, since you have twice as many output "fields" then you had input frames [16:09:20 CEST] <cone-811> ffmpeg 03Timo Rothenpieler 07master:4e6638abb4fc: avcodec/nvenc: always output picture timing SEI [16:09:33 CEST] <ubitux> fits tests are broken or that's me? [16:09:44 CEST] <nevcairiel> its broken [16:10:12 CEST] <ubitux> ok [16:10:25 CEST] <jkqxz> The pic_timing SEI contains relative timestamps, if it looks at them. The container timestamps are more likely to be relevant, though. [16:10:51 CEST] <BtbN> nevcairiel, I have actually no idea how nvenc returns those two seperate fields. There is no logic to double timestamps in interlaced encoding mode. [16:11:02 CEST] <BtbN> So I guess it returns two of them at a time, and they only get one timestamp? [16:11:25 CEST] <nevcairiel> avcodecs problem is that with the "old" internal API you can't output two packets for one input frame, but the new API at least can do that now [16:11:38 CEST] <BtbN> nvenc is using the old API [16:11:39 CEST] <BtbN> and it works [16:11:49 CEST] <BtbN> So it must be outputting the two slices as one frame at once [16:11:51 CEST] <nevcairiel> well probably because it just throws both fields into one packet [16:12:03 CEST] <nevcairiel> so they get one timestamp [16:12:08 CEST] <nevcairiel> which might throw the decoder off [16:12:13 CEST] <BtbN> I have no idea how I could possibly fix that [16:12:21 CEST] <nevcairiel> a proper field-coded h264 stream has distinct timestamps for the fields [16:15:07 CEST] <BtbN> the nvenc API can only output exactly one packet per input frame [16:15:20 CEST] <BtbN> So I guess it has to put the two seperate fields into a single packet [16:16:48 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:e70e2a7abdd4: build: group z libs with other autodetected libraries [16:16:49 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:55fdfc88b844: build: treat crystalhd like other hwaccels [16:16:50 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:c9075d2c652b: build: treat iconv like other autodetected libraries [16:16:51 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:1c08ff08adc4: build: treat libxcb like other autodetected libraries [16:16:52 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:72655616d9d1: build: treat securetransport and schannel like other autodetected libraries [16:16:53 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:778fa6350e24: build: isolate sdl-to-sdl2 aliasing [16:16:54 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:b802971d6db5: build: treat sdl2 like other autodetected libraries [16:16:55 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:353c2e384c70: build: replace use of HAVE_SDL2 with existing CONFIG_SDL2 [16:16:56 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:7e98c3cbb372: build: remove vda_framework from enable_weak [16:16:57 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:9ef5a2f5f30b: build: simplify weak-enabling of autodetected libraries [16:16:58 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:e3c1219c7c74: build: add --disable-autodetect switch [16:16:59 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:fe9c85e4e265: build: make sure a disabled autodetect still pick the libc's iconv [16:17:00 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:b447629093d7: build: make alsa part of the autodetected libraries [16:17:01 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:b7fbb3516a99: build: make jack part of the autodetected libraries [16:17:02 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:e090e750bac8: build: make sndio part of the autodetected libraries [16:17:03 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:69e6877de8ad: build: drop unused sndio_h and asoundlib_h [16:17:11 CEST] <BtbN> nice [16:17:22 CEST] <JEEB> \o/ [16:20:37 CEST] <BBB> ubitux: sweet! [16:20:47 CEST] <durandal_170> HURRAY!! [16:21:02 CEST] <BBB> (Ive been compilig binaries with combinations of disable-abcdefghijklmnop for years now, this makes it so much easier) [16:21:08 CEST] <ubitux> it would be nice to have the pthread thing handled correctly though [16:21:29 CEST] <BBB> you said lets get this in and make the pthread portion perfect later, and I think you got that exactly right [16:21:37 CEST] <BBB> or something like that [16:21:50 CEST] <ubitux> yeah [16:22:26 CEST] <BBB> "libpthread" vs "pthread" is still not handled, but that's not blocking [16:22:27 CEST] <BBB> for this patchset. Actually, I'd rather have it pushed before messing [16:22:28 CEST] <BBB> around with something sensible like pthread. ubitux, 8/30/17 [16:22:36 CEST] <BBB> just to make sure I got that quote right :-p [16:22:42 CEST] <ubitux> :) [16:22:49 CEST] <BBB> again, thank you, I love this patchset [16:22:56 CEST] <BBB> purely selfish, but still [16:22:59 CEST] <ubitux> np, glad it helps [16:23:28 CEST] <nevcairiel> indeed, can probably rip out a bunch of nonsense from various build scripts, and worry less in the future [16:23:33 CEST] <BBB> does anyone have major objections to the execute3 patch to have a main function in the slice threading for avcodec? [16:23:50 CEST] <nevcairiel> what exactly does that do? execute a follow up function after the threads finish? [16:24:00 CEST] <BBB> alongside [16:24:09 CEST] <BtbN> nevcairiel, I wonder if nvenc expects to get seperate fields as input in the first place? [16:24:14 CEST] <BBB> in vp9, the tile (~~ slice) threads work on separate units [16:24:21 CEST] <BBB> but the loopfilter works in the main function [16:24:33 CEST] <nevcairiel> BtbN: that would be weird, barely anthing ever handles lonely fields in raw [16:24:34 CEST] <BBB> you can either do that after-the-fact, or (this is better for caching) alongside the tile threads [16:24:49 CEST] <BBB> so thats 1 main function (since lpf crosses tile boundaries) [16:25:01 CEST] <BBB> its very strange, I admit [16:25:24 CEST] <BtbN> nevcairiel, hm, specially as it has a flag on the frames, which reads NV_ENC_PIC_STRUCT_FIELD_TOP_BOTTOM ot BOTTOM_TOP [16:25:25 CEST] <BtbN> not TOP or BOTTOM [16:26:25 CEST] <ubitux> BBB: i think so cleanups are still required for the videotoolbox and avfoundation stuff [16:26:29 CEST] <ubitux> you may want to have a look [16:26:41 CEST] <nevcairiel> BBB: so it executes them tile by tile as the tiles finish, instead of in one go afterwards? [16:26:52 CEST] <BBB> nevcairiel: row-by-row [16:27:00 CEST] <BBB> nevcairiel: lpf has no tile awareness, it crosses tile boundaries [16:27:09 CEST] <BBB> nevcairiel: imagine you have 4 tile columns, 4 threads [16:27:10 CEST] <BtbN> nevcairiel, if I output to raw h264, and then re-mux that with ffmpeg. It should "fix" it, right? [16:27:10 CEST] <nevcairiel> oh well, same thing, just more granularity [16:27:16 CEST] <BBB> as each finishes row1, the loopfilter for row1 can execute [16:27:19 CEST] <BBB> yes [16:27:32 CEST] <nevcairiel> what thread does it run on? does it make its own? take one from the pool? [16:27:46 CEST] <ubitux> typically, videotoolbox is *not* part of auto lib list (but is marked as autodetect), but there is that videotoolbox_hwaccel thing [16:27:54 CEST] <ubitux> which is inconsistent with all other hwaccel [16:27:58 CEST] <nevcairiel> BtbN: not sure if its smart enough to make new timestamps [16:28:06 CEST] <BBB> -threads N creates N-1 threads without this, and the last thread runs in the main function (since execute() blocks anyway) [16:28:08 CEST] <ubitux> (it's also in a weird place) [16:28:12 CEST] <BtbN> nevcairiel, there are no timestamps in raw h264 though? [16:28:16 CEST] <BtbN> so it has to [16:28:22 CEST] <nevcairiel> well not hard to try [16:28:23 CEST] <BBB> so with this, -threads N creates N threads and the main function (which is supposed to block) calls this extra function [16:28:39 CEST] <BtbN> nevcairiel, it does indeed fix it [16:28:42 CEST] <BBB> so it sort of creates an extra thread, I guess [16:28:53 CEST] <nevcairiel> BBB: i see [16:29:01 CEST] <BBB> ubitux: I believe vtb is autodetected [16:29:10 CEST] <BBB> ubitux: at least for me it always is compiled in I think? [16:29:18 CEST] <BBB> (on a mac) [16:29:21 CEST] <ubitux> maybe, but it's inconsistent [16:29:33 CEST] <ubitux> as a result it may not be disabled by --disable-autodetect [16:29:37 CEST] <ubitux> you may want to check [16:29:48 CEST] <BBB> ah I see what you mean [16:29:51 CEST] <BBB> okiedokie I shall check [16:30:11 CEST] <nevcairiel> BBB: i havent looked at the code but if it helps to boost performance, it should be fine [16:30:18 CEST] <ubitux> pretty sure you want to drop videotoolbox from EXTERNAL_LIBRARY_LIST, and rename videotoolbox_hwaccel to videotoolbox in HWACCEL_AUTODETECT_LIBRARY_LIST [16:30:28 CEST] <ubitux> (and fix the rest of the configure) [16:30:37 CEST] <BBB> you know configure is black magic for me, right? [16:30:45 CEST] <BBB> I know just enough python to do a 3-line script [16:30:46 CEST] <ubitux> compare with other hwaccel [16:30:51 CEST] <BBB> my shell scripting is worse :-p [16:31:02 CEST] <BBB> hm Ill look [16:31:04 CEST] <ubitux> i'm guessing audiotoolbox is a good reference point [16:31:10 CEST] <BBB> Ill ask many stupid questions [16:31:12 CEST] <BBB> just so you know [16:31:15 CEST] <ubitux> sure [16:32:13 CEST] <BBB> so disable-autodetect should disable everything like x, vda, vtb, etc., right? [16:32:19 CEST] <BBB> so only c, m and pthreads are left [16:32:22 CEST] <BBB> and ld [16:32:33 CEST] <ubitux> ideally yes [16:33:05 CEST] <ubitux> i have tested on mac so a bunch of other stuff may still be in (such as VT as i mentioned) [16:33:13 CEST] <ubitux> have not* [16:34:45 CEST] <BBB> Enabled indevs: [16:34:45 CEST] <BBB> avfoundation lavfi [16:34:49 CEST] <BBB> I guess that is the problem? [16:35:01 CEST] <ubitux> lavfi is fine, avfoundation isn't [16:35:05 CEST] <BtbN> hm, I cannot think of a way to fix this. Without moving nvenc to the new API [16:35:08 CEST] <ubitux> avfoundation is another thing than videotoolbox btw [16:35:13 CEST] <ubitux> it's even higher level [16:35:31 CEST] <nevcairiel> avfoundation is probably not handled the same way as anything else, i remember it having special dealys everywhere because of its ObjC mess [16:35:43 CEST] <ubitux> yeah [16:35:52 CEST] <ubitux> it's in the "external library" things [16:35:55 CEST] <ubitux> for some reason [16:36:00 CEST] <BBB> vtb is properly disabled [16:36:16 CEST] <BBB> and the vtb hwaccel is also [16:37:39 CEST] <BBB> its called avfoundation_index [16:37:48 CEST] <BBB> do I need to add it to some list to get autodetect-disable to work? [16:38:21 CEST] <ubitux> i think it needs to be split avfoundation + avfoundation_indev [16:38:30 CEST] <ubitux> avfoundation_indev with a deps on avfoundation [16:38:37 CEST] <ubitux> and avfoundation in the autodetect list with the others [16:39:01 CEST] <ubitux> and the weird avfoundation_indev checks move earlier with the other autodetect stuff [16:40:07 CEST] <ubitux> that stuff is weirdly done ;) [16:40:57 CEST] <BBB> let me see if I understand this... [16:41:02 CEST] <BBB> Im testing random stuff [16:41:04 CEST] <BBB> no idea what Im doing [16:41:17 CEST] <ubitux> i'm sure you're having a lot of fun [16:44:08 CEST] <BBB> thats a pretty broad definition of fun :-p [16:48:18 CEST] <BBB> ok, so [16:48:21 CEST] <BBB> it works partially [16:48:25 CEST] <bove> I am creating a decoder for a raw-ish format, and am trying to understand what's the absolute minimum for a decode function. Am I correct that the input comes from avpkt->data and the output is set to data->data? [16:48:39 CEST] <BBB> vda is disabled [16:48:43 CEST] <BBB> vtb is disabled [16:48:45 CEST] <BBB> avf is disabled [16:48:46 CEST] <BBB> but [16:48:54 CEST] <BBB> -framework QuartzCore is still part of EXTRALIBS [16:48:56 CEST] <BBB> why?!? [16:50:25 CEST] <BBB> qtkit is also disabled btw [16:50:42 CEST] <atomnuker> bove: yes, the data argument in the decode function you need to cast to an AVFrame and then write to its data fields [16:50:52 CEST] <BBB> ah, coreimage [16:50:54 CEST] <BBB> what is coreimage? [16:50:59 CEST] <atomnuker> you also need to set *got_frame = 1 to indicate you have something to output [16:51:28 CEST] <atomnuker> (and you also need to call ff_get_buffer to allocate the data fields in the avframe before you start decoding to them) [16:51:45 CEST] <BBB> let me try again with coreimage added to that list also [16:54:17 CEST] <BBB> crap, almost [16:54:26 CEST] <BBB> left with CoreGraphics and CoreServices [16:55:41 CEST] <BBB> huh [16:55:42 CEST] <BBB> check_lib coreservices "CoreServices/CoreServices.h" UTGetOSTypeFromString "-framework CoreServices" [16:55:46 CEST] <BBB> thats just there unconditionally [16:55:49 CEST] <BBB> does anyone know why? [16:57:16 CEST] <BBB> seems part of videotoolbox [16:58:26 CEST] <BBB> more hackyhack [16:58:38 CEST] <ubitux> this is just to define HAVE_UTGETOSTYPEFROMSTRING [16:59:32 CEST] <ubitux> (and actually link to that stuff if available) [17:01:10 CEST] <BBB> yes [17:01:11 CEST] <BBB> so [17:01:12 CEST] <BBB> -framework CoreGraphics [17:01:16 CEST] <BBB> I still have that [17:01:21 CEST] <BBB> I dont understand where it comes from [17:01:32 CEST] <bove> atomnuker: Thanks!!! seems ff_get_buffer() was the missing bit [17:01:36 CEST] <BBB> Im linking to x264, libvpx and vmaf, but none of them seem to require that [17:02:24 CEST] <ubitux> what's your diff? [17:02:44 CEST] <ubitux> coregraphics is triggered by avoundation_indev [17:03:34 CEST] <BBB> avfoundation is disabled though [17:03:58 CEST] <BBB> https://pastebin.com/MiXhcbnf [17:04:46 CEST] <ubitux> you have no check for avfoundation, so it's assumed to be enabled by default [17:04:55 CEST] <ubitux> so avfoundation_indev deps are satisfied [17:05:00 CEST] <ubitux> so it checks for coregraphics [17:05:02 CEST] <ubitux> (wild guess) [17:05:16 CEST] <BBB> hm... [17:05:50 CEST] <BBB> isnt avfoundation_indev_deps="pthreads avfoundation" enough? [17:06:00 CEST] <BBB> so that if avfoundation is disabled, it disabled avfoundation_indev also? [17:06:30 CEST] <ubitux> i wonder if you shouldn't add `check_header_objcc AVFoundation/AVFoundation.h` to the existing list of all header checks [17:06:42 CEST] <ubitux> and then avfoundation_indev_deps="pthreads AVFoundation_AVFoundation_h" [17:07:01 CEST] <BBB> Im not sure I follow :-p [17:07:10 CEST] <BBB> if avfoundation_indev_deps includes avfoundation [17:07:18 CEST] <BBB> and avfoundation is in autodetect-list and so disabled [17:07:24 CEST] <BBB> doesnt that disable the indev? [17:07:34 CEST] <ubitux> mmh my idea isn't great actually [17:08:06 CEST] <ubitux> BBB: enabled avfoundation && check_header_objcc AVFoundation/AVFoundation.h || disable avfoundation [17:08:09 CEST] <ubitux> i guess? [17:09:04 CEST] <kurosu> I would be interested academically to see a high level representation of what the vp9 frame+tile threading looks like [17:09:17 CEST] <kurosu> I expect no new threading api ? [17:09:51 CEST] <kurosu> openhevc's wpp+frame threading introduced a new -thread_type frameslice for that [17:12:14 CEST] <BBB> kurosu: is not interesting for decoders, honestly [17:12:30 CEST] <BBB> kurosu: for vp9, for 4k content, frame threading or tile threading only, I can easily get to a few 100 frames/sec [17:12:36 CEST] <BBB> kurosu: do we really need 10k fps? [17:12:56 CEST] <BBB> kurosu: for encoders its different [17:13:11 CEST] <BBB> kurosu: but I feel were solving a problem that isnt really one, for decoders at least [17:13:35 CEST] <kurosu> isn't it the decoder this threading/patchset applies to ? [17:13:52 CEST] <BBB> ubitux: still there [17:14:02 CEST] <BBB> kurosu: yes, but its either slice or frame, not both [17:14:09 CEST] <kurosu> iirc, slice+frame was done to cope with very low latency and intra frame causing extra delays [17:14:11 CEST] <BBB> which one you choose depends on latency requirements [17:14:31 CEST] <ubitux> BBB: you need to figure out the actual dep tree [17:14:36 CEST] <BBB> ok [17:14:59 CEST] <ubitux> i'm pretty sure these -framework things should be added automatically if the check_lib so i wonder why they are explicited in the extralibs [17:15:05 CEST] <kurosu> for hevc and the 40+ Mb/s cabac streams, slice+frame would make more sense [17:15:24 CEST] <kurosu> (eg uhd bluray, 4K 10bits) [17:15:32 CEST] <BBB> kurosu: yes, probably [17:15:33 CEST] <ubitux> nevertheless, the "indev" is a core component, and it depends on various libs/frameworks which should be autodetected [17:15:44 CEST] <BBB> kurosu: but vp9 doesnt really seem to be going there& plus, theres av1 already :-p [17:15:53 CEST] <ubitux> so basically avfoundation_indev_deps should point to its actual core deps [17:16:05 CEST] <BBB> I added avfoundation to avfoundation_indev [17:16:09 CEST] <ubitux> and the core deps should be tested with enabled <thedep> &&& check <thedep> [17:16:10 CEST] <BBB> but I think Im screwing something up [17:16:35 CEST] <ubitux> (...so that they are disabled if unmet) [17:16:38 CEST] <kurosu> I'm thinking of attending vdd mostly for the av1 panels [17:16:56 CEST] <ubitux> (and make sure they are disable, because some checks do not automatically disable it, typically when the actual check doesn't match the lib) [17:16:59 CEST] <ubitux> (such as a header check) [17:17:19 CEST] <BBB> kurosu: cool, you should :) [17:17:42 CEST] <BBB> kurosu: please help me push the av1 people to make the panels not just a this is what we added yesterday, but an actual full proposed bitstream overview [17:17:48 CEST] <kurosu> I'm unsure about the realtime decoding of all that stuff on s/w though [17:17:57 CEST] <BBB> kurosu: otherwise people that missed yesterdays meeting wont get anything out of it [17:18:11 CEST] <BBB> Im more concerned about encoding speed at this point [17:18:16 CEST] <kurosu> BBB, I'm stuck between a rock and a hard place there [17:18:30 CEST] <BBB> ? [17:18:52 CEST] <kurosu> conflicting opinions and decisions I must comply to [17:19:06 CEST] <kurosu> eg, can't push one way or another the mess [17:19:19 CEST] <kurosu> people still rely on s/w decoding for some applications [17:19:44 CEST] <BBB> true [17:19:49 CEST] <BBB> I dont disagree with your concern [17:19:57 CEST] <BBB> its a good concern, and Im happy people are concerned about it [17:20:08 CEST] <BBB> but Im less itnerested in decoding only at this point, I have significant itnerest in encoding speed [17:20:19 CEST] <kurosu> yeah, that's what can be sold [17:20:23 CEST] <BBB> ubitux: yeah, the dep tree isnt being propagated [17:20:28 CEST] <BBB> enabled avfoundation_indev returns true [17:20:37 CEST] <BBB> enabled avfoundation is false [17:20:44 CEST] <BBB> and avfoudation_indev_deps contains avfoundation [17:20:46 CEST] <BBB> Im so confused [17:20:55 CEST] <BBB> kurosu: right :-p [17:21:13 CEST] <kurosu> I'm afraid this is a lost fight, though [17:21:32 CEST] <kurosu> sure you can avoid bad tradeoffs, but the whole thing is now a bad tradeoff [17:21:58 CEST] <BBB> huh? [17:22:02 CEST] <BBB> what is a bad tradeoff? [17:22:08 CEST] <kurosu> most of the gains are now coming from "let's try those upteen way of coding the same block of data" [17:22:35 CEST] <kurosu> in a particular tool, say you increase encoder complexity by N% and have gain of M% [17:23:00 CEST] <BBB> right [17:23:02 CEST] <kurosu> if for hevc/vp9, that was some value, in av1&others, that'll be likely 4-5 times [17:23:14 CEST] <BBB> theres new stuff in av1 [17:23:20 CEST] <BBB> like per-symbol adaptivity [17:23:22 CEST] <BBB> thats a good thing [17:23:23 CEST] <kurosu> you have to test a hell of a lot of stuff to get just 1% [17:23:43 CEST] <BBB> but yes, I dont like that type of complexity much [17:23:43 CEST] <BBB> anyway [17:23:48 CEST] <BBB> not my choice [17:23:50 CEST] <kurosu> that'll be 4% most often, maybe 10% for lowbitrate ? [17:23:58 CEST] <BBB> I dont work there :-p [17:24:10 CEST] <kurosu> and then, what about decoding complexity, that's like cabac [17:24:19 CEST] <kurosu> I don't either ;-) [17:24:30 CEST] <BBB> decoding complexity is up by a lot [17:24:40 CEST] <BBB> but encoding complexity is only up by the same amount, not exponentially [17:24:43 CEST] <BBB> so thats good for me ;) [17:25:02 CEST] <kurosu> for reference s/w, h266 inter is 10x h265 [17:25:25 CEST] <kurosu> intra is 30x, but there's a lot of "less than ideal stuff" in there [17:25:54 CEST] <JEEB> hmm, I only quickly talked with some NHK people about the new MPEG format [17:25:59 CEST] <BBB> before we talk h266, can we first get some serious user for h265? :-p [17:25:59 CEST] <JEEB> didn't look into it more [17:26:11 CEST] <BBB> nobody wants h265, so I dont see why anyone would want h266 [17:26:16 CEST] <BBB> brb [17:26:41 CEST] <kurosu> BBB: you mean like broadcast in EU/US/JPN, UHD alliance and netflix ? ;) [17:27:19 CEST] <BBB> like I said, not much ;) [17:27:23 CEST] <BBB> anyway [17:27:33 CEST] <BBB> the issue for h265 is licensing, not tech [17:27:37 CEST] <BBB> so let them fix the licensing [17:27:42 CEST] <BBB> gonna take kids to zoo [17:27:43 CEST] <BBB> bbl [17:27:49 CEST] <atomnuker> kurosu: those pyrrhic proposals mostly come from google who have ran out of ideas on how to fix scalar quantization [17:27:52 CEST] <atomnuker> (you can't) [17:27:55 CEST] <BBB> ubitux: if you have more ideas, let me know, I dont understand, but the dep tree doesnt work for me :( [17:28:07 CEST] <nevcairiel> as long as people want to make money, the companies that hold those patents arent going to want to make less money =p [17:28:15 CEST] <atomnuker> if only we kept working on pvq [17:29:21 CEST] <atomnuker> some people seem to want to make av1 a franchise like vp9 rather than a hit like h264 was [17:29:31 CEST] <atomnuker> or at least it seeems that way [17:29:39 CEST] <ubitux> BBB: yeah i don't know, especially since i can't really test it [17:30:41 CEST] <kurosu> the termination clause of aom is another licensing issue for av1 [17:31:12 CEST] <jamrial> kurosu: i thought netflix was vp9 for desktop (using BBB's encoder at that), and h264 for mobile/smarttv/assorted devices [17:31:18 CEST] <kurosu> in the end, it's bigco against bigco - the way they compete can take a lot of shapes [17:31:31 CEST] <kurosu> jamrial, iirc, no, for 4K and HDR [17:31:54 CEST] <kurosu> vp9 is afaik only the lowrate lowres downloadable option - but BBB might correct this :) [17:32:49 CEST] <kurosu> cf. their requirement for av1: 20% better than hevc (not vp9) [17:32:53 CEST] <atomnuker> kurosu: its definitely not bigco vs bigco [17:33:10 CEST] <atomnuker> oh that, no, its not like that either [17:33:21 CEST] <atomnuker> its against vp9, not h264 [17:33:25 CEST] <atomnuker> or hevc [17:33:43 CEST] <kurosu> ok, that's the only information that's kind of public as of a target [17:34:17 CEST] <atomnuker> sadly vp9 was very heavily psnr optimized [17:34:34 CEST] <kurosu> av1 was Q1 2017 at first, and that set off some decision planning in some places [17:34:37 CEST] <nevcairiel> psnr makes for good scientific papers :p [17:34:48 CEST] <nevcairiel> just not for good videos [17:35:59 CEST] <kurosu> anyway, like BBB said, it's not about tech at this point (they are comparable) [17:36:15 CEST] <atomnuker> wut? its all about tech [17:36:19 CEST] <atomnuker> and reasearch [17:36:47 CEST] <kurosu> I'm talking about vp9 vs hevc, in the scope of comparing to av1 and set a target [17:37:06 CEST] <kurosu> whatever the basis, it must be 20-30% to make sense and care [17:38:33 CEST] <atomnuker> no, aiming for something higher that than [17:39:11 CEST] <atomnuker> and you know what, we reached 30% gain compared to then-current av1 at one point with pvq on psnr-hvs [17:39:24 CEST] <atomnuker> 20% regression on psnr too :/ [17:39:38 CEST] <kurosu> and there are expectations for 2017? or will av1 be delayed ? [17:39:59 CEST] <kurosu> pvq won't be in av1, right ? [17:41:01 CEST] <atomnuker> very sadly and disappointingly no, you can't stick slides in people's faces and scream: "THIS IS BETTER, STOP THINKING OF PSNR" [17:41:35 CEST] <atomnuker> it could have tbh, but some people didn't want to risk [17:44:04 CEST] <atomnuker> safe choices suck and when pvq makes it in some codec and its awesome I'll not be keeping quiet about how I was right [17:46:16 CEST] <kierank> atomnuker: SAD! [17:46:28 CEST] <kurosu> I came recently across the Chinese SVAC video+audio standard: iirc, vp9 inter coding/loop filtering/entropy coding and hevc intra coding/SAO [17:46:58 CEST] <kurosu> if unholy frankenstein creature had an implementation in video coding, that'd be it [17:47:51 CEST] <JEEB> sounds like a nice smörgåsbord of features [18:23:13 CEST] <BtbN> An encoder only implementing the new api would break users of the old API? [18:23:22 CEST] <BtbN> So I need to emulate the old API as well [18:23:55 CEST] <nevcairiel> or you just say screw it =p [18:24:01 CEST] <nevcairiel> (or them) [18:24:17 CEST] <atomnuker> BtbN: I still don't know how an encoder may break any of the either old or new api [18:24:24 CEST] <atomnuker> nothing has changed internally [18:24:49 CEST] <BtbN> There is a wrapper that translate from new to old API. But not the other way around [18:24:50 CEST] <atomnuker> you still always get frames and you still sometimes give packets [18:25:08 CEST] <BtbN> you don't always get frames [18:25:20 CEST] <atomnuker> well, except when you flush at the end [18:25:37 CEST] <BtbN> It can return EAGAIN at any time, to tell you to give it more input before it can output a new frame [18:25:54 CEST] <atomnuker> you mean a packet? [18:26:04 CEST] <nevcairiel> atomnuker: the "breakage" would be if you want to output multiple packets from one input frame, which the old API cannot do [18:26:22 CEST] <atomnuker> why would you want to do that? how could you even do that? [18:26:25 CEST] <nevcairiel> ie. two packets with one field each for interlaced [18:26:41 CEST] <nevcairiel> h264 paff works like that [18:27:43 CEST] <atomnuker> you get a single pointer to an avpkt in the function arguments and a single *got_packet pointer to signal you've got output [18:27:50 CEST] <nevcairiel> thats the old api [18:27:52 CEST] <BtbN> That's the old api [18:27:59 CEST] <jamrial> BtbN: you could try to do with encoders what 061a0c14bb5 did to decoders [18:28:42 CEST] <BtbN> jamrial, that commit still confuses me [18:28:50 CEST] <BtbN> the previous state seemes more intuitive to me [18:28:53 CEST] <nevcairiel> you can't fix the fundamental conflict that m:n output is not possible with the old public api though [18:29:24 CEST] <atomnuker> nevcairiel: there's one encode2 entry in the avcodec struct [18:29:30 CEST] <jamrial> it turned the old public api into a wrapper for the new one, rather than the other way around [18:29:39 CEST] <atomnuker> there's no new avcodec api [18:29:51 CEST] <nevcairiel> atomnuker: of course there is, its send_frame and receive_packet [18:29:54 CEST] <BtbN> nevcairiel, yeah, interlaced encoding just would not work with the old API. I'm fine with that. [18:29:55 CEST] <jamrial> you don't need to change the internal api for encoders like that commit did [18:31:21 CEST] <jamrial> just turn the old public api into a wrapper for the new. that way you can write new encoders using the new api without breaking users of the old, supposedly [18:33:36 CEST] <atomnuker> meh, I guess you could use the new api to accept variable frame sizes in audio encoders and do a fifo internally [18:35:20 CEST] <nevcairiel> with its m:n nature, certainly [18:35:34 CEST] <BtbN> jamrial, that actually sounds like a good idea [18:36:01 CEST] <BtbN> The change of the internal API that commit did seemed extremely weird to me, and I still haven't understood the argument behind it [18:36:42 CEST] <BtbN> the decoder actively pulling in packets is just unusual [18:36:48 CEST] <BtbN> when being asked for output [19:06:09 CEST] <BtbN> Converting nvenc to the new API is actually straight forward. Split the encode function in the middle, and you have the two functions almost done already. [19:48:54 CEST] <BtbN> So, can I use C99 (namely, dynamic array on stack) now? [19:49:17 CEST] <philipl> msvc doesn't and will never support it [19:49:31 CEST] <philipl> It was downgraded to an optional part of the standard in c11 (was it 11?) [19:51:54 CEST] <jamrial> BtbN: vla? no, that's disabled with a compiler option, even [19:53:27 CEST] <BtbN> Basically just uint32_t array[some_variable]; [19:54:25 CEST] <jamrial> yeah, you can't do that :p [19:54:36 CEST] <jamrial> use av_malloc/realloc [19:56:37 CEST] <BtbN> "Array size must be equal to size of frame in MBs." what do they even mean by that? [19:56:49 CEST] <BtbN> width * height / (8 * 8)? [20:12:43 CEST] <BtbN> Well that is handy. nvenc can tell you the offset to each of the two slices [20:12:57 CEST] <BtbN> That makes this a whole lot less insane [20:29:57 CEST] <BtbN> Great. The API for reporting slice offsets seems broken [20:30:10 CEST] <BtbN> All offsets are 0. Even though it reports the slice count to be 2 [20:32:55 CEST] <BtbN> It works if I artificially split stuff into multiple slices. But only for the first 4. [20:33:19 CEST] <BtbN> Like, it reports 8 slices. But only the first 4 offset fields are populated. [20:46:44 CEST] <atomnuker> ubitux: neat, would be interesting to see the overhead the perf api has on x86 [20:48:46 CEST] <atomnuker> ubitux: though I think you should be using PERF_COUNT_HW_REF_CPU_CYCLES [20:49:00 CEST] <atomnuker> that one isn't affected by frequency scaling according to the docs [21:02:13 CEST] <BtbN> Just e-mailed all the nvidia dudes about what I think is a driver bug. [21:02:24 CEST] <BtbN> no idea who of them is responsible. [21:39:01 CEST] <philipl> BtbN: What are you trying to do with nvenc? [21:39:13 CEST] <BtbN> interlaced encoding [21:39:23 CEST] <philipl> I thought it mostly worked already [21:39:33 CEST] <BtbN> It works great, but nvenc does field mode encoding [21:39:42 CEST] <BtbN> so for each input frame, it outputs two pictures, so 2 slices [21:40:28 CEST] <BtbN> And each picture needs to go into its own package with its own proper timestamp. Or most players will play it at half framerate, as the two field pictures have the identical timestamp [21:40:52 CEST] <philipl> ah. hence, why you were looking at using m:n api for encoding [21:41:13 CEST] <BtbN> In theory there even is an API in nvenc to get the offset to the second slice [21:41:15 CEST] <BtbN> but it's broken [21:41:18 CEST] <philipl> Hmm. [21:41:20 CEST] <BtbN> seems like nobody used it before [21:41:31 CEST] <philipl> And so that trac ticket 6633 showing up right now is completely a coincidence? [21:41:57 CEST] <BtbN> No, he just decided to open it. We have been trying to figure out what's broken for the last couple days [21:41:57 CEST] <philipl> Considering how bad their documentation is, I suspect most of their features have never been used before. [21:42:08 CEST] <BtbN> The documentation on this is pretty good and clear [21:42:12 CEST] <BtbN> It just doesn't work [21:42:16 CEST] <philipl> heh [21:42:21 CEST] <BtbN> the Lock Bitstream Parameters can report the slice count and can fill an array with the slice offsets [21:42:33 CEST] <BtbN> It correctly reports 2 instead of 1 slices when doing interlaced encoding [21:42:39 CEST] <BtbN> but does not actually put anything into the array [21:43:00 CEST] <nevcairiel> maybe you need to allocate it for it to fill? some apis are like that [21:43:12 CEST] <BtbN> yes, the array needs to be allocated by ffmpeg [21:43:18 CEST] <BtbN> It is decently sized [21:47:27 CEST] <durandal_170> atomnuker: i resolved doing bigger array size so i do not need fftshift, dunno how to do MxN otherwise [21:47:57 CEST] <nevcairiel> even if it never works, h264 bitstream is pretty easy to split into seaprate NALs yourself [21:48:01 CEST] <nevcairiel> we even have code for that [21:49:12 CEST] <BtbN> As in, code I'd need to copy, or an API somewhere? [21:49:19 CEST] <nevcairiel> an api [21:49:28 CEST] <BtbN> I suppose I only need to search for the startcode [21:49:33 CEST] <BtbN> Which is pretty easy [21:49:37 CEST] <jya> BBB: can a VP8 have alpha channels? [21:49:53 CEST] <JEEB> VPx had some weird separate alpha thing [21:49:54 CEST] <BtbN> And then look at the byte right after it, to figure out if it's a slice [21:50:28 CEST] <nevcairiel> jya: not as part of the video stream, its kept separately [21:50:57 CEST] <jya> this video has an alpha element 0x53c0 http://rebbephoto.com/test/ffwebm/3.5.01763.webm [21:50:58 CEST] <BtbN> nevcairiel, which API is it? And where is it? [21:51:01 CEST] <jya> it's vp8 codec [21:51:07 CEST] <jya> libvpx chokes on it [21:51:30 CEST] <nevcairiel> BtbN: h2645_parse.h, it can split it into separate NALs and you can then re-assemble them into two packets [21:51:41 CEST] <jya> nevcairiel: yes, I know you decode the two stream separately... [21:52:05 CEST] <BtbN> nevcairiel, ah, neat. It reads like it can do it for both avc and hevc [21:52:14 CEST] <nevcairiel> yeah that syntax is pretty much the same in both [21:52:17 CEST] <nevcairiel> hence its shared code [21:52:31 CEST] <nevcairiel> jya: that sounds like a webm feature more so then vp8 [21:52:54 CEST] <BtbN> I guess I just have to find all Slice-NALs, and then split right after the last one of the first half [21:53:02 CEST] <nevcairiel> there is like a handful of different ways to store alpha in webm, sadly [21:53:40 CEST] <jya> nevcairiel: currently, we look for a 0x53c0 element. [21:54:45 CEST] <nevcairiel> thats the AlphaMode property in mkv syntax [22:08:51 CEST] <wm4> AFAIK that works for both vp8 and vp9 [22:09:03 CEST] <wm4> libavcodec supports it only with the libvpx wrappers [22:09:08 CEST] <wm4> we discussed this before [22:13:41 CEST] <jamrial> vp8/9 alpha decoding with the native decoders is a listed gsoc 2017 project, but no idea if anyone took it [22:26:18 CEST] <jamrial> jya: the libvpx wrapper looks at the matroska blockaditionals passed as packet side data, which contain the alpha channel. it doesn't care about the stream metadata entry created by the presence of a 0x53c0 element [22:27:08 CEST] <jamrial> if you're not using libavformat's matroska demuxer, you might want to make sure your demuxer handles those [22:29:40 CEST] <BtbN> nevcairiel, can I somehow just get an offset into the buffer for the NAL? I suppose I can just do "nal.raw_data - 4 - original_buffer"? [22:29:51 CEST] <BtbN> Or is it not always 4 bytes? [22:30:18 CEST] <JEEB> it can be 3 bytes [22:30:29 CEST] <JEEB> under specific circuimstances [22:30:41 CEST] <BtbN> I guess it's safe to assume that nvenc will always output 4 [22:31:44 CEST] <jamrial> BtbN: you could expand H2645NAL to also store the offset, i guess [22:32:06 CEST] <BtbN> raw_data is just an incremented input pointer [22:33:15 CEST] <nevcairiel> its a bit wasteful to use these functions honestly because it'll also unescape the buffers for you, but its easier then re-implementing startcode searches, i guess [22:38:08 CEST] <BtbN> I'd prefer if nvidia just fixes their driver [22:38:21 CEST] <BtbN> Will wait for a replay for a few days [22:38:54 CEST] <BtbN> Or I'll just write a generic get-offset function. Which can either be trivially filled with the official offset, or do the parsing. [22:41:21 CEST] <jamrial> BtbN: instead of keeping the old encode2() implementation of nvenc, remove it so downstream users are forced to migrate to the new api in their code :p [22:41:38 CEST] <BtbN> that would break API [22:42:16 CEST] <jamrial> it would make nvenc stop working with avcodec_encode_video2(), yeah, that's the idea :p [22:42:37 CEST] <BtbN> That needs the normal deprecation period [22:42:50 CEST] <jya> jamrial: there's alpha data there, one with non zero side. [22:43:07 CEST] <atomnuker> could we handle encoders/decoders which do not support the old api in utils.c? [22:43:18 CEST] <BtbN> for decoders we already do [22:43:20 CEST] <jamrial> BtbN: technically speaking, the deprecation period is ongoing ever since avcodec_encode_video2 was deprecated [22:43:38 CEST] <jamrial> but i guess yeah, making nvenc stop working with it is kinda a dick move [22:43:41 CEST] <jya> We only found the stuff found in the meta data to determine e which decoder to use, as currently we've only made the alpha stuff work with the libvpx decoder, not ffvp9/8 [22:43:49 CEST] <philipl> Drop the old api as part of the next break. :-) [22:44:11 CEST] <jamrial> philipl: once it's two years old and every decoder/encoder has been migrated, sure [22:44:41 CEST] <jamrial> bah, i guess there's no need to migrate anything out of encode2 since that's internal [22:44:54 CEST] <philipl> We have two decoders and no encoders migrated right now, right? [22:44:55 CEST] <BtbN> Making up the timestamps for those two fields will also be fun [22:45:51 CEST] <BtbN> I guess just setting the second field to NOPTS won't work [22:46:11 CEST] <BtbN> Also, the timebase might not allow intermediate frames [22:53:54 CEST] <ubitux> atomnuker: i sometimes observe something like a 400 decicyles overhead [22:54:00 CEST] <ubitux> seems a bit random [22:54:15 CEST] <ubitux> (that is, difference with what we have, which may be innacurate/broken for various reasons) [22:54:22 CEST] <ubitux> i didn't test PERF_COUNT_HW_REF_CPU_CYCLES [22:54:28 CEST] <ubitux> feel free to try my github branch [22:54:30 CEST] <ubitux> (named perf) [23:53:37 CEST] <cone-035> ffmpeg 03Michael Niedermayer 07master:2a0823ae966b: avcodec/diracdec: Fix integer overflow in INTRA_DC_PRED() [23:53:37 CEST] <cone-035> ffmpeg 03Michael Niedermayer 07master:f71cd44147e7: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting [23:53:37 CEST] <cone-035> ffmpeg 03Michael Niedermayer 07master:c595139f1fdb: avcodec/dirac_vlc: Fix invalid shift in ff_dirac_golomb_read_32bit() [00:00:00 CEST] --- Sun Sep 3 2017

1 0

ffmpeg.log.20170902
by burek 03 Sep '17

03 Sep '17

[00:40:45 CEST] <diverdude> hello. Can i somehow using ffmpeg simulate a video stream with a certain resolution and a certain framerate that is streamed via ethernet such that i can use that to develop a player that can play data from this stream? [00:41:44 CEST] <c_14> "via ethernet" [00:42:03 CEST] <c_14> like what, raw video slammed into an ethernet frame? [00:46:57 CEST] <c_14> the answer is probably yes btw as long as your answer to my question isn't yes [00:47:41 CEST] <diverdude> sorry didnt see your response [00:48:12 CEST] <diverdude> so yes, as a raw stream [00:48:46 CEST] <diverdude> c_14: can you maybe show me how i can simulate this? [00:49:23 CEST] <c_14> Do you mind if there's tcp/udp in the way? [00:49:57 CEST] <c_14> Even udplite would work [00:50:13 CEST] <c_14> But if you want raw tcp you'll need something to generate the TCP frame and segment the video data into that yourself [00:50:23 CEST] <c_14> s/raw tcp/raw ethernet/ [00:50:31 CEST] <c_14> s/TCP/Ethernet/ [00:50:35 CEST] <diverdude> hmmm ok good point [00:50:37 CEST] <c_14> I'm too tired for this [00:51:02 CEST] <c_14> What problem are you trying to solve with this? [00:51:16 CEST] <diverdude> i really wanted to mimic a camera. moment, will look at specs [00:51:18 CEST] <klaxa> test-source for a network player? [00:51:41 CEST] <c_14> most likely the camera is outputting via tcp/udp/rtp [00:51:45 CEST] <c_14> probably even http [00:52:02 CEST] <c_14> If you're _reeeally_ lucky, it's flash [00:52:04 CEST] <c_14> <_< [00:53:05 CEST] <klaxa> i would guess something like this should simulate it well enough? ffmpeg -f lavfi -r 30 -i testsrc -s 1280x720 -listen 1 -f matroska tcp://0:8080 [00:53:21 CEST] <diverdude> ahh sorry, actually its using USB3... ok [00:53:26 CEST] <klaxa> maybe don't use matroska but some other container that the camera uses [00:53:40 CEST] <klaxa> sounds like a case for v4l2 :x [00:53:44 CEST] <c_14> yeah [00:54:01 CEST] <diverdude> i wanted to try and mimic this camera: https://www.ptgrey.com/grasshopper3-123-mp-mono-usb3-vision-sony-pregius-im… [00:54:08 CEST] <c_14> If the camera is detected by v4l2 you can fake a v4l2 device using ffmpeg by using v4l2loop or whatever it was called [00:54:24 CEST] <klaxa> >Seite nicht gefunden [00:54:25 CEST] <klaxa> wot [00:54:50 CEST] <diverdude> ahh...its the geo stuff. Its called grasshopper3 from ptgrey.com [00:55:27 CEST] <klaxa> changing the country to the us of a worked [00:55:31 CEST] <klaxa> wew what a crappy website [00:55:42 CEST] <diverdude> yeah i agree..totally crappy website [00:56:00 CEST] <diverdude> but the cameras are at least quite good :) [00:58:12 CEST] <c_14> Oh god [00:58:27 CEST] <c_14> FlyCapture [00:58:34 CEST] <diverdude> ok, so i have to use an v412loop? Is this just a command i run? [00:58:47 CEST] <c_14> I have memories of this **** [00:58:50 CEST] <diverdude> c_14: you dont like FlyCapture? [00:58:54 CEST] <c_14> afaik it won't be detected by v4l2 [00:59:07 CEST] <c_14> I don't like it because it isn't compatible with system software [00:59:13 CEST] <c_14> It does everything on its own [00:59:49 CEST] <c_14> I mean, you can try checking if your pc detects it with v4l2 but it probably won't [01:00:17 CEST] <c_14> If it doesn't there's no real way to emulate the camera using FFmpeg [01:00:22 CEST] <c_14> not without hacking your way through FlyCap anyway [01:00:56 CEST] <diverdude> c_14: ah right....thats a good point [01:01:34 CEST] <klaxa> is v4l2 available on windows even? did we ever clear up what OS you are on even? [01:01:46 CEST] <c_14> Well [01:01:49 CEST] <c_14> if you're on windows [01:01:50 CEST] <diverdude> ok...but i think i am not really interested in emulating that acurate....i just want to emulate the stream such that i can see if i can playback the data fast enough and process the incoming data fast enough [01:01:51 CEST] <c_14> Give up now? [01:02:19 CEST] <klaxa> save up to 2 years of time loss \o/ [01:02:37 CEST] <c_14> I mean, if that's what you care about [01:02:43 CEST] <c_14> Just create a dump of the stream into a file [01:02:48 CEST] <c_14> and use that to test the decoding speed [01:03:09 CEST] <c_14> That way you don't have to worry about camera access until you know you're fast enough [01:05:06 CEST] <diverdude> i can see how what i am saying is making less and less sense....probably because i have not formulated myself very well.... i am trying to build a program that can handle a specific framerate and a specific resolution. The program grabs the "generic" videostream which for example could come from that ptgrey camera - it takes the stream and displays it on a canvas where user can press start, stop and draws on top of the canvas while [01:05:33 CEST] <diverdude> c_14: true...i dont have any camera yet though...thats why i want to simulate :) [01:06:19 CEST] <c_14> If you know the codec and resolution, ffmpeg can generate test video for you to work with [01:07:34 CEST] <diverdude> c_14: right ok....not sure about the codec actually. i think the video is just raw frames [01:07:49 CEST] <diverdude> and then i need to apply some codec to these raw frames [01:07:50 CEST] <c_14> ffmpeg can do rawvideo too [01:08:32 CEST] <diverdude> i want to do 4096 x 3000 @ 30FPS raw video grayscale video [01:09:50 CEST] <klaxa> ffmpeg -f lavfi -r 30 -i testsrc -pix_fmt gray -c rawvideo -s 4096x3000 test.mkv [01:09:58 CEST] <c_14> ffmpeg -f lavfi -i testsrc:s=4096x3000:r=30:d=60 -pix_fmt gray10le out.mkv [01:10:07 CEST] <klaxa> that might be better [01:10:16 CEST] <c_14> mostly ninjad so I didn't finish the end part [01:10:34 CEST] <klaxa> d=60 is duration 60 seconds? [01:10:39 CEST] <c_14> I picked 10bit gray, there's also 12bit and 9bit [01:10:50 CEST] <klaxa> 8 as well [01:10:51 CEST] <c_14> wtf is 9bit video [01:11:09 CEST] <c_14> Oh, there is also an 8bpp version [01:11:10 CEST] <klaxa> 3 bit per color :P [01:11:22 CEST] <klaxa> in grayscale... wait a second... [01:11:24 CEST] <c_14> Nah, it's 9bpp [01:11:48 CEST] <klaxa> because you're such a good customer we throw in a bit for free? [01:11:53 CEST] <diverdude> c_14: good point...i see ADC of this camera is 10 and 12 bit...is it normal to have a 10bit resolution of a monochrome video? [01:12:06 CEST] <c_14> Well, it's not monochrome [01:12:07 CEST] <c_14> It's grayscale [01:12:14 CEST] <klaxa> monochrome would be 1 bit [01:12:15 CEST] <diverdude> sorry, true [01:12:18 CEST] <diverdude> yes [01:12:27 CEST] <c_14> I mean [01:12:33 CEST] <c_14> There's a lot of Shades of Gray [01:12:35 CEST] <c_14> Maybe 50 [01:12:37 CEST] <c_14> Maybe more [01:12:48 CEST] <c_14> (forgive the pun) [01:12:50 CEST] <klaxa> 8 bit grayscale is really not that much [01:12:57 CEST] <diverdude> c_14: hehehehe [01:12:58 CEST] <diverdude> :D [01:13:35 CEST] <diverdude> hmm ffmpeg -f lavfi -i testsrc:s=4096x3000:r=30:d=60 -pix_fmt gray10le out.mkv --->[lavfi @ 0x7f8793000000] No such filter: 'testsrc:s' [01:13:51 CEST] <c_14> eh, testsrc= [01:13:57 CEST] <c_14> the first one is always an equals [01:14:01 CEST] <c_14> I keep messing that up [01:14:45 CEST] <diverdude> Unknown pixel format requested: gray10le. [01:15:13 CEST] <klaxa> huh, that's weird [01:15:15 CEST] <durandal_1707> only nut supports all rawvideo formats [01:17:46 CEST] <diverdude> i have ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers [01:18:38 CEST] <c_14> try out.nut instead of out.mkv [01:19:15 CEST] <diverdude> im still getting Unknown pixel format requested: gray10le. [01:19:30 CEST] <durandal_1707> what player he wants to use? [01:19:36 CEST] <klaxa> his own [01:20:06 CEST] <c_14> diverdude: Is it listed in `ffmpeg -pix_fmts' as IO? [01:22:30 CEST] <diverdude> hmm [01:22:47 CEST] <diverdude> the following gray is listed: IO... gray 1 8 IO... gray16be 1 16 IO... gray16le 1 16 [01:23:10 CEST] <c_14> And none of the other ones? [01:24:07 CEST] <diverdude> no [01:24:14 CEST] <diverdude> i did a grep on gray [01:24:20 CEST] <diverdude> on that command you gave me [01:24:26 CEST] <diverdude> and only those 3 came out [01:25:14 CEST] <diverdude> c_14: this is the total output http://paste.ubuntu.com/25447834/ [01:26:19 CEST] <c_14> 3.2 should be old enough for gray10 [01:27:03 CEST] <c_14> I mean, you can try updating to recent git master or 3.3 and checking [01:28:13 CEST] <diverdude> i will try [01:30:04 CEST] <diverdude> hmm ok upgraded to 3.3.3 and stilli get the same [01:30:19 CEST] <diverdude> Unknown pixel format requested: gray10le. [01:30:39 CEST] <diverdude> should i somehow install that filter? [01:30:46 CEST] <diverdude> i am on a mac btw [01:32:56 CEST] <c_14> There's nothing to install post-factor, it's either there or it isn't. [01:33:01 CEST] <c_14> not sure why it isn't though [01:35:00 CEST] <diverdude> could i use gray16be instead= [01:35:02 CEST] <diverdude> ? [01:35:12 CEST] <diverdude> would that create a 16bit signal? [01:35:43 CEST] <c_14> I mean, you can but then the video would be "completely" different than with 10bit content [01:36:09 CEST] <c_14> Though I guess you can abstract that away so that your program should be able to handle either [01:41:44 CEST] <diverdude> c_14: true...i guess if it can handle a 16bit video it can also handle a 10bit [01:43:21 CEST] <diverdude> what is difference btwn. gray16be and gray16le ? [01:43:31 CEST] <c_14> endianess [01:43:39 CEST] <c_14> be is big-endian, le is little-endian [01:43:57 CEST] <diverdude> ah yeah [01:43:57 CEST] <c_14> just pick your system-native one [01:43:59 CEST] <diverdude> true [01:47:14 CEST] <diverdude> c_14: so lets say i get this camera and stream video via usb, i then grab all the frames in my c++ program and do some analysis on them and forward each frame to an ffmpeg encoder which then forwards encoded frames to some videoplayer as well as to a file that will contain the entire video for later playback.... would that be a sane way to setup such a pipeline? [01:47:20 CEST] <acos> Wow this chat is finally busy. [01:47:56 CEST] <c_14> diverdude: yeah, seems sane enough [01:57:31 CEST] <diverdude> hmm when i run : ffmpeg -f lavfi -i testsrc=4096x3000:r=30:d=60 -pix_fmt gray16le out.nut i get a warning issued: Incompatible pixel format 'gray16le' for codec 'mpeg4', auto-selecting format 'yuv420p' does this mean that a color video is actually streamed? [01:58:23 CEST] <diverdude> c_14: when i run : ffmpeg -f lavfi -i testsrc=4096x3000:r=30:d=60 -pix_fmt gray16le out.nut i get a warning issued: Incompatible pixel format 'gray16le' for codec 'mpeg4', auto-selecting format 'yuv420p' does this mean that a color video is actually streamed? [01:58:29 CEST] <klaxa> diverdude: add: -c rawvideo [01:59:15 CEST] <c_14> what klaxa said [01:59:58 CEST] <diverdude> hmmm still the same: http://paste.ubuntu.com/25447957/ [02:00:15 CEST] <c_14> after the -i [02:01:23 CEST] <c_14> (and the filename, but before the output filename) [02:01:30 CEST] <c_14> options go before the "file" they modify [02:01:42 CEST] <c_14> In this case you want to set the output video codec so it goes before the output file and after the input file [02:02:03 CEST] <diverdude> ahh yeah that worked [02:04:12 CEST] <diverdude> c_14: so you mentioned earlier that flycapture was horrible because it has its own api etc etc. So am thinking that if i have to capture frames using some proprietary api and i want to encode using eg. ffmpeg, will i then not have to copy each frame into an ffmpeg buffer? memcp is pretty expensive as i know, maybe that will create problem when dealing with so large amounts of data as 12MP@30FPS ? [02:05:42 CEST] <klaxa> if you want to use the libraries, your frames will already be in memory anyway, you should be able to just pass them to ffmpeg [02:06:18 CEST] <klaxa> if you want to use the command line interface of ffmpeg, just pipe it and your OS should do the "optimizations" [02:06:35 CEST] <damata> Hi people, if ffserver is no longer update, how can i stream on http with ffmpeg ? [02:07:14 CEST] <c_14> hls or dash [02:07:35 CEST] <c_14> or you write your own program that leverages the libav* libraries [02:14:04 CEST] <damata> first i have try to set a rtp stream, but i thing my router dont support it because i cant play the stream on my smartphone... [02:17:05 CEST] <klaxa> *shamelessly self-advertising* https://github.com/klaxa/mkvserver_mk2 [02:17:19 CEST] <damata> its strange because i can listen the stream on my laptop my not on my phone... [02:17:26 CEST] <damata> can someone help me ? [02:17:34 CEST] <klaxa> takes a file and turns it into a matroska-stream [02:17:43 CEST] <klaxa> oh, audio? [02:17:47 CEST] <klaxa> maybe just use icecast? [02:18:36 CEST] <damata> last time i try icecast i end up with like 5 seconds delay, my objective is "zero" selay [02:18:52 CEST] <klaxa> ah [02:19:30 CEST] <klaxa> if you are on linux, maybe look into pulseaudio network setup? [02:19:41 CEST] <klaxa> although it's usually not really viable over wifi [02:19:59 CEST] <klaxa> i think there is a pulse client for android [02:20:36 CEST] <damata> i'am working on a project that stream the audio from tv for smartphones ! iam using Raspberry to stream the audio [02:21:27 CEST] <diverdude> any idea if there is some player i can use to watch the nut file i just created using ffmpeg on mac? [02:21:43 CEST] <klaxa> mpv [02:21:49 CEST] <damata> with ffserver i can make a http unicast stream with 2 seconds latency for phones and 0 latency for laptop... i have no ideia who to make it work better on the phones [02:22:13 CEST] <klaxa> https://github.com/dront78/PulseDroid [02:22:25 CEST] <klaxa> afaik pi's *usually* run pulse anyway [02:22:35 CEST] <acos> Phones are slower than laptops ? [02:22:56 CEST] <klaxa> huh, this is 7 years old, not sure if it still works :x [02:23:57 CEST] <damata> @acos i think so, they both are connect by wifi i dont know why i have more delay on the phone... [02:24:26 CEST] <klaxa> are you using a "normal" mediaplayer? [02:24:33 CEST] <damata> vlc [02:24:33 CEST] <klaxa> if so, it's probably buffering [02:24:53 CEST] <damata> i set the internet buffers to 0, in my laptop and phone too [02:25:37 CEST] <klaxa> i wrote some android stuff that used udp to just push raw pcm frames, that was pretty much real-time but it suffered stuttering [02:25:43 CEST] <klaxa> but you can't fix that because it's wifi [02:37:52 CEST] <diverdude> does ffmpeg libraries support video overlay? Basically drawing on top of a video being played back [03:33:42 CEST] <damata> ffmpeg -f alsa -ac 1 -ar 44100 -i hw:1,0 -acodec mp2 -ab 32k -ac 1 -f rtp rtp://234.5.5.5:1234 , there is something wrong with this comand ? [03:56:20 CEST] <atomnuker> yes, 32k mpeg2 audio will sound like crap [04:01:12 CEST] <acos> LOL what a bit rate [04:20:18 CEST] <damata> ok but the rtp is correct ? i cant play this on my phone, he open the stream but dont play it [04:23:57 CEST] <furq> does your phone play mpeg4 [04:24:02 CEST] <furq> you probably want -c:v libx264 [04:24:26 CEST] <damata> iam uisng vlc on my phone [04:27:05 CEST] <damata> i try ffmpeg -f alsa -ac 1 -ar 44100 -i hw:1,0 -c:v libx264 -ab 32k -ac 1 -f rtp rtp://234.5.5.5:1234 but still no sound on my phone [05:08:39 CEST] <furq> damata: -c:a aac [05:13:59 CEST] <damata> c:i can open the stream om my pc using sdp file but no in my phone [08:48:19 CEST] <diverdude> Should I expect to be able to encode 12.3MP@30FPS in realtime? [08:50:22 CEST] <c3-Win> What codec? What 'quality' setting for said codec? How much encoding power do you have relative to the codec? [09:01:47 CEST] <alexpigment> BtbN: are you around yet? [09:01:59 CEST] <alexpigment> I got caught up with a call at work yesterday [09:02:31 CEST] <alexpigment> Anyway, hopefully you can see the problem when remuxing NVENC into MP4 and ffprobe showing the frame rate as 60000/1001 [09:03:55 CEST] <alexpigment> I'm going to do a comparison in staxrip tomorrow and make sure it's correct (which it was last time I checked). I know that this seems like a player-specific issue, but I think it's an issue with FFMPEG's NVENC interlace implementation that causes some players to view it as 59.94 instead of 29.97 [09:04:34 CEST] <alexpigment> so far WMP and VLC on my end are problematic and MediaInfo shows it as 59.94 [09:04:44 CEST] <alexpigment> Kodi plays it correctly [09:05:07 CEST] <alexpigment> x264 is fine in all players as well as MediaInfo [09:09:22 CEST] <acos> Y'all seen this ? https://youtu.be/vbydG78Al8s [09:12:38 CEST] <diverdude> c3-Win: hmm coding power means how much its being compressed? [09:18:21 CEST] <diverdude> acos: i wonder how long it took to create DarkLabel ? [09:18:36 CEST] <acos> It seems so cool [09:18:46 CEST] <acos> It's not my software but still. It's Korean [09:19:25 CEST] <diverdude> acos: yeah, i want to create something like it [09:19:54 CEST] <acos> Good luck diverdude [09:20:26 CEST] <diverdude> acos: you wanna help me? :) We can make it as open source project [09:21:13 CEST] <acos> Ya would be fun [09:23:58 CEST] <diverdude> acos: i think so too. I am thinking we could utilize qt5 as GUI [09:24:44 CEST] <diverdude> acos: how much experience do you have with ffmpeg? [09:31:50 CEST] <acos> Not much at all sadly. [09:31:59 CEST] <acos> Whenever I try to use it I get errors. [09:44:49 CEST] <mozzarella> I chuckled [09:44:59 CEST] <mozzarella> you made me chuckle [09:46:15 CEST] <diverdude> mozzarella: me? [09:46:26 CEST] <mozzarella> no, acos [09:46:36 CEST] <acos> Yayyyyy ty mozzarella [10:03:52 CEST] <mozzarella> acos: which OS are you using? is it archlinux? [10:04:52 CEST] <acos> Windows 7x64 and 8.1x64 or centos or Ubuntu if needed [11:33:41 CEST] <BtbN> alexpigment, like I said, I can put complete garbage in the framerate field, and nothing changes. [11:33:47 CEST] <BtbN> So it's _not_ the framerate. [11:49:26 CEST] <BtbN> alexpigment, also, if you're muxing to anything but .ts, you are likely hit by some bug in ffmpeg.c [12:10:42 CEST] <alexpigment> Btbn: yeah the ts files from ffmpeg also are reported as 59.94 when encoded via NVENC [12:11:02 CEST] <alexpigment> anyway, there's a bug here. when I get some time to look into it tomorrow, I'll log it up in trac [12:12:08 CEST] <BtbN> "There is some bug here somewhere" won't be a very useful report [12:12:25 CEST] <BtbN> There's a good chance it's just broken players [12:12:26 CEST] <alexpigment> BtbN: a bug that affects certain players is still a bug [12:12:57 CEST] <alexpigment> if you don't realize that, then you haven't been a developer for very long [12:12:58 CEST] <BtbN> Your best bet is to report it to nvidia [12:13:08 CEST] <alexpigment> It doesn't affect NVENC from Staxrip [12:13:17 CEST] <BtbN> They might be fixing it in post-processing [12:13:22 CEST] <alexpigment> They might be [12:13:31 CEST] <BtbN> Did you ask them? [12:13:36 CEST] <alexpigment> So they probably *fixed a bug* [12:13:38 CEST] <alexpigment> No [12:13:51 CEST] <BtbN> I will _not_ introduce bitstream postprocessing to fix driver bugs [12:14:00 CEST] <BtbN> If it turns out to be the case, it's nvidias bug [12:14:19 CEST] <alexpigment> You may be right. I just know that ffmpeg is the only place I'm seeing this problem [12:15:14 CEST] <alexpigment> Anyway, I'm not doing work-work tomorrow, so I'll probably have more time to look into it and log my findings on trac [12:28:08 CEST] <BtbN> The only other idea I had was forcing it to write the VFR flag into the stream. [12:28:11 CEST] <BtbN> Did nothing as well [12:28:31 CEST] <BtbN> This is most definitely not something affecting nvenc, but something with the ffmpeg muxers. [13:32:07 CEST] <BtbN> alexpigment, can I have a file converted with staxrip nvenc? [13:32:18 CEST] <BtbN> It is using some _very_ weird chinese software to do the conversion. [13:33:06 CEST] <BtbN> Namely, this thing: https://github.com/rigaya/NVEnc [13:36:11 CEST] <BtbN> My current observation is that nvenc mangles the framerate I pass to it. The framerate passed to its API is 2997/100, which is correct. The correct framerate to write to the VUI would be 5994/100. But it writes 60000/1001 instead. Which is close, but not quite it. [13:50:43 CEST] <kepstin> huh, i wonder if there's some hardcoded fixup. because 60000/1001 is the correct field rate for interlaced ntsc [13:50:46 CEST] <grublet> BtbN: it's accurate to 1 millionth [13:51:01 CEST] <grublet> and that error is most likely just accounting for rounding [13:51:26 CEST] <BtbN> The original and a x264 encoded file have the SPS VUI timinig info set to 5994/100 [13:51:33 CEST] <BtbN> The nvenc one has 60000/1001. [13:51:45 CEST] <BtbN> The original and x264 one play smooth in WMP, and nvenc one stutters [13:51:53 CEST] <grublet> those are effectively identical ratios [13:51:53 CEST] <BtbN> And that framerate is the only difference I can possibly find [13:51:58 CEST] <grublet> no clue why it stutters [13:52:27 CEST] <grublet> im not familiar with nvenc so someone else will have to help on this [13:55:41 CEST] <hendry> this: ffmpeg -y -i canon.mkv -movflags +faststart -pix_fmt yuv420p -c:v libx264 -acodec aac 2017-09-02/canon.mp4 # seems to take quite long on my machine... can it made faster? i.e. less compressing work ? [13:56:26 CEST] <c_14> use a faster preset [13:56:30 CEST] <BtbN> do you even need to re-encode it? [13:56:36 CEST] <BtbN> Or do you just want to move the moov atom? [13:56:51 CEST] <BtbN> Or remux it, rather [13:59:30 CEST] <hendry> BtbN: FCPX 10.3 doesn't seem to grok .mkv [13:59:45 CEST] <hendry> BtbN: just want to get this .mkv as quickly as possible into FCPX [14:00:57 CEST] <BtbN> so remux it to mp4, without re-encoding [14:09:07 CEST] <kepstin> hendry: just give this a try: ffmpeg -i canon.mkv -c copy -movflags +faststart canon.mp4 [14:09:26 CEST] <kepstin> if it works, great, if not, there's some options to speed up the encoder [14:17:08 CEST] <damata_> can some one tell me why my ffserver only accepts 3 or less clients. when i connect the 4 client the server output error 503 , this is my ffserver config :https://pastebin.com/LTNLYNEB [14:21:57 CEST] <kepstin> damata_: ffserver isn't really supported, and so there probably isn't anyone who can tell you what's gone wrong. [14:35:36 CEST] <hendry> kepstin: Could not find tag for codec pcm_s16le in stream #1, codec not currently supported in container [14:35:39 CEST] <hendry> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [14:36:04 CEST] <hendry> BtbN: thought my initial line was effecting remuxing [14:46:04 CEST] <kepstin> hendry: looks like you'll want to encode the audio, yeah, but you might not need to re-encode the video [14:46:22 CEST] <kepstin> could try -c:v copy -c:a aac [14:52:37 CEST] <damata_> is there something easy to install to replace ffserver ? [14:53:43 CEST] <klaxa> people usually recommend using hls or rtmp with nginx-rtmp [14:58:05 CEST] <c_14> there's also dash these days [15:45:26 CEST] <BtbN> alexpigment, another difference I found is that nvenc does not by default output a picture timing SEI. Which contains information about the picture struct (TOP_FIELD, BOTTOM_FIELD, TOP_BOTTOM, BOTTOM_TOP, and so on) [15:45:49 CEST] <BtbN> It seems bad/wrong to not output that for interlaced encodes, I'll push a patch soon to enable it [16:29:06 CEST] <BtbN> alexpigment, I found the problem. [16:29:11 CEST] <BtbN> And it seems impossible to fix. [16:29:32 CEST] <BtbN> You can workaround it though. [16:29:50 CEST] <BtbN> Output to a raw .h264 file with ffmpeg nvenc, and then remux that to your final container. [16:29:59 CEST] <BtbN> That way it generates proper timestamps [16:30:42 CEST] <BtbN> nvenc emits two output "frames" per input frame in interlaced encoding mode. But outputs them in a single packet. And timestamps in ffmpeg are per packet. [16:30:52 CEST] <BtbN> So the two fields share a timestamp, which explains the 30 FPS effect [16:37:28 CEST] <BtbN> StaxRip avoids the problem because it calls an external binary for the nvenc, which outputs raw avc. And then splits that avc itself. [16:38:00 CEST] <BtbN> I have absolutely no idea how to fix this in ffmpeg. Might be plain not possible. [16:38:15 CEST] <acos> Ooooo [16:39:38 CEST] <kepstin> well, one way to "fix" it would be to have the ffmpeg nvenc wrapper parse the packets it gets back and split/repacketize them. But that would be pretty messy :/ [16:39:56 CEST] <BtbN> it can't [16:40:11 CEST] <BtbN> That would mean outputting two packets at once [16:40:20 CEST] <BtbN> Which isn't possible [16:40:35 CEST] <JEEB> so you get a single buffer with N>1 video packets? [16:40:43 CEST] <JEEB> as in, NAL units [16:40:48 CEST] <BtbN> in interlaced encoding mode, yes [16:40:51 CEST] <JEEB> yikes [16:40:58 CEST] <BtbN> nvenc does field mode encoding [16:41:01 CEST] <BtbN> one "frame" per field [16:41:07 CEST] <JEEB> picture, but yes [16:41:15 CEST] <BtbN> so each field needs its own timestamp [16:41:15 CEST] <kepstin> hmm, I thought that the newer encoder api in ffmpeg supported different input vs output frames [16:41:17 CEST] <JEEB> that's why all the specs use the word "picture" [16:41:27 CEST] <BtbN> nvenc is using the old API [16:41:29 CEST] <JEEB> kepstin: yea but in this case you'd have to have a parser [16:41:35 CEST] <BtbN> And migrating it would be quite a task [16:41:47 CEST] <JEEB> because you've got N>1 NAL units in a single buffer [16:41:53 CEST] <BtbN> And would then still leave you with a mess of h264 and hevc parsing to do the splitting [16:41:55 CEST] <JEEB> and yes, migration to new APIs is "fun" [16:42:04 CEST] <JEEB> I wonder if you could stick the h264 parser [16:42:05 CEST] <JEEB> there [16:42:08 CEST] <kepstin> JEEB: well, ffmpeg already has a parser, the api migration is the hardest part :/ [16:42:08 CEST] <JEEB> or something [16:42:19 CEST] <JEEB> kepstin: yes, or sticking the parser there *after* the decoder [16:42:32 CEST] <JEEB> uhh [16:42:33 CEST] <BtbN> The parser would then have to make up timestamps [16:42:33 CEST] <JEEB> encoder I mean [16:42:53 CEST] <BtbN> I don't think ffmpeg supports putting a bsf after the encoder [16:43:02 CEST] <kepstin> would be in the encoder, not after the encoder, i think [16:43:12 CEST] <BtbN> Then you still have the same problem [16:43:13 CEST] <JEEB> yes, that's the other alternative [16:43:22 CEST] <JEEB> but as noted, same kind of issue more or less :3 [16:52:31 CEST] <kepstin> hmm, on a only tangentially related note, I kinda want to rewrite the fps filter using the request_frame() api so it doesn't buffer millions of frames to fill in large timestamp gaps. [16:55:26 CEST] <kepstin> hmm, well, I really don't know how to make that work :/ [16:56:25 CEST] <JEEB> probably durandal_1707 can help you? [16:58:01 CEST] <durandal_1707> kepstin: activate instead [16:59:48 CEST] <kepstin> ah, that's what I looking for. No wonder I got confused. [17:02:29 CEST] <kepstin> hmm, my checkout was out of date, there are actually a few filters using the activate callback now. I guess vf_blend might work as a reference [17:04:36 CEST] <kepstin> oh, hmm, that uses framesync and has multiple inputs, a bit more complex than fps [17:04:54 CEST] <durandal_1707> kepstin: no, vf zoompan is best example [17:07:17 CEST] <BtbN> I think I'll migrate nvenc to the new API [17:07:32 CEST] <BtbN> And when that is done, try to do some crazy bitstream processing [17:07:47 CEST] <BtbN> Shouldn't really be too hard. Just look for 0x000001 [17:16:29 CEST] <kepstin> durandal_1707: thanks. This doesn't actually look like it'll be that hard. Who knows if I actually produce anything useful this weekend, tho :) [17:16:34 CEST] <ZexaronS> Hello [17:17:36 CEST] <ZexaronS> I'm trying to do a batch script to remove some parts of a file, output extracts and then reconcat the extracted part, if something like that is out there already ? [17:20:28 CEST] <JEEB> BtbN: if nvenc always outputs like that then sure, it should work [17:55:39 CEST] <BtbN> JEEB, it's always {SEI, SEI, SEI, ...} n x SLICE [18:43:55 CEST] <alexpigment> BtbN: Man, I just woke up - great news to hear :) [18:44:10 CEST] <BtbN> Well, this is not going to be fixed soon. If at all [18:44:30 CEST] <alexpigment> I kinda thought you were of the mindset that this was an Nvidia issue and you weren't going to look into it further [18:44:47 CEST] <BtbN> It kind of is an nvidia issue. In that their API is weird [18:44:54 CEST] <BtbN> It gives no way to properly handle this [18:45:02 CEST] <BtbN> As it just throws two output pictures in one packet at you [18:45:03 CEST] <alexpigment> Well, at any rate, there's hope that it might get fixed at some point I suppose [18:45:25 CEST] <BtbN> The current FFMpeg API nvenc uses makes it impossible to fix it [18:46:18 CEST] <alexpigment> You said that migrating to the new API "shouldn't be that hard". Are there any other roadblocks? [18:46:26 CEST] <alexpigment> (Aside from your time, of course) [18:46:31 CEST] <BtbN> Someone needs to do that [18:46:34 CEST] <BtbN> it's still quite a task [18:46:37 CEST] <alexpigment> Gotcha [18:46:52 CEST] <BtbN> And even if that's done, you need to parse the h264 and hevc bitstream [18:46:54 CEST] <BtbN> and split it apart [18:47:00 CEST] <BtbN> and make up intermediate timestamps [18:47:13 CEST] <alexpigment> right [18:47:40 CEST] <alexpigment> Is there anything that can be learned from the players that play the file correctly? [18:48:04 CEST] <BtbN> They just ignore timestamps [18:48:07 CEST] <alexpigment> I.E. is it possible that they're doing something interesting to process the file that could be also done in ffmpeg? [18:48:12 CEST] <alexpigment> Ah [18:48:14 CEST] <BtbN> and strictly play according to the FPS [18:49:53 CEST] <alexpigment> Well at the very least, I'll get something logged up in trac today as I said I would [18:50:34 CEST] <alexpigment> And it can sit there until someone decides 1080i is not dead yet and wants to fix it ;) [18:50:59 CEST] <alexpigment> (or it can sit there until 1080i is actually dead, I suppose) [18:59:34 CEST] <BtbN> You can work it around easily [18:59:38 CEST] <BtbN> if you're not live-streaming [19:03:52 CEST] <alexpigment> How so? [19:03:58 CEST] <alexpigment> I must have missed that above [19:04:13 CEST] <alexpigment> Live streaming 1080i is going to be very rare I suspect [19:05:31 CEST] <alexpigment> Oh, demuxing and remuxing? [19:05:53 CEST] <alexpigment> I tried that yesterday. It still gave me a file that was read as 59.94fps [19:06:07 CEST] <alexpigment> Maybe I need to output to a particular container and demux in a particular way? [19:07:13 CEST] <alexpigment> Oh, output to raw first [19:07:21 CEST] <alexpigment> Ok, I'll try this on my end [19:13:30 CEST] <alexpigment> I'm still seeing the same problem on my end. I'm going out to raw h264 first, then I'm muxing back to mp4 [19:14:26 CEST] <alexpigment> I tried ts, but the tsmuxer in ffmpeg is a bit janky (or I've never figured out how to use it correctly, perhaps), so I have to then remux it with Tsmuxer to get something that will play in WMP [19:14:43 CEST] <alexpigment> Either way, it's still being read as ~60fps in MediaInfo [19:36:52 CEST] <alexpigment> BtbN: https://trac.ffmpeg.org/ticket/6633 [19:37:13 CEST] <BtbN> No idea what to do about that. [19:37:19 CEST] <alexpigment> I didn't put any of the information you listed above because that didn't seem appropriate to do [19:37:29 CEST] <alexpigment> But if you'd like to add any information to the comments, feel free to do so [19:50:09 CEST] <ZexaronS> alexpigment i hope interlaced dies already [19:50:56 CEST] <ZexaronS> as well as noneven frame rates [19:52:21 CEST] <BtbN> Yeah. Just bumping up the feature check to 2, so it will bail out if nvenc does not support frame interleaved encoding, is very tempting [19:52:29 CEST] <WebWalker3D> I'm attempting to setup drupal to use ffmpeg. From what I can tell, I have it installed correctly *ffmpeg - using the atrpms repo [19:53:32 CEST] <WebWalker3D> I keep getting a strange error, Error applying options to the filter. Error opening filters! [19:53:45 CEST] <WebWalker3D> and Unable to parse option value "(null)" as sample format [19:54:10 CEST] <WebWalker3D> that's after running: /usr/bin/ffmpeg -i /var/www/html/sites/default/files/mediaRecorder_59a9abb367ee3.ogg /var/www/html/sites/default/files/mediaRecorder_59a9abb367ee3.ogg.mp3 [19:54:35 CEST] <WebWalker3D> Google and forums after 2 days have failed me >.< [19:55:17 CEST] <relaxed> WebWalker3D: pastebin the console output [19:56:03 CEST] <WebWalker3D> relaxed: https://pastebin.com/PcW7kZap [19:56:34 CEST] <WebWalker3D> I get an empty file created though [19:58:02 CEST] <relaxed> WebWalker3D: version 2.2.1 is pretty old, try https://www.johnvansickle.com/ffmpeg/ [19:58:37 CEST] <alexpigment> ZexaronS: unfortunately, the Blu-ray people decided to make it a standard rather than wait a few months until 1080p60 was feasible. So 1080i is sadly the best option for non-24fps Blu-ray [19:58:44 CEST] <WebWalker3D> relaxed: I spent hours trying to compile ffmpeg before saying screw it and finding a repo [19:59:17 CEST] <alexpigment> Of course, players after 2010 will play 1080p60 per the AVCHD 2.0 standard, but you can't put out a Blu-ray to the masses and say "this might not work on your player" [19:59:38 CEST] <relaxed> WebWalker3D: they're static binaries, download and move the ffmpeg binary to your bin dir [19:59:57 CEST] <ZexaronS> alexpigment, oh, I don't bother with bluray, unless the drive costs 20$ [20:00:20 CEST] <alexpigment> yeah, I focus mostly on Blu-ray and broadcast [20:00:55 CEST] <alexpigment> 1080i is very much entrenched in both markets [20:01:07 CEST] <ZexaronS> that's business I guess, oh I'm just archiving stuff personally, on HDDs, moved my own collections to x265 progressive [20:01:10 CEST] <grublet> interlacing is such an annoyance [20:02:01 CEST] <ZexaronS> stuff at 29 fps i just recoded to 30, at 23.bleh i just put to 24, 59 to 60 [20:02:33 CEST] <alexpigment> ZexaronS: moved everything to x265? that sounds like a huge pain. What was the impetus to spend all that time and potentially lose quality in the process? Just space? [20:03:50 CEST] <ZexaronS> I took days of an did something else while it was recoding one thing for 12 hours [20:03:54 CEST] <ZexaronS> off* [20:04:05 CEST] <alexpigment> I suppose that's fair [20:04:24 CEST] <alexpigment> I usually leave everything in the source format unless I have to convert it for compatibility [20:04:31 CEST] <alexpigment> Saves me time and saves quality :) [20:05:03 CEST] <alexpigment> Then again, I probably have 40TB of data right next to me, so there's a tradeoff ;) [20:05:26 CEST] <ZexaronS> time solves it, more time, it'll retain quality, but indeed it's a pain x265 encoder quality the implementation decides speed not what ISO specifies "should take 50% more computation" that's all worthless if the code isn't as optimized as with x264 [20:05:47 CEST] <alexpigment> Very true [20:06:27 CEST] <alexpigment> Also, you're kinda limited to playing back the content only on hardware that specifically has hardware h265 decoding [20:06:50 CEST] <alexpigment> I suppose if you always know the hardware you're playing it on, that's not a huge issue [20:09:13 CEST] <ZexaronS> Well the compatability thing is, I'm archiving so it survives another 20-30 years, who knows what can happen, already troubles with MPC-HC, better to move this to safer format versus uncovering old HDDs 20 years from now just to find them in the original formats and in future you might not be able to even find or run an old app anymore since things are just moving so fast and stuff gets erased from history [20:09:57 CEST] <alexpigment> You make a valid point, certainly [20:10:29 CEST] <ZexaronS> so I thought, if it's in x265, there should still be decode/play support 20 years later [20:10:32 CEST] <alexpigment> If you've got random FLVs and MOVs and AVIs in various codecs, it makes sense to move to something more accepted and standardized [20:10:59 CEST] <alexpigment> We'll see. If technology stopped right now though, h264 would be a safer bet [20:11:15 CEST] <alexpigment> But yes, it's probably safe to assume that H265 will continue to be a common standard going forward [20:11:25 CEST] <ZexaronS> and if it doesn't have interlaced/odd things, then it would be a bit easier [20:11:33 CEST] <alexpigment> I agree with that [20:12:27 CEST] <alexpigment> I guess I just always stick with a format that has a physical component [20:12:59 CEST] <alexpigment> Because 20-30 years, we might not know how to deal with interlacing or non-integer frame rates on systems, but I'll be able to find a Blu-ray player and a TV that supports it [20:13:06 CEST] <alexpigment> So no problem there ;) [20:13:32 CEST] <alexpigment> which goes back to exactly why I have to deal with 1080i all the damn time [20:13:49 CEST] <alexpigment> It's the highest resolution (spatial and temporal) that this short-sighted format allows [20:14:03 CEST] <alexpigment> And of course almost all TV is in 1080i [20:14:10 CEST] <alexpigment> so I archive TV recordings to Blu-ray [20:14:21 CEST] <alexpigment> And in most cases that requires zero transcoding [20:14:30 CEST] <ZexaronS> H265 might not be popular, but if it's ISOIEC then govts/agencies/national archives would probably have those long-term systems with that support, so something should still survive, but then you have hardcore community memebers who keep all that old stuff safe and sound, the problem is, that could be sprinkled all over the world and unless they put it on internet I wouldn't know about it [20:16:07 CEST] <ZexaronS> the nasa mcdonalds apollo tapes story is an example, like only 1 company in US still knew how to operate the machines and was able to get original sources digitalized http://www.thelivingmoon.com/47john_lear/02files/Lunar_Orbiter_Tapes_Found.… [20:16:11 CEST] <alexpigment> Yeah true [20:17:10 CEST] <alexpigment> This looks like a pretty cool read [20:17:43 CEST] <alexpigment> Also, I'm a bit of an archivist, so I have a lot of hardware that I'm hoarding for various scenarios [20:18:18 CEST] <alexpigment> I have like 4 Panasonic AG-1980p VCRs (arguably the best ever made. 2 equivalent level JVCs [20:18:32 CEST] <alexpigment> a D-VHS high definition VCR [20:18:48 CEST] <alexpigment> several multi-format (PAL, SECAM, NTSC) VCRs [20:19:00 CEST] <alexpigment> Beta players [20:19:21 CEST] <alexpigment> lots of dvd recorders that I don't really use anymore except as a pass through for my capture setup [20:19:33 CEST] <ZexaronS> It's quite mysterious when you think about it, i knew about this story for several years, and I revisit it like 2 times per year as it always pops up in a discussions, like this one, and I never said this but I have another idea now ... why would the tapes be placed there and machines to play them ... [20:20:09 CEST] <alexpigment> Yeah, it's really ridiculous when you read it as a headline [20:20:50 CEST] <ZexaronS> I think they were ordered to destroy/throw em in trash, and the low level folks just put it in the mcdonalds ... whithout saying anything, hoping decades in future someone will find it [20:21:04 CEST] <ZexaronS> that's one theory [20:24:04 CEST] <alexpigment> Maybe this particular McDonalds was a front/coverup for the illuminati... [20:24:08 CEST] <alexpigment> (joking of course) [21:14:42 CEST] <BtbN> alexpigment, well, not I actually hit a driver bug. [21:15:00 CEST] <BtbN> There is an API which tells you the slice offsets. Which correctly tells me there are two slices when doing an interlaced encode. [21:15:10 CEST] <BtbN> But the offset for the second one does not get populated. [21:34:39 CEST] <Alid> Hellllooooo [21:34:54 CEST] <Alid> I need help [21:35:46 CEST] <Alid> Is there anyone here? [21:41:20 CEST] <Alid> Can someone help me?I'm an Android developer. [21:42:03 CEST] <JEEB> just ask instead of doing metaquestions [22:13:49 CEST] <kerio> there's always someone somewhere that can help you [22:19:23 CEST] <AliD1> I can compile ffmpeg for android by this file with no errors: [22:19:33 CEST] <AliD1> https://github.com/Buzgus/MyExploits/blob/master/ffmpeg_builder_Ok.sh [22:20:44 CEST] <AliD1> but when I add --enable-libmp3lame flag I get error. [22:20:54 CEST] <AliD1> Error Message Is: [22:21:07 CEST] <JEEB> that configure line is so out of date and overcomplicated it's not even funny [22:21:24 CEST] <AliD1> ERROR: libmp3lame >= 3.98.3 not found [22:21:24 CEST] <AliD1> If you think configure made a mistake, make sure you are using the latest [22:21:24 CEST] <AliD1> version from Git. If the latest version fails, report the problem to the [22:21:24 CEST] <AliD1> ffmpeg-user(a)ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. [22:21:24 CEST] <AliD1> Include the log file "config.log" produced by configure as this will help [22:21:25 CEST] <AliD1> solve the problem. [22:21:25 CEST] <AliD1> Makefile:2: config.mak: No such file or directory [22:21:26 CEST] <AliD1> Makefile:67: /common.mak: No such file or directory [22:21:51 CEST] <JEEB> you have to build LAME first, and if it's more than a single line post it in a pastebin like service in the future [22:21:54 CEST] <JEEB> and link here [22:22:16 CEST] <AliD1> I have lame sources [22:22:39 CEST] <JEEB> AliD1: you can stop overriding the sysroot as soon as you create a standalone toolchain with the make_standalone_toolchain.py script :P [22:22:44 CEST] <AliD1> and I compiled it to .a file by using Android NDK [22:23:02 CEST] <JEEB> (simplifies a fuckload of things because the tools know the sysroot by default then) [22:23:36 CEST] <JEEB> AliD1: you configured and set a prefix and installed the things under a prefix? in that case you should have a .pc file created by LAME in <prefix>/lib/pkgconfig [22:24:04 CEST] <JEEB> if that is so, PKG_CONFIG_LIBDIR=<prefix>/lib/pkgconfig <configure line for FFmpeg> [22:24:21 CEST] <JEEB> that way pkg-config will help you pick the correct parameters to build FFmpeg with LAME :P [22:27:53 CEST] <AliD1> I also get a warning about pkg-config: [22:27:58 CEST] <AliD1> WARNING: /home/ali/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-pkg-config not found, library detection may fail. [22:28:46 CEST] <JEEB> yes, it means that a specific pkg-config for the cross prefix was not found. it will still attempt to use the global one [22:29:00 CEST] <JEEB> also goddamnit you people not putting your toolchains into PATH :D [22:29:10 CEST] <JEEB> you're doing this shit so fucking hard to yourselves [22:29:23 CEST] <JEEB> > not making a standalone toolchain > not putting the toolchain into your PATH [22:29:55 CEST] <JEEB> it seems like someone did a bad guide at some point about using it like that, and after that everyone just parrots that shit :) [22:30:07 CEST] <JEEB> oh well, hope you're happy [22:31:47 CEST] <AliD1> Bor,I'm not a linux lover.I'm forced to use it because of my asshole computer(RAM:2.8 :((((((((((((( ) so I don't know what to do and I just Copy and Paste :) [22:35:31 CEST] <JEEB> the concept of PATH is common between lunix and windows, among other things [22:36:44 CEST] <JEEB> anyways, you need to build LAME with the build system with a set prefix, so you can install the headers and libraries into a specific place together with the pkg-config .pc file that contains the required compiler/linker parameters for LAME [22:37:19 CEST] <JEEB> and then you have to set PKG_CONFIG_LIBDIR to that location (directory) of that installed pc file when configuring something that's using it [22:37:54 CEST] <AliD1> there is no .pc between compiled lame files... [22:38:10 CEST] <JEEB> then you built it in a bad way [22:38:37 CEST] <AliD1> I have many object codes and a .a file [22:39:12 CEST] <JEEB> it sounds like you used a hacked up NDK specific build thing, instead of the LAME configure script and friends which is the standard build system [22:39:55 CEST] <JEEB> because when configuring LAME properly you configure the prefix with --prefix=/path/to/your/build/prefix/ [22:40:06 CEST] <JEEB> and then you do make for build and make install to install it to the configured prefix [22:40:13 CEST] <JEEB> the last step should also generate a .pc file [22:40:30 CEST] <AliD1> I used this help: [22:40:31 CEST] <JEEB> so that you would have a lame .pc file under /path/to/your/build/prefix/lib/pkgconfig [22:40:32 CEST] <AliD1> http://zhgeaits.me/android/2016/06/17/android-ffmpeg.html [22:40:59 CEST] <JEEB> LOL [22:40:59 CEST] <JEEB> yea [22:41:08 CEST] <JEEB> that completely goes around LAME's build system [22:41:13 CEST] <JEEB> you wanted shit, you got shit [22:43:05 CEST] <AliD1> Also I found this: [22:43:08 CEST] <AliD1> https://github.com/gaurav5670/Compile-ffmpeg-for-android-through-command-li… [22:43:10 CEST] <JEEB> this is how you generate a normal toolchain with NDK [22:43:11 CEST] <JEEB> https://github.com/mpv-android/buildscripts/blob/master/download.sh#L44..L65 [22:43:30 CEST] <JEEB> then you add the bin/ directory of that toolchain into PATH [22:43:58 CEST] <JEEB> then suddenly you don't have to a) use the sysroot overrides all the time b) specify the full path to tools [22:44:13 CEST] <JEEB> so suddenly the normal build systems start working much better/simpler for you :P [22:45:04 CEST] <AliD1> Bro thank you for this help but I can't download (wget dl.google.com) because of SANCTIONS! [22:45:30 CEST] <JEEB> you already have the NDK archive around anyways [22:45:55 CEST] <JEEB> don't just copy-paste but understand what the fuck those things mean [22:46:38 CEST] <AliD1> But also you should know that Internet speed is fucking us in Iran.It's 20kb/s [22:47:16 CEST] <JEEB> you already have NDK around so I don't think that matters right now [22:47:26 CEST] <JEEB> since you just use the script included with your NDK download [22:47:42 CEST] <JEEB> afterwards after you add the standalone toolchain's bin/ directory to PATH you should be able to call `arm-linux-androideabi-gcc` or `arm-linux-androideabi-clang` [22:47:57 CEST] <JEEB> without specifying the long path :P [22:48:31 CEST] <AliD1> Ok.I'm going to test that.I will come back here soon. [22:48:53 CEST] <JEEB> thus the minimum FFmpeg configuration becomes (for ARMv7) `--prefix=/your/prefix --arch=armv7 --cpu=armv7-a --enable-cross-compile --target-os=android --cross-prefix=arm-linux-androideabi-` [22:49:07 CEST] <JEEB> which is much shorter than what that random script had :P [22:56:08 CEST] <AliD1> I got this error:https://paste.ee/p/mBjpY [22:57:14 CEST] <JEEB> why are you running that script since what you need is just using the script that you already have in your NDK directory? [22:57:38 CEST] <JEEB> not the script I linked, I specifically highlighted lines of it that are useful to you [23:00:31 CEST] <AliD1> Must I save the selected part of code and save it as .sh file then run it? [23:00:54 CEST] <JEEB> no [23:00:59 CEST] <AliD1> ? [23:02:27 CEST] <JEEB> you have under `build/tools/` in your NDK a script called `make_standalone_toolchain.py`, run it and check the parameters you can give to it. the script lines I pointed to create two toolchains and you can also use them as hints [23:17:06 CEST] <AliD1> Bro,Check this:https://paste.ee/p/nW4qr [23:18:06 CEST] <JEEB> yea, you don't stop at your first error which is that for API version of 14 you can't build a arm64 toolchain. it seemed to get the armv7 one done, though? [23:18:25 CEST] <AliD1> yes [23:18:27 CEST] <JEEB> (do really check how old of an API version you need) [23:18:45 CEST] <JEEB> https://source.android.com/source/build-numbers [23:19:16 CEST] <JEEB> basically the newer API sysroot you use, the newer android version is required by your built things, but on the other hand you get various bug fixes by google :P [23:19:20 CEST] <JEEB> (and new APIs/features) [23:19:35 CEST] <AliD1> my minimum is 14 because of my project codes [23:19:41 CEST] <JEEB> ok [23:19:47 CEST] <JEEB> or well, maximum [23:19:53 CEST] <JEEB> you mean? [23:19:59 CEST] <AliD1> No [23:20:37 CEST] <AliD1> about 100% of people will be able to use my app [23:20:43 CEST] <JEEB> yes [23:20:57 CEST] <JEEB> I meant that you have a reason why you are targeting that old API version [23:21:26 CEST] <AliD1> I have no problem with higher APIs. [23:21:29 CEST] <JEEB> it's just also important to not set the thing too low because you lose features/bug fixes [23:22:03 CEST] <AliD1> There is no problem.I can use 21 [23:22:22 CEST] <JEEB> yea, it just means that devices under 21 can't use the binaries :) [23:22:39 CEST] <JEEB> I use 21 myself because my opengl code would just not run on 4.4.x devices or older [23:25:08 CEST] <AliD1> Great.Thank you for your helps.Bro,Is this Ok?Have I all files?https://paste.ee/p/tCzEx [23:25:45 CEST] <JEEB> that's still not the one you created [23:26:03 CEST] <JEEB> anyways, I'm out [23:26:10 CEST] <AliD1> yes I can have arm64 too [23:27:15 CEST] <AliD1> Now,what should I do? [23:27:29 CEST] <AliD1> Compiling Lame? [00:00:00 CEST] --- Sun Sep 3 2017

1 0

ffmpeg-devel.log.20170901
by burek 02 Sep '17

02 Sep '17

[00:08:18 CEST] <michaelni> durandal_170, in git master the multiplication looks like just real valued not complex so while it scales its not compatible with convolution [00:09:58 CEST] <durandal_170> michaelni: yes, i'm reusing rdft_horizontal and rdft_vertical and doing complex multiplication [00:10:21 CEST] <michaelni> iam not sure if not one of these need to be changed to C2C [00:11:33 CEST] <durandal_170> wouldn't same be needed if one does just inverse of itself? [00:16:20 CEST] <atomnuker> BtbN: so CUdeviceptr are pointers but you can't access them directly? [00:17:02 CEST] <atomnuker> what are AVFrames supposed to contain in the data pointers if they're on the hardware? [00:17:20 CEST] <atomnuker> pointers to contexts so the hwcontext functions can access them? [00:18:39 CEST] <nevcairiel> every hardware pixfmt defines what the data pointers contain [00:18:55 CEST] <nevcairiel> so just opaque things you need to know how to access [00:20:02 CEST] <rcombs> it can be an actual pointer, or an integer surface ID, or whatever else [00:20:42 CEST] <atomnuker> and nothing else but hwcontext functions will access it, right? [00:21:08 CEST] <nevcairiel> not necessarily [00:21:18 CEST] <nevcairiel> its documented what it contains, so the user could access it [00:21:35 CEST] <nevcairiel> and of course encoders/decoders/filters access it [00:21:35 CEST] <wm4> hm I think opencl is one example where it's more complex? [00:22:00 CEST] <wm4> most hw pixfmts have just a single pointer which is an API object in the underyling hw API [00:22:18 CEST] <atomnuker> opencl isn't a hwaccel and its rather shoddily implemented [00:22:51 CEST] <wm4> I thought you're doing this for a filter [00:22:51 CEST] <atomnuker> I don't like it and I think we need to get rid of it, vulkan does everything it does better [00:23:03 CEST] <jkqxz> There is an opencl hwcontext, but it's stalled for lack of any proper use. [00:23:05 CEST] <wm4> unless you're talking about the old opencl filters [00:23:12 CEST] <jkqxz> The opencl filters in ffmpeg are just awful. [00:23:23 CEST] <atomnuker> wm4: not necessarily, there's jpeg decoding shaders which I'd like to implement [00:23:28 CEST] <atomnuker> so its a hwaccel [00:23:30 CEST] <wm4> yeah I recall jkqxz wanted to add some real opencl filters [00:23:38 CEST] <wm4> atomnuker: oh [00:24:04 CEST] <nevcairiel> that sounds stupid [00:24:48 CEST] <jkqxz> What do you want JPEG decoding for? All the decode APIs implement it, but noone has bothered to write a hwaccel. That rather suggests that noone cares. [00:25:39 CEST] <atomnuker> because they're already written and seem to perform better and to demonstrate it might be usable elsewhere to decode [00:26:15 CEST] <nevcairiel> "because it exists" shouldnt be a reason to bloat up ffmpeg, you're one of those always eager to delete stuff thats not used by anything =p [00:26:36 CEST] <atomnuker> they're faster then :) [00:26:43 CEST] <jkqxz> Perform better than what? Does that include all the time messing around with upload/download? [00:27:18 CEST] <atomnuker> yep [00:27:25 CEST] <atomnuker> jpegturbo IIRC [00:27:47 CEST] <jkqxz> (The whole point of the opencl stuff was that upload/download was terrible and you should do stuff only on the GPU, so it interoperates with DXVA2, D3D11 and VAAPI to do that. Upload/download is possible but to be avoided.) [00:28:26 CEST] <wm4> atomnuker: is this a generic compute shader? [00:28:34 CEST] <atomnuker> no, glsl [00:28:35 CEST] <atomnuker> https://archive.org/details/lca2017-GPU_Accelerated_JPEG_Rendering [00:28:46 CEST] <wm4> well compute shaders can be written in glsl [00:29:24 CEST] <nevcairiel> meh its a partial decoder [00:29:37 CEST] <wm4> aren't normal hwaccels too? [00:29:38 CEST] <nevcairiel> you need to do bitstream shit on the cpu, which leads to super ugly code IMHO [00:29:48 CEST] <nevcairiel> well no, hwaccels get the full slices [00:29:53 CEST] <atomnuker> https://people.xiph.org/~negge/LCA2017.pdf [00:29:56 CEST] <nevcairiel> this needs entropy decoding on the cpu [00:30:04 CEST] <wm4> yeah, but everything else is done on the CPU [00:30:18 CEST] <nevcairiel> so basically its at a state where video hwaccels were 10 years or so ago [00:30:20 CEST] <wm4> hm makes sense [00:30:23 CEST] <nevcairiel> and people moved on to things that dont suck [00:30:32 CEST] <wm4> or which suck more [00:30:39 CEST] Action: wm4 stares at apple and linux/arm things [00:30:55 CEST] <nevcairiel> slice decoders are definitely better then MC/IDCT decoders from long ago =p [00:30:58 CEST] <jkqxz> Hybrid stuff does have value for new codecs. JPEG isn't what I'd pick there though... [00:32:48 CEST] <atomnuker> well its to proove a concept, don't expect me to write loopfilter shaders for vp9 just yet [00:33:41 CEST] <jkqxz> VP9 will be in ~all new hardware pretty soon. Better start with AV1! [00:33:56 CEST] <nevcairiel> the performance numbers in that paper include things like yuv -> rgb conversion, no wonder it turns up faster in the end [00:34:38 CEST] <jkqxz> I bet they don't do correct colourspace conversion. [00:35:12 CEST] <wm4> nevcairiel: they provide separate numbers for that [00:35:52 CEST] <atomnuker> jkqxz: and look what good hardware decoding does when it fails to decode 90% of the videos I'd like to watch [00:36:02 CEST] <atomnuker> hevc 10bits isn't even supported on skylake [00:36:08 CEST] <atomnuker> its all because of profiles and levels [00:36:19 CEST] <jkqxz> Are you one of those amine people who wants 10-bit H.264? [00:36:31 CEST] <atomnuker> no, HDR 4K 10bit videos [00:36:40 CEST] <wm4> I think people have tried to do h264 in shaders before [00:36:52 CEST] <wm4> and the performance wasn't necessarily convincing, I think? [00:36:57 CEST] <nevcairiel> not at all [00:37:01 CEST] <jkqxz> So Kaby Lake, right. The profiles are a pain, yeah, but new ones will just be added as they become useful. [00:37:09 CEST] <nevcairiel> nothing beats full hardware decoders anyway [00:37:20 CEST] <nevcairiel> they got so fast in recent years [00:37:26 CEST] <atomnuker> no, skylake, I have a skylake from the end of 2015, and yet it doesn't do 10bit [00:37:27 CEST] <wm4> "hybrid" decoding done by intel drivers probably also uses programmable GPU parts [00:37:30 CEST] <atomnuker> what use is it then? [00:38:13 CEST] <nevcairiel> there is literally no hevc content commercially available though outside of walled-garden ecosystems we don't get to play in anyway =p [00:39:15 CEST] <atomnuker> nevcairiel: they go fast? decoding low res h264 is faster in software [00:39:27 CEST] <jkqxz> No, I mean it works on Kaby Lake. Anything Intel newer than what you have will do it. [00:39:27 CEST] <nevcairiel> define fast [00:39:28 CEST] <atomnuker> by 5 to 10 times too [00:39:33 CEST] <atomnuker> 5 to 10 times [00:39:41 CEST] <nevcairiel> i get like a thousand fps on 1080p [00:39:52 CEST] <nevcairiel> no clue how well it scales down on lowres [00:40:09 CEST] <atomnuker> jkqxz: considering how it has a different socket you need to fork out enough cash for a new machine [00:40:13 CEST] <nevcairiel> but i don't particularly care if it goes lightning fast or ultra lightning fast [00:40:37 CEST] <nevcairiel> also skylake has hybrid hevc10 decoding afaik, its not all that brilliant but it works [00:40:39 CEST] <jkqxz> The constant overhead gets annoying. At low resolutions it's only worth using hardware decode if you need the output in GPU surfaces. [00:40:53 CEST] <rcombs> nevcairiel: isn't that only useful with MFX [00:41:00 CEST] <nevcairiel> works through dxva as well [00:41:05 CEST] <rcombs> hmmm [00:41:11 CEST] <rcombs> but not VAAPI, presumably [00:41:14 CEST] <nevcairiel> not sure about platforms that dont have a central decoding api :p [00:41:37 CEST] <wm4> I thought there are some "special" closed vaapi drivers that do hybrid [00:41:48 CEST] <wm4> maybe they were bundled with MFX or some shit [00:41:54 CEST] <atomnuker> I'm sure I'm also not the only one who'd like a fully multiplatform hwaccel, even if its hybrid [00:41:57 CEST] <wm4> quicksync sdk something something [00:42:03 CEST] <rcombs> wm4: yeah that's MFX [00:42:04 CEST] <nevcairiel> hybrid generally sucks [00:42:12 CEST] <atomnuker> nevcairiel: APIs suck more [00:42:27 CEST] <nevcairiel> I can implement APIs, I can't fix inherent suckyness of a hybrid approach [00:42:36 CEST] <wm4> khronos should make a hwaccel API... but it'd suck or nobody would use it or both [00:42:57 CEST] <jkqxz> They do. It's called OpenMAX. [00:42:59 CEST] <rcombs> ^ [00:42:59 CEST] <atomnuker> nevcairiel: well you could if it was open... which with vulkan it would be [00:43:12 CEST] <nevcairiel> besides on a codec like hevc entropy decoding quickly becomes a major bottleneck [00:43:13 CEST] <rcombs> iirc AMD uses it, don't they [00:43:13 CEST] <jkqxz> It sucks and some people use it anyway. [00:43:16 CEST] <nevcairiel> so good luck getting that any faster [00:43:35 CEST] <rcombs> and also Realtek on e.g. RPi, and a fair bit of Android stuff [00:43:54 CEST] <nevcairiel> atomnuker: well i can't, because its just how hybrid works, its sucky by design [00:44:12 CEST] <atomnuker> nevcairiel: so you're fully complacent with not touching things anymore if they run faster than realtime on your system? [00:44:16 CEST] <rcombs> meanwhile, I recently learned that Android MediaCodec is capable of doing zero-copy buffer-passing& and it's built on top of EGL [00:44:39 CEST] <rcombs> they added an EGL function for "set the PTS of the next frame I send" [00:44:42 CEST] <wm4> jkqxz: oh, that's sad [00:44:46 CEST] <wm4> rcombs: oh, that's sad, too [00:44:47 CEST] <rcombs> and then you send a frame by doing swapBuffers() [00:44:53 CEST] <wm4> .................. [00:45:01 CEST] <wm4> just... [00:45:20 CEST] <wm4> does it refer to using a GL interop API and rendering to an offscreen surface? [00:45:33 CEST] <wm4> you had to do this with vaapi/x11, and it sucked to hell and back [00:45:33 CEST] <rcombs> I think that's the idea? [00:45:36 CEST] <nevcairiel> atomnuker: what does that have to do with anything? I have full decoding capability through GPUs of all 3 major vendors, I just don't need subpar hybrid =p [00:45:58 CEST] <wm4> (vaapi had only a X11 rendering API... so you rendered to a X pixmap and mapped that as GL texture) [00:46:10 CEST] <rcombs> so I'm still not entirely sure if this is better or worse than getting the vendors to give us access to the devfs nodes and using OMX directly [00:46:11 CEST] <nevcairiel> you're never going to get hybrid faster then those dedicated decode ASICs [00:46:23 CEST] <rcombs> (all this GL nonsense is implemented on top of OMX) [00:46:28 CEST] <wm4> rcombs: I think it's both [00:46:41 CEST] <rcombs> well, net-better or net-worse [00:47:00 CEST] <atomnuker> nevcairiel: and when a new codec comes out or some other one's unsupported profile becomes a large enough meme, then what? [00:47:12 CEST] <rcombs> the primary advantages of using the GL stuff is that it's theoretically portable (within android anyway), and it doesn't involve directly fucking with OMX [00:47:22 CEST] <nevcairiel> then I rather decode on software then some crap hybrid :) [00:47:36 CEST] <atomnuker> nevcairiel: but that crap hybrid might be 2x faster [00:47:46 CEST] <wm4> rcombs: I'd rather continue to insist that google take a look at existing APIs instead of continuing to fuck up [00:47:57 CEST] <wm4> d3d11va and vaapi are good examples these days [00:48:25 CEST] <rcombs> so, is it sufficiently worse than OMX (in terms of both API [and having to deal with GL] and performance) that using OMX is preferable? [00:48:33 CEST] <rcombs> I dunno the answer [00:48:51 CEST] <rcombs> wm4: do you have thoughts on the new v4l2 codec interface [00:49:01 CEST] <jkqxz> I think d3d11va and vaapi are considered too hard, because they give too much control to the user. [00:49:10 CEST] <nevcairiel> I like control :( [00:49:12 CEST] <jkqxz> V4L2 is the logical conclusion of taking all control away from the user and hiding everything in kernel blobs. [00:49:38 CEST] <rcombs> meanwhile VideoToolbox is halfway in between [00:49:48 CEST] <nevcairiel> the linux people really like their monolitic-everything-kernel, dont they [00:49:54 CEST] <rcombs> everything is hidden, except for frame reordering, which you've got to do yourself [00:50:04 CEST] <rcombs> and also it doesn't tell you how [00:50:08 CEST] <nevcairiel> VT is just the most terrible of them all [00:50:26 CEST] <rcombs> nevcairiel: IMO the API would be just fine if it weren't for how it fucks up on reordering hard [00:50:28 CEST] <wm4> rcombs: well I guess it's better than X vendor APIs that work the same anyway [00:50:33 CEST] <nevcairiel> it doesn't give you any control but doesn't even do the things it ought to be doing [00:50:53 CEST] <rcombs> (for decode, I mean) [00:51:06 CEST] <wm4> rcombs: and other than being full-stream and being full of awkward kernel dev fuckups, it's reasonable I guess [00:51:21 CEST] <nevcairiel> fullstream is the future! [00:51:34 CEST] <nevcairiel> and we parse the btistream anyway because they dont export half the metadata [00:51:40 CEST] <rcombs> I'm fine with fullstream in concept, as long as it actually does all the stuff [00:51:40 CEST] <wm4> (awkward kernel dev fuckups means kernel devs don't know how to create APIs, and force it into existing, inadequate POSIX or related APIs) [00:51:43 CEST] <wm4> like ioctl hell [00:51:46 CEST] <rcombs> just, in practice nothing does all the stuff [00:52:17 CEST] <rcombs> wm4: did you see the time when the VideoToolbox kernel people forgot to zero buffers before they gave them to the decoder [00:52:19 CEST] <wm4> nevcairiel: yeat, VT is terrible [00:52:22 CEST] <wm4> *yeah [00:52:28 CEST] <wm4> nevcairiel: both API and implementation [00:52:43 CEST] <wm4> rcombs: yep [00:52:45 CEST] <RiCON> wm4: speaking of VT, what happened to your april 1st MF patch [00:53:14 CEST] <rcombs> I've got nothing against the VT API apart from the stuff that's missing [00:53:17 CEST] <wm4> RiCON: yeah, I should fix that I guess [00:53:30 CEST] <rcombs> if it had the missing functionality, but otherwise worked the same way it does now, it'd be fine [00:53:42 CEST] <wm4> rcombs: you mean reordering? [00:53:50 CEST] <rcombs> reordering, and other metadata stuff [00:54:02 CEST] <nevcairiel> i have a thick skin and can ignore "bad" APIs mostly, as long as I can actually reach my goal eventually [00:54:16 CEST] <nevcairiel> but VT doesn't seem to make that possible [00:54:42 CEST] <rcombs> it's like they got halfway through designing something decent, and then stopped [00:54:57 CEST] <rcombs> exactly at the point where it did enough for their own applications [00:54:59 CEST] <nevcairiel> probably designed the other half in the OSX video player app [00:55:05 CEST] <nevcairiel> and forgot that it didnt belong there [00:55:09 CEST] <wm4> also, now is the time that users are crying for hevc support on OSX [00:55:16 CEST] <nevcairiel> didnt they add that [00:55:25 CEST] <wm4> yes, it seems so [00:55:29 CEST] <wm4> with no docs [00:55:35 CEST] <nevcairiel> even has an encoder i heard [00:56:06 CEST] <wm4> I also need to fix that ffmpeg's VT crashes if multithreading is enabled [00:56:32 CEST] <rcombs> lol [00:56:35 CEST] <nevcairiel> people have been bugging me about hwdecoding for linux, luckily mac didnt come up yet [00:56:56 CEST] <nevcairiel> speaking about that, does avcodec have a built-in way to auto-select vaapi or vdpau on availability yet? [00:56:59 CEST] <wm4> I think VT mostly works now... I only remember a patch by tmm1 which fixed some sps midstream change thing [00:57:18 CEST] <wm4> nevcairiel: no [00:57:54 CEST] <cone-182> ffmpeg 03Dale Curtis 07master:f1e47f87131d: avformat/mov: Bail when invalid sample data is present. [00:57:54 CEST] <cone-182> ffmpeg 03Daniel Glöckner 07master:feb1dbc7bd4c: avformat/mov: prevent duplication of first fragment's ctts_data [00:57:56 CEST] <nevcairiel> what would the best way be to "probe"? try to create a device context? [00:58:19 CEST] <wm4> that's what I do, plus checking for awful emulation layers [00:58:41 CEST] <jkqxz> Probe is nasty because it's hard to know whether a given stream will actually be decodable on it. [00:59:06 CEST] <nevcairiel> i guess, but i'm not worried about artificial cases like multiple GPUs yet [00:59:17 CEST] <wm4> usually API probing means either it probably works with most streams, or it's horseshit [00:59:30 CEST] <nevcairiel> so if I can detect if the API is actually available (and perhaps rule out emulation things), that might be enough [01:01:32 CEST] <jkqxz> Most other stuff is just about there. The last generic hwaccel patch (not yet complete) in the other tine finishes off knowing which devices are usable and matching them to formats. [01:01:46 CEST] <jkqxz> Given that you just look at the possibly-usable devices and try to make them. [01:03:35 CEST] <wm4> jkqxz: oh right, getting in this hwframes adjustment API we've talked about would be nice because apparently a new ffmpeg release is planned soon [01:05:01 CEST] <durandal_170> michaelni: well, i cant get identity impulse to be all 1 in re and all 0 in im so C2C doesnt hold for that one [01:15:16 CEST] <jkqxz> wm4: Yeah, I should get back to that one. [01:15:51 CEST] <jkqxz> I've been distracted by finishing off CBS and playing with some silly stuff recently. (Anyone want no-CPU screen grab for Linux? Works with or without X! Also needs root, boo :(.) [01:24:47 CEST] <wm4> no-CPU? wut [01:29:49 CEST] <jkqxz> KMS lets you find the buffers being used for scanout as DRM objects which you can give to VAAPI. [01:32:48 CEST] <kiroma_> Is there a filter that can blend frames together to lower framerate of video? [01:33:19 CEST] <kiroma_> for example blend 10 frames together in a 600 fps input video to produce a smooth 60 fps one? [01:33:21 CEST] <durandal_1707> michaelni: it have something to do with copy_rev() [01:33:47 CEST] <durandal_1707> kiroma_: define blend [01:34:54 CEST] <kiroma_> Uh [01:35:52 CEST] <kiroma_> Overlay one image on top of another with 50% opacity? [01:36:01 CEST] <durandal_1707> iirc for simple blend there is framerate filter [01:36:48 CEST] <kiroma_> Oh [01:36:58 CEST] <kiroma_> Okay thanks [01:37:17 CEST] <kiroma_> (how did I not notice that?) [02:47:57 CEST] <cone-182> ffmpeg 03pkviet 07master:73bed07373f2: avocdec/libopus: fix typo [02:47:58 CEST] <cone-182> ffmpeg 03Yi(SÑ) 07master:c24bcb553650: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop. [02:47:59 CEST] <cone-182> ffmpeg 03Yi(SÑ) 07master:900f39692ca0: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array() [02:48:00 CEST] <cone-182> ffmpeg 03Yi(SÑ) 07master:9d00fb9d70ee: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack() [02:48:13 CEST] <rpw> doublya [02:53:30 CEST] <Compn> irc client actually displays those chinese characters [02:53:34 CEST] <Compn> impressive [03:05:14 CEST] <rpw> I'm calling scale_slice in vf_scale.c from multiple pthreads. I'm getting a segmentation fault. [03:13:00 CEST] <rpw> Perhaps I need a unique struct SwsContext per thread. Can I just do a memcpy(new_sws, sws, sizeof(struct SwsContext))? [04:21:56 CEST] <cone-182> ffmpeg 03Steven Liu 07master:837580f458f2: avformat/dash: move reused API to common file and header file [06:52:48 CEST] <cone-182> ffmpeg 03Anton Khirnov 07master:b12e4d3bb8df: avio: add a destructor for AVIOContext [07:22:47 CEST] <cone-182> ffmpeg 03Anton Khirnov 07master:78a7af823b7c: Use the new AVIOContext destructor. [10:10:34 CEST] <wm4> stevenliu: you could post the dash patch also as series of incremental patches, if that makes it easier [10:24:41 CEST] <stevenliu> wm4: you mean: make avformat/dash and avformat/dashdec to [PATCH 1/2] [PATCH 1/2] ? do i get the mean? [10:26:03 CEST] <wm4> stevenliu: yeah [10:26:19 CEST] <stevenliu> Ok, Thanks wm4 :D [10:27:10 CEST] <wm4> and I get that these patch iterations are painful... but I also think it's required to fix the remaining things [10:31:24 CEST] <stevenliu> yes, only a little modify in a big patch, review and check is a hard work, just me know which part is modified, reviewers to review it is not easy :( [10:41:10 CEST] <durandal_170> michaelni: how is multiplication done in 2d fft? [10:44:45 CEST] <BtbN> atomnuker, you can, but with CUDA functions. [10:46:11 CEST] <wm4> <rpw> I'm calling scale_slice in vf_scale.c from multiple pthreads. I'm getting a segmentation fault. [10:46:12 CEST] <wm4> <rpw> Perhaps I need a unique struct SwsContext per thread. Can I just do a memcpy(new_sws, sws, sizeof(struct SwsContext))? [10:46:13 CEST] <wm4> no [10:46:21 CEST] <wm4> even the slice calls are stateful [10:46:39 CEST] <wm4> they probably store at least a line of the previous call in memory for interpolation or so [10:46:50 CEST] <nevcairiel> i learned that the hard way, sws isnt exactly thread friendly [10:47:23 CEST] <wm4> doing just conversion without scaling would be pretty trivially threadable [10:47:36 CEST] <wm4> except when it converts to 420p or some shit as intermediate step [10:47:40 CEST] <wm4> (does it still do this?) [10:48:05 CEST] <nevcairiel> most of the conversions i cared to possibly make faster involved scaling, like 420 to rgb [10:48:48 CEST] <wm4> I was thinking format conversion without size (or subsampling) change [10:48:51 CEST] <nevcairiel> ultimately I NIH'ed that with simple bilinear chroma scaling because factor 2 is so easy [10:49:11 CEST] <wm4> I just use GPU shaders duh [10:49:26 CEST] <nevcairiel> i tell people to do that, but some want software conversion [10:49:57 CEST] <wm4> stupid people or dshow whatever restrictions? [10:50:08 CEST] <nevcairiel> mostly stupid people i guess [10:50:20 CEST] <nevcairiel> or people who want dumb post-processing things that d ont like yuv so they need rgb first [10:50:57 CEST] <wm4> we have user shaders for that kind of stuff (and vapoursynth things for the more hopeless nerds) [10:51:16 CEST] <nevcairiel> noone ever bothered to make a vapoursynth directshow filter [10:51:38 CEST] <wm4> doom9 folks are still tripping on avisynth [10:51:53 CEST] <nevcairiel> but user shaders are possible in many dshow players, but apparently hlsl is hard [10:51:59 CEST] <JEEB> yup [10:52:09 CEST] <JEEB> heck, MPC-HC even had an included shader editor [10:52:12 CEST] <JEEB> which I went WTF at [10:52:20 CEST] <nevcairiel> i never even opened that i dont think [10:52:41 CEST] <JEEB> I once noticed it in the menus and double-blinked [10:55:01 CEST] <BtbN> Does patchwork not pick up E-Mails with patches attached anymore? [11:01:42 CEST] <cone-136> ffmpeg 03Timo Rothenpieler 07master:a0b69e2b0a7b: avcodec/nvenc: add support for specifying entropy coding mode [11:01:42 CEST] <cone-136> ffmpeg 03Timo Rothenpieler 07master:0e995eac2035: avcodec/nvenc: only push cuda context on encoder close if encoder exists [11:15:13 CEST] <cone-136> ffmpeg 03Timo Rothenpieler 07release/3.3:bab4cb3fb55e: avcodec/nvenc: only push cuda context on encoder close if encoder exists [12:54:04 CEST] <cone-136> ffmpeg 03Steven Liu 07master:adeb41afb80f: avformat/dash:add copyright to dash.c [14:10:06 CEST] <mobi> hi [14:10:17 CEST] <mobi> Nobody used youtube live channels? [14:10:18 CEST] <mobi> It is broken after this commit [14:10:39 CEST] <mobi> http://trac.ffmpeg.org/ticket/6490 [14:17:06 CEST] <durandal_170> stevenliu: ^ [14:18:09 CEST] <stevenliu> let me see [15:03:42 CEST] <stevenliu> mobi: here? [15:03:52 CEST] <stevenliu> Wnat your email address? [15:05:44 CEST] <stevenliu> be used to add author [15:06:23 CEST] <mobi> Yes , why do you need my email ? [15:06:32 CEST] <stevenliu> Yes [15:06:51 CEST] <stevenliu> Submit and commit modify need your author info [15:07:16 CEST] <stevenliu> for example me: Steven Liu <lq(a)chinaffmpeg.org> [15:07:55 CEST] <mobi> this workround is not good. That makes live play only a little less broken [15:12:30 CEST] <stevenliu> let me think about it, don't worry [15:13:03 CEST] <stevenliu> will fix it sunday or monday [15:16:29 CEST] <mobi> ok, thx [15:20:37 CEST] <mobi> stevenliu: you dash patch need this : +OBJS-$(CONFIG_DASH_DEMUXER) += dash.o dashdec.o for build without mux [17:28:14 CEST] <cone-638> ffmpeg 03James Almer 07master:877076ffa17b: avformat/avio: update avio_alloc_context() doxy [17:44:03 CEST] <ubitux> for the ppl on ARM/ARM64 who want to cycle count stuff but don't want to mess with kernel modules [17:44:08 CEST] <ubitux> i did https://github.com/ubitux/FFmpeg/compare/perf [17:44:35 CEST] <ubitux> i'll probably make a build switch and submit [17:44:38 CEST] <ubitux> but it's already usable [17:45:48 CEST] <atomnuker> wouldn't it be more useful being in lavu/timer.h rather than checkasm only? [17:46:30 CEST] <ubitux> atomnuker: that's what i initially did, but it's way too much pain [17:46:51 CEST] <ubitux> not sure that's even possible without a lot of problems [17:47:27 CEST] <ubitux> first because i need a "global" fd [17:47:39 CEST] <ubitux> (and i don't want to if () in the read time) [17:48:13 CEST] <ubitux> the other problem is syscall (which requires _GNU_SOURCE) [17:48:44 CEST] <ubitux> the nop time and other heuristics are pretty different in timer.h too [17:48:52 CEST] <ubitux> so having a common api is very tricky [17:49:05 CEST] <ubitux> i couldn't have a common api within libavutil without some avpriv shit [17:49:19 CEST] <ubitux> so in the end i put that stuff in checkasm where it matters the most [17:49:33 CEST] <ubitux> you're not supposed to use START/STOP_TIMER anymore [17:49:47 CEST] <ubitux> just write your stuff in checkasm so it has coverage and benchmark infrastructure [17:52:16 CEST] <atomnuker> too complicated and doesn't offer non-synthetic input [17:57:19 CEST] <cone-638> ffmpeg 03wm4 07master:5d7667475680: lavf: make avio_read_partial() public [18:03:21 CEST] <ubitux> atomnuker: that's all i can propose, sorry [18:09:55 CEST] <iive> ubitux: please, checkasm is not reliable benchmark, it is in essense a syntetic test and does not cover real world usage [18:10:29 CEST] <ubitux> yeah well, you can ask me all you want, i don't have any other solution [18:10:39 CEST] <ubitux> and checkasm is covering my use case [18:11:35 CEST] <ubitux> any solution i could come up with as part of the lavu/timer.h thing had too much outstanding issues that couldn't be solved [18:14:38 CEST] <jamrial> iive: to check if an asm function is faster or not than the c version it's more than enough [18:18:26 CEST] <iive> once again, this is syntheric test. [18:19:25 CEST] <ubitux> which shouldn't mean much given that you rarely have any condition [18:22:06 CEST] <iive> ? [18:22:46 CEST] <ubitux> whatever the input you perform most of the time the same instructions in the simd code [18:23:00 CEST] <ubitux> i know there are a few exceptions [18:23:27 CEST] <iive> well, it wasn't for the last SIMD i wrote. [18:23:59 CEST] <iive> and i've had cases where some change is slightly better in the synthetic tests, but doesn't bode so well in ffmpeg. [18:24:29 CEST] <BBB> why not use START/STOP_TIMER? [18:24:36 CEST] <BBB> ubitux: ^ [18:24:48 CEST] <ubitux> i replied earlier [18:25:06 CEST] <iive> that's where it started. should we have start/stop for arm that is implemented ugly [18:25:19 CEST] <BBB> ubitux: oh is that arm only? so on x86 its still ok? [18:25:22 CEST] <iive> or we should rely on checkasm benchmark [18:25:23 CEST] <atomnuker> you usually only have one start/stop timer in the entire code, so having global context isn't that bad [18:25:44 CEST] <ubitux> BBB: it's not arm only, it's linux only, but it's mostly useful for arm [18:25:50 CEST] <ubitux> (and yes, i'll make a build switch) [18:26:06 CEST] <BBB> on x86 I can still use START/STOP_TIMER, right? [18:26:15 CEST] <ubitux> i'm not touching start/stop timer [18:26:32 CEST] <iive> we are talking about extending it. [18:26:32 CEST] <BBB> ok so I can still use it then, tnx [18:26:47 CEST] <ubitux> i'm just making possible to run checkasm on arm/arm64 [18:27:10 CEST] <ubitux> without compiling and running an unreliable random kernel module found on github [18:27:38 CEST] <iive> ubitux: it would be useful to have start/stop that could work with arm [18:27:52 CEST] <ubitux> you can't [18:28:14 CEST] <ubitux> unless you use kernel API like i did, which requires various context stuff [18:28:30 CEST] <BBB> ok, cool [18:28:41 CEST] <ubitux> anyway, gtg [18:28:42 CEST] <BBB> I probably misunderstood the earlier comment, sorry about that [18:28:52 CEST] <BBB> cya [18:40:46 CEST] <TimothyGu> FYI https://patchwork.ffmpeg.org/ still uses the old StartSSL certs that's blocked by Chrome etc. [18:41:13 CEST] <BtbN> works for me [18:41:13 CEST] <TimothyGu> michaelni: ^^ [18:41:41 CEST] <TimothyGu> I'm using Chrome beta if that matters [18:42:11 CEST] <TimothyGu> but either way we should switch to let's encrypt, which ffmpeg.org already uses [18:43:05 CEST] <michaelni> TimothyGu, talk with reimar, he did setup the lets encrypt stuff [18:44:30 CEST] <TimothyGu> michaelni: is he in control of the patchwork server? [18:45:50 CEST] <TimothyGu> BtbN: curl https://patchwork.ffmpeg.org/ also fails on debian stable [18:48:01 CEST] <michaelni> TimothyGu, everyone with root access to the main server should have root access to patchwork [19:07:57 CEST] <cone-638> ffmpeg 03James Almer 07master:3ec6d9c6b297: avfilter: remove duplicate and disabled trace log function [19:38:03 CEST] <durandal_170> michaelni: i dont get simple horizontal only fft to match reference [19:38:17 CEST] <durandal_170> michaelni: do I need to padd with zeroes or what? [19:50:54 CEST] <cone-638> ffmpeg 03James Almer 07master:9aa24699302c: avcodec/internal: move FF_QSCALE_TYPE defines from avcodec.h [19:57:32 CEST] <BtbN> There is a bug somewhere in ffmpeg. When transcoding interlaced, from mkv to mkv. Input: Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first) Output: Stream #0:0(eng): Video: h264 (Main), yuv420p(top coded first (swapped)) [19:57:41 CEST] <michaelni> if the code doesnt pad with zeros then it likely needs to [19:57:56 CEST] <BtbN> If I transcode to .ts instead, it says (top first) on the output as well [19:58:05 CEST] <BtbN> So I guess something with the mkv muxer messes this up, somehow [19:59:19 CEST] <BtbN> It can't be the codec. It happens with both libx264 and nvenc. [19:59:27 CEST] <jamrial> BtbN: the field_order stuff is wrong atm, library wide [19:59:31 CEST] <jamrial> there's a patch in the ml [20:00:14 CEST] <BtbN> It works fine if I mux to ts [20:00:19 CEST] <BtbN> And is broken if I mux to mkv [20:04:22 CEST] <nevcairiel> thats because ts doesnt store any metadata whatsoever [20:06:25 CEST] <durandal_170> michaelni: see http://www.ft.unicamp.br/docentes/magic/khoros/html-dip/c5/s2/dft-w.gif of this I get only right half [20:06:34 CEST] <BtbN> The patch on the ML would not fix mkvenc though. It only changes some labels [20:16:01 CEST] <jamrial> BtbN: probably https://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=ccb6638e0a4140d1… then [20:16:42 CEST] <BtbN> Yes. Now that just looks plain wrong [20:17:00 CEST] <jamrial> source mkv is TT, ffmpeg.c changes it to TB [20:20:11 CEST] <durandal_170> atomnuker: simple horizontal fft should be symetrical, but it is not for me for some reason [20:24:43 CEST] <BtbN> jamrial, I wonder if that is just plain wrong then. And should be dropped [20:25:42 CEST] <BtbN> That AV_FIELD_TB/BT mode seems highly uncommon to me. [20:26:55 CEST] <jamrial> BtbN: i don't know, to be honest. commit dcbf72836c9 added it but without any explanation [20:28:11 CEST] <jamrial> send a patch to remove it, arguing it looks like weird heuristics [20:55:31 CEST] <BtbN> jamrial, or maybe the heuristic is reversed? [20:56:18 CEST] <jamrial> BtbN: i send a patch to reverse it. it wasn't popular [20:56:42 CEST] <jamrial> s/send/sent [20:57:22 CEST] <BtbN> The current version is clearly broken [20:59:54 CEST] <doublya> I need some help with multithreading scale_slice in vf_scale.c. I'm testing two with slices on two threads. I'm getting a seg fault from desc[i].process, I'm looking through the possible function that coule be assigned to function pointer process. [21:01:28 CEST] <wm4> wasn't this answered a few days ago? the answer is it can't and won't work [21:02:57 CEST] <doublya> are you talking to me? [21:04:32 CEST] <mobi> why come the fix in git? https://patchwork.ffmpeg.org/patch/4386/ [21:04:47 CEST] <mobi> why come the fix not in git? https://patchwork.ffmpeg.org/patch/4386/ [21:06:30 CEST] <wm4> doublya: yes [21:25:39 CEST] <wm4> if you want that, a reasonable way would be adding threading directly to libswscale [21:27:45 CEST] <durandal_170> wm4: slice threading is already in swscale [21:28:54 CEST] <wm4> well that makes it easier [21:29:31 CEST] <durandal_170> there was even gsoc project for it [21:44:05 CEST] <wm4> I guess vf_scale could do frame threading easily... is there libavfilter frame threading support? [21:45:13 CEST] <durandal_170> not yet [21:51:45 CEST] <doublya> wm4: I need slice threading per frame. It seems as vf_scale.c may have had though of line by line threading via scale_slice function. If you're suggesting threading libswscale, it seems to me that the for loop on line 370 of swscale.c would be a good place. [21:52:55 CEST] <doublya> I was thinking the SwsContext would be the only needed per thread when calling scale_slice (vf_scale.c) [21:54:10 CEST] <wm4> as durandal_170 is saying this already exists [21:54:23 CEST] <durandal_170> doublya: have you looked at sws_scale() in header? [21:56:15 CEST] <durandal_170> doublya: yes, you can parallelize with execute only if nb_slices is set [21:56:51 CEST] <durandal_170> note that it is marked currently for debug purposes only [21:57:13 CEST] <durandal_170> ask michaelni why, but you can test slice scaling already [22:01:45 CEST] <doublya> I'm just bypassing the if(scale->interlaced>0... block in vf_scale.c I'm threading with pthreads. Calling scale_slice from worker function on each p thread. testing with two threads. Seg fault happens in one of the functions in vscale.h .. the call to desc[i].process near the end of swscale function [22:05:11 CEST] <durandal_170> doublya: why? there is internal threading api. use that [22:06:55 CEST] <wm4> doublya: for the thousands time, it won't work and can't wolk [22:06:57 CEST] <wm4> work, even [22:08:10 CEST] <doublya> durandal_170: What are you suggesting exactly? [22:08:24 CEST] <doublya> wm4: Well I need it. So maybe I need to write my own filter. [22:11:01 CEST] <durandal_170> doublya: look at other filters, that call execute, they have own slice threading flag [22:11:46 CEST] <durandal_170> libavfilter/vf_yadif.c: ctx->internal->execute(ctx, filter_slice, &td, NULL, FFMIN(h, ff_filter_get_nb_threads(ctx))); [22:14:44 CEST] <kiroma> Does the `framerate` filter interpolate all frames from the input, or only two closest to interp_start/interp_end values? [22:17:41 CEST] <durandal_170> kiroma: iirc those parameters have nothing to do with how many frames will be used from input [22:20:32 CEST] <doublya> wm4: I looked at vf_yadif.c per durandal_170. Similar to what I'm doing already no? [22:23:28 CEST] <doublya> I'll test it out [23:49:12 CEST] <durandal_170> michaelni, atomnuker: i resolved bunch of issues switching to av_fft, now I keep getting output in only 2 quadrants, topleft and bottomright, 2 missing quadrants are overlayed over existing ones [23:56:26 CEST] <atomnuker> so 2 quadrants are correct and 2 look like what? [23:57:18 CEST] <durandal_170> atomnuker: i can get all quadrants, they are just overlaid onto each other [23:58:48 CEST] <atomnuker> overlaid? [00:00:00 CEST] --- Sat Sep 2 2017

1 0

ffmpeg.log.20170901
by burek 02 Sep '17

02 Sep '17

[00:07:30 CEST] <idlus> Hello, I have a basic question, I am applying a filter chain '[vid1] split [a][b]; [a] crop=... [a]; [b] crop=..., scale=-1:.6*ih, [a] overlay=0:main_h-overlay_h, scale=4/3*ih:ih' [00:09:44 CEST] <idlus> the resulting jpg file has dimensions 925x694 and a "density" parameter of 954x925 [00:10:39 CEST] <idlus> some viewers display at 925x694 while another (mpv) resizes at 954x694 [00:10:58 CEST] <idlus> What am I missing? [00:12:21 CEST] <damata> I'am Using ffmpeg + ffserver to stream audio from a input mic in my raspberry, on my pc i have almost 0 delay but when e play the stream in my phone (android) i have almost 2 seconds delay. Can i fix this and have better delay on my phone ? [00:14:50 CEST] <damata> iam using vlc in both pc and smartphone [00:45:59 CEST] <rhizome> hi all. i have a video where the video freeze-frames for some seconds. time continues, so it's not like the decode is hung or anything, just multiple duplicate frames. is there anything in ffmpeg that can detect (and hopefully remove) these frames? re-encoding is not a problem. [00:56:01 CEST] <rhizome> the alternate strategy i can think of is to manually step through frames, comparing each to its previous, using some language [01:05:33 CEST] <klaxa> rhizome: maybe you can use the decimate filter https://ffmpeg.org/ffmpeg-filters.html#decimate-1 [01:07:41 CEST] <klaxa> this drops at regular intervals though [01:19:25 CEST] <furq> !filter mpdecimate @rhizome [01:19:34 CEST] <furq> uh [01:24:01 CEST] <furq> !filter mpdecimate @rhizome [01:24:01 CEST] <nfobot> rhizome: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate [02:04:32 CEST] <thebombzen> does anyone know anything about the AV1 bitstream freeze? [03:16:53 CEST] <damata> I'am Using ffmpeg + ffserver to stream audio from a input mic in my raspberry, on my pc i have almost 0 delay but when e play the stream in my phone (android) i have almost 2 seconds delay. Can i fix this and have better delay on my phone ? i'am using vlc in both pc and smartphone [03:49:57 CEST] <rhizome> furq: klaxa perfect, thanks [09:51:27 CEST] <dystopia_> is there anyway to toggle flags on the fly? [09:51:34 CEST] <dystopia_> like -re [09:52:28 CEST] <Nacht> Define: on the fly [09:52:39 CEST] <dystopia_> while an encode is running [09:52:46 CEST] <Nacht> Why ? [09:52:48 CEST] <dystopia_> i hit a key to enable / disable -re [09:53:08 CEST] <dystopia_> because if im encoding from a live source, and im a far behind live i could disable it to catch up [09:53:27 CEST] <dystopia_> and when i get to a few seconds behind live, i would enable it, to prevent hitting the end of the file [09:53:36 CEST] <c_14> You shouldn't use -re with a live source anyway [09:53:53 CEST] <dystopia_> what would be the preferred method c_14? [09:54:02 CEST] <c_14> just without -re [09:54:10 CEST] <c_14> You can't read faster than realtime from a live source anyway [09:54:11 CEST] <Nacht> Yeah, -re is for when, for example, you have a VOD which you transmux to a stream [09:54:19 CEST] <dystopia_> no because then i encode faster than the source, hit the end of the file [09:54:24 CEST] <dystopia_> before the show has finnished [09:54:29 CEST] <c_14> Is your live source an actual file? [09:54:34 CEST] <dystopia_> and ffmpeg things it's over [09:54:39 CEST] <dystopia_> a tv show for example [09:54:43 CEST] <dystopia_> being written to a .ts file [09:55:10 CEST] <c_14> You want to feed ffmpeg the bytes as they're being written, not the file itself [09:55:37 CEST] <dystopia_> so if the show is 50fps, i use -re to encode at 50fps, which works well but it would be nice to toggle [09:55:59 CEST] <dystopia_> hmm im not sure i have the skills to code somthing to do that c_14 [09:56:11 CEST] <c_14> How is the show being saved to the .ts file? [09:56:38 CEST] <dystopia_> via dvb application called dvbviewer, it writes it to disk as .ts [09:56:54 CEST] <dystopia_> hadware is a bda capture device [09:56:59 CEST] <dystopia_> hardware* [09:58:16 CEST] <c_14> I'd probably get dvbviewer to write to a fifo then and let ffmpeg read from that [09:58:55 CEST] <c_14> Is this Windows or Linux? [09:59:28 CEST] <dystopia_> windows [09:59:30 CEST] <c_14> On windows you could probably use ffmpeg's dshow input to directly grab from the device and use that [10:00:03 CEST] <c_14> try `ffmpeg -f dshow -list_devices` [10:00:05 CEST] <dystopia_> i don't think that would be possible because i use plugins in dvbviewer to access my ca card to decrypt channels [10:00:20 CEST] <c_14> mhm [10:00:35 CEST] <dystopia_> it might with the fta stuff [10:00:52 CEST] <dystopia_> but im not sure who i would be able to tell ffmpeg which transponder to lock to [10:01:02 CEST] <dystopia_> and then which channel in the transponder to encode from [10:02:33 CEST] <dystopia_> Unrecognized option 'list_devices'. [10:02:33 CEST] <dystopia_> Error splitting the argument list: Option not found [10:07:48 CEST] <c_14> You might want to see if dvbviewer can output as a network stream which ffmpeg can listen on or try outputting to a Named Pipe somehow. Toggling -re is technically possible with the realtime filter, but would most likely require coding your own ffmpeg replacement [10:11:48 CEST] <dystopia_> ok, thank you for the info c_14 [10:11:53 CEST] <dystopia_> will do some research [11:32:57 CEST] <flux> so the packet.dts of first packet can be negative, but can the packet.pts be positive? [11:34:22 CEST] <BtbN> of course it can? [11:34:56 CEST] <flux> right, I was thinking if it might be somehow normalized to always be zero [11:34:59 CEST] <flux> thank you :) [11:35:16 CEST] <BtbN> I'm not sure I understand your question [11:35:35 CEST] <BtbN> them being positive is the normal. Being negative in the beginning is the exception [11:35:47 CEST] <flux> yes, normal, but I'm talking only about the first frame [11:35:51 CEST] <flux> can pts>0 in first frame? [11:36:08 CEST] <BtbN> I don't think pts need to start at 0 [11:36:20 CEST] <BtbN> neither do dts [11:36:35 CEST] <BtbN> depends on the container though [11:37:46 CEST] <flux> so I'm looking at an ISO MPEG4 file and the CompositionOffset of its first sample is 512 (in time scale units) [11:37:57 CEST] <flux> how av_read_frame doesn't say dts=0, pts=512? [11:38:24 CEST] <flux> (no edit list) [12:26:04 CEST] <borsh> Has anybody tried to stream to chaturbate.com? [12:26:42 CEST] <borsh> ffmpeg -i ... -f flv "$url token=$token" [12:27:01 CEST] <borsh> It works, the stream is getting accepted, no errors. [12:27:26 CEST] <borsh> But the video is not getting published. And the stream is offline on the site. [12:27:32 CEST] <borsh> Am I missing any extra rtmp flags? [12:36:38 CEST] <borsh> Nothing special in obs about this https://github.com/jp9000/obs-studio/blob/4c58dcf65c426eaa83541c8e752a01b18… [12:36:45 CEST] <borsh> But obs is intended to just work [12:51:06 CEST] <stevenliu> do you want publish stream to the rtmpserver? [12:51:15 CEST] <stevenliu> borsh: ? [13:14:47 CEST] <borsh> stevenliu: yes. [13:18:48 CEST] <hendry> hmm, i noticed the 1080p video i uploded to youtube is 3.8GB 1920x1080 [SAR 1:1 DAR 16:9], 15549 kb/s... but when i download from yt it's a 517mb 1920x1080 [SAR 1:1 DAR 16:9], 2381 kb/s [13:19:30 CEST] <hendry> so since i've trusted YT to keep a keep "an original" copy, I'm screwed right? [13:20:34 CEST] <klaxa> youtube never keeps originals [13:20:47 CEST] <klaxa> hasn't ever iirc [13:20:51 CEST] <borsh> hendry: `youtube-dl -F $url` [13:20:59 CEST] <borsh> hendry: it will show you the available formats [13:21:32 CEST] <borsh> hendry: vp9 could be pretty close to the original [13:21:57 CEST] <hendry> borsh: https://s.natalian.org/2017-09-01/1504264899_2548x1398.png [13:22:43 CEST] <hendry> borsh: can't see vp9... so I assume: "137 mp4 1920x1080 DASH video 4934k , avc1.640028, 30fps, video only" is better? [13:22:53 CEST] <hendry> borsh: video in question: youtube-dl -F https://www.youtube.com/watch?v=X0wTCckdUNI [13:22:57 CEST] <borsh> hendry: looks like you want 137 and 140 [13:23:32 CEST] <borsh> vp9 could appear later [13:24:15 CEST] <hendry> borsh: oh, wonder if youtube-dl can combine them to save the trouble [13:24:23 CEST] <hendry> borsh: very very useful info thank you [13:24:38 CEST] <borsh> hendry: ffmpeg could combine easily [13:24:41 CEST] <hendry> borsh: so i still have a good chance of recovering a new original i take it [13:25:35 CEST] <hendry> borsh: so i still have a good chance of recovering "a near" original i take it [13:26:08 CEST] <borsh> hendry: ffmpeg -i video07642530.mp4 -i audio76053249.m4a -c copy a-new-near-original.mkv [13:26:45 CEST] <borsh> hendry: notice you could probably use mp4 or nut or whatever instead of mkv for the output file [13:26:52 CEST] <borsh> depends on your needs or preferences& [13:33:46 CEST] <hendry> borsh: something that i can play back in the browser via a video element 😅 [13:37:47 CEST] <borsh> hendry: then you could use them as-is or try merging into mp4 or flv or mpegts [13:43:21 CEST] <borsh> stevenliu: looks like obs is not an option as it requires some unavailable on this hardware opengl features http://dpaste.com/2BF486J [13:43:31 CEST] <hendry> borsh: thanks again for taking the time [13:44:32 CEST] <hendry> ive stopped using obs. prefer to multicam edit bu taking ffmpeg capture + mp4 from canon in fcpx 10.3 [13:44:58 CEST] <borsh> hendry: ffmpeg works but I'm missing some extra rtmp flags [13:44:59 CEST] <borsh> ffmpeg -i ... -f flv "$url token=$token" [13:45:11 CEST] <borsh> hendry: the stream is getting accepted by the server but just not getting published [13:45:16 CEST] <borsh> I've tried setting live=1 [13:46:02 CEST] <borsh> hendry: what is the proper rtmp vo for chaturbate? [13:50:53 CEST] <borsh> hendry: I wanted to run obs for dicovering rtmp options using rtmpdump [13:50:54 CEST] <hendry> borsh: wat? haha, no idea. tested with twitch? [13:51:02 CEST] <borsh> hendry: twitch works. [13:51:22 CEST] <borsh> But twitch will ban me for the content I provide :D [13:51:22 CEST] <hendry> sorry, i have zero exp with live [13:51:43 CEST] <borsh> obs wants opengl 3.2 but the card only provides 2.0 [13:51:44 CEST] <hendry> borsh: going to assume the worst 😂 [13:51:47 CEST] <borsh> So it is failing to start. [13:53:31 CEST] <borsh> this is what I mean by live -> ffmpeg -i ... -f flv "$url token=$token live=1" [13:53:58 CEST] <borsh> I will return in half an hour [13:54:03 CEST] <borsh> hendry: good luck! [13:57:11 CEST] <damata> I'am Using ffmpeg + ffserver to stream audio from a input mic in my raspberry, on my pc i have almost 0 delay but when e play the stream in my phone (android) i have almost 2 seconds delay. Can i fix this and have better delay on my phone? Using vlc in both pc and smartphone [14:08:33 CEST] <stevenliu> borsh: ffmpeg -re -i input.mp4 -c copy -f flv rtmp://blablabla.com/live/stream can you give me a rtmpserver , let me try it :) [14:29:18 CEST] <borsh> stevenliu: rtmp://live.stream.highwebmedia.com/live-origin [14:29:51 CEST] <BtbN> stevenliu, can always use Twitch or YouTube [14:31:32 CEST] <stevenliu> I usually use my own rtmpserver .... [14:32:41 CEST] <borsh> hendry: what is multicam edit? [14:32:51 CEST] <stevenliu> borsh: what's your stream name? [14:33:00 CEST] <borsh> stevenliu: not sure what it is [14:33:11 CEST] <stevenliu> for example: rtmp://live.stream.highwebmedia.com/live-origin/streamname [14:33:16 CEST] <borsh> stevenliu: I only have the link and the stream token [14:33:20 CEST] <borsh> No stream name afaik [14:34:28 CEST] <BtbN> that token is most likely the name. [14:34:32 CEST] <BtbN> But it's private [14:35:24 CEST] <borsh> BtbN: token is used like this: ffmpeg -i ... -f flv "$url token=$token live=1" [14:35:36 CEST] <borsh> it is an rtmp option [14:35:59 CEST] <borsh> pass a wrong option to get the list of valid rtmp options [14:36:02 CEST] <stevenliu> I think the $url and $token is a var [14:36:46 CEST] <borsh> I provide both $url and $token vars but 'live=1' does not help to get the stream published [14:40:06 CEST] <borsh> hendry: stevenliu: more info: https://support.chaturbate.com/customer/portal/articles/2831439-external-en… [14:40:49 CEST] <borsh> I will try passing more random options heh [14:41:49 CEST] <stevenliu> Let me try to login in it :D [14:42:01 CEST] <stevenliu> maybe sex video, haha [14:42:09 CEST] <stevenliu> many sex video [14:44:18 CEST] <borsh> pubUser pubPasswd are interesting fields [14:52:53 CEST] <stevenliu> Ohho, it need my more information... [14:59:17 CEST] <borsh> stevenliu: these fields are accepted by ffmpeg via librtmp: http://dpaste.com/2CNT423 [15:00:20 CEST] <stevenliu> i know [15:00:31 CEST] <stevenliu> ffmpeg support these yet [15:00:48 CEST] <stevenliu> but i don't know how should i do [15:01:01 CEST] <stevenliu> i don't want share my more information to the site [15:02:01 CEST] <borsh> ok fixed obs with LIBGL_ALWAYS_SOFTWARE=1 [15:02:06 CEST] <borsh> now it thinks I have opengl 3 [15:02:14 CEST] <borsh> how do I rtmpdump what I'm streaming? [15:02:29 CEST] <borsh> I really want to get these rtmp options asap [15:03:56 CEST] <borsh> stevenliu: obs only need the token for streaming, no username or password [15:33:17 CEST] <borsh> stevenliu: obs now works [15:33:31 CEST] <borsh> I can stream and see the video is getting published [15:34:27 CEST] <borsh> How do I rtmpdump what I'm streaming now? :D [15:34:41 CEST] <borsh> I want to derermine these rtmp options!! [17:27:49 CEST] <borsh> I can't figure out how to use rtmpdump on my stream [17:36:27 CEST] <bigx> hello, Im trying to leverage hw encoding with some filter_complex [17:36:42 CEST] <bigx> but I when I do it, I see a 400% cpu usage [17:36:55 CEST] <bigx> so clearly noy HW accelerated [17:37:25 CEST] <bigx> how is filter_complex supported with nvenc? [17:44:00 CEST] <durandal_1707> bigx: only with hw filters you will get less cpu usage [17:44:46 CEST] <bigx> thanks durandal_1707 , do you know any hw overlay filter ? [17:44:53 CEST] <BtbN> There is none [17:48:18 CEST] <Fenrirthviti> Hmm. Does this actually test the hardware support, or is it just checking what the driver says? https://gist.github.com/Brainiarc7/c6164520f082c27ae7bbea9556d4a3ba [17:48:40 CEST] <Fenrirthviti> Context: Trying to find a simple way to actually test NVENC support on a given system. [17:49:11 CEST] <Fenrirthviti> Since many laptop GPUs are scale-downs that don't have NVENC support, even though the driver reports it does. When you try to encode anything, it just fails. [17:49:44 CEST] <BtbN> Fenrirthviti, it does not check anything. It only lists which npp|cuvid|nvenc|cuda encoders/decoders/filters ffmpeg was compiled with. [17:49:53 CEST] <Fenrirthviti> Drat, that's what I feared. [17:50:16 CEST] <Fenrirthviti> That's what we do now, and it's giving false positives for actual support and making for annoyed end users (and me, cause I have to hear about it) [17:50:28 CEST] <Fenrirthviti> Rather, we do something similar now I should say. [17:50:45 CEST] <borsh> Is it possible to use radeon gpu for speeding up x264 encoding or hqdn3d? [17:51:05 CEST] <BtbN> The x264 opencl support is rather minimal. Don't use it. In worse cases it can even make stuff slower. [17:51:09 CEST] <borsh> What is the filter name for chroma key? [17:51:11 CEST] <BtbN> And I have no idea what hqdn3d is. [17:51:16 CEST] <BtbN> chromakey. [17:51:28 CEST] <BtbN> Fenrirthviti, you'll need to actually try and decode/encode/filter something to be sure your set of parameters is supported. [17:51:36 CEST] <borsh> hqdn3d is a fine denoise thing [17:52:17 CEST] <Fenrirthviti> BtbN: I was afraid of that too, dangit. Thanks for clarifying. [17:52:38 CEST] <Fenrirthviti> nvidia's documentation is infuriatingly sparse. [17:52:38 CEST] <BtbN> The filters pretty much always work though, when there is a CUDA capable GPU [17:53:04 CEST] <borsh> is not it possible to run chromakey on gpu? [17:53:15 CEST] <BtbN> If someone were to write a CUDA version of it. [17:54:09 CEST] <borsh> Don't you also know how to rtmpdump the stream generated by obs? [17:54:16 CEST] <borsh> I'm trying to get the rtmp flags [17:55:29 CEST] <borsh> Because the stream generated by ffmpeg is not getting published and I'm trying to determine how it is different from obs one [17:57:41 CEST] <BtbN> you connect to the server with rtmpdump, and dump the stream? [17:59:13 CEST] <borsh> Probably not the option as the server is modifying the stream. [17:59:34 CEST] <bigx> if there is no hw overlay filter, I then wont be able to use gpu encoding, right? [17:59:47 CEST] <Fenrirthviti> borsh: You can't intercept the stream from OBS -> Server if that's what you're asking [18:00:11 CEST] <borsh> Should I use strace or something instead? [18:00:38 CEST] <borsh> I'm not sure how to derermine the rtmp options obs enables for the stream. [18:00:59 CEST] <Fenrirthviti> What are you actually trying to do here? [18:01:27 CEST] <borsh> I'm streaming to charutbate.com, the steam is getting accepted by the server but is not getting published. [18:01:38 CEST] <BtbN> obs sets the rtmp options you tell it to? [18:01:53 CEST] <borsh> BtbN: it only asks for the stream token [18:01:59 CEST] <Fenrirthviti> You should probably contact chaturbate support. They're pretty solid, very knowledgeable. [18:02:00 CEST] <borsh> It is the same option I set with ffmpeg. [18:02:11 CEST] <borsh> I think it is setting something else in addition [18:02:16 CEST] <BtbN> rtmp://server/endpoint_name/token [18:02:19 CEST] <BtbN> that's all OBS sets [18:02:35 CEST] <Fenrirthviti> well, not strictly true. [18:02:39 CEST] <BtbN> It has a seperate, read-protected box for the token though [18:03:08 CEST] <borsh> I thought it should be something like this: ffmpeg -i ... -f flv "$url token=$token" [18:03:18 CEST] <Fenrirthviti> OBS doesn't use ffmpeg for rtmp [18:03:22 CEST] <BtbN> seems like it's not [18:03:23 CEST] <Fenrirthviti> it uses librtmp [18:03:45 CEST] <borsh> librtmp allows ffmpeg to use 'token' rtmp option (and others) [18:03:53 CEST] <borsh> I'm trying to use ffmpeg and not obs [18:04:53 CEST] <Fenrirthviti> I know for an absolute fact that OBS works with chaturbate, I spent time working with them on it. [18:05:11 CEST] <borsh> obs works for me! [18:05:27 CEST] <borsh> I started trying obs when wanted to determine the rtmp options it uses [18:05:32 CEST] <Fenrirthviti> Ahhh, wait I understand here, sorry. [18:06:48 CEST] <borsh> BtbN: So should I try appending token to the url instead of using the rtmp option from librtmp? [18:07:20 CEST] <Fenrirthviti> you should be able to just do -f flv rtmp://host/app/token [18:07:52 CEST] <borsh> Fenrirthviti: already checked and it works! [18:07:55 CEST] <borsh> Thanks. [18:08:11 CEST] <borsh> -f flv "$url/$token" [18:08:30 CEST] <borsh> Looks like I don't even need librtmp. [18:08:43 CEST] <borsh> obs uninstall time! [18:08:55 CEST] <BtbN> an rtmp url is always rtmp://server/ingest_name/stream_name [18:09:03 CEST] <BtbN> if it's longer or shorter than that, it's wrong [18:09:39 CEST] <borsh> right, the $url is rtmp://live.stream.highwebmedia.com/live-origin [18:10:24 CEST] <azarus> Hey, I can't seem to be getting the vp8_vaapi or vp9_vaapi encoder to work. Here's what I tried: "ffmpeg -i in.mp4 -c:v vp8_vaapi out.webm" And here's the output: http://ix.io/zwZ [18:11:50 CEST] <BtbN> There is no vp9_vaapi encoder. [18:12:42 CEST] <jkqxz> azarus: It can only encode things which are already in GPU surfaces. See <https://trac.ffmpeg.org/wiki/Hardware/VAAPI> (the encoding section). [18:12:44 CEST] <BtbN> And for vp8, you need to set the hwaccel options, and/or insert an upload filter [18:13:00 CEST] <jkqxz> BtbN: Yes there is. [18:13:05 CEST] <BtbN> where? [18:13:16 CEST] <BtbN> I only see encode_vp8.c [18:13:35 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_vp9.c> [18:13:50 CEST] <jkqxz> Old version? [18:14:12 CEST] <azarus> Thanks, jkqxz, I'll try that. [18:16:46 CEST] <BtbN> What hardware even supports vp9 encoding? And how terrible is it? [18:17:21 CEST] <borsh> Which hardware to buy if I want to reencode a lot of videos fast with fine encoding quality? [18:17:37 CEST] <BtbN> Bunch of Threadripper-Servers [18:17:44 CEST] <BtbN> Or wait for Epyc, and then a bunch of those [18:18:05 CEST] <borsh> And which encoder will I use? [18:18:19 CEST] <jkqxz> BtbN: Kaby Lake (and then probably all future Intel). As hardware encode goes it's surprisingly not-completely-terrible, and obviously it wins epically on speed. [18:18:21 CEST] <BtbN> Depends on what codec you need [18:18:30 CEST] <borsh> Not sure on this one. [18:18:38 CEST] <jkqxz> Though obviously all normal caveats about hardware encoding apply. [18:19:47 CEST] <azarus> What's better for encode, an overclocked i5-6600K or a stock i7-2600? (Note the generational difference) [18:20:16 CEST] <BtbN> most likely the SKL I'd say, but hard to tell for sure without testing [18:20:26 CEST] <alexpigment> azarus: hardware or software? [18:20:32 CEST] <borsh> is H.264 good or should I try vp8/vp9? [18:21:04 CEST] <jkqxz> The 6600K will win by a long way. SMT is only a marginal benefit and everything else is in its favour (clock, memory speed, IPC, etc.). [18:21:56 CEST] <alexpigment> borsh: personally, H.264 is still a great codec, and its hardware support is way better than anything else at this point. I don't see any reason to switch to vp8/vp9 [18:22:11 CEST] <BtbN> license fees. [18:22:21 CEST] <alexpigment> that's a fair point [18:22:42 CEST] <borsh> The video is not getting sold [18:22:53 CEST] <alexpigment> still, i'd imagine someone trying to watch vp8 on a 4-year-old phone or tablet is not going to be a great experience [18:23:38 CEST] <BtbN> Not sure what the exact license terms are, but when you offer it publicly, you might have to pay. [18:23:52 CEST] <jkqxz> VP8 is not really useful for anything. VP9 is gaining quite a bit of traction now and does offer significant benefits, but it is still a pretty big pain on old devices. [18:24:13 CEST] <BtbN> YouTube technically also does not sell the videos. [18:24:15 CEST] <alexpigment> H.264 licensing is actually not bad. You have to go up to a certain amount of units before you have to pay. AAC on the other hand... [18:24:36 CEST] <jkqxz> BtbN: You need to sell a lot of units (100k?). And just streaming doesn't count, that has an exemption nowadays. [18:24:42 CEST] <azarus> I'm suprised how well cheap smartphones can handle FHD stream with no problem. [18:24:52 CEST] <BtbN> They all have hardware decoders. [18:24:53 CEST] <azarus> Also, in VP8. [18:25:04 CEST] <BtbN> And VP8 is rather cheap to decode on CPU as well [18:25:55 CEST] <jkqxz> There is still pretty much no reason to use VP8 over H.264 unless you are Google. [18:26:53 CEST] <alexpigment> still, vp9 hardware decoder just happened in the past few years [18:27:13 CEST] <alexpigment> like for nvidia, you have to have a 900 series card or above (which I do, but not everyone will) [18:27:19 CEST] <BtbN> Browsers are only very slowly starting to adopt it [18:27:31 CEST] <BtbN> And on Linux there is a lack of APIs [18:27:50 CEST] <alexpigment> I just feel like until the hardware support is ubiquitous, it's best to stick with H.264 [18:28:39 CEST] <alexpigment> Also, one thing I learned when trying to avoid licensing issues with AAC audio is that Apple products will not play sound from an MP4 with MP3 audio [18:28:50 CEST] <alexpigment> Even though MP4 technically supports it [18:29:03 CEST] <alexpigment> But if you rename it to F4V, Apple products will play the audio [18:29:19 CEST] <alexpigment> Greedy tactics, but whatever.. [18:35:02 CEST] <azarus> Yay, vp8_vaapi works for me! [18:35:12 CEST] <azarus> And with very fast speed :D [18:35:50 CEST] <BtbN> But probably very ugly quality [18:36:10 CEST] <azarus> I'll see, and probably i'll bump up the bitrate, [18:36:31 CEST] <BtbN> vp8 will need quite a lot of bitrate, specially when hw encoded [18:37:31 CEST] <jkqxz> Also make sure you have the recent driver (> 1.8.1ish?). The one before that was basically a placeholder and laughably terrible. [18:38:06 CEST] <azarus> jkqxz: The vaapi driver? [18:38:28 CEST] <jkqxz> Yeah. [18:39:02 CEST] <azarus> I have 1.8.3 [18:39:37 CEST] <jkqxz> Then you're good. [18:51:05 CEST] <azarus> Okay, vp8_vaapi is 12.5x faster, but produces 'okay' quality. [18:51:22 CEST] <azarus> Difference not perceptible to me as of now. [18:58:23 CEST] <alexpigment> BtbN: I figured out what's up with NVENC's interlaced handling btw. I was in the process of logging up a new issue and it seems that the fields are just reversed. if you bob deinterlace it, the motion jumps back and forth each frame (i.e. each field prior to bob deinterlace)) [18:59:37 CEST] <BtbN> If that's the case, just put a https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1857 in here. [18:59:45 CEST] <BtbN> a ! [19:00:13 CEST] <BtbN> Would seem weird though. The if looks correct [19:00:43 CEST] <alexpigment> a ! is some sort of reverse command? [19:01:13 CEST] <alexpigment> at any rate, now that I see where to make the change, I can test this on my own [19:01:16 CEST] <alexpigment> Thanks for the heads up [19:01:23 CEST] <BtbN> Just negates the condition [19:01:25 CEST] <alexpigment> I'll finish logging up the issue here in a bit [19:01:41 CEST] <alexpigment> Cool, thanks for confirming that [19:01:45 CEST] <BtbN> I'd call this a bug on nvidias end though, if this is the wrong way around. [19:02:15 CEST] <BtbN> Cause NV_ENC_PIC_STRUCT_FIELD_TOP_BOTTOM is definitely documented as top field first [19:02:23 CEST] <alexpigment> Well, I tested it in another application that does NVENC and it was correct. Maybe they're doing it backwards too [19:02:42 CEST] <alexpigment> Yeah, I'll make this change and confirm. There could be another problem in the pipeline [19:10:57 CEST] <nelder> hi guys, does anybody can help me to understand what does it mean when i play .m4a file wich was compressed from .flac by means of 'ffmpeg -i <file> -codec:a libfdk_aac -b:a 225K <result.m4a>'? [19:11:17 CEST] <nelder> i have this warning -> [lavf] Edit lists are not correctly supported (FFmpeg issue) [19:12:05 CEST] <nelder> when I listen original .flac-files I don't see this warning [19:49:57 CEST] <acos> Hi [19:50:16 CEST] <nelder> hi [19:50:54 CEST] <BtbN> alexpigment, are you using mkv by any chance, for your interlaced testing? [20:02:02 CEST] <alexpigment> BtbN: no, MP4 input and output [20:02:37 CEST] <BtbN> anyway, field ordering is broken globally in ffmpeg. nvenc is not at fault, it does its part correctly. And at least when muxing to mpeg-ts it works fine. [20:03:00 CEST] <alexpigment> then why does libx264 not suffer from the same problem? [20:03:10 CEST] <BtbN> It does [20:03:16 CEST] <alexpigment> Not in my tests [20:03:24 CEST] <alexpigment> But I just rebuilt, so I'll check again [20:03:39 CEST] <BtbN> I just tested it 5 minutes ago. No matter what encoder I use, it's equally broken everyhwere. [20:03:50 CEST] <alexpigment> I'll confirm your findings in 2-3 minutes [20:03:51 CEST] <BtbN> It's quite obvious with ffprobe [20:04:10 CEST] <BtbN> The input is Stream #0:0(eng): Video: h264 (High), yuv420p(top first), 1920x1080 [20:04:17 CEST] <BtbN> Output is Stream #0:0(eng): Video: h264 (Main), yuv420p(top coded first (swapped)) [20:04:51 CEST] <BtbN> That information that breaks it is purely in the muxer. h264 itself does not even carry that information. [20:06:09 CEST] <alexpigment> ok, so where's what I'm doing: [20:06:35 CEST] <alexpigment> (btw, I just retried in my newest rebuild, but I specified "prefer stable" [20:06:38 CEST] <alexpigment> no I'm not on a nightly [20:06:53 CEST] <BtbN> I'm only ever testing and comparing git master. [20:07:23 CEST] <alexpigment> ffmpeg.exe -i interlacedsample.mp4 -c:v libx264 -b:v 8000000 -pix_fmt yuv420p -flags +ilme+ildct -profile:v high -level 41 interlacedoutput.mp4 [20:07:42 CEST] <alexpigment> https://trac.ffmpeg.org/attachment/ticket/6260/interlacedsample.mp4 [20:07:55 CEST] <alexpigment> output is interlaced and as smooth as the original [20:08:57 CEST] <alexpigment> I also tried the change you suggested, and it still looks busted for nvenc [20:11:59 CEST] <BtbN> It looks completely fine to me, on both of them [20:12:06 CEST] <BtbN> No artifacts, no jumping, nothing [20:13:25 CEST] <alexpigment> is it possible you could post your interlaced sample somewhere so I can see it and do some investigating? [20:13:36 CEST] <BtbN> I'm using the same one. [20:13:42 CEST] <alexpigment> sorry [20:13:51 CEST] <alexpigment> sample of your interlaced output from nvenc [20:16:04 CEST] <BtbN> alexpigment, https://btbn.de/public/out.ts [20:16:44 CEST] <alexpigment> wow, that looks busted :) [20:17:18 CEST] <BtbN> It looks 100% correct to me. No idea what could possibly be busted there. [20:17:36 CEST] <alexpigment> You did see view the original, right? [20:17:46 CEST] <alexpigment> The motion should be as smooth as 1080p60 [20:17:51 CEST] <BtbN> It is [20:18:16 CEST] <alexpigment> Not over here at all [20:18:35 CEST] <alexpigment> This might as well be 1080p30 [20:19:08 CEST] <BtbN> No idea what you are seeing there [20:19:16 CEST] <BtbN> If I play them in parallel, it looks 100% identical [20:19:30 CEST] <alexpigment> Is your player properly deinterlacing to 1080p60? [20:19:39 CEST] <BtbN> Yes, using yadif2x [20:19:44 CEST] <Fenrirthviti> Plays perfectly smooth for me as well, in both vlc and mpc-hc [20:20:06 CEST] <alexpigment> I'm going to try Kodi just to triple check this [20:21:14 CEST] <alexpigment> Weird. Kodi plays it smooth too. I'm confused why VLC and WMP don't on my end (and do for the x264 version) [20:21:52 CEST] <BtbN> VLC plays it just fine for me as well [20:22:01 CEST] <BtbN> In Auto-Deinterlace-Mode, with Yadif2x as deinterlacer [20:22:08 CEST] <alexpigment> Yeah I did that [20:22:12 CEST] <alexpigment> And then tried Bob as well [20:22:24 CEST] <BtbN> And WMP is just trash [20:23:04 CEST] <alexpigment> WMP is better than VLC for interlaced content [20:23:07 CEST] <alexpigment> Which is why I use it often [20:23:19 CEST] <BtbN> My general advice for interlaced content is to not use it. [20:23:52 CEST] <BtbN> But my overall conclusion about this is that the nvenc side of interlaced encoding is just fine. And ffmpeg is doing something weird the field ordering. [20:23:55 CEST] <alexpigment> BtbN: I deal with interlaced content daily. It's the primary format for broadcast and the closest you'll get to 1080p60 on Blu-ray [20:24:06 CEST] <alexpigment> I'm doing some tests on hardware players now [20:24:26 CEST] <BtbN> The primary format is bad then [20:25:04 CEST] <alexpigment> Not sure what you mean by that [20:27:26 CEST] <alexpigment> oh duh [20:27:28 CEST] <alexpigment> I see the problem ehre [20:27:30 CEST] <alexpigment> *here [20:27:40 CEST] <alexpigment> You didn't make a proper 1080i30 file [20:27:47 CEST] <alexpigment> You made a 60fps video that's interlaced [20:27:55 CEST] <alexpigment> That's why it looks all janky [20:28:24 CEST] <BtbN> Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc [20:28:26 CEST] <BtbN> no I didn't. [20:29:03 CEST] <alexpigment> I know you hate when people talk about MediaInfo, but why does MediaInfo say this? [20:29:30 CEST] <BtbN> no I didn't. [20:29:32 CEST] <BtbN> It's probably showing you the field rate. Which is indeed 59.94 [20:29:46 CEST] <alexpigment> It never shows the field rate in place of the frame rate [20:30:26 CEST] <alexpigment> Somewhere in the stream is a flag that's saying it's 59.94 [20:30:39 CEST] <alexpigment> let me hexedit it [20:30:54 CEST] <BtbN> 59.94 tbc [20:31:18 CEST] <alexpigment> what does the x264 variant say for the tbc? [20:32:09 CEST] <BtbN> the same [20:32:18 CEST] <BtbN> tbc is the timebase [20:32:30 CEST] <alexpigment> And it plays just fine over here and is reported correctly in MediaInfo [20:32:39 CEST] <alexpigment> so it's not the tbc and it's not the field rate [20:32:57 CEST] <alexpigment> there's something else here that is causing some plays to play/read the file incorrectly [20:33:06 CEST] <BtbN> analyze wise, the files look 100% identical to me [20:33:44 CEST] <alexpigment> I don't doubt it. But I'm going to keep looking for the problem [20:33:47 CEST] <BtbN> https://btbn.de/public/out_x264.ts [20:33:51 CEST] <alexpigment> Because this is not compliant [20:34:16 CEST] <BtbN> There is also this: https://github.com/FFmpeg/FFmpeg/commit/dcbf72836c90d077067248a0ddc4e4c7556… [20:34:29 CEST] <BtbN> I'm pretty sure this is the main culprit for when using mp4/mkv/anything that's not ts [20:34:34 CEST] <alexpigment> Your x264 sample doesn't show frame rate values because it's VFR, but that's not a problem [20:34:49 CEST] <BtbN> It's mpegts [20:34:56 CEST] <BtbN> it only has timestamps [20:35:19 CEST] <BtbN> No idea where you are getting those readings from. They seem dubious to me [20:35:23 CEST] <alexpigment> BtbN: I understand what you're saying. I'm just looking at it in the tools at my disposal [20:35:33 CEST] <alexpigment> So MediaInfo is reporting it wrong, but also WMP and VLC are playing it wrong [20:35:47 CEST] <alexpigment> So whatever MediaInfo is reading is spilling over into real-world playback issues [20:35:52 CEST] <alexpigment> And that is my primary concern here [20:36:00 CEST] <BtbN> Are you re-muxing it to mp4, or how are you reading it? [20:36:07 CEST] <alexpigment> You can be a developer and say it's right, but I'm telling you that it's not right based on results [20:36:16 CEST] <alexpigment> I'm playing the ts in VLC [20:36:35 CEST] <alexpigment> I remuxed to TS with Tsmuxer and also remuxed to MP4 with ffmpeg, just to check [20:36:54 CEST] <alexpigment> all files show the frame rate as 59.94 in MediaInfo, and fail in the two players mentioned [20:37:06 CEST] <alexpigment> the x264 version plays just fine in all players and mediainfo reports it correctly as 29.97 [20:37:31 CEST] <alexpigment> (well, mine reports it as 29.97 at least, but I'm going straight to mp4 on my end via ffmpeg) [20:37:46 CEST] <alexpigment> your x264 just says the rate is variable [20:37:53 CEST] <alexpigment> but it plays fine, I presume it is actually 29.97 [20:38:39 CEST] <BtbN> it's mpegts. It's always "variable" framerate [20:38:43 CEST] <BtbN> as with a lot of other containers [20:39:17 CEST] <alexpigment> you're focusing on this aspect and it's unimportant [20:39:20 CEST] <alexpigment> the x264 file is fine [20:40:58 CEST] <BtbN> The biggest difference I see is that x264 stores it as a single interlaved frames, with mbaff coding [20:41:04 CEST] <BtbN> While nvenc uses seperate fields [20:41:04 CEST] <alexpigment> Right [20:41:17 CEST] <alexpigment> But I've got other separate fields files from cameras that are fine, fwiw [20:41:28 CEST] <alexpigment> Any AVCHD camera stores it that way these days [20:49:41 CEST] <BtbN> Whatever it is, it's not something the nvenc API gives any control over. [20:50:10 CEST] <BtbN> The things that can be set are all set correctly [20:50:30 CEST] <BtbN> The one questionable thing is the framerate. But it doesn't seem to matter, as container framerate overrides it anyway. [20:50:44 CEST] <BtbN> At least just plain commenting it out or setting bullshit does not have any visible effect [20:50:56 CEST] <alexpigment> Yeah, I'm still doing some investigating over here [20:51:14 CEST] <alexpigment> There's a nuanced bug here, regardless of what ffprobe is showing you [20:59:58 CEST] <alexpigment> ok, so I demuxed the two streams, put them back into mp4 with silent aac audio (just so my players can all deal with it). I ffprobed them both [21:00:08 CEST] <alexpigment> the x264 says r_frame_rate=30000/1001 [21:00:18 CEST] <alexpigment> the nvenc says r_frame_rate=60000/1001 [21:00:37 CEST] <alexpigment> the streams are untouched [21:01:39 CEST] <alexpigment> also the nvenc says the avg_frame_rate is 72000000/1202503 [21:01:47 CEST] <alexpigment> ~59.875 [21:04:31 CEST] <BtbN> https://btbn.de/public/out_test.ts this is with nvenc and the framerate artificially halved. [21:04:49 CEST] <BtbN> It's still stuttering in WMP for me, so I doubt that's the issue [21:04:57 CEST] <alexpigment> looks very bad over here [21:05:23 CEST] <BtbN> I suspect it's something weird in the h264 bitstream [21:05:35 CEST] <BtbN> Which is completely out of anyones but nvidias control [21:05:45 CEST] <alexpigment> does r_frame_rate get defined in the stream or in the container? [21:05:56 CEST] <BtbN> I have no idea what r_frame_rate is [21:06:18 CEST] <alexpigment> I'm going to do a comparison with staxrip again, just to make sure their nvenc implementation is still working correctly [21:06:32 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c;h=1220ae4… I stuck a *2 in there to get the halved framerate [21:06:57 CEST] <alexpigment> Yeah, that doesn't seem like it addresses the issue here [21:07:10 CEST] <BtbN> yep, so it's not the framerate that's the issue [21:07:19 CEST] <BtbN> I even made a sample where I set it to 65k FPS [21:07:37 CEST] <BtbN> still plays fine in VLC, and stutters the same in WMP. So the in-bitstream framerate is just entirely ignored, like it should [21:07:43 CEST] <alexpigment> sorry, work is calling. be back in a second [21:07:49 CEST] <BtbN> The container timestamps are what matters [21:11:02 CEST] <doux> Question about terminology: Does a single packet from a stream contain one encoded frame? Or in the case of stereo audio two encoded frames? [21:11:49 CEST] <DHE> an AVPacket should contain a single encoded video frame or a all audio channels from single period of time. again encoded [21:12:05 CEST] <doux> DHE: thank you [21:12:14 CEST] <DHE> but I suppose there's no guarantees. the content really should go to a decoder and it will provide the data properly to you [21:12:35 CEST] <doux> DHE: right, just want to understand how data is stored. [21:13:48 CEST] <DHE> an AVPacket gets decoded into an AVFrame which will contain exactly 1 video frame or exactly N samples from all channels of the audio. it's just that as I understand it all codecs do basically 1:1 mappings here [21:14:29 CEST] <doux> DHE: each channel is in its own frame right? [21:14:35 CEST] <doux> DHE: audio channel [21:14:59 CEST] <DHE> no. an AVFrame contains an array of pointers and each channel maps to one array slot [21:15:15 CEST] <DHE> unless the stored format is planar [21:15:21 CEST] <DHE> or do I have that backwards [21:16:23 CEST] <doux> DHE: all the channels for that time period as stored in a single frame then? [21:17:43 CEST] <doux> i think that's what you said already. nevermind. [21:19:37 CEST] <doux> DHE: thanks for the help [21:19:40 CEST] <DHE> keep in mind said time period is usually fractions of a second [21:19:53 CEST] <doux> DHE: ok [21:46:06 CEST] <kinkinkijkin> blugh, I'm on arch, trying to do a full system update, and this comes along [21:46:07 CEST] <kinkinkijkin> ffmpeg-git: installing x265 (2.5-1) breaks dependency 'libx265.so=116-64' [21:46:52 CEST] <kinkinkijkin> completely stops me from being able to update my system and I don't know what package is pulling x265 2.5-1 nor why ffmpeg-git requires a very specific (and seemingly old) version of x265 [21:47:32 CEST] <kinkinkijkin> issue on the arch package maintainers' side? [22:19:51 CEST] <acos> Sup [23:03:45 CEST] <Martchus> kinkinkijkin: ffmpeg-git is an AUR package which you likely built and installed using some AUR helper. You need to rebuild the package against the latest x265. [23:05:08 CEST] <Martchus> kinkinkijkin: So this is not an Arch package issue. It is just your old custom package. [23:09:30 CEST] <kinkinkijkin> oh nice I have to force install stuff [23:26:41 CEST] <kinkinkijkin> Martchus, built it with latest x265, it didn't install [23:28:22 CEST] <Martchus> kinkinkijkin: You should not force the installation. The correct way of building packages is in a current, clean chroot using makechrootpkg. [23:29:31 CEST] <kinkinkijkin> this is the only time I've seen this recommended to anyone, ever, in all of my 5 years running unixlikes fulltime [23:29:55 CEST] <Martchus> kinkinkijkin: Do you get the same error with the new ffmpeg-git package or a different error? If you get the same error, I doubt at the current x265 was present at build time. [23:30:49 CEST] <kinkinkijkin> no, I didn't get an error last time at build time, this time I got an error after installing saying that the dependency of x265:116-64 was not present [23:33:02 CEST] <Martchus> kinkinkijkin: Ok, so still the same error at install/upgrade time. [23:33:32 CEST] <Martchus> kinkinkijkin: And building in a clean chroot is really the way, checkout the Wiki https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chro… [23:34:02 CEST] <Martchus> kinkinkijkin: Other distros do the same, eg. osc build under suse also uses a chroot. [23:36:03 CEST] <kinkinkijkin> the build succeeded so, I'm thinking it's just a bad package like I expected before [23:36:44 CEST] <kinkinkijkin> so I'll fix the package before build and build it again [23:38:12 CEST] <kinkinkijkin> package isn't broken [00:00:00 CEST] --- Sat Sep 2 2017

1 0

ffmpeg-devel.log.20170831
by burek 01 Sep '17

01 Sep '17

[02:50:12 CEST] <cone-463> ffmpeg 03James Almer 07master:027c682fa079: avfilter/vf_mcdeint: remove usage of deprecated AVCodecContext.me_method [02:53:37 CEST] <cone-463> ffmpeg 03Martin Vignali 07master:2fcf47e2d175: fate/pixlet : add test for rgb [03:46:07 CEST] <cone-463> ffmpeg 03James Almer 07master:6e131a7cd970: ffmpeg_opt: add proper deprecation guards to lowres code [03:57:11 CEST] <rpw> I need more performance from vf_format. The first thing I noticed is that it's not threaded. I'm looking at vf_curves.c for an example of a threaded video filter; however vf_format.c doesn't have a filter_Frame function so I'm not sure where to start. [04:05:39 CEST] <durandal_170> rpw: format uses swscale or scale [04:13:09 CEST] <rpw> Thanks. Checking now [04:17:32 CEST] <kepstin> rpw: the 'format' filter itself doesn't do anything itself, it just sets allowed formats at a specific point in the stream. Usually (but not always) this means a 'scale' filter is auto-inserted to convert to an allowed format. [04:19:13 CEST] <rpw> thanks. Is there any WIP on threading swscale? [04:29:27 CEST] <cone-463> ffmpeg 03James Almer 07master:b34c16a38d3e: fate/flvenc: set bitexact output format flag explicitly [09:55:29 CEST] <JEEB> > feeding 960 samples to the AAC encoder [09:55:31 CEST] <JEEB> them artifacts [10:49:13 CEST] <wm4> I wonder what akamai needs decklink for [10:57:35 CEST] <JEEB> wm4: I would guess they offer services for customers that include that part [10:59:24 CEST] <wm4> hm, live streams? [10:59:32 CEST] <wm4> and stuff like that... could make sense [11:04:59 CEST] <JEEB> so the audio frame size stuff... should that be handled by avfilter or avcodec? I guess avcodec since it knows the frame size required? [11:05:31 CEST] <JEEB> and the push/pull mechanism already gives you the way to say "no, feed me more" or request multiple packets one after another without feeding [11:05:54 CEST] <JEEB> because I'm not sure if all clients should be required to re-invent the audio buffering wheel ^^; [11:06:08 CEST] <wm4> yeah we could handle that in libavcodec to make the API easier [11:06:19 CEST] <wm4> but currently you're supposed to feed the frame sizes the encoder expects [11:06:22 CEST] <JEEB> yea [11:06:36 CEST] <wm4> libavfilter can do that (there's a function to request a specific number of how many samples you want) [11:06:56 CEST] <JEEB> oh? [11:07:06 CEST] <JEEB> I tried looking at the audio buffer/sink ones but I must have missed it [11:07:37 CEST] <wm4> maybe av_buffersink_set_frame_size [11:07:37 CEST] <JEEB> any grep'able keywords? [11:07:41 CEST] <JEEB> k [11:07:50 CEST] <wm4> also av_buffersink_get_samples [11:07:58 CEST] <wm4> not sure which one you're supposed to use lol [11:08:32 CEST] <JEEB> lol [11:09:26 CEST] <JEEB> ffmpeg.c only uses the former [11:09:28 CEST] <JEEB> so I will go with that [11:28:41 CEST] <nevcairiel> av_buffersink_get_samples generally works better, because set_frame_size needs to be called pretty early and if the graph pushes samples before you call it, its a bad situation =p [11:29:26 CEST] <nevcairiel> while get_samples just doesnt care, you could request a different amount every call [11:29:35 CEST] <wm4> sounds like a bad implementation rather than an API problem [11:30:24 CEST] <nevcairiel> avfilter is a bad implementation [11:30:27 CEST] <nevcairiel> but what can you do [11:31:55 CEST] <wm4> is directshow better? [11:34:07 CEST] <nevcairiel> at least its a defined interface anyone can plug their own filters in, but it definitely has its own problems [11:36:46 CEST] <BtbN> DirectShow is painful [11:39:26 CEST] <rcombs> keep in mind that the decklink stuff can interface with a bunch of other blackmagic hardware too [11:42:34 CEST] <durandal_1707> anybody of you know how lens blur works? [11:43:22 CEST] <durandal_1707> looks like nobody [11:51:38 CEST] <cone-187> ffmpeg 03Tobias Rapp 07master:b7101151b36c: fate: add tests for some video source filters [12:10:23 CEST] <atomnuker> durandal_1707: a chromatic abberation filter would be great though [12:12:21 CEST] <durandal_1707> atomnuker: patch welcome [12:13:08 CEST] <atomnuker> that I can do [12:14:02 CEST] <durandal_1707> how? [12:14:39 CEST] <durandal_1707> im writting generic video convolver [12:15:12 CEST] <atomnuker> the filter? its simple to model. how? by writing it today [12:15:17 CEST] <atomnuker> I had the entire week off [12:55:39 CEST] <atomnuker> actually this is a lot harder than I thought it would be [12:55:45 CEST] <atomnuker> much easier in shaders though [12:58:07 CEST] <atomnuker> and I have all this vulkan boilerplate lying around, and we don't need jit shader compilation [13:12:39 CEST] <rcombs> <atomnuker> the filter? its simple to model. how? by writing it today [13:12:40 CEST] <rcombs> <atomnuker> actually this is a lot harder than I thought it would be [13:12:43 CEST] <rcombs> is this a record [13:12:51 CEST] <rcombs> how long between those lines :P [13:13:06 CEST] <rcombs> atomnuker: gonna try to sell the tech to kyoani? [13:14:59 CEST] <atomnuker> 40 minutes BUT I ate a pizza and a chocolate and drank 2 litres of water and I only wrote some boilerplate [13:15:18 CEST] <atomnuker> to anyone wanting to go to cornwall ever: don't [13:15:29 CEST] <iive> what's that? [13:15:52 CEST] <atomnuker> most southwest point of england [13:16:59 CEST] <atomnuker> complete list of things to do: take the sleeper train from london, smell the sea, vomit, see st. michael's mount, eat fish and chips and return back on the train with sore feet, dehydration and sleep depravation [13:17:25 CEST] <rcombs> sleeper trains are cool, at least [13:17:47 CEST] <nevcairiel> cant be all that cool, you sleep through the experience [13:17:57 CEST] <atomnuker> yep, this one was awesome, its known as the night riviera, one of only 2 sleeper trains in the uk running today [13:18:19 CEST] <rcombs> nevcairiel: cool in the way that long-haul business-class plane seating is cool [13:18:32 CEST] <rcombs> i.e. you _can_ sleep through the experience, reasonably comfortably [13:19:00 CEST] <atomnuker> even better, you have your own coupe [13:19:12 CEST] <atomnuker> and its much much quieter than a plane [13:22:34 CEST] <atomnuker> what does the vld in videotoolbox_vld stand for? [13:23:49 CEST] <kurosu> sleep depravation, that sounds kinky and interesting [13:25:06 CEST] <iive> i'm more amazed that the train takes a whole day [13:25:20 CEST] <atomnuker> in a passenger train full of screaming kids in the quiet car? I was just jetlagged [13:25:26 CEST] <iive> are they still using steam engine? [13:25:43 CEST] <atomnuker> it takes 8 hours if you take the sleeper train, 5.5 hours if you take the non-sleeper train [13:26:11 CEST] <atomnuker> iive: only on some journeys [13:26:38 CEST] <atomnuker> (and not the night riviera) [13:27:25 CEST] <rcombs> britain is about US-level in terms of high-speed rail, isn't it? [13:27:28 CEST] <rcombs> (i.e. "no") [13:28:05 CEST] <kurosu> iirc, they have been mostly discontinued in fr, like <10 lines remaining (if not 4 iirc) [13:28:23 CEST] <kurosu> (sleeper train) [13:28:48 CEST] <rcombs> is that because france actually has high-speed rail, so it's fast enough that you don't need to sleep on it [13:28:55 CEST] <rcombs> or is that just germany [13:29:31 CEST] <rcombs> meanwhile japan's putting in a 500km/h maglev line [13:29:36 CEST] <nevcairiel> we still have sleeper trains here, but they often go internationally [13:29:49 CEST] <nevcairiel> like from northern germany to vienna or something like th at [13:29:54 CEST] <kurosu> not for every direction and you often need to change trains for some of them, because these faster lines have only a few destinations [13:30:12 CEST] <rcombs> and the hyperloop people somehow expect me to be impressed by 320kph [13:30:17 CEST] <kurosu> sleeper trains are supposed to be an experience [13:30:21 CEST] <rcombs> I mean, that's great by US standards [13:31:00 CEST] <rcombs> but how the hell do you build a whole evacuated-tube system with 1-car trains and still not go as fast as proper trains at 1atm [13:32:37 CEST] <iive> rcombs: i think that these speeds are only because they don't have big enough track [13:32:38 CEST] <kurosu> evacuated or vacuumed or? both sounds weird [13:33:27 CEST] <iive> rcombs: aka, they don't be able to stop on time. [13:33:40 CEST] <iive> wont [13:33:58 CEST] <rcombs> well maybe one day they'll build a proper test track and give me some numbers that are actually impressive [13:34:21 CEST] <rcombs> but in the meantime they just look dumb, announcing speed records that are slower than real trains [13:34:34 CEST] <rcombs> also what's up with this whole 1-car concept [13:35:49 CEST] <atomnuker> reminds me how years ago the soviets planned an underground train from moscow to st. petersburg [13:36:13 CEST] <atomnuker> built in a straight line e.g. not following the curve of the earth and being at a constant depth [13:36:18 CEST] <atomnuker> because then they [13:36:25 CEST] <rcombs> uh [13:36:25 CEST] <atomnuker> 'd need no power to run it [13:36:34 CEST] <rcombs> &that's not how this works [13:36:36 CEST] <nevcairiel> rcombs: not sure how you can call the maglev a real train though, its a decade away from actually being in service [13:36:40 CEST] <rcombs> that's not how any of this works [13:36:43 CEST] <wm4> how much is the curvature of the earth over such a distance? [13:36:52 CEST] <rcombs> nevcairiel: I mean trains with proper cars [13:37:15 CEST] <rcombs> as opposed to tiny round pods [13:37:27 CEST] <atomnuker> probably enough to cancel gravity contribution and make it zero-g [13:37:54 CEST] <rcombs> nobody tell them about resistive forces [13:37:57 CEST] <durandal_1707> im trying to do 2d fft with code from fftfilt filter [13:38:14 CEST] <rcombs> by that logic no train needs power once it's up to speed [13:38:27 CEST] <atomnuker> rcombs: https://en.wikipedia.org/wiki/Gravity_train [13:38:31 CEST] <rcombs> nevcairiel: also apparently they're considering having a demonstration track running in 2020 [13:38:34 CEST] <nevcairiel> the problem with such high speeds eventually becomes acceleration and decceleration anyway, you can't really accelerate much f aster at some point because of the G forces, and as such the length of the track decides your average speed [13:38:52 CEST] <rcombs> yeah, acceleration on the maglev is like .1g [13:39:06 CEST] <rcombs> which is just about nothing [13:39:28 CEST] <rcombs> atomnuker: "ignoring the effects of friction" [13:40:41 CEST] <atomnuker> eh, put a small rocket engine at the back [13:40:55 CEST] <atomnuker> fixed things in ksp [13:41:03 CEST] <durandal_1707> how i should multiply re and im stuff after i get vertical rdft pass? [13:41:32 CEST] <atomnuker> for a 2d rdft? [13:44:04 CEST] <iive> rcombs: well, musk now has a boring machine and he could be boring wherever he wants. [13:45:31 CEST] <wm4> oh no, who gave him this!? [13:45:45 CEST] <wm4> imagine what things he'd be boring [13:46:35 CEST] <stevenliu> :D [13:49:33 CEST] <durandal_1707> atomnuker: yes 2d rdft, doing generic convolver which can do lens blur among other stuff [14:02:17 CEST] <atomnuker> I think its separable so you should just run it horizontally [14:06:12 CEST] <durandal_1707> what that means? i must multiply in complex domain input and kernel [14:08:33 CEST] <atomnuker> separable means if you apply it separately to the vertical and horizontal it'll produce a transform of the entire 2d input [14:10:00 CEST] <atomnuker> hm, not sure how that works if your transform does a real -> complex [14:25:23 CEST] <durandal_170> atomnuker: see http://www.jhlabs.com/ip/FFT.java [14:25:42 CEST] <durandal_170> and http://www.jhlabs.com/ip/LensBlurFilter.java [14:25:55 CEST] <durandal_170> trivial stuff [14:29:23 CEST] <durandal_170> and my code: https://github.com/richardpl/FFmpeg/blob/adefda3e4b679547971c56d1fd0c3c473c… [14:31:00 CEST] <atomnuker> oh, its not on a square block, not sure how that'd work then [14:31:06 CEST] <atomnuker> maybe ask in #daala [14:31:32 CEST] <durandal_170> atomnuker: i'm doing it on square block [14:32:15 CEST] <durandal_170> with this http://www.johnloomis.org/ece563/notes/restoration/linblur/h.jpg [14:32:41 CEST] <durandal_170> one should get nice linear blur with 256x256 input png [14:36:07 CEST] <durandal_170> for input: https://0x0.st/5g5.png i get this: https://0x0.st/5gR.png [14:37:48 CEST] <durandal_170> michaelni: can vf_fftfilt.c fft code be reused for generic convolution of 2 images? [15:42:48 CEST] <durandal_170> atomnuker: no ideas? [15:45:34 CEST] <atomnuker> no ideas, the code looks fine [16:28:39 CEST] <cone-910> ffmpeg 03James Almer 07master:1291a6d0ff9a: avcodec/fits: add missing header includes [16:34:10 CEST] <cone-910> ffmpeg 03Justin Ruggles 07master:1a0d9b503d2e: avformat/concatdec: add fallback for calculating file duration [17:49:28 CEST] <BtbN> My new Ryzen arrived. Time to torture it [17:49:51 CEST] <BtbN> Immediate observation: Under full load, it easily runs 7°C cooler. [18:01:50 CEST] <Fenrirthviti> BtbN: Make sure you update BIOS before going too hard so you don't run into microcode crashes :) [18:02:18 CEST] <BtbN> I'm not aware of any Microcode-Crashes on Ryzen [18:02:31 CEST] <BtbN> There was one weird instance with running old 16 bit DOS code that crashed [18:02:39 CEST] <BtbN> but that's fixed [18:08:20 CEST] <Fenrirthviti> We see x264 crash all the time on early Ryzen CPUs without bios updates due to it [18:12:21 CEST] <Fenrirthviti> Seems to be related to high-load scenarios, mostly on the linux side from what I've seen. [18:31:45 CEST] <Fenrirthviti> BtbN: https://www.digitaltrends.com/computing/ryzen-amd-bios-fix-fma3-crash/ here we go, this is what I was talking about [18:31:51 CEST] <Fenrirthviti> if you're curious at all [18:40:42 CEST] <doublya> got a simple question. When I add -vf "filter=nv12" as a ffmpeg CIL flag, where in the source code is the call to sws_scale? [18:47:38 CEST] <durandal_170> atomnuker: i get completly wrong magnitude/modulus of impulse in output [18:47:58 CEST] <jkqxz> doublya: I assume you mean format=nv12? Here: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_scale.c;h=332…>. [18:48:06 CEST] <durandal_170> it should be completely white frame, but I get stripes [18:48:37 CEST] <doublya> jkqxz: sorry yes, that's what I mean. Thanks I'll take a look [18:56:49 CEST] <atomnuker> durandal_170: stripes? stride issue? [19:00:32 CEST] <durandal_170> atomnuker: https://0x0.st/5EF.png [19:05:31 CEST] <atomnuker> weird, looks like a stride issue [19:05:51 CEST] <atomnuker> how about this: do the transform only in one dimension [19:06:11 CEST] <atomnuker> it should blur but only in one dimension [19:52:59 CEST] <BtbN> Fenrirthviti, that's an actual hardware fault [19:53:03 CEST] <BtbN> the fma3 but is long fixed [19:53:13 CEST] <atomnuker> jkqxz/wm4: what's the difference between sw_format and hw_format [19:53:35 CEST] <BtbN> This CPU here seems fine now. I just stressed it with a highly crashy workload for 2 hours. No errors [19:53:46 CEST] <atomnuker> (as used in AVHWFramesContext) [19:54:15 CEST] <atomnuker> is it there because some hw apis can do conversion between sw and hw formats? [19:54:39 CEST] <atomnuker> (when its uploaded/downloaded) [19:54:57 CEST] <BtbN> hw_format could be CUDA, and sw_format NV12 [19:55:07 CEST] <BtbN> When inside the CUDA frame there is NV12 pixel data in GPU memory [19:55:21 CEST] <BtbN> And it's similar for most hwaccels [19:55:46 CEST] <atomnuker> ah, ok, so its what's wrapped/allowed to be wrapped in a hw frame [19:56:47 CEST] <BtbN> it's what's actually in there [19:56:53 CEST] <BtbN> there can be pretty much everything [19:58:05 CEST] <jkqxz> The hw format will be an opaque format (AV_PIX_FMT_FLAG_HWACCEL). The sw format is something which reasonably represents the data actually contained (though not necessarily actual-layout accurate because tiling). [19:58:48 CEST] <BtbN> For CUDA it actually is layout accurate. Just in GPU memory. [19:59:00 CEST] <BtbN> But CUDA is a bit of a special case in terms of hwaccel [19:59:07 CEST] <jkqxz> CUDA doesn't tile at all? [19:59:25 CEST] <BtbN> CUDA hwaccel frames are basically just cuMemalloc + cuMemcpy [19:59:30 CEST] <BtbN> same as you'd do on CPU memory [19:59:40 CEST] <jkqxz> I guess it needn't in general, but it might be useful for some special cases. [19:59:51 CEST] <BtbN> NVENC supports tiled input [19:59:59 CEST] <wm4> typically the sw_format reflects the format of the data you see when you, well, access it [20:00:08 CEST] <BtbN> But it's not wired up in ffmpeg. And I for sure won't bother with it. [20:00:15 CEST] <jkqxz> Requiring you to use special allocation and copy functions can hide any manner of absurd layout. [20:00:23 CEST] <wm4> e.g. when transfering it to CPU memory, or accessing it via shaders on the GPU [20:00:34 CEST] <BtbN> jkqxz, you can actually do pointer arithmetic on the CUDA pointers. [20:00:51 CEST] <BtbN> Of course you don't know the physical layout in VRAM, but you don't really do for normal RAM either. [20:01:26 CEST] <jkqxz> You can? Wow, I didn't realise that. [20:02:42 CEST] <wm4> d3d11va supports decoding to an opaque format [20:02:51 CEST] <wm4> the transfer functions simply fail on it [20:03:03 CEST] <wm4> (this is pretty much by D3D11 design, not our choice) [20:06:34 CEST] <durandal_170> atomnuker: now i get this: https://0x0.st/56j.png [20:07:08 CEST] <BtbN> jkqxz, http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_cuda.c;h… [20:07:34 CEST] <BtbN> data is just a CUdevptr [20:08:41 CEST] <jkqxz> I like how the YUV420P is surprise YV12 :P [20:09:49 CEST] <BtbN> Yeah, it was decided to disguise it, as YUV420P is super common, and supporting it that way saves _a lot_ of pointless conversions [20:10:58 CEST] <wm4> jkqxz: I'm convinced ffmpeg actually got the inverse of the common convention [20:11:37 CEST] <wm4> (if you're referring to the swapped planes) [20:13:22 CEST] <atomnuker> durandal_170: on a white input? [20:13:42 CEST] <atomnuker> is this for a vertical or a horizontal only transform? [20:14:49 CEST] <BtbN> wm4, the weird thing is, for YUV444, ffmpeg and nvenc/cuda agree on the layout. [20:14:54 CEST] <BtbN> For YUV420 they don't [20:15:08 CEST] <BtbN> But both nvenc and ffmpeg call the format the same, yuv420/444 [20:15:40 CEST] <durandal_170> atomnuker: nope, horizontal only, doing only inverse of single dot pixel in center of image, it should display magnitude of fft part of impulse [20:16:31 CEST] <durandal_170> atomnuker: using http://bigwww.epfl.ch/demo/ip/demos/11-FFT/ as reference [20:17:02 CEST] <durandal_170> i modified code to not do convolve but just show mag [20:17:53 CEST] <durandal_170> this is strange, because doing fft_2d and than ifft_2d on single image gives same output [20:18:07 CEST] <wm4> BtbN: ok that seems inconsistent [20:18:30 CEST] <ubitux> BBB: so want to use intrinsics? [20:18:46 CEST] <BtbN> wm4, I'm pretty sure the inconsistency is on the nvenc side though [20:18:47 CEST] <ubitux> (RE: ADM thing) [20:19:44 CEST] <durandal_170> what? [20:19:57 CEST] <BtbN> wm4, ok, nevermind. They either renamed it at some point, or I just plain misremembered that: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h;h… [20:20:43 CEST] <BBB> ubitux: wait what? [20:20:50 CEST] <BBB> missing context [20:21:54 CEST] <BBB> Im pretty sure Im missing something incredibly obvious but Im not seeing it :-p [20:22:04 CEST] <BBB> please someone clue me in [20:22:26 CEST] <ubitux> [PATCH] avfilter: add ADM filter [20:22:31 CEST] <ubitux> you're apparently co-author? [20:22:51 CEST] <ubitux> +#include <emmintrin.h> [20:23:19 CEST] <BBB> ashk43712: ohright we shouldnt use such headers :-p [20:23:24 CEST] <BBB> no, no intrinsics [20:23:29 CEST] <ubitux> :) [20:23:31 CEST] <BBB> probably just a copypaste from the netflix code [20:23:54 CEST] <BBB> (this is algorithmically based on their opensource code from github) [20:26:26 CEST] <wm4> I hope it says that in the commit message [20:35:27 CEST] <ashk43712_> BBB: ok, what's the alternative for emmintrin.h? They use it to calculate "float xi = _mm_cvtss_f32(_mm_rcp_ss(_mm_load_ss(&x)));" which I have a very little clue about. [20:37:07 CEST] <BBB> thats 1/x [20:37:17 CEST] <BBB> float xi = 1/x; [20:38:16 CEST] <ashk43712_> oh, cool then. we don't need emmintrin.h. [20:39:48 CEST] <BBB> 1.0/x [20:39:50 CEST] <BBB> anyway [20:39:53 CEST] <BBB> you know what I mean [20:41:31 CEST] <ashk43712_> yeah, ok. [20:43:30 CEST] <wm4> the next step would be writing asm for it [20:43:36 CEST] <wm4> and making it faster than the intrinsic code [20:43:55 CEST] <wm4> (for bonus points, I guess) [20:45:18 CEST] <BtbN> why do they use intrinsics to calculate 1/x? oO [20:48:05 CEST] <ashk43712_> wm4: yes, started working on it. [21:11:53 CEST] <atomnuker> BtbN: its not even SIMD, its 1/first_float, next floats in the reg are passed as is [21:13:09 CEST] <atomnuker> its not as exact as a div but its faster than a div [21:16:30 CEST] <Gramner> it's a reciprocal approximation. faster than a normal division but significantly less accurate (only 12 bits precision) [21:49:40 CEST] <durandal_170> michaelni: ping [22:00:29 CEST] <atomnuker> neat, the vulkan hwaccel almost works now [22:01:11 CEST] <atomnuker> what other filters are easily doable in shaders but difficult in software? [22:03:44 CEST] <kiroma> There's vulkan hwaccel coming? How fast is it when compared to other methods? [22:04:36 CEST] <atomnuker> should be quite fast for things doable quickly in shaders [22:05:59 CEST] <atomnuker> I know most of mjpeg decoding can be done in shaders [22:06:08 CEST] <kiroma> neat [22:07:15 CEST] <atomnuker> but I'm mainly doing this for filters where having fractional pixels makes everything much easier [22:07:50 CEST] <kiroma> I see [22:08:37 CEST] <atomnuker> (well, not everything, just filters that do require fractional pixels) [22:09:18 CEST] <michaelni> durandal_170, its probbly possible to reuse it for convolution in principle [22:14:06 CEST] <atomnuker> schedule is up: https://www.videolan.org/videolan/events/vdd17/ [22:16:23 CEST] <atomnuker> (pinging j-b if he could schedule a technical meeting for ffmpeg sometime too) [22:16:58 CEST] <durandal_170> michaelni: convolving with identity image produce mirrored output [22:35:25 CEST] <BBB> atomnuker: did you propose the av1 meeting? [22:36:04 CEST] <BBB> I would really like to see someone doing a summary of av1 talk, not just an update compared to yesterday, because 99% of us dont know what it did yesterday so the update is semi-meaningless [22:36:32 CEST] <atomnuker> nope, wasn't me [22:37:42 CEST] <durandal_170> i propose general convolution meeting, people easily forgot such stuff [22:38:15 CEST] <BBB> TD-Linux: do you know whose talk it is? [22:40:12 CEST] <durandal_170> michaelni: give me some hint how to fix it, i'm desperate [22:42:11 CEST] <durandal_170> nobody knows how to do 2d fft with ffmpeg... [22:42:31 CEST] <atomnuker> few people know how to do it at all [22:42:46 CEST] <atomnuker> look on the bright side, once you learn you'll be one of them [22:43:45 CEST] <kiroma> Would it work if I passed both --enable-static and --enable-shared? I'm expecting to have both libraries and static executables. [22:45:33 CEST] <nevcairiel> On some systems that is possible, on some it isn't. [22:46:00 CEST] <nevcairiel> Some just can't build shared and static at the same time [22:48:25 CEST] <durandal_170> ubitux: you were writting 2d fft api? [22:48:37 CEST] <ubitux> was i? [22:49:15 CEST] <ubitux> ah you meant https://github.com/ubitux/dct ? [22:49:30 CEST] <ubitux> i used it for the dct filter but that's all [22:52:54 CEST] <kiroma> Well, it looks like it just omits the static flag. [22:55:38 CEST] <durandal_170> michaelni: shouldn't I need IDFT_C2C for this> [23:18:55 CEST] <michaelni> durandal_170, probably yes, [23:23:21 CEST] <durandal_170> michaelni: wouldn't than fft2d(image)-->ifft2d(image) not return same image if one doesnt do IDFT_C2C? [23:30:24 CEST] <michaelni> the image input and and final image should be real valued if the data that its convolved with is real valued, The stuff in freq domain is complex valued [23:30:45 CEST] <michaelni> the multiplication in fftfilt doesnt look correct for convolution [23:31:35 CEST] <durandal_170> michaelni: you mean my added code or already present one? [23:31:44 CEST] <michaelni> present one [23:31:51 CEST] <michaelni> didnt look at your code [23:32:06 CEST] <durandal_170> my code is based losely on fftfilt [23:32:30 CEST] <durandal_170> michaelni: what's not correct? [23:37:24 CEST] <iive> do you turn each pixel sample into complex real,img pair? [23:40:58 CEST] <durandal_170> iive: yes [23:49:27 CEST] <Compn> michaelni : i never got that dvdnav- ml password btw [23:49:35 CEST] <Compn> thanks for your help with it , of course :) [00:00:00 CEST] --- Fri Sep 1 2017

1 0

ffmpeg.log.20170831
by burek 01 Sep '17

01 Sep '17

[00:00:29 CEST] <JEEB> x264 by default sets the minimum level that you bit stream (outside of VBV/HRD) complies to [00:00:56 CEST] <JEEB> then you can set it to higher than that, but I think highest might be the same as auto - at least with profiles it could be like that [00:01:02 CEST] <JEEB> don't quote me on this [00:01:14 CEST] <JEEB> I just remember all those people setting -profile:v high and getting main :P [00:02:11 CEST] <alexpigment> yeah, there are restrictions [00:02:16 CEST] <alexpigment> but it's only one direction [00:02:50 CEST] <alexpigment> so yes, i agree with you JEEB :) [00:20:21 CEST] <alexpigment> well, I'm not really familiar with the patch submission process, and I don't even know if this is the clean way to do this - I'm just using diff between the original and the resultant file, but here's my pastebin: [00:20:33 CEST] <alexpigment> https://pastebin.com/a3aQPF2Z [00:21:03 CEST] <alexpigment> I've gotta head out. I've tested that the patch works. If anyone would like to submit it, feel free. [00:22:06 CEST] <alexpigment> (specifically, I don't know how to reference the files at the top. my compile script just asks me which files I'm trying to patch and I point it at the file manually) [01:22:03 CEST] <acos> ? [01:22:45 CEST] <acos> Oh hi [02:00:12 CEST] <acos> What do yall use ffmpeg for? [02:04:14 CEST] <c3r1c3-Win> I use it as a way to frustrate my life, because if it wasn't for ffmpeg I would be perfectly happy. [02:11:10 CEST] <redrabbit> lol. [02:29:34 CEST] <dystopia_> acos, pretty much everything [02:31:16 CEST] <acos> dystopia_ wow sounds. You don't get errors ? Lucky! [02:32:26 CEST] <c3r1c3-Win> I only get errors with ffmpeg when I try to write code against it... and that's only because I suck. [02:32:33 CEST] <c3r1c3-Win> Using it, it's awesome. [02:33:11 CEST] <c3r1c3-Win> And I use it for converting files from one codec to another, and remuxing. [02:54:19 CEST] <acos> c3r1c3-Win: nice nice [03:20:51 CEST] <MrDave20161> Does anyone have any tips/example links for how to query a v4l2 device for capabilities via the API? I wasn't able to find much on the "avdevice_capabilities_create" function and it is returning a "function not implemented". Ultimately I need to determine whether a particular pixel format(h264) is supported by the device before I specify that as the "input_format" and open the device. [03:38:55 CEST] <DHE> acos: over-the-air capture into a streaming format so I can watch it from anywhere [07:28:28 CEST] <borsh> Hello! [07:29:11 CEST] <borsh> I'm trying to stream to chaturbate.com but [07:29:26 CEST] <borsh> How to geal with rtmp stream key? Can't figure out what to do with it. [07:29:30 CEST] <borsh> s/geal/deal/ [07:32:39 CEST] <borsh> rtmp stream token [07:33:37 CEST] <borsh> This thing does not really help as obs has a separate field for the token [07:33:39 CEST] <borsh> https://support.chaturbate.com/customer/portal/articles/2831439-external-en… [09:52:32 CEST] <borsh> this does not work: ... -f flv "rtmp://some/url token=$token_data_here" [09:52:41 CEST] <borsh> [rtmp @ 0x56071008d850] Detected librtmp style URL parameters, these aren't supported by the libavformat internal RTMP handler currently enabled. See the documentation for the correct way to pass parameters. [09:52:45 CEST] <borsh> no token here https://www.ffmpeg.org/ffmpeg-protocols.html#rtmp [09:52:50 CEST] <borsh> Unrecognized option 'rtmp_token= [09:53:02 CEST] <borsh> Is it just not supported? [09:57:59 CEST] <Nacht> What version are you running ? [09:59:52 CEST] <borsh> Nacht: N-82889-g54931fd [10:00:31 CEST] <borsh> Nacht: do I need to rebuild? [10:40:55 CEST] <Nacht> borsh: It wouldn't hurt to try. [10:41:11 CEST] <borsh> Nacht: I'm now rebuilding [10:41:20 CEST] <borsh> Nacht: but this ffmpeg is probably only a week old [10:42:14 CEST] <borsh> Nacht: but I don't see the proper syntax in the docs [10:43:41 CEST] <borsh> haha [10:43:47 CEST] <borsh> I will try enabling librtmp :D [10:47:30 CEST] <borsh> Nacht: I had no rtmpdump installed. [10:48:00 CEST] <Nacht> I see. But I can't see N-82889 being a week old [10:48:40 CEST] <borsh> ok, rebuilding again anyway [10:49:41 CEST] <Nacht> You could just try the static ones ? [10:49:56 CEST] <Nacht> Saves you the time building [10:51:48 CEST] <borsh> But will the static one work with all these libs or does it include it's own lib set? [10:54:44 CEST] <Nacht> The static ones have quite a few libs included, incl rmtp [10:54:58 CEST] <Nacht> https://www.johnvansickle.com/ffmpeg/ [10:55:32 CEST] <Nacht> You can find the list of libs there [10:59:22 CEST] <borsh> Thanks [12:43:39 CEST] <dragmore> hi, the changelog for ffmpeg 3.3 says : - libvmaf video filter support, but when i run : ffmpeg -i source.mp4 -i dest.mp4 -lavfi libvmaf -f null - i get No such filter libvmaf, anyone know why? [12:43:59 CEST] <thatandyrose> hey there! can anyone help with an audio issue I'm trying to fix? Basically I have an m4a file with a start time > 0. I'd like to add "padding" to the beginning of the audio file so that its start time is zeroed essentially. How do I do this? [12:44:35 CEST] <thatandyrose> My first thought is to just pad it with silence. So say start time is 3.001 then I pad with 3.001 of silence? [12:45:08 CEST] <thatandyrose> but how do I do this? I want the file to be as unchanged as possible, except for this "padding" [12:45:34 CEST] <thatandyrose> for example... what would the command be? ffmpeg -i 1.m4a .... and then? [12:47:02 CEST] <thatandyrose> the reason I'm asking is because I'm going to merge this audio file with another audio file. And I find that when I do this the start time on the merged file gets zeroed, but because the start time offsets haven't been taken into account the audio is off [12:47:17 CEST] <thatandyrose> disclaimer: total n00b [12:58:39 CEST] <borsh> Nacht: it is N-87141-gb34c16a now [13:02:13 CEST] <borsh> Now I'm geting lots of [mjpeg @ 0x55f34d13f550] unable to decode APP fields: Invalid data found when processing input [13:04:28 CEST] <borsh> used garbage as an rtmp option and got the list of valid rtmp options yay! [13:04:44 CEST] <borsh> token is one of them so looks like I figured it out [13:15:45 CEST] <borsh> Will try fixing unable to decode APP fields: error in mjpeg downgrading to 3.3.3 [13:16:11 CEST] <borsh> streaming works but the stream is not getting online. [13:20:06 CEST] <borsh> Should I add any extra rtmp flags? [13:48:12 CEST] <borsh> What am I doing wrong? [14:16:33 CEST] <sloth_on_meth> helloooo [14:17:08 CEST] <sloth_on_meth> getting strange errors. [14:17:08 CEST] <sloth_on_meth> https://pastebin.com/iZSPWeMB [14:17:56 CEST] <DHE> sloth_on_meth: you need a package whose name is likely "gnutls-dev" or such in order to build using gnutls [14:18:05 CEST] <sloth_on_meth> okay, will try [14:19:02 CEST] <sloth_on_meth> never used FFMPEG beofre i ran into letsrobot.tv haha [14:19:11 CEST] <sloth_on_meth> for some reason, apt-get is extremely slow... [14:19:57 CEST] <sloth_on_meth> https://thepasteb.in/p/oYhl3k0gJxPCZ [14:20:40 CEST] <DHE> while I don't normally troubleshoot debian/ubuntu issues, I am guessing you have broken ipv6 [14:21:21 CEST] <sloth_on_meth> i have native IPV6 from my isp, that i work for. could this be a clientside issue on my rbp? i'll try disabling ipv6 just for testing [14:21:56 CEST] <JEEB> that would explain the slowness with apt-get :P [14:22:03 CEST] <JEEB> since it tries to connect through ipv6 first [14:22:04 CEST] <JEEB> then times out [14:22:17 CEST] <sloth_on_meth> oh. can i force ipv4? [14:22:46 CEST] <JEEB> disabling ipv6 in the VM or whatever is probably simplest :) [14:23:11 CEST] <sloth_on_meth> i've added -o Acquire::ForceIPv4=true [14:23:28 CEST] <sloth_on_meth> yeah i did that but then it still tries to conenct to ipv6 making me wait for the timeouit [14:24:07 CEST] <sloth_on_meth> you guys ever heard of letsrobot? [14:38:45 CEST] <blap> +1 for nickname sloth [14:40:59 CEST] <sloth_on_meth> ty ty [15:43:12 CEST] <ForceRecon> how to config from 720 to 360 [15:44:35 CEST] <Kadigan> Just in case someone has the same issue I did w/ 50i material looking like 25fps (seemingly 25PsF) when deinterlaced w/ YADIF in mode 1 (recreate fields into frames to create a slow motion effect), check your shutter speed -- it didn't occur to me before (as I'm not the cam operator) that setting the exposure to anything longer than 1/fps would cause this effect. We were recording 50i and got 25PsF at any moment the exposure was longer than 1/50. A [15:44:36 CEST] <Kadigan> small detail, but it matters. [15:45:23 CEST] <ForceRecon> I have a guy in the debian channel asking for help.. I redirected him here, but I don't see him.. just trying to help him out.. I don't use ffmpeg.. he is to stream to youtube and asked [15:45:26 CEST] <ForceRecon> i work on ffmpeg but 720p [15:45:28 CEST] <ForceRecon> i need to config it to 360p????? [15:45:37 CEST] <ForceRecon> can anyone help with this configuration [15:45:54 CEST] <Kadigan> ForceRecon: he has 720p video and needs to recompress to 360p? [15:46:38 CEST] <ForceRecon> Stream status Bad 720p Stream? [15:46:56 CEST] <ForceRecon> that about all I can give you.. but it sounds like you are on the right track [15:47:09 CEST] <Kadigan> Okay, I don't recognize that message. Sorry. [15:47:35 CEST] <ForceRecon> if he wanted to recompress to 360 is there an option [15:47:59 CEST] <Kadigan> yes, he needs to add -vf "scale=-1:360" to his call options. [15:48:18 CEST] <Kadigan> (the -1 will preserve aspect ratio and rescale the width accordingly so that it fits the new height) [15:49:24 CEST] <ForceRecon> Thanks Kadigan appreciated, he might come here.. just so you know doslas [15:52:32 CEST] <doslas> hi [15:52:47 CEST] <doslas> https://pastebin.com/F6WszwFz [15:52:59 CEST] <doslas> this is my ffmpeg conf [15:53:14 CEST] <doslas> it is 720p [15:53:32 CEST] <doslas> i need it 360p????? [15:53:36 CEST] <doslas> how??? [15:54:23 CEST] <doslas> any one here?? [15:54:27 CEST] <doslas> plz [15:54:32 CEST] <Kadigan> We're reading. Wait. [15:54:44 CEST] <doslas> ok [15:55:13 CEST] <Kadigan> Well, like we told ForceRecon, if you want it 360p, you'll need to add -vf "scale=-1:360" to the commands. [15:55:14 CEST] <Nacht> -vcodec libx264 -vf "scale=-1:360" -pix_fmt yuv420p -preset $QUAL -r $FPS -g $(($FPS * 2)) -b:v $VBR \ [15:55:34 CEST] <Kadigan> Though I'm not sure whether this'll work as you expect, since it'll take some time encoding. [15:55:34 CEST] <Nacht> Not sure why it needs to be 360 though [15:56:27 CEST] <Kadigan> You might want to try -preset ultrafast, ... I think... [15:56:56 CEST] <doslas> i will add it and try [15:57:00 CEST] <Nacht> Youtube should be able to ingest 720p tho [15:57:04 CEST] <Nacht> https://support.google.com/youtube/answer/2853702? [15:57:20 CEST] <BtbN> you can stream 4K there if you want to [15:57:48 CEST] <doslas> :) [15:57:53 CEST] <BtbN> ultrafast ist overkill in terms of badness [15:58:01 CEST] <BtbN> veryfast is usually a good compromise [15:58:18 CEST] <BtbN> anything faster will disable features and look notably worse [15:58:38 CEST] <doslas> no i need 360p & 240p [15:59:00 CEST] <Nacht> You need both ? [15:59:49 CEST] <doslas> no [16:00:11 CEST] <doslas> once 360p [16:00:20 CEST] <doslas> once 240p [16:00:36 CEST] <doslas> if i need [16:00:44 CEST] <Nacht> Just a question. But what exactly are you trying to do, and who says it needs to be 360p ? [16:00:49 CEST] <Nacht> Is it live, or a vod ? [16:01:45 CEST] <doslas> the Internet is slow [16:02:08 CEST] <doslas> Stream status [16:02:08 CEST] <doslas> Bad [16:02:09 CEST] <doslas> 720p Stream [16:03:14 CEST] <furq> lol this fucking script again [16:03:32 CEST] <furq> i swear this thing gets pasted by someone new once a month [16:03:38 CEST] <Nacht> heeh [16:04:10 CEST] <furq> why -threads 6 in a blog post command? why -qscale 3? why 712kbps mp3? we will never know [16:04:41 CEST] <bencoh> because! [16:04:50 CEST] <furq> i can sort of understand the first two coming from not understanding the commands you cobbled this together from [16:05:01 CEST] <furq> but how has anyone ever come to the conclusion that -b:a 712000 is a thing [16:05:33 CEST] <furq> oh and i forgot -deinterlace [16:05:40 CEST] <bencoh> haha [16:05:47 CEST] <doslas> https://pastebin.com/aiVjh1tk [16:05:55 CEST] <Nacht> Perhaps if for an Opera live channel :) [16:06:05 CEST] <doslas> after tried [16:06:12 CEST] <furq> doslas: basically get rid of almost all of that command because it sucks [16:06:22 CEST] <furq> and also don't copy ffmpeg commands from blogs because they were all written by idiots [16:06:27 CEST] <bencoh> furq: a lot of tv channels are still interlaced, but ... yeah :) [16:07:07 CEST] <furq> ffmpeg -i "$SOURCE" -c:v libx264 -pix_fmt yuv420p -b:v 2500k -c:a aac -b:a 128k -f flv "$YOUTUBE_URL/KEY" [16:07:20 CEST] <furq> then add -vf "scale=-2:360" as needed [16:07:46 CEST] <furq> also that's going to make no difference to the bandwidth if you don't change -b:v to something lower [16:08:29 CEST] <doslas> ok [16:08:48 CEST] <Kadigan> furq: you mean "written for specific purposes" don'tcha ;) [16:09:05 CEST] <furq> well no big chunks of that are just plain wrong [16:09:09 CEST] <furq> you can't even have a 712kbps mp3 [16:09:11 CEST] <Kadigan> Like 90% of issues I see when it comes to configs or scripts is because people copy&paste w/o understanding what {X} does. [16:09:14 CEST] <Kadigan> Yeah, that bit I know. [16:09:26 CEST] <furq> but yeah [16:09:35 CEST] <Kadigan> Looks like someone was writing some pro-formats script and ended up replacing sound w/ libmp3lame [16:09:45 CEST] <furq> you start with that, then you get a second generation of blog cobbled together from the first [16:10:08 CEST] <furq> and then you end up with some magnificent eighth-generation cluelessly assembled command like this [16:10:16 CEST] <Nacht> I'm still in the dark as why Youtube would request 360p though [16:10:20 CEST] <doslas> same prop [16:10:24 CEST] <Kadigan> Hey, I just wasted 3 man-hours of Canon Support on operator error ;-) [16:10:35 CEST] <furq> doslas: -2:360 [16:10:36 CEST] <doslas> in youtube [16:10:36 CEST] <furq> not -1 [16:10:53 CEST] <doslas> Stream status Bad 720p Stream [16:11:14 CEST] <doslas> 720p not 360p [16:11:16 CEST] <Kadigan> furq: why -2? https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg says -1 [16:11:23 CEST] <furq> -2 ensures it resizes to mod2 [16:11:27 CEST] <Kadigan> Ah. [16:11:31 CEST] <Kadigan> Good to know. [16:11:34 CEST] <furq> otherwise you get [libx264 @ 0x55cb734952c0] width not divisible by 2 (641x360) [16:11:39 CEST] <Kadigan> (I do recall seeing it somewhere, just forgot about it) [16:12:27 CEST] <doslas> -2 Worked [16:12:36 CEST] <doslas> but 720p not 360p [16:12:43 CEST] <Nacht> Ah, so it always better to use -2 then [16:12:55 CEST] <furq> it is if you're using a pixel format that requires mod2 [16:13:19 CEST] <Nacht> TIL [16:13:37 CEST] <furq> doslas: i have no idea what youtube error messages actually mean, but you should be able to see that the output is 360p [16:14:05 CEST] <doslas> Can you fix me on the Iscript [16:14:32 CEST] <doslas> i need image sit? [16:14:36 CEST] <furq> Stream #0:0: Video: h264 (libx264), yuv420p, 640x360 [SAR 3:4 DAR 4:3], q=-1--1, 25 fps, 25 tbn, 25 tbc [16:14:41 CEST] <furq> you should have something like that in the output [16:15:01 CEST] <doslas> i upload photo [16:20:06 CEST] <doslas> https://pasteboard.co/GIcYYqo.png [16:20:45 CEST] <doslas> https://pasteboard.co/GIcZiHg.png [16:21:01 CEST] <Kadigan> Ah. Well, that's not suprising. Transcoding takes time -- and if you're transcoding FROM a live stream TO a live stream, you're going to have a bad time. [16:21:41 CEST] <Kadigan> Set "-b:a 128k" for starters -- youtube is telling you that what you have is too high and not needed. [16:21:45 CEST] <doslas> https://pasteboard.co/GIcZJ7o.png [16:21:45 CEST] <Nacht> You didn't change the bitrates [16:22:16 CEST] <Kadigan> Yeah, video is also too high -- don't use -qscale, use the bitrate options (there are four in total, and you need to use three of them) [16:22:37 CEST] <doslas> how? [16:22:38 CEST] <Nacht> what does FFMPEG say about your input ? [16:22:45 CEST] <Kadigan> Yes, I know they're not usually recommended, but in this case they're quite mandatory if you want to maintain constant output. [16:22:47 CEST] <doslas> use the bitrate option??? [16:23:19 CEST] <Kadigan> doslas: you have three bitrate options that concern you -- max, min and avg - you'll want them at the same value, for starters. [16:23:28 CEST] <Kadigan> (you can tweak min/max later, when it works) [16:23:53 CEST] <doslas> https://pastebin.com/0a4rE8tQ [16:24:02 CEST] <doslas> this is my script [16:24:13 CEST] <doslas> make it for me [16:24:25 CEST] <doslas> fix it plz [16:24:29 CEST] <Kadigan> No. [16:24:39 CEST] <Kadigan> We can HELP you, but if you need WORK, pay for it. ;) [16:24:43 CEST] <doslas> fix it to 320p [16:25:33 CEST] <Nacht> first run 'ffprobe -i udp://239.255.139.0:1234' and tell us what it says [16:25:57 CEST] <doslas> I've been experimenting for a week, and there's been no success. [16:25:57 CEST] <doslas> [16:26:45 CEST] <doslas> Nacht ok [16:28:17 CEST] <doslas> https://pastebin.com/zY3q6fKb [16:28:22 CEST] <doslas> Nacht [16:31:14 CEST] <Nacht> Thats not everything [16:33:18 CEST] <doslas> He freezes after this. [16:34:37 CEST] <doslas> look [16:34:40 CEST] <doslas> https://pasteboard.co/GId4TPk.png [16:35:05 CEST] <doslas> Nacht [16:35:11 CEST] <Nacht> ah yeah ofc, its a stream [16:36:41 CEST] <Nacht> The thing is, I can't think of a reason why you have to send 360p to Youtube. [16:37:03 CEST] <Nacht> You could prolly just transmux the video without even having to transcode it [16:37:36 CEST] <Nacht> try 'ffmpeg -i udp://239.255.139.0:1234 -t 00:00:01' [16:38:01 CEST] <doslas> Because I want to be broadcasting fast when viewers slow internet owners [16:38:02 CEST] <doslas> [16:39:25 CEST] <doslas> look [16:39:26 CEST] <doslas> https://pasteboard.co/GId6Sb6.png [16:40:07 CEST] <Nacht> afaik Youtube transcodes for you [16:41:39 CEST] <doslas> in youtube [16:41:42 CEST] <doslas> We are not receiving video data at a fast enough rate. Your viewers may experience buffering. Ensure your connection is fast enough or consider using a lower bitrate. [16:41:56 CEST] <doslas> youtube says [16:42:01 CEST] <doslas> We are not receiving video data at a fast enough rate. Your viewers may experience buffering. Ensure your connection is fast enough or consider using a lower bitrate. [16:42:53 CEST] <Nacht> okido [16:43:53 CEST] <Nacht> try this: https://pastebin.com/ButxUDD5 [16:44:31 CEST] <doslas> ok [16:44:34 CEST] <Martchus> Trying to (re)mux an AVI file to Mkv without reencoding. Is this a known bug or do I just miss some CLI flag? http://paste.opensuse.org/52110957 My files seem to be fine, at least mkvmerge can handle them well. [16:48:26 CEST] <doslas> same problem [16:48:29 CEST] <doslas> https://pasteboard.co/GIdarpp.png [16:48:47 CEST] <doslas> Nacht [16:49:09 CEST] <Nacht> doslas: Could be two things. Your upload speed is crap, or your PC cant transcode fast enough [16:49:20 CEST] <Nacht> Martchus: try with -fflags +genpts [16:51:11 CEST] <Martchus> Nacht: Works, thanks. [16:51:17 CEST] <doslas> Why hasn't it changed to 320p? [16:51:17 CEST] <doslas> [16:51:28 CEST] <doslas> look at image [16:51:57 CEST] <doslas> Still 720p [16:53:15 CEST] <doslas> my upload is 50k/s [16:57:10 CEST] <Nacht> The ffmpeg command will def output 360p [16:57:28 CEST] <Nacht> Just write it to a local mp4 '-f mp4 test.mp4' and you will see [16:59:39 CEST] <doslas> I'm a live feed from a file already in the home [17:00:23 CEST] <doslas> https://pastebin.com/SNqTHrNA [17:02:33 CEST] <Nacht> nways, gotta go [17:04:43 CEST] <doslas> Nacht What i do? [18:48:02 CEST] <Vlad__> Hello, everyone! Can someone please explain what this ffmpeg command does? https://pastebin.com/7rpDH1xH [18:49:41 CEST] <Mavrik> Hmm, takes the input test.mp4, decodes it into raw video, converts it to grayscale, resizes to 1280x720 and I think drops every 3rd and 4th frame? [18:50:03 CEST] <Mavrik> Not sure about the last part, select= selects frames to output and I'd have to check the calculation a bit more in depth [18:50:16 CEST] <Mavrik> It outputs the result on stdout [18:52:30 CEST] <Vlad__> @Mavrik, yes, my main misunderstanding comes from that filtergraph, does it select every 3rd and 4th? or actually pick every 3rd and 4th? [18:52:31 CEST] <bigx> hello there [18:53:18 CEST] <bigx> Im trying ot do ffmpeg encoding with nvenc on an ec2 g3.4xlarge instance (with a Tesla M60 gpu) [18:53:38 CEST] <bigx> but my encoding is only 8.5fps [18:54:02 CEST] <bigx> it seems theres something wrong [19:00:54 CEST] <bigx> here is the command and the ffmpeg output I have [19:01:00 CEST] <bigx> https://pastebin.com/BzmVXctK [19:01:53 CEST] <bigx> so it seems `--enable-nvenc` is indeed here, but it seems to have no effect, Im a bit lost [19:05:19 CEST] <jkqxz> How fast is it if you don't do all the crazy overlay stuff? [19:05:55 CEST] <bigx> thanks for your answer jkqxz , I havent tried it yet [19:06:04 CEST] <jkqxz> Also note that the decode of the mov file is happening on the CPU; -hwaccel is a per-stream option applying to the next input file. [19:06:37 CEST] <bigx> oh! nice catch, I wasnt aware of that [19:07:23 CEST] <jkqxz> Oh, but it's qtrle so there is no hardware for that anyway. [19:07:32 CEST] <jkqxz> I think you're just doing a lot on the CPU. [19:07:58 CEST] <jkqxz> So however fast the encode itself is it doesn't really help much. [19:08:40 CEST] <bigx> ok, so I should first transcode my video assets to h264 first I guess [19:09:01 CEST] <bigx> (without the crazy overlay stuff, I run it at 30fps) [19:09:13 CEST] <kerio> i thought qtrle was quite fast [19:10:20 CEST] <jkqxz> Maybe. But it's 3328x1664 at 58Mbps. [19:10:58 CEST] <doslas> Nacht [19:11:39 CEST] <doslas> Kadigan [19:11:56 CEST] <Kadigan> doslas: ? [19:11:57 CEST] <bigx> yup, these are 360 videos at the end [19:12:33 CEST] <doslas> pleas say thanks to Nacht [19:12:36 CEST] <kerio> thats a lot of pixels ;o [19:12:41 CEST] <doslas> yeah [19:12:56 CEST] <kerio> bigx: encode them [19:12:59 CEST] <kerio> IN LOSSLESS H264 [19:13:01 CEST] <kerio> MWAHAHAHAHA [19:13:04 CEST] <bigx> oh, on this topic I was a bit disapointed to see I need an external tool to inject 360° metadata (https://github.com/google/spatial-media/tree/master/spatialmedia) [19:13:19 CEST] <Kadigan> Pardon? [19:13:37 CEST] <bigx> I was thinking Id be able to inject it with ffmpeg, but I had no success [19:13:41 CEST] <doslas> every thing is work by script Nacht [19:14:52 CEST] <Kadigan> doslas: then you should thank him; it's cool that he helped [19:15:05 CEST] <doslas> goodbye & thank you for all [19:15:14 CEST] <doslas> ok [19:15:16 CEST] <Kadigan> bigx: yeah, had the same problem when I pushing 360fly videos to YT after processing [19:15:23 CEST] <Kadigan> s/I/I was [19:15:28 CEST] <doslas> i will be back [19:15:53 CEST] <bigx> Kadigan: you ended up using the same tool as me? something else? [19:16:57 CEST] <Kadigan> I recall Google has this tool... or something. [19:17:15 CEST] <Kadigan> (I'm on a Mac, so whatever Windows tools they propose are sort of useless to me) [19:17:17 CEST] <bigx> well, yes the one I use too https://github.com/google/spatial-media/tree/master/spatialmedia [19:17:36 CEST] <Kadigan> If that's the Google thing, then probably that. [19:17:42 CEST] <bigx> theres a gui and a python script [19:17:46 CEST] <Kadigan> (I do recall it being a GUI thing) [19:17:49 CEST] <Kadigan> Yeah, I guess. [19:17:50 CEST] <bigx> but yes, must be it [19:17:59 CEST] <Kadigan> Point is, [19:18:01 CEST] <Kadigan> it didn't work. [19:18:30 CEST] <Kadigan> Or, rather, it sort of did... but it didn't. I had to go and publish through the 360fly camera app. [19:18:40 CEST] <Kadigan> (which injected the <correct> data) [19:20:13 CEST] <bigx> I tried, and posting to youtbue and facebook 360 is ok now [19:20:20 CEST] <bigx> now as yesterday [19:20:44 CEST] <Kadigan> Okay, if you say so. I was doing spherical videos, if it matters. Well, half-spherical. [19:21:30 CEST] <bigx> mine are spherical [19:21:31 CEST] <Kadigan> Well, "spherical sort-of". I'm <still> not quite sure where the middle of that thing is, or why it's so distorted as to be tilted to all possible sides by one or two degrees when in its "neutral" position... but meh. Birthing pains, I assume... [19:21:43 CEST] <bigx> true that [19:21:56 CEST] <Kadigan> Ended up doing a lil' Photoshop overlay w/ degrees and positions, [19:22:03 CEST] <Kadigan> so that I could do animated titles. [19:22:12 CEST] <Kadigan> (ie. warp stuff) [19:22:47 CEST] <Kadigan> But I feel this is getting distinctly un-ffmpeg-y. ;) [19:22:59 CEST] <bigx> :) [19:24:55 CEST] <Vlad__> Can someone, please, clarify what the filtergraph in this command does? https://pastebin.com/7rpDH1xH [19:27:06 CEST] <Kadigan> Filtergraph? I'm not familiar w/ that term. Anyone? [19:31:55 CEST] <acos> Sup [19:34:42 CEST] <Kadigan> Vlad__: if I'm not mistaken (I'm still a bit fuzzy on the + operation), it processes 2 frames every 2 frames, so 0, 1, 4, 5, 8, 9... [19:35:02 CEST] <durandal_1707> Kadigan: read manual to learn more [19:36:44 CEST] <Kadigan> durandal_1707: ah, so "filtergraph" is the proper name for what I consider the processing chain [19:36:49 CEST] <Kadigan> Okay. [19:37:10 CEST] <Kadigan> So, Vlad__ - it resizes the video to HD and then selects 2 frames every 2 frames [19:37:18 CEST] <Kadigan> (starting at the first) [19:38:37 CEST] <Kadigan> That's actually fairly cool... I never considered this, but it would seem I could use an 8k source as input, and then use ffmpeg to split this into four, resize into Full HD and feed into four devices attached to displays organized as slices of the bigger picture [19:38:38 CEST] <Kadigan> cool. [19:43:58 CEST] <Vlad__> Kadigan, thanks for your input [19:51:04 CEST] <dongcarl> hi all, is there an option to have ffplay automatically resume when url finishes buffering? [19:52:23 CEST] <furq> probably don't use ffplay [19:52:31 CEST] <furq> it's not intended to be used for anything other than testing [19:58:07 CEST] <dongcarl> furq: got it, thanks! [20:57:45 CEST] <dragmore_> Anyone know when lib_VMAF will be released in ffmpeg? [20:58:11 CEST] <dragmore_> says : - libvmaf video filter in the changelog for 3.4 but cant too find it in the nightlies.. [20:59:00 CEST] <durandal_170> dragmore_: you need to compile with libvmaf lib support enabled [21:00:56 CEST] <pgorley> hi, is there a way to estimate the bitrate based on the crf value and resolution? [21:01:32 CEST] <klaxa> not really [21:02:57 CEST] <klaxa> highly depends on the content [21:03:11 CEST] <klaxa> very static content will have a lower bitrate than highly dynamic content [21:03:19 CEST] <pgorley> makes sense [21:03:50 CEST] <klaxa> you could take an "average" scene and do short test-encodes to vaguely estimate the bitrate for different crfs for that file [21:06:16 CEST] <acos> What's the way to set a constant bit rate and not variable? [21:07:22 CEST] <klaxa> -b:v 1024k will set the video bitrate to 1 megabit/s [21:07:44 CEST] <klaxa> although i'm not sure in how far each encoder honors that [21:08:45 CEST] <furq> acos: what codec [21:08:58 CEST] <furq> if you want proper cbr then it depends on the encoder [21:16:47 CEST] <dragmore_> durandal_170: Any pre-compiled windows builds with it around? [21:22:48 CEST] <durandal_170> dragmore_: no [21:24:18 CEST] <BtbN> freenode sure is acting weird with changing the nick before killing it [22:28:10 CEST] <acostres> Well was trying to do x264 stuff [22:28:49 CEST] <klaxa> cbr and h264 is a bad idea tbh [22:29:13 CEST] <klaxa> https://trac.ffmpeg.org/wiki/Encode/H.264#CBRConstantBitRate [00:00:00 CEST] --- Fri Sep 1 2017

1 0