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

[burek]

[00:39:16 CEST] <tmm1> JEEB: have a link to your 'late pcr' sample?
[00:47:40 CEST] <JEEB> pm'd a link since I hadn't cut it at all
[01:00:43 CEST] <tmm1> ah ok i see, two teletext packets with wildly behind pts before the first pcr shows up
[01:01:10 CEST] <JEEB> yes
[01:01:20 CEST] <JEEB> because their timestamps are 5xxxxxx
[01:01:24 CEST] <JEEB> while video is 8xxxxx
[01:01:32 CEST] <JEEB> difference about ~8.5h
[01:01:41 CEST] <JEEB> and then as soon as PCR comes they start getting adjusted
[01:03:33 CEST] <tmm1> using -fix_teletext_pts, or is there some other generic pts adjustment too
[01:03:56 CEST] <JEEB> I think it's generic because I don't think I used that option
[01:04:21 CEST] <JEEB> also it gets funny when lavf reads in the timestamp after the video track's
[01:04:40 CEST] <JEEB> it then decides there's a wrap-around and puts it like 20 hours in the future
[01:06:04 CEST] <JEEB> the worst thing of course is that everyone seems to handle those with PCR, so nobody cares if the PTS is all over the place splattered on the walls :D so you can't really do much more than wait for the delicious PCR in one way or another
[01:10:21 CEST] <cone-622> ffmpeg 03Michael Niedermayer 07master:d628caf54f57: avformat/mxfenc: Add Sample width/height/x offset/y offset, Display x offset and F2 offset
[01:10:21 CEST] <cone-622> ffmpeg 03Michael Niedermayer 07master:10ca419dd8a3: avformat/mxfenc: Set color siting to 0 for D10-MXF
[01:16:18 CEST] <JEEB> but for now, some sleep
[02:59:25 CEST] Action: kierank agrees with atomnuker 
[02:59:30 CEST] <kierank> about twitter poll
[02:59:41 CEST] <atomnuker> that was quick
[02:59:54 CEST] <kierank> but it's not 2k
[02:59:59 CEST] <kierank> it's 256 bytes
[03:00:05 CEST] <kierank> so maybe not 
[03:00:44 CEST] <atomnuker> fragmentation then in case you have anther LUT which doesn't fit in L1
[03:01:16 CEST] <kierank> could well be that a synthetic benchmark doesn't match reality
[03:02:55 CEST] <atomnuker> definitely won't
[04:10:32 CEST] <philipl> BtbN, wm4: So, as expected, it's all fine. It's the same decoder and poll after a seek. So no worries.
[11:07:44 CEST] <aleontiev> What is the meaning of bits_per_coded_sample for video streams? Is it the same as total amount of memory needed to store pixel in encoded stream?
[11:26:29 CEST] <nevcairiel> there is no clear use for that property in encoded video
[11:30:59 CEST] <aleontiev> OK, but for rawvideo?
[12:16:47 CEST] <durandal_1707> atomnuker: you sure you will finish it this weekend?
[12:45:12 CEST] <cone-648> ffmpeg 03Paul B Mahol 07master:9b6f8fb25df6: avfilter/vf_deblock: add timeline support
[14:56:11 CEST] <atomnuker> durandal_1707: might take a bit longer, I'm reorganizing the tables and merging the init functions
[14:56:37 CEST] <atomnuker> and wondering why the init function is templated and how that even works
[15:05:59 CEST] <durandal_1707> atomnuker: so expect it arround next year this time?
[15:44:40 CEST] <atomnuker> lol no
[15:48:09 CEST] <durandal_1707> 5 months passed for atrac9 and still nothing, so anything is possible
[15:49:28 CEST] <cone-648> ffmpeg 03Paul B Mahol 07master:1c2e5fc4546f: avfilter/vf_maskedmerge: add slice threading
[16:10:28 CEST] <atomnuker> durandal_1707: I did take a look at that 2 weeks ago, seems to be a problem with demuxing
[16:10:53 CEST] <atomnuker> also one track from the testset breaks band extension, just need to fix that
[16:11:32 CEST] <atomnuker> I'll leave the demuxing problem in as a todo, can't figure it out
[16:11:52 CEST] <atomnuker> it only happens on files from one game anyway
[16:54:44 CEST] <durandal_1707> there appears someone uses owdenoise filter
[17:02:36 CEST] <durandal_1707> some even compared owdenoise and hqdn3d with avisynth filters, and wrote like author of hqdn3d is Fabrice
[17:07:15 CEST] <JEEB> and I guess he isn't? :) people have always various funny ideas of things
[17:12:09 CEST] <atomnuker> the netflix guys used it to develop the film grain reconstruction av1 experiment
[17:12:25 CEST] <atomnuker> told them to use nlmeans back in august, don't know if they did
[18:15:03 CEST] <durandal_1707> ubitux: nlmeans=s=4:p=7:r=65 this are translated parameters used by KNLMeansCL for that gray sample i uploaded, yours implemenation have bad edges
[18:16:37 CEST] <durandal_1707> and i can confirm that tnlmeans, another implementation (without need for OpenCL)- does not have this bug, it gives similar results as KNLMeansCL
[18:18:12 CEST] <durandal_1707> are you gonna fix this, or you are working on subtitles?
[18:44:44 CEST] <JEEB> michaelni: I wonder if you just lowered the possibility of having a lot of mp3 streams in mpeg-ts inputs with those patches 8)
[18:45:42 CEST] <durandal_1707> is that bad or good?
[18:46:35 CEST] <JEEB> I think that's good, mislabeling "unknown" as "mp3" isn't too great
[18:47:29 CEST] <BtbN> ffmpeg doesn't have an OpenCL deinterlace filter (yet), does it?
[18:48:12 CEST] <jamrial> i think not
[18:48:24 CEST] <jamrial> isn't there a gsoc student doing opencl in some form?
[18:48:24 CEST] <JEEB> nope
[18:48:29 CEST] <JEEB> yea
[18:48:38 CEST] <BtbN> I basically want to port one to CUDA
[18:48:39 CEST] <JEEB> I think someone was supposed to be doing some sort of opencl?
[18:48:58 CEST] <BtbN> And I'm bad at writing the actual code, so having something to just port would be nicer
[18:49:21 CEST] <BtbN> I mean, getting a stupid simple bob deinterlacer would probably be possible, but who wants that
[18:49:52 CEST] <BtbN> can't write a generic filter that runtime-loads cuda code sadly
[18:51:04 CEST] <jamrial> well, we first need an opencl one that can run on any hardware :p
[18:51:29 CEST] <BtbN> At least that wouldn't be an issue for CUDA
[18:52:15 CEST] <durandal_1707> are  .exe still detected as .mp3 ?
[18:53:54 CEST] <michaelni> they should not be anymore, but i dont have many exe on my linux box
[18:54:22 CEST] <durandal_1707> and elf?
[18:58:32 CEST] <michaelni> the one i tried is no longer detected as mp3
[19:01:35 CEST] <durandal_1707> excellent!
[19:07:29 CEST] <BtbN> I don't get why there is basically zero pre-existing code for OpenCL/CUDA deinterlacers. Everyone just using the in-GPU ones it seems
[19:09:57 CEST] <BtbN> it doesn't help that the best algorithm, NEDI, also shares name with some neural network deinterlacing stuff
[19:10:55 CEST] <BtbN> From how I understand it, nedi "deinterlacing" is just throwing away the even or odd fields, and then scaled the remaining ones up?
[19:13:51 CEST] <JEEB> more or less yes, except you can also do it for both fields
[19:13:58 CEST] <JEEB> thus you get full rate bobbing
[19:14:37 CEST] <BtbN> what even is considered the state of the art deinterlacing algorithm right now?
[19:14:43 CEST] <BtbN> except for that neutral network stuff
[19:15:30 CEST] <JEEB> well you have two different problems anyways. pictures that are not really connected to each other, and pictures that are part of the same picture
[19:17:09 CEST] <atomnuker> before neural networks it used to be motion estimated deinterlacers
[19:17:19 CEST] <atomnuker> but I think neural networks do better
[19:18:22 CEST] <JEEB> I mean, inter prediction can work with deinterlacing, but it's a hard problem
[19:18:25 CEST] <JEEB> to make it look good
[19:18:33 CEST] <JEEB> thus it is just simpler to throw good scaling at the problem
[19:18:46 CEST] <BtbN> well, I can't find any documented algorithm for motion adaptive deinterlacing that could easily be implemented
[19:18:55 CEST] <JEEB> I think there was an avisynth script called QTGMC
[19:19:05 CEST] <JEEB> which picked up NNEDI3 and some mocomp stuff
[19:19:18 CEST] <BtbN> but nnedi3 is the neural network thing?
[19:19:19 CEST] <JEEB> used to be the top of the line stuff for deint in avisynht world
[19:19:33 CEST] <JEEB> yes, it mixed the stuff up
[19:19:40 CEST] <JEEB> doing mocomp probably on top of the upscaled images
[19:19:46 CEST] <JEEB> never looked into its internals
[19:19:51 CEST] <BtbN> I'm looking for something to implement in CUDA, to replace the inaccessible deinterlacer in cuvid
[19:20:27 CEST] <JEEB> yes, and you were asking about "state of the art", and I gave thee the state of the art in Avisynth communities. of course for academical stuff I can point you towards prunedtree
[19:30:24 CEST] <BtbN> I don't get this whole probing/mp3/txt security debate. If you have the ability to make ffmpeg open arbitrary system files, you have already a bit problem no matter what. No matter if we disable more and more demuxers/formats, something is going to open it, and it will have ways to attack it.
[19:31:57 CEST] <j-b> Well, sure, but in the automatic/probing part, it should tell you "this is weak detection"
[19:32:02 CEST] <JEEB> I think the "security" side is just additive. it was generally about "people throw txt or exe/elf files at lavf and except them to get two middle fingers raised"
[19:49:38 CEST] <Compn> i love the txt decoder in ffmpeg :D
[19:53:39 CEST] <durandal_1707> for mplayer devs thats normal
[20:49:30 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:6f50be876016: avformat/mpegtsenc: set AVFMT_NODIMENSIONS
[20:49:30 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:18074b309fb4: avformat/hlsenc: set AVFMT_NODIMENSIONS
[20:50:55 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:9152c1e49555: avformat/mpegts: parse sections with multiple tables
[20:50:56 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:7db022e67bab: avformat/mpegts: reindent after last change
[21:03:49 CEST] <Mindless`> I have a small bug to report, but Trac won't let me sign up (captcha is broken)
[21:03:49 CEST] <Mindless`>  - man page says option is named "xsd_compliant" -- https://github.com/FFmpeg/FFmpeg/blob/1c2e5fc4546f2c80212add77015003de200f7963/doc/ffprobe.texi#L587
[21:03:49 CEST] <Mindless`>  - actual option name is "xsd_strict" -- https://github.com/FFmpeg/FFmpeg/blob/1c2e5fc4546f2c80212add77015003de200f7963/fftools/ffprobe.c#L1629
[21:10:10 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:cae004cabb68: doc: fix incorrect reference to xsd_compliant option
[21:10:11 CEST] <tmm1> Mindless`: thanks
[21:10:23 CEST] <JEEB> :)
[21:12:10 CEST] <Mindless`> no problem, thanks for fixing it
[21:37:01 CEST] <BtbN> philipl, what format are OpenGL textures in when mapped to CUDA? 0BGR?
[21:41:47 CEST] <durandal_1707> we use C99 in FFmpeg, so isnormal() is expected to always be available?
[21:44:37 CEST] <jamrial> durandal_1707: we have wrappers for isinf() and isnan() in libavutil/libm.h, so probably not
[21:45:16 CEST] <jamrial> then again, most of those were for old msvc, and i think we're not supporting versions older than 2013 (first one c99 compliant) anymore
[21:45:43 CEST] <JEEB> yea, I think 2013 update 2 is needed
[21:46:29 CEST] <atomnuker> seriously?
[21:46:46 CEST] <atomnuker> right, then its time to accept for (int loops
[21:47:07 CEST] <JEEB> yea, the msvc conversion thing possibly still works, but effectively we don't test nor care about it in general
[22:20:18 CEST] <durandal_1707> ubitux: i fixed excessive edges artifacts and added option for less blurred denoising
[23:08:07 CEST] <philipl> BtbN: I don't know. I've only done the write-target work where I create a texture with the right number of channels for YUV data.
[23:08:35 CEST] <philipl> I assume that any GL format is representable. You get however many channels there are in the array and in CUDA they are just bytes.
[23:09:49 CEST] <philipl> BtbN: I found a GL implementation of yadif
[23:09:53 CEST] <philipl> I can dig it up again for you
[23:10:12 CEST] <BtbN> A GL implementation?
[23:10:25 CEST] <philipl> shader implementation, yes.
[23:10:34 CEST] <BtbN> interesting. Yes, that should be portable
[23:13:22 CEST] <philipl> While I'm digging that out, here is a simple GL one from gstreamer
[23:13:24 CEST] <philipl> https://github.com/GStreamer/gst-plugins-base/blob/master/ext/gl/gstgldeinterlace.c
[23:14:11 CEST] <philipl> and here is the yadif: https://git.sesse.net/?p=movit;a=tree
[23:15:17 CEST] <philipl> https://git.sesse.net/?p=movit;a=blob;f=deinterlace_effect.frag;h=140f4205e421b79b73cbb4f132fd3da8888ffd5b;hb=HEAD
[23:15:35 CEST] <JEEB> huh, gl version of yadif
[23:17:00 CEST] <BtbN> it's RGB instead of YUV, but that shoudln't be too different
[23:18:15 CEST] <wm4> didn't we know about it and it was bad because GPL?
[23:18:15 CEST] <durandal_1707> GPU cant do YUV
[23:18:28 CEST] <philipl> wm4: we knew about it and it was useless for mpv because of GPL, yes.
[23:18:39 CEST] <philipl> I assume BtbN is not bothered by that.
[23:18:41 CEST] <BtbN> of course it can, the GPU doesn't care what numbers it crunches
[23:18:46 CEST] <wm4> useless fo broader ffmpeg use too
[23:18:56 CEST] <BtbN> it will be non-free in ffmpeg anyway
[23:19:02 CEST] <philipl> Even better.
[23:19:06 CEST] <philipl> GPL non-free :-)
[23:19:22 CEST] <durandal_1707> why non-free?
[23:19:25 CEST] <BtbN> because CUDA
[23:19:57 CEST] <BtbN> I wonder what license you end up with if using https://forum.doom9.org/showthread.php?p=980375#post980375 as basis
[23:20:15 CEST] <durandal_1707> please remove all non LGPL parts of ffmpeg and make new fork
[23:21:40 CEST] <philipl> Only GPL+non-free builds will be allowed from now on.
[23:47:58 CEST] <philipl> BtbN: double-non-free.
[00:00:00 CEST] --- Sun May 13 2018