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

[burek]

[00:25:16 CET] <acetone> Hi, may I have a question about swscale?
[00:27:35 CET] <JEEB> just ask
[00:31:05 CET] <acetone> We use swscale to just convert pixel format, so we do scale 1:1, I am reviewing bug report of "quality loss" and found that swscale tries to scale the image even if src res is the same as dst res
[00:31:41 CET] <acetone> we use SWS_FAST_BILINEAR method.
[00:32:01 CET] <JEEB> yes, I think there can be plenty of conversions that f.ex. go through YCbCr or so. also colorspace conversions like RGB to 4:2:0 will anyways have chroma subsampling
[00:33:20 CET] <acetone> So it's unavoidable then?
[00:33:54 CET] <JEEB> depends on what's your exact conversion etc
[00:35:16 CET] <acetone> in this case it's AV_PIX_FMT_YUV444P10LE to AV_PIX_FMT_RGBA
[00:35:45 CET] <JEEB> ok, so in theory there should be no chroma subsampling unless you somehow end up in a chain that does that
[00:35:52 CET] <JEEB> since input and output are 4:4:4
[00:36:38 CET] <JEEB> although there might have been a required option for swscale to not try to be "fast" with certain conversions and insert chroma subsampling somewhere
[00:36:55 CET] <JEEB> acetone: are you utilizing through lavfi or swscale itself?
[00:38:16 CET] <acetone> Also when I said "tried to scale" I meant, in X on the "left" side of the image, there was almost no difference from reference, but on the "right" side of the image pixels were shifted 1pixel to the right...
[00:39:15 CET] <acetone> JEEB, I think this is swscale directly. it's defined in swscale.h
[00:44:36 CET] <acetone> I can upload a picture, that demonstrate this issue if it helps
[00:50:53 CET] <jdarnley> swscale must have a couple of options that might be related because they are accessible from ffmpeg's command line
[00:51:03 CET] <jdarnley> something like "full chroma intrpolation"
[00:54:32 CET] <jdarnley> https://ffmpeg.org/ffmpeg-scaler.html#sws_005fflags
[00:54:57 CET] <jdarnley> full_chroma_int Enable full chroma interpolation. full_chroma_inp Select full chroma input.
[00:56:19 CET] <JEEB> acetone: if you were on lavfi I would have recommended testing out 4:4:4 to gbrp with zscale, and then gbrp->rgba packetizing with the format filter (which is swscale)
[00:56:28 CET] <JEEB> since that seemed to work for me :P
[00:58:35 CET] <JEEB> uhh, scale filter I meant for the packetizing - format to tell zscale what to output, scale to do the simple conversion
[00:58:45 CET] <JEEB> but yes, with swscale I would test those options
[00:59:01 CET] <JEEB> because swscale can do fun things by default :P
[00:59:10 CET] <acetone> JEEB, I am afraid that I will not be able to change libs that we use. Project I am working on is Blender, but I can reproduce this with VLC also
[00:59:20 CET] <jamrial> there's bitdepth conversion from yuv444p10 to rgba
[00:59:31 CET] <jamrial> so there is data loss no matter what
[00:59:40 CET] <JEEB> yes, that of course will be there
[01:08:13 CET] <acetone> I uploaded the image https://drive.google.com/file/d/15npoPBX776L3YRz6BtLzX2-lczMVHiv4/view?usp=sharing
[01:10:19 CET] <acetone> first 3 pixels is reference. IMO it seems more like a bug then only a subsampling issue - it is clear, that it scales the image to X+1 pixel
[01:11:45 CET] <JEEB> if you can create a simple thing to replicate it, feel free to post an issue on the trac issue tracker
[01:15:17 CET] <acetone> JEEB, Can I refer to our code to replicate issue, or do you need something like console command?
[01:15:40 CET] <JEEB> if you can replicate it with ffmpeg.c as well, that's fine too
[01:15:50 CET] <JEEB> if not, you can minimal API example
[01:16:31 CET] <acetone> OK, worst case you will request better case I guess..
[01:17:08 CET] <JEEB> you can dump an example yuv444p10 frame into y4m or so :P
[01:19:44 CET] <acetone> biggest problem is that I don't know a lot of what you are talking about, that's why I want you to look at it :)
[01:23:26 CET] <JEEB> provide a sample of the input and the way to replicate the issue, post on the issue tracker
[01:23:41 CET] <JEEB> it's 2:23 AM here and I'm definitely not going to be looking into swscale any time soon :P
[01:25:07 CET] <acetone> Sure. Anyway, thanks for help :) bye!
[08:20:43 CET] <JEEB> argh, why is the gmail application so bad. i cannot properly reply to my own mail and do an in-line reply. the darn client just refyses to leave quoting
[08:20:58 CET] <JEEB> will have to reply when I get to a pc
[08:33:17 CET] <JEEB> because while lgplv3 is ok by me, i missed to note that i do not want to use my free time in pulling in a 3rd party lib packaged in distros if the end result isn't even compatible with our base license
[13:02:08 CET] <cone-800> ffmpeg 03PaweB Wegner 07master:835ab35ef023: libavformat/dashdec: disable seeking only for live streams.
[19:34:43 CET] <JEEB> can I get some extra opinions on the libaribb24 thing? because right now it seems like it's just me who wants to put that thing in, and just carl who doesn't
[20:09:14 CET] <durandal_1707> JEEB: ask nicolas
[20:14:11 CET] <iive> JEEB, what is libaribb24?
[20:14:31 CET] <JEEB> the library VLC uses for ARIB caption decoding
[20:14:49 CET] <JEEB> I did babby's first subtitle decoder using it :P (and also implemented demuxing of those captions)
[20:15:01 CET] <JEEB> mostly because the alternative would have been
[20:15:25 CET] <JEEB> a) import an out of tree iconv module that is LGPLv2.1+ and never went upstream because broadcast text is "not common in computing"
[20:15:44 CET] <JEEB> b) start figuring out if an anonymous, never-talked-to-upstream implementation of the captions was any good
[20:15:55 CET] <JEEB> you can see why I decided to make sure I had a reference first :P
[20:16:12 CET] <JEEB> because vlc already uses libaribb24 and it's packaged in debian etc
[20:16:51 CET] <JEEB> iive: the patch itself for the decoder is @ https://patchwork.ffmpeg.org/patch/11965/
[20:16:59 CET] <JEEB> I don't think anyone had any objections to the demuxing patch
[20:17:23 CET] <JEEB> demuxer patch is https://patchwork.ffmpeg.org/patch/11960/
[20:17:24 CET] <JEEB> :V
[20:18:41 CET] <JEEB> also I don't even know how people would react if we had to pull in a full text encoding conversion thing into lavu or something since all of the MPEG-TS metadata in ARIB streams is also coded in that text encoding
[20:19:41 CET] <JEEB> iive: how it looks like rendered: https://megumin.fushizen.eu/screenshots/arib_subs/mpv-shot0004.png
[20:20:00 CET] <JEEB> (the 0/0 patch has a sample linked)
[20:20:48 CET] <iive> why is carl opposing it? I see no reason for objections.
[20:21:00 CET] <iive> unless he wants to merge the library into ffmpeg
[20:21:42 CET] <JEEB> he wanted that but I did most recently tell him that since it's LGPLv3 I would probably not put in all the effort if it ends up being a thing that isn't enabled in the default config :P
[20:21:59 CET] <JEEB> because it means the whole effective parts of that library have to go through FFmpeg code review
[20:22:02 CET] <JEEB> :P
[20:22:15 CET] <JEEB> and at that point I'd rather start working on the LGPLv2.1+ alternatives
[20:22:30 CET] <durandal_1707> there is no FFmpeg code review - really
[20:22:50 CET] <iive> JEEB, this doesn't sound like strong objection, only preference
[20:23:34 CET] <durandal_1707> you need to explicitly ask Carl if that is objection/blocking
[20:23:42 CET] <JEEB> he already said no, thankfully
[20:23:47 CET] <JEEB> he just doesn't like it
[20:23:53 CET] <iive> and even if somebody is working on merging or porting the code, it makes sense to have library support to compare it.
[20:24:23 CET] <iive> so, there is no problem then.
[20:25:40 CET] <JEEB> I'm just mostly looking for opinions so I know how many people's tastes I step onto since at least one person has shown dislike towards it :P
[20:25:49 CET] <JEEB> because right now it looks like 1:1
[20:37:32 CET] <nevcairiel> why do crazy asians not like unicode :(
[20:37:48 CET] <nevcairiel> or rather, utf-something
[20:38:17 CET] <JEEB> I think they actually have UTF-8 in the spec, but I bet in 2003 all the broadcasters went "uuhhhh, this is very much like this ISO Japanese coding so we'll just go with it"
[20:38:26 CET] <JEEB> (except it isn't exactly)
[20:39:05 CET] <JEEB> I think like half of it matches some ISO, and another matches some other coding native to Japan (JIS?)
[20:39:51 CET] <JEEB> back in like 2011-12 or so when I was trying to get a friend to implement this stuff for funzies and giggles, he just took a look at the character mapping at the end of the spec and ragequit on the spot
[20:40:09 CET] <JEEB> fun times
[20:40:27 CET] <nevcairiel> heh
[20:40:36 CET] <JEEB> also I found it extra fun when the guy who implemented the decoding (and encoding!) in an iconv module actually tried to push it upstream
[20:40:50 CET] <nevcairiel> using something like iconv for this stuff is the only realistic option, one really doesnt want to re-implement it
[20:40:54 CET] <JEEB> let me find the thread where he got told that broadcast text codings aren't computing enough
[20:40:57 CET] <nevcairiel> hopefully iconv supports it? :P
[20:40:59 CET] <JEEB> nope
[20:41:03 CET] <JEEB> it's only in linuxtv's modules
[20:41:04 CET] <JEEB> xD
[20:41:20 CET] <JEEB> so to have it available anywhere you have to basically start taking it in
[20:43:27 CET] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00008.html
[20:43:55 CET] <JEEB> and then https://sourceware.org/ml/libc-help/2015-03/msg00016.html
[20:46:42 CET] <JEEB> so now they're just sitting @ https://git.linuxtv.org//v4l-utils.git/tree/contrib/gconv
[20:48:58 CET] <JEEB> but yes, I wish it was available in iconv things :P
[20:49:28 CET] <JEEB> because I bet if you try to put text decoding/encoding into lavu someone will have a "you w0t m8" moment
[20:52:41 CET] <iive> JEEB, have you tried extending the iconv to support it?
[20:53:32 CET] <JEEB> do you mean some other iconv than the one I posted because it got pretty well nope'd there?
[20:53:52 CET] <JEEB> (I thought we only wrap iconv)
[20:56:05 CET] <JEEB> or do you mean that all the iconvs have a standardized API?
[20:56:15 CET] <JEEB> into which you can stick new modules
[20:57:14 CET] <JEEB> I know iconv modules are a thing but I'm not sure it worked with f.ex. windows?
[20:57:27 CET] <durandal_1707> RULE 1: if nobody reviews your patch after 5 days of sending, it get automatically pushed
[21:02:44 CET] <durandal_1707> mailing list activity is not high as it used to be
[21:02:53 CET] <iive> JEEB, following the whole libc thread, i'm a bit confused. some of the developers kind of agreed, then somebody gave up?!
[21:03:26 CET] <JEEB> the end result seems to be that first it was "let's take a look at it"
[21:03:34 CET] <JEEB> and then when it came to it, another person went "nope, not computing enough"
[21:03:45 CET] <JEEB> that patch set had both the DVB text coding and ARIB
[21:04:14 CET] <iive> but the thread continued after that
[21:04:32 CET] <iive> and developers were inclined to ... not reject it.
[21:05:07 CET] <JEEB> looking at https://sourceware.org/ml/libc-help/2015-03/threads.html#00016
[21:05:26 CET] <JEEB> it seems like Florian and Carlos generally started talking about reworking parts of gconv
[21:05:44 CET] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00032.html
[21:05:58 CET] <JEEB> is where the guy settles for the linuxtv.org repo
[21:06:43 CET] <iive> you see the quoted text?
[21:07:39 CET] <iive> it looks like Akihiro TSUKADA declares defeat and tries another approach
[21:08:05 CET] <iive> and the libc guys simply accept it, since it means less work for them.
[21:08:47 CET] <iive> https://sourceware.org/ml/libc-help/2015-03/msg00024.html
[21:08:57 CET] <iive> that sounds like they were OK with including it.
[21:09:04 CET] <JEEB> yes, he then got positive stuff
[21:09:20 CET] <JEEB> unfortunately he also got a NACK
[21:09:26 CET] <JEEB> anyways, long story short it never went in
[21:09:54 CET] <iive> it should have.
[21:10:10 CET] <iive> it could have...
[21:10:20 CET] <durandal_1707> so did work got committed somewhere after all?
[21:10:27 CET] <JEEB> in linuxtv repo
[21:10:31 CET] <JEEB> https://git.linuxtv.org//v4l-utils.git/tree/contrib/gconv
[21:10:37 CET] <durandal_1707> ah
[21:12:46 CET] <iive> what is that and how is it used?
[21:13:17 CET] <JEEB> seems to have a makefile to make modules, but I don't think it works with anything else than linux :P
[21:13:32 CET] <JEEB> the arib one is the ARIB STD-B24 dec/enc
[21:13:38 CET] <JEEB> and the en300 one is DVB
[21:14:05 CET] <iive> oh...
[21:14:24 CET] <JEEB> and when I say dec/enc I mean the *text* encoding
[21:14:26 CET] <iive> so totally useless.
[21:15:38 CET] <JEEB> but yea, I was planning on looking at this stuff and seeing if I could make it into an OK API'd thing in lavu or so
[21:15:46 CET] <JEEB> so that lavf/lavc would be able to use it
[21:16:11 CET] <JEEB> after that the anonymous ARIB STD-B24 lavc decoder that's LGPL2.1+ could be looked into
[21:16:18 CET] <JEEB> since right now it 100% bases on that module
[21:16:37 CET] <JEEB> so you need to be able to replace that text coding conversion part with something else
[21:17:16 CET] <JEEB> libaribb24 just happens to have both of those parts in it (text coding and the actual captions), which is why I picked it as the first thing :P
[21:17:27 CET] <JEEB> it just unfortunately is LGPLv3
[21:24:58 CET] <atomnuker> that would be okay too, we have a flag for that
[21:25:27 CET] <JEEB> yes, but if I have to drag that thing through code review then I'm not going to do it with an LGPLv3 component :P
[21:25:37 CET] <JEEB> for an external lib it's OK
[00:00:00 CET] --- Thu Feb  7 2019