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

[burek]

[00:16:20 CEST] <rcombs> oh, they left
[00:16:39 CEST] <rcombs> I tried to add HEIF support a while back and ended up deciding it's impossible to reasonably integrate into lavf and gave up
[00:16:59 CEST] <rcombs> because the tiling is stupid
[00:17:22 CEST] <rcombs> it's container-level tiling of codec-level frames, I don't know how you'd sanely present that
[00:17:42 CEST] <rcombs> it's trivial to expose them all as separate streams, but then the API consumer has to stitch them
[00:18:07 CEST] <rcombs> and there's not really a reasonable way to expose the stitching metadata
[00:18:19 CEST] <nevcairiel> I would export them as one stream, one frame per tile, some stream metadata, and thats it for avcodec
[00:18:24 CEST] <nevcairiel> let avfilter then stitch it
[00:18:56 CEST] <rcombs> so avfilter buffers the frames and stitches them based on some opaque-to-user stream meta?
[00:18:59 CEST] <nevcairiel> definitely no stitching in avcodec
[00:19:03 CEST] <rcombs> or, I guess it doesn't have to buffer them at original res
[00:19:05 CEST] <nevcairiel> well not necessarily opaque
[00:19:21 CEST] <nevcairiel> could just be aome openly defined metadata
[00:19:25 CEST] <nevcairiel> which avfilter can consume
[00:19:31 CEST] <nevcairiel> or the user can if he is into that
[00:19:33 CEST] <rcombs> would that be a metadata string, or some sort of side-data attachment?
[00:19:41 CEST] <nevcairiel> sidedata i reckon
[00:20:05 CEST] <rcombs> I guess you could do a stream-level side-data for the overall res, and then a packet-level one for the coordinates of each frame
[00:20:13 CEST] <nevcairiel> i want to say stream level, but i already forsee that it needs to be frame level because someone makes that into more hten one image per container with different tiling setups
[00:20:33 CEST] <rcombs> yeah that's a thing you can do
[00:20:42 CEST] <nevcairiel> fuck those people that made that
[00:21:03 CEST] <rcombs> technically HEIF has a ridiculous number of features that nobody is likely to ever implement
[00:21:08 CEST] <jamrial> can each tile be decoded alone? avfilter expects raw decoded frames
[00:21:10 CEST] <rcombs> it's almost PSD-like
[00:21:14 CEST] <rcombs> jamrial: yes
[00:21:23 CEST] <jamrial> alright
[00:21:25 CEST] <nevcairiel> we'll make an open format thats so complicated that everyone will just pay us to use our implementation, instead of making it proprietary
[00:21:37 CEST] <rcombs> oh actually this is a bit tricky for the single-stream concept: they have separate extradata
[00:21:38 CEST] <jamrial> otherwise, it sounded more like the job for a bsf, that the demuxer can invoke
[00:21:51 CEST] <rcombs> I guess you could return annexb
[00:21:51 CEST] <nevcairiel> throw extradata updates into every frame
[00:21:57 CEST] <Lynne> yep, that's what I suggested, I did look into it and it seems possible
[00:21:58 CEST] <nevcairiel> the decoder wont be too happy but it should cope
[00:22:28 CEST] <rcombs> well, I've got code to parse this (and export separate streams) around somewhere
[00:22:34 CEST] <rcombs> I might give this a go again
[00:22:45 CEST] <nevcairiel> isnt that a GSOC project
[00:22:54 CEST] <nevcairiel> i have no  clue if we even got accepted and have students
[00:23:03 CEST] <rcombs> idk I wrote it ages ago
[00:23:12 CEST] <jamrial> maybe that's _bluez 
[00:23:16 CEST] <rcombs> and then realized the tiling shit is actually used in practice and gave up
[00:23:35 CEST] <Lynne> thankfully you can disable filtering across tiles in hevc (should really be enabled but obviously blocking artifacts are less important than making everyone's life a misery)
[00:23:57 CEST] <nevcairiel> well most gsoc projects are rather silly, but the people that run that will tell you that we shouldn't complain unless we can provide better ideas .. but the l ack of a better idea doesn't improve the ones they had :P
[00:23:59 CEST] <rcombs> idk why they decided to do container-level tiles, yeah
[00:24:19 CEST] <nevcairiel> I reckon container level tiles exist because in practice hevc decoders have s ize limits
[00:24:58 CEST] <nevcairiel> and decoding  x tiles of size/x is a thing they can do, instead of just a frame of full size
[00:25:23 CEST] <nevcairiel> and effing digital camera resolution is going through the sky
[00:26:28 CEST] <nevcairiel> in any case that approach should be workable, and with any luck the decoder wont even need any changes, all in demuxing and filtering
[00:26:51 CEST] <rcombs> yeah, when I tested this out ages ago the individual tiles decoded just fine
[00:27:14 CEST] <rcombs> worst-case the decoder might need some tweaks to make sure the side-data gets passed along? but iirc generic lavc code handles that already
[00:27:22 CEST] <nevcairiel> yeah it should
[00:27:40 CEST] <rcombs> speaking of weird apple HEVC extensions, has anyone looked at the alpha thing yet
[00:27:46 CEST] <Lynne> I don't like the lavfi approach though, stitching them in the decoder would be better
[00:28:07 CEST] <Lynne> obviously a bsf would be the best since you could integrate that into lavf too
[00:28:26 CEST] <rcombs> idk how you'd do it in a bsf
[00:28:43 CEST] <nevcairiel> stitching in decoder would be a nightmare with hwaccel
[00:28:54 CEST] <philipl> That's also a problem.
[00:28:57 CEST] <jamrial> rcombs: the vps extension parsing is a bitch, and the decoder right now downright ignores spatial layers other than 0
[00:29:15 CEST] <rcombs> unless HEVC has some built-in tiling that's extremely compatible with this concept already
[00:29:38 CEST] <philipl> You want to do hw decode & display, you'd have to stitch in GPU side code too.
[00:29:41 CEST] <rcombs> (I know it has tiling but idk if it's close enough to this to reasonably convert between them in a bsf, and then I'd worry about hwaccel, yeah)
[00:29:59 CEST] <nevcairiel> AVIF uses the same tiling with another decoder
[00:30:07 CEST] <nevcairiel> doing it out of decoder gets us that basically for free
[00:30:15 CEST] <rcombs> oh fuck did AVIF actually pull this shit
[00:30:17 CEST] <jamrial> stitching in bsf, if possible, would introduce the decoding size limit nevcairiel mentioned
[00:30:30 CEST] <Lynne> if the tiling in hevc is sane (e.g. byte aligned and completely independent) it should just be a matter of rewriting the header and stitching the tiles
[00:30:33 CEST] <nevcairiel> AVIF is basically HEIF with AV1 without any limits
[00:30:52 CEST] <rcombs> someone asked me about that a while ago and I told them "HEIF is basically alright but it's way over-featured, and in particular the tiling shit is a nightmare and shouldn't be included"
[00:31:05 CEST] <rcombs> and I was hoping they'd take that advice
[00:31:07 CEST] <rcombs> sounds like not
[00:31:10 CEST] <nevcairiel> I didn't see any exclusions in AVIF
[00:31:52 CEST] <nevcairiel> the spec doesnt even contain a format spec, it directly refers to HEIF and just tells you what to set some fields to, like brand etc
[00:35:39 CEST] <rcombs> there's also the "thumbnail" feature
[00:35:47 CEST] <rcombs> which should probably be its own stream
[00:38:39 CEST] <rcombs> does HEVC tiling support overlap
[00:40:50 CEST] <rcombs> >NOTE: In the case of HEVC tile items, the tile information given in the SubSampleItem may match the information in the ImageSpatialRelationBox of a single tile, e.g. horizontal_display_offset (resp. vertical_display_offset ) may be set to ctb_x (resp. ctb_y), but this is not mandated. Especially, if an author wishes to assemble a composition of HEVC tiles from different HEVC images, there will be no relationships between the SubSampleItem and the Imag
[00:40:51 CEST] <rcombs> eSpatialRelationBox.
[00:50:32 CEST] <rcombs> Lynne: so, the BSF route would only work if HEVC tiles can overlap, each have separate headers, and also AV1's tiles meet those requirements
[00:50:50 CEST] <rcombs> if that's all the case then it seems like a reasonable route to take; otherwise I think it's gotta be the filter
[00:52:59 CEST] <rcombs> (most importantly, I don't want to do anything that could result in lavf creating a bitstream that's only readable by lavc)
[00:54:03 CEST] <Lynne> side data does tick that mark since any decoder can just ignore it and decode each tile as-is
[00:54:27 CEST] <Lynne> also each tile in heif would need to not contain any heif tiles
[00:55:26 CEST] <Lynne> and the tiling dimensions used in heif would need to be compatible with hevc's spec
[00:55:53 CEST] <Lynne> well, if it doesn't work there's always the option to disable hwaccel for heif and do the stitching in the decoder
[01:08:18 CEST] <rcombs> jamrial: re: alpha, I'd imagine the bulk of it will just be "store 2 copies of the context and do everything, including hwaccel, twice", but I wonder about VideoToolbox, which I _think_ has support built-in
[01:08:54 CEST] <jamrial> i think that's what we're doing for vp9 alpha
[01:09:30 CEST] <rcombs> oh also, is there an existing pixfmt for this?
[01:09:41 CEST] <rcombs> well, multiple for different bit depths
[01:09:44 CEST] <rcombs> 4204, I guess
[01:10:38 CEST] <rcombs> oh yup AV_PIX_FMT_YUVA420P and co
[01:10:58 CEST] <rcombs> might want a 3-planar format, NV12A or something
[01:11:50 CEST] <rcombs> (assuming it's easy enough to just short-circuit the entirety of chroma decoding for this& though that might be a bit trickier for hwaccels&)
[01:12:31 CEST] <rcombs> fortunately nobody's actually asking me for HEVC+alpha support at the moment
[01:12:53 CEST] <rcombs> so I'm mostly discussing it here to make sure we don't make any decisions around HEIF that would make HEVC+alpha support more difficult down the line
[01:21:59 CEST] <cehoyos> How is alpha stored in hevc?
[01:26:22 CEST] <cehoyos> Found it: The spec say that the alpha layer has to be 4:2:0
[03:47:07 CEST] <electrotoscope> Hi I'm wondering if there's anything I could do about the patch at https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245694.html that is in response to https://trac.ffmpeg.org/ticket/7947
[03:47:37 CEST] <electrotoscope> Should I just reply in the mailing list with the text "ping" apologies for my ignorance of proper procedure
[03:59:57 CEST] <jamrial> electrotoscope: yes, ping asking for one of the two versions to be applied, if no further changes are required
[04:01:15 CEST] <electrotoscope> thanks!
[05:53:55 CEST] <cone-591> ffmpeg 03Steven Liu 07master:a514244319ab: avformat/dashdec: fix code style in dash_read_packet
[06:38:01 CEST] <prem> hi
[12:55:27 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:0f39ef4db2b8: avfilter/vf_lut: fix regression with >8bit planar filtering
[13:16:26 CEST] <mkver> The IRC logs are working again. Who have we to thank for this?
[13:54:34 CEST] <BtbN> Probably the one who replied on the ML saying to look into it.
[13:56:46 CEST] <durandal_1707> you are so ignorant, i mentioned fflogger here multiple times
[13:57:08 CEST] <nevcairiel> did you fix it? no? then why should we thank you? :P
[13:59:53 CEST] <BradleyS> "you are so ignorant" <- i think everyone will appreciate you not communicating this way, personal attacks are not helpful
[14:00:40 CEST] <BradleyS> you contribute a lot of good code and are appreciated, there's no reason to engage this way
[14:02:02 CEST] <durandal_1707> i'm sick of seeking political correctness
[14:02:20 CEST] <BradleyS> it's not politically correct to avoid attacking people
[15:56:07 CEST] <durandal_1707> why i can't get dehum working with FFT? i'm desperate, this should be trivial, reduce magnitude of static tones
[15:57:23 CEST] <j-b> durandal_1707: buy a brain enhancer :)
[15:57:51 CEST] <j-b> (joke for the people hard to understand)
[16:01:13 CEST] <BradleyS> how are you approaching the problem? targeting 50/60 Hz and harmonics?
[16:01:43 CEST] <BradleyS> a simple notch filter with harmonics would work fine, and you could make it dynamic by measuring the persistence and amplitude of the static tones
[16:08:32 CEST] <Lynne> I'd bandpass it between 40 and 70 hz, autocorrelate to find the peak-peak distance, average that with the last frame's and filter around that
[16:32:22 CEST] <durandal_1707> BradleyS: i just try to locate magnitudes that hardly change across time (comparing previous and current frame) and then reduce it by some factor
[16:33:00 CEST] <BradleyS> i would certainly limit that to low frequencies
[16:33:06 CEST] <BradleyS> probably <= 250 Hz
[16:33:33 CEST] <durandal_1707> yes, i resample audio to 2048 rate, and than FFT that with 2048 FFT
[16:34:20 CEST] <BradleyS> autocorrelation is a great idea Lynne
[16:34:41 CEST] <BradleyS> in fact there are analog stereos from the 70s and 80s that do that for noise reduction in high frequencies
[16:35:20 CEST] <BradleyS> phase linear 1000 and 4000 come to mind
[16:36:02 CEST] <BradleyS> bandpass is more correct, but i would go wider, say 25-250 Hz
[16:36:17 CEST] <durandal_1707> then i filter out so only hum remain and than just do original source - detected hum
[16:36:33 CEST] <BradleyS> so, half mains voltage (50 Hz eur, 60 Hz north am) up to the 4th or 5th harmonic
[16:36:52 CEST] <durandal_1707> if works wonders with static sine audio source provided by ffmpeg
[16:37:18 CEST] <BradleyS> autocorrelate and reduce the fundamental frequency, then do the same for harmonics reduced
[16:37:37 CEST] <durandal_1707> idea is it must be 0 phase so i can output only removed hum
[16:37:52 CEST] <BradleyS> so if you find hum at 50 Hz and reduce by 12 dB, you should reduce 100 Hz by N dB (maybe 6), etc... out as many harmonics as you want
[16:38:36 CEST] <BradleyS> it's really common to have second harmonic hum, so here in north america 120 Hz is bad, sometimes ~240 can also be heard
[16:38:55 CEST] <durandal_1707> harmonics can be all way around - odd or even and at different strength
[16:38:58 CEST] <BradleyS> ideally you would allow to configure how many harmonics and how much to reduce those
[16:39:06 CEST] <BradleyS> cool
[16:39:30 CEST] <BradleyS> probably want to be able to adjust the Q also
[16:39:34 CEST] <BradleyS> (width of filter)
[16:39:34 CEST] <durandal_1707> there is one audio with hum at around 300hz
[16:39:51 CEST] <durandal_1707> no i can not use ugly IIR filtering
[16:41:01 CEST] <BradleyS> here's a visual example of a non-fft method using notch filtering https://imgur.com/a/2mBKeDW
[16:41:14 CEST] <durandal_1707> notch filtering is very limited
[16:41:33 CEST] <BradleyS> anyway, those settings give a lot of control even if you're doing fft, which should sound better
[16:42:31 CEST] <BradleyS> so i guess 4th harmonic for 60 Hz is 300 Hz, that's probably a decent limit
[16:44:58 CEST] <BradleyS> i guess one point i probably have not been clear enough on, is that once you identify the fundamental frequency of the hum, you can automatically filter the harmonics also without further analysis
[16:45:02 CEST] <durandal_1707> 300 is only one present in audio
[16:45:08 CEST] <BradleyS> which, given their signal will be lower, would be less accurate
[16:46:35 CEST] <taliho>  /whois mkver
[16:47:35 CEST] <BradleyS> also, durandal_1707... you should upsample the audio to a sample rate with integer relationship
[16:48:21 CEST] <BradleyS> e.g. 48 kHz to 2304 kHz or whatever
[16:49:07 CEST] <durandal_1707> why?
[16:49:11 CEST] <BradleyS> less distortion
[16:50:06 CEST] <BradleyS> most daw use specialized post processing when downsampling also
[16:51:25 CEST] <BradleyS> (realistically, 16x oversampling might be enough)
[18:18:25 CEST] <Lynne> durandal_1707: btw you might make this work with FFT, but you'll need big framesizes (like 100ms or so) to get enough resolution on the bins to do certain frequencies
[18:21:08 CEST] <Lynne> probably even more, but a filter's the right thing to use here
[18:45:51 CEST] <durandal_1707> Lynne: you forgot that i resample audio to 2048 and that I need adaptive filter, fixed filter is of no use
[18:48:00 CEST] <dastan> does someone here know about VLC? i know they have their own channel but it look nobody answer there
[18:49:26 CEST] <dastan> is michaelni alive?
[18:49:48 CEST] <durandal_1707> please do not spam this channel with off-topic stuff, thanks
[18:50:16 CEST] <durandal_1707> also bunch of devs are already on #vlc
[18:50:59 CEST] <dastan> ok, so can we speak about HLS connections?
[18:51:08 CEST] <dastan> i have some buffer problems
[18:51:23 CEST] <dastan> and i dont know how to solve it
[18:52:02 CEST] <dastan> i am sking about FFmpeg
[18:52:05 CEST] <dastan> did i make spam again?
[18:52:54 CEST] <durandal_1707> best place to ask is via ffmpeg-user mailing list
[20:52:56 CEST] <durandal_1707> oh, now, instead of nonsense, i get echoed output for some reason
[20:53:35 CEST] <cone-179> ffmpeg 03Cameron Cawley 07master:dcf3f8b368cd: avformat/rpl: Fix detection of 8-bit linear formats
[20:53:35 CEST] <cone-179> ffmpeg 03Cameron Cawley 07master:1f8336fd985d: avformat/rpl: Allow a file to have audio, but not video
[20:53:35 CEST] <cone-179> ffmpeg 03Cameron Cawley 07master:0cbdedbd2fc2: avformat/rpl: Calculate the duration of the video track
[21:32:12 CEST] <cone-179> ffmpeg 03James Almer 07master:7c644989a5c2: avcodec/hevc_ps: fix range of num_tile_{columns,rows}_minus1
[22:21:26 CEST] <durandal_1707> should I use synthesis window also as analysis window?
[23:32:20 CEST] <Lynne> par?
[23:32:38 CEST] <durandal_1707> par par
[23:43:09 CEST] <Lynne> after some ridiculous amount of digging: "The par file demuxer is just some glue around a non-free library that I don't (yet) have permission to distribute."
[23:43:17 CEST] <Lynne> >ffmpeg-devel ML 2011
[23:44:34 CEST] <Lynne> guess it took them this long to finish it and they still don't distribute the library anyway
[23:45:40 CEST] <durandal_1707> what non-free library does?
[23:48:00 CEST] <nevcairiel> wtf does it modify 20 files for
[23:48:01 CEST] <Lynne> it's libparreader, and with the way its API looks it writes and reads super-secret bytes to make a valid par format
[23:48:12 CEST] <JEEB> hah
[23:48:30 CEST] <JEEB> just by these comments that seems like a winner :P
[23:48:58 CEST] <nevcairiel> the code  looks horrible too, and its nonfree to boot
[23:49:11 CEST] <durandal_1707> NAK! NAK! NAK! NAK!!!!!!!!!!!
[23:51:59 CEST] <nevcairiel> if a single proprietary format needs 24 files and 7000 lines of code, and then still depends on an external library, wtf was someone that made  it smoking
[23:53:12 CEST] <Lynne> the comment in admime_probe() is fun to read
[23:53:47 CEST] <JEEB> sounds worse than the current Nokia/DVB-H/"next gen broadcast" thing I'm poking at
[23:53:58 CEST] <JEEB> which also includes a lot of "I wish I smoked the same stuff the authors did"
[23:54:45 CEST] <Lynne> this is for some obscure cctv systems from what I read, so no doubt
[23:55:09 CEST] <JEEB> (and actual broadcast input reader module vendors seem to be nope'ing at this format and asking people to internally convert into MPEG-TS according to people who I've discussed with)
[23:55:18 CEST] <nevcairiel> why do such companies believe that a very broken proprietary format is the way to go
[23:55:30 CEST] <JEEB> very good question
[00:00:00 CEST] --- Sat Jul  6 2019