[01:48:52 CET] <tmm1> i'm trying to figure how the new decoder api handles m:n.. how would i return two frames from receive_frame for one incoming packet? [01:59:14 CET] <cone-253> ffmpeg 03Carl Eugen Hoyos 07master:e867b7b11a28: fate: Fix ffprobe dependency for fate-mov-guess-delay-*. [02:02:02 CET] <atomnuker> tmm1: from inside lavc? populate the new avcodec pointers and use them [02:05:18 CET] <atomnuker> I think that we should stop accepting any codecs using the old api now [02:05:57 CET] <atomnuker> and return an error during init if someone tries to use the old api with new codecs [02:06:07 CET] <BtbN> tmm1, the decoder api is a bit weird. You basically just don't pull a new packet. [02:06:21 CET] <BtbN> So only pull a new packet on every second call to receive_frame [02:09:34 CET] <tmm1> ok i got it working [02:09:55 CET] <tmm1> trying to convert mediacodecdec.c over to the new api [02:15:23 CET] <cone-253> ffmpeg 03Carl Eugen Hoyos 07master:d01eeef4a229: configure: libvmaf depends on pthreads. [02:18:18 CET] <tmm1> hmm its leaking somewhere [02:41:27 CET] <tmm1> i guess somehow the old api works just as well.. if you call receive_frame multiple times it must emulate it via the old decode callback [02:47:23 CET] <tmm1> oops never mind [04:11:22 CET] <philipl> cd /storage/video/tv/Sasuke/ [04:11:23 CET] <philipl> ls [04:11:27 CET] <philipl> argh [05:26:46 CET] <vlad_> hello! for some reason avcodec_descriptor_get_by_name doesn't seem to know about h264_nvenc [05:26:55 CET] <vlad_> the ffmpeg binary takes -c:v h264_nvenc just fine [06:31:28 CET] <wm4> vlad_: that describes codecs in general, not individual implementations [07:43:40 CET] <cone-558> ffmpeg 03Karthick Jeyapal 07master:9e25fe420410: avformat/hlsenc: Modularized audio rendition playlist write to allow reuse [07:43:40 CET] <cone-558> ffmpeg 03Karthick Jeyapal 07master:8fd2bdd07207: avformat/hlsplaylist: Audio rendition's name and defaultness made configurable [07:43:40 CET] <cone-558> ffmpeg 03Karthick Jeyapal 07master:5297ae96a13f: avformat/dashenc: Addition of #EXT-X-MEDIA tag and AUDIO attribute [11:13:39 CET] <cone-536> ffmpeg 03Karthick Jeyapal 07master:e8f71ef33899: avformat/hlsenc, utils: Moved is_http_proto from hlsenc to utils for re-use [11:13:39 CET] <cone-536> ffmpeg 03Karthick Jeyapal 07master:0c78b6a416c6: avformat/dashenc: Persistent HTTP connections supported as an option [12:55:04 CET] <wm4> "[WARNING! RECEIVED FROM EXTERNAL SENDER]" that's a new one [12:55:49 CET] <wm4> actually not the first one from an akamai dev heh [14:26:22 CET] <vlad_> wm4: ah I suspect I should be using avcodec_find_encoder_by_name instead? [14:27:42 CET] <nevcairiel> it depends what you want to achieve, those functions do quite different things [14:30:21 CET] <wm4> vlad_: that's probably what you want if you want to explicitly select and use the nvenc thing [14:32:08 CET] <vlad_> yeah right now I am using avcodec_find_encoder(codec_id) where codec_id is one of output_format->video_codec or codec_desc->id [14:32:47 CET] <vlad_> codec_desc is returned by avcodec_descriptor_get_by_name [14:33:08 CET] <wm4> both codec_desc and codec_id just describe the video format [14:34:33 CET] <vlad_> right, and find_encoder gives me the default for that format? [14:35:39 CET] <wm4> yes [15:44:54 CET] <vlad_> ok, so that worked, but now I'm getting "Failed to init cuda." under specific circumstances [15:45:22 CET] <vlad_> it's very strange because if I just run my program plainly it works (video encodes) [15:45:42 CET] <vlad_> but when I run it as a python subprocess as part of a larger thing the cuda error happens [15:46:06 CET] <wm4> nvidia only allows 2 transcodes at a time, is it this? [15:46:35 CET] <BtbN> You'd get a different error then though [15:46:45 CET] <vlad_> maybe? my other process is using tensorflow, but only the cpu version [15:46:52 CET] <BtbN> Failed to init cuda is cuInit() returning unsuccessful [15:47:05 CET] <BtbN> Which should never happen unless something on your system is broken [15:47:19 CET] <vlad_> as I said, it only happens under very specific circumstances [15:48:01 CET] <vlad_> it doesn't occur if I make a small python script that runs my program in a subprocess [15:48:53 CET] <vlad_> oh wait I think I know what's going on, my other program sets CUDA_VISIBLE_DEVICES="" to stop itself from taking the gpu [15:49:23 CET] <vlad_> which might be affecting the subprocess's environment as well [15:50:28 CET] <vlad_> yup that was it! [17:01:32 CET] <kierank> durandal_1707: can you review my patch [17:33:57 CET] <durandal_1707> kierank: its very clean patch [17:34:10 CET] <kierank> durandal_1707: s->block2 is ugly though [17:34:30 CET] <kierank> and it will need more work for dpcm because dpcm allows weird directions [18:26:27 CET] <iive> kierank: if you accept hacks, you can have `short blocks[16][128] ` instead of `int blocks[16][64]` [18:26:55 CET] <kierank> iive: causes a LOT of function prototypes to need changing [18:27:34 CET] <iive> yeh [18:27:49 CET] <kierank> a union would be best i think [18:28:09 CET] <iive> unions have bad rap with compiler optimizations [18:30:45 CET] <wm4> can we move the git server to github or something? the performance of the current server is pathetic [18:30:58 CET] <wm4> do I really have to wait half a minute for git pull [18:32:35 CET] <wm4> forget half a minute it just freezes [18:34:12 CET] Action: wm4 sighs and adds github mirror remote [18:34:35 CET] <kierank> wm4: ping thresh on #videolan [18:35:01 CET] <nevcairiel> its always been slow, thats not exactly a new development [18:35:24 CET] <wm4> why is he not on this channel if he's apparently maintaining the git server [18:35:33 CET] <iive> wm4: is that happening now? coz I just did pull and it was blazingly fast. [18:36:15 CET] <wm4> tmm1: HLS with crypto is crashing in ff_http_do_new_request() [18:36:32 CET] <wm4> tmm1: because it accesses the crypto proto as http without any checks [18:36:56 CET] <wm4> tmm1: things like these is why I keep droning on and on that this should be handled in a better way, like adding a URLContext callback [18:39:55 CET] <wm4> there's probably a patch for this on the ML, but if the github mirror is up to date, it hasn't been pushed yet [18:57:37 CET] <kierank> wm4: nevcairiel: been fine for me, I wonder if it's the iliad/german isp peering thing [19:01:02 CET] <Risc1911> good evening [19:01:44 CET] <Risc1911> has anyone here successfully compiled and run ffmpeg 3.4 with libndi_newtek on Ubuntu 16.04 Xenial? [19:02:35 CET] <Risc1911> i got the sdk and it compiled clean but: "ffmpeg -f libndi_newtek -find_sources 1 -i dummy" does not find any sources (yes i ahve multiple sources running) [19:02:56 CET] <Risc1911> are there any other tests i can do to debug this issues? [19:06:52 CET] <wm4> kierank: it can't seem to connect here [19:07:24 CET] <wm4> ping doesn't get back either [19:09:00 CET] <wm4> ah with --ipv4 it works [19:14:13 CET] <wm4> and the dashenc.c is broken in similarly funny ways [19:14:19 CET] <wm4> +commit [19:14:38 CET] <wm4> I mean I don't know a case where it's actually broken, but you can tell it's fragile [19:14:55 CET] <wm4> there's no reason to write code like that [19:25:41 CET] <durandal_1707> devs are lazy [19:28:16 CET] <Compn> Risc1911 : do any other libndi newtek programs work to display sources ? [19:44:37 CET] <Tzimmo> Why does the order of detected subtitles in a vob file change if I set for example -analyzeduration 1G -probesize 100M ? [19:45:20 CET] <Tzimmo> They must be in some certain order in the vob file and I though that would be the order where they are detected, but it seems to change when those parameters are changed. [19:47:42 CET] <Tzimmo> This makes generating overlay subtitles using -filter_complex "[0:v][0:s:5]overlay[v]" quite impossible because that number (5) should be changed to 0 for this specific file if I omit -analyzeduration and -probesize. [19:48:47 CET] <Tzimmo> I tried "[0:v][0:s:#0x24]overlay[v]" as well but it always selected subtitle index 0 instead of the one with id 0x24... was there a way to choose a subtitle with a specific ID using this format? [19:49:55 CET] <durandal_1707> does anyone knows what new fourcc does in utvideo? [20:40:14 CET] <tmm1> wm4: do you have the backtrace or a sample playlist? [20:41:09 CET] <tmm1> wm4: i dont understand what you mean by "URLContext callback". like a struct member thats a function pointer? [20:42:23 CET] <wm4> tmm1: "mpv http://southpark.cc.com/full-episodes/s21e07-doubling-down" seems to trigger it (via youtube-dl and some weird contraption through EDL, but seems obvious in the debugger) [20:42:59 CET] <wm4> tmm1: as URLProtocol member or so, I guess, like everything else [20:44:17 CET] <tmm1> one problem is you dont know if the aviocontext is wrapping urlcontext or not without checking protocol first [20:49:51 CET] <wm4> then you obviously need to add a callback to AVIOContext to pass it through [20:50:26 CET] <wm4> like e.g. read_pause and all that obscure stuff [21:00:41 CET] <nevcairiel> that you dont know if an AVIOContext holds a particular URLContext is the source of all that trouble [21:00:56 CET] <nevcairiel> and all the guesses are just that - guesses [21:01:48 CET] <wm4> and normally nothing guesses at all [21:02:08 CET] <wm4> also I still haven't understood why the HLS code explicitly checks for custom AVIO contexts... [21:02:27 CET] <nevcairiel> probably for that re-usable http hackfest [21:03:05 CET] <wm4> no, it was there before [21:03:29 CET] <wm4> possibly related to setting/getting cookies? [21:53:12 CET] <tmm1> it would be nice if AVIOContext contained the name of the protocol it was wrapping, i.e. http or crypto or tls [21:53:34 CET] <tmm1> i tried to add it but there's so many layers i can't figure it out [21:55:07 CET] <tmm1> ffurl_open* don't even have access to AVIOContext anymore to add members to it [21:55:18 CET] <wm4> tmm1: checking a name is the opposite I'm arguing for [21:56:05 CET] <wm4> I mean come on [21:56:09 CET] <tmm1> ok but same thing applies for any other property [21:56:52 CET] <wm4> you want to look at ffio_fdopen [21:57:06 CET] <wm4> which has a bad name and really wraps an URLContext as AVIO [21:57:14 CET] <wm4> (why does this AVIO crap even exist...) [21:57:47 CET] <wm4> there are clearly too many wrappers wrapping wrappers [21:59:15 CET] <Compn> Tzimmo : did you read dvd spec ? also lots of non-standard dvds :( [21:59:46 CET] <Compn> durandal_1707 : i feel like we should have better contact with utvideo and other codec developers :\ [22:15:13 CET] <tmm1> wm4: is this what you mean https://github.com/tmm1/ffmpeg/commit/d7e82b622cf0fe951ef10fe6af007bfb967c63... [22:16:24 CET] <wm4> tmm1: absolutely not [22:18:14 CET] <durandal_1707> Compn: stop wasting my time! [22:18:28 CET] <wm4> it's a bit better than previous ideas, but hls should simply not have to include http.h at all [22:18:53 CET] <wm4> and instead call that function through function ptrs [22:32:14 CET] <tmm1> wm4: https://github.com/tmm1/ffmpeg/commit/da2f48236ae224a25577e05252ca234ff88fe7... [22:35:54 CET] <wm4> tmm1: yeah, that's what I was thinking of [22:36:48 CET] <wm4> though to be more in line with the existing url code, it should be a callback in URLProtocol [22:36:59 CET] <tmm1> yea let me see if i can move it [22:37:31 CET] <wm4> (instead of URLContext) [22:37:50 CET] <tmm1> also trying to come up with a better name [22:37:55 CET] <tmm1> maybe url_open_another [22:39:36 CET] <wm4> I think the name is sort of ok [22:39:59 CET] <tmm1> https://github.com/tmm1/ffmpeg/commit/ac4930eaf26053c3734ac1c8f47846542c52d7... [22:40:03 CET] <tmm1> moved to URLProtocol [22:41:26 CET] <wm4> is that patch still incomplete? [22:41:42 CET] <tmm1> i don't think so? [22:41:45 CET] <tmm1> it compiles and works [22:41:54 CET] <wm4> so where is the new callback called? [22:42:10 CET] <tmm1> line 620 of hls.c [22:42:25 CET] <wm4> oh right [22:42:56 CET] <tmm1> i guess i should split into two commits [22:43:22 CET] <wm4> a bit sketchy that it uses ffio_geturlcontext [22:44:05 CET] <wm4> yeah I think it'd be better if you changed the callback to take an AVIOContext arg instead of URLContext [22:44:10 CET] <tmm1> hmm yea.. should i make the invocation (*pb)->new_http_request(*pb, url) and do it internally [22:44:11 CET] <wm4> because there's no reason to [22:44:37 CET] <wm4> you'd probably annoyingly need a stub to redirect the call, but IMO better to do this [22:45:18 CET] <wm4> then hls.c wouldn't deal with URLContext anymore at all [23:00:54 CET] <tmm1> wm4: https://github.com/tmm1/ffmpeg/compare/http-uc-flag.patch [23:03:27 CET] <wm4> tmm1: LGTM so far (I wonder if some things could be refined) [23:04:27 CET] <tmm1> ok i'll send to the list to see if anyone else has suggestions [23:06:11 CET] <wm4> I'm mostly wondering if open_url_keepalive couldn't fall back to io_open itself, instead of having the caller do that [23:06:48 CET] <wm4> though one of the two callers is strange (why is there even a "#if 1") [23:07:56 CET] <tmm1> yea the playlist path is weird [23:10:26 CET] <tmm1> wm4: thanks for the help, definitely much cleaner now [23:10:57 CET] <Tzimmo> Compn: No, but still cannot understand how analyzeduration and probesize could change the order of subtitles when the source file (.vob dump) does not change. [23:57:39 CET] <Compn> Tzimmo : these are 1gb vob files, with a film spanning multiple vobs ? [23:58:02 CET] <Compn> Tzimmo : it might be better to use a different program to rip out the vobsubs first ? if thats possible for your situation [00:00:00 CET] --- Sat Dec 30 2017