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

[burek]

[09:48:21 CEST] <gagandeep> kierank: i think i understand pngdec file (both png and apng) and how frame threading is used
[09:48:51 CEST] <gagandeep> shall i discuss with you?
[09:50:34 CEST] <gagandeep> sync is with : ff_thread_report_progress and ff_thread_await_progress
[10:13:01 CEST] <thardin> so many mxf patches lately
[11:17:17 CEST] <HappyPonyLand> this was pretty depressing... was googling an error, came across a 2010 IRC log from this channel with the guy that originally implemented this code :|
[11:18:16 CEST] <atomnuker> what error?
[11:20:23 CEST] <HappyPonyLand> I'm having trouble linking __imp_av_pix_fmt_descriptors
[11:20:35 CEST] <HappyPonyLand> (also: hi! to the next person at our company reading this in 2026)
[11:21:10 CEST] <nevcairiel> you should ideally avoid linking to the data array directly and instead use the accessor function
[11:22:19 CEST] <nevcairiel> or do we not have one for that one? anyhow linking data arrays requires special care to be taken
[11:23:00 CEST] <nevcairiel> av_pix_fmt_desc_get is the accessor
[11:23:08 CEST] <HappyPonyLand> well, I had it working earlier so I must have mistakenly reverted something
[11:31:03 CEST] <BtbN> Even if it works, it won't be very stable. That's why the accessors exist
[11:31:27 CEST] <nevcairiel> if you get an _imp prefix you usually forgot to wrap it in an extern C block
[11:37:05 CEST] <HappyPonyLand> BtbN: we're using a forked 0.11 :| but I'll keep that in mind, I have a hunch I will be the one tasked with bringing us up to 4.0
[11:37:47 CEST] <BtbN> uhm... don't do that. That sounds like a really bad idea.
[11:41:55 CEST] <HappyPonyLand> I'm just following orders
[11:42:07 CEST] <HappyPonyLand> but yeah, it's a discussion for another day. it might be more trouble than it's worth
[12:03:41 CEST] <HappyPonyLand> thardin: oh hey
[13:02:31 CEST] <memeka> hi I have a weird issue maybe you guys can help
[13:03:12 CEST] <memeka> I am working on a custom decoder, and after the decoding is done, I get this behaviour:
[13:04:50 CEST] <memeka> when output pix_fmt is yuv420p, image pointers are 0 and I get segmentation fault; when output pix_fmt is rgb32 all is good
[13:09:57 CEST] <atomnuker> which codec are you writing a decoder for?
[13:11:34 CEST] <memeka> atomnuker: i am modifying v4l2m2m decoder, to automatically pass data through a v4l2m2m converter
[13:13:05 CEST] <memeka> atomnuker: if i hardcode converter to RGB32, something like ffmpeg -vcodec mycodec -i file -pix_fmt rgb32 out.mkv works
[13:13:47 CEST] <memeka> if i leave the pixfmt to be decided by ffmpeg, it will choose yuv420p
[13:14:15 CEST] <memeka> and ffmpeg -vcodec mycodec -i file out.mkv => segm fault at the first AVFrame out of my code
[13:14:34 CEST] <memeka> in the encoder somewhere, where it tries to access the AVFrame
[13:15:33 CEST] <jkqxz> Is the converter required to be part of the decoder?  (That is, you end up with something which looks like a single V4L2 device outputting the converted frames, and never see the intermediates.)
[13:15:48 CEST] <jkqxz> If not, you should probably write it as a filter rather than touching the decoder at all.
[13:16:02 CEST] <memeka> jkqxz: yes that's my intention, to have it part of the decoder
[13:16:04 CEST] <memeka> not filter
[13:16:13 CEST] <jkqxz> So it can't be separated?
[13:16:27 CEST] <memeka> jkqxz: it can, but I want it to be a whole thing
[13:17:07 CEST] <thardin> HappyPonyLand: who dis?
[13:17:16 CEST] <memeka> jkqxz: that's because I want to use dmabuf between the devices
[13:17:49 CEST] <memeka> and it would be more difficult to implement it as a filter, esp since atm v4l2m2m decoder only supports MMAP
[13:18:09 CEST] <jkqxz> There are patches for it outputting dmabuf referenced as DRM PRIME objects.
[13:18:21 CEST] <jkqxz> If you can take those as input then it should be a filter.
[13:18:39 CEST] <jkqxz> (Which can then also be used with things other than the decoder.)
[13:19:39 CEST] <HappyPonyLand> thardin: the ghost of your past mistakes
[13:19:49 CEST] <memeka> jkqxz: yes i know about them, but that's for DRM
[13:20:24 CEST] <memeka> jkqxz: I want: decoder <- zero copy -> converter <-> zero copy <-> drmprime
[13:20:40 CEST] <jkqxz> Which is what you would get with a filter.
[13:20:50 CEST] <jkqxz> You really don't want to tie that into the decoder.
[13:21:08 CEST] <memeka> jkqxz: it would be difficult to implement zero copy with the filter atm
[13:21:43 CEST] <memeka> since, like i said, v4l2m2m stuff in ffmpeg is only MMAP
[13:22:51 CEST] <jkqxz> Well, use the patches on the ML for making it output DRM objects for your testing.
[13:22:53 CEST] <memeka> i am talking about V4L2_MEMORY_MMAP and V4L2_MEMORY_DMABUF, not exporting out of the decoder
[13:23:09 CEST] <jkqxz> Since the components are completely independent you don't need any dependency.
[13:23:21 CEST] <memeka> jkqxz: I my DRM and my decoder don't use the same pixel format
[13:23:43 CEST] <memeka> so yeah i can use those patches to export DRM, but DRM won't accept it
[13:23:59 CEST] <memeka> I need to convert first to something DRM accepts
[13:24:27 CEST] <memeka> and using a filter will not be zero copy
[13:24:37 CEST] <memeka> hence I want to hide the conversion within the decoder
[13:24:57 CEST] <memeka> plus, I already got it working (well kind of :P)
[13:25:26 CEST] <memeka> I don't understand why the resulting AVFrame, if it's got pix_fmt rgb32 is OK, if it's got pix_fmt yuv420p it's not 
[13:25:56 CEST] <Shibe> im not quite sure i understand what time_base is. What unit is it in? nanoseconds?
[13:26:58 CEST] <jdarnley> Seconds, isn't it?
[13:28:34 CEST] <jdarnley> Yep, that's what avcodec.h says
[13:29:50 CEST] <jkqxz> Why would a you not be able to use zero copy?  The DRM objects pass between decoders and filters normally.
[13:36:45 CEST] <memeka> jkqxz: can you explain?
[13:37:08 CEST] <memeka> converter needs to CHANGE the data right?
[13:37:50 CEST] <atomnuker> yes, please, do make v4l2 use the standard hardware infrastructure we have, it sucks its implemented the way it is currently as a custom decoder
[13:38:12 CEST] <jkqxz> The decoder outputs DRM objects in some format.  The converter takes those as input (without copying), and then writes output in some new format (also as DRM objects) and returns that to the user.
[13:39:56 CEST] <atomnuker> I wish the encoder would accept dmabuf avframes too, it would allow screen recording on arm devices
[16:10:42 CEST] <cone-124> ffmpeg 03Gyan Doshi 07master:4cd5c3f9ec78: doc/filters: state negate filter's option
[19:54:20 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:bab0716c7f47: avformat/mxfdec: Fix av_log context
[19:54:21 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:2b46ebdbff1d: avformat/asfdec_o: Check size_bmp more fully
[19:54:22 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:a7e032a27745: avformat/rmdec: Do not pass mime type in rm_read_multi() to ff_rm_read_mdpr_codecdata()
[19:54:23 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:9807d3976be0: avformat/pva: Check for EOF before retrying in read_part_of_packet()
[22:29:25 CEST] <relaxed> .quit
[00:00:00 CEST] --- Fri Jul  6 2018