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

[burek]

[00:20:25 CEST] <klaxa> hrm
[00:20:48 CEST] <klaxa> for some reason i have the feeling lua's stack made interfacing with it somewhat easier than using json
[01:55:49 CEST] <Gramner> jamrial: wider vectors results better performance/watt, at least in theory, so it could be useful even on low-power cpus. it just that the throttling has been way to course grained in existing hardware, hopefully they'll improve that
[01:56:52 CEST] <jamrial> that's what i mean, unless they solved the throttling and heat issues, i don't see it being too useful in such a cpu
[01:59:10 CEST] <Gramner> heat isn't really an issue - just downclock it. they just need to figure out how to do that more gracefully than a binary on/off frequency offset
[02:03:26 CEST] <atomnuker> I wonder if using the opmasks and 128/256bit regs would result in less downclocking
[02:04:17 CEST] <Gramner> intel's 10nm being a complete disaster has resulted in nothing new being released so I don't even know what they have internally. ICL has been sitting on a shelf for a year because they can't manufacture it
[02:04:31 CEST] <Gramner> yes, that'd be the same as using sse/avx
[02:05:58 CEST] <atomnuker> they announced they won't be shipping 10nm server chips next year
[02:06:25 CEST] <Gramner> probably nothing else of value either
[02:07:07 CEST] <Gramner> at this rate it'll probably slip to 2020
[02:09:28 CEST] <Gramner> I know some high-ranking intel engineers wanted to backport ICL to 14nm years ago but got shot down by management, so now we have nothing but skylake re-re-re-releases
[02:11:20 CEST] <atomnuker> with different sockets
[02:13:20 CEST] <atomnuker> amd seem to be skipping 10nm and going for 7nm
[02:26:10 CEST] <Gramner> well, "everyone elses" 7nm is comparable to intels 10nm, but tsmc, gf, and samsung will probably all have volume shipments of 7nm before intel 10nm
[02:26:21 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:4dd2c8b9ea46: avcodec/g2meet: Check RGB upper limit
[02:26:21 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:ab834b8f36c8: avcodec/g2meet: ask for sample with overflowing RGB
[02:26:21 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:9f73ae31e075: avcodec/mpeg4videode: Eliminate out of loop VOP startcode reading for studio profile
[02:26:21 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:9e5d0860c043: avcodec/mpeg4videodec: Do not corrupt bits_per_raw_sample
[02:26:21 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:b3a18511cc93: avcodec/mpeg4videodec: Check bps (VOL header) before VOP for studio profile
[02:26:21 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:ba97d75ac625: avcodec/mpeg4video: Detect reference studio streams as studio streams
[02:26:22 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:c6a11714c4b1: avcodec/fic: Avoid some magic numbers related to cursors
[02:26:22 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:cb2f7ea96b4f: avcodec/fic: Check available input space for cursor
[02:26:23 CEST] <cone-255> ffmpeg 03Michael Niedermayer 07master:cb944fc7f132: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0 / COMPOSE_DD137iL0
[04:37:35 CEST] <FishPencil> Where would I find the official spec for a Blu-ray mpls playlist file?
[12:20:15 CEST] <cone-609> ffmpeg 03Carl Eugen Hoyos 07master:380ca1bc0ce8: lavc/v210dec: Skip Canopus C210 extradata.
[14:10:23 CEST] <kierank> gagandeep: hi, do you have patch
[14:11:26 CEST] <gagandeep> kierank: i have seen one more function that is used for a different file with another variable so will implement it first as well
[14:11:34 CEST] <gagandeep> difference coding is done
[14:11:37 CEST] <kierank> ok
[14:12:03 CEST] <gagandeep> but a 'peaklevel' variable is also used in dequantization with other sample
[14:12:30 CEST] <gagandeep> also since they have implemented whole entropy and dequantization in fsm it is tough to go through the code
[14:12:53 CEST] <gagandeep> they are not doing it like you did, where you have dequantized seperately
[14:13:40 CEST] <gagandeep> they first build fsm based on the quantization and then decode the bytestream
[14:15:08 CEST] <kierank> did you start getting those avi files to decode using ffmpeg version of cineformsdk
[14:17:48 CEST] <gagandeep> haven't started that but was going through the ip progressive sample i have acquired
[14:17:59 CEST] <gagandeep> tracking the functions in testcfhd
[14:18:06 CEST] <gagandeep> like i did with interlaced
[14:19:29 CEST] <gagandeep> kierank: although the mountain sample was giving the same error in ffmpeg as the ip progressive sample so i guess if i implement ip frame, it will begin to work
[14:19:42 CEST] <kierank> ok
[14:20:00 CEST] <gagandeep> aka transform type = 2 not implemented, it is the ip transform
[14:20:05 CEST] <kierank> with IP frame you probably need to disable threading
[14:20:11 CEST] <kierank> threading is frame threads, each frame is decoded by a thread
[14:20:14 CEST] <kierank> you can't do that with ip
[14:21:02 CEST] <gagandeep> kierank: there was a macro for enabling debugging in cineformsdk, which helps to reduce thread dependence of code
[14:21:40 CEST] <kierank> I mean in ffmpeg you need to disable
[14:21:43 CEST] <kierank> when you start work
[14:21:53 CEST] <kierank> otherwise you will have many problems
[14:22:36 CEST] <gagandeep> ok, will see
[17:59:05 CEST] <jamrial> nevcairiel: https://gitlab.com/mbunkus/mkvtoolnix/commit/42b5f13c6b60e0cbd65c0f89584cbd8762f63439 since you were wondering about it
[18:00:42 CEST] <nevcairiel> yeah i know, its slightly unfortunate that he had a release before that, but what can you do
[19:31:44 CEST] <jamrial> durandal_1707: can't you use float_dsp anywhere in these filters?
[19:35:01 CEST] <durandal_1707> jamrial: nope, they are doing very special matrix operations that take 85% of whole time, LDL factorization
[20:33:46 CEST] <cone-609> ffmpeg 03Aman Gupta 07master:2734f8d63a38: avformat: add skip_estimate_duration_from_pts
[20:38:29 CEST] <tmm1> how do i decide between minor and micro bump
[20:38:38 CEST] <tmm1> just added AV_DISPOSITION_STILL_IMAGE to avformat.h
[20:42:23 CEST] <JEEB> isn't it bugfixes=micro, new things=minor?
[20:42:33 CEST] <JEEB> and backwards incompatible is ajor
[20:46:29 CEST] <tmm1> ok that makes sense
[20:47:56 CEST] <tmm1> rcombs: if you get a chance to poke at http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/229483.html it could use a set of fresh eyes
[21:05:59 CEST] <cone-609> ffmpeg 03Aman Gupta 07master:5dfeb7f0811c: avformat/mpegts: tag video streams with still images
[22:21:09 CEST] <tmm1> rcombs: ok i took another stab and sent a cleaner version of the patch to the ML
[22:43:09 CEST] <JEEB> funky, someone implementing MVC? https://gitlab.websupport.sk/peter.kovar/ffmpeg-mvc
[22:46:39 CEST] <nevcairiel> Anton worked on that as well before he vanished
[22:47:18 CEST] <JEEB> which hwdecs supported MVC btw?
[22:47:38 CEST] <JEEB> d3d11va or dxva2? or is it just the intel stuff
[22:48:03 CEST] <JEEB> and of course there's the question of the muxing that a lot of those things have the stuff in (not in a single stream)
[22:48:10 CEST] <nevcairiel> dxva can do it theoretically, if you had a software decoder to do all the other stuff
[22:49:04 CEST] <wm4> did anyone manage to make this gitlab thing show a diff for the mvc changes?
[22:51:02 CEST] <JEEB> nevcairiel: I guess you're just using the libbluray demuxer as well as reader?
[22:51:09 CEST] <JEEB> and then you get both things in a single stream
[22:51:16 CEST] <JEEB> => feed to something?
[23:08:55 CEST] <nevcairiel> JEEB: yeah i properly interleave the two streams to feed them to the decoder
[23:11:00 CEST] <JEEB> ah, so using full libbluray input doesn't do that automagically for you
[23:11:08 CEST] <JEEB> ok, then there's some extra interleaving needed, yes :)
[23:11:13 CEST] <nevcairiel> interleaving is currently timestamp based so its a bit fragile, but the  blu-ray s pec is pretty strict about that
[23:11:25 CEST] <JEEB> yea
[23:11:55 CEST] <nevcairiel> libbluray doesnt really do any 3D stuff
[23:12:31 CEST] <nevcairiel> so i get the main stream t hrough it, and the mvc stream i parse directly through avformat, then interleave afterwards
[23:12:47 CEST] <JEEB> :)
[23:12:48 CEST] <nevcairiel> doesnt help that main and mvc stream are in separate files =p
[23:13:10 CEST] <JEEB> isn't there another one where they're in the same?
[23:13:21 CEST] <JEEB> since they do some UDF packet-based hackery
[23:13:25 CEST] <nevcairiel> sort of, but its not interleaved frame-by-frame but interleaved in blocks
[23:13:25 CEST] <JEEB> the SS-something
[23:13:31 CEST] <nevcairiel> so its odd to use
[23:13:35 CEST] <JEEB> ah, right
[23:13:38 CEST] <nevcairiel> not sure w hat exactly the use-case for those combined files is
[23:13:51 CEST] <nevcairiel> maybe to ensure IO is done a lways sequentally
[23:13:54 CEST] <nevcairiel> but i dont use those
[23:24:20 CEST] <tmm1> JEEB: AVProgram has a flags field but I can't tell if it is used for anything
[23:25:36 CEST] <tmm1> maybe AV_PROGRAM_RUNNING was meant to be a flag, but it was never used for anything
[00:00:00 CEST] --- Fri May 18 2018