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

[burek]

[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-color-explained.gif
[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