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

[burek]

[02:43:26 CET] <atomnuker> what's the difference between hwcontext map_to and frames_derive_to?
[04:30:38 CET] <atomnuker> "Robins are one of the few birds that hold a territory throughout the winter so continue to sing when the majority of other birds have stopped. "
[04:31:19 CET] <atomnuker> ITS FUCKING 03:30 AT NIGHT AND THAT STUPID MISERABLE PIECE OF SHIT IS UNDER A STREET LAMP THINKING ITS DAY ANS SINGING
[04:42:52 CET] <BBB> lol
[04:42:59 CET] <BBB> at least it allows you to continue working at night
[04:43:06 CET] Action: BBB zzz now
[05:35:44 CET] <wm4> jkqxz: I want to make libavfilter filters export which hwcontexts they accept (hw_frames_ctx on filter pads, and hw_device_ctx on the filter itself)
[05:35:53 CET] <wm4> jkqxz: do you have any thoughts about this?
[05:36:09 CET] <wm4> also, in which phase should this happen? (after filter init, or filter configure)
[05:39:59 CET] <wm4> I'd probably make it an array of enum AVHWDeviceType, which a count so AV_HWDEVICE_TYPE_NONE can be part of it (on AVFilterContext and AVFilterPad)
[05:40:21 CET] <wm4> in truth this should probably be somehow part of query_formats, but that isn't public (or in any way flexible) in the first place
[14:13:34 CET] <cone-599> ffmpeg 03James Almer 07master:02dba49dd3f0: avformat/adtsenc: add adts_init()
[14:13:35 CET] <cone-599> ffmpeg 03Gyan Doshi 07master:96f94624e0a1: avformat/adtsenc: allow only AAC streams
[14:15:46 CET] <atomnuker> jkqxz: know why do I get an AV_PIX_FMT_UNDEFINED in frames_init if I put all pixel formats supported in get_constraints?
[14:16:27 CET] <wm4> because you need to set it yourself
[14:18:29 CET] <atomnuker> I guess I could skip doing that in the init function and do it every time in the pool alloc function
[14:20:14 CET] <wm4> no, the API user sets it
[14:20:17 CET] <wm4> that's how it works
[14:20:32 CET] <wm4> I don't know what you mean by pool alloc function
[14:21:54 CET] <atomnuker> the function you give to av_buffer_pool_init2()
[14:23:15 CET] <atomnuker> I still get a pix_fmt of 0 in that function, so do you think ffmpeg.c doesn't set the pix_fmt properly?
[14:27:43 CET] <wm4> what does av_buffer_pool have to do with frames at all
[14:28:11 CET] <wm4> a bunch of code uses that
[14:28:20 CET] <wm4> hwcontext backends can use it as a helper
[14:28:25 CET] <wm4> but what does that have to do with anything
[14:29:25 CET] <atomnuker> I need to know the sw_format to allocate an image but its blank
[14:29:45 CET] <atomnuker> I guess I'm doing something wrong, opencl uses ctx->sw_format there and its probably not 0
[14:30:01 CET] <wm4> allocate WHERE
[14:34:08 CET] <atomnuker> wm4: the pool allocation function, I'm using it as a helper in HWContextType.frames_get_buffer
[14:36:12 CET] <wm4> you need to set format and sw_format before av_hwframe_ctx_init, did you do that?
[15:03:58 CET] <atomnuker> no, you don't need to set the sw_format anywhere
[15:04:10 CET] <atomnuker> vaapi/opencl/qsv don't
[15:04:35 CET] <atomnuker> nor do you need to set the pix_fmt yourself, its derived from the HWContextType
[15:04:56 CET] <atomnuker> I think the order of formats in valid_sw_formats might be important
[15:06:41 CET] <wm4> looked at vaapi_frames_init, it definitely errors out if sw_format is not set
[15:11:32 CET] <atomnuker> grr, if I put anything extra or incorrect in valid_sw_formats in get_constraints I won't get a "preferred format" set in get_transfer_formats and I won't get anything in frames_init
[15:12:46 CET] <atomnuker> wait, what the fuck?
[15:13:23 CET] <atomnuker> if I put yuv444p first in valid_sw_formats and put another pix_fmt after it I get 0 as the preferred format in get_constraints
[15:13:43 CET] <atomnuker> if I put it second I get the first pixel format as preferred pix_fmt in get constraints
[15:15:17 CET] <atomnuker> wait, no, it depends on what I put first in valid_sw_formats
[15:15:27 CET] <atomnuker> what the fuck is wrong with this code?
[15:15:46 CET] <atomnuker> why does picking a bloody pix_fmt need to be so complicated
[15:16:39 CET] <atomnuker> what kind of animal do I need to sacrifice to the blood gods to make this work right?
[15:35:27 CET] <wm4> I'd blame lavfi format negtiation
[15:35:30 CET] <wm4> *negotiation
[15:35:34 CET] <wm4> I had my own fun with it
[15:35:47 CET] <wm4> is this for hw_upload or what
[15:35:59 CET] <atomnuker> upload/download
[15:36:31 CET] <atomnuker> it worked when I had my little list of exatly 1 supported pixfmt, but I've changed the way I handle formats and added loads more that vulkan supports
[15:37:41 CET] <atomnuker> (it does all yuv subsamplings at 8/10/12/16 bits, nv12, rgbs, etc., only planar rgb is missing but oh well, nothing shaders can't fix)
[15:39:39 CET] <wm4> how very backwards to use fixed function yuv conversion
[15:47:35 CET] <atomnuker> I thought about it, I'm doing this to make handling yuv images faster (on paper) and easier
[15:49:18 CET] <atomnuker> being able to use ycbcr samplers for images will be easier for api users too if they want to take the fixed function conversion path
[15:58:20 CET] <cone-599> ffmpeg 03sfan5 07master:66e551eafb8d: dashdec: Expose bandwidth and representation ID as metadata
[15:58:21 CET] <cone-599> ffmpeg 03sfan5 07master:94cc16499ff1: dashdec: Support for multiple video/audio streams
[15:58:22 CET] <cone-599> ffmpeg 03sfan5 07master:bb0cc2e7bd6d: dashdec: Search for segment timeline inside AdaptionSets too
[15:58:23 CET] <cone-599> ffmpeg 03sfan5 07master:74b143d81fa3: dashdec: Correct seeking behaviour
[15:58:35 CET] <sfan5> ah nice
[16:04:00 CET] <cone-599> ffmpeg 03sfan5 07master:01d74c405564: dashdec: Avoid trying to read any segments beyond the last
[16:04:01 CET] <cone-599> ffmpeg 03sfan5 07master:57dbabd9c13b: dashdec: Support SegmentTemplate inside Period
[16:12:01 CET] <atomnuker> does this make dashdec usable now?
[16:13:50 CET] <wm4> maybe... though it still depends on libxml2
[16:14:34 CET] <sfan5> usable for watching youtube videos
[16:14:43 CET] <sfan5> livestreams are still broken for some reason I couldn't figure out
[16:14:55 CET] <sfan5> youtube livestreams, at least
[16:15:32 CET] <atomnuker> libxml2 is kinda standard at least, it was installed by default on my machine
[16:16:10 CET] <JEEB> yea, both libxml2 and the other XML library are quite widely used
[16:17:22 CET] <wm4> libexpat would have been better IMO
[16:19:56 CET] <JEEB> well, that one had no code so the one that had any code won :)
[16:20:41 CET] <JEEB> in the end, I would guess most code dealing with XML would end up somehow being ugly/bad though
[16:20:47 CET] <JEEB> esp. with the complexity of something like MPEG-DASH manifests
[16:21:30 CET] <JEEB> the only positive thing is that there's an actual schema for MPEG-DASH manifests http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd
[16:21:39 CET] <JEEB> also I think there was a reference set >_>
[16:22:27 CET] <wm4> xml schema is one of those things even the devil should not have allowed to exist
[16:28:22 CET] <JEEB> MPEG-DASH is stupidly extensible
[16:28:23 CET] <JEEB> https://github.com/Dash-Industry-Forum/dash-live-source-simulator/wiki/Test-URLs
[16:35:26 CET] <wm4> is there a HLS live stream simulator?
[16:35:34 CET] <BtbN> Twitch
[16:35:45 CET] <wm4> finding twitch URLs is annoying
[16:35:57 CET] <BtbN> streamlink or youtube-dl gives them to you
[16:36:22 CET] <wm4> I mean finding web URLs
[16:36:29 CET] <BtbN> hm?
[16:36:58 CET] <wm4> most of those live URLs surely end at some point and then you need a new one
[16:37:03 CET] <wm4> not nice for testing
[16:37:12 CET] <BtbN> There are plenty of 24/7 channels on Twitch
[16:38:01 CET] <wm4> really, what do they even stream
[16:38:09 CET] <wm4> "the daily live of a gamer"
[16:38:14 CET] <BtbN> pretty much like a TV channel with gaming related content
[16:38:28 CET] <BtbN> https://www.twitch.tv/rocketbeanstv for example
[16:41:07 CET] <wm4> nice, I can immediately make libavformat choke by seeking forward
[16:43:43 CET] <wm4> well no idea what libavformat actually thinks it's doing
[16:43:58 CET] <wm4> I really need to make the hls demuxer export the seekable time range though
[18:58:14 CET] <durandal_1707> what codename for next release will be?
[20:35:42 CET] <rcombs> durandal_1707: if we call it blockchain maybe people will throw money at us
[20:36:46 CET] <sfan5> doesn't that only work if your company is listed on the stock market?
[20:49:53 CET] <iive> yeh, you need to provide a way for the people to throw money at you :D
[00:00:00 CET] --- Mon Jan 15 2018