[00:00:41 CEST] <jamrial> nevcairiel: there's a function called interleaveBytes_sse2 that's used when you convert yuv420p -> nv12 [00:01:36 CEST] <nevcairiel> oh well, could still be optimized by doing it on-the-fly while filling the bugger [00:01:39 CEST] <nevcairiel> buffer* [00:02:31 CEST] <BtbN> Hm, using swscale there would mean linking lavc to sws [00:04:45 CEST] <BtbN> philipl, on my gt630, on linux, with 352.09, yuv420p works [00:04:51 CEST] <BtbN> on windows, my compiler broke [00:05:32 CEST] <BtbN> only the cygwin one still works [00:06:18 CEST] <BtbN> interesting that my 40¬ GT630 has a higher SM version (3.5) than my GTX760 (3.0) [00:08:21 CEST] <nevcairiel> they build a few "new" 630s with a newer chip [00:09:04 CEST] <BtbN> Yes, i made sure i have one of those. The original 630 isn't Kepler [00:09:12 CEST] <BtbN> It's the cheapest possible card with nvenc support [00:09:18 CEST] <BtbN> propably around 30¬ now [00:18:09 CEST] <philipl> BtbN: guess its a driver improvement then [00:20:03 CEST] <nevcairiel> so a user dug up a 1519x733 rgb24 video file ... where do these people find such odd things [00:23:14 CEST] <philipl> Selection bias. what other project would even pretent to consider supporting such a format [00:23:20 CEST] <philipl> :-) [00:26:59 CEST] <wm4> sounds easy to handle? [00:27:58 CEST] <nevcairiel> not if you want to encode it into 420 h264 :D [00:28:09 CEST] <nevcairiel> apparently, some part of the chain didnt like that resolution [00:29:02 CEST] <philipl> its certainly not aligned! [00:29:14 CEST] <BtbN> It non-even [00:29:21 CEST] <BtbN> h264 doesn't even support that iirc [00:29:28 CEST] <nevcairiel> sure it does [00:29:31 CEST] <nevcairiel> with cropping metadata [00:29:50 CEST] <BtbN> Non-even resolutions in yuv420 mode? [00:30:21 CEST] <nevcairiel> the encoder might not allow it, but there is no reason the cropping metadata couldnt be set to allow that [00:30:23 CEST] <BtbN> It supports non-power of 8 resolutions that way, but non even? [00:30:40 CEST] <BtbN> How would you even get that converted to yuv420? [00:30:53 CEST] <BtbN> which shared the U/V data for 4 pixels each [00:31:12 CEST] <nevcairiel> that is the more interesting question, thats probably the area of the code that didnt like this file [00:31:16 CEST] <nevcairiel> hope the user shares it [00:32:09 CEST] <nevcairiel> personally i would probably just pretend its 1px wider and higher and add black =p [00:33:33 CEST] <BtbN> Or something would automaticaly insert a scaler and it would ruin the quality by doing a linear scale [00:44:03 CEST] <philipl> To get that as your input format, there's a very good chance it's already ruined. [00:44:31 CEST] <philipl> "I have a sequence of screencap bmps..." [00:56:22 CEST] <michaelni_> durandal_1707, are the other apng patches from donny yang ok to be applied (that is #3 & #4 i think) or they are on hold because of the thread support removial #1 patch ? [01:21:37 CEST] <philipl> BtbN: do you understand how the 2 pass nvenc mode works? I don't see how it can actually run two passes. [01:21:44 CEST] <philipl> the documentation is terrible [01:21:58 CEST] <BtbN> They must have an interesting interpretation of what 2pass means [01:22:08 CEST] <philipl> Quite. [01:22:39 CEST] <BtbN> low-latency hq with 2pass enabled gives the best quality for live streaming though [01:22:54 CEST] <BtbN> No idea how that makes any sense [01:23:07 CEST] <BtbN> I'd expect low-latency to result in worse quality [01:23:15 CEST] <BtbN> and 2pass should not be a thing for live streaming [01:23:36 CEST] <philipl> "3.1.2 Input Buffers Allocated Externally" [01:23:41 CEST] <philipl> right [01:29:12 CEST] <kierank> hardware can run two passes in realtime [01:29:32 CEST] <kierank> similarish to x264 lookahead but it does the actual encoding [01:29:52 CEST] <philipl> Not true 2pass though - it can't evaluate the entire stream [01:30:01 CEST] <BtbN> But it'd have to keep some buffer for that to even work at all [01:30:17 CEST] <BtbN> And low-latency usualy means keeping as little of a buffer as possible [01:31:02 CEST] <kierank> it can encode the frame and encode it again [01:31:15 CEST] <kierank> 2-pass is usually marketing though [01:31:35 CEST] <BtbN> It's some kind of obscure quality booster [01:32:02 CEST] <BtbN> which you just have to turn on, and you get better quality for a lower encode speed, which doesn't matter at all if you are doing live streaming [01:33:00 CEST] <philipl> Strangely, at least for 4k60, llhp is slower than regular hp, or even hq. [01:33:04 CEST] <philipl> Makes it sub-realtime. [01:33:10 CEST] <philipl> Rendering the ll pointless. [01:33:24 CEST] <BtbN> yes, ll is slower and has a better quality than the non-ll profiles [01:33:36 CEST] <BtbN> It makes no sense at all [01:34:02 CEST] <philipl> Ours not to reason why. [01:35:27 CEST] <BtbN> The nvenc encoder in OBS just has an "Automatic" mode, which just selects the best quality mode which is known to work in realtime for the selected resolution/fps [01:35:38 CEST] <BtbN> To safe the users from having to deal with that chaos [01:35:46 CEST] <philipl> A good idea. [01:35:59 CEST] <kierank> damn OBS [01:36:01 CEST] <kierank> stealing my name [01:36:36 CEST] <BtbN> There is also another, secret, mode. [01:36:44 CEST] <philipl> oh yes? [01:37:03 CEST] <BtbN> If you query the nvenc api, how many profiles it supports, it lists two more than there are GUIDs in the public header [01:37:26 CEST] <philipl> but without guids you can't use them? [01:37:30 CEST] <BtbN> yep [01:38:06 CEST] <BtbN> I did some wiretapping on the ShadowPlay app, and when you use it to stream to twitch, it uses a GUID for the encoding preset and profile that are not in the public header [01:38:30 CEST] <philipl> It would make sense that it's shadowplay related. And if you pass those GUIDs? [01:38:30 CEST] <BtbN> But just using that GUID results in an initialization error [01:38:40 CEST] <philipl> heh [01:39:16 CEST] <BtbN> I guess it's NvIFR/FBC related, and a special mode to encode on-gpu [01:39:55 CEST] <philipl> right. [01:42:06 CEST] <BtbN> If you google a bit, you can actualy find api headers and libs for an older version of those [01:42:23 CEST] <BtbN> They came with some old nvidia driver release, that's still mirrored on some sites [01:42:39 CEST] <BtbN> But they don't work anymore [02:54:51 CEST] <cone-046> ffmpeg 03Ganesh Ajjanagadde 07master:42db4aaaa6e4: vf_colormatrix: calculate coefficients only once [02:56:44 CEST] <durandal_1707> michaelni_: Yes because of threads [04:07:54 CEST] <klaxa> i'm currently looking at http listen and chunked encoding and also maybe creating headers in a less static way [04:08:09 CEST] <klaxa> does it even make sense to not use chunked encoding for serving files? [04:08:53 CEST] <klaxa> i don't think i can tell the stream-size while encoding [04:09:15 CEST] <klaxa> or muxing or whatever [04:11:34 CEST] <Compn> what [04:11:47 CEST] <Compn> who is the target for your videos klaxa ? [04:11:58 CEST] <klaxa> an http client, e.g. wget [04:12:08 CEST] <Compn> just you? 3million people? 41 nerds at a lan party? [04:12:34 CEST] <Compn> or do you mean for developing chunked encoding for ffmpeg ? [04:12:39 CEST] <Compn> sorry, i am confused :P [04:13:07 CEST] <klaxa> i am working on http.c in libavformat [04:13:11 CEST] <Compn> oh ok :) [04:13:13 CEST] <Compn> ignore me then [04:13:29 CEST] <klaxa> heh, ok [04:14:26 CEST] <klaxa> for now it only accepts one client, but nicolas george suggested we could write it to support multiple clients, but first i have to clean up the code for a single client and make it work for most usecases [04:14:57 CEST] <klaxa> and a client sending a file without chunked transfer encoding is a pretty valid usecase i think [05:29:46 CEST] <cone-046> ffmpeg 03Philip Langdale 07master:cc904353fa9a: avcodec/allcodecs: Re-order nvenc encoders below x264/5. [06:20:53 CEST] <jamrial> should every demuxer, muxer and protocol remain enabled if i run configure with --disable-avformat? because that's what happens [06:21:56 CEST] <jamrial> same with libavdevice and in/outdevs, and i assume with the other libraries as well [06:22:25 CEST] <jamrial> guess configure is missing some dependency checks? [06:25:48 CEST] <cone-046> ffmpeg 03James Almer 07master:e225f5f23253: fate: add missing avdevice dependency to closed caption test [12:50:52 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:d6039063aaba: ffserver: Check allocations (likely not all) [13:31:18 CEST] <mattlea> Hello, does anyone have any experience with psychoacoustic models? [15:15:34 CEST] <anshul_mahe> is there anything I can help to get my hls webvtt patch in main stream [15:16:25 CEST] <BtbN> Did you send it to the ML? [15:20:39 CEST] <anshul_mahe> yes its on ml from 6 months [15:20:56 CEST] <anshul_mahe> I am tired of merging it with new git [15:23:34 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:dc55477a64ce: avformat/ffmdec: Check ffio_set_buf_size() return value [15:23:35 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:0023ea4e20b0: avformat/aviobuf: Check for ffio_set_buf_size() failure [15:23:36 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:ddda9cee1c4b: ffserver: Check for ffio_set_buf_size() failure [15:24:49 CEST] <BtbN> It propably won't be merged before 2.7 is branched, but i didn't follow the ML on that patch [15:33:36 CEST] <anshul_mahe> yes I dont have any problem even if it get merged later, here is this month mail https://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/173813.html [15:34:38 CEST] <anshul_mahe> but I came here asking to atleast get experts comment to make that patch better [18:03:15 CEST] <ubitux> anshul_mahe: + {"hls_subtitle_path", "set path of hls subtitles", OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E}, [18:03:26 CEST] <ubitux> can't you pick an input subtitles stream instead? [18:03:32 CEST] <ubitux> that sounds wrong at first sight [18:10:04 CEST] <ubitux> ah that's the output one [19:05:14 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:7c453277a399: avdevice/iec61883: Check pthread init for failures [20:21:41 CEST] <cone-151> ffmpeg 03Clément BSsch 07master:40cc3be73c2c: avfilter: fix a few 5 spaces indent [20:26:48 CEST] <ubitux> i'm writing a filter that will take up to 4 * 9 settings, or 4 adjustments for 9 different region/colorranges [20:27:04 CEST] <ubitux> you will generally want to adjust the 4 settings for one or 2 regions [20:27:20 CEST] <ubitux> what would ppl prefer as interface? [20:27:54 CEST] <ubitux> 4*9 options, requiring to fill with 0 all the unaffected regions (or explicit 4 or 8 (or more) keys) [20:28:34 CEST] <ubitux> or having the region as option key, and a quad of floats? (region1=0.1|0.6|0.3|0.4:region2=...) [20:29:42 CEST] <ubitux> (first case being expliciting region[0..8]_setting[0..3] option -- note: no digit in the final names, they are more meaningful/uniques) [20:30:31 CEST] <ubitux> i personally prefer the second solution (because more convenient for the user -- cli at least) [20:31:13 CEST] <ubitux> which will require to just sscanf "%f|%f|%f|%f" on every region option [20:31:36 CEST] <ubitux> ...which actually brings me to the question: shouldn't we add array-like options in AVOption? [20:33:52 CEST] <beastd> ubitux: good question. such an avoption extension would probably be useful in more instances. [20:34:00 CEST] <wm4> there are already array avoptions, and unfortunately I even had to use one of them [20:35:02 CEST] <beastd> i remember sth about arrays in avoption, IIRC it came up in lavd discussions. but i may be mistaken [20:35:19 CEST] <ubitux> ah? damn i time wrapped or something, seems i missed a few changes [20:35:34 CEST] <ubitux> what's the type name? [20:36:00 CEST] <ubitux> ah, avoptionrange mmh [20:39:31 CEST] <kierank> wm4: https://ffmpeg.org/pipermail/ffmpeg-user/2015-May/026824.html [20:39:33 CEST] <kierank> lol [20:39:34 CEST] <wm4> ah I think I removed my array usage, and replaced it with something simpler and Libav compatible [20:39:54 CEST] <kierank> stream-ids aren't based on pmt's they are based on when the data appears in the stream... [20:40:00 CEST] <wm4> kierank: wait, everything is detecred as mp3? [20:40:10 CEST] <kierank> no but the stream order isn't based on what the ts says [20:40:15 CEST] <kierank> it's based on stupid probing as usual [20:40:26 CEST] <wm4> ah [20:41:05 CEST] <wm4> just today I was wondering how to stop libavformat from detecting ELF files as mp3 [20:41:09 CEST] <wm4> probing sure is a mess [20:43:12 CEST] <kierank> poor user [20:44:50 CEST] <JEEBsv> every now and then I decide to see if I can care enough to make lavf's mpeg-ts demuxer support PID switching. But then I always lose my will to poke it after opening the file [20:45:41 CEST] <wm4> I remember how the mpeg-ts demuxer had issues with h264 timestamps, and the bug was actually in obscure utils.c code [20:48:08 CEST] <nevcairiel> why would someone rely on stream order anyway o.o [20:50:16 CEST] <wm4> there's no real way to identify a stream, other than the ffmpeg index [20:50:19 CEST] <wm4> which is annoying [20:50:27 CEST] <nevcairiel> in mpegts you also get the pid [20:50:31 CEST] <wm4> for some formats, like mpeg-ts, you could of course special-case it, and get the real id [20:50:49 CEST] <wm4> but for other formats, the field may just be 0 (for all streams!) or something random [20:50:52 CEST] <nevcairiel> and formats with actual headers have their order based on that [20:50:58 CEST] <nevcairiel> its just mpegts which doesnt necessarily [20:56:11 CEST] <kierank> mpegts has order in pmt [20:56:15 CEST] <kierank> that's why that user isn't happy [20:56:21 CEST] <kierank> because ffmpeg produces a random order each time [21:11:13 CEST] <durandal_1707> ubitux: what filter does? [21:11:23 CEST] <ubitux> PS selective color [21:12:15 CEST] <ubitux> http://dsp1i8etdrigy.cloudfront.net/wp-content/uploads/2011/08/4-selective-c... [21:24:39 CEST] <anoop_r> while encoding i get Past duration 0.619041 too large why? [21:26:08 CEST] <anoop_r> onybedy [21:26:13 CEST] <anoop_r> anybody [21:26:14 CEST] <anoop_r> help me [21:28:18 CEST] <nevcairiel> you need to ask in #ffmpeg, you ahve been told several times that this is the wrong channel [21:31:57 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:4c4c3d5d5abb: avcodec/libstagefright: Check for pthread_create() failure [21:31:57 CEST] <anoop_r> no body answers [21:32:04 CEST] <nevcairiel> then wait [21:32:15 CEST] <nevcairiel> that doesnt give you the right to ask here, bencause you wont get answers here either [21:32:48 CEST] <anoop_r> but its an ffmpeg bug .x265 also confiremed it [21:33:21 CEST] <JEEBsv> no, you were just told that it's ffmpeg pushing out the message [21:33:54 CEST] <anoop_r> why its logging if its not a bug [22:09:39 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:0dbea4642f92: avformat/rmenc: Remove float usage [00:00:00 CEST] --- Mon Jun 8 2015