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

[burek]

[04:46:59 CET] <shivamgoyal> Hi, I am Shivam Goyal. I would like to work on the 'HEIF Support' as my GSoC 2019 project. I have an experience of C language. But a little experience on multimedia (although I know how to read and write a Bitmap Image using C and has opened an wav audio file in C ). I need some guide on this and want to know if the position is still available or the mentor has paired with someone else.
[11:48:02 CET] <j-b> Hello !
[13:03:36 CET] <thardin> https://www.phoronix.com/scan.php?page=news_item&px=AV1-Image-Format-v1.0   AVIF finalized
[13:06:07 CET] <nevcairiel> is it equally stupid as HEIF
[13:07:58 CET] <thardin> seems it's actually still a draft
[13:08:46 CET] <thardin> I still think JPEG works surprisingly well, especially if we actually went ahead and implemented all its features
[13:09:41 CET] <thardin> do any intra formats do what old game codecs do, copying already decoded pixels into the current block?
[13:10:00 CET] <nevcairiel> you mean intra-prediction?
[13:10:25 CET] <thardin> doesn't that just use surrounding pixels?
[13:10:43 CET] <nevcairiel> which other pixel would you use?
[13:11:07 CET] <thardin> no I mean the intra prediction modes I've seen only uses the immediately neighbouring pixels
[13:11:52 CET] <thardin> rather than using an MV (and maybe scaling+biasing)
[13:12:23 CET] <nevcairiel> i suppose so, since thats the most likely to be useful
[13:12:30 CET] <thardin> scaling+biasing pixel values that is
[13:13:43 CET] <nevcairiel> I would still consider it intra prediction even if you used entire blocks with some coefficients to transform them, but for real-world image data thats probably not overly useful
[13:14:31 CET] <nevcairiel> which is why they dont do it
[13:14:39 CET] <nevcairiel> game codecs with flat uniform blocks, maybe more so
[13:52:09 CET] <kurosu> for screen content (in particular spreadsheet, browsers, anything having text basically), it's very efficient
[13:52:16 CET] <kurosu> it's called intra block copy in eg av1
[14:47:22 CET] <tronifier> Hello everyone
[14:47:36 CET] <tronifier> This is Leforge Tronifier, a GSoC asspirant, it's my first time participating in this event.
[14:50:16 CET] <durandal_1707> have you looked at our wiki?
[14:51:40 CET] <tronifier> Currently I am reading it.
[14:55:49 CET] <durandal_1707> on what part you are interested in working on FFmpeg?
[15:03:37 CET] <tronifier> I am interested to work on the motion search using Vulkan on GPU.
[15:04:41 CET] <atomnuker> that's my area
[15:09:38 CET] <tronifier> So, where should I start working from? Currently, I know how to work with shaders in openCL and Vulkan.
[15:13:01 CET] <durandal_1707> atomnuker have some not committed patches with some framework and filters
[15:14:18 CET] <durandal_1707> if atomnuker is willing to be your mentor...
[15:28:39 CET] <atomnuker> tronifier: its too early, and I don't really want to be a mentor this year
[15:31:56 CET] <durandal_1707> it is never too early for vulkan
[15:52:53 CET] <atomnuker> yeah, no, I can definitely and absolutely tell you that's wrong
[15:55:33 CET] <tronifier> .
[15:55:58 CET] <tronifier> So, should I start by reading the repository on github?
[15:57:27 CET] <JEEB> tronifier: start with cloning the repo from git.videolan.org
[15:57:34 CET] <JEEB> then build it :)
[15:57:37 CET] <JEEB> that way you have the thing
[15:58:06 CET] <tronifier> Okay boss
[15:58:42 CET] <JEEB> requires basic build tools (shell, compiler&linker, pkg-config/pkgconf, nasm for x86(_64))
[15:59:22 CET] <JEEB> after cloning you can do in the source tree `mkdir -p test_build && cd test_build && ../configure && make`
[15:59:28 CET] <JEEB> and see how it goes, as long as you have those dependencies around
[15:59:42 CET] <jdarnley> since you want to do vulkan stuff you will also need whatever libs it requires
[15:59:53 CET] <JEEB> yup, that's probably a good idea :P
[16:00:00 CET] <JEEB> but first get FFmpeg itself built
[16:00:05 CET] <jdarnley> indeed
[16:00:05 CET] <JEEB> then try enabling the vulkan functionality
[16:00:33 CET] <tronifier> ffmpeg Cloned, now just getting it built
[17:08:49 CET] <durandal_1707> got 5.X working too
[18:47:49 CET] <durandal_1707> nevcairiel: so you got only 3 (test) samples?
[18:49:04 CET] <nevcairiel> thats all the ones i got yeah
[18:49:26 CET] <durandal_1707> still need one with speech coding
[18:50:07 CET] <durandal_1707> otherwise I will just put it on TODO
[19:43:58 CET] <vel0city> Are there any big challenges in fixing this? https://trac.ffmpeg.org/ticket/3720
[19:44:08 CET] <vel0city> Asking because the format seems sufficiently reversed and it seems fairly low hanging fruit (from an inexperienced person's perspective, I haven't done anything with ffmpeg or related projects).
[19:48:25 CET] <durandal_1707> no challenge, nobody cares here becuse nobody uses such format
[19:53:34 CET] <vel0city> I'd expect one of ffmpeg's objectives is to support as many format's as possible?
[19:53:44 CET] <vel0city> and _someone_ is clearly using it :)
[19:54:51 CET] <vel0city> that Chinese company stil exists and it seems like the files are called .xve now (?) https://github.com/stomakun/xve
[19:56:24 CET] <vel0city> anyway, both of the .xv links in that ticket are dead so...
[19:56:44 CET] <durandal_1707> you can code it yourself, or ask someone to do it..
[19:58:18 CET] <vel0city> durandal_1707: I have no need for this, I'm not even Chinese. I came across it in the qualification challenges list for a GSoC project and was curious.
[19:58:36 CET] <durandal_1707> pick something else :)
[19:58:47 CET] <vel0city> haha fair enough
[19:59:22 CET] <durandal_1707> is this QT for DiCOM format support?
[20:00:39 CET] <vel0city> yeah
[20:01:46 CET] <vel0city> HEIF as well
[20:01:53 CET] <durandal_1707> it is part of template of last year, dunno would it be active for this year
[20:02:11 CET] <durandal_1707> ask by mail on ffmpeg-devel mailing list
[20:05:36 CET] <vel0city> not sure I'm interested yet, I'll ask if so
[20:07:47 CET] <JEEB> not sure how many ideas were come up with so if you have a feeling that there's some worthwhile idea in there that's not around, poke ML or wiki with it
[20:08:02 CET] <JEEB> *out there
[20:09:43 CET] <JEEB> also not sure who this year are doing mentoring - and I bet who would be interested in doing mentoring also depends on the topic
[20:20:04 CET] <durandal_1707> are there any ATMOS in EAC3 out there?
[20:22:20 CET] <j-b> never seen
[20:22:25 CET] <j-b> ATMOS in truehd, sure.
[20:22:33 CET] <nevcairiel> iirc netflix streams that for some titles
[20:26:40 CET] <durandal_1707> no blurays?
[20:27:33 CET] <JEEB> blu-rays usually have truehd for atmos
[20:27:50 CET] <JEEB> E-AC3 is mostly seen with plastic box streaming like netflix which was mentioned
[20:27:55 CET] <JEEB> not sure if amazon does it?
[20:38:09 CET] <tronifier> .
[20:39:45 CET] <JEEB> that's a dot
[20:41:12 CET] <tronifier> sorry, typed by mistake
[20:43:13 CET] <tronifier> I just wanted to know, which library should I study and work on?(my topic is motion search using vulkan)
[20:43:40 CET] <JEEB> did you get FFmpeg built? did you get FFmpeg built with vulkan?
[20:44:08 CET] <tronifier> I only get ffmpeg built
[20:44:49 CET] <JEEB> there's some filter stuff for vulkan so install vulkan development headers and library (the loader library most likely) and check the --help output of configure script for vulkan
[20:45:26 CET] <tronifier> okay.
[20:47:44 CET] <durandal_1707> JEEB: are you from alternative reality? atomnuker vulkan stuff is not pushed to master
[20:47:52 CET] <JEEB> oh
[20:47:55 CET] <JEEB> I assumed it was
[20:47:57 CET] <JEEB> christ
[20:48:52 CET] <durandal_1707> atomnuker is busy making nukes instead
[20:48:54 CET] <JEEB> shows how tired I am :P
[20:50:29 CET] <atomnuker> I have to finish the api (since we can't change avvkframes) and hope the pipeline barrier chaining is fixed
[20:51:06 CET] <atomnuker> I have to finish the fft as well, grmbl
[20:51:49 CET] <JEEB> and I still need to finish the LGPLv2.1+ ARIB STD-B24 text conversion module -_-
[20:52:11 CET] <j-b> hahah
[20:52:18 CET] <j-b> text conversion
[20:52:49 CET] <atomnuker> is it backward compatible with ascii like shift-jis?
[20:53:21 CET] <JEEB> I think it is
[20:53:28 CET] <JEEB> since TBS was still TBS
[20:53:49 CET] <JEEB> j-b: all just because upstream glibc iconv didn't take the patch in.
[20:53:59 CET] <j-b> of course
[20:54:05 CET] <JEEB> together with the DVB text coding thing
[20:54:14 CET] <j-b> JEEB: the g in glibc should have given you an hint
[20:54:15 CET] <JEEB> "these are not normal computing text codings"
[20:54:40 CET] <j-b> JEEB: it means "idiots over-engineering and not doing necessary work, but bikeshedding"
[20:54:48 CET] Action: j-b is grumpy tonight
[20:54:56 CET] <JEEB> ah
[20:54:57 CET] <JEEB> yea
[20:55:07 CET] <JEEB> first guy responding to "would this be OK to post here?" was positive
[20:55:11 CET] <JEEB> then the patch was posted
[20:55:19 CET] <JEEB> then "umm this is not 'normal computing'"
[20:55:26 CET] <JEEB> which was the first response of course
[20:55:29 CET] <atomnuker> I blame ascii for the large amount of custom text encodings
[20:55:35 CET] <JEEB> aand then there wsome positive responses
[20:55:44 CET] <JEEB> but at that point the author got derp'd already
[20:55:51 CET] <atomnuker> "other encodings don't support my obscure charset, and I'm too lazy to start unicode, i'mma extend ascii"
[20:56:38 CET] <JEEB> ARIB specs actually let you use unicode as well, but since it got into production in 2003
[20:56:45 CET] <JEEB> thus nobody at that point was using unicode in broadcast
[20:58:25 CET] <j-b> oh boy, WV DSD is a thing?
[20:58:38 CET] <nevcairiel> yes
[20:58:55 CET] <j-b> Why?
[20:58:59 CET] <nevcairiel> who knows
[20:59:13 CET] <nevcairiel> to be fair the existing typical containers for dsd are crap too
[20:59:14 CET] <j-b> Can I cry?
[20:59:59 CET] <durandal_1707> crying here is forbiden and punished
[21:00:19 CET] <j-b> ok
[22:43:12 CET] <rcombs> oh I missed durandal_1707
[22:43:30 CET] <rcombs> but yes atmos in eac3 is a thing and afaik it's a completely separate encoding from atmos in truehd
[22:48:52 CET] <nevcairiel> i would have hoped its the same atmos coding, but figures that its something else entirely =p
[22:49:02 CET] <JEEB> usual dolby
[22:49:04 CET] <nevcairiel> but i have zero knowledge about its internals
[22:49:09 CET] <JEEB> same marketing word
[22:49:12 CET] <JEEB> different meaning
[22:49:41 CET] <nevcairiel> "dolby atmos" is a whole range of technologies anyway
[22:49:45 CET] <nevcairiel> same as dolby vision
[22:49:56 CET] <nevcairiel> its big marketing n ames with dozens of alternative techs behind it
[22:50:00 CET] <JEEB> just like dolby vision is everything from the additional tone mapping messages to the 12bit HDMI stuff to the ICtCp-like proprietary thing
[22:50:04 CET] <JEEB> yup
[00:00:00 CET] --- Fri Mar  1 2019