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

[burek]

[00:33:19 CEST] <jkqxz> tmm1:  I don't think there is anything funny about it?  With the other SVC stuff implemented then it's just another NAL unit type, like the subset sequence parameter set.
[00:37:30 CEST] <jkqxz> I looked at including the SVC/MVC/3D syntax a while ago, but it's quite a lot of work and not really of much value to anyone.
[01:25:19 CEST] <tmm1> gotcha, thanks
[01:30:26 CEST] <jkqxz> Are you trying to implement something SVC?
[01:31:09 CEST] <jamrial> the vps extension stuff alone is a pita, last time i checked
[01:39:40 CEST] <tmm1> nah, i just noticed some "Decomposition unimplemented" log messages and was wondering if it was a quick fix to make them go away
[01:42:50 CEST] <jkqxz> With something which wasn't one of the SVC conformance test streams?
[01:45:17 CEST] <tmm1> yea a sample JEEB had, https://megumin.fushizen.eu/videos/2019-08-japan/VID_20190817_124927.mp4
[01:45:56 CEST] <tmm1> h264_analyze couldn't parse NAL_PREFIX so i'm not sure whats in there
[02:06:27 CEST] <rcombs> is patchwork down
[02:06:47 CEST] <nicolas17> rcombs: fails for me too
[02:09:18 CEST] <rcombs> cehoyos: heh, so decoding within lavf
[02:09:27 CEST] <cehoyos> Or not
[02:09:39 CEST] <rcombs> I'd considered that but had thought it seemed too extreme
[02:09:53 CEST] <rcombs> but if everyone else is okay with it
[02:12:20 CEST] <cehoyos> What did consider too extreme?
[02:12:24 CEST] <cehoyos> (Nobody is ok with it)
[02:12:27 CEST] <rcombs> decoding within lavf
[02:12:43 CEST] <cehoyos> I thought having code that nobody uses is not so good
[02:13:17 CEST] <rcombs> (I don't know if there's a particularly better way to do it, though; probably something weird in lavfi)
[02:13:48 CEST] <cehoyos> No (I mean of course, but not primarily), the code should be in the calling application, ffmpeg.c.
[02:14:17 CEST] <rcombs> some people discussed doing something with the HEVC decoder, or possibly having a BSF that generates tiled HEVC
[02:14:34 CEST] <cehoyos> Imo, this is not Alice in Wonderland...
[02:14:47 CEST] <cehoyos> (the bitstream filter)
[02:25:54 CEST] <jamrial> rcombs: a bsf wouldn't work. the tiles need to be assembled after decoding. so it's either libavfilter, or up to the user after libavformat returns the demuxed stream
[02:26:34 CEST] <rcombs> jamrial: HEVC has its own tiling syntax, so there was some speculation as to whether or not that could be used
[02:26:39 CEST] <rcombs> idk if it ever panned out though
[02:27:39 CEST] <jamrial> the point of using separate hevc images to combine into a single image after decoding is to get huge resolutions that no decoder could output otherwise
[02:28:56 CEST] <rcombs> my impression was that the codec-level tiling was similar, but that's about the extent of what I heard about it
[08:40:25 CEST] <peak3d> Hi, I'm from Kodi, for android h/w decoder feed we use ffmpeg lib to extract codec extradata if the source doesn't provide it (LiveTV for example). Code part: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxClient.cpp#L136-L182.
[08:41:43 CEST] <peak3d> We now need sample_aspect_ratio for an h.263 packet, but from debugging parser struct does not contain this field (android decoder does not provide it)
[08:41:57 CEST] <peak3d> (h.264, sry)
[08:43:10 CEST] <peak3d> parser already seems to have parsed SPS because the dimensions are set in parser struct, question is now if there is any way to get the sample_aspect_ratio without decoding the packet
[08:44:05 CEST] <peak3d> the fields in AVContext are all empty at this stage, neither width nor height are filled, the only usable information is in parser 
[08:48:14 CEST] <thardin> I was going to say this kind of info gets filled in when you decode the first packet, but if you want to avoid that then I suspect someone needs to implement it in the parser
[08:50:55 CEST] <peak3d> thardin: thx, ok, then for first I'll decode the frame, should not cost too much
[08:51:50 CEST] <peak3d> If it is too expensive (4K stuff), I'll provide a patch for it
[09:07:55 CEST] <thardin> sounds good. but there are peeps more knowledgable about h264 in lavc than me in here
[09:10:35 CEST] <peak3d> IMO the possibilities are limited, AVCodecParserContext does not contain such info (but width / height was added somewhen between 2.3 -> 4.0), I'll follow this code path to see if it is simple to append it
[09:16:21 CEST] <peak3d> There is another struct AVCodecParameters which contains the sample_aspect_ratio, not sure if this is only for encoders (??)
[09:17:20 CEST] <thardin> pass
[09:19:32 CEST] <kurosu> You need to get a SPS, and therefore the corresponding NAL
[09:20:03 CEST] <kurosu> This is located in the Video User Info, which is optional (but then that's the default value)
[09:21:16 CEST] <kurosu> peak3d: which is down to ff_h264_decode_seq_parameter_set, though I don't know what would trigger calling it
[09:21:47 CEST] <kurosu> But you certainly need to do some low level parsing
[09:25:43 CEST] <peak3d> kurosu SPS is already parsed inside ffmpeg during av_parser_parse2, I don't want to implement an own parser only because there is one field missing
[09:25:45 CEST] <peak3d> https://www.ffmpeg.org/doxygen/4.1/h264__parser_8c_source.html#l00391
[09:26:51 CEST] <peak3d> this is the place ffmpeg already sets AVParserContext fields from sps, so its a single line change ( or 5 lines changed if we do this for the other codecs, too) inside ffmpeg
[09:27:34 CEST] <kurosu> Right, you already get the SPS, so you're almost there but indeed the parser context doesn't have it
[09:27:50 CEST] <peak3d> I implemented yesterday an own SPS parser inside kodi, but I hate to implement things we already have in ffmpeg
[09:28:30 CEST] <peak3d> kurosu I'll add a patch for kodi, but will provide the change for discussion upstream
[09:30:32 CEST] <kurosu> You likely want SPS::sar and pass it down somehow, but then it becomes an ABI/API problem. That and the surprising fact that only h26* would implement populating the field at first
[09:30:56 CEST] <peak3d> IMO if we already provide width and height in ACParserContext (necessary e.g. to setup a display), sample_aspect_ratio makes sense, too. At least for kodi it would help (Android / ARM embedded h/w decoder) 
[09:32:07 CEST] <kurosu> Note: not an API or "high-level" designer, so even if I agree with you, I'm not the right person for continuing the discussion
[09:32:27 CEST] <kurosu> Likely talk to nevcairiel or jamrial whenever they are active
[09:32:28 CEST] <peak3d> kurosu right, its unfortunately an ABI/API change, because of that I'll patch in kodi's version and look where discussion ends
[09:33:11 CEST] <peak3d> maybe there are already som other requests about extending AVPaserContext, and we can do all with one bump
[09:34:07 CEST] <peak3d> will wait for them, thx already
[09:39:51 CEST] <peak3d> I would also love to have the timing information from SPS to make an early display mode switch
[09:40:30 CEST] <peak3d> Currently we display the first decoded frame, then switch mode, then seek backwards, it looks sometimes not quite nice
[09:41:11 CEST] <peak3d> (timing information = fps
[09:45:46 CEST] <kurosu> I believe this is again optional and highly unreliable
[09:47:29 CEST] <kurosu> peak3d: the question is about the API, not the fields needed, right? (otherwise, that's timing_info_present_flag and the 2 following fields)
[09:48:38 CEST] <kurosu> But then that's again the old debate of codec vs container timing info, with lots of heuristics
[09:54:51 CEST] <peak3d> yes, from techical PV its all simle, but I fear that the discussion takes much more time because of the reasons you mentioned
[09:54:59 CEST] <peak3d> POV
[09:59:16 CEST] <peak3d> I'm away now for the next ~ 5 hours, sry
[12:29:16 CEST] <cone-861> ffmpeg 03Nicolas Gaullier 07master:cae5b36e2071: avcodec/h264: Fix poc_lsb in open gop context
[17:23:25 CEST] <cone-556> ffmpeg 03Shiyou Yin 07master:de5543d8d442: avcodec/mips: Fix a warnning of indentation not reflect the block structure.
[17:23:26 CEST] <cone-556> ffmpeg 03Jun Zhao 07master:3740bdee77ae: lavf/avidec: fix memory leak in error handling path
[17:23:27 CEST] <cone-556> ffmpeg 03Pascal Massimino 07master:857fd2ad9903: avcodec/webp: fix decoding for trailing junk
[17:23:28 CEST] <cone-556> ffmpeg 03Nikolas Bowe 07master:b794df43f3a5: avfilter/vf_fps: Avoid inlink fifo build up.
[17:23:29 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:10ea6c3116f9: avcodec/pnm_parser: Use memchr() in pnm_parse()
[18:04:02 CEST] <durandal_1707> test
[18:05:42 CEST] <BradleyS> o7
[19:00:19 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:329505d90885: avfilter/vf_v360: add support for stereographic as input projection
[20:31:47 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:5fcb3cbaf0ba: avfilter/vf_v360: increase v_fov max limit
[20:31:48 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:e26fb6a714f6: doc/filters: extend flip options in v360 filter
[21:21:13 CEST] <durandal_1707> Lynne: how is vulkan framework going? i wish to write gpu v360 filter
[21:39:16 CEST] <Lynne> durandal_1707: I'll need to resurrect the scale filter to make sure lavfi-wise it still works
[22:33:38 CEST] <Lynne> durandal_1707: you can start from here https://0x0.st/zJls.patch https://0x0.st/zJlz.patch
[22:34:21 CEST] <Lynne> philipl: also implemented cuda semaphores ^^, but for some reason even if I disable them I leak GPU memory slowly, not sure where though
[22:53:06 CEST] <cone-556> ffmpeg 03Aman Gupta 07master:8a3623e2fbde: avcodec/mediacodecdec: warn when input buffers are not configured with proper size
[22:53:07 CEST] <cone-556> ffmpeg 03Aman Gupta 07master:7fddf4b2662b: avcodec/mediacodec_surface: define and use FFANativeWindow to mimic NDK interface
[00:00:00 CEST] --- Wed Sep 11 2019