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

[burek]

[00:03:04 CET] <durandal_1707> michaelni: its never recognized
[00:11:40 CET] <michaelni> durandal_1707, it is recognized here, ffprobe prints " yuv420p(tv"
[00:14:19 CET] <durandal_170> michaelni: why itts experimental.?
[03:45:23 CET] <cone-274> ffmpeg 03Rodger Combs 07master:2e391a576c1f: lavf/mpegts: mark packets with TEI flag as corrupted
[09:39:41 CET] <durandal_1707> michaelni: the limited mjpeg command cant work as is, you would need to also set color range
[12:53:32 CET] <Chloe> What's the status on ffserver removal? Weren't we waiting for an ABI bump to remove it? Has that happened yet? 
[12:54:38 CET] <atomnuker> yes we are, no the period isn't over, we still need to remove the avpriv_atomic stuff
[12:54:39 CET] <durandal_1707> yea, whats status?
[12:55:09 CET] <durandal_1707> but commit was reverted
[12:55:14 CET] <Chloe> What to do to remove avpriv_atomic? 
[12:55:15 CET] <atomnuker> nevcairiel said he'd look into making the cas function (the only blocker) disappear but seems like he hasn't had the time yet
[12:55:33 CET] <atomnuker> durandal_1707: one was, it was unrelated to atomics stuff, was just a simplification
[12:56:10 CET] <atomnuker> Chloe: figure out how to replace the avpriv_atomic_ptr_cas with regular c11 atomics
[12:57:50 CET] <atomnuker> btw nevcairiel you really should have pinged me before reverting my commit
[12:58:05 CET] <atomnuker> or at least talk with michaelni to figure out if its worth keeping the atomic stuff
[12:59:23 CET] <wm4> wasn't that already discussed to death
[12:59:50 CET] <wm4> and that code is rather crappy and barely safe anyway (theoretically failure modes were discussed)
[12:59:57 CET] <wm4> +possible
[13:00:14 CET] <atomnuker> yes, and there were 2 ways to solve it - remove atomics or properly fix the wrapper to support atomic_bool
[13:00:40 CET] <atomnuker> yes, I agree, that's option 2 btw Chloe - make the list compile time and make the registry functions a noop
[13:01:08 CET] <wm4> like BSFs - that's the ideal solution
[13:05:06 CET] <Chloe> atomnuker: dont you just have to rewrite the whole atomics file? 
[13:05:48 CET] <atomnuker> no, the idea is to remove the avpriv atomic stuff altogether
[13:06:03 CET] <atomnuker> since they're part of the abi and we'd like to keep it clean
[13:06:18 CET] <Chloe> Oh right
[13:06:20 CET] <atomnuker> and since they're useless code since everywhere else we use c1s
[13:06:52 CET] <Chloe> Ok. I misunderstood, i thought you wanted a c11 atomic wrapper for some reason 
[13:08:16 CET] <wm4> at least cas in the win32 wrapper is fundamentally broken, which brought us this whole issue
[13:10:14 CET] <Chloe> It's only used across 4 files. Mmmh. I'll give it a look when I get home
[13:23:57 CET] <michaelni> durandal_1707, about mjpeg limited color range, you are correct it looks like its needed once yuvj is gone. Before yuv420p seems to have been interpreted as limited range by default, so forcig just that seems to have been enough
[13:25:23 CET] <michaelni> this change should be documented somewhere with examples
[13:25:42 CET] <wm4> apichanges.txt
[13:26:00 CET] <wm4> (ok, there's no .txt extension)
[13:42:15 CET] <nevcairiel> atomnuker: i tried to convert it, but i'm not sure i fully understand the logic in avcodec_register in the first place, it doesnt seem entirely thread-safe to me .. plus i have no way to test if it is, since any cases that would result in it being called simultaneously are extremely contrived and unlikely
[13:44:28 CET] <nevcairiel> usually linked lists are implemented by swapping the head element out atomically which is easy, this one is weirdly backwards
[13:45:47 CET] <jkqxz> It needs to preserve the order so that searching for a codec gives you the normal answer by default rather than some hardware codec you don't have hardware for.
[13:48:21 CET] <wm4> yep
[13:48:32 CET] <wm4> I have no idea why the list isn't just protected by a mutex
[13:48:44 CET] <wm4> that would be easiest
[13:48:45 CET] <nevcairiel> static mutexes are annoying
[13:48:54 CET] <nevcairiel> but yeah it certainly would be much easier
[13:49:02 CET] <wm4> static mutexes are perfectly possible on windows
[13:49:09 CET] <wm4> on vista+, MS has explicit API for them
[13:49:21 CET] <nevcairiel> not that i can see
[13:49:36 CET] <wm4> for XP you could statically initialize CriticalSection, which is not documented, but happens to work (and it won't change anymore so it'll keep working)
[13:49:56 CET] <wm4> you'd weirdly have to switch between them at runtime though, if you really want binaries to support both
[13:50:08 CET] <wm4> or we could just drop XP support
[13:50:10 CET] <jkqxz> Fuck XP support.
[13:50:14 CET] <jkqxz> Yeah, that.
[13:50:31 CET] <nevcairiel> i dont do XP either anymore these days, but who knows if there would be consensus
[13:51:35 CET] <nevcairiel> you could do a pthread_once initialized mutex if you wanted to go down that route, but technically you're leaking a handle
[13:52:23 CET] <wm4> the lock manager is already leaking one
[13:53:18 CET] <j-b> We drop XP after this release of VLC
[13:53:31 CET] <j-b> So, I won't break your b*lls anymore about XP and Vista
[13:53:52 CET] <nevcairiel> vista is fine on the api level, most of those things appeared with  vista
[13:54:16 CET] <j-b> well, sure
[13:59:20 CET] <wm4> what stops us from providing a DllMain, and just leaking it for static builds?
[14:00:20 CET] <BBB> seems like a lot of effort for a dead os
[14:00:30 CET] <BBB> (xp is well beyond eol)
[14:00:42 CET] <wm4> yes
[14:01:08 CET] <wm4> but you know well that once we actually attempt to drop it, all the trolls will come out of their holes
[14:01:22 CET] <nevcairiel> I killed XP in the version where I added d3d11 decoding, because the visual studio SDK which supports XP doesnt have full d3d11, so it was kinda required and a good excuse =p
[14:01:47 CET] <atomnuker> btw where does the 40 byte leak happen when using valgrind? in ffmpeg.c
[14:02:03 CET] <wm4> --leak-report=full ?
[14:02:54 CET] <BBB> wm4: so let the trolls come
[14:03:04 CET] Action: jdarnley is already here
[14:03:05 CET] <BBB> we get trolled every day
[14:03:51 CET] <BBB> \o/
[14:14:19 CET] <wm4> do we have an official list of people who can participate in votes?
[14:14:27 CET] <wm4> or any document which outlines how votes work
[14:15:01 CET] <wm4> because I want to post a RFC+vote on this
[14:17:23 CET] <durandal_1707> on xp support?
[14:18:13 CET] <durandal_1707> top 10 recent commit authors can vote
[14:18:57 CET] <atomnuker> wm4: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html
[14:20:37 CET] <wm4> what dates should be used?
[14:21:13 CET] <wm4> well uh the procedure for determining the members of the voting committee is still unclear to me
[14:21:39 CET] <wm4> I guess I remove the --until, and set --since to 1 year ago
[14:22:42 CET] <durandal_1707> lets ditch all commiters and leave only me and michael
[14:23:06 CET] <atomnuker> wm4: well, the people shouldn't have changed
[14:23:15 CET] <wm4> hm the result I'm getting can't be right
[14:23:36 CET] <atomnuker> originally we agreed to include people from 5th of september (the day of the meeting) until the next 5th of sepetember
[14:23:51 CET] <atomnuker> but we just kept the committee as-is
[14:25:05 CET] <atomnuker> you should update the committee list first though if you want to document it
[14:26:16 CET] <wm4> just sent my post
[14:26:35 CET] <wm4> I wanted to include the voting committee member list, but dunno how to do that
[14:26:41 CET] <wm4> I don't even know if I can still vote
[14:27:27 CET] <atomnuker> yep, you can
[14:29:06 CET] <wm4> in any case a list would be useful so we don't have dozens of end users sending votes
[14:30:51 CET] <durandal_1707> we have no more subscribers
[14:31:06 CET] <durandal_1707> all unsuscribed since my spam
[14:33:03 CET] <j-b> m
[14:35:27 CET] <rcombs> I dropped XP when Chrome did
[14:35:31 CET] <iive> won't it be simple if we just turn off threads on winxp?
[14:35:51 CET] <atomnuker> yeah, I don't see the issue xp has if threading was disabled
[14:36:30 CET] <rcombs> lol
[14:36:33 CET] <atomnuker> durandal_1707: hardly spam, your work to get rid of yuvj is very appreciated
[14:37:00 CET] <rcombs> XP still supported, but rendered useless
[14:37:09 CET] <wm4> I thought about disabling threads too, but I don't think this would raise general acceptance
[14:37:22 CET] <wm4> since multithreaded decoding is pretty important
[14:37:33 CET] <rcombs> yeah I don't really see the point of half-assing removal
[14:37:59 CET] <rcombs> if the only reason not to remove is people whining about their 2001 OS
[14:39:02 CET] <iive> well, wine still hasn't implemented winxp api's fully. and win7 is even less complete.
[14:39:16 CET] <rcombs> who uses ffmpeg in wine
[14:39:24 CET] <rcombs> have they noticed it's cross-platform
[14:39:35 CET] <iive> is there native linux handbrake?
[14:39:41 CET] <jdarnley> Must.  Not.  Troll.
[14:39:54 CET] <rcombs> yup
[14:40:01 CET] <rcombs> (though also, >>handbrake)
[14:42:58 CET] <wm4> rcombs: win32 has a more stable ABI, so using wine on portable programs can be attractive
[14:43:26 CET] <iive> anyway, if you vote, I'd prefer to put an option for making all codec/filter static and not having to register it at startup.
[14:43:46 CET] <iive> it/them
[14:43:55 CET] <rcombs> like with bsfs?
[14:44:09 CET] <iive> i guess.
[14:44:34 CET] <rcombs> I do have a use-case that requires the _ability_ to register new ones at runtime
[14:44:52 CET] <rcombs> though that doesn't mean everything _has_ to be
[14:45:01 CET] <wm4> iive: that's prthogonal
[14:45:08 CET] <wm4> orthogonal even
[14:45:16 CET] <iive> it's the root of the problem, isn't it?
[14:45:39 CET] <wm4> static mutexes might be useful for other reasons too
[14:45:52 CET] <wm4> also there's an incentive for not using the XP emulation code on modern windows
[14:46:12 CET] <iive> are you working for microsoft now?
[14:46:16 CET] <iive> ;)
[14:47:16 CET] <wm4> no
[14:47:57 CET] <wm4> the modern windows locking APIs effectively use the linux futex design
[14:50:05 CET] <iive> so the deprecation would simplify the code? would that affect any code outside the os-compatibility?
[14:50:24 CET] <wm4> yes, because we could use static mutexes and such
[14:51:18 CET] <iive> no, i mean, would that allow clean up of existing if/def-ery, that does not involuve writing new code.
[14:53:56 CET] <wm4> that's not sure, but I expect it makes writing new windows code easier, because you don't have to care about XP anymore, and that's a big one
[14:55:26 CET] <iive> so, no.
[14:56:23 CET] <wm4> I said it's not sure
[14:56:26 CET] <wm4> I didn't check for it
[15:01:50 CET] <nevcairiel> there definitely is a bunch of stuff that could remove a bunch of checks
[15:01:55 CET] <nevcairiel> primarily in the thread emulation
[15:02:08 CET] <nevcairiel> but also sprinkled all over
[15:03:59 CET] <durandal_1707> do we have xp fate machines?
[15:05:49 CET] <nevcairiel> wm4: technically the end of "all support" was on April 8, 2014
[15:06:19 CET] <wm4> nevcairiel: how so?
[15:06:35 CET] <nevcairiel> thats just how it is
[15:08:30 CET] <nevcairiel> not sure what 2009 was, mainstream support? extended support  ended in 2014, which is the point they stop doing security updates
[15:08:53 CET] <JEEB> yea
[15:09:41 CET] <Compn> there are so many people still using xp
[15:09:53 CET] <Compn> millions of users
[15:10:04 CET] <Compn> j-b still supports windows xp as well iirc
[15:10:10 CET] <nevcairiel> The way I see it, Old OS = Old FFmpeg
[15:10:14 CET] <nevcairiel> its not like 3.4 or such stop working
[15:10:24 CET] <rcombs> yeah
[15:10:26 CET] <j-b> Compn: as I said, I don't.
[15:10:31 CET] <Compn> oh you dont, ok then :)
[15:10:53 CET] <Compn> all those poor dos users .... :D
[15:10:54 CET] <wm4> j-b: will vlc for windows keep using ffmpeg 3.4?
[15:11:12 CET] <rcombs> well they're dropping it after 3.0 so ¯\_(Ä)_/¯
[15:11:21 CET] <iive> btw, the thread cleanup could still be done if XP is used with threads disabled.
[15:11:24 CET] <wm4> 3.0 is apparently not released yet
[15:11:30 CET] <rcombs> SOON"
[15:12:28 CET] <Compn> security updates from microsoft haha
[15:13:44 CET] <j-b> wm4: 3.0, yes.
[15:14:04 CET] <j-b> wm4: 3.0 is LTS, and won't move the ffmpeg hash for a long time
[15:14:28 CET] <j-b> wm4: and vlc.git has already dropped XP+Vista+Seven-without-some-KB
[15:14:31 CET] <nevcairiel> if its meant to be supported, perhaps it should though, you know, security updates :D
[15:14:43 CET] <wm4> neat
[15:15:02 CET] <j-b> nevcairiel: and therefore, it will be patched.
[15:15:05 CET] <wm4> what does Seven-without-some-KB affect API wise?
[15:15:09 CET] <j-b> yessir
[15:15:15 CET] <wm4> possibly d3d11 decoding?
[15:15:18 CET] <nevcairiel> why not just track the release branch, thats what its for
[15:15:45 CET] <nevcairiel> i couldnt get d3d11 decoding working on 7 at all, other then using the opaque pixfmt which I just flat out refuse to consider valid
[15:16:11 CET] <nevcairiel> cant make nv12 textures on 7
[15:16:13 CET] <j-b> wm4: so far, no.
[15:16:14 CET] <wm4> yeah, I heard some got it to work...
[15:16:21 CET] <j-b> wm4: KB2533623
[15:16:33 CET] <wm4> even if it's just the opaque format, then it might still be more useful than dxva
[15:16:36 CET] <j-b> wm4: D3D11va sucks on Win7 and Win8.0, in many configuration.
[15:17:23 CET] <Compn> win10 is better ?
[15:17:29 CET] <j-b> (read borken drivers)
[15:17:45 CET] <Compn> win10 has better drivers? 
[15:17:53 CET] <nevcairiel> 8.0 should be considered dead and buried anyway, there is literally no reason to stay with 8.0 and not go 8.1
[15:17:55 CET] <j-b> Compn: yes.
[15:17:59 CET] <Compn> huh wow
[15:18:14 CET] <wm4> as far as I'm concerned, there's only win7 and 10 in practice
[15:18:24 CET] <wm4> if someone dares to use vista or 8.x, their fault
[15:18:31 CET] <j-b> Compn: basically, the windows desktop on Windows7 is rendered with D3D9. So D3D9 drivers are well tested.
[15:18:39 CET] <Compn> ah
[15:18:43 CET] <nevcairiel> I still use 8.1 on my HTPC because 10 has a whole bunch of annoying things with video playback
[15:18:44 CET] <Compn> yes aero is shit
[15:18:45 CET] <j-b> Compn: on Windows 10, it is using D3D11. So D3D11 drivers are well tested.
[15:18:56 CET] <j-b> We have 2% of users on Windows 8.0
[15:19:02 CET] <j-b> because it is a pain to update to 8.1
[15:19:30 CET] <j-b> because Microsoft is stupid.
[15:19:38 CET] <Compn> j-b : you could copy paste all this into a winxp faq wiki on trac.voo
[15:19:41 CET] <Compn> :)
[15:19:43 CET] <j-b> Compn: sure.
[15:20:05 CET] <Compn> i think it would be a good idea for those winxp holdouts.
[15:20:19 CET] <Compn> who demand answers!
[15:20:20 CET] <Compn> :)
[15:20:48 CET] <wm4> j-b: how many users on 8.1?
[15:21:28 CET] <j-b> wm4: 4.98%
[15:21:38 CET] <j-b> 8.1% on XP.
[15:22:06 CET] <wm4> that's a lot
[15:22:11 CET] <j-b> yup
[15:23:21 CET] <j-b> and you know the worse? Windows 7 usage is increasing...
[15:25:13 CET] <wm4> nice
[15:25:25 CET] <wm4> Microsoft fucking up really badly
[15:25:29 CET] <Compn> because no one wants to be on a terrible untested win10 platform ?
[15:26:38 CET] <j-b> because XP and Vista upgrading to 7
[15:27:04 CET] <Compn> "its the last "good" windows" ?
[15:27:54 CET] <wm4> any windows user who's on an older version will think that
[15:28:02 CET] <wm4> I thought that of Windows 2000 as well
[15:28:10 CET] <wm4> (and I upgraded to Linux, instead of XP lol)
[15:28:18 CET] <Compn> i rocked win2k into 2013? ehe
[15:28:44 CET] <Compn> wm4 : what distro do you use/like ?
[15:29:33 CET] <wm4> use debian, like none
[15:29:45 CET] <wm4> considering opensuse
[15:30:38 CET] <Compn> i tried suse a few years ago and did not like it. maybe it has gotten better since the
[15:30:38 CET] <Compn> n
[15:30:53 CET] <j-b> win10 is good.
[15:32:16 CET] <wm4> one major issue with getting rid of global mutable code is that some wrappers populate AVCodec.pix_fmts with runtime information
[15:32:20 CET] <wm4> e.g. libvpx
[15:32:29 CET] <wm4> (see ff_vp9_init_static)
[15:32:57 CET] <j-b> I hate libvpx.
[15:33:50 CET] <wm4> happens with libx264 too
[15:34:11 CET] <wm4> it's a fundamental problem with libavcodec's API
[15:36:34 CET] <j-b> That does not change my opinion of libvpx :)
[15:36:56 CET] <wm4> of course
[15:37:13 CET] <wm4> I just noticed that on libvpx
[15:37:23 CET] <wm4> on its lavc wrapper I mean
[15:52:58 CET] <wm4> meh, v4l is missing AV_COCEC_CAP_DELAY
[15:53:08 CET] <durandal_1707> what it adds to .pix_fmts?
[15:56:06 CET] <wm4> durandal_1707: supported formats
[15:56:13 CET] <wm4> which can depend on how those libs were built
[16:00:33 CET] <durandal_1707> atomnuker: whats status of ffmpeg related work? anything new was implemented?
[16:02:54 CET] <atomnuker> am in a convention in austin, but 2 new pvq searches for opus may be on their way
[16:17:47 CET] <atomnuker> durandal_170: oh yeah and I'm looking into somehow making the filter list static
[16:18:00 CET] <atomnuker> *compile time
[17:01:58 CET] <durandal_170> atomnuker: you are not doing anything yet?
[17:25:15 CET] <tmm1> anyone interested in reproducing my hls/http network benchmark? curious what kind of results others see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222270.html
[17:27:01 CET] <atomnuker> durandal_170: I am, but if you'd like to help in making the register functions noops by making the array compile time you're welcome
[17:29:57 CET] <durandal_170> just change macro
[17:38:25 CET] <atomnuker> which one?
[18:02:20 CET] <wm4> man who ever thought AVClass was a good idea
[18:02:49 CET] <wm4> or that every codec would have to define its own AVClass
[18:03:00 CET] <wm4> is there even any purpose?
[18:04:18 CET] <BtbN> to identify it without each codec defining the same fields?
[18:16:34 CET] <rcombs> wm4: isn't it for logging
[18:16:41 CET] <rcombs> and also for options
[18:17:31 CET] <rcombs> so that both of those facilities can work with more than just a single type of component
[18:36:38 CET] <atomnuker> ok, seems like making the lavf/lavc/lavfi lists compile time won't be hard
[18:37:10 CET] <atomnuker> configure already supports everything, just need to add find_things_extern to generate a file and include it
[18:37:24 CET] <atomnuker> and copy the next function from the bsf avclass
[18:37:25 CET] <wm4> rcombs: not in the beginning - it was added with av_log
[18:43:50 CET] <iive> atomnuker: new pvq searches? tell me more.
[18:45:02 CET] <atomnuker> kamedo's been working on that for a few months now
[18:45:11 CET] <atomnuker> I think its just heuristics
[18:50:32 CET] <Dis> Hi, does mp4 muxer provide segmented 'senc' atom per track when used with the dash? moving senc from stbl atom creates an issue while streaming.
[19:15:16 CET] <wm4> jkqxz: fine if I push "[PATCH] avcodec: add metadata to identify wrappers and hardware decoders"?
[19:36:43 CET] <wm4> well now Libav pushed it, so I guess I'll push it to ffmpeg too
[19:40:34 CET] <cone-669> ffmpeg 03wm4 07master:b945fed629a8: avcodec: add metadata to identify wrappers and hardware decoders
[20:02:40 CET] <philipl> wm4: push it
[20:02:45 CET] <philipl> too late
[20:07:26 CET] <atomnuker> why are all AVCodec definitions non-const?
[20:07:34 CET] <atomnuker> all bsf defines are consts
[20:41:19 CET] <wm4> atomnuker: 1. for the linked lists, 2. to populate the pix_fmts list
[20:41:29 CET] <wm4> atomnuker: 2. was what I just brought up today
[20:41:37 CET] <wm4> libvpx and libx264, possibly more
[20:42:04 CET] <atomnuker> might change them all to consts
[20:42:24 CET] <atomnuker> (or might have to)
[20:42:25 CET] <wm4> you can't
[20:42:31 CET] <atomnuker> why not?
[20:42:37 CET] <atomnuker> its done for the bsfs
[20:42:41 CET] <atomnuker> oh
[20:42:43 CET] <atomnuker> nvm
[20:42:52 CET] <atomnuker> because of the pix fmt not being init'd on init
[20:43:26 CET] <wm4> yeah, and fixing this will require an API change
[20:45:00 CET] <iive> is avcodec a public struct?
[20:45:56 CET] <atomnuker> oh well, ought to work fine with it being const
[20:45:56 CET] <iive> i mean, we can have them static, and libvpx/x264 could return a modified copy
[20:49:41 CET] <wm4> always fun when ffmpeg devs don't know their own API
[20:52:24 CET] <durandal_170> that hurts
[21:01:48 CET] <wm4> atomnuker, iive: you can see this e.g. on X264_init_static
[21:02:13 CET] <wm4> apparently libx264 can be built with support for a specific bit depth
[21:02:50 CET] <wm4> and depending on that only certain pixfmts are available
[21:03:11 CET] <wm4> and AVCodec.pix_fmts is of course public API
[21:03:26 CET] <wm4> API users need to use it to check whether an encoder supports a pixfmt
[21:04:20 CET] <wm4> so we could need to add av_codec_get_pix_fmts() or something
[21:04:23 CET] <wm4> then wait 2 years
[21:04:27 CET] <wm4> then you can make it const
[21:07:19 CET] <durandal_170> wait for 2 years? im too old for that crap
[21:07:54 CET] <durandal_170> break now for good
[21:08:47 CET] <wm4> apparently that's not project policy
[21:09:10 CET] <durandal_170> lets vote on new project policy
[21:17:31 CET] <durandal_170> wm4: did you knew that it must pass 7 days for every voting to complete?
[21:18:02 CET] <wm4> durandal_170: no, where is that written
[21:18:19 CET] <durandal_170> voting rules
[21:18:28 CET] <wm4> anyway, downstreams hate us for changing the API all the time
[21:18:36 CET] <wm4> even though we really don't
[21:18:55 CET] <wm4> (you'd think 2 years are plenty of time)
[21:19:22 CET] <BtbN> They keep using a 10 year old version and then are surprised the API changed when they update to the latest version
[21:19:56 CET] <wm4> yes
[21:20:02 CET] <durandal_170> you didnt specify how much voting should take time, so it runs indefinetely
[21:20:26 CET] <BtbN> I think it already good a 51% majority of all active voters?
[21:21:01 CET] <durandal_170> so you must abandon this voting and start new one,  rules are rules
[21:22:21 CET] <durandal_170> we should pick api ala gstreamer and then we dont need to change a thing
[21:23:18 CET] <BtbN> Inventing your own meta-programming-language to then implement an API in does not count
[21:23:52 CET] <wm4> gstreamer is so unattractive because filters and their connections handle literally everything a transcoder or player would do
[21:24:07 CET] <wm4> having a plugin system with stable API is still a good idea
[21:28:05 CET] <durandal_170> should i tell ffplay to set its buffersink color range to limited only and bee done with it? or proper selection of pix fmt thus rewrite of code  is  required?
[21:28:50 CET] <wm4> ffplay probably always expects limited range for output?
[21:31:56 CET] <durandal_170> but for rgb you are doomed
[21:32:38 CET] <wm4> how so
[21:33:52 CET] <durandal_170> rgb is full range
[21:34:14 CET] <durandal_170> and ffplay supports rgb output
[21:34:50 CET] <durandal_170> or in this case for rgb, range is unspecified
[21:37:22 CET] <wm4> swscale AFAIK only deals in full range RGB
[21:38:09 CET] <durandal_170> so i can give it limited and be done with it
[23:10:15 CET] <cone-639> ffmpeg 03Martin Storsjö 07master:18a0f420269f: checkasm: Use LOCAL_ALIGNED for aligned variables on the stack
[23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:6ff29343b019: lavc/qsvenc: set HRD buffer size
[23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:bddb2ce179c5: lavc/qsvenc: ICQ/VCM/QVBR are not avilable on Linux
[23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:7c65a76b16bc: lavc/qsvenc: add error messeage if ICQ unsupported.
[23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:f2e9a0ecbef5: qsv/vp8dec: fixes memory leak issue
[23:10:16 CET] <cone-639> ffmpeg 03Luca Barbato 07master:508378556631: qsv: Support explicit lookahead downscaling
[23:10:16 CET] <cone-639> ffmpeg 03James Almer 07master:5fc649505b2d: Merge commit '18a0f420269ff4c730422361c5c4d8eea096e900'
[23:10:17 CET] <cone-639> ffmpeg 03James Almer 07master:0929def32765: Merge commit '6ff29343b01923e9b125fe7404ac8701cdfb1fe5'
[23:10:17 CET] <cone-639> ffmpeg 03James Almer 07master:2ca3c049cd09: Merge commit 'bddb2ce179c57db6e3c79fdc3363c165d90850b0'
[23:10:18 CET] <cone-639> ffmpeg 03James Almer 07master:f61cf0e4df52: Merge commit '7c65a76b16bc3a44f1592acde2176f187a058797'
[23:10:19 CET] <cone-639> ffmpeg 03James Almer 07master:b4718b76937a: Merge commit 'f2e9a0ecbef5027f9532c49ffcdfc11d199f6150'
[23:10:20 CET] <cone-639> ffmpeg 03James Almer 07master:374f818bfbc5: Merge commit '508378556631dc18d32247b4a4e35703758e1ca9'
[23:12:34 CET] <cone-639> ffmpeg 03wm4 07master:47687a2f8aca: avcodec: add metadata to identify wrappers and hardware decoders
[23:12:35 CET] <cone-639> ffmpeg 03James Almer 07master:980af9a88cfd: Merge commit '47687a2f8aca3f65b6fdd117b1cb66a7409a7fd1'
[23:22:07 CET] <daddesio> Hi all, would it be worth adding a decoder for EA MicroTalk in FFmpeg? It's a 32kbit/s speech codec used in some (obscure?) EA games from 1997-2002: Beasts & Bumpkins, Ultima IX, FIFA 2001, FIFA 2002, and The Sims Online.
[23:22:29 CET] <daddesio> https://wiki.multimedia.cx/index.php/Electronic_Arts_MicroTalk
[23:23:09 CET] <daddesio> Thing is, almost every game uses a different container. At least FIFA uses SCxl.
[23:26:38 CET] <daddesio> which we already have support for.
[23:28:08 CET] <BBB> I think yes
[23:28:17 CET] <BBB> we have a ton of game codecs, and theyre typically quite straightforward
[23:28:28 CET] <BBB> (decoding only, right? I Dont think we want to encourage encoding of such files)
[23:28:34 CET] <jdarnley> I don't object.  I once submitted a patch for a demuxer fr 13 files from 1 game.
[23:28:59 CET] <jdarnley> speaking of which, I should finish that by adding a probe function.
[23:29:16 CET] <daddesio> :p
[23:29:51 CET] <daddesio> Okay another thing is that each SCxl packet contains 4 MicroTalk frames.
[23:30:13 CET] <daddesio> But MicroTalk doesn't explicitly indicate the size of the frame. You have to decode it first to find out its length.
[23:30:31 CET] <daddesio> MicroTalk frames are variable-length.
[23:30:41 CET] <daddesio> e.g. it uses unary coding at one point
[23:30:46 CET] <jdarnley> So there is no indication where one frame ends without decoding?
[23:30:50 CET] <daddesio> correct
[23:32:19 CET] <daddesio> The Sims Online has a custom container (.UTK) that doesn't use packets. The UTK body is a stream of thousands of (variable-length) MicroTalk frames, so it's impossible/difficult to seek.
[23:32:28 CET] <jdarnley> I don't know much about the API so I would just say that you should make the decoder tolerate several frames in one AVFrame/AVPacket
[23:33:00 CET] Action: jdarnley forgets which structgets passed into decoders
[23:33:22 CET] <daddesio> lu_zero in #libav-devel suggested I write a reframer to first decode the MicroTalk frame in order to find out the length, then pass the frame to the real decoder.
[23:33:27 CET] <BtbN> I think it's pretty common for audio decoders to only partially consume input packets
[23:33:47 CET] <BBB> yes
[23:33:56 CET] <BBB> but that doesnt give concatenation of packets
[23:34:05 CET] <BBB> so you need to give the whole file at once from demuxer to decoder
[23:34:12 CET] <BBB> or parse them in e.g. a parser or bsf
[23:34:17 CET] <BBB> as lu_zero also said
[23:34:47 CET] <daddesio> Well, you can place a pretty generous upper bound on MicroTalk frames. (Technically, MicroTalk frames can be infinite in size due to the unary coding, but I think we can cap the unary coding to 16 bits.)
[23:35:48 CET] <StevenLiu> Ping jamrial
[23:36:46 CET] <daddesio> But also, decoding a MicroTalk frame isn't that hard to do. You can probably do it in 100 lines.
[23:36:54 CET] <daddesio> so a reframer isn't out of the question
[23:37:40 CET] <daddesio> Also, vgmstream just added support for MicroTalk, so... we don't strictly need support for it in FFmpeg anymore. :P
[23:37:58 CET] <StevenLiu> i see there hre duplicate the ./libavcodec/reverse.c ./libavdevice/reverse.c from why don't define them in libavformat/ , libavcodec, libavfilter, libavdevice, ? only include it?
[23:39:40 CET] <StevenLiu> include a c source file, looks it weird even though that have no problem
[23:41:05 CET] <StevenLiu> i see there hre duplicate the ./libavcodec/reverse.c ./libavdevice/reverse.c,  why don't define them in libavformat/ , libavcodec, libavfilter, libavdevice, ? only include it? 
[23:41:50 CET] <durandal_170> daddesio: see interplay acm decoder
[23:42:16 CET] <jdarnley> whatever you decide to do you shouldn't decode the audio twice just so you can neatly pass a single frame around.
[23:42:50 CET] <daddesio> Well you don't need to decode the audio, you only need to decode the fields.
[23:43:49 CET] <jdarnley> perhaps I misunderstood, I thought you meant to had to process bits in some from the entire frame
[23:43:52 CET] <durandal_170> there must be max possible size of encoded frame, right?
[23:44:11 CET] <daddesio> If you cap the unary codes to 16 bits, then yes there is a max size.
[23:44:31 CET] <daddesio> The whole decoder is here: https://github.com/daddesio/utkencode/blob/master/utk.h
[23:44:39 CET] <daddesio> It's a pretty simple codec.
[23:45:05 CET] <daddesio> see utk_decode_frame: https://github.com/daddesio/utkencode/blob/master/utk.h#L289
[23:45:49 CET] <daddesio> Basically it has a Huffman table to decode commands to construct the excitation signal, and some of the commands have arguments.
[23:47:10 CET] <daddesio> Also, SCxl guarantees that there are 1-4 MicroTalk frames per SCDl packet.
[23:47:56 CET] <daddesio> I think SCxl tells you the duration of the frame which means you can calculate how many MicroTalk frames there are supposed to be inside it.
[23:48:11 CET] <daddesio> s/duration of the frame/duration of the SCDl packet/
[23:48:57 CET] <daddesio> I realize that FFmpeg is designed to handle streaming audio from the internet and seeking to random points in the audio.
[23:52:51 CET] <cone-639> ffmpeg 03Gyan Doshi 07master:1c76134fe37a: avfilter/drawbox+drawgrid - add option to prevent overwriting of source pixels
[23:55:02 CET] <daddesio> Has anyone ever thought about adding coroutines to FFmpeg for situations like this? :p
[23:56:34 CET] <durandal_170> daddesio: shorten and acm are codecs similar as that one
[23:56:50 CET] <durandal_170> and ffmpeg have decoders for them
[23:57:12 CET] <durandal_170> you just cant seek within them
[23:59:33 CET] <daddesio> The thing is, I feel it should be possible to seek within SCxl (since there are guaranteed no more than 4 MicroTalk frames per SCDl packet), just not within The Sims Online's UTK format.
[23:59:49 CET] <atomnuker> daddesio: you can look into using AV_CODEC_CAP_SUBFRAMES
[00:00:00 CET] --- Fri Dec 15 2017