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

[burek]

[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/3a12c50dc1a5cef46d60e29eb7baf85795538167#diff-6a6d4269338abd71eaff037290b6f3d5
[00:07:02 CEST] <Zexaron> and more stuff like this https://github.com/dolphin-emu/dolphin/commit/3c65c5f2c53f3efedb3bd94cf1f55ff4f90309c9
[00:07:45 CEST] <Zexaron> didn't meant to specify specific line on first link, proper https://github.com/dolphin-emu/dolphin/commit/3a12c50dc1a5cef46d60e29eb7baf85795538167
[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_opencl.c;h=cd293c25223951245494ec505572bf8b032e2980;hb=HEAD#l493
[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/944b5fade625823814c04b4acbf835c89fbd191d/Source/Core/VideoCommon/AVIDump.cpp
[20:52:16 CEST] <Zexaron> https://github.com/dolphin-emu/dolphin/blob/944b5fade625823814c04b4acbf835c89fbd191d/Source/Core/VideoCommon/RenderBase.cpp
[20:53:09 CEST] <furq> https://github.com/dolphin-emu/dolphin/blob/944b5fade625823814c04b4acbf835c89fbd191d/Source/Core/VideoCommon/AVIDump.cpp#L330-L358
[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/3a12c50dc1a5cef46d60e29eb7baf85795538167#diff-6a6d4269338abd71eaff037290b6f3d5
[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/3a12c50dc1a5cef46d60e29eb7baf85795538167
[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