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

Sat Dec 30 03:05:03 EET 2017

[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/d7e82b622cf0fe951ef10fe6af007bfb967c6334
[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/da2f48236ae224a25577e05252ca234ff88fe77c
[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/ac4930eaf26053c3734ac1c8f47846542c52d7d5
[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