Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2018

1 participants
62 discussions

ffmpeg-devel.log.20181020
by burek 21 Oct '18

21 Oct '18

[02:03:54 CEST] <cone-674> ffmpeg 03Devin Heitmueller 07master:9e21ba3dc340: avdevice/decklink: Fix compile breakage on OSX [06:30:36 CEST] <philipl> BtbN: Could you verify the current state of the mpv PR still works correctly on windows? I think it's finally done. Thanks! [06:44:23 CEST] <qwefytuoityty> have encoder av1? VLC have decoder av1? aom, but, now youtube encode file through AV1? [06:50:05 CEST] <Compn> hmm where is lou [06:50:19 CEST] <Compn> remind him we should move some old news to old news page. ffmpeg news getting long [06:50:46 CEST] <Compn> news page goes back to 2013 :D [10:43:57 CEST] <BtbN> philipl, builds and works fine still [13:15:42 CEST] <uau> that above ticket #7446 is caused by libx264 using strtok, which is not threadsafe [13:16:27 CEST] <uau> (not sure if any of the people caring about that are here though...) [13:17:50 CEST] <atomnuker> echo $LD_LIBRARY_PATH = /usr/local/lib -> ffmpeg -> library mismatch [13:17:59 CEST] <atomnuker> LD_LIBRARY_PATH=/usr/local/lib ffmpeg -> all ok [13:18:04 CEST] <atomnuker> wat [13:18:25 CEST] <JEEB> uau: cheers. I can comment on the ticket regarding that. [13:18:53 CEST] <BtbN> So libx264.c just wrongfully has FF_CODEC_CAP_INIT_THREADSAFE set then. [13:19:07 CEST] <nevcairiel> there is already a patch on the ML that explains that [13:19:25 CEST] <uau> BtbN: well it really is more buggy than that [13:19:36 CEST] <uau> strtok is not safe if the process has any other threads whatsoever [13:19:43 CEST] <uau> so not really appropriate for a library [13:19:49 CEST] <uau> locking around init won't fix that [13:19:54 CEST] <nevcairiel> can only blame x264 for that, nothing we can do about that [13:20:25 CEST] <BtbN> If x264 only uses it during init, that should fix it [13:20:33 CEST] <BtbN> If it uses it at runtime, well... [13:20:43 CEST] <BtbN> not much ffmpeg can do about it [13:20:58 CEST] <JEEB> I guess it's the key/value parameter parsing [13:20:59 CEST] <nevcairiel> the point is that some othre thread entirely unrelated to x264 may also use strtok [13:21:02 CEST] <nevcairiel> and break it [13:21:08 CEST] <JEEB> yes [13:21:13 CEST] <nevcairiel> whoever designed strtok should get banned from development, really [13:21:16 CEST] <BtbN> Any sane other thread should use the thread safe variant of strtok [13:21:16 CEST] <JEEB> anyways, that is an issue in x264 [13:24:27 CEST] <uau> nevcairiel: which mailing list do you mean btw? i tried searching for strtok on ffmpeg-dev but found no matches [13:25:09 CEST] <uau> hmm maybe it was too limited by time [13:25:16 CEST] <JEEB> ffmpeg-devel has a patch from marton [13:25:28 CEST] <JEEB> "avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag" [13:25:37 CEST] <JEEB> > Libx264 uses strtok which is not thread safe. Strtok is used in [13:25:54 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/10724/ [13:29:16 CEST] <uau> ok too new then, i didn't fetch new messages before searching... [13:30:32 CEST] <JEEB> also TIL strtok_r [13:30:49 CEST] <JEEB> and FreeBSD has strsep(3) it seems [13:45:08 CEST] <BtbN> https://github.com/mirror/x264/search?utf8=%E2%9C%93&q=strtok&type= weird [13:48:10 CEST] <BtbN> param_parse is using strtok_r [13:48:56 CEST] <BtbN> but nothing else is [13:49:33 CEST] <JEEB> yea, ratecontrol.c uses strtok_r already [13:50:04 CEST] <JEEB> and it already has a thing to replace strok_r with strtok if someone is unfortunate enough to not have strtok_r [13:51:24 CEST] <BtbN> it should be trivial to fix it up to use it everywhere [13:51:58 CEST] <JEEB> yea [13:52:22 CEST] <nevcairiel> unless the report in question was actually from a system that doesnt have strtok_r [13:53:06 CEST] <JEEB> seemed to be just a usual GCC-based system [16:42:08 CEST] <philipl> BtbN: thanks! [19:37:06 CEST] <j-b> jamrial: so, around 270 lines? Not too bad. [22:50:20 CEST] <philipl> BtbN, nevcairiel: Posted an updated patchset for the 444 stuff with expanded discussion of pix fmt situation. Let's please get a decision. [23:26:33 CEST] <philipl> BtbN: thanks for reviewing [00:00:00 CEST] --- Sun Oct 21 2018

1 0

ffmpeg.log.20181020
by burek 21 Oct '18

21 Oct '18

