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

[burek]

[00:36:59 CEST] <kierank> durandal_1707: - from get vlc i think means end of bitstream
[00:43:08 CEST] <durandal_1707> kierank, atomnuker: i fixed it by interpreting negative values as positive one
[00:43:18 CEST] <durandal_1707> and it works TM
[00:43:49 CEST] <kierank> durandal_1707: https://patchwork.ffmpeg.org/patch/7430/
[00:44:34 CEST] <durandal_1707> kierank: that is not reality
[00:44:39 CEST] <atomnuker> durandal_1707: which decoder are you porting?
[00:44:45 CEST] <kierank> durandal_1707: tell michaelni that
[00:44:59 CEST] <durandal_1707> atomnuker: see ml
[00:47:45 CEST] <atomnuker> that's a lot of tables
[00:50:46 CEST] <kierank> dts level of tables
[01:00:19 CEST] <atomnuker> wm4: patch sent for mp3 float, it seems only 2 tests needed changing
[01:00:37 CEST] <cone-475> ffmpeg 03Josh de Kock 07master:cda43940da87: checkasm/Makefile: add EXTRALIBS-libavformat
[01:00:37 CEST] <cone-475> ffmpeg 03Josh de Kock 07master:8f1382f80e0d: lavfi: add new iteration API
[01:00:37 CEST] <cone-475> ffmpeg 03Josh de Kock 07master:d8ae40611bc0: Revert "lavd: add new API for iterating input and output devices"
[01:00:37 CEST] <cone-475> ffmpeg 03Josh de Kock 07master:65452bcd6416: lavd: remove linked lists
[01:00:37 CEST] <cone-475> ffmpeg 03Josh de Kock 07master:22381906f3fd: cmdutils: use new APIs
[01:06:46 CEST] <nevcairiel> why not do the same thing for mp2 as well, its basically the same code isnt it
[01:06:54 CEST] <JEEB> pretty much
[01:08:08 CEST] <JEEB> anyone interested in testing out https://patchwork.ffmpeg.org/patch/8256/ ? I can link the sample, didn't just post it on the ML because it's ~300MiB as I'm a lazy git and haven't cut it yet :P
[01:09:08 CEST] <jamrial> Chloe: move the avpriv_register_devices() prototype to avformat/internal.h
[01:09:39 CEST] <Chloe> jamrial: Will do. Any other comments?
[01:10:11 CEST] <wm4> atomnuker: I tried to change some other decoders as well
[01:11:04 CEST] <jamrial> Chloe: still looking
[01:12:13 CEST] <wm4> atomnuker: and that was more work and in the end I didn't bother to finish it
[01:12:22 CEST] <Chloe> jamrial: can i also revert the commit which adds the if FF_API_NEXT stuff to format.c as thats no longer needed
[01:12:33 CEST] <Chloe> (Ill send it all to the ML of course)
[01:13:41 CEST] <jamrial> send any patches you have for further changes, yes
[01:21:57 CEST] <atomnuker> wm4: which other decoders do that?
[01:25:06 CEST] <Chloe> oops forgot to fate test before I sent patches
[01:25:30 CEST] <Chloe> (the ones on the ML, I definitely tested before I pushed dont worry)
[01:44:56 CEST] <wm4> I forgot... maybe the other mpX codecs?
[01:52:41 CEST] <sfan5> mp1float, mp3adufloat, mp3on4float exist
[01:58:18 CEST] <JEEB> &34
[02:04:39 CEST] <atomnuker> sfan5: yeah, I reordered all the mp3 ones
[02:04:45 CEST] <atomnuker> so I guess its just mp1 and mp2
[03:00:10 CEST] <cone-475> ffmpeg 03Michael Niedermayer 07master:8247e0304ed5: configure: fix build
[03:00:11 CEST] <cone-475> ffmpeg 03Timo Teräs 07master:8c980b1c92bb: avformat/mov: parse multiple iTunes cover images
[03:00:12 CEST] <cone-475> ffmpeg 03Michael Niedermayer 07master:47b7c68ae545: avcodec/utvideodec: Set pro flag based on fourcc
[03:00:13 CEST] <cone-475> ffmpeg 03Michael Niedermayer 07master:35eeff30caf3: avfilter/vf_signature: use av_strlcpy()
[03:14:50 CEST] <jamrial> michaelni: curious, are you using zsh or something like that?
[03:15:08 CEST] <jamrial> i couldn't reproduce the error you reported and fixed
[03:15:22 CEST] <michaelni> maybe my cnofigure used dash, not sure
[04:18:27 CEST] <Chloe> jamrial: All fixed locally, with a couple other commits which fix const warnings. Am I alright to just push it?
[04:20:47 CEST] <jamrial> Chloe: the patch moving the prototype to internal, yes if fixed, since it's simple
[04:21:04 CEST] <jamrial> for the others wait a bit to see if someone else reviews/test them
[04:21:55 CEST] <Chloe> jamrial: I added a couple more commits, I'll just resend the whole set then; I think that'd be best.
[04:22:06 CEST] <jamrial> sure
[04:26:29 CEST] <Chloe> Well fate needs to run, so I might as well go to sleep. I'll run `make fate && git send-email` so they may appear on the ML whenever fate completes (if it passes)
[04:31:04 CEST] <atomnuker> make fate -j8 doesn't run in like 2 minutes for you?
[04:33:57 CEST] <jamrial> Chloe: you should let make run several jobs using -j# as atomnuker mentioned
[06:15:14 CEST] <cone-218> ffmpeg 03enctac 07master:be502ec6cde0: vf_libvmaf: Fix memory leak
[10:00:25 CEST] <durandal_1707> Chloe: the new API is broken in sense I can not easily switch branches while developing new filters - I need to recompile every single time
[11:58:13 CEST] <durandal_1707> michaelni: do you know a reson why would get_vlc2 return negative values different than -1?
[12:20:09 CEST] <durandal_1707> is there dsp for copying macroblocks?
[12:27:05 CEST] <jdarnley> I recall there being a function to copy from some block to an plane.
[12:41:47 CEST] <michaelni> durandal_1707, get_vlc* should return the code that the user had in the table ints initialized with, if the user places negative values in it it should return these too
[12:43:44 CEST] <durandal_1707> michaelni: symbols/codes are uint16_t and I use: int v = get_vlc2()
[12:46:22 CEST] <JEEB> michaelni, durandal_1707 - the sample for that fix I made for disappearing subtitles is https://kuroko.fushizen.eu/samples/2018-03-26-subtitles_disappear_after_ad_pause.ts btw, so you can test it too
[12:47:51 CEST] <JEEB> it should replicate with anything that gives out audio and video
[12:47:54 CEST] <JEEB> in the filter chain
[12:48:33 CEST] <JEEB> -filter_complex "[0#1000][0#3000]overlay=eof_action=pass[overlay_out];[overlay_out]yadif=mode=send_frame:deint=interlaced[yadif_out];[yadif_out]scale=w=1024:h=576[output];[0#2000]aresample=48000[a_out]"
[12:48:59 CEST] <JEEB> and then map the video with any encoder and it should be pretty obvious :)
[12:50:12 CEST] <JEEB> durandal_1707: this also shows the PTS going backwards after the re-init
[12:50:30 CEST] <JEEB> if you map the audio and feed it to aac f.ex.
[12:51:15 CEST] <michaelni> durandal_1707, if iam not mistaken, the internal data type for thr vlc table is int16_t so even if the input is uint16_t some larger ones should fold onto negative ones
[13:10:34 CEST] <cone-767> ffmpeg 03Jan Ekström 07master:e760c12aeef6: ffmpeg: prevent premature EOF in sub2video with nullptr AVSubtitles
[13:11:48 CEST] <JEEB> yay, got a comment from nicolas in the end :)
[14:02:49 CEST] <cone-767> ffmpeg 03Rostislav Pehlivanov 07master:a1b91b0cc28a: lavc: prefer the mp3float decoder to the mp3 decoder
[15:27:39 CEST] <Chloe> durandal_1707: send a patch to revert the new API
[15:27:52 CEST] <durandal_1707> Chloe: why?
[15:28:45 CEST] <Chloe> You say its broken, no? (Only after its pushed no less)
[15:29:04 CEST] <Chloe> Or do you have a better suggestion on how to fix your issue
[15:30:02 CEST] <durandal_1707> i have workaround
[15:32:32 CEST] <Chloe> Also how did you not have to recompile when adding new components before? It would change allfilters.c because of a new filter define which triggers a full rebuild of lavfi
[15:33:31 CEST] <Chloe> Or if youre talking about it not being in filter_list.c then its pretty easy to just add it to the list without rerunning configure
[15:49:47 CEST] <cone-767> ffmpeg 03Martin Vignali 07master:4152413dde1c: avfilter/showvolume : move clear picture part to a func
[15:49:48 CEST] <cone-767> ffmpeg 03Martin Vignali 07master:e4cfb2c66999: avfilter/showvolume : move width test for draw volume to the start of the loop
[15:49:49 CEST] <cone-767> ffmpeg 03Martin Vignali 07master:78b6887da3b9: avfilter/showvolume : indent after prev commit and add comment
[15:58:06 CEST] <atomnuker> jkqxz: I got vaapi -> map to vulkan -> filter -> map to drm -> map to vaapi working
[15:59:08 CEST] <atomnuker> unsuprisingly vaapi doesn't care that most of the fields of the drm frame mapped from vulkan are missing (no modifier and no objects set)
[16:02:01 CEST] <kierank> michaelni: so your patch is wrong?
[16:02:01 CEST] <wm4> atomnuker: looks like nicolas george prefers Libav development policies, what is your position on this?
[16:03:18 CEST] <atomnuker> I'll tell him to kindly fuck off
[16:03:49 CEST] <wm4> :/
[16:04:14 CEST] <wm4> also lol at his explanation of "LGTM"
[16:05:14 CEST] <atomnuker> :/? should I unkindly tell him to do that?
[16:17:51 CEST] <michaelni> kierank, what patch ? and why would it be wrong ?
[16:18:24 CEST] <kierank> michaelni: https://patchwork.ffmpeg.org/patch/7430/
[16:19:13 CEST] <michaelni> ok, what do you think is wrong on it ?
[16:20:03 CEST] <jamrial> <@atomnuker> I'll tell him to kindly fuck off
[16:20:05 CEST] <jamrial> no, you wont
[16:20:43 CEST] <jamrial> you'll ignore him, seeing he's not even asking you to revert it
[16:21:12 CEST] <jamrial> we don't need more threads with insults and flamewars
[16:23:18 CEST] <atomnuker> I'll just tell him to go on IRC
[16:29:29 CEST] <wm4> anyway, this is so ffmpeg
[16:36:11 CEST] <Chloe> jamrial: looks like the set sent to the ML. Its got all fixed patches previously sent and another fix for an issue I noticed (which didnt come up in fate cause was still using the old API)
[16:39:41 CEST] <kierank> michaelni: you just said negative values are allowed
[16:44:31 CEST] <michaelni> kierank, yes the user could use -1 as a valid code in the initialization. But this doesnt contradict "returns the code parsed or -1 if no vlc matches". The text does not say -1 implies its an error if the user defines one of the valid codes as -1. 
[16:44:50 CEST] <kierank> of course it contradicts
[16:45:04 CEST] <kierank> it's a function, you don't know what's going on underneath
[16:45:15 CEST] <michaelni> please explain how it contradicts
[16:45:47 CEST] <kierank> how is a user meant to know the failure state
[16:46:02 CEST] <kierank> this is not about mathematical facetiousness, it's about good documentation
[16:46:59 CEST] <michaelni> sure, its bad situation, i am disagreeing. but the documentation isnt at fault it just documents how it works
[16:47:08 CEST] <michaelni> i am NOT disagreeing
[16:47:54 CEST] <michaelni> the user could simply not use -1 as a valid code then -1 can be used to detect the error case
[16:50:54 CEST] <durandal_1707> error code and return value should not use same memory
[16:51:43 CEST] <durandal_1707> error code should be returned in sepearate argument
[18:24:56 CEST] <jamrial> atomnuker: please stop replying to that thread. just drop the subject
[19:23:54 CEST] <atomnuker> I did
[19:55:17 CEST] <cone-924> ffmpeg 03heimdallr 07master:354b26a3945e: avcodec/imgconvert: Fix loss mask bug in avcodec_find_best_pix_fmt_of_list()
[20:38:02 CEST] <cone-924> ffmpeg 03Paul B Mahol 07master:8dff6c284496: avfilter/af_amix: add weights option
[20:55:08 CEST] <cone-924> ffmpeg 03Paul B Mahol 07master:52e97814a18f: avformat/mpeg: fix PCM-DVD mis-detection as MLP
[20:55:09 CEST] <cone-924> ffmpeg 03Paul B Mahol 07master:7643e2752804: avformat/mpeg: fix detection and demuxing of raw AC3 in mpegps
[21:00:36 CEST] <atomnuker> durandal_1707: why did you push this? an lgtm from michaelni? when he says it looks good to him it means it looks good to him only and no one else!
[21:00:40 CEST] <cone-924> ffmpeg 03Paul B Mahol 07master:1f7705e5b16d: avformat/mpeg: fix logic failure
[21:02:19 CEST] <atomnuker> I really hate how he said that, as if he's the fucking grand master of the project and all commits need to go through him, at his own leisure
[21:04:50 CEST] <atomnuker> sorry, but at least I feel better now
[21:06:11 CEST] <kierank> durandal_1707: I think I will finish sstp today
[21:09:37 CEST] <cone-924> ffmpeg 03Paul B Mahol 07master:099564120274: avformat/mpeg: add missing check
[21:09:44 CEST] <durandal_1707> i hate mpeg*
[21:19:09 CEST] <durandal_1707> i will push big ucod unreviewed patch to make nicolas happy
[21:28:41 CEST] <kierank> how do I fix =yes: not found eval: librtmpt_protocol
[21:28:45 CEST] <kierank> some stupid line endings bug
[21:29:36 CEST] <kierank> michaelni: 
[21:29:36 CEST] <kierank> please use different variable names
[21:29:36 CEST] <kierank> mb_width and mb_height are generally used to represent the width and height in number of macroblocks
[21:29:36 CEST] <kierank> not the width or height of a single macroblock (which is basically fixed at 16 for mpegvideo
[21:29:41 CEST] <kierank> can you suggest a name please
[21:29:45 CEST] <kierank> I am not as creative as you
[21:30:01 CEST] <kierank> width_of_mb?
[21:30:16 CEST] <durandal_1707> mb_size_w
[21:30:25 CEST] <kierank> lol
[21:31:27 CEST] <michaelni> kierank, pick what you prefer, width_of_mb sounds fine
[21:31:51 CEST] <durandal_1707> pick MacroBlockWidthInt
[21:32:11 CEST] <kierank> I think I will push patches, they have been through many rounds of review
[21:32:23 CEST] <kierank> including many LGTM and then further review
[21:32:41 CEST] <durandal_1707> is it feature complete?
[21:33:29 CEST] <kierank> DPCM mode I will do later
[21:33:36 CEST] <kierank> but really I need samples
[21:33:43 CEST] <michaelni> kierank, if the patches differ from what was tested / reviewed / approved its maybe better to post again
[21:34:10 CEST] <kierank> nobody tested anything, just complained about issues they didn't bother to research about
[21:34:16 CEST] <kierank> just ricing complaints
[21:34:23 CEST] <durandal_1707> i tested, and it worked fine
[21:35:16 CEST] <durandal_1707> the last one, previous would random crash
[21:36:28 CEST] <michaelni> i did also test one older set IIRC but if i can retest what will be pushed before its pushed that decreases the chance of a missed bug
[21:36:48 CEST] <kierank> Please use avpriv_find_start_code() or document why that should not be used.
[21:36:48 CEST] <kierank> Otherwise i guess it wont take long for someone to replace this by a call
[21:36:48 CEST] <kierank> to it or some other optimized existing start code search routine
[21:36:53 CEST] <kierank> I still don't understand what this review means
[21:36:58 CEST] <kierank> it's not the same start code
[21:37:11 CEST] <kierank> so I don't understand why it needs avpriv_find_start_code
[21:37:13 CEST] <kierank> I said this before
[21:38:01 CEST] <durandal_1707> did you tried to use it inside code?
[21:40:02 CEST] <kierank> of course not
[21:40:06 CEST] <kierank> I have an unaligned bitstream
[21:40:37 CEST] <kierank> anyway I will let michaelni write riced version
[21:41:49 CEST] <durandal_1707> just commit, if somebody wants to improve, he can send patch or push
[21:45:42 CEST] <durandal_1707> atomnuker: why is atrac9 is so slow doing? can I try to fix it?
[21:46:37 CEST] <kierank> durandal_1707: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225186.html
[21:46:41 CEST] <kierank> what is correct coding style?
[21:47:26 CEST] <durandal_1707> kierank: } else {
[21:47:30 CEST] <durandal_1707> in same line
[21:47:45 CEST] <kierank> ok thanks
[21:48:02 CEST] <durandal_1707> also sizeof(*s->block32)
[21:48:57 CEST] <kierank> one sec I still fixing michaelni review
[21:49:45 CEST] <kierank> michaelni: 
[21:49:46 CEST] <kierank> > +    s->mb_intra = 1;
[21:49:46 CEST] <kierank> This can probably be set outside the mb loop
[21:49:49 CEST] <kierank> where do you want me to set it?
[21:50:32 CEST] <durandal_1707> that is    e x t r e m e   m i c r o     o p t i m i z a t i o n
[21:52:55 CEST] <kierank> durandal_1707: yes of course
[21:53:59 CEST] <durandal_1707> kierank: before loop that calls it bunch of times
[21:54:20 CEST] <kierank> I can't because that's done in function pointer
[21:54:26 CEST] <kierank> by mpegvideo.c madness
[21:54:56 CEST] <durandal_1707> than ignore that one, and do other one
[22:03:49 CEST] <durandal_1707> was libaom wrapper really written in 2010? :o
[22:23:32 CEST] <kierank> ok I will submit patch, I await ricing reiews
[22:23:33 CEST] <kierank> reviews
[22:26:01 CEST] <durandal_1707> atomnuker: what about dca psy patch?
[22:27:24 CEST] <kierank> durandal_1707: can you review
[22:30:13 CEST] <jamrial> durandal_1707: no, that's a copy paste copyright header from libvpx wrapper
[22:31:09 CEST] <jamrial> since it's pretty much the same code after a s/vpx/aom/
[22:38:49 CEST] <durandal_1707> kierank: can't apply it
[22:38:53 CEST] <kierank> why
[22:38:58 CEST] <kierank> ah you need older commit I think
[22:39:35 CEST] <kierank> Needs "    simple_idct: Template functions to support an input bitdepth parameter
[22:39:35 CEST] <kierank> "
[22:40:18 CEST] <durandal_1707> $ git apply .git/rebase-apply/patch
[22:40:18 CEST] <durandal_1707> error: patch failed: libavcodec/idctdsp.c:256
[22:40:18 CEST] <durandal_1707> error: libavcodec/idctdsp.c: patch does not apply
[22:41:10 CEST] <kierank> I dunno how to take patch from past and put on top 
[22:43:34 CEST] <kierank> durandal_1707: try http://paste.ubuntu.com/p/83mZJXyssj/
[22:44:16 CEST] <durandal_1707> kierank: if both patches are on same branch, just do: git format-patch master
[22:44:31 CEST] <kierank> I have both on top now
[22:50:26 CEST] <durandal_1707> kierank: works fine, but its somehow slow on my i3
[22:51:21 CEST] <kierank> wow ffmpeg needs to buy you a faster cpu
[22:53:50 CEST] <atomnuker> durandal_1707: was busy with av1, less so now that it's been "finished", I'll fix atrac9 and review that dca psy patch today or tomorrow
[22:54:26 CEST] <atomnuker> in other news, I have vf_scale_vulkan running, can scale anything->anything and convert anything->rgb (but not back)
[22:54:47 CEST] <durandal_1707> speed versus swscale ?
[22:57:33 CEST] <jamrial> atomnuker: "finished"?
[22:58:21 CEST] <JEEB> -32
[23:01:20 CEST] <Chloe> durandal_1707: your vfrdet filter, shouldnt vfr and cfr be unsigned? Is there any reason for them to be signed?
[23:02:24 CEST] <durandal_1707> no, but arent they huge enough? you have video which would overflow it?
[23:05:20 CEST] <atomnuker> durandal_1707: 2x faster than swscale for an equivalent operation (download from vaapi 4k,nv12 -> swscale 1920x1080,rgba vs map from vaapi 4k,nv12, scale_vulkan 1920x1080,rgba, download from vulkan)
[23:05:39 CEST] <Chloe> I dont have more than two years of 60fps video, but i dont see a reason to not use a uint instead
[23:05:40 CEST] <atomnuker> obviously no CPU used at all if you don't download it
[23:06:12 CEST] <Chloe> durandal_1707: thats my only comment anyway. Filter looks fine though it will need to be updated for new registration format
[23:06:53 CEST] <atomnuker> jamrial: well the hasty press release said finished but the truth is that dead or alive we need to finish this by NAB (which is on saturday?)
[23:07:11 CEST] <atomnuker> till then there's still some things to finalize
[23:07:29 CEST] <kierank> atomnuker: there's still TAPAS to go through
[23:07:36 CEST] <nevcairiel> artificial goals for silly trade shows are so dumb
[23:07:39 CEST] <atomnuker> that doesn't count apparently
[23:07:47 CEST] <jamrial> i know the press release was rushed for marketing purposes and the spec wasn't finished back then. I was wondering why you used quotes right now
[23:08:10 CEST] <atomnuker> one thing on the table is a color range flag added for rgb video (proposed by someone from apple at the last minute)
[23:08:25 CEST] <atomnuker> because someone working in broadcasting wanted it
[23:08:37 CEST] <kierank> not me for once
[23:08:48 CEST] <atomnuker> I objected and so did someone from google so thankfully it doesn't seem likely that'll make it in
[23:08:58 CEST] <atomnuker> because really, that flag would also be used for XYZ
[23:09:02 CEST] <jamrial> monochrome got implicit full range defined in the spec a day ago as well
[23:09:19 CEST] <atomnuker> and what the hell is limited range XYZ defined as?
[23:09:23 CEST] <jamrial> or was it rgb?
[23:09:28 CEST] <atomnuker> we'd have to define it if we could signal it
[23:09:30 CEST] <nevcairiel> the av1 syntax sounds weird, surely you have a yuv range flag, so  is it coding different things based on the color space?
[23:10:21 CEST] <atomnuker> yes we do, but the proposal here was to also signal and define what it means for rgb/xyz
[23:11:33 CEST] <nevcairiel> limited range rgb is sort-of a thing, at least for wire transmission, but probably noone should ever be encoding that
[23:12:56 CEST] <atomnuker> yeah, that's what I responded with
[23:13:40 CEST] <atomnuker> after all, this being a modern codec for the internet implies we shouldn't have support for legacy stuff barely used in the context of video encoding
[23:16:16 CEST] <jamrial> TD-Linux, atomnuker: the changes from aom commit 085095dc19 are not reflected in the spec (https://raw.githubusercontent.com/AOMediaCodec/av1-spec/master/06.bitstream.syntax.md)
[23:17:48 CEST] <atomnuker> debharga will probably do it tomorrow, if not we'll do it, worry not, the spec will somewhat define the codec by the time its deemed ready
[23:17:57 CEST] <jamrial> the ticket is not closed, so i guess such change may be in the queue, yeah
[23:22:37 CEST] <durandal_1707> so nobody is against vfrdet filter idea in codebase?
[23:23:10 CEST] <kierank> durandal_1707: what is vfrdet
[23:28:31 CEST] <durandal_1707> kierank: variable frame rate detector
[23:28:46 CEST] <kierank> how does that work?
[23:28:51 CEST] <kierank> durandal_1707: did my patch apply
[23:30:06 CEST] <jamrial> atomnuker: looks like it was updated just now
[23:31:27 CEST] <durandal_1707> kierank: i told you so already, and i played samples
[23:31:37 CEST] <kierank> durandal_1707: can you lgtm
[23:34:28 CEST] <durandal_1707> kierank: wait, i'm looking at one regression 
[23:34:39 CEST] <kierank> crap
[23:36:43 CEST] <durandal_1707> kierank: not your code :)
[23:36:51 CEST] <kierank> phew
[23:36:52 CEST] <kierank> :)
[23:41:33 CEST] <durandal_1707> kierank: vfrdet checks pts delta
[23:41:51 CEST] <kierank> but what happens for 59.94p in mpegts for example
[23:42:03 CEST] <kierank> or 29.97 in flv
[23:42:09 CEST] <kierank> where it's not really vfr
[23:42:22 CEST] <nevcairiel> if its smart it handles small constant "judder"
[23:44:25 CEST] <nevcairiel> it just logs output anyway, so you would get printouts of the  frame differences and can easily tell that its just inaccurate timings
[00:00:00 CEST] --- Mon Apr  2 2018