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

[burek]

[00:08:36 CET] <JEEB> was this sort of indent OK? http://up-cat.net/p/963d6176
[00:09:30 CET] <Chloe> JEEB: I'd say it's fine
[00:15:52 CET] <cone-158> ffmpeg 03Jan Ekström 07master:5b31dd1c6b1e: avformat/hlsenc: use stream's maximum bit rate as fall-back advertised rate
[03:46:07 CEST] <atomnuker> is there any way to get a usable answer from pixdesc about how many bits each sample has?
[03:46:17 CEST] <atomnuker> which works for RGB, YUV, etc.?
[03:47:27 CEST] <atomnuker> padded or not, I don't care, though I'd prefer padded
[03:48:57 CEST] <atomnuker> comp[].step and av_get_bits_per_pixel()/av_get_padded_bits_per_pixel() are useless since for planes with more than 1 component they show the distance in between samples of the same component
[03:52:33 CEST] <kierank> atomnuker: there's a function for bits_per_sample
[03:52:35 CEST] <kierank> or a struct element
[03:54:36 CEST] <atomnuker> av_get_exact_bits_per_sample? its for audio and its in lavc
[04:04:48 CEST] <kierank> for video as well iirc
[04:04:55 CEST] <kierank> because I remember arguing with jdarnley about sample vs pixel
[04:06:29 CEST] <atomnuker> which one is it?
[04:17:08 CEST] <kierank> atomnuker: get_pix_fmt_depth
[04:17:10 CEST] <kierank> i think
[04:30:04 CEST] <atomnuker> fuck yeah, finally
[04:30:11 CEST] <atomnuker> a fully working avgblur_vulkan
[04:30:30 CEST] <atomnuker> nv12, p010, yuv4XXpXX, you name it
[04:30:38 CEST] <atomnuker> rgb as well too ofc
[04:32:32 CEST] <atomnuker> its around 10 times faster than opencl's filter for upload+download, though I did use a cleverer algorithm with a barrier so texel fetches don't blow up with blur area
[05:50:30 CEST] <rcombs> does MPEG-2 VideoToolbox hwdec ever work
[05:50:41 CEST] <rcombs> I'm getting kVTCouldNotFindVideoDecoderErr
[08:30:44 CEST] <tmm1> rcombs: maybe on macos if you use -allow_sw 1
[08:31:06 CEST] <tmm1> but even then you're better off with ffmpeg's sw dec
[08:31:14 CEST] <rcombs> you'd think, right?
[08:32:52 CEST] <rcombs> as long as it's not just me, w/e
[09:16:31 CEST] <gagandeep> kierank: I am unable to fix the interlaced bug for now, and I need to submit the proposal
[09:17:56 CEST] <gagandeep> kierank: I have been reading the Cineform code , but for writing the proposal, I will need to implement new features
[09:18:50 CEST] <gagandeep> I believe I can start with features (like Bayer listed on bounty) and temporal
[09:20:38 CEST] <gagandeep> Also, I am thinking about speeding up the decoder , but for that threading is the way, and I don't know anything about intrinsics and stuff
[09:23:17 CEST] <gagandeep> So how much plausible do you think would the goal for threading would be for me?
[09:23:17 CEST] <gagandeep>  I am willing to learn threading, but that will also cut the coding time
[10:40:30 CEST] <kierank> gagandeep: I would say leave Bayer to the end
[10:40:53 CEST] <kierank> Do interlace fix, temporal transform and assembly
[10:41:59 CEST] <kierank> Threading is pretty simple, ffmpeg will do most of the work
[14:16:57 CEST] <gagandeep> kierank: I am thinking of coding the threading used in Cineform for proposal, so do you think this could be something deliverable if I have to learn parallel processing and intrinsics (or whatever method is used for the same in C)
[14:20:11 CEST] <gagandeep> Furthermore, since I haven't used Cineform professionally, I don't really know a lot of good and practice features that should be added to FFmpeg, so I would like if you can at least provide me a list
[14:27:34 CEST] <kierank> gagandeep_: er, for gsoc you have to do all the tasks
[14:27:46 CEST] <kierank> (except maybe Bayer, that's hard)
[14:28:01 CEST] <kierank> So interlaced, temporal transform and threading at least
[14:28:11 CEST] <kierank> And thats quite an easy gsoc to be honest
[14:28:29 CEST] <kierank> I hope durandal_1707 and atomnuker would agree
[14:28:59 CEST] <kierank> You wouldn't do intrinsics you would do external asm in FFmpeg
[14:29:26 CEST] <gagandeep_> so can i still submit the proposal first and continue to debug the interlaced
[14:29:40 CEST] <atomnuker> there's no need to use the threading from cineform too, we have 2 threading models flexible enough
[14:30:30 CEST] <gagandeep_> kierank: will i still not be qualified to even work on cineform, if i can't figure out the interlaced?
[14:30:51 CEST] <gagandeep_> i will be sending the patch for chroma, i have been busy with interlaced and some collage work
[14:31:04 CEST] <kierank> atomnuker: yeah I mean he's got to implement threading
[14:31:27 CEST] <kierank> For p-frames this is nontrivial
[14:31:28 CEST] <gagandeep_> guys, i am right now worried about my work regarding qualification tasks
[14:32:14 CEST] <kierank> gagandeep_: They are not checkboxes for qualification, it's still at our discretion.
[14:32:28 CEST] <kierank> Qualification is really about showing you are capable of finishing the project
[14:33:43 CEST] <gagandeep_> ok, interlaced, temporal, threading for now i should put in proposal
[14:35:07 CEST] <kierank> And assembly
[14:35:30 CEST] <kierank> Frankly this is an easy gsoc since you have an open source implementation already
[14:35:42 CEST] <gagandeep_> yeah, i also believe so
[14:37:28 CEST] <gagandeep_> irony on me, interlaced is still not fixed :(
[16:07:19 CEST] <Chloe> gagandeep__: note that if you choose to do a different project (or not do this at all), then it will just get done by someone else as it has a bounty on it (from VLC)
[16:21:00 CEST] <gagandeep__> Chloe: yeah
[17:24:02 CEST] <gagandeep> kierank: how much time should i allocate to learn assembly and the threading structure that i will need
[17:24:41 CEST] <gagandeep> the time from 1st May to 13th May is totally free
[17:26:51 CEST] <kierank> ?
[17:26:53 CEST] <kierank> Is that it
[17:27:47 CEST] <kierank> I think p-frames are 2-3 weeks easily, assembly one week but cineform assembly is very simple
[17:28:18 CEST] <gagandeep> i mean before coding starts, one can learn it in that and after that more can be used from the time coding begins
[17:28:47 CEST] <kierank> Ah ok
[17:29:03 CEST] <kierank> To be honest cineform assembly is so simple you should just work on the problem itself
[17:29:53 CEST] <gagandeep> so can i tackle the assembly before phase one evaluations
[17:30:17 CEST] <kierank> You should work on p-frames and interlace first
[17:30:30 CEST] <kierank> P-frames = temporal frame transform
[17:30:37 CEST] <kierank> Aka 3d transform
[17:31:20 CEST] <gagandeep> ok, so i better start with temporal transforms
[17:33:02 CEST] <gagandeep> hmm, like you said it will take time to look how the p frame is working, cause i still haven't seen into it
[17:35:07 CEST] <gagandeep> kierank: so how about p frames till phase one evaluation
[17:36:12 CEST] <kierank> Interlace and p-frames yes
[17:37:29 CEST] <gagandeep> so threading model of ffmpeg will be done along wiht p-frame
[17:51:21 CEST] <gagandeep> kierank: i will also need to look at interlacing for p-frames, because right now i have only looked at intra frames
[17:52:41 CEST] <kierank> Don't know if those exist in the wild
[17:55:29 CEST] <gagandeep> haha, ok i also don't know, just from the top of my head
[17:58:29 CEST] <gagandeep> ok, will read about p frames properly by tomorrow :)
[17:58:44 CEST] <gagandeep> but aren't they like the difference in frames
[17:59:09 CEST] <gagandeep> and algorithm is used to reconstruct frame from i frame?
[17:59:29 CEST] <gagandeep> frankly, haven't read about them properly yet.
[18:08:40 CEST] <kierank> gagandeep: cineform p-frames are not p-frames in the true sense
[18:08:48 CEST] <kierank> they just have a transform that uses data from multiple frames
[18:09:09 CEST] <atomnuker> jkqxz: so when mapping drm to vaapi you always search for the vaapi fourcc which maps to the drm format
[18:09:11 CEST] <atomnuker> why?
[18:09:40 CEST] <atomnuker> hwfc->sw_format seems to always match what you find
[18:09:56 CEST] <atomnuker> once you translate it into vaapi fourcc
[18:10:44 CEST] <atomnuker> in fact the properties of the mapped frame are as you'd expect always matching the dst_fc
[18:10:59 CEST] <atomnuker> what fills them in? are they inherited from the source fc?
[18:12:45 CEST] <gagandeep> kierank:alright, will look directly at cineform implementation
[18:13:18 CEST] <atomnuker> if they're the same you can save quite a bit of code by removing the search function and the map
[18:13:22 CEST] <kierank> gagandeep: it's the 3d transform they call it
[18:14:07 CEST] <gagandeep> kierank: ok, so till phase one evaluations interlacing in all the way it exists in the wild and p frames
[18:14:31 CEST] <kierank> how long do you have between start and phase one?
[18:15:09 CEST] <gagandeep> 1st may = start and 10th june is end, 11th june - 15th june evaluations
[18:15:52 CEST] <gagandeep> provided i work 7 hrs a day
[18:16:18 CEST] <gagandeep> i will have to adapt depending on the amount of work is getting done
[18:16:45 CEST] <gagandeep> we can keep assembly for phase 2 (aka 3 weeks after phase 1)
[18:17:43 CEST] <gagandeep> 14th may is though the official 'coding begins'
[18:18:16 CEST] <gagandeep> but i would like to learn their implementation of temporal from 1st may to 13th may
[18:18:36 CEST] <kierank> gagandeep: https://samples.ffmpeg.org/V-codecs/CFHD/
[18:18:45 CEST] <kierank> most samples in there don't play if i recall
[18:19:40 CEST] <gagandeep> was this directory in any of the bugs
[18:20:05 CEST] <gagandeep> tbh, this is the first time i am seeing these samples
[18:21:49 CEST] <kierank> nobody reported them
[18:21:54 CEST] <kierank> somewhere I have a whole hard disk full of samples
[18:22:10 CEST] <gagandeep> lol, upload them
[18:22:12 CEST] <kierank> some of which don't play (which didn't stop libav adding them to their fate!)
[18:22:15 CEST] <kierank> they are 100GB
[18:23:02 CEST] <gagandeep> yeah, the 3rd sample in fate-suite was broken i think
[18:24:10 CEST] <gagandeep> i mean it has problem with it's container and it has a wierd frame image
[18:26:07 CEST] <gagandeep> kierank: ok so i am writing assembly for phase 2 evaluations
[18:26:24 CEST] <kierank> ok and maybe bayer if you finish quickly
[18:26:28 CEST] <kierank> but bayer is hard for many reasons
[18:28:11 CEST] <gagandeep> i mean i am here relying on you for time line cause they will involve me to first look into cineform and then code it into ffmpeg
[18:31:17 CEST] <gagandeep> kierank: i am concerned how long the threading model for ffmpeg will take me to use?
[18:32:15 CEST] <durandal_1707> gagandeep: look at other decoders in ffmpeg which use threading
[18:39:36 CEST] <kierank> durandal_1707: not much point until he has p-frames working
[18:41:41 CEST] <gagandeep> kierank: so how about we keep threading for last 3 weeks, if i am able to get p-frames working early, i will look into it before, and if after all this time is left in last phase start some work with bayer
[19:29:41 CEST] <cone-364> ffmpeg 03wm4 07master:b7d0d912ef9b: avcodec: add a subcharenc mode that disables UTF-8 check
[19:29:42 CEST] <cone-364> ffmpeg 03wm4 07master:b0644c3e1a96: movtextdec: fix handling of UTF-8 subtitles
[19:44:32 CEST] <jkqxz> tmm1:  I sent a new set with the common closed caption stuff suitably abstracted (also some nearby things - anyone care about bar data?).  Encoder bits are still to-do.
[19:46:52 CEST] <nevcairiel> i think the documentation should state somewhere that extraction results in out-of-order data not suitable for direct decoding
[19:47:12 CEST] <nevcairiel> (although i would really like a bsf that could also re-order to be able to decode without running it through a decoder)
[19:47:13 CEST] <jkqxz> Only suitable for decoding, you mean?
[19:47:38 CEST] <jkqxz> Oh, decoding the CC data, not decoding the stream.
[19:50:04 CEST] <jkqxz> Yeah, writing that BSF for H.264 is vaguely planned to do at some point.
[19:55:18 CEST] <nevcairiel> some people have been pestering me for CC support during playback, but getting that out of the decoder is so awkward in my structure
[21:59:08 CEST] <tmm1> jkqxz: awesome, thanks for that. the new patchset looks great
[23:28:34 CEST] <cone-233> ffmpeg 03Paul B Mahol 07master:261171d084bc: doc/filter.texi: fix some spotted typos
[23:28:34 CEST] <cone-233> ffmpeg 03Paul B Mahol 07master:78f8036c9c1f: avfilter/af_mcompand: make error message more helpful
[00:00:00 CEST] --- Mon Mar 26 2018