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

[burek]

[00:35:10 CEST] <DHE> av1 encoder update. it's been ~23 hours. 482 frames in, ~380 frames out. I'm thinking AV1 might make a good codec in a year and then I'll see if it can race this instance with a 365 day head start...
[00:35:33 CEST] <DHE> so if anyone asks about ffmpeg support for av1... yeah about that...
[00:38:33 CEST] <furq> i'll wait for xv1
[00:43:13 CEST] <JEEB> DHE: rav1e last I checked was at over 1000fps for HD, but of course the compression ratios are different :)
[00:43:35 CEST] <JEEB> (rav1e is the alternative encoder made to verify the specification, because that is useful)
[00:45:19 CEST] <furq> In order to build the codec, you need two libraries: wxWidgets 3.0 and yasm.
[00:45:20 CEST] <Johnjay> rav1e
[00:45:20 CEST] <Johnjay> everything has to have a number in its name
[00:45:21 CEST] <furq> what
[00:48:36 CEST] <DHE> the codec is called av1. they put an 'r' and an 'e' on it...
[00:49:41 CEST] <DHE> I can understand yasm for building, but wx isn't forgivable
[00:49:55 CEST] <DHE> also rust?
[00:51:42 CEST] <JEEB> yea another thing for it was to see how good/bad rust was for coding something like that
[00:51:50 CEST] <JEEB> the wx dep is new for me, though
[00:52:05 CEST] <DHE> anyway, this is just satisfying my curiosity... I'm not taking this seriously...
[00:52:31 CEST] <c_14> I couldn't even get libaom to build
[00:52:33 CEST] <c_14> cmake aborts
[00:53:38 CEST] <JEEB> also as they added features it seems like the speed has gone down :) although it does seem to do more of actual coding now, lol
[00:53:49 CEST] <JEEB> and I just asked the author if the wxwidgets dependency is some sort of troll
[00:57:16 CEST] <TD-Linux> furq, that's actually libaom deps, I'll see if I can fix it
[00:58:04 CEST] <TD-Linux> it actually has speed levels now so you can use -s 0 for potatovision of -s 3 for fast potatovision
[01:15:50 CEST] <n000g> Hey guys, I'm trying to convert an NTSC DVD from VOB to MP4, and deinterlace it on the way. With yadif, I get frame stutter. As in every 3-4 frames, a frame is shown twice. I think I somehow fixed that before, but can't remember how. Any ideas? I was unsuccessful on the search engine...
[01:16:11 CEST] <furq> it sounds like you want to IVTC, not deinterlace
[01:18:12 CEST] <n000g> Yes, I think that might be what I did!
[01:18:21 CEST] <n000g> I'll look into that, thanks!
[01:20:09 CEST] <furq> -vf fieldmatch,yadif=deint=interlaced,decimate
[01:20:32 CEST] <furq> there are many ways of doing it but that one's recommended now afaik
[01:21:33 CEST] <n000g> fieldmatch=order=tff:combmatch=full, yadif=deint=interlaced, decimate
[01:21:43 CEST] <n000g> That's what I tried now and it looks awesome!
[01:22:09 CEST] <n000g> It was the one on the filters documentation.
[01:22:16 CEST] <n000g> Thank you, furq!
[05:21:52 CEST] <spot> msg NickServ SET HIDEMAIL ON
[11:45:43 CEST] <kerio> does anyone know of a python wrapper for libav?
[11:46:04 CEST] <kerio> right now i'm shelling out to the ffmpeg command line
[11:46:14 CEST] <kerio> which is somewhat silly, if workable
[11:49:53 CEST] <liyou> 111
[12:50:04 CEST] <tal_> Hi all, I am trying to combine 2 commands execution with ffmpeg CLI into one command and would like to get some help. I am trying to both encode some raw video stream to H264 into segmented files AND that the files will be encrypted. I have here the 2 seprate commands i have used to do each operation (https://pastebin.com/KN0vscLX). thanks ahead!
[12:51:38 CEST] <dragmore88> Anyone know of a free/opensource frameaccurate mpeg2TS trim/cutter/editor?
[13:59:03 CEST] <DHE> tal_: just repeat everything after the input filename...
[14:01:25 CEST] <DHE> tal_: https://pastebin.com/PWh7VhV2  like this... though this isn't very efficient since you are transcoding the video twice.
[14:26:24 CEST] <tal_> DHE: tried it but my fragmented files are not encrypted
[14:42:46 CEST] <kiloreux> How can I cut only the first 10 frames of a video ?
[14:43:01 CEST] <kiloreux> I meant extract the first 10 frames as a video.
[14:44:43 CEST] <sfan5> ffmpeg -i video.mp4 -an -vframes 10 -f image2 "frame%02d.png"
[14:45:01 CEST] <kiloreux> I want the output to be a video. Not images.
[14:45:07 CEST] <kiloreux> A 10 frames video :/
[15:03:09 CEST] <atbd> hi, i'm trying to transcode a video and audio stream but i have a sync issue. The video stream stays the same but audio is resampled, after the resampling my audio is delayed by ~2sec. I tried to use av_compare_ts but without success... To compute the frame pts for video i follow the frame number, for audio i add the nb_samples. Somebody could help me to find my mistake?
[15:03:42 CEST] <BtbN> you'll need to take the original timestamps into account instead of just making up new ones
[15:04:44 CEST] <atbd> that was my first attempt but i had issue with frames extracted from swr_convert buffer. My stream was laggy
[15:40:47 CEST] <atbd> there is others useful functions to synchronise besides av_compare_ts?
[15:46:49 CEST] <BtbN> like I said, Don't throw away the original timestamps. They are the _only_ way to sync them.
[16:11:51 CEST] <atbd> okay thanks, i'll look in this direction
[16:34:38 CEST] <dragmore88> anyone know how to parse an AVI file and result with the total frames for the video ?
[16:36:47 CEST] <alexpigment> dragmore88: have you tried any of these methods? https://stackoverflow.com/questions/2017843/fetch-frame-count-with-ffmpeg
[16:37:26 CEST] <dragmore88> yes, they just time out, or result with nothing
[16:37:36 CEST] <dragmore88> its a FFV1.3 in a AVI container
[16:37:52 CEST] <dragmore88> i need to compare 4 files, that they have the same amount of frames
[16:38:10 CEST] <alexpigment> gotcha. if those methods don't work, then I'm not sure
[16:40:12 CEST] <dragmore88> when im trying the first method, ffprobe only uses like 5% cpu time and a tiny bit of my SSD raids performance.. not sure why its so slow
[16:40:54 CEST] <dragmore88> it seems that ffprobe is singlethreaded?
[16:42:36 CEST] <alexpigment> well, singlethreaded or not, querying the container should be fast
[16:42:44 CEST] <alexpigment> did you try with mediainfo?
[16:43:14 CEST] <dragmore88> yes, and im getting wildly different framecounts..
[16:43:19 CEST] <dragmore88> i cut the files in avidemux
[16:43:29 CEST] <dragmore88> so they should be frame accurate
[16:43:30 CEST] <alexpigment> ah, avidemux :)
[16:43:48 CEST] <alexpigment> that program has never done anything that i would consider paying for. my 2 cents
[16:43:50 CEST] <dragmore88> couldnt find any other frame cutter that supported ffv1
[16:50:23 CEST] <atbd> the time_base of AVFrame->pts is from AVCodecContext or AVStream?
[16:51:39 CEST] <alexpigment> dragmore88: i just double checked an my smart cutter application of choice - VideoReDo - supports FFV1. of course, smartcutting is not necessary in this context, but at least it's a program that I use daily in a professional environment and trust
[16:52:58 CEST] <DHE> atbd: a "Frame" doesn't belong in an AVStream, so it would be the codec context's time base
[16:55:26 CEST] <dragmore88> alexpigment: ill check it
[16:56:04 CEST] <atbd> DHE: thanks
[16:56:30 CEST] <dragmore88>  alexpigment tv suite or plus ?
[16:56:41 CEST] <alexpigment> i use tv suite
[16:56:44 CEST] <alexpigment> i think
[16:56:48 CEST] <dragmore88> ok
[16:56:51 CEST] <dragmore88> i only need to cut
[16:56:53 CEST] <alexpigment> yep. tvsuite v5
[16:57:10 CEST] <dragmore88> and save withouth any tampering with the ES layer
[17:08:53 CEST] <dragmore88> anyone know of a ffmpeg build that is statically compiled with VMAF support including support libraries?
[17:09:50 CEST] <durandal_1707> dragmore88: on windows?
[17:10:13 CEST] <dragmore88> yupp
[17:10:39 CEST] <dragmore88> im gonna do some SSIM, PSNR and VMAF objective tests on some video encoders
[17:51:24 CEST] <primitivist> is there anything special about -r to drop frames? does it simply remove frames in a uniform manner so that the fps matches? just looking for any documentation on the algorithm
[19:12:46 CEST] <kepstin> primitivist: it's a not particularly smart thing, i'm not sure how exactly it works.
[19:13:07 CEST] <kepstin> primitivist: I recommend using the fps filter instead, it has configurable rounding behaviour and generally gives better results
[19:32:10 CEST] <kevinnnnnnnnn> Hi all, I am getting strange artifacts when using x264 and I am fairly sure that my source does not have these artifacts. Can anyone give me some pointers as to what could be causing these artifacts?
[19:32:17 CEST] <kevinnnnnnnnn> here is an example: https://imgur.com/a/K7IiV
[19:34:53 CEST] <klaxa> quite the tear, what's the source? also pastebin (use pastebin.com or whatever) to show the exact command you used + output
[19:34:55 CEST] <klaxa> !pastebin
[19:35:00 CEST] <klaxa> !paste
[19:35:02 CEST] <klaxa> hmm
[19:35:36 CEST] <klaxa> anyway, my first guess would be it was incorrectly deinterlaced during decoding
[19:36:00 CEST] <klaxa> but without more input than a screenshot from the result there is nothing to do but speculate
[19:36:51 CEST] <kevinnnnnnnnn> klaxa: okay give me a sec
[19:38:16 CEST] <kevinnnnnnnnn> klaxa: here's my tuning: https://pastebin.com/dnWA0ux9 (I am not using a command, I programmed this using c++)
[19:38:33 CEST] <kevinnnnnnnnn> And I grab the screen using this: XShmGetImage
[19:41:29 CEST] <kevinnnnnnnnn> So the source is x11
[19:43:12 CEST] <atomnuker> if the image updates while you're encoding it then yeah, you'll get tearing
[19:43:42 CEST] <kevinnnnnnnnn> atomnuker: does XShmGetImage not account for that?
[19:44:05 CEST] <kevinnnnnnnnn> because I know ffmpeg's x11grab uses XShmGetImage to get the x11 screen
[19:44:31 CEST] <alexpigment> why are you encoding as 25fps?
[19:44:51 CEST] <debianuser> kevinnnnnnnnn: Do you get the same artifacts if you capture with ffmpeg command line? If not - just look at the x11grab implementation in ffmpeg and use that. :)
[19:45:01 CEST] <atomnuker> kevinnnnnnnnn: are you on nvidia?
[19:45:27 CEST] <kevinnnnnnnnn> debianuser: okay let me try via the commandline and see if I get the same artifacts
[19:45:31 CEST] <alexpigment> at any rate, it's at least best that you match the monitor rate, which is presumably 60hz
[19:45:40 CEST] <kevinnnnnnnnn> atomnuker: no I am not on nvidia
[19:45:41 CEST] <alexpigment> and if you need to half that, then go to 30fps
[19:46:24 CEST] <kevinnnnnnnnn> alexpigment: I think I already have that tuned right?
[19:46:31 CEST] <atomnuker> dunno then, you could use kmsgrab which is guaranteed to not tear (but you'll need to be a superuser)
[19:47:08 CEST] <alexpigment> maybe i'm just confused at what i'm looking at. your fps is 25. i would try 30 and see if the tearing goes away
[19:47:30 CEST] <alexpigment> i would think you would just get frame drops (and therefore judder), but tearing is another possible outcome i guess
[19:48:28 CEST] <alexpigment> and i guess if you want to keep a 2 second GOP, change the keyint max to 60
[19:49:08 CEST] <colekas> hello friends, I'm trying to transcode a multicast stream, and when I probem the output stream, ffprobe fails to find some of the codec parameters
[19:49:12 CEST] <kevinnnnnnnnn> alexpigment: hmm okay let me adjust that too and see if it looks any better
[19:49:28 CEST] <colekas> instead of increasing the probesize and analyzeduration, I was curious if there was anything I could do on the transcode side?
[19:49:36 CEST] <kevinnnnnnnnn> atomnuker: let me look into that and see if I can't figure it out
[19:49:36 CEST] <colekas> I'm uxing libx264 + ultrafast + zerolatency
[19:51:14 CEST] <primitivist> kepstin: thank you
[19:52:22 CEST] <alexpigment> kevinnnnnnnnn: the other thing could be that this tearing is happening on playback, which would again point to a problem with trying to align 25fps with the native display refresh rate. although good players and good graphics card drivers would fix that
[19:53:37 CEST] <kevinnnnnnnnn> alexpigment: okay, I see, but I outputted that frame using ffmpeg -i ../video.x264 image%d.jpg. Wouldn't ffmpeg account for that?
[19:54:31 CEST] <alexpigment> well, that would seem to rule out a playback problem
[19:54:44 CEST] <alexpigment> still could be related to encoding at 25fps though
[19:54:55 CEST] <atomnuker> no it isn't
[19:55:09 CEST] <alexpigment> or take atomnuker's word
[19:55:22 CEST] <kevinnnnnnnnn> atomnuker: how do you figure that it isn't a play back issue?
[19:56:14 CEST] <atomnuker> could be a playback issue if it occurs with other videos
[19:56:46 CEST] <kevinnnnnnnnn> atomnuker: any video I play has occasional tears in it like this
[19:56:53 CEST] <alexpigment> all i know is that tearing is almost always caused by a difference in frame rate and refresh rate. it can be mitigated through a frame buffer
[19:57:53 CEST] <kevinnnnnnnnn> alexpigment: well I do capture the frame using x11grab about 60 times a second (60fps)
[19:58:08 CEST] <alexpigment> then encode to 25fps?
[19:58:40 CEST] <kevinnnnnnnnn> alexpigment: okay... wait why?
[19:58:56 CEST] <kevinnnnnnnnn> didn't you just suggest 30fps?
[19:59:06 CEST] <alexpigment> yeah, i was asking a question
[19:59:09 CEST] <alexpigment> not suggestion you do that
[19:59:13 CEST] <alexpigment> that's what i saw in your pastebin
[19:59:26 CEST] <alexpigment> so are you saying that the problem still happens when changing those values to 60 (or 30)?
[20:00:23 CEST] <kevinnnnnnnnn> alexpigment: yes I've messed around with these variables a bit and it is always tearing
[20:00:30 CEST] <alexpigment> gotcha
[20:01:03 CEST] <alexpigment> and you've installed the latest graphics card drivers, presumably?
[20:02:06 CEST] <alexpigment> for example, in the past when i play a video on a system with the base generic graphics driver (on windows), i've see the same tearing
[20:02:33 CEST] <alexpigment> then again, just moving a window on the screen looks laggy as hell without a proper driver :)
[20:03:08 CEST] <alexpigment> anyway, that's the last idea i have, so i'll be quiet now
[20:03:50 CEST] <alexpigment> (oh and also check to make sure your monitor is actually running at 60hz)
[20:03:54 CEST] <kevinnnnnnnnn> alexpigment: hmm, you think it is a driver issue?
[20:04:01 CEST] <kevinnnnnnnnn> Well the thing is...
[20:04:08 CEST] <kevinnnnnnnnn> there is no monitor
[20:04:08 CEST] <alexpigment> i'm ruling out factors one by one
[20:04:17 CEST] <kevinnnnnnnnn> I am running on a headless machine
[20:04:25 CEST] <kevinnnnnnnnn> the x11 instance is just Xdummy
[20:04:26 CEST] <alexpigment> ah
[20:04:31 CEST] <kevinnnnnnnnn> and I am running a video on it
[20:04:34 CEST] <kevinnnnnnnnn> capturing it
[20:04:39 CEST] <kevinnnnnnnnn> and then exporting it
[20:04:48 CEST] <alexpigment> i wonder if there's a native refresh that's different on a headless setup
[20:04:50 CEST] <kevinnnnnnnnn> using ffmpeg and looking at what was rendered
[20:05:01 CEST] <kevinnnnnnnnn> hmm
[20:05:07 CEST] <kevinnnnnnnnn> I am not sure if there is
[20:05:46 CEST] <alexpigment> if you run xrandr, does it give you resolutions and refresh rates?
[20:05:57 CEST] <alexpigment> just on a command line, i mean
[20:06:04 CEST] <kevinnnnnnnnn> let me see
[20:07:47 CEST] <alexpigment> so you could presumably do xrandr -s [resolution] -r [refresh rate]
[20:07:47 CEST] <kevinnnnnnnnn> it does show resolutions
[20:07:59 CEST] <alexpigment> just make sure it's set to a -r of 60
[20:08:19 CEST] <alexpigment> and not 75
[20:08:46 CEST] <kevinnnnnnnnn> okay when I did xrandr it showed my resolution but there wasn't anything next to it
[20:08:54 CEST] <alexpigment> weird
[20:09:03 CEST] <kevinnnnnnnnn> no refresh rate, but the other resolutions did have refresh rates next to it
[20:09:33 CEST] <alexpigment> well, is it possible to force one?
[20:09:50 CEST] <kevinnnnnnnnn> hmm, okay let me see
[20:17:34 CEST] <kevinnnnnnnnn> alexpigment: Ya I can't set the resolution...
[20:17:39 CEST] <kevinnnnnnnnn> I don't know why
[20:18:29 CEST] <alexpigment> ok
[20:18:49 CEST] <alexpigment> well, if it gets to the point where you're still getting tearing, you might want to just hook up a monitor and see if the tearing still happens
[20:19:17 CEST] <alexpigment> still could be graphics driver related though
[20:19:33 CEST] <alexpigment> but i have zero experience capturing headless
[20:20:46 CEST] <kevinnnnnnnnn> alexpigment: okay thanks, I am going to try debianusers suggestion and see if ffmpeg x11grab also has the same tearing as I do
[20:20:59 CEST] <kevinnnnnnnnn> In which case I think this would be an actual bug in ffmpeg
[20:21:43 CEST] <alexpigment> sounds good
[20:33:22 CEST] <kevinnnnnnnnn> debianuser: hey! so I recorded using ffmpeg's x11grab
[20:33:28 CEST] <kevinnnnnnnnn> and there are tears here too
[20:33:45 CEST] <kevinnnnnnnnn> I wonder how no one else has stumbled upon this yet
[20:34:17 CEST] <kevinnnnnnnnn> alexpigment: there are tears in ffmpeg's stream too!
[20:35:09 CEST] <kevinnnnnnnnn> here's the ffmpeg command I used:
[20:35:10 CEST] <alexpigment> ok, well i guess it's time to plug a monitor into it, so it forces a refresh rate of 60 (or 59), then see what happens
[20:35:12 CEST] <kevinnnnnnnnn> ffmpeg -s 1920x1080 -framerate 30 -f x11grab -i :1 -c:v libx264 -preset veryfast -tune zerolatency -pix_fmt yuv444p -x264opts crf=20:vbv-maxrate=3000:vbv-bufsize=100:intra-refresh=1:slice-max-size=1500:keyint=30:ref=1 output.mp4
[20:35:29 CEST] <kevinnnnnnnnn> ahh, well there's a problem with that too
[20:35:35 CEST] <kevinnnnnnnnn> it's a VPS
[20:35:45 CEST] <kevinnnnnnnnn> so... I am not sure there is a way to do that
[20:35:55 CEST] <alexpigment> ah
[20:36:15 CEST] <alexpigment> did you try just doing xrandr -r 60 earlier?
[20:36:26 CEST] <alexpigment> i know you said you couldn't force a resolution, but maybe you could force a refresh rate
[20:36:53 CEST] <kevinnnnnnnnn> no no I couldn't force a refresh rate
[20:37:05 CEST] <kevinnnnnnnnn> I can force any resolution I want
[20:37:12 CEST] <alexpigment> i see
[20:37:28 CEST] <alexpigment> well, maybe try updating the driver
[20:37:37 CEST] <kevinnnnnnnnn> the graphics driver?
[20:37:40 CEST] <alexpigment> yeah
[20:38:00 CEST] <kevinnnnnnnnn> hmm, how can I do that?
[20:38:28 CEST] <alexpigment> i don't have much experience with VPS, but is it using a physical card driver or a virtual driver?
[20:38:35 CEST] <kevinnnnnnnnn> I am running through this: https://xpra.org/trac/wiki/Xdummy
[20:38:40 CEST] <kevinnnnnnnnn> so it is a virtual driver
[20:38:53 CEST] <kepstin> you might consider using Xvfb instead
[20:39:07 CEST] <kepstin> which is a dedicated virtual x server, rather than an x server with a virtual driver
[20:39:24 CEST] <alexpigment> does it have a frame buffer?
[20:39:38 CEST] <kevinnnnnnnnn> kepstin: out of curiosity why? Isn't xvfb depreciated?
[20:39:41 CEST] <kepstin> Xvbf stands for "X virtual frame buffer"
[20:39:42 CEST] <alexpigment> oh vfb stands for virtual frame buffer :)
[20:39:55 CEST] <alexpigment> yeah, then a frame buffer should solve the tearing
[20:39:56 CEST] <kepstin> dunno, I've just found it works well when i've used it previously
[20:40:21 CEST] <kevinnnnnnnnn> alexpigment: the framebuffer will solve tearing? how so?
[20:40:45 CEST] <alexpigment> tearing occurs when the rates don't match. frame buffers are used to fix that
[20:41:35 CEST] <alexpigment> for example, if a video game on a PC drops below 60fps, it *should* tear
[20:41:40 CEST] <alexpigment> but they have frame buffers
[20:41:55 CEST] <kevinnnnnnnnn> alexpigment: right, I actually used to use Xvfb, and I switched to xdummy, but if I recall I was also having issues with tearing... let me see if I can revert to that older code again
[20:42:13 CEST] <kepstin> you're confusing different terms, tearing is caused by single buffering, and can be solved by e.g. double-buffered output
[20:42:20 CEST] <kevinnnnnnnnn> basically what I was doing was I mmap'ing the framebuffer file and copying it out every time I wanted to capture the frame
[20:42:40 CEST] <kepstin> you should be able to just use -f x11grab on the Xvfb server
[20:43:05 CEST] <kevinnnnnnnnn> but even a mmap'ed framebuffer what if I copy out while xvfb is writing to the framebuffer? Wouldn't it result in the same tearing?
[20:43:27 CEST] <kepstin> don't copy the mmaped frame buffer. Get the display via the X protocol - e.g. with x11grab
[20:44:53 CEST] <kevinnnnnnnnn> kepstin: you mean with something like XShmGetImage?
[20:45:22 CEST] <kepstin> ... or ffmpeg -f x11grab
[20:45:59 CEST] <kevinnnnnnnnn> kepstin: okay let me try that
[20:46:00 CEST] <kepstin> I don't know if that will actually solve tearing issues, but I don't recall seeing them when I was using Xvfb and ffmpeg -f x11grab to screencap applications before
[20:46:04 CEST] <kepstin> your milage may vary
[20:48:04 CEST] <alexpigment> kepstin: sorry, you're right. double buffering was exactly what i was thinking of. a frame buffer is required for that, but it's also required for single buffering too
[20:48:40 CEST] <kepstin> the number of X drivers that do double-buffering for classic 2d applications is very small
[20:48:53 CEST] <kepstin> iirc, with weird options you could force it on the nvidia and intel drivers
[20:49:25 CEST] <alexpigment> i'm in windows world, so fortunately i don't deal with any of this on a regular basis :)
[20:49:49 CEST] <kepstin> the solution to this in linux is - like in windows - to run a compositing manager that double-buffers the window rendering
[20:49:59 CEST] <alexpigment> like compiz?
[20:50:00 CEST] <debianuser> kevinnnnnnnnn: By the way, does the tearing happen only inside the app, or can you also see it if you capture the window moving? Something like this: https://a.uguu.se/v4sWaUCjoIgr.flv If you see "tearing" in the app, but not while you move the window - it's the app-specific issue. If you see tearing when moving the window too - it's xserver-related or driver-related.
[20:50:51 CEST] <kepstin> compiz is a fancy opengl compositing manager, but a 2d one like xcompmgr works too, or the ones builtin to modern versions of gnome and kde
[20:52:22 CEST] <kepstin> I don't know if any of these would work on a virtual framebuffer or dummy driver, since most compositing managers want the render extension or opengl :/
[20:53:08 CEST] <kevinnnnnnnnn> debianuser: hmm, I don't think it extends outside the app. At least I haven't see it do so yet. But the app I am running is google chrome to view the videos. I hardly think google chrome is at fault
[20:53:32 CEST] <kevinnnnnnnnn> kepstin: Unfortunately the results are the same whether it be xvfb or xdummy
[20:53:34 CEST] <alexpigment> well, chrome is definitely not infassible
[20:53:39 CEST] <alexpigment> *infallible
[20:53:43 CEST] <kepstin> hmm, i've had google chrome do tearing when watching flash videos on real displays
[20:53:46 CEST] <alexpigment> and it uses gpu acceleration by default
[20:53:57 CEST] <alexpigment> there's an acceleration checkbox in the chrome settings
[20:54:02 CEST] <alexpigment> might be worth just toggling that
[20:54:13 CEST] <kevinnnnnnnnn> okay let me run the test using firefox and iceweasle
[20:54:24 CEST] <kepstin> none of the acceleration would work in xvfb or xdummy, so I'd expect it to disable itself.
[20:54:37 CEST] Action: debianuser thinks it's a rather complex way to capture videos : ffmpeg-capture them played in chrome on a headless server.
[20:54:40 CEST] <kevinnnnnnnnn> I think that will probably fully address whether or not it is an app specific problem
[20:54:45 CEST] Action: debianuser 'd use youtube-dl...
[20:54:49 CEST] <alexpigment> yeah, i just don't know how it would interact with a dummy driver. i.e. does it turn the checkbox off?
[20:55:09 CEST] <kepstin> alexpigment: probably leaves the checkbox on and prints a warning log message or something :)
[20:55:22 CEST] <kepstin> in firefox they called the checkbox "use accelleration when available" so it's more clear
[20:55:31 CEST] <alexpigment> yeah i remember it was more verbose
[20:58:12 CEST] <debianuser> kevinnnnnnnnn: You can attach to a remotely running xserver with x11vnc (literally run `x11vnc`, that'd start a vnc server on a 5900 port, I think), and then connect to it with any vnc-client (krdc, remmina-plugin-vnc, etc.)
[20:59:12 CEST] <kevinnnnnnnnn> debianuser: hmm, do you think that'll produce different results from x11-grab with ffmpeg?
[20:59:13 CEST] <debianuser> kevinnnnnnnnn: vnc is probably not fast enough to notice the tearing, but you can use it to try some settings, move windows around, and capture the result.
[21:02:42 CEST] <kevinnnnnnnnn> kepstin: firefox is tearing too
[21:02:59 CEST] <kevinnnnnnnnn> kepstin: I got it to tear when just moving the window
[21:03:14 CEST] <kevinnnnnnnnn> debianuser: I got it to tear when I move the window
[21:03:24 CEST] <kevinnnnnnnnn> using x11grab with ffmpeg
[21:04:26 CEST] Action: alexpigment tends to agree with debianuser that this is a really roundabout way to do this :)
[21:10:54 CEST] <utack> what can I do when i have a package installed from aur, but ffmpeg configure says "not found using pkg-config
[21:10:54 CEST] <utack> "
[21:13:19 CEST] <debianuser> kevinnnnnnnnn: You can try running a composition wm there, i.e. run `xcompmgr -c -f` in terminal and see what it says: it'd either start (and then you can kill it with Ctrl+C) or print some error. If it starts (unlikely) you can try capturing some windows moving with ffmpeg and see if you can see tearing then.
[21:14:27 CEST] <debianuser> kevinnnnnnnnn: Also if what you're really trying to do is to save some videos from the web: check out youtube-dl. :)
[21:21:06 CEST] <kevinnnnnnnnn> debianuser: ya I can't get the xcompmgr to work... basically my use case here is not to just record videos online. I want to create a remote desktop app
[21:21:13 CEST] <utack> i uploaded the log here, maybe someone understands why it fails https://paste.ubuntu.com/p/hrtcmCwqrT/
[21:22:32 CEST] <kevinnnnnnnnn> alexpigment: ya I know this is a round about way to do this but it really seems like this is an issue with ffmpeg
[21:25:50 CEST] <utack> pkg-config actually works, it tells aom exists and is at least the required version
[21:27:25 CEST] <alexpigment> just for a quick google search you probably just forgot to link the pthread library
[21:30:48 CEST] <utack> alexpigment i did not write any of that code, just wondering why configure fails
[21:30:53 CEST] <alexpigment> ah
[21:31:28 CEST] <alexpigment> well, "undefined refrence to 'pthread_once" and the other two seem to be associated with not linking to pthread properly
[21:31:45 CEST] <alexpigment> so i'm not sure where the problem would be
[21:31:58 CEST] <c_14> utack: --extra-ldflags='-lpthread'
[21:32:05 CEST] <debianuser> kevinnnnnnnnn: `xcompmgr` needs a "Composite" extension, is that enabled? You can see the list of available extensions in `xdpyinfo` output. If it's not there you probably have to enable it, https://xpra.org/trac/ticket/56 and https://xpra.org/trac/wiki/Xdummy mention `Xvfb +extension Composite ...` and `Xorg -dpi 96 +extension GLX +extension RANDR +extension RENDER ...` Maybe those could help.
[21:32:19 CEST] <c_14> utack: the .pc file is probably borked/incorrect
[21:33:44 CEST] <utack> aaah yes, now configure goes through c_14
[21:33:46 CEST] <utack> thank you!
[21:34:45 CEST] <kevinnnnnnnnn> debianuser: okay let me try and enable that. Also  I made an interesting discovery. even though ffmpeg shows tears throughout the video this app doesn't in its recording: http://www.maartenbaert.be/simplescreenrecorder/. I've been scrubbing the code but I can't find any thing in it that is different than mine when it comes to capturing the screen. Look here: https://raw.githubusercontent.com/MaartenBaert/ssr/master/src/AV/Input
[21:36:31 CEST] <alexpigment> your link is incomplete
[21:36:38 CEST] <kevinnnnnnnnn> debianuser: there is some strange sleep code in function InputThread that I don't have but would that be causing tears in my code and ffmpeg?
[21:37:10 CEST] <kevinnnnnnnnn> alexpigment: which one?
[21:37:26 CEST] <alexpigment> the github one
[21:37:45 CEST] <kevinnnnnnnnn> https://github.com/MaartenBaert/ssr/blob/master/src/AV/Input/X11Input.cpp
[21:37:49 CEST] <kevinnnnnnnnn> how about that
[21:38:32 CEST] <alexpigment> yeah that works
[21:39:02 CEST] <kevinnnnnnnnn> alexpigment: ya take a look, this code for some reason works...
[21:39:09 CEST] <kevinnnnnnnnn> but ffmpeg and my code doesn't
[21:42:24 CEST] <debianuser> kevinnnnnnnnn: Looks like XShmGetImage/XGetImage too... and it's based on "x11grab.c" :) Does it use XShmGetImage or XGetImage by the way? I.e. does it print "Using X11 shared memory" or "Not using X11 shared memory"?
[21:43:31 CEST] <kevinnnnnnnnn> it prints "Using X11 shared memory"!
[21:43:57 CEST] <kevinnnnnnnnn> And my code looks so similar to what this guy is doing... I don't get why his is recording cleanly
[21:47:04 CEST] <kevinnnnnnnnn> debianuser
[21:49:21 CEST] <debianuser> kevinnnnnnnnn: Yeah, I don't know either. Maybe it was just a coincidence? Test it again. Both your code and ssr. Maybe ssr is tearing too, you just didn't notice that. Or some of your changes fixed it and your code works now too...
[21:50:51 CEST] <kevinnnnnnnnn> debianuser: okay and that pause code has no real significance? I know alexpigment kept suggesting it has something to do with framerate and stuff
[21:56:03 CEST] <debianuser> kevinnnnnnnnn: I don't know, it's just a guess. :) That sleep code looks like a regular framerate limiter, a better version of usleep(1000000/framerate)
[21:56:33 CEST] <kevinnnnnnnnn> debianuser: ya I know I figured that
[21:57:03 CEST] <kevinnnnnnnnn> debianuser: mine is still tearing unfortunately...
[22:00:19 CEST] <lkiesow> In the command line: ffmpeg -f concat -safe 0 -i mylist.txt -c copy output
[22:00:23 CEST] <lkiesow> Does anyone know what the `-safe 0` is supposed to do?
[22:00:28 CEST] <lkiesow> Can't find it in the docs right now
[22:01:35 CEST] <durandal11707> lkiesow: it steals your passwords
[22:02:46 CEST] <alexpigment> i want to say it has something to do with a security thing and "unsafe file names"
[22:02:49 CEST] <lkiesow> durandal11707: good answer ;-P
[22:03:19 CEST] <alexpigment> and basically safe 0 overrides those security settings
[22:03:32 CEST] <alexpigment> this is all from what i can remember because i'm not seeing it in the source code
[22:04:07 CEST] <alexpigment> https://www.ffmpeg.org/ffmpeg-formats.html#Options
[22:04:13 CEST] <alexpigment> there it is
[22:05:12 CEST] <lkiesow> alexpigment: Thanks!
[22:05:23 CEST] <alexpigment> so i guess it's just a way to avoid running into errors due to characters in the file name
[22:05:24 CEST] <alexpigment> np
[22:05:33 CEST] Action: lkiesow is just reviewing a pull request for Opencast where that is included by default
[22:05:47 CEST] Action: lkiesow thinks it shouldn't be included by default :D
[22:10:41 CEST] <kepstin> if you are playing arbitrary playlists off the internet, you should not use -safe 0
[22:10:57 CEST] <kepstin> if you are playing playlists that you built yourself with files you put there, then it's fine
[22:21:53 CEST] <dragmore88> hmm.. anyone know if --ss is deprecated in ffmpeg 3.4.2 ? Cant get : "I:\ffmpeg.exe -i --ss 00:05:00.000 e:\output2.mov -t 5 -c copy i:\test1.mov" to work..
[22:23:39 CEST] <kepstin> dragmore88: all ffmpeg options start with a single -
[22:24:04 CEST] <kepstin> dragmore88: but you have other issues with that command too,
[22:24:27 CEST] <kepstin> right now you have "-i --ss" which means "try to open a file named --ss as an input"
[22:25:07 CEST] <kepstin> dragmore88: correct command is "ffmpeg -ss 00:05:00.000 -i e:\output2.mov [...]"
[22:25:50 CEST] <kepstin> note that the -ss option is before the -i. All options affecting a specific input go before the -i for that input
[22:25:50 CEST] <dragmore88> ure right, me stupid
[22:25:55 CEST] <dragmore88> thx
[22:25:57 CEST] <dragmore88> tired ;)
[22:41:45 CEST] <utack> well ffmpeg needs a new unit if it wants to deal with libaom: "fps=0.0"
[22:41:56 CEST] <utack> frames per decade maybe
[22:43:26 CEST] <alexpigment> weird
[22:43:31 CEST] <alexpigment> where is that being reported?
[22:45:39 CEST] <furq> probably in the statusline
[22:45:55 CEST] <furq> libaom is genuinely that slow right now
[22:46:51 CEST] <alexpigment> oh, right
[22:46:52 CEST] <furq> i think DHE was running a 1080p test encode with it and got 500 frames out in 24 hours
[22:47:06 CEST] <alexpigment> haha
[22:47:27 CEST] <alexpigment> i feel like the world keeps on trying to get video more and more efficient
[22:48:01 CEST] <alexpigment> let's just stick with h.264 for a while and work on improving internet speeds and storage sizes :)
[22:48:43 CEST] <alexpigment> HEVC even seems unnecessary to me
[22:48:59 CEST] <furq> aom is a beta reference encoder, you'd expect it to be unbelievably slow
[22:49:15 CEST] <furq> ffmpeg supporting it is a bit of a red herring really
[22:49:31 CEST] <alexpigment> well, true, but is there any chance it will ever be close to the speed of h.264?
[22:49:50 CEST] <furq> probably not but there'll be av1 encoders that are orders of magnitude faster
[22:50:00 CEST] <furq> there already is one
[22:50:08 CEST] <furq> it's not very efficient though
[22:50:20 CEST] <alexpigment> so an order of magnitude greater than 0.0fps is? :)
[22:50:47 CEST] <furq> i think DHE was getting 0.02fps
[22:51:04 CEST] <furq> i said "orders" so let's say 2fps
[22:51:42 CEST] <alexpigment> i think i'll just stick with h.264 for a while then
[22:52:14 CEST] <furq> google have said they're planning to adopt av1 six months after the bitstream freeze
[22:52:23 CEST] <furq> so you've got at least six and a half months before anyone else is using it
[22:53:09 CEST] <alexpigment> anyone wanna take bets on when intel/nvidia/amd add hardware support?
[22:53:11 CEST] <kepstin> i'd expect that eventually there might be an encoder that is as fast as x264, which gets that way by dropping efficiency so it's not any better than x264.
[22:53:36 CEST] <kepstin> alexpigment: I'd expect around 18 months from when the spec is frozen
[22:53:52 CEST] <furq> hardware will exist within a year
[22:54:08 CEST] <furq> but it'll probably be another year after that before enough people have it to make it viable to support it
[22:54:17 CEST] <alexpigment> what kind of performance is expected on decoding?
[22:54:29 CEST] <alexpigment> on the cpu, i mean
[22:54:40 CEST] <alexpigment> like is it a codec that is a non-starter until hardware is present?
[22:55:25 CEST] <utack> alexpigment yep statusline
[22:55:26 CEST] <kepstin> I'd expect the decoder complexity to be not far off from hevc?
[22:56:01 CEST] <alexpigment> ok, so feasible on a modern desktop CPU, iffy on mobile
[22:56:25 CEST] <utack> some article was throwing around numbers saying 2x vp9 requirements to decode
[22:56:29 CEST] <utack> is the goal for end of this year
[22:56:59 CEST] <furq> it's probably impossible to say until the bitstream is frozen
[22:57:05 CEST] <furq> i've heard all sorts of numbers thrown around
[22:57:38 CEST] <kepstin> iirc there's some new features that do add some decoder complexity over vp9, like cdef
[22:57:52 CEST] <utack> and all sorts of comparisons too. depending on who you ask it is either 30% more or less efficient than H265...
[22:57:56 CEST] <kepstin> but as for speed, well? who knows.
[22:58:34 CEST] <utack> i hope frame parallel encoding is added in the next year, but who knows
[22:59:32 CEST] <alexpigment> "Tests from Netflix showed that, based on measurements with PSNR and VMAF at 720p, AV1 could be about 25% more efficient than VP9 (libvpx), at the expense of a 410 fold increase in encoding complexity."
[23:00:09 CEST] <alexpigment> "The researchers found that the used AV1 encoder was operating at a speed 25003500 times lower than competitors, while admitting that it has not been optimized yet."
[23:00:57 CEST] <furq> i've never tried the hevc reference encoder but i assume it's not much faster than aom right now
[23:11:28 CEST] <utack> alexpigment so that would mean back then it was as efficient as x265 http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx
[23:11:40 CEST] <utack> let's hope the stuff aded since then moves it a notch higher
[23:13:30 CEST] <alexpigment> hopefully so
[23:14:53 CEST] <DHE> furq: less, actually. now at 48 hours(-ish) and got 832 frames.
[23:15:58 CEST] <utack> which cpu-used?
[23:16:22 CEST] <DHE> it's a ryzen7 1700 running a 3 GHz. one thread because that's all that seems to work
[23:20:49 CEST] <DHE> in contrast x264 in placebo mode (also 1 thread, same input file) is getting a hair better than 0.5 fps
[23:25:57 CEST] <furq> https://github.com/listenlink/HM
[23:25:59 CEST] <furq> what about this
[00:00:00 CEST] --- Wed Apr  4 2018