[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

1 0

ffmpeg-devel.log.20181019
by burek 20 Oct '18

20 Oct '18

[00:24:24 CEST] <thebombzen> I believe I've found a solution that allows using -r:v as an input option for streamcopy [00:24:40 CEST] <thebombzen> and it passed "make fate". should I just send it to the email list? [00:26:28 CEST] <thebombzen> it's here https://0x0.st/sEtq.patch [15:25:35 CEST] <uau> https://github.com/mpv-player/mpv/issues/6218 <- that's apparently caused by "avctx->skip_frame = AVDISCARD_NONREF;" no longer working right with new x265-encoded files (used by mpv when doing precise seeks; what the PR says about "--hr-seek" not mattering is misleading) [15:25:46 CEST] <uau> can anyone tell whether that's a libavcodec bug or x265 bug? [15:27:12 CEST] <uau> the issue is visible in ffplay too if you add "d->avctx->skip_frame = AVDISCARD_NONREF;" as the first line of decoder_decode_frame() in ffplay.c [15:38:29 CEST] <jamrial> uau: it could be a bug in libavcodec, like a nal unit wrongly listed in ff_hevc_nal_is_nonref() that new x265 generates [15:46:02 CEST] <jamrial> uau: try removing HEVC_NAL_IDR_N_LP from that list, see if that helps [15:51:38 CEST] <uau> ok testing [15:54:03 CEST] <uau> commenting out "case HEVC_NAL_IDR_N_LP:" does remove visible corruption under ffplay [17:48:37 CEST] <cone-281> ffmpeg 03Paul B Mahol 07master:8baaed7889f3: avfilter: add sinc source filter [19:05:47 CEST] <durandal_1707> atomnuker: what is status of fft/mdct ? [19:59:07 CEST] <atomnuker> durandal_1707: I think I need to scrap the work I did on having a wrapper layer for complex.h [20:00:49 CEST] <atomnuker> I don't think c99 complex variables have a standard abi across all x86 platforms so we can't really pass them off to SIMD functions [20:01:28 CEST] <atomnuker> plus they're now optional under c11 and they really don't improve anything either [20:02:08 CEST] <atomnuker> I don't know why I thought they would be a nice idea but I probably looked at how the fftw api work and thought it was nice [20:02:49 CEST] <atomnuker> they use their own float types but if you include <complex.h> before their header you can give it _Complex floats/doubles [20:03:41 CEST] <atomnuker> oh well, I only did this for mdct15.c, not much at all [20:04:22 CEST] <atomnuker> and I still need bofh_ to tell me how to modify that code to work for non-multiples of 15 [20:19:44 CEST] <cone-281> ffmpeg 03Carl Eugen Hoyos 07master:feb05ffa99fc: lavf/dump: Fix a typo: comentary -> commentary. [20:33:54 CEST] <cone-281> ffmpeg 03Carl Eugen Hoyos 07master:10f468156c01: lavc/sinewin: Do not declare AAC 120/960 tables as const. [20:37:34 CEST] <cone-281> ffmpeg 03Carl Eugen Hoyos 07master:6871c1717359: lavf/matroskadec: Simplify string length calculation. [22:46:26 CEST] <durandal_1707> why we do not have 8k alias for frame size? [22:46:39 CEST] <JEEB> we don't have aliases for a whole lot of frame sizes [22:46:48 CEST] <JEEB> also do you mean UHD 8K or cinema 8K? [22:47:20 CEST] <JEEB> 2K/4K/8K are not exactly something meaning a single thing :P [22:47:32 CEST] <durandal_1707> we already have some uhd4320 [22:47:55 CEST] <JEEB> that's fun [22:48:52 CEST] <durandal_1707> so i think our 2k/4k is cinema one [22:51:47 CEST] <atomnuker> I think we can change it given it really didn't take off [22:52:02 CEST] <durandal_1707> what change? [22:52:32 CEST] <JEEB> atomnuker: you can just go look at which aspect ratio f.ex. tears of steel uses [22:52:55 CEST] <JEEB> but yea, it's mostly just used in cinema and since we only get BD/UHD BD versions those are always 16:9 :P [22:53:21 CEST] <durandal_1707> i prefer to type less [00:00:00 CEST] --- Sat Oct 20 2018

1 0

ffmpeg.log.20181019
by burek 20 Oct '18

20 Oct '18

[01:14:52 CEST] <zamba> i'm digitalizing some old tapes.. which container should i output to to be able to view the result while i'm encoding? [01:15:03 CEST] <zamba> using .mp4 means i can't preview it until it's done [01:25:39 CEST] <furq> mkv [01:25:47 CEST] <furq> you should use mkv anyway because it won't be unrecoverable if ffmpeg crashes [03:32:14 CEST] <Spring> is there a likely cause why the 'blocksize' option for the deshake filter won't run if the value is higher than '10'? The default value according to the docs is '8', with a possible range of 4 to 128. [03:40:08 CEST] <Spring> also ffmpeg.pastebin.com is broken for me [08:21:08 CEST] <poutine> I'm experiencing a bug in software when PTS rolls over in a HTTP Live Stream where I have not captured the segments the rollover occurs in. Any ideas how I could generate that or get an example mpeg ts file that contains a PTS rollover? [14:48:58 CEST] <Zexaron> So it was said MKV precision is 10k for VFR, what about MPEG-TS ? [14:49:24 CEST] <BtbN> precision? [14:49:44 CEST] <BtbN> mpeg-ts has a 1/90000 timebase, if that's what you mean. [14:49:51 CEST] <Zexaron> some kind of timecode stuff [14:50:06 CEST] <Zexaron> which is needed for accurate VFR [14:50:08 CEST] <JEEB> Zexaron: the matroska time base is adjustable, unlike MPEG-TS [14:50:22 CEST] <JEEB> but only in tens if I recall correctly [14:50:35 CEST] <Zexaron> What about decimal? [14:50:47 CEST] <JEEB> as in, you cannot set a time base like 1001/24000 for matroska [14:50:58 CEST] <JEEB> which is why all 24000/1001 fps content in matroska is effectively VFR :P [14:51:21 CEST] <JEEB> MPEG-TS is as BtbN said - 1/90000 time base (and that one's hard-coded) [14:51:29 CEST] <atomnuker> afaik a lot of demuxers break when the matroska timebase isn't 1/1000 [14:51:51 CEST] <JEEB> hard-coding is best coding [14:54:01 CEST] <Zexaron> JEEB: If you recall the previous discussion about captuing frames, I did more thinking and I've theorized why does it have to be VFR and timecodes anyway, why couldn't the video just be CFR at 60FPS, ffmpeg would simply put the frames together like this, wait longer (just wait, no empty or dummy frame) or delay the frames if it's faster than a fixed FPS [14:54:48 CEST] <Zexaron> There's no need for the video to actually be VFR [14:54:58 CEST] <JEEB> if your source is rendering faster than your expected rate then you can't just delay the frames can you? [14:55:05 CEST] <JEEB> you can only do CFR if you know your source to be CFR [14:55:23 CEST] <JEEB> or if you are ready to do hacky crap like dropping frames or generating frames out of thin air [14:55:30 CEST] <JEEB> which I kind of thought where something you wouldn't like to do [14:55:49 CEST] <BtbN> just using timecodes is usually easier anyway [14:55:53 CEST] <JEEB> you mean timestamps [14:56:07 CEST] <BtbN> In the most simple case, you set the timebase to 1/60 or whatever, and advance by 1 evers frame [14:56:11 CEST] <JEEB> matroska uses the wording "timecodes" which has driven people insane for years [14:56:55 CEST] <Zexaron> Not exactly delay, delay as in queued, stored in buffer if the encoding can't happen fast enough due to CPU constraints, and I was already hoping to set ffmpeg's encoding to low priority and make it use less threads [14:58:22 CEST] <Zexaron> What Im getting at is "construction" ... lets say ffmpeg encoder is building a syscraper, no matter how fast or slow the resources, materials, concrete, steel is coming in, you have the same distance between floors [14:58:41 CEST] <Zexaron> or some kind of analogy [14:59:06 CEST] <JEEB> do you always have the same distance between floors? [14:59:20 CEST] <JEEB> I'd expect the emulation rendering speed to differ per frame depending on various variables [15:00:03 CEST] <Hello71> I think it assumes frame perfect rendering [15:00:06 CEST] <Hello71> or at least no skipping [15:00:37 CEST] <JEEB> yes if you are rendering a demo or something you can just make the emulator as a whole work at non-1x speed [15:00:48 CEST] <JEEB> but I'd guess most use cases that's not the case :P [15:00:56 CEST] <BtbN> timestamps are just easier [15:01:01 CEST] <Zexaron> Yes it does differ but also game speed differs, if it gets below 60 or 30 the time moves slower, audio is slower, like a time machine, so there's no point having recreated that in the resulting video [15:01:16 CEST] <BtbN> CFR is a special case of VFR anyway, so if you implement the later, you get it for free [15:01:21 CEST] <Zexaron> Because game time/speed is tied to FP [15:01:22 CEST] <Zexaron> FPS* [15:02:32 CEST] <Zexaron> And the game runs at it's normal speed only the predefined FPS it's suppose to run at, 30 FPS is the most common followed by 60 [15:04:42 CEST] <Zexaron> So does that make sense? [15:05:27 CEST] <Zexaron> I hope there's not some kind of thing I'm missing there that would make that theory invalid [15:06:16 CEST] <Zexaron> btbN it has to be official spec CFR for editors to have no problems with the resulting file, this is not the case currently [15:06:36 CEST] <BtbN> What is official spec cfr? [15:06:50 CEST] <Zexaron> so if it's VFR with timecodes approx that "it looks like CFR" that's not enough [15:07:42 CEST] <Zexaron> well if there's no such spec, I guess, if all the frame have exact time delay that's CFR [15:07:57 CEST] <Zexaron> and feeding that to a video editor should be bug free [15:07:58 CEST] <JEEB> duration you mean :P [15:08:08 CEST] <JEEB> and editors will always have issues, don't worry about that [15:08:34 CEST] <JEEB> but given that editors can nowadays read both MPEG-TS and MP4 and MOV I'm pretty sure the basic support for things is there [15:08:56 CEST] <BtbN> Just put in constantly incrementing timestamps yourself, if you want the video to match game fps, and not emulation fps [15:09:02 CEST] <Zexaron> With dolphin's framedumping files they have a lot more than usual, it's one of the main issues, so I was told [15:09:39 CEST] <JEEB> without further technical details I cannot comment on that whatsoever. [15:09:40 CEST] <JEEB> but anyways [15:09:50 CEST] <JEEB> I did ask you to look into some initial time base [15:09:57 CEST] <JEEB> at which teh emulator as a whole works :P [15:10:06 CEST] <JEEB> that can be 1/60, or that can be something else [15:10:14 CEST] <JEEB> figure that out if there's one [15:10:28 CEST] <JEEB> then you can stick your rendered stuff onto that time line [15:11:05 CEST] <Zexaron> BtbN: for what reason would I want it to match game fps? In my logic, at least my opinion, I do not want to have a video that recreates the game speed, that's what the existing solution is already doing, it's not VFR even tho everyone's saying it is, MPC-HC reports 60FPS ... the VFR part might just be 0.9 FPS jitter aroung 60 [15:11:34 CEST] <BtbN> If you dump every frame the game renders, that's what you get [15:11:35 CEST] <Zexaron> It may technically be VFR, but in practice it's not trying to be VFR [15:11:48 CEST] <BtbN> Didn't you just ask the exact opposite minutes ago? [15:11:56 CEST] <BtbN> How to make it _not_ cfr? [15:13:04 CEST] <Zexaron> Yes because I was looking at that method, but I have simultaneously been thinking about going totally different, I have doubts it has to be VFR [15:13:31 CEST] <Zexaron> different approach, from what the familiar developers were saying needs to happen in the end [15:13:51 CEST] <Zexaron> "We do timecode adjusting so the resulting video always plays back at normal speed, not the speed it was rendered at" [15:14:11 CEST] <BtbN> The emulation running anywhere between full speed 60 fps and anything less because lagging is a prime example of VFR [15:15:42 CEST] <Zexaron> With more info I started theorizing why bother getting timecodes if you're going to have to adjust them later anyway to make it look like CFR [15:17:13 CEST] <Zexaron> So that's when I had in mind, why wouldn't FFmpeg just pick a bunch of frames and put it together with constant frame time, same way you would pick a folder full of PNG image files, put them together with -r 30, then all this implmentation would be a convenient way to do this on the fly without the user having to run ffmpeg separately later [15:18:15 CEST] <Zexaron> the rate just has to be exactly for the specific game, or else it wouldn't playback at normal gamespeed. [15:19:00 CEST] <Zexaron> Nobody even wants any other speed except normal, afaik. [15:19:24 CEST] <JEEB> well even if the renderer itself would be slown down it would still know when the frame is supposed to be shown, I'd think? [15:19:49 CEST] <JEEB> so as long as that darn thing does its job, your job as the encoder is to just use that timestamp and pass it on to encoding [15:20:26 CEST] <JEEB> doing any sorts of comparisons against -r is just fucking futile since generally you don't want to drop or duplicate any frames - which is exactly what that -r option does (it uses ffmpeg.c's dumb as fuck "vsync" logic) [15:21:25 CEST] <JEEB> and hopefully you can get the audio in a 1x speed from the emulator's audio output :P [15:21:26 CEST] <Zexaron> Indeed that's exactly what I wanted to eventually make sure ... if ffmpeg supports such a thing I'm trying to get at, "construction" like that [15:21:56 CEST] <JEEB> FFmpeg's API literally just fucking lets you pass in raw video and audio frames in and codes them [15:22:12 CEST] <BtbN> ffmpeg generally doesn't care about time at all [15:22:17 CEST] <BtbN> it just passes through timestamps [15:22:28 CEST] <BtbN> And converts them if the timebase can't be kept [15:22:48 CEST] <Zexaron> And I already knew the next step if it doesn't, make support for that in FFmpeg first, if necessary, I could try but my skills/time, not sure yet [15:23:00 CEST] <JEEB> what the flying fuck are you speaking about at this point [15:23:20 CEST] <Zexaron> A feature like that might also come useful elsewhere not just in this dolphin-emu case [15:23:23 CEST] <JEEB> ok, if you have the emulation running at <1x then the frames will render slower than they'd be rendering [15:23:37 CEST] <JEEB> but the renderer should still understand what the supposed shown timestamp should be, no? [15:23:41 CEST] <JEEB> or at least fucking hopefully [15:23:57 CEST] <JEEB> you should not be attempting to fucking filter the stuff if your idea is to get what the emulator is feeding you [15:24:09 CEST] <JEEB> not dropping input frames nor duplicating them [15:24:13 CEST] <Zexaron> the gamespeed changes by proportionally, 60 is 100% game speed [15:24:19 CEST] <JEEB> yes, I FUCKING UNDERSTAND THAT [15:24:33 CEST] <JEEB> THAT IS EXACTLY WHY ALL YOU NEED IS THE FUCKING TIMESTAMP OF WHEN THE FRAME WAS SUPPOSED TO GET RENDERED [15:24:48 CEST] <JEEB> even if it comes early or late the media framework does not fucking care [15:24:56 CEST] <JEEB> as in, wallclock wise [15:25:23 CEST] <BtbN> You don't even need that. The emulator dumps out images, and you know the framerate, as it's NTSC/PAL/... [15:25:42 CEST] <BtbN> It only gets complicated when you want to match emu render speed, not intended games speed [15:25:50 CEST] <JEEB> well I'm trying to not set up too many expectations depending on how the emulator will develop etc [15:25:59 CEST] <BtbN> And since you aparently don't want that... I fail to see what you even want [15:27:08 CEST] <JEEB> what can get funky is audio output if your game time goes <1x. but I hope the emulator can output audio at 1x speed in some way [15:27:24 CEST] <JEEB> nothing to do with video since if you have a known maximum time base according to which all frames come through [15:27:52 CEST] <JEEB> and the fact that the emulator does not drop frames by itself, of course - which is why timestamps are nice if it ever drops or whatever [15:28:10 CEST] <Zexaron> Well maybe I simply don't know how to explain properly, so you guys don't understand what I mean by "construction" ... it may be something that's never been known to FFmpeg or similar, but I didn't knew that [15:28:38 CEST] <Zexaron> I confirmed from others that it never drops frames to keep going [15:28:50 CEST] <BtbN> I don't even know what you are talking about [15:28:57 CEST] <Zexaron> If it can't render it, it slowls down, halts [15:29:02 CEST] <BtbN> video timestamps are a pretty well established thing, nothing there to invent really [15:29:06 CEST] <JEEB> ^ [15:30:24 CEST] <Zexaron> Sure, timestamps for a CFR 60 FPS should all be same distance apart right, which means it's soemthing fixed that FFmpeg can figure out on it's own, no need to have emulator feed it and do checks [15:30:39 CEST] <JEEB> what the fuck are you once again talking about [15:31:03 CEST] <JEEB> anyways, if your input never drops then you still do the same as usual. you get the supposed presentation time of that given frame and pass it along on the time base that you have. everyone's happy [15:31:08 CEST] <JEEB> there's nothing to do there, literally [15:31:16 CEST] <JEEB> with video that is [15:31:57 CEST] <JEEB> with audio you just hope that the engine can output the audio samples as-is so that when you play them you get the original 1x speed :P [15:32:22 CEST] <JEEB> if that is true, then the whole encoding and multiplexing part is very simple [15:32:38 CEST] <Zexaron> Yes, see this is what I have a hard time explaining, all FFmpeg would do is to insert frames into a CFR video, timestamps are all known, tarts at 0 and for 60FPS video is what 16.6ms or 8.3 ms or how much is it again apart, they're all same distance apart, you don't even need to calculate them every time, can even have a predefined list stored in a template [15:33:02 CEST] <Zexaron> I can do that with Excel right now [15:33:30 CEST] <JEEB> you're not having an issue explaining the fact that currently it seems like all your frames are fucking +1 on some fucking time base [15:33:43 CEST] <JEEB> it's just that I don't want to make the design such that if the design ever changes you get butt-fucked [15:33:51 CEST] <JEEB> and thus I am talking about timestamps and getting them from the renderer [15:33:59 CEST] <Zexaron> You don't need any timebase either, when framedumping starts, starts from zero, from that video [15:34:16 CEST] <JEEB> TIME BASE IS FUCKING TICKS PER SECOND YOU FUCKING IMBECILE [15:34:18 CEST] <Zexaron> if I understood timebase correctly, heh still a few holes [15:34:37 CEST] <JEEB> I'm pretty sure I went through this shit during all the nights I've been up trying to explain you shit [15:35:40 CEST] <JEEB> so if the fucking video renderer knows it's supposed to be 1/60 or 1/50 or 1001/60000 it can signal that [15:35:46 CEST] <JEEB> that is your fucking video time base [15:35:57 CEST] <JEEB> then if nothing ever gets dropped all the presentation time stamps would be +1 [15:36:00 CEST] <JEEB> on that fucking time base [15:36:10 CEST] <JEEB> this should not be a fucking hard premise to understand [15:36:25 CEST] <Zexaron> maybe ffmpeg doesn't have an internal timer, it doesn't have to be in ffmpeg, ofcourse that timecode stuff can be in the main program, in the framedumping code, running on another thread yes [15:36:36 CEST] <JEEB> stop thinking about wallclock time [15:36:38 CEST] <JEEB> STOP [15:36:43 CEST] <JEEB> THIS HAS NOTHING TO DO WITH WALLCLOCK [15:37:46 CEST] <Hello71> sounds like some proprietary crap where it has to have a bajillion adapters. can't possibly be something simple [15:37:53 CEST] <Zexaron> Sorry I'm just using one term to talk them all, I heard about them a couple of days ago for the first time, I'll get up to speed sooner than later tho [15:39:13 CEST] <JEEB> it's the presentation side wallclocks, sure. but literally the only thing you have to do with the multimedia APIs is that you pass the right timestamps on the correct time base along [15:39:52 CEST] Action: Mavrik gives a cookie to JEEB . There, there. [15:39:55 CEST] <Mavrik> Timebase is a hard concept :/ [15:40:23 CEST] <JEEB> I'm still trying to explain to him that he doesn't need anything from FFmpeg if his input gives him the time base and the presentation time stamp of both audio and video to him [15:40:58 CEST] <Zexaron> JEEB: I understand that part, rendered suppose to know it has to be 1/60 .. it can signal that, but why does it have to signal each frame, before the framedumping starts the emulator and ffmpeg API code can negotiate the normal-speed frame rate, then FFmpeg would just fill things based on what is predefined, in a CFR video there's no difference, what's there to figure out, it's all the same, if it's fixed [15:41:31 CEST] <JEEB> why the fuck would FFmpeg suddenly start touching your input in inappropriate ways? [15:41:38 CEST] <JEEB> if you don't require any of that [15:41:39 CEST] <Zexaron> Technically the emulator doesn't know anything, we just see it as slow-game speed if FPS dips [15:42:00 CEST] <JEEB> also at the very fucking least you want some sort of fucking timestamps to start getting the video and audio synchronize'able [15:42:26 CEST] <JEEB> unless your sources can 100% note that both start at exactly the same time and you don't need to adjust anything [15:42:52 CEST] <JEEB> I just know way too many cases of where audio frames don't exactly align with video frames [15:42:57 CEST] <Zexaron> Oh yes ... but as it is right now, video and audio is separate, audio is also tied to game-speed as FPS is, it'll slow down proportionally [15:43:31 CEST] <JEEB> anyways, just fucking deal in fucking presentation time stamps because that way if any of the fucking details changes in anywhere else you don't have to fucking rewrite your fucking bullshit [15:43:49 CEST] <JEEB> you can have a fucking piece of shit code hard-coding +1 for each fucking frame [15:43:52 CEST] <JEEB> as the fucking PTS [15:43:58 CEST] <JEEB> from the fucking 1/frame_rate time base [15:44:02 CEST] <JEEB> yes, you can have that [15:44:03 CEST] <JEEB> SURE [15:44:11 CEST] <JEEB> BUT IS THAT A GOOD FUCKING SOLUTION GODDAMNIT [15:44:14 CEST] <Zexaron> But I am, I was willing to rewrite the whole frame dumping logic ... even parts of the rendering if necessary [15:44:25 CEST] <Zexaron> It's like 10 years old [15:44:26 CEST] <JEEB> IF THE FUCKING RENDERER KNOWS THE FUCKING PRESENTATION TIME OF A FRAME [15:44:34 CEST] <JEEB> AND IF IT KNOWS THE VIDEO FUCKING TIME BASE [15:44:38 CEST] <JEEB> vittu saatana [15:44:44 CEST] <JEEB> why do I even bother with you [15:44:45 CEST] <TheAMM> saatanan tunarit [15:45:05 CEST] <JEEB> sorry for the caps, at this point I fucking give up and maybe do something more productive [15:45:36 CEST] <TheAMM> I haven't read this all but hasn't this been going on for a week [15:45:59 CEST] <TheAMM> And the situation is exactly "the renderer has a timestamp" [15:46:39 CEST] <Zexaron> Well, I'm wasn't assuming this method would be 100% perfect, it could simply be one option which may be useful for other reasons, there are debugging reasons which may seem like wrong way of doing things ofcourse [15:48:50 CEST] <pagios> hello, can i serve an m3u8 file from server1, and include in that file the .ts files to be consumed from server2? [15:49:32 CEST] <JEEB> have you tried looking at the AVOptions of the HLS "muxer" :P [15:49:55 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#hls-2 [15:50:18 CEST] <Zexaron> I apprecitate the fact he's trying to explain the correct way of how things are generally done, this isn't a general case tho, but I failed to explain in the beginning that this is just research and I'm creating a protoype for this method, the idea may not exist nor be possible with ffmpeg currently, and what my disagreement is that everyone thinks it wouldn't work, I was looking for an explanation why CFR wouldn't work but nothing is [15:50:18 CEST] <Zexaron> conclusive, so that has strengthened my interest into making a prototype to see how would it work versus the existing solution and others [15:51:09 CEST] <JEEB> there is nothing that you've mentioned that isn't possible with FFmpeg's APIs [15:51:19 CEST] <JEEB> it just doesn't make any fucking sense for your fucking encoding module [15:51:38 CEST] <JEEB> to be something more than the receiving end of push_rendered_frame(EmulatedFrame) [15:51:52 CEST] <JEEB> where EmulatedFrame would have the actual image data of course, but also the fucking timestamp [15:52:11 CEST] <JEEB> because that way you leave the actual timestamp handling etc to the stuff that comes fucking before you [15:52:18 CEST] <JEEB> you can, yes, just fucking hard-code things [15:52:30 CEST] <JEEB> but that's fucking last resort when no-one in the project wants to work with you and you need to ship something [15:52:37 CEST] <pagios> talking to me? [15:52:45 CEST] <JEEB> no, only the HLS ffmpeg-all page was for you [15:53:12 CEST] <Zexaron> Maybe the issue is, i don't understand why it doesn't make sense, I would need a working example, or more easily, some kind of explanation or animation to explain that, I can ofcourse take a break and let this thing sit for awhile and do more learning on other stuff I don't know yet and then come back to it [15:53:41 CEST] <JEEB> why would you not like whatever comes before you handle the "when is this picture supposed to be rendered" part?! [15:53:51 CEST] <JEEB> if it can just pass you on that information from the fucking renderer [15:53:58 CEST] <JEEB> there are things to try if that isn't possible, yes [15:54:11 CEST] <JEEB> but generally a fucking capture thing should not do things it isn't required to [15:54:52 CEST] <JEEB> and if the renderer only knows its own time base (50Hz or 60Hz or 60/1.001Hz) [15:55:00 CEST] <JEEB> then it can do the +1 calculation on that time base [15:55:14 CEST] <JEEB> but you as teh capture component should not fucking be doing +1 calculations [15:56:12 CEST] <JEEB> if your job is to take in video frames and push them forwards then that's your job. multimedia is already hard enough so if require the frames to come with a timestamp then that's just super [15:56:23 CEST] <JEEB> *so if you require [15:57:03 CEST] <JEEB> I really fail to understand what the fuck is so hard about grasping such a design that you have a component that does a single. thing. [15:57:15 CEST] <Zexaron> So you mean, you did understood my idea, and instead of having FFmpeg calculate or read from template, you would have the emulator report the timestamp or whatever when that frame was suppose to be rendered, in 60FPS it would be rendered on XYZ, but we got it on YXX, that's one way of doing it, hoever I'm still not sure if we're on the same page [15:57:48 CEST] <JEEB> FFmpeg shouldn't be calculating anything. the API client handles making sure there are timestamps at all. [15:58:19 CEST] <JEEB> but yes, the part of the emulator feeding you frames should know the presentation timestamp on the time base it's rendering things at [15:58:23 CEST] <JEEB> so if it knows [15:58:28 CEST] <JEEB> just pass it on together with the frame [15:58:38 CEST] <pagios> JEEB, say a client asks for an m3u8 and gets 1.ts , 2.ts , 3.ts in that file so he starts consuming, now 3.ts is reached, how does he know how to consume 4.ts? [15:58:46 CEST] <pagios> it is not in the playlist that he initially opened [15:59:01 CEST] <furq> i only briefly looked at the existing code you posted for this but it was making use of some gamestate ticks value that was provided from elsewhere in the emulator [15:59:28 CEST] <furq> it shouldn't be difficult to derive your pts values from that [16:00:11 CEST] <JEEB> and if there were bugs due to you calling at the later stage (during encoding), then the logic passing completed frames from the renderer to you can just do that [16:00:21 CEST] <JEEB> it shouldn't be the capture component coming up with the timestamps [16:00:22 CEST] <JEEB> :P [16:01:15 CEST] <furq> if you have absolute 100% faith in your heart that the emulator will definitely give you frames with monotonically increasing timestamps for audio and video then by all means ignore the timestamps it's giving you [16:01:24 CEST] <furq> but if you did have that faith you probably wouldn't be here asking these questions [16:01:50 CEST] <Zexaron> JEEB: Unfortunately I don't have enough dolphin-emu rendering experience yet to know if those time things are or can be known ahead like that, if you say that's the way to go ofcourse this will be considered and support would be written to make that happen if it's not too hard, I'll surely pass the idea forward to the appropriate people, I apologize as I'm a bit stubborn sometimes I want to reinvent the wheel [16:02:41 CEST] <Zexaron> I'm also the wrong guy attempting to do this, others just don't have time, or they would done it already [16:02:56 CEST] <JEEB> Zexaron: just fucking think of the component you're supposedly working about. it takes frames in, and they are supposed to be presented at time X on the time line. a "capture" component would not start coming up with the presentation time at that point, no? [16:03:28 CEST] <JEEB> you are supposed to get the image together with a timestamp. and just work with that. [16:03:33 CEST] <JEEB> division of responsibilities [16:05:06 CEST] <furq> https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/… [16:05:18 CEST] <furq> i assume this is what you want [16:06:50 CEST] <JEEB> yea, that exactly seems like the wrong place for that. and that should only be done if the rest of the framework cannot give you a presentation time stamp [16:07:09 CEST] <JEEB> that might have historical reasons for that to be done in the capture component [16:08:06 CEST] <JEEB> and yes, I just checked that VideoInterface::GetTargetRefreshRate gives you a frame rate, although it seems like /1001 time bases are not supported [16:08:15 CEST] <JEEB> so the video interface already knows something about timing :P [16:08:59 CEST] <JEEB> so why wouldn't it (or the renderer) be the one giving you the timestamp together with the image data [16:09:31 CEST] <Zexaron> VideoInterface has it's separate frame rate, if you caught that last time I mentioned, it's sort of the analog TV , VPS is the framerate of the VideoInterface, sometimes game FPS would be lower, but usually they should both be the same [16:10:08 CEST] <Zexaron> Yes that's completely fair and correct, for a true capture VFR video [16:10:13 CEST] <JEEB> FUCKING STOP [16:10:19 CEST] <JEEB> this has nothing to do with that [16:10:47 CEST] <JEEB> also get out of your head real rendering frame rates (as in, the speed of the renderer that can be higher or lower than the emulator's 1x rate) [16:11:07 CEST] <Zexaron> that might be useful for something I migt just have it as an option ... it's not? [16:11:56 CEST] <JEEB> what we need to know is the time base of the emulation's video, and the time stamp. [16:12:08 CEST] <JEEB> how quickly or slowly that fucking frame got rendered in real time we don't fucking care [16:12:48 CEST] <JEEB> also this effectively means we don't have to care about if the emulator is VFR or not (aka does the game speed change depending on the video rendering speed) [16:13:33 CEST] <JEEB> I hope this makes it clear? [16:13:34 CEST] <Zexaron> I'm not sure how it is with other emulators, but I hope you are takin VI (VideoInterface) cause it's would matter in some ways [16:13:34 CEST] <Harzilein> with, say, vice, i'd expect starting media output, setting pause, and pressing "advance frame" to call ffmpeg every frame, telling it about new data [16:16:04 CEST] <Zexaron> I ofcourse agree tthat real-time doesn't matter yes [16:16:05 CEST] <Hello71> stop trying to jam everything into your 80s video model [16:16:35 CEST] <JEEB> Hello71: this has nothing to do with 1980s. just that he seems to have a tough understanding that the stuff could just give him the info he needs in a good design [16:17:19 CEST] <Hello71> seems to me like Zexaron is insisting to write everything in terms of his proprietary interfaces (some of this proprietary stuff is just in Zexaron's head) [16:17:59 CEST] <JEEB> Zexaron: anyways, don't you agree that as a capture component your starting point is to just get a frame, and its timestamp? no? [16:18:10 CEST] <JEEB> as in, when it is supposed to be presented on the presentation time line [16:18:53 CEST] <JEEB> and the presentation time stamp in this case is when it should be shown when the capture is being played, that is [16:20:36 CEST] <JEEB> and whether that presentation time has anythign to do with the actual time line of the thing you're capturing shouldn't be *your* concern [16:21:03 CEST] <JEEB> so for example with somethign that runs at <1x speed and doesn't drop frames, you would get the 1x speed presentation time stamp [16:21:13 CEST] <JEEB> do you understand this far? [16:23:01 CEST] <Zexaron> Yes I do that now, ofcourse, I just didn't thought it be that easy [16:23:37 CEST] <Zexaron> The question is then how accurate that time stamp for 1x would be [16:23:54 CEST] <Zexaron> If we tried to compare it to CFR, but okay, not necessary, no need to then [16:24:18 CEST] <w1kl4s> every time i see a question about frames with ffmpeg i'm glad i listened to JEEB and used VapourSynth :P [16:24:45 CEST] <durandal_1707> i gonna ban w1kl4s right now [16:24:55 CEST] <w1kl4s> rip [16:24:56 CEST] <JEEB> Zexaron: if the thing creating those frames is giving you the timestamp, you trust that. if that has problems, it's not an issue that the *capture* component should be fixing [16:25:08 CEST] <JEEB> do you understand this? [16:25:33 CEST] <Zexaron> I would have, eventually, got to the point, that I was trying to make a case for CFR, to eventually figure out there's going to be minute differences that would make it out of sync with audio/video, which JEEB it's only the list of TODOs, to make ffmpeg also include audio into it, so ofcourse the way you're saying it probably the way to go [16:26:06 CEST] <JEEB> even if it was CFR I don't think it's the *capture* component's job to make up that timestamp [16:26:11 CEST] <JEEB> like, seriously [16:26:41 CEST] <JEEB> whatever gives you the frame upwards in the chain gives you the timestamp and the frame data [16:26:42 CEST] <Zexaron> I suppose, I just hope that that's improvable on their end, I hope some kind of limitation isn't hit, because the emulator tries to be very accurate to how the console worked, but I might be jumping ahead so let's just forget about this unless it's an issue [16:27:48 CEST] <JEEB> Zexaron: and as I said, if there's no better approximation than the +1 on the frame rate time base then that's it. but that's not *your* problem if what you're handling is the *capture* part [16:28:59 CEST] <Zexaron> I guess we're trying to do a lot of things there, make it 1x speed, not the realtime, and make it glitch free, and video editor friendly ... [16:29:50 CEST] <JEEB> well all of this me trying to preach what in my opinion is good software design is because IIRC you were talking about rewriting the stuff [16:29:55 CEST] <Zexaron> Well, I don't actually know the video editor issues right now, someone else mentioned that, but AVI ofcourse has to go, so it would be MKV [16:30:33 CEST] <JEEB> if you just want to do bug fixes then your shit's your shit and I have no idea what your issues are and if they are even on your side of the code [16:30:52 CEST] <JEEB> and to be honest, it's usually a full-time support thing to figure those things out and I have enough projects I support :P [16:31:21 CEST] <Zexaron> I t was more of a, I'll give it a try, it may take me several weeks because I'll probably take large breaks in between [16:32:13 CEST] <Zexaron> No none of the github stuff is my code, that's still Master, I didn't do much of my code yet [16:33:01 CEST] <Zexaron> I tried figuring it out before I go write some code in a rabbit hole for nothing [16:33:20 CEST] <JEEB> also to be honest I would first just actually look at the issues at hand rather than grabbing at things randomly. knowing the problem space is good. [16:33:43 CEST] <JEEB> also for the record, if your output is supposed to be supported by editors as-is then Matroska is not going to fly :P [16:34:23 CEST] <Zexaron> Indeed that was the next thing, now matroska aint going to fly, ... so many factors [16:34:44 CEST] <JEEB> just fucking look at your fucking problems first with teh current solution and actually *technically* figure them out [16:34:47 CEST] <Zexaron> That's why I speculated about MPEG-TS earlier [16:34:54 CEST] <JEEB> not fix them, but understand what sort of issues those are [16:38:10 CEST] <Zexaron> I should go first figuring out fully how the current thing works in detail then, I ofcourse expected eventually have to do it [16:40:42 CEST] <JEEB> a lot of it just seems like general libavformat/libavcodec usage and the doxygen as well as examples under docs in the FFmpeg code tree should generally help with understanding how things hopefully should be used that are there [16:41:29 CEST] <JEEB> of course the module also seems to attempt to set a constant frame rate timestamp there which IMHO is not a capture component's job, but leaving that aside it would make sense for you to actually look into what are the issues people are having with this crap [16:41:44 CEST] <JEEB> that way you then know if you need a full rewrite or for some issues you can just do bug fixes :P [16:51:21 CEST] <Zexaron> The issues are all over the place, it puts too much load on GPU as it's doing some whatever-with-frames as FFmpeg isn't actually encoding on GPU obviously and generally it takes too much resources it than should if FFmpeg was ran independently [16:51:32 CEST] <Zexaron> I might not be the one fixing all of that ofcourse [17:25:20 CEST] <kepstin> the extra load on the gpu would be downloading the image from vram into system ram. unavoidable with any software encoder [17:25:58 CEST] <kepstin> theoretically avoidable when using on-gpu hardware encoders, depending on vendor and api. Doing that might require tighter integration with the renderer [17:31:36 CEST] <Zexaron> Yeah there's quite a back-and forth in Dolphin, including emulated ram which resides in RAM or VRAM ... not sure how much the option "GPU Texture Decoding" counts in this case [18:53:36 CEST] <Zexaron> I was also thinking of a raw I-frames output in the ffmpeg, that should be straightforward to do in the API right, I wasn't thinking about quality here because this would be helpful for debugging if it makes a lot less impact on performance, but also a good way to store each frame in one file if one would want to do that for some reason [18:54:09 CEST] <Zexaron> and the filesize isn't that of a problem in a debugging case as it's temporary allocation [19:11:43 CEST] <kepstin> Zexaron: doing that wouldn't make any difference in terms of actually writing the frame dumper, it's just a single configuration option that you set on the encoder. [19:12:06 CEST] <kepstin> depending on the encoder, I-frame-only may be slower since it has to output at higher bitrate. [19:17:09 CEST] <Zexaron> Really? But it's a SSD, and it's not like it would take all the speed of a HDD imo [19:51:30 CEST] <kepstin> no, in terms of cpu usage [22:03:29 CEST] <poutine> I'm experiencing a bug in software when PTS rolls over in a HTTP Live Stream where I have not captured the segments the rollover occurs in. Any ideas how I could generate that or get an example mpeg ts file that contains a PTS rollover? [22:04:21 CEST] <poutine> afaik, PTS is stored as a 33 bit signed integer, and most rollovers implement it that it just continues to increment as if it were an unsigned integer [22:04:51 CEST] <JEEB> libavformat unless you disable wrap-around handling should at the very least handle it once (although I would hope for longer) [22:05:58 CEST] <JEEB> HLS might or might not have to signal it separately to base MPEG-TS though [22:05:59 CEST] <JEEB> not sure [22:06:00 CEST] <poutine> JEEB, My bug is actually in converting embedded 608 captions to WebVTT in near real time with the timestamping, I really just need an example mpeg ts file with an rollover how most encoders would deal with it (Wowza, akamai, etc) [22:06:16 CEST] <poutine> I know there's the setpts filter but that doesn't seem to modify the start_pts of the file [22:06:57 CEST] <poutine> you'd think there'd be example files of weird conditions like this for OSS developers, but I'm having trouble finding it [22:07:05 CEST] <poutine> think I might just have to capture ts chunks when it occurs [22:07:47 CEST] <JEEB> I'm pretty sure there are, although for me libavformat itself handles this :P [22:07:47 CEST] <poutine> afaik I'd just need to start pts ~8589934592 [22:08:08 CEST] <JEEB> yes, you can create one yourself with libavformat if you just start far enough and mux enough packets [22:08:29 CEST] <poutine> Ok I will check out that angle, thanks [22:08:58 CEST] <JEEB> also is your input or output HLS? [22:09:03 CEST] <JEEB> which is giving you the problems :P [22:09:16 CEST] <poutine> input is HLS, output is WebVTT [22:09:32 CEST] <JEEB> yea, then the HLS "demuxer" might not be marked for the discontinuity handling [22:10:48 CEST] <JEEB> yea, I have a feeling it isn't [22:11:15 CEST] <JEEB> yea, it would have to have AVFMT_TS_DISCONT [22:11:22 CEST] <JEEB> in the flags [22:12:06 CEST] <poutine> so I have not seen any discontinuities in these HLS streams, so I think they just let it overflow into the signed bit, and continue until it wraps to 0, so 0-8589934592 -> -4294967296 -> 0 [22:12:18 CEST] <poutine> w/ 2 rollovers [22:12:44 CEST] <poutine> I will just capture some segments, I think that's the easiest path, thanks for the pointer to libavformat, but think this might be the easiest route [22:12:54 CEST] <JEEB> the MPEG-TS thing is 33 bits unsigned I think [22:13:07 CEST] <JEEB> so there's no negative part to fall into [22:13:19 CEST] <JEEB> it just goes back to around zero [22:13:29 CEST] <poutine> http://libav-users.943685.n4.nabble.com/How-to-handle-33-bits-rollover-in-M… <- kind of touches on it [22:14:27 CEST] <JEEB> in 2012 libavformat added basic support for wrap-around handling [22:14:34 CEST] <JEEB> and since then I think it's been improved a few times [22:14:49 CEST] <JEEB> at least the samples with singular wrap-arounds have passed through fine in my case [22:14:55 CEST] <JEEB> as in, libavformat handles them [22:15:04 CEST] <JEEB> I get constantly rising timestamps [22:15:21 CEST] <JEEB> some people say that the wrap-around handling in lavf only works once, but I'm not sure of that [22:15:24 CEST] <poutine> I'm not actually using ffmpeg/libavformat for parsing NAL units and pulling the captions [22:15:28 CEST] <poutine> just trying to generate a test case with it [22:15:33 CEST] <JEEB> right [22:16:00 CEST] <JEEB> I think for wrap-around handling MPEG-TS specifically I would probably take a look at upipe :P [22:16:25 CEST] <JEEB> https://github.com/cmassiot/upipe/blob/master/lib/upipe-ts/upipe_ts_demux.c… [22:16:30 CEST] <JEEB> this function specifically [22:16:45 CEST] <poutine> Thanks for that pointer that's very useful [22:24:16 CEST] <Zexaron> Side research ... would it be possible for those timecodes to pack into a file and for ffmpeg to use it later? [22:25:13 CEST] <Zexaron> I struck one other idea, framedumping and running ffmpeg while trying to play the game is in it self the biggest issue that lowers the frame rate [22:25:14 CEST] <furq> no but you can have other muxing tools use it later [22:25:22 CEST] <furq> mkvmerge and l-smash both support timecode files [22:25:32 CEST] <JEEB> you are using the APIs [22:25:40 CEST] <JEEB> how does not using timestamps there help you in any way or form? [22:25:48 CEST] <JEEB> anyways, sorry for commenting [22:25:49 CEST] <furq> i didn't want to ask that [22:27:05 CEST] <Zexaron> Well, I kinda struck the idea while I was making an image sequence video with Vegas PRO earlier, to 60FPS, I played while dumping to PNGs, PNG dumping is slow, only 2-8 FPS, resulting video is kinda weird, it seems 60FPS ingame time but it's speed up considerably [22:28:00 CEST] <Zexaron> The emulator it self may not be actually trying to output a frame when it has to, that's another thing I don't know, I only know it doesn't skip frames but whatever that counts [22:28:17 CEST] <furq> you don't know that the game itself is running at 60fps though [22:29:37 CEST] <Zexaron> Well it's suppose to, it's programmed that way, normal speed at 60, currently only PNG image dumping is supported that's why it was so slow, I tried if I could make it ouput RAW and do second step, at least for this experiment https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/… [22:30:02 CEST] <iive> you might want to capture to huffyuv, it's fast, lossless, and produces big files [22:31:17 CEST] <Zexaron> there was a nother option there yeah [22:32:08 CEST] <Zexaron> I'll see if some of the video lossless options have a significant benefit, might not need to do the image thingy I was playing with [22:32:38 CEST] <Zexaron> Someone said before I-frame only would be even harder on CPU, true ? [22:34:40 CEST] <Zexaron> JEEB: The idea bases on what you said before, it would just output timecodes to file, one way is a big ZIP with image frame files and timecode for each, and it be processed all later when gameplay stops, inside dolphing, not as an external step [22:35:21 CEST] <Zexaron> Now if there's a lossless video codec/format that be faster than that, sure [22:35:29 CEST] <iive> sorry, i thought you are using ffmpeg... [22:35:46 CEST] <durandal_1707> Zexaron: JEEB left, he could not consume too much crap [22:37:11 CEST] <Zexaron> The whole thing why ffmpeg runs at the same time the emulator is dumping was because of filesize issues, but with dolphin people telling me that this is a niche feature and most average users use OBS for streaming, this has opened more possibility now to produce really good looking, accurate videos [22:37:32 CEST] <Zexaron> And for a small subset of users who are technical the space is a nonissue [22:39:01 CEST] <Zexaron> durandal_1707: If he heard me out to the finish ... he assumed wrong, but that's understandable for today oh well [22:39:30 CEST] <Zexaron> This idea doesn't go agains his, but whatever [22:58:02 CEST] <Hello71> you don't *have* an idea [23:07:25 CEST] <kepstin> the way to get good looking accurate videos is 1. to get the emulator to push frames to the encoder as they're rendered, and also say what the time each frame corresponds to is, and 2. use ffmpeg with a configurable codec [23:27:46 CEST] <angular_mike_2> I'm trying to simulate someone skipping through the video by tapping right arrow key. How can I drop N frames after every M frames? Or is there a way to programmatically modulate frame rate, the way you can apply jitter to effects in some video editors? [23:33:15 CEST] <ChocolateArmpits> angular_mike_2, did you look into "select" filter? [23:58:07 CEST] <Zexaron> kepstin, alright, so that would just automatically produce a CFR video ? [23:58:26 CEST] <Zexaron> in this case the emulator should be pushing out frames 60FPS [00:00:00 CEST] --- Sat Oct 20 2018

1 0

ffmpeg-devel.log.20181018
by burek 19 Oct '18

19 Oct '18

[00:04:39 CEST] <philipl> BtbN: I'm going to rework your change a bit to reduce the number of #ifdefs. I'm guessing you don't care if I do. [00:04:54 CEST] <BtbN> I already reduced them quite a bit [00:06:11 CEST] <philipl> eg: We can have one get_external_foo method. [00:16:35 CEST] <philipl> https://github.com/philipl/mpv/commit/ad4e136af4aeed92e828f1c3b99b11754b5e7… [00:16:43 CEST] Last message repeated 1 time(s). [00:16:43 CEST] <philipl> https://github.com/philipl/mpv/commit/9d0e73adcf795b90b80aaef4e9791a423af7c… [00:16:46 CEST] <philipl> rather [00:17:16 CEST] <philipl> BtbN: My modified versions of your changes. [00:19:35 CEST] <BtbN> the memory_fd extension can totally exist on Windows btw. [00:19:41 CEST] <BtbN> ifdefing it out seems wrong [00:19:59 CEST] <philipl> It can exist, it won't be used. [00:20:04 CEST] <philipl> So the symmetry seems desirable. [00:27:50 CEST] <BtbN> If that doesn't matter, sure [00:29:56 CEST] <cone-421> ffmpeg 03Carl Eugen Hoyos 07master:e90d4e92729c: lavc/mjpegdec: Support 2:3 subsampling. [00:43:24 CEST] <BtbN> The LunarG Vulkan SDK actually comes with a 100MB .lib file for shaderc [00:43:29 CEST] <BtbN> but it's for MSVC builds only [00:43:40 CEST] <BtbN> trying to link gives me several 100MB of missing references on link [00:43:59 CEST] <BtbN> anyway, managed to build one myself now with the posix enabled toolchain [00:44:08 CEST] <JEEB> congrats [00:46:28 CEST] <BtbN> philipl, if I do "./mpv.exe --gpu-api=vulkan --vo=gpu --hwdec=nvdec ..." and I get "VO: [gpu] 1920x1080 cuda[nv12]" it means it works, right? [00:46:47 CEST] <JEEB> yes, it means you're getting nv12 from hte "cuda" decoder [00:47:05 CEST] <JEEB> lavc doesn't return you nv12 so it's definitely some sort of hwdec [00:47:07 CEST] <BtbN> More interested if it actually render them via vulkan, or does sw download and re-upload or something [00:47:19 CEST] <JEEB> --log-file=mpv_sucks.log [00:47:27 CEST] <JEEB> higher verbosity and timestamps etc [00:48:06 CEST] <JEEB> and if you just want the terminal stuff, then --msg-level=module=verbose where module is the module you care about (vd maybe?) [00:48:38 CEST] <JEEB> (or debug instead of verbose, which is what log-file also uses) [00:49:11 CEST] <BtbN> "[ 0.758][d][vo/gpu/cuda-nvdec] vk_external_handle[1][0]: 0000000000000994 1036800 2073600" yeah, it's doing what it should. And it looks reasonable [00:49:34 CEST] <JEEB> cool [00:50:58 CEST] <philipl> BtbN: yeah, you succeeded! [02:34:09 CEST] <cone-421> ffmpeg 03Michael Niedermayer 07master:4e19cfcfa394: avformat/utils: Fix integer overflow in discontinuity check [02:34:10 CEST] <cone-421> ffmpeg 03Michael Niedermayer 07master:079d1a7175c4: avformat/utils: Never store negative values in last_IP_duration [02:34:11 CEST] <cone-421> ffmpeg 03Michael Niedermayer 07master:c6282141cba2: avcodec/ra144: Fix integer overflow in add_wav() [02:34:12 CEST] <cone-421> ffmpeg 03Michael Niedermayer 07master:25eb10d941f3: avcodec/ilbcdec: Limit indexes in create_augmented_vector() [02:34:13 CEST] <cone-421> ffmpeg 03Michael Niedermayer 07master:d01788665767: avcodec/ilbcdec: Fix multiple invalid left shifts [02:34:14 CEST] <cone-421> ffmpeg 03Michael Niedermayer 07master:d7dbad12f820: avcodec/ilbcdec: Fix multiple integer overflows [02:34:15 CEST] <cone-421> ffmpeg 03Michael Niedermayer 07master:f72b9904fefa: avcodec/h264_cavlc: Check mb_skip_run [02:37:25 CEST] <tmm1> i'm trying to figure out where in the code the h264 parser splits two fields into separate packets [04:18:01 CEST] <tmm1> found http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/175525 which could be adapted to a bsf [07:33:11 CEST] <cone-330> ffmpeg 03Karthick Jeyapal 07master:444cdb422d3c: avformat/dashenc: Dont ignore the codec tag from codec parameters [10:08:20 CEST] <durandal_1707> what about adding (a)replace filters? they would replace (samples/)frames from one stream with another stream for some duration in random position in stream [10:24:31 CEST] <cone-330> ffmpeg 03Paul B Mahol 07master:bf5bdbdb9267: avfilter/af_adelay: do not crash if allocation of chandelay failed [11:01:53 CEST] <ubitux> durandal_1707: ablend? [11:01:56 CEST] <ubitux> (hello) [11:02:54 CEST] <ubitux> (with mode=overlay for replacing or sth) [11:03:46 CEST] <ubitux> because you may want to mix it and not just replace it completely [11:03:59 CEST] <ubitux> ablend is a bad name though [11:08:10 CEST] <durandal_1707> ubitux: you are back! [11:08:22 CEST] <ubitux> yeah i should, pretty soon [11:08:32 CEST] <ubitux> i'm sorry for leaving again, i thought i had time, but i didn't [11:08:49 CEST] <ubitux> but i finally moved home after a few months, fucking pain [11:20:53 CEST] <JEEB> I moved two years ago and now they're cutting all the trees :< [11:29:34 CEST] <atomnuker> I haven't moved yet and they've probably already ruined wherever I would move to [11:38:56 CEST] <cone-330> ffmpeg 03Paul B Mahol 07master:0ce7005d34e2: avfilter/vf_lensfun: use av_freep [11:38:57 CEST] <cone-330> ffmpeg 03Paul B Mahol 07master:2d9c290a2ffc: avfilter/vf_lensfun: use av_malloc_array() [12:14:56 CEST] <durandal_1707> NEW FILTER in nearest filter factory! chromahold [14:13:21 CEST] <ubitux> durandal_1707: http://www.ipol.im/pub/art/2018/23/ [15:13:02 CEST] <victorqueiroz> What should I do when I receive "missing picture in access unit with size 24" error? [18:41:54 CEST] <cone-330> ffmpeg 03Aman Gupta 07release/4.0:380bc8585c75: Revert "avcodec/cbs_h264: silence errors about end_of_seq nalus" [19:02:31 CEST] <thebombzen> I'm trying to figure out how to make "-r" work the same way for streamcopy as it does for decoding but I cant' make heads or tails of ffmpeg.c's process_input_packet [19:02:38 CEST] <thebombzen> since I've never worked on ffmpeg.c before [19:03:08 CEST] <thebombzen> where does it check for the value of "-r" as an input option when decoding? [19:05:23 CEST] <BtbN> isn't -r just some magic that makes the demuxer in question return EAGAIN until the timestamp isn't too early anymore? [19:18:44 CEST] <JEEB> not that I think... [19:20:38 CEST] <JEEB> thebombzen: fftools/ffmpeg_opt.c: "set frame rate (Hz value, fraction or abbreviation)", "rate" }, [19:20:48 CEST] <JEEB> see which struct member that goes into [19:21:00 CEST] <thebombzen> aight thx [19:21:38 CEST] <JEEB> BtbN: IIRC -r with encoding just uses ffmpeg.c's vsync to duplicate/drop decoded frames [19:21:58 CEST] <BtbN> oh, -r, not -re, nvm [19:22:08 CEST] <JEEB> yea, -re sleeps [19:22:29 CEST] <JEEB> also -re is very fun when you find someone trying to use it with MPEG-TS or so [19:22:35 CEST] <JEEB> suddenly wild discontinuity [19:22:41 CEST] <JEEB> and suddenly the thing is waiting for N hours :P [19:23:15 CEST] <kierank> lol [19:52:22 CEST] <jamrial> durandal_1707: be consistent with using float constants and standard float c functions in your sinc source patch [19:53:06 CEST] <jamrial> i see powf() but then sin(), plus lots of constants missing the f suffix while others don't [21:43:14 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:d7731ea9d43c: avcodec/proresenc_aw : use scan table from prores_data file [21:43:14 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:1a45b12cdc41: avcodec/proresenc_aw : use AVframe primaries, transfert, colorspace for frame header instead of default (unknown, unknown, Rec601) [21:43:14 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:cea5e90bde4a: avcodec/proresenc_aw : use qp close to the official encoder [21:43:14 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:98637be753df: avcodec/prores_enc : not calculate dct a each quantif search step [21:43:14 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:c51b36ec8f70: avcodec/proresenc_aw : add support for prores 444 [21:43:14 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:e832d769f465: avcodec/proresenc_aw : use for frame flag in the header the same value than the official encoder [21:44:52 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:658bbc006002: swscale/x86/rgb2rgb.asm : add Ivo Van Poorten name to the top of the file [21:44:53 CEST] <cone-571> ffmpeg 03Martin Vignali 07master:db4771af8196: swscale : add YA16 LE/BE output [22:18:01 CEST] <j-b> 'morning [22:19:11 CEST] <durandal_1707> sweet dreams [22:19:36 CEST] <atomnuker> how commercial is demuxed on a scale of the fsf to apple? [22:22:30 CEST] <j-b> atomnuker: 6/10 [22:22:42 CEST] <j-b> 10/10 being apple [22:23:37 CEST] <durandal_1707> VDD is 3/10 ? [22:23:47 CEST] <atomnuker> ibc is 8/10? [22:24:03 CEST] <atomnuker> would nbc then be 10/10? [22:24:26 CEST] <j-b> durandal_1707: sounds about right [22:24:33 CEST] <j-b> fsf being 1/10 [22:24:40 CEST] <j-b> NAB would be 9/10 [22:26:40 CEST] <atomnuker> wonder what would 10/10 be [22:26:49 CEST] <atomnuker> oh it has to be that apple dev event [22:27:06 CEST] <j-b> WWDC [22:27:10 CEST] <j-b> or Google I/O [22:27:55 CEST] <atomnuker> +microsoft's thing [22:28:23 CEST] <j-b> Microsoft thing is less bad than WWDC [22:28:27 CEST] <j-b> it's way more technical. [22:30:11 CEST] <wbs> the actual sessions at WWDC are rather technical [22:31:57 CEST] <j-b> the ambiant around them are not. [22:33:02 CEST] <wbs> especially the keynote [22:37:46 CEST] <j-b> and the groupies... [00:00:00 CEST] --- Fri Oct 19 2018

1 0

ffmpeg.log.20181018
by burek 19 Oct '18

19 Oct '18

[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

1 0

ffmpeg-devel.log.20181017
by burek 18 Oct '18

18 Oct '18

[00:12:40 CEST] <jamrial> jkqxz: right, nevermind, the ff_stream_add_bitstream_filter() call happens only with mp4 encapsulated packets [00:12:54 CEST] <jamrial> for some reason i assumed it was always inserted [00:16:54 CEST] <jkqxz> So, IVF only? [00:18:50 CEST] <jkqxz> (Or should MKV also be included since vp9_superframe is included unconditionally there?) [00:19:27 CEST] <jamrial> yes, vp9_superframe should be a dep for both matroska and ivf [00:20:01 CEST] <jamrial> as i said, it prevents muxing split packets that neither muxer can detect and promptly abort [00:21:29 CEST] <jkqxz> I don't think you can do that anyway, because the muxer will fail at init with VP9 if the BSF isn't there. [00:24:01 CEST] <jamrial> true [03:26:25 CEST] <BBB> tmm1: Im at demuxed this week </late> [03:52:51 CEST] <peloverde> me too [08:26:20 CEST] <BBB> peloverde: woohoo! see you tomorrow :) [16:56:17 CEST] <durandal_1707> Compn: can you search web for ScreensDMO.ax file? [17:43:08 CEST] <durandal_1707> posted on reddit, looking if anything useful appears [17:44:50 CEST] <BtbN> philipl, do you have a commandline I can test with? I have no idea how mpv works. [17:45:45 CEST] <philipl> mpv --gpu-api=opengl --hwdec=nvdec --msg-level=vo=debug <file> [17:46:12 CEST] <philipl> At the top, it'll say if it's using angle or not. I would assume not unless you went out of your way to install it. [17:46:22 CEST] <philipl> There's some other command line option to force the gl context. [17:46:57 CEST] <philipl> --gpu-context=win [17:47:24 CEST] <philipl> That should get you to symbol loading failing. [17:50:13 CEST] <philipl> BtbN: I think the issue is the simplified load/sym calls in the header aren't enough. [17:50:22 CEST] <philipl> w32dlfcn is a lot more elaborate. [17:50:42 CEST] <BtbN> it really only does security checks. A plain stupid implementation should work [17:51:22 CEST] <BtbN> also... why is my mpv.exe 1.3GB in size [17:51:41 CEST] <BtbN> Just noticed that it took weirdly long to copy it around [17:51:52 CEST] <philipl> Better strip those symbols. :-) [17:52:17 CEST] <BtbN> now it's 163M [17:54:19 CEST] <BtbN> "./mpv.exe --gpu-api=opengl --hwdec=nvdec --msg-level=vo=debug /mnt/d/Cache/game.of.thrones.s01e01.1080p.mkv" seems to work fine, but it "Cannot load cuInit" [17:54:49 CEST] <philipl> Yes. That's what I saw [18:00:40 CEST] <BtbN> I do wonder how it can compile, but not actually load the symbols [18:01:35 CEST] <philipl> You don't need the cuda dll around to compile do you? [18:02:42 CEST] <BtbN> no [18:02:58 CEST] <BtbN> But the loading of the DLL seems to work [18:03:02 CEST] <BtbN> but loading the symbol fails [18:06:45 CEST] <philipl> Weird. [18:12:29 CEST] <BtbN> A stupid simple test program works [18:12:53 CEST] <BtbN> https://bpaste.net/show/c7037d22a702 [18:13:25 CEST] <BtbN> https://bpaste.net/show/cb742c9ea259 [18:14:29 CEST] <philipl> urp [18:25:16 CEST] <BtbN> I have no idea what's going wrong when mpv does it [18:28:28 CEST] <BtbN> I have a slight suspiciou it has something to do with it also linking against ffmpeg, which also loads the symbols, but differently [18:35:05 CEST] <BtbN> oh, I have a suspicion [18:36:54 CEST] <thebombzen> so apparently you can modify the timestamps of the AVPacket returned by av_read_frame to change the speed of video [18:37:14 CEST] <BtbN> That's how timestamps work, yes? [18:37:17 CEST] <thebombzen> however ffmpeg.c has no way to harness this [18:37:30 CEST] <thebombzen> would it make sense to add an input option -force_framerate [18:37:46 CEST] <iive> that's how video stamps work, audio is a little bit special [18:38:05 CEST] <philipl> BtbN: your suspicion is? [18:38:49 CEST] <thebombzen> yea I'm just referring to video here. I'm thinking of adding an input option -force_framerate that just modifies the timestamps on the AVPacket returned by av_read_frame for a video stream [18:39:08 CEST] <thebombzen> to harness that feature on the ffmpeg.c CLI, but I'm not entirely sure if this is the best way to go about doing it [18:39:23 CEST] <thebombzen> it might also make sense to implement as a bitstream filter [18:41:03 CEST] <BtbN> philipl, http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=commitdiff;h=5054a… [18:41:27 CEST] <BtbN> mpv is probably built in WString mode [18:43:03 CEST] <JEEB> :) [18:43:28 CEST] <BtbN> I wonder why this even compiled without a single warning?! [18:43:32 CEST] <JEEB> yea [18:43:40 CEST] <JEEB> something definitely skipped a check somewhere [18:43:48 CEST] <JEEB> or auto-converted in a header [18:43:57 CEST] <BtbN> This is gcc-8.2.0 as well [18:44:00 CEST] <philipl> BtbN: cool. So with that, it worked? [18:44:03 CEST] <BtbN> I'd expect it to be warn-happy [18:44:11 CEST] <BtbN> no idea, didn't test yet, but it was definitely wrong [18:45:41 CEST] <BtbN> Yeah, load error is gone with that [18:46:09 CEST] <BtbN> I can't really see if it's now using cuda hwaccel. Everything else looks the same [18:46:42 CEST] <philipl> It'll say something like: VO: [gpu] 1920x1080 cuda[nv12] [18:46:55 CEST] <BtbN> yes, it does do that [18:47:00 CEST] <philipl> Then you did it. [18:47:09 CEST] <philipl> You're the hero [19:18:22 CEST] <BtbN> philipl, I updated the 8.0 branch and created an up to date 8.1 branch of the SDK, to avoid higher driver requirements where they are not needed. [19:26:23 CEST] <philipl> OK [19:30:29 CEST] <BtbN> So, not to get this Vulkan stuff working [19:32:26 CEST] <philipl> yay! [19:32:32 CEST] <philipl> s/not/now/ [19:32:59 CEST] <philipl> For reference: https://github.com/NVIDIA/cuda-samples/blob/master/Samples/simpleVulkan/vul… [19:33:06 CEST] <philipl> That has both linux and win32 interop in it [19:33:56 CEST] <BtbN> They have the cuda side stuff different? [19:34:08 CEST] <philipl> Just the handle type [19:34:31 CEST] <BtbN> https://github.com/NVIDIA/cuda-samples/blob/master/Samples/simpleVulkan/vul… [19:35:17 CEST] <BtbN> hm, that looks like normal C, why is it .cu? [19:35:23 CEST] <philipl> filename weirdness [19:37:46 CEST] <JEEB> has to be special because nvidia and cuda? [19:38:45 CEST] <BtbN> I guess it's to make it be compiled with nvcc, not normal cc [19:39:28 CEST] <BtbN> Is Vulkan on Windows 64bit only? [19:46:23 CEST] <BtbN> this looks way messier than I expected [19:46:36 CEST] <philipl> I think it is [20:37:46 CEST] <cone-539> ffmpeg 03bnnm 07master:02ea060b2976: avformat/xwma: fix WMAv2 with incorrect bit rate [20:38:14 CEST] <BtbN> philipl, mingw dxgi header don't have some required stuff... [20:40:37 CEST] <JEEB> release or master? [20:40:44 CEST] <JEEB> unfortunately they often only have some stuff in master [20:43:10 CEST] <BtbN> master has DXGI_SHARED_RESOURCE_READ/DXGI_SHARED_RESOURCE_WRITE [20:43:17 CEST] <BtbN> ".dwAccess = 0x80000001, // DXGI_SHARED_RESOURCE_READ | DXGI_SHARED_RESOURCE_WRITE" it is... [20:47:39 CEST] <cone-539> ffmpeg 03Carl Eugen Hoyos 07master:b9136c1b9003: lavf/mxfenc: Remove a write-only variable. [21:13:00 CEST] <BtbN> philipl, https://github.com/BtbN/mpv/commit/f858fec34d5078934d6723c4137f578d76e5e927 WinAPI is just lovely [21:13:48 CEST] <JEEB> fancy [21:17:38 CEST] <BtbN> it's far from done btw [21:40:24 CEST] <nevcairiel> do you even need the security attributes, its optional [21:41:03 CEST] <nevcairiel> its probably only needed if you want cross-process access or shit like that [21:42:03 CEST] <nevcairiel> heck the entire struct may be unneeded if you want default access [21:42:19 CEST] <nevcairiel> (which is READ|WRITE) [22:11:16 CEST] <BtbN> no idea, this is straight from nvidias example [22:12:51 CEST] <BtbN> https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.ht… yeah, it can just be NULL. [22:13:02 CEST] <BtbN> that simplifies things... a bit [22:29:01 CEST] <BtbN> philipl, so, how do I use this vulkan interop? [22:50:21 CEST] <BtbN> "[vo/gpu/vulkan] Failed initializing SPIR-V compiler!" hm [22:50:58 CEST] <atomnuker> nvidia deprecated their glsl to spriv extension, didn't they? did they disable it as well? [22:51:18 CEST] <atomnuker> if so you'll have to compile shaderc, good luck [22:53:37 CEST] <philipl> 2I had to compile shaderc yeah [22:53:43 CEST] <philipl> It is not bad on linux [22:53:56 CEST] <philipl> it expects you to checkout all the dependencies into its tree [22:54:11 CEST] <philipl> the nvidia extension is gone in 4xx drivers. [22:54:15 CEST] <philipl> which you need for interop [22:54:34 CEST] <BtbN> This is Windows. It's probably a hot mess. [22:55:58 CEST] <JEEB> shaderc is OK as long as you just vendor it with your app [22:56:16 CEST] <JEEB> (in other words, no .pc file and nobody suddenly breaks your build) [22:58:08 CEST] <BtbN> Doesn't seem like mpv does that [22:58:32 CEST] <philipl> I had to do CFLAGS/LDFLAGS to find libshaderc for my linux build. [22:58:42 CEST] <philipl> So no danger of .pc messing with you... [22:59:13 CEST] <JEEB> BtbN: I've wondered but then people want to package it... [22:59:34 CEST] <JEEB> although someone on #mpv just built it with mingw-w64 so apparently it works right now [23:00:05 CEST] <JEEB> philipl: yes, the "you have to know which flags" is as fun as always :) [23:09:10 CEST] <BtbN> ../third_party/glslang/StandAlone/StandAlone.cpp:1157:29: error: 'thread' is not a member of 'std' [23:09:11 CEST] <BtbN> fun [23:09:53 CEST] <philipl> newer libstdc++! [23:10:25 CEST] <nevcairiel> and dont go around blaming windows again, msvc supports that since 2012! [23:11:21 CEST] <BtbN> this is mingw [23:11:35 CEST] <BtbN> And I'm running on gcc 8.2.0 [23:12:03 CEST] <philipl> https://stackoverflow.com/questions/37358856/does-mingw-w64-support-stdthre… [23:12:06 CEST] <philipl> ? [23:12:17 CEST] <nevcairiel> mingw and threading is a terrible situation [23:12:45 CEST] <nevcairiel> i wonder if their threading library stopped sucking these days [23:14:11 CEST] <kierank> tmm1 on stage [23:14:14 CEST] <BtbN> Do the "official" mpv Vulkan builds for Windows also do all that shit? [23:14:28 CEST] <philipl> There are no official builds, per se. [23:14:43 CEST] <JEEB> not sure which modules lachs0r enables but his docker images are used in the CI [23:14:54 CEST] <philipl> You can ask shinchiro what he does too [23:15:02 CEST] <philipl> His builds have vulkan [23:15:17 CEST] <JEEB> he seems to build his own toolchain and all that crap, while I'm mostly just using fedora's standard toolchain with updated CRT and headers [23:15:17 CEST] <BtbN> I have to re-build mxe [23:15:22 CEST] <BtbN> this is gonna take an hour [23:15:58 CEST] <BtbN> They have a special target for that [23:16:13 CEST] <JEEB> ok, travis seems to build vulkan [23:16:16 CEST] <JEEB> https://travis-ci.org/mpv-player/mpv/jobs/442733580 [23:16:27 CEST] <JEEB> so in theory you could use lachs0r's sysroot [23:16:35 CEST] <philipl> but only for linux... [23:16:58 CEST] <BtbN> I have x86_64-w64-mingw32.static right now. Need to re-build the toolchain to get x86_64-w64-mingw32.static.posix [23:17:45 CEST] <nevcairiel> all these weird complicated projects to build cross-compilers [23:17:58 CEST] <BtbN> mxe seems to be the most decent one so far [23:18:05 CEST] <nevcairiel> i just use a shell script to invoke the configures etc [23:18:20 CEST] <BtbN> Doing that for all the stuff mxe does would take me a week [23:20:21 CEST] <nevcairiel> I strongly believe that one should at least once figure out how to build stuff, which is also why I really dislike these things like "Media Autobuild Suite" or however that thing is called that everyone uses to build ffmpeg and x265 these days. If you cant figure out how to build stuff, then just download binaries :) [23:20:38 CEST] <BtbN> There are no binaries for this [23:20:45 CEST] <BtbN> mxe is basically cross-compiler-emerge [23:20:58 CEST] <nevcairiel> there is plenty cross-compiler binaries [23:21:07 CEST] <BtbN> The compiler is the smallest problem of this [23:22:09 CEST] <BtbN> It would take me a whole day to setup the environment mxe gives me within half an hour build time [23:25:30 CEST] <wbs> fwiw, libc++ supports c++11 threads without any of the winpthreads mess inbetween. I've got prebuilt toolchains for windows now if anyone wants to give them a try; https://github.com/mstorsjo/llvm-mingw/releases [23:26:44 CEST] <nevcairiel> the typical mingw stuff is so messy because it tries to get by without shipping its own C l ibrary or C++ library, and instead use the one in Windows, but at least for C++, they are really bad at it [23:28:34 CEST] <nevcairiel> because it ends up an odd mixture of components, some from GCC, some from mingw, some from Windows itself [23:29:25 CEST] <wbs> fwiw, my toolchains also target ucrt instead of the old deprecated/discouraged msvcrt.dll [23:33:28 CEST] <wbs> ... and they support address sanitizer [23:36:52 CEST] <jamrial> now that's interesting [00:00:00 CEST] --- Thu Oct 18 2018

