[00:02:10 CET] <atomnuker> you ought to know [00:04:28 CET] <jdarnley_obs> heh maybe [00:15:11 CET] <BtbN> thardin, mjpeg also fulfills that codec requirement. [00:15:43 CET] <BtbN> Though it's not nearly as fast to de and encode [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:61cb505d18b8: lavu/opencl: replace va_ext.h with standard name [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:d0f3798b4e7f: lavfi/colorspace: move some functions to common file [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:2593122a167d: lavfi/opencl: add ff_opencl_print_const_matrix_3x3() [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:8b951cd4752c: lavfi/tonemap_opencl: reuse color matrix calculation from colorspace.c [02:40:44 CET] <cone-659> ffmpeg 03Ruiling Song 07master:b073fb9eeae8: lavfi/colorspace_common: add ifdef check to be more compatible. [03:39:35 CET] <rcombs> JEEB: if it's guaranteed to be UCS-2 (and not UTF-16) then it's literally just "encode UTF-8 from 16-bit code points", which lavu has code for (PUT_UTF8) [03:40:18 CET] <rcombs> JEEB: if it might be UTF-16 (which isn't a bad idea to assume regardless), it's ever-so-slightly complex in that you have to decode surrogate pairs, but lavu also has code for that (GET_UTF16) [08:04:55 CET] <JEEB> rcombs: cool. that might make it workable purely within lavu [09:01:17 CET] <thardin> BtbN: it does? I thought jpeg's transforms weren't bitexact [09:07:58 CET] <atomnuker> they aren't unless you use some different approximation close enough to decoder mjpeg coeffs with some errors but be reversible [09:08:28 CET] <atomnuker> though everyone agrees that the libjpeg integer ones are the de-facto standard [09:09:04 CET] <atomnuker> there's a real standard, some ieee document, but it only tells you how to test transforms and gives you an approximate error to keep below [09:14:43 CET] <thardin> yeah I've seen those [09:15:11 CET] <thardin> h264's transform is fully specified, an intra-only thing based on it without intra prediction would work [11:01:24 CET] <vel0city> durandal_1707: why does the decode function (decode_frame) get called twice when converting a tif to some other format? [11:02:06 CET] <atomnuker> once to probe it to check the resolution and pixel format and once to actually decode it [11:02:13 CET] <atomnuker> if it had a parser it wouldn't need to [11:09:18 CET] <vel0city> atomnuker: I see [11:20:04 CET] <kierank> atomnuker: thardin: https://guru.multimedia.cx/the-mpeg124-and-h26123-idct/ [11:31:51 CET] <thardin> yeah I remember that post [12:31:06 CET] <cone-925> ffmpeg 03Carl Eugen Hoyos 07master:e704070f61e8: lavd/v4l2-common: Add an entry for Z16. [13:34:30 CET] <gnafu> So, who's gonna update https://trac.ffmpeg.org/ticket/7589? [13:34:36 CET] <gnafu> ;-) [14:37:36 CET] <durandal_1707> how is interpolation in MC working? [14:54:46 CET] <atomnuker> mayjick [15:00:31 CET] <kurosu> or something involving a cardinal sin [15:01:48 CET] <durandal_1707> motion compenstation [15:06:22 CET] <BBB> most interpolation filters are either variations of bilinear, or something sinc-like [15:07:03 CET] <BBB> sinc: sin(x)/x where x is distance from center [15:07:09 CET] <BBB> and then some approximation thereof [15:07:20 CET] <durandal_1707> i have certain codec, which apparently does not need edge emulation for MC [15:07:27 CET] <BBB> and then in vp9/av1 they merge the standard sinc with a sharpening or blurring filter [15:07:42 CET] <BBB> some codecs use mirror edging [15:07:53 CET] <durandal_1707> does avcodec allows padding frame data pointers? [15:08:32 CET] <BBB> yes [15:09:19 CET] <durandal_1707> i allocate bigger frame, so i do not need to emulate edges [15:15:28 CET] <kierank> durandal_1707: means you can't render codec into fixed buffer size for hw or something though [15:15:30 CET] <kierank> edge emu is useful [15:40:26 CET] <BBB> edge emu is mostly for decoders though [15:40:40 CET] <BBB> for encoders, I think actually drawing the edge is faster [15:43:18 CET] <BradleyS> anyone interested in / working on EIA-608 CC? [15:44:24 CET] <durandal_1707> (A - 4*B + 19*C - 4*D + E + 1) >> 5 [15:44:42 CET] <durandal_1707> this is MC for Y [15:44:57 CET] <kierank> BradleyS: what doesn't work [15:45:08 CET] <BradleyS> https://github.com/HandBrake/HandBrake/issues/1300 [15:45:27 CET] <BradleyS> multiple reports from multiple users stating latest ffmpeg release doesn't recognize it [15:45:33 CET] <BradleyS> thus handbrake does not recognize it [15:46:29 CET] <durandal_1707> BBB: give above formula, how I can derive horizontal/vertical/both MC? [15:46:32 CET] <kierank> ah it's the track based variant [15:46:57 CET] <BBB> durandal_1707: encoder or decoder? [15:47:03 CET] <durandal_1707> decoder [15:47:19 CET] <xxxmaker> https://pastebin.com/rB5cUs3K [15:47:48 CET] <xxxmaker> both mediainfo/ffprobe doesn't recognize the subtitle track [15:48:16 CET] <nevcairiel> then it d oesnt exist [15:48:38 CET] <xxxmaker> nevcairiel it does, VLC can play it: but only vlc player can play this video with subtitle [15:48:58 CET] <xxxmaker> EIA-608 c608 [15:49:12 CET] <nevcairiel> matroska doesnt have codec tags for that, i dont think [15:49:26 CET] <xxxmaker> nevcairiel same issue with .mp4 [15:49:48 CET] <nevcairiel> its never the same issue with distinct container formats [15:50:06 CET] <nevcairiel> in any case bug reports go to #ffmpeg [15:50:16 CET] <nevcairiel> or better, trac :) [15:50:44 CET] <BradleyS> i sent him here, blame me ;) [15:51:23 CET] <nevcairiel> also the ffmpeg info dump from that handbrake ticket shows it finding the track just fine [15:51:27 CET] <nevcairiel> Stream #0:2(eng): Subtitle: c608 [15:51:56 CET] <BradleyS> xxxmaker: upload a safe for work sample somewhere and open an issue on ffmpeg's trac i guess [15:51:57 CET] <xxxmaker> nevcairiel but mine doesn't [15:52:04 CET] <BradleyS> the handbrake issue was created by others [15:52:26 CET] <nevcairiel> if the CC data is actually inside the video stream, then ffmpeg will never show it as a seperate track [15:52:30 CET] <xxxmaker> https://i.imgur.com/xjFiVDS.jpg [15:52:31 CET] <nevcairiel> its up to the API user to extract i t [15:53:25 CET] <xxxmaker> nevcairiel is that "inside" or "outside" [15:54:01 CET] <xxxmaker> https://i.imgur.com/xjFiVDS.jpg this from vlc player [15:54:10 CET] <vel0city> durandal_1707: pushed a patch for multipage, whenever you get the chance [15:54:39 CET] <nevcairiel> i have no points of reference to interpret its output, so its impossible to say. [15:54:44 CET] <nevcairiel> provide a sample file. [15:55:03 CET] <xxxmaker> what is the command to cut this file to 1 minute [15:55:37 CET] <nevcairiel> cutting will re-write the headers, so quite possibly influence the behavior [15:55:41 CET] <BradleyS> nevcairiel: sorry if i pinged you on github, forgot to remove the @ [15:56:18 CET] <xxxmaker> nevcairiel but it might not; let me try at least [15:56:40 CET] <nevcairiel> I dont actually know how Handbrake uses ffmpeg, if you use the ffmpeg CLI tool itself, it also has a feature to extract the CC data into a stream, but its a bit complicated to use [15:56:52 CET] <nevcairiel> but if you u se avcodec/avformat, you need to make code for that [15:57:14 CET] <BradleyS> it's api-based [15:57:54 CET] <nevcairiel> the main problem there being that the CC data is only available after decoding, not through demuxing [15:58:09 CET] <nevcairiel> someone wanted to make a bitstream filter to extract it without decoding iirc, but that never got anywhere [15:59:21 CET] <xxxmaker> nevcairiel but how do i tell if it's "inside" or "outside" [16:00:08 CET] <BradleyS> i think the fact that in your case it's not identified as a separate track indicates it's inside the video track [16:00:35 CET] <BradleyS> i pinged one of our developers regarding this, so maybe he'll have an idea [16:00:48 CET] <xxxmaker> how does VLC able to show it as separate track? doesn't vlc use ffmpeg? [16:00:49 CET] <BradleyS> but it sounds like we have to decode some or all of the video track to identify its presence [16:01:17 CET] <vel0city> durandal_1707: I made some multipage tiffs for testing, do ask if you want them [16:02:03 CET] <nevcairiel> CC data is super annoying, because it breaks the typical data flow we use for everything else [16:02:36 CET] <nevcairiel> lazy muricans couldnt develop a proper subtitle format [16:03:34 CET] <BradleyS> we get fat, too [16:04:04 CET] <durandal_1707> vel0city: why you added uint16 type to opt? that is completely useless [16:04:21 CET] <nevcairiel> I wouldnt be surprised if CC was still in ATSC 3.0. Everything else they change (and m ake terrible in the process), but I already see it, CC remains =p [16:04:36 CET] <kierank> it's in the law, there's nothing they can do [16:04:45 CET] <kierank> literally a copy of the spec [16:04:49 CET] <durandal_1707> vel0city: please use just int [16:04:50 CET] <vel0city> durandal_1707: I noticed the min/max limits later. Figured I'd leave it in since I had already done it... [16:04:58 CET] <nevcairiel> the law is so technical that it says you have to provide subtitles in this particularly crappy format? [16:04:59 CET] <vel0city> And no need to be hostile [16:05:02 CET] <xxxmaker> nevcairiel : this is very minor issue that i know how to get around it: but ffmpeg doesn't support S_TEXT/WEBVTT [16:05:17 CET] <durandal_1707> vel0city: please no code bloating [16:07:25 CET] <atomnuker> just saw the twitch ad insertion talk at demuxed [16:07:55 CET] <atomnuker> so if they delay each segment to fill the hole the ad might have left what happens with each next ad? [16:08:02 CET] <funman> nevcairiel: don't think so but it has to work on existing TVs [16:08:21 CET] <nevcairiel> funman: as if atsc 3.0 will w ork on those without extra hardware [16:08:35 CET] <nevcairiel> those boxes could overlay subs or whatever [16:08:37 CET] <kierank> nevcairiel: the signals will need to be transcoded back to atsc20 for years [16:08:41 CET] <kierank> for hotels and hospitals etc [16:08:50 CET] <kierank> so need to have cc [16:09:00 CET] <atomnuker> (also they're very clever, ads have pts/dts of 0 but since twitch's timestamps are bad no client can use the pts to detect an ad) [16:09:02 CET] <BtbN> "if (intnum == 1 && d == (float)UINT16_MAX) {" what [16:09:21 CET] <BtbN> why would ffmpeg need a AV_OPT_TYPE_UINT16 in the first place [16:09:40 CET] <funman> https://www.ecfr.gov/cgi-bin/text-idx?SID=72eb5a624e8dc043293819a5663dff41&node=47:4.0.1.1.6.1.1.1&rgn=div8=47 [16:10:15 CET] <nevcairiel> so basically, CC will never go away [16:10:20 CET] <nevcairiel> never ever [16:10:51 CET] <JEEB> I was surprised that even advertisements had captions in the US [16:11:22 CET] <nevcairiel> those are the most important to have captioned [16:11:26 CET] <xxxmaker> nevcairiel okay i created a 1 minute sample and it worked [16:11:26 CET] <nevcairiel> need to sell the things [16:11:48 CET] <xxxmaker> do you accept dcc? [16:11:53 CET] <nevcairiel> no. [16:11:59 CET] <xxxmaker> then where can i upload [16:12:13 CET] <nevcairiel> host it somewhere publicly so more then one person can look at it [16:12:24 CET] <xxxmaker> where can i do that? [16:17:51 CET] <xxxmaker> http://www.filedropper.com/video-with-subtitle-and-cc-problem [16:20:49 CET] <xxxmaker> nevcairiel are you able to download? [16:26:46 CET] <nevcairiel> the video stream definitely contains CC data [16:29:59 CET] <xxxmaker> nevcairiel and how do/did you determine that? [16:35:24 CET] <nevcairiel> i looked at ffprobe, which has fancy info like side_data_type=ATSC A53 Part 4 Closed Captions [16:36:14 CET] <xxxmaker> i see [16:36:31 CET] <xxxmaker> how does vlc make this work if vlc uses ffmpeg [16:37:05 CET] <nevcairiel> ffmpeg has all the tools for that, this is entirely up to handbrake to support it [16:37:52 CET] <xxxmaker> BradleyS said ffmpeg doesn't support this [16:38:03 CET] <nevcairiel> he was wrong :) [16:38:22 CET] <nevcairiel> its just complicated because CC is an annoying format [16:38:33 CET] <xxxmaker> how how do i play this file with ffplay and make the subtitle appear [16:38:42 CET] <nevcairiel> no clue [16:38:46 CET] <nevcairiel> ffplay is a bit dumb itself [16:38:59 CET] <xxxmaker> lol, then you can't say ffmpeg support this [16:39:08 CET] <nevcairiel> of course i can [16:39:14 CET] <nevcairiel> handbrake doesnt want to play the video, does it [16:39:58 CET] <xxxmaker> video is fine: just subtitle part is not working [16:43:26 CET] <JEEB> I'm pretty sure I've recently explained to just you why ffmpeg.c et al don't handle this right, but the FFmpeg libraries do [16:43:34 CET] <JEEB> as a proof you can see how mpv does it with FFmpeg :P [16:44:00 CET] <nevcairiel> it also doesnt help that lavfi doesnt really do subtitles [16:44:07 CET] <nevcairiel> so i cant exactly make a graph for ffplay to overlay them [16:46:30 CET] <nevcairiel> didnt ubitux want to get back on lavfi subtitles sometime ago [16:47:28 CET] <xxxmaker> jeeb no idea what you just said: are you talking about the cc/subtitle issue? [16:47:39 CET] <JEEB> yes [16:47:46 CET] <xxxmaker> i see [16:47:46 CET] <BradleyS> i've been wrong before [16:47:51 CET] <nevcairiel> in any case, the ffmpeg libraries have all the tools required to handle CC data [16:47:57 CET] <nevcairiel> its sitll annoying and maybe we could do more [16:48:02 CET] <nevcairiel> but anyone that wants to support it can [16:48:10 CET] <xxxmaker> nevcairiel but if ffplay cannot play then you can't prove that it does [16:48:21 CET] <nevcairiel> i dont have to prove anything, to you or anyone [16:48:40 CET] <BradleyS> xxxmaker: i think you've got your answer, ball's back in handbrake's court [16:48:55 CET] <BradleyS> i've pinged one of our other developers regarding it and we'll look into it further [16:49:01 CET] <BradleyS> thanks for the clarifications nevcairiel! [16:58:25 CET] <JEEB> you just don't get an extra AVStream because it's not a stream, and the first x minutes of video might not have any captions anyways [16:58:59 CET] <JEEB> you need to keep an eye on side data. mpv checks after decoding if the avframe has the side data [16:59:06 CET] <JEEB> if I recall correctly [17:49:26 CET] <durandal_1707> BBB: no ideas? [18:14:53 CET] <BBB> durandal_1707: ? [18:15:14 CET] <BBB> durandal_1707: I don't udnerstand, you have the formula, what is the question? [18:15:24 CET] <BBB> you want me to write out what? [18:15:39 CET] <BBB> it's a simple 5-tap filter [18:16:26 CET] <BBB> for (y=0;y<h;y++){for(x=0;x<w;x++){dst[x] = FILTER(src, y*stride+x);}} [18:17:24 CET] <BBB> with #define FILTER(src, pos) ((src[pos-2]-4*src[pos-1]+19*src[pos]-4*src[pos+1]+src[pos+2]+1) >> 5) [18:17:28 CET] <BBB> that's the horizontal filter [18:17:35 CET] <durandal_1707> now i need to do same for V and V & H [18:17:47 CET] <BBB> then same for vertical, but instead of -2, -1, +1, +2 you use -2*stride [18:17:53 CET] <BBB> so it's two loops [18:18:05 CET] <BBB> one into a temp buffer of size w*(h+4) [18:18:09 CET] <BBB> from y-2 to h+2 [18:18:17 CET] <BBB> and then use that temp buffer as input for the vertical (second) pass [18:18:29 CET] <BBB> fairly simple [18:18:45 CET] <BBB> 19-4-4=11+1+1-13 btw [18:18:48 CET] <BBB> 13 is not 32 [18:18:55 CET] <BBB> so your formula might have a bug [18:19:09 CET] <BBB> either >>5 is wrong, or 1/-4/19 is wrong [18:19:20 CET] <BBB> I Think it may be a 6tap filter [18:19:24 CET] <BBB> 19-4=15+1=16 [18:19:26 CET] <BBB> 2*16=32 [18:19:41 CET] <BBB> so the halfpel position is probably this, and then +1,-4,+19,+19,-4,+1 [18:19:45 CET] <BBB> that makes 32 [18:20:00 CET] <durandal_1707> yes, correct formula is something else.... [18:20:32 CET] <BBB> ok, so does it make sense now? [18:20:45 CET] <durandal_1707> yes [19:15:05 CET] <durandal_1707> vel0city: upload one multipage tiff if you can somewhere [19:52:34 CET] <atomnuker> also I think the correct way to handle multipage is to expose them all as streams via lavf [19:53:43 CET] <durandal_1707> atomnuker: tiff is not simple container [19:57:52 CET] <atomnuker> its fine, if the header isn't duplicated lavf can just splice the 2 together [20:07:13 CET] <cone-071> ffmpeg 03Martin Storsjö 07master:0676de935b1e: arm: Implement a NEON version of 422 h264_h_loop_filter_chroma [20:07:13 CET] <cone-071> ffmpeg 03James Almer 07master:47e12966b754: Merge commit '0676de935b1e81bc5b5698fef3e7d48ff2ea77ff' [20:25:03 CET] <atomnuker> who decodes h264 without a hardware decoder on arm? [20:25:36 CET] <atomnuker> in fact who decodes anything that isn't a picture on any arm ISA without a hardware decoder [20:25:51 CET] <JEEB> I do it for various stuff :) [20:26:30 CET] <kierank> atomnuker: I do for 4:2:2 [20:27:06 CET] <atomnuker> surely not cabac 1080i30 at 20mpbs, it doesn't have enough power [20:27:13 CET] <kierank> mine does [20:27:56 CET] <kierank> rk3399 [20:28:56 CET] <jamrial> atomnuker: h264 caught your attention, but all the vp9, hevc and av1 arm simd didn't? [20:30:53 CET] <atomnuker> well, yeah, I don't know an arm chip that doesn't have a (terrible mostly) h264 decoder [20:34:08 CET] <atomnuker> they're mostly all mobile too, so low power is a must for them [20:34:52 CET] <JEEB> my 2014 oneplus one could almost do 720p24 10bit H.264 perfectly [20:35:12 CET] <JEEB> (it had some drops together with rendering & subs and all) [20:46:05 CET] <Gramner> ass subs can sometimes take more cpu power to render than than decoding a 10-bit 1080p video though [20:46:18 CET] <JEEB> yup [20:46:26 CET] <Gramner> doesn't seem very optimized [20:46:32 CET] <BtbN> ass is just complex [20:46:47 CET] <BtbN> and drawing text is as well [20:47:35 CET] <philipl> Need to GPU accelerate it like DirectWrite :-) [20:48:16 CET] <atomnuker> which reminds me mozilla have a vulkan powered font rasterier now [20:49:21 CET] <philipl> written in rust? :-P [20:53:51 CET] <atomnuker> well, yeah [20:54:21 CET] <durandal_1707> BBB: do I need mirroring when doing temp in V&H MC? [20:54:59 CET] <BBB> it depends on the exact nature of the MC algorithm in the codec [20:55:07 CET] <BBB> are you sure they do mirroring? [20:55:20 CET] <BBB> or do they just clamp the index? [20:55:24 CET] <BBB> (that's emu_edge) [20:56:47 CET] <durandal_1707> I just get black last row of MB with VH MC [21:45:31 CET] <TD-Linux> I looked a while back and libass wouldn't be too hard to plug into pathfinder [21:45:45 CET] <JEEB> funky [21:46:00 CET] <TD-Linux> it has a bunch of "create circle" "create arc" commands that you would just map to building a pathfinder display list [22:37:37 CET] <durandal_1707> BBB: how this HV MC is done? I get last black row, filter is: #define LHFILTER(src) ((((src)[0]+(src)[1])*19 >> 1)-((src)[-1]+(src)[2 ])*2+(((src)[-2 ]+(src)[3 ])>>1)+8>>4) [22:40:30 CET] <BBB> if it's at the bottom of the frame, that's what emu_edge is for [22:40:36 CET] <BBB> you need to implement some form of emu_edge [22:40:40 CET] <BBB> or is this on each block? [22:40:43 CET] <BBB> then your temp bfuferis not filled [22:41:50 CET] <durandal_1707> what size of temp buffer needs to be? 16x21 ? [22:41:59 CET] <durandal_1707> do i need only one temp buffer? [22:44:45 CET] <atomnuker> what codec is this for? [22:45:12 CET] <durandal_1707> atomnuker: bink [22:54:04 CET] <BBB> 16x21 yes [22:54:11 CET] <BBB> a temp buffer on stack should be enough [22:57:15 CET] <durandal_1707> BBB: how second pass should look like? [23:02:17 CET] <BBB> show me code [23:02:28 CET] <BBB> what do you have, I'll show you what's wrong [23:02:39 CET] <BBB> and show me what artifact you get [23:02:46 CET] <BBB> is it per-block or per-image bottom row? [23:03:57 CET] <durandal_1707> https://pastebin.com/S17U3706 [23:04:02 CET] <durandal_1707> it is in middle [23:04:14 CET] <durandal_1707> it does not need emu edge [23:04:59 CET] <durandal_1707> and artifacts are small, black row in last row of 16x16 macro block [23:05:12 CET] <durandal_1707> this is for Y, for now... [23:08:21 CET] <BBB> you need >> 5, not 4? [23:08:33 CET] <BBB> 19+19-4-4+1+1 = 32 [23:08:44 CET] <BBB> oh >> 1 insid [23:08:45 CET] <BBB> weird [23:08:48 CET] <durandal_1707> no, filter is working fine [23:09:21 CET] <BBB> your h loop has wrong dimensions [23:09:25 CET] <durandal_1707> BBB: https://0x0.st/z8Fb.png [23:09:30 CET] <BBB> when you do the horizontal filter, you need to do it vertically 21 times [23:09:39 CET] <BBB> and horizontally 16 times, which consumes (horizontally) up to 21 pixels [23:09:53 CET] <BBB> then you have 21 input pixels horizontally per line giving horizontally 16 output pixels [23:09:55 CET] <BBB> 21 lines [23:09:58 CET] <durandal_1707> ignore bottom black blocks -- those are wrong DC because of some other bug [23:10:02 CET] <BBB> do that vertically to reduce vertical 21 -> 16 [23:10:05 CET] <BBB> output is 16x16 [23:10:14 CET] <BBB> for (int j = 0; j < 16; j++) { [23:10:14 CET] <BBB> for (int i = 0; i < 21; i++) [23:10:15 CET] <BBB> make that [23:10:20 CET] <BBB> for (int j = 0; j < 21; j++) { [23:10:20 CET] <BBB> for (int i = 0; i < 16; i++)