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

[burek]

[00:01:10 CEST] <Zexaron> that's what JEEB said, i don't have to care about anything else just use timecodes
[00:24:19 CEST] <Zexaron> why the hell are audio and video even based on different, why can't be both based on time or samples or whatever
[00:25:00 CEST] <kepstin> If the emulator provides frame timestamps from its internal clock, then the video will be correct, either VFR or CFR depending how the emulator works internally
[00:25:18 CEST] <kepstin> They're both based on time...
[00:25:31 CEST] <Zexaron> if I made a new codec today, i'd only support progressive, whole frame rates, absolutely no nondivisable fractions whatsoever, sound resolutions
[00:25:48 CEST] <kepstin> Then your codec would be useless
[00:25:50 CEST] <furq> and then nobody would use it because their camera only records at 60000/1001 fps
[00:26:37 CEST] <furq> i really don't know what part of PTS values is giving you so much trouble
[00:26:49 CEST] <Zexaron> Well the idea doesn't stop with just a codec ... the whole industry needs a turn around
[00:26:55 CEST] <BtbN> why?
[00:27:12 CEST] <kepstin> Fortunately if your codec is otherwise ok, someone using it can just set proper timestamps in the container when muxing and ignore your broken framerate
[00:28:45 CEST] <kepstin> Webcams are even more fun, you usually get variable framerate based on the light level (darker means longer exposure so lower framerate)
[00:29:38 CEST] <Zexaron> consumer cameras aren't really useful for any serious stuff, just looks at what kind of mess it is, you have cameras recording totally alien resolutions with old pre 90ies standards, then you have film at 24 fps, then NTSC at odd decimal 29,97, then throw interlaced on top
[00:29:54 CEST] <Zexaron> It's liek someone wanted it to make as of a big screwup as possible
[00:30:23 CEST] <kepstin> Ntsc is an exact fraction, not a rounded decimal
[00:31:10 CEST] <Zexaron> it threw this out: 0,02997002997003
[00:31:33 CEST] <Zexaron> is any PC/monitor/ able to go down that precise to hold the fps steady
[00:31:55 CEST] <Zexaron> and this was win7 calc.exe
[00:32:09 CEST] <Zexaron> not sure if that's the full number
[00:32:23 CEST] <kepstin> Ntsc is exactly a field rate of 60000/1001, and this can be exactly represented using pts and time base
[00:32:36 CEST] <furq> it's a rational number
[00:32:41 CEST] <furq> if you were using perl 6 it would make perfect sense
[00:33:07 CEST] <Zexaron> well that's probably why frame time is the way to go, FPS is just one side of the story
[00:33:20 CEST] <furq> nothing modern actually has any conception of fps
[00:33:29 CEST] <furq> pretty much every modern codec just has frame timestamps
[00:33:35 CEST] <furq> and/or container
[00:34:10 CEST] <Zexaron> that's interesting, so why do peolpe say video editors have trouble with VFR, if that's kinda the base method
[00:34:25 CEST] <kepstin> A constant framerate video is just one where the frame time goes up by the same amount each frame
[00:34:27 CEST] <furq> because video editors suck
[00:35:07 CEST] <furq> i assume the reason is that a lot of them can't export to vfr, so having vfr sources is going to result in choppy playback
[00:35:26 CEST] <Zexaron> I'd believe that yes
[00:35:28 CEST] <furq> but i try my best to avoid commercial video editors so i couldn't tell you for sure
[00:35:43 CEST] <kepstin> a lot of video content and tools is made for broadcast video which is all constant rate
[00:36:05 CEST] <furq> yeah that's why i assume commercial tools won't export vfr
[00:36:10 CEST] <furq> because there's no demand for it
[00:36:27 CEST] <Zexaron> Ineed, allright, if the blame goes on the video editors, I'll just worry to make codec-correct video and turn the blame on that where it belongs
[00:36:42 CEST] <furq> you shouldn't worry in the slightest about making vfr video
[00:36:50 CEST] <furq> at some point if it has to be cfr then frames are going to get dropped
[00:37:05 CEST] <furq> it's better for you to keep them all and let something else drop them
[00:37:49 CEST] <Zexaron> That has certainly explained a lot now, and I totally agree with it, it's like preservation, if it doesn't play right, it's the player's fault then
[00:37:59 CEST] <Zexaron> Thanks furq that helped a lot
[00:38:31 CEST] <furq> there are some containers (like mp4) that store the fps in the header, but i'm pretty sure that's just advisory
[00:39:03 CEST] <Zexaron> Oh yeah, that thing confused me many times, I don't trust mediainfo that much anymore
[00:39:12 CEST] <kepstin> And there's old stuff like avi that you just shouldn't use
[00:39:35 CEST] <furq> mediainfo/ffprobe are just scanning the video stream and averaging the first few pts deltas
[00:39:51 CEST] <furq> which is why mediainfo says 29.97fps video in mkv is vfr, because the deltas aren't contant
[00:39:59 CEST] <furq> s
[00:40:21 CEST] <Zexaron> Sure that's on the chopping block already, I commited that already, but I chosen MKV at this time, however JEEB had some things about MKV that I have to adjust it to raise the limit or what
[00:40:58 CEST] <furq> the timebase defaults to 1/1000 iirc
[00:41:23 CEST] <furq> at least in ffmpeg
[00:41:38 CEST] <furq> iirc mkv timebase is always 1/10^n where n < 9
[00:41:49 CEST] <Zexaron> man an average is such a deceptive piece of information sometimes, it's artificial, doesn't exist
[00:42:18 CEST] <kepstin> I've never seen an mkv with any other value. I think the ffmpeg muxer is hardcoded to that.
[00:42:32 CEST] <furq> that might be true, i've never had cause to find out
[00:42:59 CEST] <kepstin> 1/1000 is fine for 60fps stuff like a console emulator might do
[00:43:10 CEST] <furq> yeah 1/1000 is never going to be more than 1ms out
[00:43:17 CEST] <furq> so idk if it actually affects playback noticeably
[00:44:04 CEST] <Zexaron> What exactly would necessitate the need for upping this limit, because of wildly changing fps in the emulator, like if there's a frame drop down to 10 for a few moments and back up, that would need more timecode precision?
[00:44:17 CEST] <furq> like i said i don't know if anything necessitates it
[00:44:20 CEST] <furq> it's just Technically Wrong
[00:44:26 CEST] <furq> which means someone on irc is sure to mention it at some point
[00:44:47 CEST] <Zexaron> oh let me read the backlog then
[00:44:49 CEST] <furq> if you can actually change the timebase then you might as well, but it's not worth worrying about if you can't
[00:45:23 CEST] <Hello71> well it could be worse if you have a bad program that uses relative timestamps in the file's timebase
[00:46:10 CEST] <kepstin> If you're doing well over 200 fps or so you might want to change the mkv timestamp precision.
[00:47:13 CEST] <Zexaron> I unfortunately don't have a way of knowing the limitations of the emulator, they try to be really accurate to how the console hardware works, so even if something's possible in general programming, doesn't meant they'll allow it, but ofcourse it's improvable and if necessary changes could be made to get those timebase and timecodes you guys talk about
[00:48:04 CEST] <Zexaron> There's only one game that's uncapped and does 300fps - in some scenes, not sure if the whole game, and it's an insignificant game, alien homein or something
[00:50:16 CEST] <Zexaron> Any comparable alternative to MKV ?
[00:50:27 CEST] <Zexaron> just incase
[00:51:39 CEST] <Zexaron> for other reasons, i mean, like if video editor can't open .MKV at all ... actually that would be a secondary optional setting
[01:01:24 CEST] <Zexaron> So no concept of fps in codecs
[01:01:43 CEST] <Zexaron> so that means MPC-HC reporting fps and fraps, that can't be trusted either then
[01:02:44 CEST] <Zexaron> if there was some kind of ffprobe thing where it would say maximum and minimum and ofcourse take full video into account, all the frames
[01:03:04 CEST] <Zexaron> We need something else instead of FPS to represent VFR smoothness
[01:03:09 CEST] <Zexaron> or something right?
[01:20:29 CEST] <Zexaron> I tried using FFV1 ... it still lowered perf by 30 %
[01:21:18 CEST] <BtbN> something like... timestamps oO
[01:21:21 CEST] <Zexaron> it was a bit faster but still significant, it may not be the encoding it self, it may be due to GPU/VRAM/RAM stuff in how things are dumped, and yeah, that's PC platform, nothing to do about it, but this isn't confimed yet
[01:22:03 CEST] <c_14> If you're going for speed above all else you might want to check utvideo or huffyuv I believe
[01:22:08 CEST] <Zexaron> FFV1 was always an opttion on windows for Dolphin tho
[01:22:39 CEST] <Zexaron> Now with PR#7110 it's full blown ffmpeg for win64 too
[01:23:09 CEST] <Zexaron> utvideo? never heard of that, but I'll try it as well yeah
[01:23:14 CEST] <furq> ffvhuff is the fastest lossless codec in ffmpeg
[01:23:19 CEST] <furq> the downside is that nothing other than ffmpeg supports it
[01:23:41 CEST] <furq> ffv1 is pretty slow, especially for hd stuff
[01:24:17 CEST] <Zexaron> and ffvhuff is not huffyuv?
[01:24:32 CEST] <Zexaron> btw how can yuv be lossless, 444 ?
[01:24:44 CEST] <c_14> lossless after transformation
[01:24:46 CEST] <Zexaron> cause in dolphin it uses BGRA
[01:25:17 CEST] <Zexaron> but this is old code ofcourse, I can change all of this to proper stuff if it's wrong
[01:25:34 CEST] <c_14> And I meant ffvhuff, I can never remember which of the two is faster
[01:25:39 CEST] <Zexaron> s_codec_context->pix_fmt = g_Config.bUseFFV1 ? AV_PIX_FMT_BGRA : AV_PIX_FMT_YUV420P;
[01:26:33 CEST] <c_14> both huffyuv and ffvhuff support bgra
[01:29:17 CEST] <furq> yeah huffyuv (and magicyuv) have misleading names
[01:37:16 CEST] <Zexaron> oh
[13:54:40 CEST] <Zexaron> Well, it there a way to limit how fast ffmpeg would work then? limiting CPU affinity and Priority is one thing, anything else ?
[13:55:07 CEST] <BtbN> define how fast it works? It will go as fast as it can
[13:55:09 CEST] <JEEB> setting threads for the encoder, mostly - if applicable
[13:55:19 CEST] <BtbN> Do you want to limit CPU usage, or video speed?
[13:56:27 CEST] <Zexaron> This is about through the API thing again, to take less CPU usage
[13:57:09 CEST] <Zexaron> I'm also thinking about that temporary raw buffer idea, if ffmpeg could work with that
[13:57:13 CEST] <JEEB> generally if you want to limit how much CPU time stuff gets that's a generic problem rather than FFmpeg-specific. FFmpeg will just utilize the amount of threads you set (if applicable to the encoder) and then do its thing. So if you need to put it on the background or something you do something like nice :P
[13:58:08 CEST] <JEEB> for input and output you can provide your own AVIO callbacks
[13:58:14 CEST] <JEEB> and those can do whatever they want
[13:58:15 CEST] <JEEB> :)
[13:58:39 CEST] <JEEB> if that's what you mean
[13:58:54 CEST] <zyme> lol@"the downside is that nothing other than ffmpeg supports it"
[13:59:16 CEST] <JEEB> although libavformat's reading and writing is already buffered and IIRC configurable
[13:59:19 CEST] <zyme> perhaps the solution to that is to have more things support ffmpeg
[13:59:49 CEST] <Zexaron> I'm thinking how to store this temporary raw buffer, in ffvhuff is one thing but not sure, that'll take some work
[14:00:09 CEST] <JEEB> if you need a lossless format that works in most editors then Ut Video is your thing :P
[14:00:16 CEST] <JEEB> that has modules for VFW, MF, QT etc
[14:00:18 CEST] <Zexaron> oh great so if it can't encode as fast it'll keep buffering the frames sent to it
[14:00:31 CEST] <JEEB> that's not IO
[14:00:35 CEST] <JEEB> that's encoding, and yes
[14:00:53 CEST] <JEEB> although the API is not async so this thing has to be in its own thread
[14:01:03 CEST] <JEEB> if you don't want it to block that is
[14:01:38 CEST] <JEEB> or well, I'm not exactly sure with the new API where the blocking will occur exactly
[14:01:47 CEST] <JEEB> since the encoding itself is generally handled in a separate thread
[14:02:46 CEST] <JEEB> but still I wouldn't be surprised if either feeding or fetching could block in the new API until a frame has been encoded
[14:02:56 CEST] <JEEB> (I might be incorrect 100%)
[14:03:06 CEST] <Zexaron> Kinda thinking that way: emulator -> dump raw to temp buffer on RAM or Disk -> pipe to ffmpeg slowly encode on low priority and only 1 or two threads -> emulator stops but ffmpeg isn't finished present dialog with progress bar showing lefotver time based on todo stuff in buffer
[14:03:22 CEST] <Zexaron> or any similar way that's better/faster
[14:03:51 CEST] <JEEB> could be same or separate process, sure.
[14:04:09 CEST] <JEEB> but IMHO it's not the component's problem that's feeding you stuff
[14:04:14 CEST] <JEEB> to buffer it
[14:04:24 CEST] <JEEB> I'd put that as one of the functionalities of the encoder component
[14:04:30 CEST] <JEEB> "another frame? yes thank you"
[14:04:30 CEST] <Zexaron> The timestamps then, how would they go along, part of the frame internally ?
[14:04:55 CEST] <JEEB> for me it'd make sense to have them as part of the data structure :P
[14:05:03 CEST] <JEEB> just like in FFmpeg we have AVFrame
[14:05:18 CEST] <JEEB> which contains not only the data, but also various additional info on the frame, such as timestamp
[14:05:50 CEST] <Zexaron> If ffmpeg has this buffer concept then it's in RAM or where, by default? Could put it on disk ?
[14:06:21 CEST] <Zexaron> Oh a struct, ofcourse
[14:07:40 CEST] <JEEB> there's the internal buffering on AVFrames you feed/AVPackets it's waiting for you to receive but I'm not sure how much the current encoders buffer there. also various 3rd party encoders like libx264 buffer dozens of frames internally sometimes
[14:07:58 CEST] <JEEB> the IO is where there's more of buffering and that's 100% override'able if you so desire
[14:08:17 CEST] <JEEB> but on the other hand, IO tends to be less interesting for you since you're only writing out stuff into a file, not reading the input
[14:08:45 CEST] <JEEB> the internal buffering, if there happens to be any, is only override'able by overriding malloc but I'm not sure if you want that at all :P
[14:09:38 CEST] <JEEB> most likely the encoding doesn't buffer things on the libavcodec level too much, so I'd just have a list of things fed to the encoding component
[14:09:59 CEST] <JEEB> so that the feeding part doesn't block the part that's feeding you frames
[14:10:20 CEST] <JEEB> then you keep feeding those buffered things to the lavc encoder as it processes things
[14:11:18 CEST] <JEEB> that way if you really want to start buffering the raw images on disk you can do it in your own code :P
[14:17:15 CEST] <Zexaron> like a feeder in the middle thing, ofcourse this wouldn't work if there's any checkback of the timecodes as you say that's not needed what's currently implemented, and that it would produce correct 1x speed output
[14:18:23 CEST] <Zexaron> probably too much time between right, it only works now because it's only a bit off somenoe said
[14:18:49 CEST] <Zexaron> The buffer should be increasing slowly
[14:19:01 CEST] <JEEB> I dunno, I quickly looked at the thing and it seemed to be just doing the +1 for each frame thing if I saw it correctly. so if it's off at that point something's bad
[14:19:23 CEST] <JEEB> so if it really was outputting each frame for X Hz then that should have worked
[14:19:28 CEST] <JEEB> (audio is separate of course)
[14:19:40 CEST] <JEEB> but yes, that's why the encoder shouldn't be concerned in making up timestamps
[14:19:50 CEST] <Zexaron> the whole point is to make encoding as lax as possible, but the buffer would never be so large as if you'd be dumping raw output all the time, so the encoded stuff that's done has to be dumped
[14:20:04 CEST] <Zexaron> still it'll be several GB if someone plays for 30 mins or more
[14:21:49 CEST] <Zexaron> well, some kind of way to get signal from encoder which parts were done? the things that are internally buffered could be cleared in this intermission buffer too, not necessairly after they're written to disk but that be safer
[14:22:20 CEST] <Zexaron> too* skip that word
[14:25:16 CEST] <JEEB> well I'd expect things get cleared out as they get encoded by either lavc or the encoding part :P
[14:26:11 CEST] <JEEB> but yes, if your encoding doesn't go fast enough you'd start accumulating buffer so you either expect that to balloon up in the worst case, or just tell the user that after N frames it will start dropping crap
[14:27:05 CEST] <Zexaron> Internal buffers, but what about the custom intermission buffer, or I don't need a custom one, just use AVIO stuff you mentioned, it will be several GB, althought temporary and wouldn't reach that high, so it may be way to get away with it for average users too
[14:27:24 CEST] <Zexaron> So it can't be in RAM, unless AVIO support to disk
[14:27:43 CEST] <JEEB> the AVIO stuff will be miniscule compared to the raw frames :P
[14:28:12 CEST] <JEEB> AVIO is for libavformat input and output buffering
[14:28:40 CEST] <JEEB> then the encoder might be buffering a few dozen frames (like libx264 depending on parameters), but that is not under your control anyways
[14:29:09 CEST] <JEEB> the only thing under your control is if you make your own feeding buffer that's waiting for the encoder pushing loop to get to it
[14:30:50 CEST] <Zexaron> Yes I do mean raw frame buffering, I expect it to keep growing as the game will probably output frames faster than ffmpeg could encode, if the goal is to throttle ffmpeg down to the slowest
[14:31:06 CEST] <JEEB> yes
[14:31:22 CEST] <JEEB> you handle that in the part that receives the frames from the thing that's feeding them for encoding
[14:31:34 CEST] <JEEB> just making sure that it doesn't block the part that's feeding you raw frames
[14:31:55 CEST] <Zexaron> So FFmpeg could be done in a way that it would see only the custom feeder, not the emulator, as it's source?
[14:32:13 CEST] <JEEB> libavcodec really doesn't care where you call it
[14:32:23 CEST] <Zexaron> indeed then
[14:32:26 CEST] <JEEB> all it cares about is that at some point it gets AVFrames
[14:32:34 CEST] <JEEB> and then it produces AVPackets
[14:32:41 CEST] <JEEB> (this is in case of encoding)
[14:33:58 CEST] <Zexaron> But working with disk IO and files that are being written to and deleted at the same time, that'll be another hoop imo
[14:34:21 CEST] <JEEB> yea if you start swapping buffers onto disk :P
[14:34:57 CEST] <JEEB> libavcodec is 100% RAM, and libavformat is what you'll most likely write the data out to disk with at the end (AVPackets muxed into a container and that gets written through a protocol - most often file)
[14:35:05 CEST] <Zexaron> Or I would need multiple buffers, write one buffer wile, while previous is being read by ffmpeg
[14:35:34 CEST] <JEEB> I really don't know, the whole disk swapping part just seems like making the whole thing X times harder to handle :P
[14:35:53 CEST] <TheAMM> What about allowing the user to just use nvenc and easily encode faster than realtime
[14:35:57 CEST] <Zexaron> Initially everything can be done in RAm
[14:36:20 CEST] <JEEB> I'd just rather have a buffer + a maximum at some point
[14:36:24 CEST] <JEEB> in RAM
[14:36:25 CEST] <Zexaron> if the buffer never crossed 20GB then it'll all work out, for +24 GB machines :)
[14:38:05 CEST] <JEEB> but yea, designing around hw encoders limits what you can do with them a lot, but it does almost always mean that the encoder will keep up with your rate most likely
[14:38:50 CEST] <JEEB> because if you have part X always running faster than part Y then you will always have issues with that
[14:39:11 CEST] <Zexaron> Well, maybe then the emulator would be interrupted, ffmpeg would have to finish the buffer out, and then continue if possible, or start new session (or it'll start and start a new ffmpeg session, if it wouldn't work with AV sync through the intermissions)
[14:39:57 CEST] <JEEB> yes, you could also have the encoding part note that its buffer is full
[14:40:01 CEST] <Zexaron> ffmpeg session = a new final output file, not appending to previous one
[14:40:13 CEST] <JEEB> and then that would block the emulator
[14:40:22 CEST] <JEEB> which would of course cause chaos
[14:40:27 CEST] <JEEB> for the player
[14:41:44 CEST] <Zexaron> Yes but ... many options: discard buffer and continue playing, encode buffer and continue playing without recording, encode buffer and quit game, encode buffer and start new recording session, discard buffer and quit game
[14:42:28 CEST] <JEEB> yes, most things seem to opt to just having a configurable buffer for the ingest and drop the pictures from the buffer if things aren't going fast enough
[14:42:56 CEST] <JEEB> because most things prefer having the gameplay go on rather than having 100% archival of all frames
[14:43:13 CEST] <JEEB> (and since you don't have infinite RAM, yet)
[14:44:08 CEST] <Zexaron> Well some people really want the best quality, someone even wanted lagarith support, accuracy is key here, frame skipping isn't preferred but it ofcourse possible option
[14:44:26 CEST] <JEEB> lagarith is just one of lossless encoders
[14:44:38 CEST] <Zexaron>  for debug probably wouldn't reach those limits or need so much archival
[14:45:14 CEST] <Zexaron> either way the buffer would be deleted after it's done encoding or discarding so whatever large file would be gone
[14:45:42 CEST] <JEEB> and yes, it's a problem of what is preferred. do you slow down the gameplay even more to keep it in speed with the encoder, or do you keep a buffer and hope you don't overflow it :P
[14:48:24 CEST] <Zexaron> btw furq explained to me yesterday why VFR is the way to go with a key point, about the video editors sucking and their fault, etc, I agreed, that was after you left
[14:49:07 CEST] <JEEB> well to be honest at this point I would be surprised if video editors couldn't handle VFR because a whole bunch of mobile phone clips are VFR
[14:49:30 CEST] <JEEB> like, you are in well lighted environment and it can use shorter period and you get the wanted FPS
[14:49:45 CEST] <JEEB> then you go into a darker area and suddenly your FPS lowers because each frame has to be acquired longer
[14:50:03 CEST] <ritsuka> I remember Premiere was unusually picky about VFR files, but maybe it's better now
[14:50:20 CEST] <JEEB> the editors will probably of course convert it to some sort of CFR on the way out
[14:50:49 CEST] <JEEB> Zexaron: also rather than the whole VFR/CFR thing, making your encoding part based on timestamps just makes it easier to enable stuff like frame dropping or whatever in the future :P
[14:51:10 CEST] <JEEB> be it in the emulator or encoding
[14:51:40 CEST] <JEEB> if your thing is CFR currently, great.
[14:53:23 CEST] <Zexaron> I don't know what it is to be honest, I'm the worst guy when it comes to PTS DTS timebase timecode time time, even tho I did output ffprobe stuff and looked at it, as for many many years dealing with archival and video transcoding I just kept avoding having anything to do with it
[14:54:00 CEST] <Zexaron> But I'll have to learn on these time stuff now, so I'll finally understand, I have to in order to know how to fix frame dumping
[14:55:03 CEST] <Zexaron> MPC-HC has that "render statistics" I figured that the FPS it's showing is probably the program refresh rate that's tied to the monitor display configuration most likely
[14:55:25 CEST] <Zexaron> That's probably not showing video fps
[14:55:38 CEST] <JEEB> I'm pretty sure I noted that already
[14:56:10 CEST] <Zexaron> That made me think "oh it's CFR"
[14:56:22 CEST] <JEEB> might very well be, I don't fucking know
[14:56:34 CEST] <JEEB> maybe you should look at the timestamps actually?
[14:56:49 CEST] <JEEB> and at this point it seems like I'm getting tired of you
[14:57:29 CEST] <Zexaron> So I had the idea, we'd need some other kind of representation of smoothnes or some other thing with VFR, but it's hard to have one number on it for the whole video
[14:57:54 CEST] <Zexaron> So maybe ffprobe could for example report minium and maximum frame time
[14:58:38 CEST] <Zexaron> man that guys assumes so quick
[14:59:39 CEST] <Zexaron> I don't think it's CFR anymore ofcourse, I was reflecting back, I have to go anyway, later,
[15:40:00 CEST] <Zexaron> avformat_network_init() not needed anymore for most stuff right?
[15:40:04 CEST] <Zexaron> deprecated ?
[15:40:42 CEST] <Zexaron> apparently it's for support for being able to input/output to networked folders/drives *
[15:41:03 CEST] <Zexaron> as I don't see any other networking use in this project
[15:42:30 CEST] <furq> usually your os would handle that for you anyway
[15:42:41 CEST] <furq> if it's cifs/nfs or something
[15:48:02 CEST] <Zexaron> oh, ok
[16:38:25 CEST] <megaTherion> uhm without reading the complete manpage of ffmpeg, does the CLI have a pretend/do nothing flag where it just outputs what it would do?
[16:44:12 CEST] <furq> megaTherion: replace the output filename with -f null -
[16:44:17 CEST] <furq> that's the closest thing to a dry run mode
[17:03:15 CEST] <jdiez> hi all, I'm trying to capture video from sway using the dmabuf-capture program included as an example with wlroots, but I'm getting an error that appears to come from ffmpeg: https://gist.github.com/jdiez17/3c90bd017a6b652adb4d78d119aa287f
[17:04:05 CEST] <jdiez> I've heard atomnuker may know how to help? :)
[17:09:53 CEST] <megaTherion> furq: thanks
[17:10:02 CEST] <atomnuker> jdiez: print arguments
[19:29:28 CEST] <nicolas17> I have two videos and I think one was remuxed (not reencoded) from the other, so their quality should be identical; how can I compare them?
[19:30:03 CEST] <JEEB> use framemd5
[19:31:50 CEST] <JEEB> ffmpeg -vsync passthrough -copyts -i INPUT -map 0:v -f framemd5 output.stats
[19:31:51 CEST] <furq> nicolas17: -i 1.mkv -i 2.mkv -map 0 -f hash - -map 1 -f hash -
[19:32:00 CEST] <JEEB> what was hash again?
[19:32:06 CEST] <furq> !muxer hash
[19:32:06 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#hash-1
[19:32:31 CEST] <JEEB> ah, framehash is also around
[19:32:42 CEST] <JEEB> so yea, similar :P
[19:32:54 CEST] <nicolas17> md5/hash seems to be for the entire stream while framehash/framemd5 are per frame?
[19:33:07 CEST] <JEEB> yes
[19:49:17 CEST] <ChocolateArmpits> framemd5 is useful if you suspect the video may be cropped from a longer one
[19:49:49 CEST] <ChocolateArmpits> additionally you can either compare wrapped frames, or decoded frames
[19:51:05 CEST] <nicolas17> does framemd5 hash the encoded packet?
[19:51:58 CEST] <ChocolateArmpits> it's an output format, so it will use what you feed it, if you specify -vcodec rawvideo, then hash for the decoded frame will be calculated, if -vcodec copy then the packet
[19:52:15 CEST] <nicolas17> ohh, interesting
[19:52:45 CEST] <ChocolateArmpits> if you suspect that the packet may change, even though the essence is the same, then maybe decoding the video may be smarter
[19:53:16 CEST] <ChocolateArmpits> really depends on your videos
[19:55:39 CEST] <ChocolateArmpits> actually it seems if you don't specify any output codec for the video, it will default to rawvideo for framemd5
[19:55:54 CEST] <ChocolateArmpits> Muxer framemd5 [Per-frame MD5 testing]:
[19:55:54 CEST] <ChocolateArmpits>     Default video codec: rawvideo.
[19:55:54 CEST] <ChocolateArmpits>     Default audio codec: pcm_s16le.
[19:57:00 CEST] <ChocolateArmpits> same for hash/md5
[20:00:28 CEST] <ChocolateArmpits> In my case I use framemd5 for decoded frames to try and determine which files constitute parts of other files and then remove them as duplicates.
[23:52:07 CEST] <Zexaron> Hey, in the existing project that uses ffmpeg API, pixfmt is defined like many times, first initialized as BRG24, then at start it gets prepared as RGBA, but when codec context is defined it gets changed to BGRA or YUV420, is this all necessary ?
[23:52:30 CEST] <Zexaron> are the first two or one definitions for the input?
[23:53:06 CEST] <JEEB> generally what happens is that you get your input, you convert that in one way or another to the pixel format you require or the user has requested from you
[23:53:19 CEST] <JEEB> and then you just tell the encoder what you will be feeding to it before calling init()
[00:00:00 CEST] --- Sun Oct 21 2018