1 0

ffmpeg.log.20181017
by burek 18 Oct '18

18 Oct '18

[00:00:14 CEST] <kepstin> Zexaron: why don't you just use the current emulated wallclock time as the frame pts? [00:00:17 CEST] <Zexaron> But I'm theorizing, even if the gamespeed is bound to FPS, but we know at which FPS the game has to run at and we know that at that FPS it's running normal speed, so I don't see why CRF wouldn't work [00:00:48 CEST] <kepstin> like, if you know what time the frame is supposed to be on a clock, then that's a pts value right there. [00:01:01 CEST] <Zexaron> kepstin: it's old code done by many people adding things to it, everyone knows it's bad, I was never a developer ... until now [00:01:35 CEST] <kepstin> (also, crf is an x264 quality setting, do you mean cfr?) [00:02:24 CEST] <Zexaron> Sorry I mean constant FPS, fixed frame rate [00:03:06 CEST] <kepstin> if the emulator renders and outputs every single frame - it doesn't skip frames - then storing it into the container as constant framerate makes sense. [00:03:06 CEST] <Zexaron> I can actuall ... [00:03:35 CEST] <kepstin> if it skips frames, then you need to have some way to find out how big of a time gap there is between frames. [00:04:13 CEST] <Zexaron> Sometimes the FPS does go higher, the games themselfs have fixed FPS, but some cutsenes run at 60 where the rest of the game is 30, some rare games have uncapped FPS for some scenes [00:05:01 CEST] <kepstin> sounds like you should use vfr and set the frame pts based on an internal clock then. [00:06:30 CEST] <kepstin> (and make sure you're not using avi, since i don't think it supports variable framerate properly, if at all) [00:06:42 CEST] <Zexaron> kepstin: I am digging through this all day today, I found this, I didn't figure out yet if this code makes a real frame drop ( according to the commit message) https://github.com/dolphin-emu/dolphin/commit/3a12c50dc1a5cef46d60e29eb7baf… [00:07:02 CEST] <Zexaron> and more stuff like this https://github.com/dolphin-emu/dolphin/commit/3c65c5f2c53f3efedb3bd94cf1f55… [00:07:45 CEST] <Zexaron> didn't meant to specify specific line on first link, proper https://github.com/dolphin-emu/dolphin/commit/3a12c50dc1a5cef46d60e29eb7baf… [00:08:06 CEST] <Zexaron> the files that are produced are always showing 60 FPS tho ... they're not actually variating [00:08:51 CEST] <Zexaron> so it feels like CFR [00:09:55 CEST] <kepstin> could be an issue with the format context setup, I think you have to set the framerate in the format context to 1/0 or something like that to indicate vfr (the docs and comments in the header say the value to use, I didn't confirm it) [00:10:05 CEST] <kepstin> and of course make sure you're not using avi. [00:10:13 CEST] <Zexaron> but it's still buggy, as reported throught years, I just never dealt with it so I don't know where those issues are exactly, most likely AV sync issues, Dual core mode doesn't work properly, etc [00:10:30 CEST] <Zexaron> That's github, I'm using MKV here in my git repo [00:10:55 CEST] <kepstin> ideally, the renderer in the emulator would be passing the frame dumper a frame along with the timestamp corresponding to when it was rendered [00:11:34 CEST] <kepstin> it looks like right now you're just getting the frame and having to go back and ask the emulator what its current timestamp is - which will be different from when the frame was actually rendered, probably :/ [00:11:44 CEST] <kepstin> (might be close enough tho, i guess) [00:12:15 CEST] <kepstin> other than that, it's just making sure that the pts values are set in the frame before encoding, and are converted to the correct timebase for muxing into the container [00:12:54 CEST] <kepstin> and the ffmpeg libraries should be taking care of the rest, as long as fields in the codec parameters and format parameters are set appropriately. [00:14:56 CEST] <Zexaron> Yeah I should set all the params to be MKV optimized and H264 ... since the code is still largely around AVI/MPEG4, if it ever was correct for that anyway [00:16:15 CEST] <Zexaron> And nobody want's to touch it as it's just a pain in the butt, so I decided to go slowly into it, while having least amount of familiarit since im fresh to dolphin development, not dolphin in general tho [00:18:45 CEST] <Zexaron> I don't have any changes up, I only have this prerequisite PR up, which is required for any further upgrades https://github.com/dolphin-emu/dolphin/pull/7110 - at least on Win64 - since the custom built libs packed-within dolphin only use 2 codecs in them, lots of features cut [00:21:34 CEST] <Zexaron> I have some example videos uploading they should be in a few moments if you want to check out [00:26:03 CEST] <Zexaron> kepstin: https://mega.nz/#F!bKAwDSRK!jFHsIm7w9VKydYmgo62X2A [00:28:18 CEST] <Zexaron> Well most of the time the FPS will be lower than target, not higher, the CFR idea might still work [00:28:34 CEST] <Zexaron> But I need to write all this code to make it work just to see it how it'll work [02:00:12 CEST] <victorqueiroz> All I need now is to get a image from each second of the video and save it to PNG using C API. how can we do that? [02:47:56 CEST] <hiihiii> hi [02:48:29 CEST] <hiihiii> really confuse about the difference between -vsync 0 and -vsync 2 [02:48:49 CEST] <hiihiii> they seem to do the same thing [02:48:51 CEST] <Hello71> seems fairly straightforward [02:48:54 CEST] <Hello71> did you read the man page [02:49:04 CEST] <hiihiii> yes [02:53:34 CEST] <hiihiii> let me rephrase that, what's a good use case for -vsync 0? [02:54:57 CEST] <Hello71> dunno [03:27:17 CEST] <relaxed> hiihiii: if you're capturing a stream from a network attached camera, you might want 0 to avoid dropping any frames [03:27:49 CEST] <relaxed> or timestamps [03:29:10 CEST] <hiihiii> relaxed: in that case you'd be getting VFR, no? [03:30:24 CEST] <relaxed> sure, but the former ensures no frames are dropped [03:31:20 CEST] <relaxed> maybe you want a lossless copy of the stream [03:33:23 CEST] <hiihiii> I've used -vsync 0 on occurrences, sometimes it also gives CFR. [03:34:03 CEST] <Hello71> it gives whatever it gives [03:34:29 CEST] <relaxed> depends on the source [03:39:12 CEST] <hiihiii> I am guessing [03:39:40 CEST] <hiihiii> vsync 0 and 2 both work to retain frames [03:39:59 CEST] <hiihiii> with vsync 2 always being VFR [03:40:21 CEST] <hiihiii> this is the idea I have now. [03:45:10 CEST] <relaxed> if your source is cfr and you're not changing the framerate, how will -vsync 2 make it vfr? [04:01:57 CEST] <hiihiii> i did a test. I'm even more confused now [05:19:57 CEST] <cryptodechange> So I got round to compiling ffmpeg with opencl and tried tonemap_opencl again [05:20:11 CEST] <cryptodechange> Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto_scaler_0' [05:20:20 CEST] <cryptodechange> Failed to inject frame into filter network: Function not implemented [07:43:49 CEST] <rkantos_> Any ideas why an RTP stream freezes every 10-15 seconds? [07:44:07 CEST] <rkantos_> doesn't matter if I'm doing TCP or UDP, over the internet or local lan [09:25:05 CEST] <kuznetsss> Hello, I am writing muxing C++ application using ffmpeg libraries. How can I control output video duration? [14:15:46 CEST] <Zexaron> Hello [14:16:10 CEST] <Zexaron> in ffmpeg code all the HWAccell stuff is ommited where it says "Encoder: unused" [14:16:25 CEST] <Zexaron> only decoder stuff is populated, how so? [14:16:52 CEST] <Zexaron> Can I encode H.264 with HWAccell without actually using another codec/encoder ? [14:23:14 CEST] <BtbN> no [14:23:49 CEST] <BtbN> The hwaccel framework is for the decoders only. Where ffmpeg does the stream parsing, and the hardware the hard decoding work. [14:25:28 CEST] <iive> Zexaron, windows or linux? radeon or nvidia? ffmpeg does support (some) hardware encoders. if you card supports them. [14:27:28 CEST] <Zexaron> Windows 10 RX480, but this is not for me, this is for a project so if it ain't working on a lot of other machines it's I guess not worth attempting it [14:33:30 CEST] <BtbN> Hardware encoders are highly hardware dependend. [14:33:35 CEST] <BtbN> There is no way to generalize them [14:33:57 CEST] <BtbN> While decoding is well defined (bit perfect output for the same input), encoding very much is not [15:52:44 CEST] <Hello71> although sometimes you can jam more layers in there like libva or whatever it's called on windows [15:56:26 CEST] <BtbN> libva is the Intel (and some mesa drivers) backend for hw decoding on Linux [15:56:49 CEST] <BtbN> Windows uses D3D11VA, which works the exact same no matter what hardware. Something that Linux still fails to do. [15:57:02 CEST] <BtbN> That's also only for decoding though [16:04:45 CEST] <Hello71> be more accurate to say open source drivers. like with eglstreams, nvidia refuses to support the open source standard because anti competition [16:06:48 CEST] <BtbN> The Open Source standard does have shortcoming though, they are not wrong about that [16:07:12 CEST] <BtbN> The common alternative is taking its time though. [16:07:28 CEST] <BtbN> It will probably be ready by the time Wayland is actually ready for production use at least [16:10:21 CEST] <Hello71> vaapi is fine though, I haven't heard any complaints about it [16:10:37 CEST] <Hello71> but they insist you use nvenc/dec for extra lockin [16:16:32 CEST] <debianuser> Aren't vdpau and vaapi kind of equivalent on linux? I mean there're both "vdpau-va-driver" (VDPAU-based backend for VA API) and "libvdpau-va-gl1" (VDPAU driver with OpenGL/VAAPI backend), so they should both work no matter which one is provided by hardware/driver? Or not? [16:22:34 CEST] <Hello71> vaapi has more features. in particular it supports more codecs [16:22:42 CEST] <Hello71> vdpau doesn't support vp9 according to arch wiki [16:25:03 CEST] <debianuser> That's easy to check too. Run `vdpauinfo` and `vainfo`, they should list supported codecs/profiles. [16:25:37 CEST] Action: debianuser can't test that, my videocard is older than vp9 :) [16:50:56 CEST] <Syl21> Hi all [16:51:26 CEST] <Syl21> I'm trying to play with FFmpeg for Wallscreen with LiveStream [16:51:58 CEST] <Syl21> I works with crop and udp:// for dividing my incoming video to eatch screen [16:52:06 CEST] <Syl21> Works very great [16:52:44 CEST] <Syl21> Now I'd love to insert a layout temporary on my screen's [16:53:52 CEST] <Syl21> But when I try it FFmpeg wait my UDP to start and freez everything when my layout is finish even using layout=eof_action=pass:repeatlast=0:shortest=0, [16:55:06 CEST] <Syl21> Can somebody help me to make ffmpeg unattend and finish layout by continuing the main [17:01:56 CEST] <cryptodechange> Anyone know how to pass the correct filter parameter for tonemap_opencl and x264? Getting 'Impossible to convert between the formats supported by the filter ' errors [17:08:44 CEST] <relaxed> cryptodechange: pastebin.com your command and output [17:42:41 CEST] <cryptodechange> relaxed: https://pastebin.com/BXcWG406 [17:54:11 CEST] <jkqxz> cryptodechange: tonemap_opencl is intended for use in cases where the frames are already on the GPU (because you used DXVA2 or VAAPI for decode, say). If everything is on the CPU side then just use tonemap. [18:04:03 CEST] <cryptodechange> jkqxz: I am trying to achieve something similar to mpv's tonemapping when encoding in ffmpeg [18:04:53 CEST] <cryptodechange> https://imgur.com/a/ifKhhld [18:05:09 CEST] <cryptodechange> If you compare the mpv screenshots, the first and last image [18:05:33 CEST] <cryptodechange> regular tonemap is much darker compared to mpv's [18:14:55 CEST] <jkqxz> cryptodechange: Try "ffmpeg -v verbose -init_hw_device opencl" to find the OpenCL devices you have available. Then something like "ffmpeg ... -i ... -init_hw_device opencl=cl:X.Y -filter_hw_device cl -vf 'format=p010,hwupload,tonemap_opencl=...,hwdownload,format=nv12' ...", with X.Y set to the device you want to use. [18:16:48 CEST] <cryptodechange> [AVHWDeviceContext @ 0x43db1c0] 0.0: Intel(R) CPU Runtime for OpenCL(TM) Applications / Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz [18:20:29 CEST] <cryptodechange> Cool! It's encoding something [18:20:40 CEST] <cryptodechange> my vf: "format=p010,hwupload,tonemap_opencl=t=bt709:tonemap=hable,hwdownload,format=nv12" [18:25:35 CEST] <cryptodechange> damn, 1fps :D [18:26:07 CEST] <JEEB> would be nice to add an example to the opencl tonemap filter's docs [18:26:27 CEST] <cryptodechange> Will provide a screenshot [18:26:55 CEST] <thebombzen> has FFmpeg gained any new features relating to timestamp manipulation of compressed frames [18:27:18 CEST] <thebombzen> like the equivalent of vf_setpts that works on encoded frames? [18:27:44 CEST] <JEEB> no idea. the API lets you do that but I don't think anyone has cared enough to add recalculation of timestamps to the CLI [18:28:50 CEST] <thebombzen> in theory if someone wanted to add a bitstream filter that just changes timestamps, would that be difficult or is it more of "patches welcome" [18:33:01 CEST] <JEEB> thebombzen: you don't even need that [18:33:41 CEST] <JEEB> you look at where ffmpeg.c calls av_read_frame (most goddamn incorrectly named function evar, since it returns an AVPacket) [18:33:55 CEST] <JEEB> but you can then just poke the DTS/PTS values in that :P [18:34:07 CEST] <JEEB> you can speed things up, you can slow them down etc [18:34:23 CEST] <thebombzen> ah you can just change the pts values of the AVPacket returned by av_read_frame? [18:34:32 CEST] <JEEB> yes [18:35:10 CEST] <thebombzen> would it make sense to add an input option -force_framerate or would you just have to modify "-r" to make it work the way you think it should [18:35:50 CEST] <JEEB> I really don't know [18:35:59 CEST] <thebombzen> would that be a question for the overlords in #ffmpeg-devel [18:36:00 CEST] <JEEB> ffmpeg.c is not exactly well designed [18:36:15 CEST] <JEEB> but yes, sounds like a discussion that could be had there [18:38:12 CEST] <kepstin> as far as it goes, altering the -r input option so it works when copying video probably wouldn't be that hard (although given the ffmpeg.c code, it's probably not entirely straightforwards either) [19:42:15 CEST] <Zexaron> Hello [19:43:46 CEST] <durandal_1707> Hello [19:44:15 CEST] <Zexaron> So do you guys remember those Crysis engine physics barrel explosion showcase, those things weren't rendered in real-time at the time, but with frame dumping and then making the video out at 60 or whatever FPS, now Crysis isn't a game-speed-FPS bound game as opposed to GCN/Wii games [19:45:33 CEST] <Zexaron> So I was theorizing, if the games run at normal speed at their 30 or 60 FPS depending on game, you'd just have to gather all the frames and target that ... would it really be out of sync ? I mean, the fact that FPS is game speed bound may not have any other effect other that it limits the possibiliy in FPS [19:45:57 CEST] <Zexaron> In Crysis or any other PC game you'd be able to pick any FPS and it wouldn't make the game appear to run slower, only choppier [19:46:35 CEST] <Zexaron> The whole reason why is this whole thng about PTS and timecodes and having to check the frame timecodes back and forth is because of the presumption it wouldn't work if the FPS ingame would vary [19:46:44 CEST] <Zexaron> like if it would be jumping from 30-40 etc [19:48:18 CEST] <cryptodechange> It looks like the filter I have applied is wrong [19:48:20 CEST] <Zexaron> I was looking what any of you think about it, so I don't waste many hours trying to create code for this, only to find out it wouldn't work [19:48:22 CEST] <cryptodechange> https://imgur.com/a/k2hIa1F [19:49:02 CEST] <cryptodechange> "format=p010,hwupload,tonemap_opencl=t=bt2020:tonemap=hable,hwdownload,format=nv12" [19:50:39 CEST] <durandal_1707> cryptodechange: mpv may use different parameters [19:50:40 CEST] <cryptodechange> @jkqxz [19:51:08 CEST] <cryptodechange> Hm [19:52:10 CEST] <cryptodechange> The results seem to be identical to https://i.imgur.com/wavwRqM.jpg, in that screenshot I just straight up converted bt2020 to bt709 (zscale=t=bt709:m=bt709:r=tv,format=yuv420p) [19:52:42 CEST] <JEEB> zimg just clamps [19:52:49 CEST] <JEEB> as in, it doesn't do real tone mapping [19:54:02 CEST] <cryptodechange> let me try linear in tonemap_opencl [19:54:04 CEST] <JEEB> yea the default for the opencl tonemap is "none"? [19:54:17 CEST] <JEEB> "tonemap", "tonemap algorithm selection", OFFSET(tonemap), AV_OPT_TYPE_INT, {.i64 = TONEMAP_NONE}, TONEMAP_NONE, TONEMAP_MAX - 1, FLAGS, "tonemap" }, [19:54:20 CEST] <JEEB> if I read this correctly [19:54:35 CEST] <JEEB> you probably want to pick some other algorithm [19:54:36 CEST] <JEEB> lol [19:55:19 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_tonemap_openc… [19:55:58 CEST] <cryptodechange> tonemap_opencl=t=bt2020:tonemap=hable [19:57:26 CEST] <JEEB> that t sets the *output* transfer function for the record [19:57:53 CEST] <JEEB> or that's how I read it [19:59:00 CEST] <cryptodechange> oh so I need to set it to the desired output (bt709)? [19:59:45 CEST] <cryptodechange> full filter params are currently "format=p010,hwupload,tonemap_opencl=t=bt2020:tonemap=linear,hwdownload,format=nv12" [20:07:12 CEST] <Zexaron> no ideas? I guess I'll just have to make an animation to get this point across [20:12:50 CEST] <Mavrik> Zexaron, not sure what's the question? :) [20:21:53 CEST] <cryptodechange> Linear vs. Hable looks exactly the same -> https://imgur.com/a/k2hIa1F [20:22:05 CEST] <cryptodechange> Fairly certain I've got the filter params wrong [20:23:07 CEST] <Zexaron> If it made any difference or not, whether a video game has it's framerate bound to game-speed, when dumping frames and creating a constant frame rate video out of that at the point when the game is suppose to run at normal speed which means we know exactly which FPS is suppose to run at [20:23:20 CEST] <JEEB> cryptodechange: did you keep output transfer as bt2020? [20:24:00 CEST] <cryptodechange> I've tried both bt2020 and bt709 to no different result [20:24:06 CEST] <cryptodechange> transfer=/t= [20:24:16 CEST] <JEEB> I think the default is bt709 so just don't override it I guess [20:24:33 CEST] <JEEB> or actually, not sure wtf the correct usage of that filter is so I'll stay quiet [20:25:09 CEST] <cryptodechange> :D [20:25:36 CEST] <cryptodechange> hopefully jkqxz can chime in on what i've done wrong [20:26:00 CEST] <Zexaron> Mavrik: So if GameA which isn't speed-fps bound runs at 5FPS, you shut down the game, you run ffmpeg and use those images with rate set to 60, you get a smooth 60 FPS video as if the game was running at 60 FPS ... [20:26:46 CEST] <Mavrik> Yes. [20:26:56 CEST] <Mavrik> But the game logic needs to run bound to fps not wall clock. [20:28:54 CEST] <Zexaron> Mavrik: You have GameB which is speed-fps bound, and it's normal speed is at 60FPS, that's the FPS the game has to run, but it doesn't it's varying from 30-40 because it's not running on an official console, but an emulator, so the game-speed is also lower, you dump frames same way you'd dump them with GameA example, as they're ready they're copied to disk, then you use ffmpeg and make a video setting a constant rate to 60 exactly [20:28:54 CEST] <Zexaron> again ... now the question is, would the result be smooth 60 and normal speed or would there be any game-speed flaws and out-of-sync noticable in the video [20:30:13 CEST] <Zexaron> I don't see why there would be, I may not have enough familiarity and background, to me it seems like it would work [20:31:23 CEST] <Zexaron> If the answer to that is that it wouldn't make any effect on game-speed then there's no need to have any kind of pts/timecode stuff whatsoever [20:32:04 CEST] <Zexaron> In reality it's not really writing images to disk, it's outputting directly into FFmpeg [20:32:21 CEST] <Zexaron> For the sake of the question I made it clearer [20:33:03 CEST] <Zexaron> Mavrik: What does game logic have to do ... plus I don't really know anything about what wall clock is yet, i'll go figure that out [20:34:47 CEST] <furq> are you sure this will actually work if you have frameskipping enabled [20:34:53 CEST] <furq> which i assume most people do [20:36:00 CEST] <furq> if the game is just running slow then presumably dolphin has some internal clock that you can derive the pts values from [20:36:10 CEST] <furq> but with frameskip then those frames just won't exist [20:45:26 CEST] <TheAMM> Solution: record a demo, then play back and render later [20:45:32 CEST] <TheAMM> (I'm not serious) [20:45:54 CEST] <furq> i mean that's not an unusual thing to do with an emulator [20:46:09 CEST] <furq> but idk how well it'll work with frameskip [20:46:45 CEST] <TheAMM> I don't know how frameskip works, other than assuming it skips rendering frames [20:47:04 CEST] <furq> that's more or less what it does yeah [20:47:09 CEST] <TheAMM> The idea behind the demo recording was that you wouldn't skip the frames when rendering [20:47:19 CEST] <TheAMM> Assuming input doesn't change on skipped frames [20:47:19 CEST] <furq> yeah i meant i don't know how well the input will sync up [20:47:37 CEST] <TheAMM> :shrug: [20:48:06 CEST] <TheAMM> Certainly there's a need for extra caution in timing the recording [20:48:19 CEST] <furq> i guess you would want to disable frameskip for recording movies anyway [20:48:25 CEST] <TheAMM> Insert skipped frames or something, but I'll leave it at that [20:48:35 CEST] <TheAMM> because it's just "hmms" and "what ifs" from me on this [20:48:43 CEST] <furq> my only real experience of dumping movies from emulators is from mame [20:48:47 CEST] <furq> which is notoriously finicky [20:49:21 CEST] <Zexaron> furq: I was hoping there be no frameskipping, but there is, but it's only used in some circumstances, like savestates, and some other [20:50:05 CEST] <furq> well most emulators have a frameskip option that makes the game run faster if you're not getting 60fps [20:50:16 CEST] <Zexaron> But other solutions could be found for that, like finding why someone implemented skipping in the first place, maybe it was a workaround [20:50:28 CEST] <furq> it's a workaround for slow computers [20:50:32 CEST] <furq> or slow emulators i guess [20:50:34 CEST] <Zexaron> Oh no, I don't think this one has [20:50:38 CEST] <furq> i don't really know how dolphin deals with that [20:51:03 CEST] <furq> i haven't really messed with any emulator for a more powerful system than the psx [20:51:39 CEST] <Zexaron> I'll go ask and make sure ... in the meantime, ffmpeg framedumping is in these 2 files, not that much code at all [20:51:50 CEST] <Zexaron> https://github.com/dolphin-emu/dolphin/blob/944b5fade625823814c04b4acbf835c… [20:52:16 CEST] <Zexaron> https://github.com/dolphin-emu/dolphin/blob/944b5fade625823814c04b4acbf835c… [20:53:09 CEST] <furq> https://github.com/dolphin-emu/dolphin/blob/944b5fade625823814c04b4acbf835c… [20:53:12 CEST] <furq> i guess this is what you're looking for [20:54:16 CEST] <furq> hopefully all the savestate abuse for tas recordings is just dealt with by the input recorder, so it's not something you need to care about [20:54:44 CEST] <Zexaron> I am in day2 of going through the whole thing to figure out how it works and all, but I don't know the whole thing yet ofcourse, unfortunately no prior ffmpeg integration experience either [20:57:26 CEST] <Zexaron> Yeah that's the core of this method, or part, but It would be good to also make sure if FFmpeg can even support such a thing im asking [20:57:43 CEST] <furq> it'll just use whatever pts values you give it [20:58:55 CEST] <furq> if you know the emulator always renders every frame you don't even need to derive the pts values from anywhere, you can just increase them monotonically [20:59:24 CEST] <furq> but failing that it looks like that gamestate ticks value is what you need [20:59:46 CEST] <Zexaron> Instead of all this PTS stuff, I would make another option, CFR, for constant frame rate, so that ffmpeg would simply listen for any frames it receives and construct a video orderly, if it receives more frames than it is defined (60 for example) it wouldn't change the video at all, all the frames in the result would have timecodes that ffmpeg decides should be for a constant frame rate [21:01:11 CEST] <Zexaron> I'll try to not touch gamestate ... or savestate stuff at all, since I have no idea where that comes in, I'll remove any frame skipping and other variables to make this test scenario [21:05:45 CEST] <Zexaron> furq: the code you pasted was actually different before, it's some kind of linux fix and it mentions it drops delayed frames https://github.com/dolphin-emu/dolphin/commit/3a12c50dc1a5cef46d60e29eb7baf… [21:06:20 CEST] <Zexaron> man why does github always tend to use the diff url, so hate that, https://github.com/dolphin-emu/dolphin/commit/3a12c50dc1a5cef46d60e29eb7baf… [21:07:19 CEST] <Zexaron> So does FFmpeg support such a thing ? [21:07:53 CEST] <Zexaron> Also I confirmed there's no frameskipping in the Dolphin rendering, if there is one around framedumping I'll ofcourse get rid of it, for this test [21:09:26 CEST] <relaxed> Does Fiona Glaser still commit to dolphin-emu? This sounds right up her alley [21:36:03 CEST] <victorqueiroz> How can I extract thumbnails using C api? I was able to decode a AVFrame but now I don't know how can I turn it into a PNG image... [21:36:58 CEST] <JEEB> convert the picture into RGB and pass it into a PNG encoder and then muxer [21:37:18 CEST] <JEEB> granted, if you want frame-exact or anything like that, look at ffms2 [21:41:49 CEST] <Zexaron> I think the only way to figure this out for sure is to actually do it, hopefully it's not a waste of time. [21:42:04 CEST] <Zexaron> relaxed: no I don't think in 2 years maybe [21:42:27 CEST] <victorqueiroz> JEEB: Thank you for your answer. I'm already taking a look, but I also want to learn with ffmpeg. Can you tell me how can I convert to RGB and PNG format, please? Apparently the pixel format is YUV420P and when I try to use the AV_CODEC_ID_PNG, I get "The encoder timebase is not set"... [23:54:31 CEST] <cryptodechange> ffmpeg log during my tonemap_opencl test - https://pastebin.com/SJcu5cBG [23:59:33 CEST] <cryptodechange> I cut out a fair bit as it was a huge log file [23:59:35 CEST] <cryptodechange> https://pastebin.com/DPQqCB0w [00:00:00 CEST] --- Thu Oct 18 2018

