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

Sun Jul 28 03:05:05 EEST 2019

[01:45:10 CEST] <cone-004> ffmpeg 03Michael Niedermayer 07master:38b6c48c4300: avcodec/brenderpix: Check input size before allocating image
[01:45:10 CEST] <cone-004> ffmpeg 03Michael Niedermayer 07master:47b6ca0b022a: avcodec/assdec: undefined use of memcpy()
[02:31:21 CEST] <tmm1> how can i dump out sidedata for output packets in ffmpeg cli
[02:36:25 CEST] <kierank> showinfo?
[02:52:35 CEST] <tmm1> i thought there was one like bsf trace_headers, but perhaps i'm thinking of ffprobe formats
[02:52:53 CEST] <tmm1> does pbc require AV_INPUT_BUFFER_PADDING_SIZE ?
[02:54:12 CEST] <tmm1> seems not, only gbc does
[15:08:29 CEST] <durandal_1707> kierank: see cfhd patch on ml, works will all cfhd samples i have
[15:09:14 CEST] <kierank> durandal_1707: all samples in that directory I gave?
[15:09:44 CEST] <durandal_1707> bayer
[15:09:54 CEST] <durandal_1707> reto samples
[15:25:42 CEST] <kierank> durandal_1707: patch is actually ok
[15:25:44 CEST] <kierank> I guess ffplay converts to rgb?
[15:25:58 CEST] <kierank> durandal_1707: I thought you were going to convert to rgb in decoder
[15:27:16 CEST] <durandal_1707> there is ugly bayer conversion in swscale
[15:29:28 CEST] <jamrial> it's getting tiresome being pinged by fflogger every other hour :/
[15:31:59 CEST] <durandal_1707> which client you use?  i do not get pings even if I'm being pinged
[15:32:21 CEST] <durandal_1707> unless i receive private message ...
[15:33:05 CEST] <kierank> irccloud
[15:36:04 CEST] <kierank> durandal_1707: I am testing patch
[15:37:44 CEST] <kierank> durandal_1707: I guess we need to do prores raw
[15:37:46 CEST] <kierank> and blackmagic raw
[15:38:16 CEST] <durandal_1707> insert *COINS*
[15:38:22 CEST] <kierank> sure
[15:38:25 CEST] Action: kierank don't care
[15:42:57 CEST] <kierank> durandal_1707: there are bayer samples with transform-type=2
[15:43:45 CEST] <kierank> http://www.siliconimaging.com/DigitalCinema/Gallery/2%20Flags%20Trailer_HD_English.avi
[15:48:23 CEST] <durandal_1707> kierank: hmm, is that supported by gsoc patch somehow, i do not have that updated code with me to check
[15:48:34 CEST] <kierank> durandal_1707: yes
[15:48:43 CEST] <kierank> at the moment trying to unzip file
[15:48:48 CEST] <kierank> uses weird mac zip format
[15:49:07 CEST] <durandal_1707> kierank: what file are you unzipping?
[15:49:58 CEST] <kierank> http://www.siliconimaging.com/DigitalCinema/Gallery/Taxi_Driving.zip
[16:51:43 CEST] <soreau> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2018-March/039090.html <-- This seems to still be a problem. I don't see a bug report for it, should there be?
[16:58:35 CEST] <jamrial> soreau: open a ticket in trac.ffmpeg.org. if it's a duplicate it will be closed as such
[17:23:10 CEST] <soreau> jamrial: Do you want me to cc you since it seems to be your patch that started this problem?
[17:23:57 CEST] <soreau> jamrial: http://trac.ffmpeg.org/ticket/8042
[17:35:39 CEST] <jamrial> soreau: what patch?
[17:36:26 CEST] <jamrial> oh, ae7df68edd? then that means the encoder is sending invalid extradata
[17:36:53 CEST] <jamrial> the reason it works for mp4 but not mkv is because the mkv muxer actually looks at the return value of ff_isom_write_avcc(), which the mp4 muxer doesn't
[17:37:13 CEST] <jamrial> so technically, the mp4 output is invalid
[17:39:59 CEST] <mkver> Does the enconder convey the extradata in-band (I presume it does, otherwise the mp4 wouldn't play)?
[17:41:17 CEST] <soreau> jamrial: so what might be the fix?
[17:42:15 CEST] <mkver> The typical solution for this is to reserve space for extradata and look for whether the first packet contains the needed extradata.
[17:42:30 CEST] <mkver> If it does and fits into the reserved space, it is used.
[17:44:03 CEST] <jamrial> i think new extradata signaled through side data is used for these cases, assuming the encoder doesn't propagate extradata during init()
[17:44:28 CEST] <jamrial> see aac/flac/av1 on mkv and mp4
[17:45:22 CEST] <mkver> But afaik the mp4 muxer doesn't check for side data extradata.
[17:45:49 CEST] <jamrial> not for h264, but it does for those codecs i listed
[17:46:28 CEST] <jamrial> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=a96139077b24024abd94758798755473f2a0c372;hb=HEAD#l5567
[17:47:58 CEST] <mkver> Given that mp4 works fine, this means that this encoder uses in-band extradata.
[17:48:16 CEST] <jamrial> looking at vaapi_encode.c, it seems it's exporting extradata during init
[17:49:19 CEST] <jamrial> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode.c;h=dd2a24de0460bd2e65cc0ed25cf2dc26ab800d7d;hb=HEAD#l2212
[17:50:47 CEST] <mkver> soreau: Can you upload an mp4 sample? I wonder what is in this extradata.
[17:50:57 CEST] <soreau> mkver: sure
[17:51:07 CEST] <soreau> mkver: do you want the input or output?
[17:51:23 CEST] <mkver> The mp4 output.
[17:51:39 CEST] <soreau> mkver: and what is your preferred upload platform?
[17:51:59 CEST] <mkver> Any filehoster that doesn't require a premium account.
[17:52:09 CEST] <jamrial> if it's smaller than 2mb or so, you can attach it to the trac ticket
[17:52:31 CEST] <jkqxz> jamrial:  Well, unless the driver doesn't support the headers.  You get a large and hard-to-ignore warning message telling you what's wrong in that case, though (line 1885).
[17:53:57 CEST] <jamrial> jkqxz: ah, so it can depend on the driver
[17:54:13 CEST] <soreau> mkver: http://trac.ffmpeg.org/attachment/ticket/8042/output.mp4
[17:54:28 CEST] <soreau> jamrial: thanks, I did attach it to the ticket
[17:54:28 CEST] <jamrial> that warning doesn't seem to be printed in the output posted in the ffmpeg-user email, though
[17:56:36 CEST] <mkver> Empty avCC (except the length field and the "avcC")
[17:57:02 CEST] <soreau> jkqxz: yes I get this messages but I also get them in the working mp4 case
[17:57:03 CEST] <jamrial> expected since it aborts at the first size check
[17:57:36 CEST] <jamrial> soreau: as i said, mp4 muxing "works" because it's ignoring the error returned by the avcC writing function
[17:57:46 CEST] <soreau> jamrial: oh ok
[17:58:07 CEST] <soreau> jamrial: well just 'break' mkv in the same way :)
[17:58:08 CEST] <jamrial> the result is a technically invalid mp4 file, but that can be played because the required sps is in-band as well in the first packet
[17:58:44 CEST] <jamrial> nope, not going to allow the creation of non spec compliant files ;)
[17:58:55 CEST] <soreau> jamrial: so we're just fortunate mp4 works
[17:59:26 CEST] <jamrial> ffmpeg can demux it, but some other strict player or demuxer may actually reject it because of the empty avcC box
[18:02:33 CEST] <mkver> E.g. mkvmerge doesn't recognize the track.
[18:03:33 CEST] <soreau> is there a fix for all of this? and is it simple
[18:04:14 CEST] <jkqxz> soreau:  Add packed header support to the VAAPI driver in Mesa.
[18:04:58 CEST] <mkver> One would have to adapt the muxers to check for in-band extradata (or packet side data -- but then the encoders would have to be changed, too) in the first packet and act appropriately.
[18:05:16 CEST] <soreau> jkqxz: It needs that and also ability to accept rgb format data (currently feeding it rgb data is treated as yuv and crashes because it thinks it has two planes instead of one)
[18:05:29 CEST] <soreau> jkqxz: If I knew how to do this, I would add it
[18:05:41 CEST] <soreau> but sadly I can't seem to get any st/va help
[18:05:57 CEST] <jkqxz> mkver:  Wrt codecpar update, I really don't like the -1, -1, -1, -1 thing along with all the extra pointers.
[18:06:05 CEST] <jkqxz> An alternative suggestion: make a new structure which contains the parameters that might need to be updated, then have an init function for it which sets them all to -1 and an update function which applies it to a codecpar.
[18:06:36 CEST] <jkqxz> Put one of those in each BSF context structure: call init on it at the start of filter, modify it inside filter and callees thereof, call update with it at the end of filter.
[18:07:08 CEST] <jkqxz> Does that sound sensible to you?
[18:08:00 CEST] <jkqxz> soreau:  Er, so always give it YUV data?  -vf scale_vaapi=format=nv12 or whatever.
[18:08:18 CEST] <soreau> jkqxz: https://bugs.freedesktop.org/show_bug.cgi?id=110719
[18:08:34 CEST] <jamrial> mkver: no need to change encoders for that since the user can just inject the extract_extradata bsf to the muxing process
[18:08:38 CEST] <soreau> jkqxz: I give it rgb0, it treats it as yuv
[18:08:42 CEST] <mkver> This would mean that said structure would always be updated on every e.g. SPS ever encountered in-band?
[18:08:57 CEST] <soreau> jkqxz: btew can you reply to bug 8042 with your general thoughts please?
[18:09:00 CEST] <soreau> btw*
[18:09:02 CEST] <mkver> The extract_extradata bsf has a bug though: It always creates annexb extradata.
[18:09:41 CEST] <jkqxz> mkver:  s/filter/init/ if preferred.
[18:10:23 CEST] <soreau> jkqxz: as this is in a screen recording application, time is of the essence
[18:11:49 CEST] <soreau> jkqxz: ideally, the driver would accept rgb0 data happily like the intel vaapi driver does
[18:12:32 CEST] <soreau> but I can't figure out if the hardware can accept it natively or must do some conversion
[18:12:54 CEST] <soreau> I wrote an opencl shader to do the conversion so sws_scale() doesn't have to but it feels pretty hacky
[18:12:57 CEST] <jkqxz> That is a really weird hacky conversion in the intel driver.  I strongly recommend not using it, rather do the conversion outside.
[18:13:00 CEST] <jamrial> mkver: yes, it would be update every time it encounters sps, which is probably not a good idea since they may not be meant to apply "globally"
[18:13:20 CEST] <jamrial> mkver: and the avcC writing function will convert it from annex-b just fine
[18:13:24 CEST] <soreau> jkqxz: Well the other option is my opencl shader solution..
[18:13:38 CEST] <soreau> and that's nearly as bad
[18:13:43 CEST] <jkqxz> soreau:  Why not the VAAPI converter?
[18:13:52 CEST] <soreau> jkqxz: what do you mean?
[18:14:01 CEST] <mkver> But the avcC writing function looks at what the extradata is and determines whether the input is annexb based upon this.
[18:15:13 CEST] <jkqxz> soreau:  The RGB -> YUV conversion, which is implemented in the Mesa driver.
[18:15:31 CEST] <soreau> jkqxz: I don't think I can use it to convert rgb0 data into any other form because it (radeonsi_drv_video.so) crashes as in the bug report I linked above
[18:16:18 CEST] <soreau> jkqxz: I am not aware of RGB -> YUV conversion implementation in mesa
[18:17:21 CEST] <jkqxz> Works for me.
[18:17:25 CEST] <jkqxz> (On Polaris.)
[18:17:38 CEST] <soreau> jkqxz: I am on polaris11. What works for you exactly?
[18:19:13 CEST] <jkqxz> Here <https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/vl/vl_compositor.c#n701>.
[18:19:31 CEST] <jkqxz> Conversion from RGB to YUV works for me.
[18:20:07 CEST] <soreau> jkqxz: but how are you using or testing this function?
[18:20:29 CEST] <jkqxz> With scale_vaapi.
[18:21:47 CEST] <soreau> jkqxz: what's the libav equivalent?
[18:22:20 CEST] <jkqxz> It's in libavfilter.
[18:23:54 CEST] <soreau> huh
[18:24:10 CEST] <soreau> I can't seem to google anything up on how to use it from C/C++
[18:24:47 CEST] <soreau> and there's no obvious scale_vaapi() function from what I can tell
[18:25:09 CEST] <jkqxz> E.g. hardware screen capture for VAAPI on AMD: "ffmpeg -y -vsync 0 -device /dev/dri/card1 -f kmsgrab -i - -vf 'hwmap=derive_device=vaapi,scale_vaapi=format=nv12' -c:v h264_vaapi -b:v 2M -frames:v 100 -profile:v main out.mp4".
[18:25:46 CEST] <soreau> well it would be nice if the driver detected rgb0 as input format and did the conversion automatically instead of crashing
[18:26:05 CEST] <soreau> jkqxz: I'm talking about how to do it from code using libav
[18:27:18 CEST] <jkqxz> There's a filtering example somewhere in the tree, or ffmpeg.c is an example of pretty much everything.
[18:43:02 CEST] <soreau> huh. I just flipped the bit to report packed headers supported and now vaapi+mkv magically works.. but is it only working by chance since packed headers are probably not actually implemented?
[18:43:27 CEST] <soreau> in the va driver
[18:44:38 CEST] <jamrial> if ff_isom_write_avcc() succeeds, which would be required for mkv to not fail, then the vaapi encoder probably sent valid headers in extradata
[18:44:39 CEST] <jkqxz> You'll probably get one generated header on the file, then a probably-different header inline.  It will work with things which accept header changes inline, like ffmpeg.
[18:45:42 CEST] <soreau> jkqxz: how can I test if it will fail?
[18:45:46 CEST] <mkver> output.mp4 is annexb btw.
[18:46:30 CEST] <mkver> I just found out after wondering why it works at all (because non-annexb would fail if the NALU length size were unknown).
[18:47:25 CEST] <jamrial> ok, then we definitely need to make the mp4 muxer abort on avcC writing failure
[18:48:23 CEST] <soreau> I just can't imagine the support is there but the bit wasn't flipped https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/config.c#n145
[20:18:29 CEST] <durandal_1707> sci-hub is useless, gives borked files 
[20:27:39 CEST] <durandal_1707> what was name of library that supposedly handles mxf better than ffmpeg?
[20:27:53 CEST] <JEEB> was it not libmxf?
[20:28:02 CEST] <JEEB> the one on SF if I recall correctly
[20:30:15 CEST] <Lynne> so lavc's fft has 2 defines to control the type
[20:30:34 CEST] <Lynne> guess what the type is without looking if FFT_FLOAT = 0 and FFT_FIXED_32 = 0
[20:33:52 CEST] <Lynne> int16_t -_-
[20:36:23 CEST] <Lynne> it uses the same code as float but with a changed type and a few changed macros
[20:36:53 CEST] <Lynne> meanwhile the 32 bit int fft is completely separate from everything but is latched on like an afterthought
[20:37:58 CEST] <durandal_1707> that was days...
[20:39:30 CEST] <Lynne> I don't think the 16 bit fft is correct or anywhere near good, it uses 16 bit intermediaries all throughout
[20:39:56 CEST] <kierank> durandal_1707: bmxlib-libmxf
[20:41:28 CEST] <durandal_1707> kierank: they do not support bunch of stuff, and also other uncompressed raw formats
[20:41:57 CEST] <kierank> sure
[20:42:02 CEST] <kierank> but they can write compliant
[20:43:15 CEST] <durandal_1707> ffmpeg is compliant too
[20:53:01 CEST] <kierank> durandal_1707: I am told it is not
[20:53:08 CEST] <kierank> but i am not mxf expert and certainly do not want to become one
[20:58:15 CEST] <soreau> jamrial: thanks for the help, I suppose I should file one for mesa
[21:01:03 CEST] <durandal_1707> last bmxlib build from 2017
[21:02:25 CEST] <kierank> use it
[21:02:26 CEST] <kierank> git
[21:33:28 CEST] <jamrial> Lynne: git format-patch with -M didn't work to make that patch smaller?
[21:37:30 CEST] <Lynne> no, same size, tried -M90% to -M5%
[22:39:09 CEST] <JEEB> (34
[23:41:54 CEST] <Lynne> also: turns out the 16 bit int fft isn't actually used anywhere
[00:00:00 CEST] --- Sun Jul 28 2019