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

[burek]

[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++)