1 0

ffmpeg-devel.log.20181016
by burek 17 Oct '18

17 Oct '18

[00:00:00 CEST] --- Tue Oct 16 2018 [00:21:37 CEST] <cone-499> ffmpeg 03Anssi Hannula 07master:b2adc3169705: MAINTAINERS: remove myself as hls demuxer maintainer [11:42:56 CEST] <JEEB> durandal_1707: do you see the new framesync affecting split filter? I seem to see a performance blow if I use splitting so that one of the video encoders is having a single thread for example [11:43:14 CEST] <JEEB> and this seems to have only happened with versions that got the new framesync [11:46:21 CEST] <durandal_1707> JEEB: full ffmpeg console output missing ;-) [11:46:38 CEST] <durandal_1707> uncut* [11:47:00 CEST] <durandal_1707> always forgot full phrase [16:45:32 CEST] <BtbN> philipl, one issue I just noticed with your patches is that they cause a compile error in a --disable-vulkan build, hwdec_cuda.c unconditionally includes Vulkan headers. [16:56:31 CEST] <philipl> BtbN: Thanks for the heads up. I haven't tested that. [16:56:37 CEST] <philipl> Did you get any further on it running? [16:56:42 CEST] <BtbN> nope [17:09:28 CEST] <BtbN> Doesn't even start with vulkan/cuda disabled. So I have absolutely no clue what's going on. [17:11:41 CEST] <philipl> weird [17:12:04 CEST] <BtbN> I guess mpv on Windows is just not a well tested target to actually use with non-standard configs [17:51:33 CEST] <JEEB> BtbN: I use it daily [17:52:08 CEST] <JEEB> although I haven't built it lately myself. but given that lachs0r's builds succeed fine I don't see any problem with building for mingw-w64/windows per se [18:49:27 CEST] <philipl> BtbN: I feel slightly bad roping you in even more but: https://github.com/mpv-player/mpv/issues/5978 [18:50:26 CEST] <philipl> shinchiro builds have cuda support: https://sourceforge.net/projects/mpv-player-windows/files/ [19:13:16 CEST] <BtbN> Finally managed to get mpv to build [19:13:24 CEST] <BtbN> had to install HyperV, Ubuntu in there, and mxe in there [19:14:14 CEST] <JEEB> I just used fedora's standard mingw-w64 toolchain with an updated mingw-w64 CRT+headers [19:16:06 CEST] <durandal_1707> JEEB: what about that framesync bug you wanted to report? [19:17:22 CEST] <JEEB> nah, I was just thinking if you have encoders with different amount of input buffering and such, how much framesync can cause blocking in the encoding chain as I think I'm seeing worse performance lately (after the new framesync) with something like yadif+overlay+split [19:18:17 CEST] <durandal_1707> overlay should use multiple cores by now [19:19:24 CEST] <JEEB> yes, overlay doesn't seem to be the problem [19:19:50 CEST] <JEEB> I'm more thinking of the split+encoders with different amount of threads/buffering requirements [19:22:09 CEST] <durandal_1707> JEEB: do you mean split final result to multiple encoders? [19:22:33 CEST] <JEEB> yea, f.ex. yadif+overlay+split+ X scale [19:22:49 CEST] <JEEB> 1080p, 720p, 576p, 480p for example :P [19:27:12 CEST] <JEEB> it seems to especially pop up when you get one of them with a lesser thread count for the encode, like 1. but yea, I just quickly wanted to ask because I haven't gotten any numbers so far [19:30:02 CEST] <philipl> BtbN: w00t. [19:30:27 CEST] <BtbN> I guess some of the dependencies I just ignored are required [19:30:30 CEST] <BtbN> like, lua, jpeg, ... [19:30:30 CEST] <j-b> + int reference_track_dolby; [19:30:32 CEST] <j-b> lol [19:31:46 CEST] <durandal_1707> yea, not acceptable [19:33:36 CEST] <kierank> you can tell it's german company because they always list their directors in communications for some reason [19:35:04 CEST] <durandal_1707> JEEB: well if you know how to reproduce it that would be perfect, i only know that new framesync will buffer much less, and use less memory if one link is faster than other [19:35:45 CEST] <JEEB> durandal_1707: yea it repros in certain cases 100% although I'm still figuring the exact variables [19:36:00 CEST] <JEEB> most likely has to do with various encoders going at different speeds and having a different amount of buffering [19:36:28 CEST] <JEEB> or at least one of those [19:36:46 CEST] <JEEB> since where it breaks live transcoding completely is where there's one profile with threads set to 1 [19:36:57 CEST] <JEEB> but yea, I'll try to figure out more data :P [19:42:30 CEST] <durandal_1707> JEEB: what encoders you use? [19:43:17 CEST] <JEEB> libx264 [19:48:07 CEST] <durandal_1707> and you set one of them to single thread? [19:48:58 CEST] <JEEB> that seems to be the common thread. I'll try to set up a similar stream on another box to make it testable [19:49:17 CEST] <JEEB> because other system with all encoders set to 4 seems to be fairing OK [19:49:29 CEST] <JEEB> then I have another which has threads set to everything from 1 to 8 [19:49:40 CEST] <JEEB> and that used to work OK with a version ~sept 2017 [19:49:56 CEST] <JEEB> then we have newer versions just boom-boom satelliting with the latter thing :P [19:51:38 CEST] <JEEB> I think most people just quick lavfi and instead just add more refs to the AVFrames coming from lavfi [19:51:43 CEST] <JEEB> *quit lavfi [19:51:50 CEST] <JEEB> instead of using the split filter [19:58:16 CEST] <durandal_1707> more shit: https://hydrogenaud.io/index.php/topic,116742 [19:59:52 CEST] <JEEB> you can always find shit [20:00:01 CEST] <JEEB> that's why you need to think positive [20:00:25 CEST] <JEEB> or add ad-blocking filters that block things that gets you down :P [20:24:15 CEST] <tmm1> anyone going to demuxed this week? [20:24:21 CEST] <durandal_1707> me [20:25:46 CEST] <tmm1> cool. some great talks scheduled, looking forward to it [20:33:00 CEST] <durandal_1707> tmm1: all talks are great [20:35:19 CEST] <kierank> tmm1: me, j-b, daemon404, BBB [20:37:28 CEST] <kierank> Can ipads decode periodic intra refresh? [20:42:00 CEST] <tmm1> i think so, but not sure [20:55:47 CEST] <cone-908> ffmpeg 03Aman Gupta 07release/4.0:aec3daa8b4b3: avcodec/cbs_h264: silence errors about end_of_seq nalus [20:55:47 CEST] <cone-908> ffmpeg 03Aman Gupta 07release/4.0:70d0d83d4d61: avcodec/cbs: fix crash in sei_pic_timestamp [20:55:47 CEST] <cone-908> ffmpeg 03Aman Gupta 07release/4.0:8791a1e7de35: avcodec/cbs: ensure user_data is padded for GBC parsing [23:13:18 CEST] <jamrial> tmm1: you need to revert aec3daa8b4b3 from release/4.0 [23:13:25 CEST] <jamrial> that's definitely not a fix [23:15:04 CEST] <cone-908> ffmpeg 03Mark Thompson 07master:f6912cc3e756: trace_headers: Fix memory leaks on syntax read failures [23:26:22 CEST] <tmm1> ah, sorry [23:26:38 CEST] <jkqxz> jamrial: While technically incorrect, it's pretty harmless. The only visible case I can see is that end-of-sequence NALs would have disappeared from trace_headers output (where previously they were warned about). [23:29:04 CEST] <jkqxz> jamrial: I'm not sure which BSF dependency cases are actually useful now. The IVF one, yes. The raw H.26[45]/LATM cases can work without it (since they do all check the stream for the "other" case), so it's not really a dependency though you probably do want to include it for remuxing. [23:29:47 CEST] <jkqxz> The more general containers have the same reasoning for those codecs (and the same checks), but you may not be interested in those codecs. [23:29:56 CEST] <jamrial> the latm case used to strictly check for adts, but now it would only fail while trying to parse it as latm [23:33:26 CEST] <jamrial> does AVOutputFormat.check_bitstream fail and the muxing process aborts if the requested bsfs is not available? [23:35:44 CEST] <jkqxz> I think so? Looks like do_packet_auto_bsf() returns failure, so av_write_frame() will too. [23:42:39 CEST] <jamrial> mmh, then h264/h265/latm should have their respective bsfs as deps to work [23:46:29 CEST] <jkqxz> Er, so they shouldn't have the deps because they might only be used for one case, and are checked at runtime for the other? [23:58:28 CEST] <cone-908> ffmpeg 03Mark Thompson 07master:57f312a34db4: doc/bitstream_filters: Add av1_metadata [00:00:00 CEST] --- Wed Oct 17 2018

