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

[burek]

[00:17:18 CET] <Compn> Chloe : hmm wsl confuses me. it sounds like a very specialized elf binary would work, but it would have to be compiled anyways so this is basically just running a linux kernel in userspace ?
[00:17:43 CET] <Compn> but "without any linux kernel code" lol
[00:17:52 CET] <Compn> so its like a linux emulator ?
[00:18:01 CET] <Chloe> Compn: it maps syscalls
[00:18:04 CET] <Chloe> afaik
[00:18:38 CET] <Chloe> wsl does just run windows binaries too (or it should)
[00:18:40 CET] <DHE> "running a linux kernel in userspace" is UML
[00:19:03 CET] <Chloe> so the idea was to be able to test FATE 'natively'
[00:19:54 CET] <Compn> reminds me of colinux
[00:21:28 CET] <kierank> michaelni: is there a reason why i couldn't make the argument to idct_pub void?
[00:22:18 CET] <kierank> is it public api?
[00:23:23 CET] <kierank> idct_put*
[00:30:47 CET] <michaelni> kierank, i dont think its public, so it could be changed to void* ... i think
[00:35:15 CET] <kierank> ok I might do that
[01:11:27 CET] <kierank> seems too much effort actually have to chaange a ton of stuff
[02:54:44 CET] <cone-415> ffmpeg 03Michael Niedermayer 07master:118e1b0b3370: avcodec/utvideodec: Fix bytes left check in decode_frame()
[09:24:33 CET] <volkan> hi everyone 
[09:24:58 CET] <volkan> i have an question about continuously stream2file
[09:25:22 CET] <volkan> i have an audio device who is play. mp2 files on disk 
[09:25:44 CET] <volkan> i wanna create mp2 files and put 1-2sec buffer and write microphone2file 
[09:26:03 CET] <volkan> is it possible
[14:57:44 CET] <Chloe> Could some other people take a look at my add-new-iteration APIs set? Itd be nice to get some input from people other than someone who made a conflicting patch and Nicolas
[15:00:42 CET] <durandal_1707> Chloe: others are very busy folks
[15:01:55 CET] <Chloe> durandal_1707: so I can just push 7 days after patch submit date I guess?
[15:09:31 CET] <atomnuker> just email the ml you'll push after a day if no one objects
[15:10:42 CET] <Chloe> atomnuker: ok
[15:12:06 CET] <wm4> I did that too but CE lashed out anyway
[15:17:19 CET] <durandal_1707> Chloe: if there are no requests for changes, yes
[16:51:55 CET] <hanna> re: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224911.html I'm sure that this patch is still bugged FWIW
[16:52:07 CET] <hanna> I can reproduce A/V desync relatively often with loudnorm active (removing and reinserting fixes it)
[16:52:20 CET] <hanna> but I don't know how to fix it any better
[16:52:45 CET] <hanna> I guess maybe we should compute the delta and always add it to the s->pts?
[16:53:00 CET] <JEEB> is this timestamp discontinuity stuff from the input?
[16:53:10 CET] <JEEB> so you were at PTS 1024 at some point, and suddenly you get PTS 12?
[16:53:11 CET] <hanna> I'm not sure
[16:53:16 CET] <JEEB> (seek f.ex.)
[16:53:23 CET] <hanna> I only observed it when watching e.g. long twitch videos
[16:53:32 CET] <hanna> it's difficult to reproduce for sane files
[16:53:49 CET] <hanna> but near the end of a 2-hour long twitch video it might be several seconds out of sync
[16:53:50 CET] <JEEB> twitch IIRC is HLS, which has MPEG-TS, which has discontinuities
[16:53:54 CET] <JEEB> hmm
[16:53:58 CET] <hanna> then yeah I guess it's that
[16:54:05 CET] <JEEB> but yea, it shouldn't be as quick as 2h
[16:54:17 CET] <JEEB> MPEG-TS discontinuities happen at ~26h
[16:54:31 CET] <JEEB> since the time base is 90000 and the timestamp field is 33bit
[16:54:34 CET] <hanna> ah
[16:54:45 CET] <sfan5> 26:29:40.39 to be exact
[16:54:49 CET] <JEEB> :)
[16:55:07 CET] <JEEB> of course it depends on how high you start muxing with to begin with
[16:55:17 CET] <JEEB> but generally muxers start at zero
[16:56:39 CET] <wm4> a good way is to use the latest PTS you got for input, and add/subtract all buffering
[16:57:07 CET] <wm4> that's still incorrect for timestamp resets, but good enough and will recover quickly
[17:00:46 CET] <hanna> I guess on a timestamp discontinuity you'd correctly need to flush the buffers and reset the filter?
[17:01:05 CET] <hanna> although that also nukes internal state which might make sense to persist after a discontinuity
[17:01:08 CET] <hanna> especially for small ones
[17:01:33 CET] <nevcairiel> if anything it should really just copy input tiemstamps, a simple filter like that really has no business messing with timestamps
[17:01:55 CET] <wm4> if it's something like dynaudnorm that buffers 15 seconds, it could matter, otherwise probably not
[17:02:05 CET] <hanna> it might buffer variable amounts of input
[17:02:19 CET] <wm4> nevcairiel: yeah but those copy all data to an internal ringbuffer, making timestamps hard to track
[17:16:43 CET] <cone-765> ffmpeg 03Muhammad Faiz 07master:caa4bd7a9fe9: avcodec/me_cmp: remove ff_me_cmp_init_static()
[18:31:43 CET] <SortaCore> sup young bois
[00:00:00 CET] --- Tue Feb  6 2018