[02:44:49 CET] <mkver> Does someone have the log of ffmpeg-meeting and could make it available (preferably putting it in the usual archive)? [02:50:43 CET] <BBB> mkver: if you don't get a response, can you ask again at the end of the week? I'll be back from tokyo by then and can post it then (if nobody objects) [02:51:20 CET] <mkver> Ok. Thanks for the offer. [08:52:05 CET] <rcombs> jkqxz: got a weird issue here that seems like it's _probably_ an iHD bug but wanted to double-check if you think there might be something else wrong [08:52:09 CET] <rcombs> LIBVA_DRIVER_NAME=iHD ffmpeg '-hwaccel:0' 'vaapi' '-i' 'infile.mkv' '-filter_complex' '[0:0]scale=w=1920:h=1080[2];[2]format=pix_fmts=nv12[3]' '-map' '[3]' -b 6000k 'out.mkv' '-y' '-init_hw_device' 'vaapi=vaapi:/dev/dri/renderD128,driver=iHD,kernel_driver=i915' '-filter_hw_device' 'vaapi' [08:52:41 CET] <rcombs> ^ pretty basic pipeline; on J3455 it's giving corrupted output (looks like a stride error?) [08:53:16 CET] <rcombs> same thing happens with the hwmap filter [08:54:14 CET] <rcombs> cc: tmm1 [08:54:35 CET] <rcombs> input being h264 [08:59:37 CET] <rcombs> I get this: https://puu.sh/EDAZu/9dc31057af.png when I should get this: https://puu.sh/EDB0P/f1d0725d0e.png [09:02:09 CET] <rcombs> (input is 1080, the scale's not actually doing anything) [09:05:58 CET] <rcombs> interestingly, it doesn't happen if I hwmap to yuv420p (but does if I hwmap to nv12, or hwdownload to yuv420p) [14:39:07 CET] <Lynne> can someone tell the heif person that the patch won't get merged for like a third time? [14:42:51 CET] <jamrial> Lynne: why? [14:59:49 CET] <Lynne> decoding in lavf [15:01:56 CET] <thardin> heif is nasty [15:02:22 CET] <thardin> when I looked at it I had doubts it can even fit in ffmpeg's data model [15:02:43 CET] <kurosu> this data embedding thing is even nastier wrt ffmpeg architecture [15:03:07 CET] <kurosu> same with a thing called scalable hevc (for which I've only seen hacks upon hacks over ffhevc) [15:03:32 CET] <thardin> is scalable hevc like bitrate slicing? [15:04:17 CET] <kurosu> in the same stream you have some data decodable as a low-resolution version, and then other streams increasing quality or resolution [15:04:38 CET] <thardin> but ffmpeg already has that lowres stuff [15:04:40 CET] <kurosu> the data is indeed in separate slices/NAL units [15:04:50 CET] <kurosu> like jpeg2k you mean ? [15:05:02 CET] <thardin> that too [15:05:08 CET] <thardin> FLIF can do it too [15:05:10 CET] <kurosu> the decoder from one resolution needs access to the lower resolution one [15:05:10 CET] <thardin> and .rm [15:05:35 CET] <thardin> myes, you'd need a decoder that takes multiple packet streams [15:06:04 CET] <kurosu> anyway, that's a side discussion though, just that some things are not so neat in ffmpeg [15:06:46 CET] <kurosu> though I don't see anyone pouring the necessary work for proper solutions [15:33:28 CET] <cone-647> ffmpeg 03Michael Niedermayer 07release/4.0:2bdcfe88973e: Update for 4.0.5 [17:49:41 CET] <TekniQue> anyone here familiar with the different ways of packing H.264 NAL (byte stream or packet stream) [17:51:48 CET] <TekniQue> I've found that ffmpeg is not 100% consistent in how it packs the raw H.264 data [17:52:01 CET] <TekniQue> when using mp4 container it is consistently packed as byte stream [17:52:20 CET] <TekniQue> but when using nut container it is usually packed as packet stream but occasionally as byte stream [17:53:31 CET] <TekniQue> and I'm wondering how I can force it to be one or the other [18:21:48 CET] <JEEB> TekniQue: I know that with movenc (which writes mp4) it will attempt to probe if the input is annex b or avcc and if needed will convert to the latter via ff_hevc_annexb2mp4 [18:22:00 CET] <JEEB> while nut muxer does not have that logic [18:22:15 CET] <JEEB> in other words, it thus falls upon your encoder (be it libx264 or otherwise to set a specific format) [18:24:18 CET] <TekniQue> JEEB: I see [18:25:26 CET] <JEEB> possibly -flags +global_header might help with it [18:25:40 CET] <JEEB> also wait, this is -devel :P [18:26:42 CET] <TekniQue> Yeah well I'm developing something [18:27:35 CET] <JEEB> this is related to FFmpeg development :) [18:27:55 CET] <JEEB> but yea, if you are developing a muxer in FFmpeg [18:28:04 CET] <JEEB> then you can set the auto-added bsf [18:28:08 CET] <JEEB> if you need annex b [18:28:28 CET] <JEEB> and for avcc forcing you need to do what movenc does [19:31:33 CET] <thardin> there's today's MXF language lawyering [19:35:04 CET] <JEEB> (44 [22:06:00 CET] <durandal_1707> michaelni: why you was tired? [22:16:27 CET] <michaelni> durandal_1707, noise from neighbor at time when i wanted to sleep [22:18:08 CET] <JEEB> that sucks. thankfully most of my neighbors have been generally nice [22:24:30 CET] <BradleyS> clearly j-b needs to create the videolan standard issue vlc hat earplug set [22:24:44 CET] <BradleyS> 10/10 would buy [22:25:08 CET] <BradleyS> s/hat/cone/ [22:25:19 CET] <BradleyS> but you can wear them with your hat! [22:25:34 CET] <BradleyS> (now i'm thinking about making vlc cone earrings) [22:26:22 CET] <BradleyS> and holidays are coming, tree ornaments [22:26:31 CET] <BradleyS> j-b take my money already [00:00:00 CET] --- Wed Nov 13 2019