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

[burek]

[02:34:47 CEST] <Chloe> tmm1: JEEB says you did a teletext thing
[02:42:22 CEST] <Mina> Hi, I've been accepted into GSoC to work on a project idea I've proposed which was the color constancy filter. I'm ready to start with my plan but thought to come and ask if there's anything I should know or share before starting.
[02:49:03 CEST] <tmm1> Chloe: yea, for subtitles
[02:49:17 CEST] <tmm1> its not great but mostly works
[02:49:37 CEST] <tmm1> i can submit if interested
[02:52:43 CEST] <klaxa> Mina: hey, yeah i don't think there is much to do right now, lurking the channel and reading what other people have to say is a good and interesting passtime at least
[02:54:53 CEST] <tmm1> Chloe: https://github.com/tmm1/ffmpeg/commit/telx-subs
[02:55:19 CEST] <Mina> klaxa: I will be delighted to chat and get to know new people. Nevertheless, the topic I am working on is not a new topic for me so I am ready to start implementing.
[02:55:50 CEST] <klaxa> heh, well gotta hold off on that for now i think
[02:57:27 CEST] <Mina> Guess I'll just implement some basic filters as showcases. Anyway, what project are you working on. I think I saw your name on GSoC.
[02:58:54 CEST] <Mina> Just received the mail, ffserver then?
[02:59:01 CEST] <klaxa> yeah
[02:59:26 CEST] <Mina> Would you like to tell me more about it? 
[02:59:59 CEST] <klaxa> well, i basically wanted to do something like this since 2012, back then i already kinda knew it must be possible
[03:00:06 CEST] <klaxa> to stream matroska with subtitles i mean
[03:00:10 CEST] <klaxa> that was my original goal
[03:00:38 CEST] <klaxa> started to experiment with some python stuff, didn't work out, tried to learn libav*, phew went pretty much over my head
[03:01:08 CEST] <klaxa> in gsoc 2015 i wrote (the much debated) http server in lavf
[03:01:27 CEST] <klaxa> then i started using it for my own project to finally do what i wanted to do since 2012, stream matroska with subs
[03:02:03 CEST] <klaxa> now it's becoming the replacement for ffserver which was recently dropped
[03:03:21 CEST] <klaxa> in gsoc 2015 i tried to replace some of the http usage of the old ffserver with the new api
[03:03:37 CEST] <klaxa> but wow, that was much harder and much more than i thought
[03:04:41 CEST] <Mina> Trying to catch up xD
[03:05:53 CEST] <Mina> First, that sounds really interesting that you've been tackling this for these years.
[03:06:00 CEST] <Mina> But why is it that hard?
[03:06:13 CEST] <Mina> And debated.
[03:07:10 CEST] <klaxa> it's debated because people disagree about whether libavformat should even have an http server
[03:07:31 CEST] <atomnuker> tmm1: doesn't look horrible, would be useful too
[03:07:46 CEST] <atomnuker> because libzvbi has never worked for me
[03:07:51 CEST] <klaxa> when i applied for that in 2015 i didn't know how divided people were on it
[03:08:12 CEST] <atomnuker> (on the few mpegts streams I had and tested it with)
[03:08:45 CEST] <atomnuker> decoding it to ass is hardcore
[03:08:59 CEST] <klaxa> well it took some time to learn how video files and libav* work and i only worked on it whenever i felt like it, became more with time
[03:09:37 CEST] <klaxa> and it is actually not too hard if you look under the hood, just took some time figuring out how to do it properly
[03:10:00 CEST] <klaxa> that makes me even more puzzled as to why there is not a single software that allows you to live stream matroska
[03:10:03 CEST] <klaxa> i have not seen one
[03:10:07 CEST] <klaxa> in all these years
[03:10:11 CEST] <Mina> Okay, so I think you found a better way to do it -which you are going to implement this year-?
[03:11:00 CEST] <klaxa> well i wish to find out in the next few days or so? that's why i wrote to the ML, getting more expert opinions before making uninformed decisions
[03:11:20 CEST] <Mina> Alternatives are?
[03:11:47 CEST] <klaxa> libmicrohttpd was suggested and writing an nginx module
[03:11:50 CEST] <tmm1> atomnuker: i'm only decoding subtitle pages which come in as mostly text
[03:13:18 CEST] <klaxa> a somewhat middle way might really be writing the server code as a library and making writing an nginx module trivial
[03:13:31 CEST] <Mina> Wished I could help but actually I don't have a clear idea.
[03:14:20 CEST] <klaxa> np, neither have i at the time :)
[03:14:36 CEST] <Mina> What's special with matroska?
[03:15:05 CEST] <klaxa> it supports more things than mp4
[03:15:10 CEST] <klaxa> for example styled subtitles
[03:15:15 CEST] <klaxa> or reading partial files
[03:16:52 CEST] <klaxa> you could have a live stream with multiple language subtitles in the same stream!
[03:17:00 CEST] <klaxa> no need to download some other file or something
[03:18:24 CEST] <atomnuker> tmm1: that's okay, most of teletext is text
[03:18:31 CEST] <Mina> Looks cool.
[03:25:23 CEST] <Mina> I guess I will leave now and come back later. Bye
[03:26:46 CEST] <klaxa> that was quick :P
[03:27:25 CEST] <Mina> hah xD I run in C 
[08:15:36 CEST] <dagb> seeing how aptx got merged to ffmpeg.... how about LDAC? git clone https://android.googlesource.com/platform/external/libldac  apache license.
[09:03:24 CEST] <rcombs> what do people use aptx in ffmpeg for anyway
[09:03:49 CEST] <rcombs> like, not saying LDAC necessarily shouldn't be added, just wondering what you'd use it for
[09:09:16 CEST] <dagb> rcombs: I agree it is an odd thing to add to ffmpeg. But stuff like bluez-alsa can link to ffmpeg, in order to de-/encode these formats.
[09:09:40 CEST] <rcombs> ahhhhhh
[09:09:55 CEST] <rcombs> welp patchwelcome then I'd imagine
[09:10:23 CEST] <dagb> having standalone codec libraries would remove the dependency on both pulseaudio and ffmpeg, which would make for a very slim and capable bluetooth audio support in linux.
[09:19:09 CEST] <Chloe> tmm1: what's missing from it?
[09:29:04 CEST] <Chloe> tmm1: it looks ok, better than zvbi at least
[11:50:49 CEST] <ubitux> durandal_1707: for what options? the strength? or the patch sizes?
[11:52:35 CEST] <durandal_1707> both, but mostly strength
[11:58:58 CEST] <ubitux> i don't think it's a problem but i need to check the patch itself
[12:00:57 CEST] <durandal_1707> ubitux: i have sample that give different output with fieldmatch,decimate and vapoursynth one, and its decimate filter that is causing it 
[12:39:30 CEST] <cone-621> ffmpeg 03Paul B Mahol 07master:0b360cae1cb7: make swresample optional for ffmpeg
[13:07:27 CEST] <ubitux> durandal_1707: iirc the decimate picking logic is slightly different due to design differences
[13:07:49 CEST] <ubitux> is it behaving badly?
[13:08:05 CEST] <ubitux> also note the filter probably needs some adjustments since when they were introduced
[13:08:17 CEST] <ubitux> i haven't tracked the changes upstream
[13:08:23 CEST] <durandal_1707> it appears, it drops different frames
[13:08:39 CEST] <ubitux> but are they duplicated frames?
[13:08:43 CEST] <durandal_1707> nope
[13:08:58 CEST] <ubitux> that's unfortunate then, patch welcome
[13:08:58 CEST] <durandal_1707> it is some strange sample i have
[13:09:22 CEST] <durandal_1707> the VDecimate also drops non dupe frames...
[13:15:15 CEST] <ubitux> there is a drop ratio
[13:15:25 CEST] <ubitux> so the filter actually has to drop something
[13:15:30 CEST] <durandal_1707> yes
[13:15:43 CEST] <ubitux> if there is no duplicate it will pick close one
[13:15:52 CEST] <durandal_1707> agree
[13:16:11 CEST] <durandal_1707> maybe sample is invalid..
[14:09:52 CEST] <cone-621> ffmpeg 03Paul B Mahol 07master:a12899ad9b4d: avfiler/vf_mix: fix crash with >8 bit depth
[15:32:43 CEST] <durandal_1707> ubitux: why nlmeans does not work with rgb formats?
[15:34:15 CEST] <ubitux> no particular reason i suppose
[15:36:57 CEST] <durandal_1707> actually it have gbrp already
[16:08:44 CEST] <jamrial> atomnuker: can you answer Thomas' question about mbedTLS so we can get that moving?
[16:10:25 CEST] <jamrial> otherwise i'll tell him to push it since there are seemingly no other objections
[16:28:21 CEST] <durandal_1707> it is comming to libav, just wait for merge
[16:39:07 CEST] <durandal_1707> who is writing av1 decoder for lavc?
[17:05:36 CEST] <atomnuker> durandal_1707: ...me
[17:07:51 CEST] <atomnuker> and BBB if he manages to negociate with j-b once the codec is complete
[17:10:37 CEST] <atomnuker> I really wish I knew when the bitstream freeze will happen
[17:10:59 CEST] <atomnuker> I know that the spec will be finalized 100 days or so after that happens
[17:11:25 CEST] <atomnuker> since it'll take the company doing the spec verification that long to make synthetic bitstreams and a decoder completely from the spec
[17:11:53 CEST] <atomnuker> I was hoping the bitstream would be frozen yesterday but no, ext_tile had to have some changes
[17:12:52 CEST] <atomnuker> which were apparently in conflict with what the experiment was adopted with (no bitstream changes, but now they want to add some signalling)
[17:35:11 CEST] <jamrial> durandal_1707: no, it's proper to apply it the way it was made for ffmpeg by its author
[18:08:32 CEST] <jamrial> durandal_1707: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-disableswresample
[18:23:34 CEST] <tmm1> Chloe: whats wrong with zvbi? (i've never used it)
[18:25:52 CEST] <durandal_1707> jamrial: looks like aresample filter is dependency of bunch of tests
[18:26:15 CEST] <atomnuker> jamrial: replied
[18:34:22 CEST] <cone-621> ffmpeg 03Paul B Mahol 07master:b2570afde362: avformat/yuv4mpegdec: fix seeking backwards
[18:49:06 CEST] <durandal_1707> jamrial: that fate box is strange, it use avresample instead
[18:49:38 CEST] <jamrial> durandal_1707: avresample is always enabled in builds made by tests/fate.sh
[18:51:10 CEST] <jamrial> just to make sure it builds, afaik
[18:51:39 CEST] <jamrial> since ffmpeg uses swr only, avr is not really used at all even if enabled (unless you invoke the relevant audio filter, which no test does)
[18:52:39 CEST] <jamrial> in any case, disabling swr evidently makes ffmpeg cli a lot less useful. same as disabling sws as seen in http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-disableswscale
[18:56:15 CEST] <durandal_1707> jamrial: is this new box or we had this box run disabling swresample, which was enabled later anyway?
[18:56:47 CEST] <jamrial> durandal_1707: it's old, you can see the run history
[18:57:38 CEST] <jamrial> before your patch removing swr dependency to ffmpeg, a build without swr would just run 321 or so non-ffmpeg based tests
[18:59:19 CEST] <durandal_1707> so i need to add 424 aresample checks to those tests :)
[19:04:17 CEST] <durandal_1707> 424 more commits to my stats? :)
[19:05:38 CEST] <atomnuker> or just have 1 fixing tests/fate.sh
[19:33:17 CEST] <jamrial> durandal_1707: adding aresample as a dep to the relevant tests would be a solution, yeah, but probably end up looking way too ugly
[19:34:02 CEST] <durandal_1707> jamrial: i dont get it, lavf-sox is used by that box but if swresample is disabled, how it managed to convert s16 to s32?
[19:35:13 CEST] <durandal_1707> it would not run any tests because ffmpeg would not exist....
[19:35:18 CEST] <jamrial> it didn't. fate-lavf-sox failed with a "'aresample' filter not present, cannot convert audio formats." error
[19:35:49 CEST] <durandal_1707> previously i mean..
[19:36:11 CEST] <jamrial> previously, lavf-sox wasn't run
[19:36:19 CEST] <jamrial> no ffmpeg cli based test did
[19:36:34 CEST] <jamrial> because ffmpeg was disabled
[19:37:06 CEST] <durandal_1707> well, tests should be run if it they do not need aresample
[19:42:42 CEST] <jamrial> if you can find a non ugly way to add aresample as dep for these 424 tests, then that'd be great :p
[19:54:34 CEST] <cone-621> ffmpeg 03Aman Gupta 07master:6a7a84b2d11e: avcodec/mediacodecdec: clarify delay_flush specific code
[19:54:35 CEST] <cone-621> ffmpeg 03Aman Gupta 07master:7a4639b1eba3: avcodec/mediacodecdec: use AV_TIME_BASE_Q
[19:54:36 CEST] <cone-621> ffmpeg 03Aman Gupta 07master:d8e92a89edd8: avcodec/mediacodecdec: refactor pts handling
[19:58:31 CEST] <durandal_1707> jamrial: what means non ugly?
[19:59:11 CEST] <nevcairiel> preferably without changing 424 places
[19:59:23 CEST] <jamrial> adding aresample to most of these would require to do things like changing a lot of DEMDEC macro usage to ALLYES
[19:59:59 CEST] <jamrial> although i see now there's a FILTERDEMDEC macro, so maybe not /that/ ugly
[20:00:07 CEST] <jamrial> but yeah, what nevcairiel said still applies
[20:01:15 CEST] <durandal_1707> i disagree, all 424 places should be changed
[21:00:38 CEST] <atomnuker> well, if they were changed now they'd have to be changed again in less than 2 years once avresample is gone
[21:03:01 CEST] <jamrial> this has nothing to do with avresample
[21:04:00 CEST] <jamrial> swresample disabled -> aresample_filter disabled -> plenty of tests that need resampling fail
[21:04:01 CEST] <jamrial> just that
[21:18:40 CEST] <atomnuker> oh, right, yeah
[21:18:53 CEST] <atomnuker> makes sense all of them to depend on aresample
[21:19:16 CEST] <atomnuker> even if it means changing it in 424 places, IMO the tests shouldn't rely on default behaviour
[21:35:58 CEST] <kierank> durandal_1707: to answer your prores12 bit question, afaik the idct just truncates values to 10-bit
[21:36:08 CEST] <kierank> the spec might explain how to actually signal 12-bit output
[21:49:16 CEST] <kierank> it might reduce precision of coefficients, can't remember prores idct was a bit odd
[21:50:27 CEST] <durandal_1707> kierank: only 16bit alpha is scaled to 10bit
[21:50:33 CEST] <cone-621> ffmpeg 03James Almer 07master:bd90a2ec04d7: avcodec/mpeg4_unpack_bframes: cache input packets directly
[21:50:34 CEST] <cone-621> ffmpeg 03James Almer 07master:0161d91db01a: avcodec/cbs_mpeg2: use memcpy when assembling fragments
[21:50:58 CEST] <kierank> durandal_1707: ?
[21:51:04 CEST] <kierank> there isn't a 12-bit pixel format
[21:53:30 CEST] <kierank> in prores at least no mention
[21:53:55 CEST] <durandal_1707> mention of what?
[21:54:41 CEST] <durandal_1707> also how I can check that extra 2 bits are really correct and not just noise?
[21:54:57 CEST] <kierank> The IDCT follows the conventions
[21:54:57 CEST] <kierank> of IEEE Std 1180-1990, specifically the expectation that the DCT coefficients have the
[21:54:57 CEST] <kierank> range of 12-bit signed integers while the reconstructed values have the range of 9-bit signed
[21:54:57 CEST] <kierank> integers. 
[21:56:15 CEST] <kierank> seems like you don't know
[21:57:30 CEST] <kierank> there's a reference decoder
[21:58:03 CEST] <durandal_1707> on windows? it can export to 16bit formats?
[22:04:12 CEST] <kierank> durandal_1707: so what you should do is make everything 12-bit
[22:04:15 CEST] <kierank> imo
[22:12:25 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:5e5c9f1804bf: avcodec/vc1: re-implement and expand VC-1 overlap smoothing
[22:12:26 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:20de893b3bb4: avcodec/vc1: change to using v->block instead of s->block for P frames
[22:12:27 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:ded52f6e36c5: avcodec/vc1: re-implement and expand VC-1 loop filtering
[22:12:28 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:c5f74b1e232c: avcodec/vc1: store additional bitstream elements during MB decoding
[22:12:29 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:79f8074cc405: avcodec/vc1: store color-difference reference field type
[22:12:30 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:dd1e717f5b79: avcodec/vc1: correct ff_vc1_mbmode_intfrp
[22:12:31 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:b43f1c522572: avcodec/vc1: correct ff_vc1_dqscale
[22:12:32 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:362ce2db4bbc: avcodec/vc1: implement interlaced out-of-bounds reference pixel replication
[22:12:33 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:e60e14ef929f: avcodec/vc1: re-implement vc1_put_signed_blocks_clamped
[22:12:34 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:cc5deeb74a34: avcodec/vc1: add overlap smooting and loop filter for frame/field-interlace
[22:12:35 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:7a70879624a0: avcodec/vc1: remove unused overlap smooting and loop filter
[22:12:36 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:a1dc0bdaf494: avcodec/vc1: correct mspel for field-interlace B frames
[22:12:37 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:797c1536a46e: avcodec/vc1: correct AC inverse quantization scaling
[22:12:38 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:9ae2845b1c0a: avcodec/vc1: correct forgotten v->blocks_off
[22:12:39 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:144ce364cd2d: avcodec/vc1: more corrections for AC inverse quantization scaling
[22:31:50 CEST] <nevcairiel> yay for vc1?
[22:32:00 CEST] <nevcairiel> now if someone would also make it properly fast, i could drop the MS decoder :p
[22:36:30 CEST] <durandal_1707> the bitstream decoding is very connected with pure frame reconstruction, so it will need heavy refactoring
[22:37:08 CEST] <durandal_1707> to support possible? threaded slice decoding
[22:39:08 CEST] <TD-Linux> you only need those to be separate if the final state of bitstream decoding affects future frames / slices (as in vp9)
[23:12:56 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:0bd0401336df: avcodec/elsdec: Fix memleaks
[23:12:57 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:7562567f41aa: avcodec/h2645_parse: Replace RNXYA by RNXY in ff_h2645_extract_rbsp()
[23:12:58 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:de841fbea765: avcodec/h263dec: Check slice_ret in mspeg4 slice loop
[23:12:59 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:1c97035e3b16: avcodec/error_resilience: Fix integer overflow in filter181()
[23:43:24 CEST] <nevcairiel> the gcc status report mails are always rather disconcerning
[23:43:34 CEST] <nevcairiel> oh hi we reached < 100 important regressions, we can totally release now
[23:43:57 CEST] <nevcairiel> 93 important regressions is still a lot of regressions folks!
[23:46:54 CEST] <wm4> just declare it UB by the applications after some standards lawyering
[23:52:30 CEST] <atomnuker> that radio canada rfc4175 guy doesn't seem to test his patches at all
[23:52:47 CEST] <atomnuker> that last version he submitted leaked every frame
[23:53:32 CEST] <atomnuker> and for the version before that he unref'd the just allocated frame and then ref'd the existing top+bottom one
[23:54:20 CEST] <jamrial> atomnuker: non important regressions are many times ICEs or wrong assembly when trying to compile invalid code, just to give you an example
[23:54:55 CEST] <nevcairiel> i think you got confuzzled there
[23:55:14 CEST] <nevcairiel> and i'm not even talking about the "non-important" ones, there is like 200 more of those
[23:55:34 CEST] <jamrial> oh, <100 important
[23:55:38 CEST] <jamrial> yeah, that does sound kinda bad
[23:55:50 CEST] <nevcairiel> its about normal for their status reports tho
[23:56:13 CEST] <nevcairiel> gcc 7.3 had 186 still open
[23:56:28 CEST] <nevcairiel> a number that actually grew from 7.2
[23:56:33 CEST] <nevcairiel> more got reported then fixed
[23:56:56 CEST] <nevcairiel> so who knows how to properly classify that
[23:57:08 CEST] <atomnuker> jamrial: did you mean to ping nevcairiel?
[23:57:19 CEST] <nevcairiel> it just sounds very odd if they call those "important" and then have such high  numbers
[23:57:26 CEST] <jamrial> atomnuker: yeah, sorry
[23:57:27 CEST] <nevcairiel> the "critical" ones they try to keep at zero at least
[23:58:10 CEST] <jamrial> critical ones are "linux kernel and chromium don't compile" :p
[00:00:00 CEST] --- Thu Apr 26 2018