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

[burek]

[00:06:20 CET] <Chloe> How does lavd depend on lavf? (like where in the build system is this specified?) 
[00:11:47 CET] <jkqxz> Isn't it just the lavfi input which depends on lavfi, not lavd as a whole?  (Which is <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=606cdd0004ea8b2b4f282899efdcc9008b2eb3ce;hb=HEAD#l3107>.)
[00:13:18 CET] <Chloe> jkqxz: https://0x0.st/sP2w.txt this is the source of my confusion 
[00:13:51 CET] <Chloe> (and pretty sure the whole of lavd depends on lavf considering it uses av_oformat_next() etc atm) 
[00:14:44 CET] <Chloe> Those functions are new api functions I've written and are just in alldevices.c
[00:15:05 CET] <Chloe> It links fine into ffmpeg_g and all the tools but not that test
[00:15:18 CET] <jkqxz> Bleh, I confused lavf and lavfi.
[00:15:42 CET] <jkqxz> Then it's <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=606cdd0004ea8b2b4f282899efdcc9008b2eb3ce;hb=HEAD#l3332>.
[00:17:55 CET] <Chloe> jkqxz: do you know if it would be possible to make lavf depend on lavd (if lavd was enabled) 
[00:18:19 CET] <nevcairiel> that sounds rather backwards, lavd depends on lavf
[00:18:23 CET] <jkqxz> The dependencies need to be acyclic for linking to work.
[00:20:12 CET] <jkqxz> atomnuker:  There, that can do silly transitions as well.
[00:21:53 CET] <Chloe> ehh. ok
[00:22:11 CET] <Chloe> I guess I can initialise lavf from lavd if lavd is enabled
[00:22:53 CET] <Chloe> I lied, I cant.
[00:26:48 CET] <Chloe> https://github.com/eintw1ck/FFmpeg/blob/master/libavformat/allformats.c#L504 could someone take a look at this. `make ffmpeg` links and works, but `make fate-api-seek` doesnt link despite using the exact same commandline (apart from some extra objects in ffmpeg one, but I checks the symbols in those objects and they dont have either of the missing functions in them).
[00:31:17 CET] <wm4> I'm not sure if you really can get away with a circular dependency, but dunno
[00:34:44 CET] <Chloe> https://0x0.st/sP2d.txt make ffmpeg and make-fate-api-seek commandlines alone with the extra symbols
[00:35:15 CET] <Chloe> wm4: I was thinking I could move that init function into lavd if lavd was enabled, but then lavf cant call it with the pthread_once stuff anyway
[00:36:25 CET] <Chloe> the other alternative is to move all the functions which call av_format_next_init into lavd if lavd is enabled
[00:36:43 CET] <nevcairiel> i can already tell you that such a patch will never fly
[00:37:49 CET] <nevcairiel> we should just add mutexes to the register function, delete the atomics, and leave unstable time already
[00:37:50 CET] <wm4> I still think lavd should register itself with an avpriv function that sets an array ptr in lavf
[00:38:19 CET] <nevcairiel> we have statix mutexes now, afterall
[00:38:22 CET] <nevcairiel> static*
[00:38:38 CET] <wm4> and have the iteration functions switch over to that array when it's set and you're at the last lavf item
[00:39:56 CET] <Chloe> nevcairiel: what really needs to happen is for devices to stop being in lavf
[00:40:13 CET] <Chloe> that actually fixes everything
[00:40:32 CET] <nevcairiel> feel free to work on that for the next 2 years, what we need is something now to drop the atomics
[00:41:46 CET] <Chloe> if we're bumping major anyway cant we just remove devices from lavf
[00:43:10 CET] <nevcairiel> even with a bump breaking things over night and expecting people to use something brand new is rather bad form
[00:44:06 CET] <wm4> we could merge lavf and lavd into 1 lib, but even that seems somewhat controversial
[00:44:13 CET] <Chloe> people will cry for a short while, but there's just no way to fix this slowly
[00:44:28 CET] <Chloe> merging lavf and lavd is the only way to fix this slowly
[00:44:44 CET] <Chloe> but I figured that's just as bad as a sudden change
[00:45:08 CET] <wm4> would what I suggested not work
[00:45:33 CET] <nevcairiel> there is no pressing reason to really break it right now, the only pressing thing right now is cleaning up the old atomics, which this all degraded from
[00:46:57 CET] <Chloe> wm4: maybe
[00:48:37 CET] <jkqxz> The libav suggestion was to just dump lavd into avconv/ffmpeg.  Pretty much all of the use-cases are there; library use of it is not particularly sane.
[00:49:47 CET] <Chloe> wm4: yeah actually, it would work.
[00:50:58 CET] <jkqxz> Does it still work if lavd is dynamically loaded later on?
[00:51:00 CET] <wm4> jkqxz: heh, that's somewhat true, but the problem is still that ffmpeg.c requires the demuxer API for all reading
[00:51:29 CET] <wm4> Chloe: and "what I suggested" meaning that stuff about using an avpriv function?
[00:51:55 CET] <Chloe> jkqxz: yes it would
[01:10:12 CET] <Chloe> wm4: yeah that fixes it
[01:10:16 CET] <Chloe> passes
[01:10:49 CET] <wm4> so how exactly does it work now?
[01:11:23 CET] <Chloe> wm4: https://github.com/eintw1ck/FFmpeg/commit/faca84969654968e0390c5a88890839507d40735
[01:11:42 CET] <Chloe> lavf stores a pointer to lavd's arrays
[01:12:04 CET] <Chloe> which is passed in through an avpriv function when lavd is initialised
[01:12:20 CET] <Chloe> lavf is then reinitialised with the lavd components
[01:15:14 CET] <wm4> why reinit?
[01:20:34 CET] <Chloe> I mean, it just adds them to the linked list
[01:22:24 CET] <jamrial> if we're doing this, might as well take the oportunity to rewrite lavd from scratch so it may stop being a lavf hack :p
[01:22:54 CET] <iive> +1
[01:23:44 CET] <Chloe> these changes allow the beginning of that
[02:37:20 CET] <atomnuker> jkqxz: oh cool
[02:37:25 CET] <atomnuker> can you add -opencl_device too?
[02:37:58 CET] <atomnuker> actually what would happen if you used different devices for vaapi and opencl? e.g. an intel and an amd?
[02:38:39 CET] <atomnuker> would you need hwmap or would mesa be smart enough to transfer it somehow?
[02:45:07 CET] <jamrial> rcombs: does that audiotoolboxenc patch look good?
[02:47:59 CET] <rcombs> jamrial: looks fine
[02:49:07 CET] <jamrial> rcombs: ok, will apply it then
[03:02:56 CET] <jamrial> rcombs: nevermind, sent a review about a small issue
[04:00:04 CET] <stevenliu> RiCON: cannot right now, dashdec not support multi bitrate now
[05:09:28 CET] <Darkie__> hey, im using github.com/filoe/cscore which binds to ffmpeg. Im using it on a linux machine and it outputs some weird logs (https://i.imgur.com/rix3Pfd.png). my tool and csc dont do such things, any ideas where those could come from?
[09:19:50 CET] <mistym> Argh, only just noticed I forgot to include a changelog with a patchset I submitted until after git send-email finished.
[10:35:20 CET] <nevcairiel> ana
[10:35:22 CET] <nevcairiel> woops
[13:38:36 CET] <KGB> [13FFV1] 15dericed opened pull request #84: use version variable in makefile (06master...06use-version-variable-in-makefile) 02https://git.io/vbjVo
[13:47:42 CET] <durandal_1707> you can use afir filter for binauralization too
[14:37:10 CET] <KGB> [13FFV1] 15dericed opened pull request #85: line breaks and formula formatting (06master...06line-breaks) 02https://git.io/vbj63
[14:41:03 CET] <jkqxz> atomnuker:  Different devices can work together transparently (after all, that was the original intent of DRM PRIME), but there may be incompatibilities because of different layouts.
[14:41:43 CET] <wm4> format negotiation horror?
[14:41:45 CET] <jkqxz> For the one case I can test, exporting Mesa (AMD) -> Beignet (Intel) does work, but that is probably helped by the Mesa stuff all exporting linear because it doesn't have the metadata to do anything else.
[14:42:19 CET] <wm4> isn't vaapi/drm also linear? (or is that due to magical untiling)
[14:42:25 CET] <jkqxz> I imagine it would probably fail in the opposite direction, but Clover (Mesa OpenCL) doesn't support enough for it to work.
[14:44:15 CET] <jkqxz> VAAPI on Intel is usually Y-tiled, but you can map it as linear via an untiler in the MMU.  (It also supports X-tiled (what Beignet normally uses) for some things, but can't do codec operations on it and therefore generates extra copies where it can to paper over the holes in the abstraction.)
[14:44:34 CET] <wm4> interesting
[14:45:15 CET] <jkqxz> Wrt negotiating this stuff, it's what the semi-mythical Unix Device Memory Allocator project is meant to solve.
[14:45:21 CET] <jkqxz> So maybe in a few more years...
[14:46:12 CET] <wm4> that thing that solves all problems with nvidia too?
[14:46:20 CET] <wm4> (alleged)
[14:46:29 CET] <jkqxz> Yeah.
[15:12:57 CET] <KGB> [13FFV1] 15retokromer opened pull request #86: fix alignment in pseudo-code (06master...06patch-1) 02https://git.io/vbjXb
[17:10:18 CET] <kierank> michaelni: are you aware of any crashes in h264 pred_spatial_direct_motion
[17:11:40 CET] <kierank> 4:11:16 PM <"funman> (gdb) print l1mv0[0]
[17:11:40 CET] <kierank> 4:11:16 PM <"funman> Cannot access memory at address 0x7ffff8353de0
[17:41:19 CET] <Chloe> wm4: do you know if AVInputFormat->next is guaranteed to be null? this is the only reason I'm setting it. I wasn't sure if it was
[17:42:42 CET] <wm4> why wouldn't it? anything declared globally is 0 inited by default
[17:43:10 CET] <wm4> including the case when you init structs with an initializer, but don't explicitly set a field
[18:46:42 CET] <TheAlexBarney> atomnuker, to answer your wonderings about the atrac9 encoder:
[18:46:59 CET] <TheAlexBarney> The encode time can take an order of magnitude longer when enabling SBR
[18:46:59 CET] <atomnuker> hey you're back
[18:47:30 CET] <atomnuker> I still don't understand what band extension is
[18:47:36 CET] <atomnuker> what is the band extension data for?
[18:48:04 CET] <TheAlexBarney> Yeah, I ended up posting what work I've done on a C port of the decoder yesterday
[18:48:59 CET] <TheAlexBarney> In a nutshell, indexes into a table of coefficients for adjusting the high spectral coefficients
[18:49:34 CET] <atomnuker> so bit allocation then
[18:49:52 CET] <atomnuker> shouldn't it touch the scalefactors then?
[18:49:55 CET] <TheAlexBarney> Not bit allocation
[18:50:00 CET] <TheAlexBarney> It doesn't
[18:50:26 CET] <TheAlexBarney> It's a form of SBR
[18:50:30 CET] <atomnuker> oh, direct adjustments thne
[18:50:40 CET] <atomnuker> ......why isn't it called SBR then?
[18:50:55 CET] <atomnuker> band extension is incredibly vague
[18:52:52 CET] <TheAlexBarney> Who knows. CRI calls their SBR implementation in their HCA codec HFR or High-frequency Regeneration
[18:59:51 CET] <TheAlexBarney> The way the encoder works is by generating a default gradient for bit allocation. Then for each frame it encodes the audio, and adjusts the gradient based on how many bits are leftover, encoding, and repeating until the number of unused bits is minimized
[19:01:37 CET] <atomnuker> welp, that's what you got to do when you're forcing a vbr codec to behave in a cbr way
[19:02:44 CET] <TheAlexBarney> I don't know too much about audio codecs, but based on what I've learned from RE'ing it, ATRAC9 seems like a rather simple codec to me when compared to others, SBR aside
[19:04:25 CET] <atomnuker> yep, its just aac but without the complicated and limited vector quantization
[19:04:57 CET] <cone-524> ffmpeg 03Derek Buitenhuis 07master:500a9bb5ba94: lavc/options: Remove unneeded header
[19:04:57 CET] <cone-524> ffmpeg 03Derek Buitenhuis 07master:6470abc74036: vf_paletteuse: Add error checking to apply_palette
[19:04:57 CET] <cone-524> ffmpeg 03Derek Buitenhuis 07master:631fa0432be8: vf_paletteuse: Don't free the second frame from ff_framesync_dualinput_get_writable on error
[19:07:33 CET] <wm4> so I'm thinking about how side data handling could be unified across all the things which need side data (AVPacket, AVFrame, AVStream, global de/muxer side data)
[19:07:47 CET] <wm4> any ideas how this should be handled for compatibility?
[19:08:04 CET] <wm4> since there isn't really a way to avoid duplicated side data (one for the old API, one for the new)
[19:11:18 CET] <atomnuker> so one function to add/remove/get side data from avpacket/avframe?
[19:12:32 CET] <wm4> yes, I'd probably put the side data list into an AVSideData thing, and add a pointer member to that to AVPacket/AVFrame etc.
[19:13:19 CET] <wm4> or is there a better way?
[19:19:45 CET] <atomnuker> how do you plan to identify between an avpacket/avframe argument? some kind of an id or maybe putting the side data fields in the same pos?
[19:20:11 CET] <wm4> there'd just be a single enum for all side data
[19:20:35 CET] <wm4> plenty of packet side data is just "renamed" and copied to frame side data in libavcodec anyway
[19:21:12 CET] <wm4> as long as it happens in the ABI unstable period, we could even define the legacy side data constants to new ones
[19:21:27 CET] <atomnuker> I thought the api would be something like av_side_data_add(void *dst, avbufferref *src)
[19:21:47 CET] <wm4> so you'd make the dst argument "dynamically" typed?
[19:23:07 CET] <wm4> anyway, the main problem is that the user can manipulate the existing side data directly (without even calling any API functions)
[19:23:56 CET] <atomnuker> that's something that shouldn't be allowed
[19:25:34 CET] <wm4> well, it is allowed
[19:26:01 CET] <wm4> I'd make the new thing opaque, but the current API is like that
[19:50:17 CET] <cone-524> ffmpeg 03Paul B Mahol 07master:09b24a807ad2: avfilter: add entropy filter
[20:02:43 CET] <cone-524> ffmpeg 03Nicolas George 07master:9ace76697ac1: lavfi/framesync: document frame ownership for dualinput.
[20:02:44 CET] <cone-524> ffmpeg 03Nicolas George 07master:29b5f3115d9f: lavfi/framesync: remove an invalid free.
[21:06:52 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vNely
[21:06:52 CET] <KGB> 13FFV1/06master 142f2133e 15Dave Rice: use version variable in makefile
[21:33:41 CET] <cone-524> ffmpeg 03Jiejun Zhang 07master:677701c6b319: lavc/audiotoolboxenc: fix noise in encoded audio
[22:37:38 CET] <atomnuker> do the apple audio decoding apis go through hardware decoding? do they put some apple-specific hardware audio decoders on their boards?
[22:45:06 CET] <wm4> interesting question
[22:45:17 CET] <wm4> on phones doing hw decoders is probably worth the trouble?
[22:45:25 CET] <wm4> for audio, I mean
[22:46:37 CET] <atomnuker> I thought the audiotoolbox apis were pc-specific only and weren't on iphones
[22:47:20 CET] <tmm1> the encoders/decoders are available on ios
[22:47:22 CET] <atomnuker> huh, apparently they're both on osx and ios
[22:47:25 CET] <tmm1> some of the apis are not, but most of audiotoolbox is
[22:52:29 CET] <BtbN> I'd be surprised if their PC hardware had audio decoders
[22:52:37 CET] <BtbN> but on phones it seems reasonable
[22:53:34 CET] <cone-524> ffmpeg 03Paul B Mahol 07master:88cbd25b193d: avfilter: pass outlink to ff_get_audio_buffer()
[23:46:22 CET] <rcombs> atomnuker: wm4: audiotoolbox is hardware on iOS
[23:46:48 CET] <atomnuker> oh wow, how fast is it compared to our decoder?
[23:46:59 CET] <rcombs> no idea; never tested on iOS
[23:47:36 CET] <rcombs> there's documented awkwardness around getting interrupted mid-decode when using hardware
[23:47:36 CET] <atomnuker> nvm I can't read today, I read that as osx
[23:49:33 CET] <wm4> "interrupted"? what
[23:59:49 CET] <tmm1> probably if your app goes into the background
[00:00:00 CET] --- Thu Jan  4 2018