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

[burek]

[00:01:33 CET] <jamrial> how would you give them visibility? writing a blog post detailing their usage, like ubitux did for palletegen/use?
[00:02:07 CET] <wm4> that would be a start
[00:02:37 CET] <Chloe> do I need anything special to test rdt/rtp, or it just in FATE?
[00:07:39 CET] <durandal_1707> wm4: which filters do same things?
[00:09:18 CET] <durandal_1707> and afir is easy to use, you just need IR files
[00:09:37 CET] <Chloe> durandal_1707: giving some cool examples of usages of all your filters might be a nice idea
[00:10:07 CET] <Chloe> people look for things they want to do, they dont look for a filter which solves their problem
[00:10:50 CET] <wm4> wtf is an IR file
[00:14:20 CET] <durandal_1707> Impulse Response
[00:14:58 CET] <durandal_1707> with FIR filtering one can do bunch of stuff
[00:17:07 CET] <durandal_1707> equalization, phase change, reverberation, etc
[00:32:53 CET] <Chloe> can someone with knowledge on how to test rtp/rdt test this: https://0x0.st/sKFi.patch (or tell me how I can do it myself)
[00:32:56 CET] <Chloe> BBB maybe?
[00:33:05 CET] <BBB> huh what?
[00:33:24 CET] <BBB> I think wbs is a better person to ask
[00:33:31 CET] <BBB> I havent touched rtp for ages :(
[00:33:51 CET] <Chloe> sorry I thought you were Ronald S. Bultje
[00:33:52 CET] <Chloe> my bad
[00:36:02 CET] <Chloe> also there's probably a better way to do this than exposing the rdt handlers
[00:36:04 CET] <jamrial> he is
[00:36:37 CET] <Chloe> ah ok
[01:32:12 CET] <BBB> Chloe: sorry, I just used to touch network stuff a lot more in the past than I do now...
[01:32:29 CET] <BBB> Chloe: peoples interest shift, and this is one that sort of fell off my radar :-/
[01:32:48 CET] <Chloe> it's alright, I'd rather have not had to look at this either :D
[03:00:08 CET] <Chloe> atomnuker: will resubmit lavc patch along with 2 extra lavf patches in 2hr or so (when they finish testing). Sorry it's going so slowly, my computer is struggling a lot
[03:20:39 CET] <Chloe> wm4: so you said that we shouldnt allow registering external codecs, but what about formats?
[03:22:35 CET] <JEEB> (32
[03:22:41 CET] <Chloe> fifo tests fail because I disallowed registering of external formats. I'm thinking about having another array for externally registered codecs, then iterating that after the internal ones
[03:23:10 CET] <Chloe> This would be fairly simple to do with the opaque pointer in the _iterate functions, but not sure if this is the best way to do it
[03:47:57 CET] <cone-178> ffmpeg 03Vishwanath Dixit 07master:26e1efb04f38: avformat/hlsenc: revamped master playlist url creation logic
[03:47:57 CET] <cone-178> ffmpeg 03Vishwanath Dixit 07master:e872befdb597: avformat/hlsenc: configurable variant stream index position in filenames
[03:47:57 CET] <cone-178> ffmpeg 03Vishwanath Dixit 07master:41e51fbcd9ed: avformat/hlsenc: creation of variant streams in subdirectories
[04:06:32 CET] <atomnuker> Chloe: no external format reg either, or we'll get something worse than external plugin codecs
[04:19:00 CET] <Chloe> atomnuker: guess the fifo test will have to be rewritten/disabled
[04:19:10 CET] <Chloe> atomnuker: what do you think?
[09:57:16 CET] <jpsollie> hello everyone, happy 2018! can somebody explain to me where the h264_vaapi profile->features mapping is done in the ffmpeg master branch? I encountered a problem whereby the stream uses unsupported features with the profile 100, but profile 77 and 66 are fine.  I want to inspect the code where it is done so I can fix it.
[09:58:34 CET] <BtbN> Somewhere in the driver.
[09:58:51 CET] <jpsollie> but if ffmpeg doesn't do it, please tell me, so I can take a step forward to libva :)
[09:58:54 CET] <jpsollie> ah
[09:58:58 CET] <jpsollie> ok, sorry
[09:59:10 CET] <jpsollie> I thought ffmpeg did it
[09:59:26 CET] <jpsollie> so I have to search the amdgpu driver then?
[09:59:34 CET] <BtbN> it just tells it to use main/high/baseline, and it does whatever it feels like
[09:59:51 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h264.c;h=a7f9a602533beb746204b748262db39bfc4434f8;hb=HEAD#l883
[10:00:59 CET] <jpsollie> all right, so it is the driver and not libva?
[10:02:27 CET] <jpsollie> anyway, thank you for your help
[10:26:14 CET] <fx159159> Hey, it was suggested to me to overwrite the AVPacket deallocation in a patch I submitted to the mailing list, how does one overwrite the deallocation correctly? Write my own av_packet_unref method?
[12:22:13 CET] <wm4> Chloe: no formats either, except libavdevice
[12:58:52 CET] <Chloe> wm4: so just remove the fifo test? seems to rely on this behaviour 
[13:04:12 CET] <wm4> what fifo test?
[13:04:45 CET] <Chloe> wm4: libavformat/tests/fifo_muxer.c
[13:05:26 CET] <wm4> first I'd ask why it even exists
[13:07:28 CET] <wm4> that's pretty annoying
[13:08:43 CET] <Chloe> it is annoying, since it seems like a pretty useful test
[13:11:37 CET] <wm4> Chloe: can't you use avformat_open_input?
[13:11:54 CET] <wm4> wait it's output
[13:12:09 CET] <Chloe> wm4: the fifo muxer is opening the muxer
[13:12:20 CET] <wm4> ok but avformat_alloc_output_context2 still can take a format directly
[13:12:29 CET] <wm4> int avformat_alloc_output_context2(AVFormatContext **ctx, AVOutputFormat *oformat,
[13:12:29 CET] <wm4>                                    const char *format_name, const char *filename);
[13:12:43 CET] <wm4> so pass &tst_failing_muxer for oformat
[13:13:38 CET] <Chloe> The fifo muxer uses av_guess_format or whatever to find the "test" muxer internally 
[13:14:07 CET] <Chloe> So you'd need to add a way for the fifo muxer to take a AVOutputFormat directly 
[13:14:36 CET] <wm4> so what's the avformat_alloc_output_context2 call for?
[13:15:12 CET] <Chloe> Isn't it just allocating the fifo muxer? 
[13:15:22 CET] <wm4> ok actually reading the code I start realizing the mess
[13:15:35 CET] <Chloe> welcome to ffmpeg 
[13:16:48 CET] <wm4> and the test muxer seems to do a lot
[13:18:48 CET] <wm4> does it ever prints its "summary"?
[13:20:36 CET] <Chloe> https://0x0.st/sPz6.txt is the output if you just noop the _register function
[13:21:17 CET] <wm4> yeah
[13:21:36 CET] <Chloe> (not unexpected)
[13:21:49 CET] <wm4> what I'm wondering, isn't there another way to test these failures (like with an existing muxer)
[13:22:25 CET] <wm4> otherwise this test muxer could just be added to lavf itself or something
[13:25:34 CET] <Chloe> adding it as ff_fifo_test_muxer would be the simplest solution maybe not the nicest though
[13:26:30 CET] <wm4> to be honest I wonder why the fifo muxer even exists
[13:26:49 CET] <wm4> but I guess it's here to stay
[13:46:59 CET] <wm4> Chloe: I think you _could_ also try to make the format settable as pointer avoption in the fifo muxer...
[13:47:21 CET] <Chloe> that seems way worse than just adding another muxer
[13:48:19 CET] <wm4> hm I don't think it's that bad
[14:37:06 CET] <Chloe> I think that's it for lavf, now just lavd and lavfi
[14:48:19 CET] <KGB> [13FFV1] 15dericed opened pull request #82: Minor edits (06master...06minor-edits) 02https://git.io/vbpyl
[15:03:50 CET] <Chloe> lavd done. Lavfi is gonna be a configure nightmare
[15:08:10 CET] <atomnuker> is lavf done too?
[15:08:20 CET] <atomnuker> with lavd support in lavf?
[15:08:23 CET] <Chloe> yes
[15:09:01 CET] <Chloe> well I just added another iter function for lavd, unless you think lavd stuff should be within the lavf iter functions
[15:09:12 CET] <wm4> uh, it has to
[15:09:36 CET] <nevcairiel> yeah it has to, lavd is basically just lavf
[15:43:30 CET] <Chloe> atomnuker: https://github.com/eintw1ck/FFmpeg I've put what I've done so far here
[15:43:42 CET] <Chloe> Got an issue with configure not configuring devices for some reason
[15:44:54 CET] <atomnuker> what do you mean? its not listing any?
[15:47:17 CET] <Chloe> the opposite, it always enables all of them
[15:47:20 CET] <Chloe> i.e. http://sprunge.us/YIHQ
[15:50:41 CET] <atomnuker> does print_enabled_components correctly skip disabled devs?
[15:51:11 CET] <atomnuker> I suggest checking what's different between lavc and lavd
[15:53:24 CET] <Chloe> atomnuker: I do the exact same 4 line change for codecs
[15:53:56 CET] <Chloe> checking if I can even disable codecs
[16:00:28 CET] <Chloe> seems like disabling codecs doesnt work either, but disabling BSFs works
[16:02:40 CET] <Chloe> I cant tell you why though, there's nothing different between BSFs, codecs, formats or devices
[16:03:34 CET] <atomnuker> put debuggint prints in that large loop which parses enable= and disable=
[16:13:47 CET] <atomnuker> maybe you need to move where disable-outdev is on that loop
[16:28:43 CET] <Chloe> ah I know why
[16:29:03 CET] <Chloe> the new list has devices as _muxer and _demuxer
[16:33:51 CET] <atomnuker> you can make a wrapper to map disable-indev in that loop if you can't find a way to fix that
[16:34:21 CET] <Chloe> yeah so this is the issue with codecs too
[16:34:39 CET] <Chloe> I was thinking to make find_things_extern take another argument as the output suffix
[16:35:01 CET] <Chloe> then change the function which outputs the array to be able to change the suffix
[16:35:17 CET] <Chloe> but mapping it in disable-*=* might be cleaner
[16:35:25 CET] <Chloe> 'cleaner' lol. it's all a hack
[16:35:54 CET] <wm4> even just rewriting the configure script in python would be a big win IMO
[16:36:05 CET] <wm4> no more emulated stacks and stuff
[16:36:19 CET] <Chloe> meson
[16:36:23 CET] <atomnuker> crap
[16:36:37 CET] <atomnuker> meson is unusable
[16:36:41 CET] <Chloe> waf
[16:36:57 CET] <Chloe> cmake
[16:37:07 CET] <Chloe> surely there's something other than shellscript chaos
[16:37:07 CET] <atomnuker> "meson: oh no you can't reconfugre, you've already done so, EVEN THOUGH IT ERRORED OUT, delete build dir"
[16:37:48 CET] <wm4> atomnuker: that's the only reason?
[16:38:19 CET] <atomnuker> apparently you can't depend on libraries NOT installed in /usr/local or /usr
[16:38:30 CET] <atomnuker> even if you supply a pkg_config_path
[16:39:16 CET] <atomnuker> waf is impractical if you want to distribute source code only since you'll either need internet connection to download the waf binary or carry the binary
[16:39:44 CET] <Chloe> isnt it just a python bundle?
[16:39:45 CET] <atomnuker> (python bytecode but still binary)
[16:39:53 CET] <Chloe> which can be put in a tarball easily
[16:40:06 CET] <Chloe> and if people are dl-ing from git then they have an internet connection anyway
[16:40:06 CET] <BBB> /leave #build-tools /join #multimedia-channel
[16:40:15 CET] <BBB> :-p
[16:40:33 CET] <wm4> waf expects you to provide the binary blob with the source
[16:40:57 CET] <wm4> (in mpv we just download it instead, which is not "proper")
[16:41:22 CET] <Chloe> BBB: if the build system was sane then it wouldnt break everything with every minor change
[16:41:36 CET] <BBB> are there sane build systems
[16:41:46 CET] <BBB> some are featureful but bloated as crap
[16:41:48 CET] <wm4> I keep looking for them
[16:41:56 CET] <Chloe> I haven't found one yet
[16:42:03 CET] <BBB> others are more shiny and sleek, but can barely zip up their own pants
[16:42:22 CET] <BBB> I think our configure script was an attempt by diego/mans to find a middle road that works for us
[16:42:27 CET] <BBB> and that really worked out well, didnt it
[16:42:49 CET] <BBB> so my feel is that this is an unsolvable problem and I dont care anyway, so I ignore it and do more itnerestinh things ;)
[17:01:01 CET] <atomnuker> well I'm glad no one suggested cmake
[17:01:58 CET] <atomnuker> or as I like to call it -DWHOEVER_THOUGHT_OF_THIS_ATE_CRAYONS=ON
[17:02:27 CET] <Chloe> 15:36:57 <Chloe> cmake
[17:02:55 CET] <j-b> BBB: yes, meson
[17:03:32 CET] <BBB> doesnt libaom use cmake?
[17:03:32 CET] <Chloe> atomnuker: I just use this https://github.com/nemequ/configure-cmake/blob/master/configure
[17:03:55 CET] <Chloe> it's a pretty interface for cmake, works nicely
[17:05:15 CET] <atomnuker> neat, the configure system which takes longer to compile than gcc needs a shell script to be functional
[17:06:22 CET] <Chloe> eh, not really. you can just use cmake, though I like to use the wrapper
[17:06:33 CET] <atomnuker> all this talk about configure systems just makes me think our slow complicated configure script is the most functional
[17:06:55 CET] <nevcairiel> it should just be written in an actual script language
[17:07:00 CET] <nevcairiel> and it would probably be ok
[17:07:01 CET] <sfan5> i'm sure it would be much faster if you rewrote it in Python
[17:07:21 CET] <atomnuker> python is crap, have you seen waf?
[17:07:34 CET] <sfan5> right
[17:07:41 CET] <Chloe> what would you write it in then
[17:07:44 CET] <sfan5> ^
[17:07:46 CET] <wm4> SHELL
[17:07:50 CET] <nevcairiel> thats like  saying C is crap because X is written in C
[17:07:57 CET] <nevcairiel> how does the language relate to some project written in it
[17:08:10 CET] <atomnuker> no, I'm saying python is woefully inadequate to make a build system
[17:08:13 CET] <Chloe> There's always rust.
[17:08:15 CET] <atomnuker> and to configure a build system
[17:08:17 CET] <atomnuker> LUA!
[17:08:18 CET] <nevcairiel> shell is far worse
[17:08:27 CET] <atomnuker> we should use lua
[17:08:38 CET] <sfan5> does lua even have a popen-equivalent?
[17:08:53 CET] <Chloe> If you want to use lua then you may as well write an external and separate build system, then use that in ffmpeg
[17:09:01 CET] <wm4> bare lua is... too bare
[17:09:03 CET] <sfan5> nevcairiel: configure's task involves lots of interaction with shell-like programs and python is admittedly not good at that
[17:09:14 CET] <atomnuker> io.popen
[17:09:37 CET] <nevcairiel> what do you really need to make a configure replacement? string processing, the ability to invoke external commands and process their output, and some typical primitive data structures. shell fails at two of those
[17:11:30 CET] <Chloe> durandal_1707: is there a filter to tile an image to a specified size?
[17:11:59 CET] <durandal_1707> Chloe: tile?
[17:12:46 CET] <atomnuker> what's fascinating about our configure script was that it was used in libvpx and libaom
[17:13:09 CET] <Chloe> durandal_1707: display the image multiple times side by side to fit the specified size
[17:13:16 CET] <atomnuker> libaom got cmake support half a year ago though but still everyone uses the configure script mostly
[17:13:53 CET] <iive> i don't like cmake... 
[17:14:10 CET] <atomnuker> no one does
[17:14:13 CET] <nevcairiel> cmake is ok for very simple things, but it can grow out of control
[17:14:48 CET] <wm4> atomnuker: some do
[17:15:57 CET] <iive> i don't like having to hunt what env var i have to change, for each different project... or not having consistent way to enable or disable things...
[17:20:03 CET] <durandal_1707> Chloe: tile filter? or hstack and vstack with crop?
[17:21:36 CET] <Chloe> latter looks like, thanks
[17:40:44 CET] <chance> trying to understand the purpose of this initial padding
[17:40:50 CET] <chance> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/aacenc.c#L970
[17:41:16 CET] <chance> shouldn't this be configured based on pre_skip in codecpar?
[17:41:39 CET] <nevcairiel> no, the encoder controls the initial padding
[17:41:55 CET] <nevcairiel> the caller cannot be expected to know how much a certain codec might need
[17:48:01 CET] <chance> @nevcairiel how will this work for segmented audio?
[17:48:13 CET] <chance> it will inject 1024 samples into each segment?
[17:48:33 CET] <Chloe> (you dont need the @ btw)
[17:48:43 CET] <chance> uggg
[17:48:49 CET] <chance> HipShat.  Sorry
[17:48:59 CET] <nevcairiel> no, the encoder is not restarted for each segment, it outputs a continous stream thats split apart later
[17:51:55 CET] <jugnoo> Does anyone happen to know why inband FEC option is not supported by libopus wrapper in ffmpeg while the packet_loss option is supported?
[17:51:58 CET] <chance> nevcairiel... why is this 1024 samples needed?
[17:52:49 CET] <jugnoo> Looking into the code of encoder wrapper ~/libavcodec/libopusenc.c the line ret = opus_multistream_encoder_ctl(enc, OPUS_SET_PACKET_LOSS_PERC(opts->packet_loss)); sets up the packet loss percentage in libopus but there is no reference to OPUS_SET_INBAND_FEC(...) libopus control in the wrapper.
[17:53:25 CET] <jugnoo> Also looking into libopus the packet loss is used in conjunction with FEC settings i.e from opus/src/opus_encoder.c 
[17:53:52 CET] <jugnoo> <snip> /* When FEC is enabled and there's enough packet loss, use SILK */  if (st->silk_mode.useInBandFEC && st->silk_mode.packetLossPercentage > (128-voice_est)>>4)           st->mode = MODE_SILK_ONLY; <snip>
[17:54:44 CET] <jugnoo> setting one and not being able to set the other would seem to be moot or am I reading it wrong!!!!!
[17:55:49 CET] <wm4> nevcairiel, wbs: do you think it'd be ok if I sent a patch that always calls WSAStartup on demand, and removes all calls to WSACleanup?
[17:56:21 CET] <wm4> my goal is that the user doesn't need to call avformat_network_init() (it handles TLS, and this win32 thing)
[17:57:09 CET] <Chloe> atomnuker: after I work out how to send emails from wsl, I'll send my updated set
[17:57:18 CET] <Chloe> (after it finishes testing as well)
[18:17:51 CET] <durandal_1707> atomnuker: no i can not reuse it
[18:23:13 CET] <durandal_1707> its float, i want double
[18:23:23 CET] <atomnuker> why do you want double?
[18:24:09 CET] <durandal_1707> number of coefficients differ between nominator and denominator
[18:24:38 CET] <durandal_1707> also my code is nicer
[18:24:53 CET] <atomnuker> yeah, I'll give you that
[18:25:03 CET] <durandal_1707> double is for all us audiophiles
[18:25:23 CET] <atomnuker> double halves simd throughput
[18:25:46 CET] <atomnuker> at least its not long double
[18:26:02 CET] <durandal_1707> atomnuker: still very fast, also i will use long double
[18:26:58 CET] <durandal_1707> more bits for golden ears
[18:28:04 CET] <durandal_1707> atomnuker: move/copy fft from lavc to lavu and make it faster @/
[18:30:17 CET] <atomnuker> doesn't lavfi use av_fft?
[18:30:22 CET] <atomnuker> which is in lavc
[18:31:09 CET] <durandal_1707> yes, so move to lavu
[18:32:30 CET] <atomnuker> yeah alright, will do it after atrac9
[18:38:05 CET] <atomnuker> might as well move both mdcts and ffts, I need the mdct for the rnnoise
[19:41:28 CET] <durandal_1707> atomnuker: also high order iirs need more bits, thats why they usually cascade 2nd order to create similar effect
[19:44:20 CET] <cone-554> ffmpeg 03Paul B Mahol 07master:92b32664cdc0: avcodec/utvideodec: add support for UMH2, UMY2, UMH4, UMY4, UMRA, UMRG
[19:44:20 CET] <cone-554> ffmpeg 03Paul B Mahol 07master:57d0c24132c5: avcodec/utvideoenc: switch to planar RGB formats
[20:11:43 CET] <durandal_1707> atomnuker: how much time of a day you spent on atrac9?
[20:45:56 CET] <wbs> wm4: that's probably ok. but you can probably still call WSACleanup as well, at least for cases where you have a clear context for it
[20:49:32 CET] <wm4> hm I can see if there's an obvious way to do it
[20:51:08 CET] <nevcairiel> opening/closing tcp/udp protocols?
[20:51:15 CET] <nevcairiel> when else is it even needed?
[20:52:18 CET] <wbs> the rtsp (or was it sdp?) code does some amount of getaddrinfo/getnameinfo outside of the tcp/udp protocols, so at least within rtsp/sdp you'd need a separate enclosing init/cleanup for it
[20:57:47 CET] <RiCON> stevenliu: can you select which representation you want in dashdec?
[21:12:16 CET] <wm4> wbs: seems to call ff_network_init
[21:12:52 CET] <wm4> most things do it indirectly via URL_PROTOCOL_FLAG_NETWORK
[21:12:59 CET] <wm4> (then avio.c calls ff_network_init)
[21:16:24 CET] <atomnuker> durandal_1707: 3, 4 days now
[21:16:32 CET] <atomnuker> I can read all scalefactors!
[21:17:02 CET] <atomnuker> still need to do that sbr thing, balance them according to the bit allocation and then read the spectral coeffs
[21:17:40 CET] <atomnuker> I can't imagine how slow the encoder should be
[21:18:00 CET] <atomnuker> if it does sbr correctly
[21:18:13 CET] <durandal_1707> encoder is faster than realtime
[21:18:38 CET] <atomnuker> since the packets need to be aligned to 8 bits to the packet size per second specified in the header
[21:19:00 CET] <atomnuker> they probably do multiple encodes to figure out the correct amount of quantization
[21:24:54 CET] <atomnuker> the whole codec's design was as if someone explained AAC-HE to someone over the phone but because they didn't need to keep backwards compat they were smart about it
[21:26:13 CET] <durandal_1707> :)
[21:26:47 CET] <Chloe> ah. I see the issue with separating lavd from lavf now
[21:27:06 CET] <Chloe> all the code depends on devices being formats
[21:27:48 CET] <durandal_1707> awful code
[21:28:05 CET] <Chloe> yeah there's actually no way around this
[21:32:12 CET] <wm4> Chloe: one suggestion was to have an avpriv function that registers the lavd list by setting a pointer to an array
[21:32:35 CET] <wm4> this would complicate iteration somewhat, but can still be handled
[22:02:39 CET] <durandal_170> im best dev you will ever have
[22:03:00 CET] <wm4> ok
[22:12:10 CET] <rcombs> I dunno, my dad's got a friend named dev and he's pretty cool
[22:12:33 CET] <durandal_170> :)
[00:00:00 CET] --- Wed Jan  3 2018