1 0

ffmpeg.log.20181016
by burek 17 Oct '18

17 Oct '18

[03:30:44 CEST] <Zexaron> hello [03:31:11 CEST] <Zexaron> how come AV_register_all and the stuff is all deprecated, what are the replacements? [03:43:45 CEST] <Zexaron> allright not neded I guess, works fine without it [06:55:36 CEST] <grosso> hi [06:57:06 CEST] <grosso> I have a little problem: [06:57:45 CEST] <grosso> I'm streaming video with ffmpeg, using mpegts and a udp:// filename [06:58:14 CEST] <grosso> the video is encoded as h264 [06:58:48 CEST] <grosso> the problem is that when decoding, sps/pps nals are missing [07:00:06 CEST] <grosso> how can I force ffmpeg to put that data on the stream? [07:15:22 CEST] <Adcock> furq: I can't understand x axis of the graph. [07:15:33 CEST] <Adcock> Look Opus bitrate 96 [07:16:02 CEST] <Adcock> Then next line says 107 kbps. [10:13:14 CEST] <Adcock> How to achieve visually lossless encoding using vp9 ? [12:03:34 CEST] <Genocide> hi all! its possible to stream videos to rtmp server using playlist or pipe without reconnect? [12:07:40 CEST] <Blacker47> pi-, stop it. [14:28:50 CEST] <victorqueiroz> How to detect the right decoder for the video? [14:30:33 CEST] <BtbN> avformat tells you which codec was found, if it has any idea from the container. If not, you'll have to probe for it. [14:31:15 CEST] <victorqueiroz> This is what I have: [14:31:16 CEST] <victorqueiroz> major_brand=mp42 [14:31:16 CEST] <victorqueiroz> minor_version=1 [14:31:16 CEST] <victorqueiroz> compatible_brands=mp41mp42isom [14:31:16 CEST] <victorqueiroz> creation_time=2018-10-01T12:45:20.000000Z [14:31:24 CEST] <victorqueiroz> I believe it'd be mp42? [14:32:06 CEST] <BtbN> That's the container... [14:32:58 CEST] <Mavrik> I think it's worth figuring out if he's using the API or hacking together something else :P [14:33:03 CEST] <BtbN> avcodec has a probe function, and containers usually tell you what they contain, avformat tells you about it [14:33:34 CEST] <BtbN> When using the commandline there is no point to think about that, since ffmpeg.c does it right on its own [14:33:59 CEST] <victorqueiroz> I'm using the C++ API, actually. I believe it's better to read the command line implementation? [14:34:25 CEST] <BtbN> There is no C++ API [14:34:30 CEST] <victorqueiroz> Sorry, the C API [14:34:47 CEST] <Mavrik> the C API will tell you which codec the stream has [14:34:53 CEST] <victorqueiroz> I'm writting C++ code using it... Like a wrapper to create various formats for a video sent by the client. Not sure how fast that'll be [14:34:55 CEST] <Mavrik> and then you just use avcode_find_decoder or whatever the call is [14:35:07 CEST] <Mavrik> victorqueiroz: there's a whole example/ dir that will give you the code you need :P [14:35:41 CEST] <victorqueiroz> Mavrik: That? https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples [14:36:33 CEST] <Mavrik> yes, the transcoding.c is probably the most interesting [14:36:48 CEST] <Mavrik> or demuxing_decoding.c for only the decode part [14:41:25 CEST] <victorqueiroz> Mavrik: Yes, thank you. [14:41:43 CEST] <victorqueiroz> Apparently two streams h264 and aac. I suppose it's Video and Audio respectively [15:15:14 CEST] <Hello71> or you could just use ffprobe (hell, even ffmpeg will tell you) [15:15:29 CEST] <victorqueiroz> Interesting, now on decoding I'm getting: pps_id 3199971767 out of range [16:48:34 CEST] <grosso> decode_slice_header error [16:48:34 CEST] <grosso> no frame! [16:48:34 CEST] <grosso> non-existing PPS 0 referenced [17:06:39 CEST] <pi-> Blacker47: sorry about that, I don't know why my MacBook is connecting and dying multiple times while I'm sleeping. [18:06:50 CEST] <hiihiii> hi [18:07:10 CEST] <hiihiii> can someone shed some light on the -frame_drop_threshold option [18:07:12 CEST] <hiihiii> ? [18:08:45 CEST] <hiihiii> what's written in the documentation is vague for me [18:08:47 CEST] <hiihiii> "which specifies how much behind video frames can be before they are dropped. In frame rate units, so 1.0 is one frame. The default is -1.1." [18:09:39 CEST] <furq> hiihiii: i'm guessing that's for use with -vsync [18:10:24 CEST] <hiihiii> yes [18:10:55 CEST] <hiihiii> that was my initial thought. it's written after vsync's documentation [18:11:21 CEST] <hiihiii> what I'm doing right now is using ffmpeg to capture my screen [18:11:52 CEST] <hiihiii> -vsync 2 gives me good results but in VFR [18:12:41 CEST] <hiihiii> with -vsync 1 my recordings seem like they are in 30fps rather than the 60fps I told ffmpeg to capture [18:13:38 CEST] <BtbN> How are you capturing the screen? [18:14:22 CEST] <hiihiii> ffmpeg -loglevel quiet -hwaccel dxva2 -threads 1 -f gdigrab -rtbufsize 512M -framerate 60 -offset_x 187 -offset_y 92 -video_size 630x464 -draw_mouse 0 -show_region 0 -i desktop -pix_fmt yuv420p -c:v libx264 -preset ultrafast -tune zerolatency -crf 21 -an -r 60 -vsync 1 "source_vsync1_fdt120.mp4" [18:15:37 CEST] <hiihiii> this step (capturing) is for preparation for another round of encoding using two inputs [18:16:15 CEST] <hiihiii> one inputs is in VFR. the second one I'm trying to get now has to be CFR [18:16:34 CEST] <hiihiii> otherwise I'll run into syncing issues [18:17:06 CEST] <hiihiii> right now I don't have a problem [18:17:32 CEST] <hiihiii> I just want to capture the best possible way I can [18:18:27 CEST] <hiihiii> maybe I'll increase the size of -rtbufsize and lower the -crf and see where that takes me [18:19:05 CEST] <BtbN> maybe it just can't keep up with 60 fps [18:19:28 CEST] <hiihiii> obviously yeah [18:19:31 CEST] <furq> gdigrab is slow [18:19:47 CEST] <hiihiii> -f dshow [18:19:48 CEST] <furq> idk if that's the problem but it's generally better to use a proper dshow capture device [18:20:58 CEST] <hiihiii> I was gonna try that too but really wanted to know if -frame_drop_threshold would be beneficial [18:38:53 CEST] <hiihiii> -f gdigrab -rtbufsize 2048M -framerate 60 -offset_x 187 -offset_y 92 -video_size 630x464 -draw_mouse 0 -show_region 0 -i desktop -pix_fmt yuv420p [18:39:15 CEST] <hiihiii> the same command with dshow [18:39:18 CEST] <hiihiii> -f dshow -rtbufsize 2048M -framerate 60 -pixel_format yuv420p -i "video=screen-capture-recorder" -vf "crop=630:464:187:92" [18:40:16 CEST] <hiihiii> :( dshow performed badly. I think since this command needs to corp its input [18:49:41 CEST] <kepstin> you should consider using OBS for screen capture on windows, it has a higher performance builtin capture method. [18:53:31 CEST] <BtbN> ffmpeg could use a desktop duplication capture source [18:53:33 CEST] <BtbN> but it's a mess [18:56:09 CEST] <BtbN> like, it doesn't just give you frames. It gives you dirty rects and move regions. You then have to contstruct the actual image from that [19:10:11 CEST] <hiihiii> sounds like an overkill [19:10:31 CEST] <hiihiii> shoot link [20:11:43 CEST] <dreamon_> hello. want to deinterlace a video without losing quality. how can I do? [20:13:45 CEST] <dreamon_> ffmpeg -i input.mp4 -deinterlace out.mp4 but it loosing much quality [20:17:59 CEST] <pzich> try adjusting the CRF: https://trac.ffmpeg.org/wiki/Encode/H.264 [20:18:11 CEST] <pzich> -crf 0 is lossless, but will result in a massive file [20:20:24 CEST] <dreamon_> pzich, Unrecognized option 'crf'. maybe Im using a old ffmpeg version? [20:21:38 CEST] <dreamon_> ffmpeg version N-83775-gdbc932e [20:25:06 CEST] <dreamon_> fflogger, https://pastebin.ubuntu.com/p/WTtKmr4z7r/ [20:25:59 CEST] <durandal_1707> do not use -deinterlace [20:26:10 CEST] <pzich> that says your build is from 2016 :o you should probably update [20:26:45 CEST] <dreamon_> durandal_1707, but I want to deinterlace its a old interlaced video.. [20:27:31 CEST] <dreamon_> pzich, where do I found a newer version for 18.04 Ubuntu.. [20:27:33 CEST] <kepstin> deinterlacing is a tricky problem, you'll want to try specific deinterlacing filters to find something that works well for your content. [20:28:10 CEST] <dreamon_> kepstin, I used -deinterlace and it look good but quality was poor [20:29:21 CEST] <kepstin> that could be either because the -deinterlace option picked a bad deinterlacer, or encoding quality issues. But yeah, get a newer ffmpeg first. [21:05:29 CEST] <Adcock> VP9 VS H264 bitrate comparsion. [21:06:44 CEST] <Adcock> H264 bitrate 1424K [21:07:21 CEST] <Adcock> What bitrate should I use for vp9 to get similar quality? [21:16:01 CEST] <Hello71> tias [21:20:22 CEST] <Adcock> Hello71: Me? [21:20:30 CEST] <Hello71> yes [21:20:51 CEST] <Adcock> Explain please. [21:21:51 CEST] <Adcock> What about size? [21:25:58 CEST] <Hello71> try it and see [21:26:16 CEST] <Adcock> I did. [21:26:49 CEST] <Adcock> I just can't find the right options. [21:27:12 CEST] <Adcock> I need some general information if you have time. [21:27:16 CEST] <Adcock> :) [21:27:49 CEST] <Adcock> Are vp9 videos of the same quality smaller in size than vp9? [21:28:10 CEST] <Adcock> I know ffmpeg devs aren't responsible for it. [21:28:19 CEST] <Adcock> But whom to ask? [21:28:55 CEST] <Adcock> Are vp9 videos of the same quality smaller in size than H264? [21:29:58 CEST] <JEEB> it's not as simple as that [21:30:17 CEST] <JEEB> like, VP9 as a format may be better on the paper [21:30:31 CEST] <JEEB> but when you're testing youj have encoder A and encoder B [21:31:10 CEST] <JEEB> if you are interested in testing video encoders I can link you some general old articles [21:31:29 CEST] <Adcock> Please :) [21:32:49 CEST] <JEEB> https://web.archive.org/web/20140822041755/http://x264dev.multimedia.cx/arc… [21:33:44 CEST] <JEEB> possibly useful write-up as well https://web.archive.org/web/20140427064753/http://x264dev.multimedia.cx:80/… [21:40:42 CEST] <JEEB> Adcock: anyways generally speaking when I test things I attempt to max out parameters (things get slow, which is generally my use case), and then encode with the slower thing with a quantizer level that does still have some issues visible [21:40:52 CEST] <JEEB> then I go to the faster one, and match size :P [21:41:11 CEST] <JEEB> (and of course you have to match all the little details like GOP length etc) [21:42:30 CEST] <Adcock> What is Keyframe interval? [21:42:38 CEST] <Adcock> IS it fps? [21:42:48 CEST] <JEEB> no [21:43:08 CEST] <JEEB> also known as GOP length, which is the interval between two Random Access Points [21:43:23 CEST] <JEEB> aka where the decoding can be started without being afraid that you'd have some references before it [21:43:53 CEST] <JEEB> usually even if you have a "keyframe" (one that can be decoded by itself), you might still have leftover references [21:44:04 CEST] <JEEB> so when you get to the following frame, it might not be decode'able [21:44:33 CEST] <JEEB> a Random Access Point is defined so that if you start decoding there, you can (in presentation order) show all following frames after that [21:46:09 CEST] <Adcock> What is PSNR? [21:47:06 CEST] <JEEB> wikipedia will probably tell you that it's a signal thing that lets you know how much the signal has been kept the same [21:47:14 CEST] <JEEB> (it also in video *loves* blurring) [21:47:31 CEST] <Adcock> :D [21:47:48 CEST] <Adcock> That's a common problem while encoding. [21:48:00 CEST] <JEEB> yes, many encoders actually are optimized for PSNR [21:48:00 CEST] <Adcock> At least Ihave experienced it. [21:48:08 CEST] <JEEB> which is pretty bad for human eyes :P [21:48:27 CEST] <JEEB> or well, I dunno. If you don't know the original maybe it's not that bad [21:48:39 CEST] <JEEB> x264 for example attempts to create something that tries to look like the detail [21:48:45 CEST] <JEEB> which is worse for PSNR [21:48:51 CEST] <JEEB> but tends to look better for humans [21:51:46 CEST] <kupi> hi [21:51:56 CEST] <kupi> is there any way to loselessly compress videos? [21:52:00 CEST] <JEEB> yes [21:52:05 CEST] <Adcock> if you don't mind may I ask how powerful computer do you use? [21:52:07 CEST] <JEEB> but if your input is not lossless [21:52:20 CEST] <JEEB> then the compressed result will probably be bigger than your source :P [21:52:38 CEST] <Hello71> hm... what about mjpeg? [21:52:39 CEST] <Adcock> o_o [21:53:01 CEST] <JEEB> Hello71: I'm not sure JPEG does lossless? [21:53:07 CEST] <Hello71> that's my point [21:53:21 CEST] <Hello71> mjpeg is a very inefficient codec [21:53:24 CEST] <JEEB> Adcock: nothing special - I've had this 4790K for quite a while [21:53:51 CEST] <JEEB> Hello71: if we go by something like prores that's lossy and like MJPEG, that generally tends to be smaller than lossless things [21:54:11 CEST] <JEEB> so I'd expect MJPEG still be smaller than comparable lossless [21:54:20 CEST] <Adcock> I asked because you said speed is slow. [21:54:21 CEST] <Adcock> For me it is super slow. [21:54:21 CEST] <Hello71> huh. [21:54:47 CEST] <JEEB> Adcock: well my test cases are "max out the encoders, match certain parameters so it's fair, let them run" [21:54:53 CEST] <Hello71> Adcock: video encoding is slow [21:54:55 CEST] <JEEB> and that's why I match against the slowest encoder [21:55:01 CEST] <JEEB> so that I don't have to re-encode :P [21:55:35 CEST] <Adcock> :) [22:05:59 CEST] <kupi> Adcock: 7440HQ [22:06:59 CEST] <Adcock> ? [22:07:11 CEST] <Adcock> oH [22:07:11 CEST] <Adcock> :) [22:10:34 CEST] <kupi> JEEB: how can I tell if a video can be compressed lossless? [22:10:51 CEST] <JEEB> all video can be compressed with lossless compression (in theory) [22:11:06 CEST] <JEEB> unless you have some very specific definition of lossless compression in mind :P [22:11:16 CEST] <JEEB> (such as re-compression without full re-encoding) [22:11:58 CEST] <kupi> my definition is decreasing file size without sacrificing quality :D [22:12:09 CEST] <Adcock> :D [22:12:15 CEST] <Adcock> Me too. [22:12:36 CEST] <Hello71> impossible [22:12:37 CEST] <Hello71> next question [22:12:48 CEST] <Adcock> Why? [22:13:14 CEST] <Adcock> Okay. No. [22:13:17 CEST] <Adcock> Skip. [22:13:37 CEST] <JEEB> in theory if your video was H.264 and it was CAVLC you could redo that with CABAC (which compresses better) [22:13:41 CEST] <JEEB> but guess if there are tools for that [22:15:21 CEST] <kupi> the video is WMV3 [22:15:38 CEST] <kupi> and I believe there are more efficient formats such as h265 [22:19:53 CEST] <JEEB> then no, there is no magical *lossless* pathway anywhere [22:22:02 CEST] <kupi> JEEB: what about AVC? [23:17:03 CEST] <^Neo> hello friends, I'm curious if anyone has any experience driving FFmpeg with pipes with python? [23:44:36 CEST] <victorqueiroz> Interesting, now on decoding I'm getting: pps_id 3199971767 out of range [23:51:15 CEST] <Zexaron> Hello [23:51:54 CEST] <Zexaron> I'm trying to compare ffprobe output from different formats/codecs, but I'm not sure if it really outputs from start to finish in order show_packets [23:51:58 CEST] <Zexaron> what does POS mean? [23:52:09 CEST] <Zexaron> position in filesize bytes ? [23:52:35 CEST] <Zexaron> because it's so different it's not really comparable from packet ID to packet ID [23:52:52 CEST] <Zexaron> 1 vs 1, 2 vs 2 [23:53:21 CEST] <ChocolateArmpits> Zexaron, maybe the packets are listed in the decoding order? [23:53:37 CEST] <ChocolateArmpits> there's also show_frames [23:53:56 CEST] <kepstin> Zexaron: not sure where you're getting 'POS' from, but pkt_pos is position of the packet within the file in bytes, yeah. [23:54:45 CEST] <kepstin> (the -show_frames output is what i'm looking at) [23:55:24 CEST] <kepstin> looks like the 'pos' value in -show_packets matches the 'pkt_pos' value in -show_frames, which makes sense :) [23:58:35 CEST] <Zexaron> both AVI/MPEG4 and MKV/H264 have this from the frame dumped videos produced by this https://github.com/dolphin-emu/dolphin/blob/944b5fade625823814c04b4acbf835c… [23:58:51 CEST] <Zexaron> oh okay [23:59:12 CEST] <Zexaron> trying to understand it and how to improve it, apparently it uses some kind of emulated frame wall time to compensate when the PC isn't fast enough to keep stable FPS the game is designed to run at, tese games have gamespeed bound to FPS also, I was thinking if it was possible to try other methods, like just trying to make a CRF slideshow with fixed framerate, make FFmpeg simply wait as frames get delivered pack them in fixed 60 or 30 [23:59:12 CEST] <Zexaron> or whatever FPS [23:59:44 CEST] <kepstin> i hope the name of that function is wrong, and you're not actually using AVI to store h264 video :) [00:00:00 CEST] --- Wed Oct 17 2018

1 0