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

[burek]

[00:03:07 CEST] <cryptodechange> https://pastebin.com/AHfRrMc5
[00:03:39 CEST] <cryptodechange> [tonemap_opencl @ 0x4cef5c0] Filter input: opencl, 3840x2160 (0). [tonemap_opencl @ 0x4cef5c0] tone mapping transfer from smpte2084 to bt709 [tonemap_opencl @ 0x4cef5c0] mapping colorspace from bt2020nc to bt2020nc [tonemap_opencl @ 0x4cef5c0] mapping primaries from bt2020 to bt2020 [tonemap_opencl @ 0x4cef5c0] mapping range from tv to tv
[00:10:08 CEST] <JEEB> cryptodechange: sounds like you then need a conversion to BT.709 primaries and colorspace after the fact?
[00:10:17 CEST] <JEEB> unless the tonemap_opencl filter can do that for oyu
[00:14:26 CEST] <cryptodechange> Well I wanted to downscale it to 1080p, so I'll throw in zscale=w=1920:h=-1:f=lanczos:t=bt709:m=bt709:r=tv
[00:14:45 CEST] <cryptodechange> After hwdownload,format=nv12
[00:22:33 CEST] <cryptodechange> little to no difference :/
[00:30:04 CEST] <Zexaron> Hey, is it true that video players don't like VFR, would it show as average FPS, let's say MPC-HC ... I keep seeing 60 all the time for what is suppose to be a VFR video
[00:30:25 CEST] <JEEB> video players have to render at the screen rate anyways in one way or another
[00:30:26 CEST] <Zexaron> but there is jutter like 0.9-0.5 ... but is that the VFR or is that normal jitter ?
[00:30:53 CEST] <JEEB> you can already think that f.ex. most matroska files are VFR :P
[00:30:56 CEST] <JEEB> or that mpeg-ts is
[00:30:59 CEST] <JEEB> or FLV
[00:31:14 CEST] <JEEB> mostly due to their limitation in timestamp time base
[00:31:34 CEST] <JEEB> for example FLV is 1/1000 (one second is 1000 ticks)
[00:31:41 CEST] <Zexaron> limitation? Everyone kept saying AVI is a limitation to replace it with MKV
[00:31:41 CEST] <JEEB> so try saving 24000/1001
[00:31:43 CEST] <JEEB> in that
[00:31:53 CEST] <JEEB> different containers are different
[00:32:02 CEST] <JEEB> matroska I'm not sure if it was 10k or so?
[00:32:19 CEST] <JEEB> although you can heighten that
[00:32:22 CEST] <JEEB> it's not hard-coded
[00:32:31 CEST] <JEEB> just IIRC you can't have exact fractions
[00:32:41 CEST] <Zexaron> This is around the emulator frame dumping again btw, so it's a 3D game that has to dump frames, feed into ffmpeg, and ffmpeg make a video all at once
[00:32:53 CEST] <JEEB> but what I'm trying to say, no - VFR is fine with most normal video players
[00:33:02 CEST] <JEEB> plastic boxes can have issues with it of course
[00:33:27 CEST] <JEEB> although even that is rarer nowadays as long as the frame rate doesn't go too high
[00:33:48 CEST] <JEEB> at which point the plastic boxes' hardware decoder might not keep up :P
[00:34:44 CEST] <Zexaron> It's used by people who deal with video, so they have the expertise to convert and manage it, but it's been kinda buggy, it's a full overhaul, the AVI format is old, so changing it to MKV, AVI default was MPEG4Visual, now it's H264 ... but you mentioned MPEG-TS  interesting tho
[00:35:18 CEST] <JEEB> Zexaron: for a live gameplay capture where the rendering rate might not be static you just pick your tick rate (whatever makes sense in your context) and then you know the exact time point where your gameplay frame on that ticket rate should be :P
[00:35:22 CEST] <JEEB> that is your PTS
[00:35:39 CEST] <JEEB> tick rate in multimedia is called time base :P
[00:36:10 CEST] <Zexaron> The whole VFR thing is because it's doing some back-and-forth with timestamps and wallclock to make game-speed normal, this is tricky because GCN/Wii games are FPS-Bound-Game-Speed so the gamepeed changes if the PC isn't fast enough to run stable full framerate
[00:36:24 CEST] <JEEB> yes
[00:36:39 CEST] <JEEB> that's what I meant
[00:37:44 CEST] <JEEB> you internally pick a tick rate which makes sense in the emulator's or whatever's context
[00:37:46 CEST] <Zexaron> Allright just making sure we're on the same page, this isn't something usual that ffmpeg has to deal with AFAIK
[00:38:01 CEST] <JEEB> it is, that's why you have time bases and PTS/DTS everywhere
[00:38:18 CEST] <JEEB> instead of hard-coded frame rates :P
[00:38:47 CEST] <JEEB> so if you know that your emulator at the maximum works at a tick rate of X kilohertz or megahertz or whatever
[00:38:52 CEST] <Zexaron> Kepstin took a look at the current github code and said that we're doing it wrong, since I'm new around that area, I don't know how the existing thing works, I wasn't the dev, trying to fix it tho
[00:39:01 CEST] <JEEB> that is your initial tick rate (time base)
[00:39:14 CEST] <JEEB> then on that tick rate you know when the emulator was able to push out a frame
[00:39:25 CEST] <JEEB> and you know its timestamp exactly on that tick rate (time base)
[00:39:30 CEST] <JEEB> Boom! PTS and time base
[00:39:31 CEST] <Zexaron> Something about that it's checking timecode back after rendering and the timecode would have since changed so it's off a bit
[00:40:13 CEST] <JEEB> yes, the part that gives the video handling thing the frames should be the one giving the PTS :P
[00:40:30 CEST] <JEEB> "this was frame X rendered at time Y"
[00:40:37 CEST] <JEEB> then the rest of the thing takes that on
[00:41:06 CEST] <Zexaron> Jeez you make it sound so simple, thanks, I'll be very helpful once I dig into it, I'm still just looking at the code to get the familiarity with the pipeline.
[00:41:53 CEST] <JEEB> it's not really simple since you have to make your infrastructure so that the giving of the frames from the emulator's renderer loop does not block
[00:42:07 CEST] <JEEB> which usually means either a separate thread or so
[00:42:38 CEST] <JEEB> so that the emulator doesn't block its rendering loop just because video encoding is hard :P
[00:44:49 CEST] <JEEB> not that I'm good at this architecture crap
[00:45:18 CEST] <JEEB> and this is all irrespective of what you end up using for the actual video processing
[00:45:22 CEST] <Zexaron> I did had discussion over there, they run framedumping on another thread, but they also say it's putting a load on the GPU, however, FFMPEG it self doesn't use HWaccell so ... I'm still just familiarizing first, but this helps a lot many thanks
[00:46:09 CEST] <Zexaron> Well I do have the IDE with the code open all day today, but I'm just looking at it so far ... and talking on 3 IRC channels
[00:52:25 CEST] <Zexaron> You mean I have to figure out at which tick rate the emulated game is suppose to run ... I don't know much about dolphin, so this is harder for me, sometimes the fix it self is much easier than the figuring out to do to get there
[00:53:15 CEST] <JEEB> I wouldn't make it game-specific, generally something regarding the tick rate of the emulator, if it has one
[00:53:25 CEST] <JEEB> if it doesn't then think how exact timestamps you want :P
[00:53:57 CEST] <Zexaron> Yeah could be, something tied to the CPU, they do emulate Video Interface it runs on it's own FPS as if it was analog TV.
[00:54:03 CEST] <Zexaron> they call it VPS
[00:54:26 CEST] <JEEB> basically, whatever makes sense as being the "root clock tick rate"
[00:54:33 CEST] <JEEB> and your frames would be on that time base
[00:54:44 CEST] <JEEB> their presentation timestamps that is (PTS)
[00:55:29 CEST] <Zexaron> And they be correct automatically, and given to ffmpeg (or ffmpeg has the means to figure it out immediately), not having to ask after each frame ?
[00:56:01 CEST] <JEEB> well the emulator would be feeding you the frames with the time on that tick rate when they'd be shown :P
[00:56:25 CEST] <JEEB> so whatever you do with the frame later, you will know the exact timestamp of when it was supposed to be shown
[00:57:01 CEST] <JEEB> in the worst case it's an approximation of when you received the frame from the renderer, in the best case if the renderer knows when the frame would be rendered on screen, that's the best
[00:57:26 CEST] <Zexaron> But did you actually seen the code, how can we know for sure, because honestly, I'm not actually sure how it all runs right now, I just know bits and pieces of what is and that it is wrong
[00:57:39 CEST] <JEEB> anything I say is 100% unrelated to any code :P
[00:57:54 CEST] <JEEB> I am just trying to examine the issue of "how to make a working capture thing"
[00:58:38 CEST] <JEEB> and then if you have a smaller scope than that, you just after thinking start splicing things into separate parts that will get done at different points, if ever
[00:58:54 CEST] <Zexaron> Understood, but that means something may already be done the way you said it ... and I have no idea what's right or wrong inside there yet, so it would give me impression everything's wrong, heh
[00:59:20 CEST] <JEEB> anyways, almost 2am here and five hours to work so I'm definitely calling it quits :P
[01:00:09 CEST] <Zexaron> Well it's not suppose to capture it in real time, it's suppose to be primairly dumping things, the video doesn't need to be output in real-time, it's not feeded into streaming, FFmpeg could be lowered to be slower and take time when encoding the video
[01:00:39 CEST] <Zexaron> so it be lower taxing on the CPU
[01:01:55 CEST] <Zexaron> Allright, thanks, I know how lack of sleep is deadly so goodnight!
[01:26:31 CEST] <cryptodechange> According to MPV, the colourmatrix/primaries are indeed BT.709 when using -vf "format=p010,hwupload,tonemap_opencl=format=nv12,hwdownload,format=nv12"
[01:27:05 CEST] <cryptodechange> Even when leaving tonemap= blank (apparently defaulting to none) leaves the finished encode overly bright and washed out
[01:27:53 CEST] <cryptodechange> Pretty much identical to converting to bt.709 via. zscale=p=bt709 with no tonemapping
[01:42:39 CEST] <victorqueiroz> I'm having "Invalid data found when processing input" while using C api and processing a file. Although it can successfully process .mov files recorded in macOS. why would that be? Any ideas?
[09:53:59 CEST] <Zexaron> Allright so I was going to use MKV, but now some dillema because there's some MKV limitation for how fine can the timestamps be, it has to be overriden or what
[15:14:20 CEST] <victorqueiroz> I'm having the following error: https://pastebin.com/DQk7323n and receiving AVERROR_INVALIDDATA although I'm passing the packets through parser and targeting the correct stream index. What should I do to avoid it? I see no such error in FFmpeg CLI while decoding the same video...
[20:18:41 CEST] <rkantos_> how many overlay_qsv filters can I have? Just by replacing the overlay filters with _qsv I get "Too many inputs specified for the "format" filter."
[20:19:36 CEST] <rkantos_> the intel hwaccel / encoding really is an adventure, I must say
[20:19:39 CEST] <durandal_1707> rkantos_: full uncut output of ffmpeg missing
[20:21:21 CEST] <rkantos_> durandal_1707: https://pastebin.com/v3aEKA2z
[20:22:11 CEST] <rkantos_> that is the one that works, it also works with the last scale set to scale_qsv, but if I add _qsv to anything before I get " too many inputs.."
[20:25:43 CEST] <rkantos_> example which doesn't work: https://pastebin.com/XzUwNsH0
[20:36:18 CEST] <zamba> i'm trying to mix audio from alsa and video from v4l2 into a single stream, but so far failing
[20:36:46 CEST] <zamba> ffmpeg -f video4linux2 -channel 1 -i /dev/video0 -f alsa -i hw:0 -strict -2 output.mp4
[20:38:31 CEST] <zamba> getting lots of alsa buffer xrun
[20:39:05 CEST] <zamba> when trying to play back the mp4 i'm getting lots of distorted audio, though i can make out that this is in fact portions from the tape
[20:39:22 CEST] <BtbN> Is your CPU hitting 100%?
[20:39:36 CEST] <BtbN> also, why -strict -2?
[20:41:21 CEST] <zamba> if i add -thread_queue_size 1024 it works
[22:05:40 CEST] <RedSoxFan07> Is there an option for deleting the original file? I'm just curious because I'd like to convert some large video files without taking up extra space on my hard drive.
[22:07:02 CEST] <durandal_1707> no
[22:09:20 CEST] <RedSoxFan07> durandal_1707: Dang!
[22:09:59 CEST] <RougeR> does anyone here use the streamio-ffmpeg gem
[22:10:01 CEST] <RougeR> for ruby?
[22:10:21 CEST] <RougeR> im thinking of forking it and conrtributing to it, we use it a lot in our work repos for a video streaming SAAS
[22:10:39 CEST] <RougeR> and its not pulled some important PRs in a few year
[22:10:40 CEST] <RougeR> s
[22:11:34 CEST] <RougeR> like .valid? always returns true even if you do FFMPRG:Movie.new('foo.txt').valid?
[22:11:53 CEST] <RougeR> its codec_type still reads video
[22:12:11 CEST] <bodqhrohro> RedSoxFan07: how do you imagine it? Encoder may need to read the file in several passes, moreover, there is no transparent way on filesystem level to shrink the old file from beginning to end while the new file is written
[22:12:45 CEST] <RedSoxFan07> bodqhrohro: I meant that I want to have FFMPEG delete the original when it's done with it - after the conversion.
[22:15:47 CEST] <bodqhrohro> RedSoxFan07: it can be done with a simple script, moreover, it brings up the possibility to check if the file was successfully converted. Why should FFmpeg do this too? Maybe it should also make a cup of coffee for you to wait until the file is converted more comfortely? :)
[22:17:03 CEST] <RedSoxFan07> bodqhrohro: On one hand, I'd like to hang onto the original in case something goes wrong with the conversion. But I'm running a little low on hard drive space, so I'd like to be able to delete the originals ASAP.
[22:20:25 CEST] <GuiToris> hey, I was wondering if ffmpeg is able to convert to DNxHD? And whether it's superior to mp4 if I'd like to further edit videoclips?
[22:20:52 CEST] <GuiToris> I've read that x264 is very resource hungry to decode
[22:21:08 CEST] <Hello71> sounds like one of those proprietary bloated as fuck formats
[22:21:16 CEST] <durandal_1707> DNxHD is ugly
[22:21:20 CEST] <Hello71> ... yup.
[22:21:29 CEST] <GuiToris> durandal_1707, which one should I use instead?
[22:21:39 CEST] <GuiToris> I've been only used x264
[22:21:41 CEST] <Hello71> and x264 isn't a codec
[22:22:16 CEST] <GuiToris> DNxHD might be a codec
[22:22:20 CEST] <GuiToris> I don't really know it
[22:22:50 CEST] <durandal_1707> GuiToris: for editting videoclips i would always use lossless, ffmpeg have DNxHD/DNxHR encoders
[22:23:55 CEST] <GuiToris> durandal_1707, when you say lossless, do you mean -c:v libx264 -crf 0?
[22:24:02 CEST] <GuiToris> or rawvideo?
[22:24:29 CEST] <Hello71> no.
[22:24:34 CEST] <durandal_1707> rawvideo is too much
[22:25:28 CEST] <Hello71> hell, if you're using an actual disk and not RAM then it's slower than a fast huffman
[22:26:48 CEST] <durandal_1707> GuiToris: yes, also any other lossless encoder: ffvhuff, magicyuv, lagarith etc
[22:29:48 CEST] <furq> GuiToris: if you need to support something like premiere then you're pretty much stuck with utvideo for lossless
[22:30:04 CEST] <GuiToris> furq, I'm using kdenlive
[22:30:27 CEST] <GuiToris> I was wondering if any of them (ffvhuff, magicyuv, lagarith) uses compression
[22:30:32 CEST] <GuiToris> I'm running out of diskspace
[22:30:35 CEST] <furq> well they all use compression otherwise what would be the point
[22:30:41 CEST] <GuiToris> I have less than 80 gigs and a bunch of clips
[22:30:48 CEST] <furq> if kdenlive uses ffmpeg then any codec should work
[22:31:02 CEST] <furq> and if you want to save disk space then lossless x264 and ffv1 are the best in class
[22:31:23 CEST] <GuiToris> they work but slow, and I read that h.264 is heavy
[22:31:57 CEST] <GuiToris> I've just found out that kdenlive has the ability to use proxy clips
[22:32:08 CEST] <furq> what are you converting from
[22:32:12 CEST] <GuiToris> mts
[22:32:21 CEST] <furq> could you not just use that
[22:32:38 CEST] <GuiToris> no, that's what our camcorder makes
[22:32:41 CEST] <GuiToris> it's not optional
[22:32:47 CEST] <furq> no i mean why not just edit that
[22:32:54 CEST] <GuiToris> oh, I get it
[22:33:08 CEST] <GuiToris> I need to deinterlace them first
[22:33:18 CEST] <furq> can kdenlive not do that
[22:34:08 CEST] <GuiToris> I was thinking about this too, but a few years ago transitions weren't so smooth, the next clip started with still images
[22:34:33 CEST] <GuiToris> I hope you know what I mean
[22:35:01 CEST] <GuiToris> I started converting the clips and this problem disappeared
[22:35:10 CEST] <furq> well i'd probably try that before anything else
[22:35:23 CEST] <GuiToris> and I also stabilize them
[22:35:28 CEST] <furq> when you say converting the clips do you mean cutting and deinterlacing the ranges you want outside of kdenlive
[22:35:44 CEST] <furq> because that might just be a seeking problem rather than a deinterlacing problem
[22:37:06 CEST] <GuiToris> -ss [time] -i [file] -t [time] -vf nnedi -crf 15 -preset veryslow -c:a copy
[22:37:15 CEST] <GuiToris> that's what I usually do
[22:37:34 CEST] <GuiToris> and mp4 of course
[22:38:24 CEST] <GuiToris> I use relatively low crf number and veryslow to preserve the details
[22:51:09 CEST] <GuiToris> what format goes well with ffv1?
[22:51:10 CEST] <saml> you in demuxed?
[22:53:02 CEST] <durandal_1707> GuiToris: nut is best
[22:54:57 CEST] <GuiToris> thanks
[22:55:44 CEST] <durandal_1707> GuiToris: but nut is not supported by comercial solutions, so you use mxf or some other crap
[22:56:20 CEST] <GuiToris> kdenlive is not a commercial solution, is it?
[22:56:50 CEST] <GuiToris> I'm just looking for a quicker file format
[22:57:17 CEST] <durandal_1707> anything better than mp4/avi is good
[22:58:02 CEST] <GuiToris> thank you for your help :)
[22:58:43 CEST] <furq> GuiToris: mkv is generally a safe bet with oss stuff
[22:59:06 CEST] <furq> idk of anything other than nut or mkv which will take ffv1 anyway
[23:01:25 CEST] <GuiToris> this guide is rather incomplate https://trac.ffmpeg.org/wiki/Encode/FFV1   it doesn't cover the possible file formats
[23:02:20 CEST] <saml> what are you doing with ffv1?
[23:05:09 CEST] <GuiToris> I'm about to prepare some videoclips so I can edit them later
[23:05:34 CEST] <Hello71> in theory I figure you can stuff it in AVI
[23:53:46 CEST] Action: CoreX nuts all over the place
[00:00:00 CEST] --- Fri Oct 19 2018