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

[burek]

[00:05:28 CEST] <J_Darnley> Does anyone here have any first hand experience with the Intel Atom C2750 cpu, in particluar with its performance?
[00:16:11 CEST] <rcombs> spoilers: it's bad
[00:17:15 CEST] <rcombs> I say with confidence by the data points (a) it's from 2013 and (b) you said "Atom"
[00:21:39 CEST] <J_Darnley> I thought that too
[00:22:08 CEST] <J_Darnley> but since all my other CPUs are so old I went looking for a comparison
[00:22:16 CEST] <J_Darnley> https://www.cpubenchmark.net/compare.php?cmp[]=772&cmp[]=2185&cmp[]=1049
[00:24:38 CEST] <jkqxz> Expect IPC something like 1/3 that of a modern Intel high-power core.
[00:24:48 CEST] <jkqxz> (From Silvermont.)
[00:26:00 CEST] <jkqxz> Those ones don't have graphics either, which does work reasonably well with quick sync stuff on similar chips.
[00:26:03 CEST] <jkqxz> I think they are only of value if the SoC I/O is useful to you.
[00:28:05 CEST] <J_Darnley> Good point.
[00:30:06 CEST] <jkqxz> That range were basically supplanted by Broadwell-D, anyway - running the larger cores a bit slower ends up better overall when it's not being sold into a market which wants the cheapest possible (i.e. smallest and least complicated) chip that you can make.
[00:32:48 CEST] <cone-259> ffmpeg 03Yogender Gupta 07master:2e8679373ab6: hwupload_cuda : Add 10/16 bit format support
[00:32:49 CEST] <cone-259> ffmpeg 03Yogender Gupta 07master:3407d8118c72: hwcontext_cuda : Support YUV444P16 format
[00:33:42 CEST] <J_Darnley> Hm.  I shouldn't be so cheap and spend more on a motherbard fora ryzen.
[00:34:08 CEST] <J_Darnley> Some of those Atom boards cost a bomb anyway
[01:54:48 CEST] <cone-259> ffmpeg 03Muhammad Faiz 07master:f2d23ec03f28: avfilter/vf_ssim: fix temp size calculation
[11:24:08 CEST] <JEEB> rcombs: had you looked at webvtt in isobmff yet?
[11:24:35 CEST] <rcombs> briefly
[11:24:51 CEST] <JEEB> it seems to be a bit less insane than ttml in isobmff
[11:24:58 CEST] <rcombs> basically enough to decide that it's way more trouble than it's worth, and potentially altogether impractical to implement in a manner that round-trips properly
[11:24:59 CEST] <JEEB> although the overlap handling is kind of meh
[11:26:07 CEST] <JEEB> (probably because isobmff doesn't let you do multiple samples with overlapping times)
[11:26:18 CEST] <rcombs> yeah
[11:26:39 CEST] <rcombs> the overlap handling is annoying but not unworkable
[11:26:49 CEST] <rcombs> it's the event extensions that are really bad
[11:26:59 CEST] <rcombs> like, starting an event in one sample, and continuing it into the next
[11:27:12 CEST] <JEEB> continuation-cues etc?
[11:27:21 CEST] <rcombs> it means you can't emit a packet until you've read the _next_ sample to check if it contains an extension
[11:27:23 CEST] <rcombs> yeah, those
[11:27:31 CEST] <JEEB> yea, that's what I meant with the overlap stuff
[11:27:31 CEST] <rcombs> I forget the terminology
[11:27:46 CEST] <rcombs> yeah, I guess it's all part of the same thing
[11:27:57 CEST] <rcombs> ultimately the whole thing is completely useless
[11:28:08 CEST] <rcombs> there's no use-case where you're not better-off just using text files
[11:29:47 CEST] <rcombs> it ends up bigger despite WebVTT's considerable timestamp-header-text overhead, _and_ it's way more complex to parse
[11:29:58 CEST] <JEEB> yea
[11:30:07 CEST] <rcombs> and it's not like people want to mux it alongside other tracks
[11:31:11 CEST] <JEEB> there's some insanity related to it with regards to live streaming
[11:31:23 CEST] <JEEB> but yea, I'm totally thinking how to make it off-band if only possible
[11:33:04 CEST] <rcombs> don't people only want this in DASH, which only ever has one track per segment file
[11:33:59 CEST] <rcombs> I ended up just telling the people asking me for this to use libjass
[11:34:03 CEST] <rcombs> which is what they were already doing anyway
[11:35:39 CEST] <JEEB> well, HLS and DASH it seems
[11:36:02 CEST] <JEEB> also lol libjass, I wonder how to do live subtitles with that
[11:36:17 CEST] <rcombs> you can feed it lines live
[11:36:33 CEST] <JEEB> also then you'd have to implement something similar in mobile clients etc
[11:36:48 CEST] <JEEB> while TTML/WebVTT seems to be already implemented
[11:36:56 CEST] <JEEB> even if shit on a stick sandwich
[11:37:00 CEST] <JEEB> why is this stuff like this ;_;
[11:37:31 CEST] <rcombs> I guess; Android's ExoPlayer has support for generic WebVTT text files and HLS supports WebVTT-in-HLS (which is also just text files)
[11:37:43 CEST] <JEEB> yea
[11:38:09 CEST] <JEEB> which is where the "let's see if we can get by with just separate files" comes into play
[11:47:59 CEST] <cone-142> ffmpeg 03Paul B Mahol 07master:80bc648e7797: avfilter: add tlut2 filter
[15:34:18 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07release/3.1:fef71d661b7a: Update for 3.1.10
[15:53:28 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07release/3.1:afa34cb36edc: RELEASE: Update release number
[16:09:04 CEST] <cone-077> ffmpeg 03Steven Liu 07master:738b29cfb69b: avformat/hlsenc: support fmp4 single file mode
[16:10:58 CEST] <cone-077> ffmpeg 03Steven Liu 07n3.1.10:HEAD: avformat/hlsenc: support fmp4 single file mode
[16:21:26 CEST] <cone-077> ffmpeg 03Steven Liu 07master:44e9783ab9a1: doc/libav-merge: remove the hls merge TODO
[17:07:16 CEST] <durandal_1707> people consider dnxhd frame threading useful
[17:14:31 CEST] <atomnuker> its intra only so it works best there
[18:35:56 CEST] <BBB> TD-Linux: how does av1 solve the problem of not being able to combine tile row threading and frame threading?
[23:04:09 CEST] <thardin> bluh, battling AVOptions
[23:05:15 CEST] <thardin> I somehow managed to get -h full into an infinite loop
[23:10:36 CEST] <nevcairiel> dont re-use the same class for multiple things
[23:10:43 CEST] <nevcairiel> otherwise that happens
[23:10:50 CEST] <thardin> so I noticed
[23:11:17 CEST] <thardin> AV_OPT_TYPE_CONST is still giving me grief. or maybe ffprobe doesn't print encoder options
[23:14:55 CEST] <thardin> so it seems. a bit strange
[23:18:08 CEST] <TD-Linux> BBB, do you mean the stall that you'd get with "up" motion vectors on the bottom tile?
[23:18:39 CEST] <BBB> yes
[23:18:48 CEST] <thardin> is there a way to make an option mandatory?
[23:21:03 CEST] <BBB> thardin: initialize it to an invalid value and then make sure its set to something else in _init
[23:21:16 CEST] <thardin> that's what I'm thinking
[23:21:48 CEST] <thardin> the options system could potentially detect that, via default being outside min/max
[23:22:10 CEST] <thardin> or a flag, which would be cleaner I think
[23:22:41 CEST] <BBB> Im sure that could be done, yes; but right now, using current impl, this is how you can do it ;)
[23:22:56 CEST] <thardin> kk
[23:23:20 CEST] <TD-Linux> BBB, that is not solved. the only thing fixed is coding dependencies across rows
[23:23:36 CEST] <BBB> TD-Linux: thats a problem
[23:23:46 CEST] <TD-Linux> (or rather it's configurable)
[23:23:54 CEST] <BBB> configurable is good
[23:23:59 CEST] <BBB> because it costs performance (quality)
[23:24:08 CEST] <BBB> and having to give up that quality even if frame threading scales better
[23:24:11 CEST] <BBB> is kind of crappy
[23:24:28 CEST] <TD-Linux> BBB, so currently you're allowed to change the tiling on a per frame basis
[23:24:29 CEST] <BBB> i.e. Id prefer frame-mt + tile-col-mt over tile-col-mt + tile-row-mt
[23:25:13 CEST] <TD-Linux> so enforcing something like "MVs can't cross tile boundaries" is not really doable
[23:26:12 CEST] <BBB> no, no, Im not suggesting you do that
[23:26:16 CEST] <BBB> I think that would be a terrible idea
[23:26:22 CEST] <BBB> the concern is more conceptual
[23:26:35 CEST] <BBB> it means you cant combine tile-row-mt with frame-mt
[23:26:44 CEST] <BBB> and thus making tile-row-mt idnuced quality loss optional solves the issue
[23:26:48 CEST] <BBB> because then its just like in vp9
[23:26:49 CEST] <BBB> which is fine
[23:26:53 CEST] <BBB> not great, but fine
[23:32:14 CEST] <TD-Linux> right. the cases you'd do heavy tile-row-mt are cases where a high latency caused by frame-mt would be unacceptable
[23:32:19 CEST] <thardin> BBB: unfortunately it skips setting the option to the default value in the case, leaving it at zero due to av_mallocz()
[23:32:38 CEST] <thardin> I guess I could make -1 "legal"
[23:32:39 CEST] <BBB> thardin: no, no, I dont mean setting it to something outside range
[23:32:44 CEST] <BBB> you need to make the invalid value legal
[23:32:45 CEST] <BBB> yes
[23:32:52 CEST] <BBB> so as an examplem for a required boolean
[23:32:55 CEST] <BBB> set range to [-1,1]
[23:32:56 CEST] <thardin> eww
[23:32:57 CEST] <BBB> init to -1
[23:32:59 CEST] <thardin> but ok
[23:33:03 CEST] <BBB> and then require that its 0 or 1 in init
[23:33:07 CEST] <BBB> its evil, yes, absolutely
[23:35:33 CEST] <BBB> thardin: isnt ffmpeg full of ewwwh stuff? :D
[23:35:57 CEST] <thardin> no, it's all sunshine and rainbows :]
[23:36:04 CEST] <BBB> sweet
[23:36:09 CEST] <thardin> [codec2raw @ 0x7efdb4000920] -mode must be set in order to make sense of raw codec2 files
[23:36:12 CEST] <thardin> good 'nuff
[23:36:25 CEST] <BBB> :D
[23:36:29 CEST] <BBB> tres bien
[23:36:37 CEST] <thardin> unless I want to dive into the arcane logic of opt.c
[23:37:10 CEST] <thardin> a mandatory flag would be nice for a lot of things I suspect
[23:37:31 CEST] <BBB> yes
[23:45:53 CEST] <thardin> -_-  more than 6000 lines of options parsing code
[23:50:55 CEST] <thardin> seems michael stefano anton and lukasz are the ones that have touched it most
[00:00:00 CEST] --- Sat Aug  5 2017