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

[burek]

[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