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

[burek]

[00:57:14 CEST] <KombuchaKip> Hey everyone. The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE
[01:36:55 CEST] <SilenceDogood> Hey guys. When I captured some gameplay footage with an external capture card on my PC yesterday, Windows sent it sideways for some reason
[01:37:13 CEST] <SilenceDogood> So I want to make an ffmpeg script to rotate it back to being normal
[01:37:38 CEST] <SilenceDogood> Currently my script says: ffmpeg -f concat -i files.txt -c:v libx264 -preset slow -crf 18 -c:a aac -b:a 192k -pix_fmt yuv420p -vf "transpose=2" out.mp4
[01:37:57 CEST] <furq> if you're going to mp4 you might as well just set the rotate metadata and save yourself reencoding
[01:38:07 CEST] <SilenceDogood> what
[01:38:12 CEST] <SilenceDogood> is that a thing?
[01:38:14 CEST] <furq> it is in mp4
[01:38:20 CEST] <furq> -c copy -metadata:s:v:0 rotate=90
[01:38:29 CEST] <SilenceDogood> ooh neat. I will try that
[01:38:34 CEST] <furq> ymmv as to whether players support it
[01:38:37 CEST] <furq> anything good ought to
[01:39:26 CEST] <furq> if you actually want to reencode then transpose should be fine
[01:40:56 CEST] <SilenceDogood> furq transpose is changing the resolution
[01:41:14 CEST] <SilenceDogood> that's what I came on here to ask about
[01:41:33 CEST] <SilenceDogood> It's rotating it while keeping the resolution the same, which creates enormous black bars on what is actually still a vertical video
[01:42:12 CEST] <SilenceDogood> what does the -c copy do?
[01:42:20 CEST] <furq> remuxes instead of reencoding
[01:42:53 CEST] <furq> transpose=2 by itself works fine here
[01:43:11 CEST] <furq> you might want to check your source files don't have rotate metadata set
[01:43:43 CEST] <SilenceDogood> They are TS files created by the Avermedia Live Gamer Portable capture device
[01:43:52 CEST] <furq> nvm then
[01:44:25 CEST] <SilenceDogood> furq transpose=2 by itself doesn't work fine here for the reason I stated about the black bars
[01:44:41 CEST] <furq> yeah i just tried that here and it changes the resolution as you'd expect
[01:45:03 CEST] <SilenceDogood> what was your command ?
[01:45:16 CEST] <furq> ffmpeg -f lavfi -i testsrc=s=720x1280:d=1 -vf transpose=2 -f null -
[01:45:43 CEST] <furq> that gives 1280x720 output
[01:46:42 CEST] <SilenceDogood> OK ... I guess I'll try again and see what happens with that
[01:48:07 CEST] <furq> maybe try -vf transpose=2:passthrough=none
[01:48:10 CEST] <furq> that should be the default though
[01:49:21 CEST] <SilenceDogood> No. Width and height are still crossed
[01:49:27 CEST] <SilenceDogood> my current command is: -vf transpose=2:passthrough=none
[01:49:28 CEST] <SilenceDogood> oops
[01:49:30 CEST] <furq> weird
[01:49:44 CEST] <SilenceDogood> ffmpeg -f concat -i files.txt -c:v libx264 -preset slow -crf 18 -c:a aac -b:a 192k -pix_fmt yuv420p -vf transpose=2:passthrough=none -t 5 out.mp4
[01:49:48 CEST] <SilenceDogood> That's my current command
[01:49:52 CEST] <SilenceDogood> I'm trying to make a YouTube-ready file
[01:49:59 CEST] <Hello71> doesn't youtube have an editor
[01:50:08 CEST] <SilenceDogood> it sucks
[01:50:08 CEST] <furq> i'm pretty sure youtube respects rotate metadata
[01:50:17 CEST] <Hello71> like, they killed the annotation editor claiming that the youtube editor does everything
[01:50:23 CEST] <SilenceDogood> OK I'll just try adding the metadata
[01:50:25 CEST] <furq> and it'll definitely take whatever your capture card produces
[01:50:28 CEST] <furq> so that's probably going to be easier
[01:50:40 CEST] <Hello71> have you considered just capturing with ffmpeg
[01:50:44 CEST] <SilenceDogood> Yeah. This isn't actually the capture card's fault. This is windows fault
[01:51:13 CEST] <Hello71> if you capture to mkv you can play the file while recording to check that it's working
[01:51:38 CEST] <SilenceDogood> I rotated the screen briefly before I started playing to hit an "OK" button that was a little too far off screen, and for some reason, when I rotated back Windows didn't change it for the capture card
[01:51:58 CEST] <furq> oh i was assuming you were playing some vertical layout arcade game
[01:52:04 CEST] <furq> i was hoping it'd be something good
[01:52:24 CEST] <SilenceDogood> Hello71, If I was going to use my computer's resources to capture then I wouldn't have spent money on an external capture card, now would I.
[01:52:37 CEST] <furq> ffmpeg can work with some capture cards
[01:52:39 CEST] <furq> i doubt it works with this one though
[01:52:50 CEST] <Hello71> oh, you said the model
[01:53:20 CEST] <furq> i guess it'd probably work with vfwcap actually
[01:53:21 CEST] <SilenceDogood> I'll see if adding metadata does the trick
[01:53:23 CEST] <Hello71> afaik it's usually cheaper to buy a better cpu and then just run x264 ultrafast lossless in the background
[01:53:34 CEST] <Hello71> not even considering that you can use the cpu for other stuff
[01:53:36 CEST] <furq> or nvenc
[01:53:52 CEST] <SilenceDogood> This is a laptop
[01:54:03 CEST] <furq> if it's a recent laptop it'll probably have quicksync
[01:54:15 CEST] <furq> or nvenc if it has a mobile nvidia gtx
[01:54:41 CEST] <SilenceDogood> Laptop model: ASUS Q551LN-BBI706
[01:54:41 CEST] <SilenceDogood>  http://www.asus.com/supportonly/Q551LN/HelpDesk_Manual/
[01:55:25 CEST] <SilenceDogood> At the time I bought it, this model was the most powerful convertible laptop (turns into a tablet) for gaming that was available.
[01:55:36 CEST] <furq> no nvenc but it has quicksync
[01:55:43 CEST] <SilenceDogood> To get more power, I'd have to give up the convertible feature and I don't wanna
[01:55:46 CEST] <furq> i forget if qsv has a lossless mode though
[01:55:56 CEST] <furq> but if it's going to youtube anyway then it doesn't matter too much
[01:56:34 CEST] <SilenceDogood> I like how with a capture card, I can guarantee that absolutely zero percent of my CPU is being used for capturing
[01:56:51 CEST] <SilenceDogood> This thing plugs into a USB port only for power
[01:57:18 CEST] <SilenceDogood> Can't blame anything in game performance on the capturing
[01:58:40 CEST] <SilenceDogood> furq that metadata thing you said must be wrong
[01:58:44 CEST] <SilenceDogood> VLC doesn't recognize it
[01:59:18 CEST] <furq> what version
[01:59:35 CEST] <SilenceDogood> of VLC?
[01:59:37 CEST] <furq> yeah
[01:59:37 CEST] <furq> 2.1 and earlier don't support rotate metadata iirc
[02:00:17 CEST] <SilenceDogood> i am grabbing latest right now to be sure
[02:00:37 CEST] <furq> i mean if you're going to upgrade then upgrade to mpv
[02:01:33 CEST] <SilenceDogood> Latest doesn't recognize it either.
[02:01:49 CEST] <SilenceDogood> If I were a betting man, I'd say mpv doesn't either.
[02:07:19 CEST] <SilenceDogood> Yeah this right here totally creates black bars ffmpeg -i 201810201906180.ts -vf transpose=2 -t 5 out.mp4
[02:07:48 CEST] <Hello71> I am a betting man, I bet you're doing it wrong
[02:10:09 CEST] <SilenceDogood> Hello71 I just pasted the exact command
[02:10:26 CEST] <Hello71> what version of ffmpeg are you using
[02:10:31 CEST] <SilenceDogood> also, the command furq mentioned earlier does nothing. ffmpeg -f lavfi -i testsrc=s=720x1280:d=1 -vf transpose=2 -f null -
[02:10:54 CEST] <Hello71> given that I think vlc 2.1 is also ancient
[02:11:18 CEST] <SilenceDogood> ffmpeg version N-92202-gf72b9904fe
[02:12:27 CEST] <SilenceDogood> What is so hard about making a windows installer for the developers of mpv
[02:12:42 CEST] <furq> https://mpv.srsfckn.biz/
[02:14:46 CEST] <SilenceDogood> Apparently, there is no such thing as players that support this mp4 rotation metadata. VLC doesn't. MPV doesn't. Windows Media Player doesn't. Either the command you suggested is wrong or the feature does not exist.
[02:19:32 CEST] <SilenceDogood> No offense meant furq but it seems like everything you say is wrong. You haven't said one correct thing so far as far as I can tell.
[02:20:50 CEST] <SilenceDogood> If a video format documents a feature which exactly zero players support then the feature doesn't exist.
[02:21:40 CEST] <SilenceDogood> https://mpv.srsfckn.biz/ does not have installers. It has builds but not installers.
[02:22:03 CEST] <SilenceDogood> Which means I can use mpv but I can't recommend it to tech illiterate people
[02:27:11 CEST] <Hello71> command works fine for everybody else
[02:27:14 CEST] <Hello71> seems just not working for you
[02:28:25 CEST] <SilenceDogood> Whatever you think the command is doing for you, it isn't.
[02:28:46 CEST] <SilenceDogood> If I use -s 1280x720 then I get a result that is letterboxed on all four sides
[02:32:14 CEST] <SilenceDogood> I think I know what the problem is
[02:32:18 CEST] <SilenceDogood> My original video is letterboxed
[02:32:18 CEST] <Hello71> you used -s?
[02:32:39 CEST] <SilenceDogood> The capture card must be designed to only work in portrait mode
[02:33:10 CEST] <SilenceDogood> so getting a sideways video caused it to record in portrait mode and letterbox
[02:33:23 CEST] <SilenceDogood> I mean in landscape mode. gaaah
[02:33:47 CEST] <SilenceDogood> The capture card must be designed to only work in landscape mode so when it gets a portrait video, it letterboxes it into a landscape recording
[02:33:58 CEST] <SilenceDogood> This means I have to crop
[02:34:08 CEST] <SilenceDogood> and will take a severe quality hit
[02:47:30 CEST] <SilenceDogood> oh well, at least I solved the mystery. thanks for trying you guys
[03:17:00 CEST] <CrystalMath> hi, is there any way to treat a local file as a stream?
[03:17:08 CEST] <CrystalMath> as in, treat it as a file that is constantly growing in size
[03:17:13 CEST] <CrystalMath> because it is such a file
[03:35:04 CEST] <Hello71> tail -f
[03:35:08 CEST] <Hello71> there's probably a better way
[03:41:14 CEST] <CrystalMath> any way for tail -f to start from the beginning?
[04:21:28 CEST] <Hello71> -c +0
[04:34:47 CEST] <JC_Yang> what is
[04:45:37 CEST] <leif> Is there any reason avformat_open_input would return NULL for the AVFormatContext argument, but there was no error?
[04:45:45 CEST] <leif> (or at least the function's return value was 0)
[05:08:46 CEST] <CrystalMath> Hello71: thank you :) sorry for not responding, i found the answer in the manual and stopped checking IRC
[05:08:53 CEST] <CrystalMath> i used -n +0
[05:09:22 CEST] <Hello71> if performance doesn't really matter that's probably good enough
[05:10:00 CEST] <Hello71> also that will probably add a good deal of latency
[05:10:38 CEST] <CrystalMath> hmm..... yeah i didn't think much
[05:10:42 CEST] <CrystalMath> i need a command fast
[05:10:49 CEST] <CrystalMath> *needED
[05:11:04 CEST] <CrystalMath> it was a live stream
[06:00:13 CEST] <JC_Yang> I'm investigating a bug found in my app using ffmpeg 4.0.2. In matroskaenc.c, line 2352, why the ts_offset of track need to be added again to formed the cluster time? ts has added the ts_offset already in line 2349. I'm not familiar to mkv, these codes seems weird to me, so I'm questioning here
[06:19:23 CEST] <th3_v0ice> Where can I find the information about the number of references for a given AVPacket?
[08:57:20 CEST] <bmu> Hi guys! Is this channel alive so I can ask a question?
[08:59:41 CEST] <Zexaron> just ask, somtimes you have to wait
[09:11:13 CEST] <bmu> Thanks. I'm using libav and trying to make a sort of a video player. What I'm doing is "call [avcodec_receive_frame], queuing frames, and consuming each frame in another thread (like in ffplay.c manner). What I'm worried about is, as long as I know, even though `av_frame_alloc` is called only once(at initialization stage), since frame->data is not actually allocated yet and
[09:11:27 CEST] <bmu> it will be allocated and freed everytime when `avcodec_receive_frame` is called, so I think there's a performance issue. So here's what I want to know is, (1) Is that right frame data is allocated and freed everytime when `avcodec_receive_frame` is called as I mentioned? (2) If then, is there any solution to prevent everytime-allocation like using MemoryPool?
[14:13:21 CEST] <th3_v0ice> Is there any particular reason why would I see 150MB memory rise when I open the output file via API?
[14:13:54 CEST] <JEEB> depends on the format etc. also if you're doing probing or not
[14:23:49 CEST] <th3_v0ice> Format is FLV, how can I check if the probing is on?
[14:24:07 CEST] <JEEB> you would call the function yourself
[14:24:18 CEST] <JEEB> avformat_find_stream_info
[14:24:20 CEST] <JEEB> specifically
[14:24:26 CEST] <JEEB> without that IIRC it doesn't do probing
[14:24:42 CEST] <JEEB> oh, output file?
[14:24:48 CEST] <th3_v0ice> Yes
[14:25:07 CEST] <JEEB> dunno then, that sounds like an awful amount of overhead. are you sure it's from that specifically?
[14:25:14 CEST] <JEEB> of course after you feed a muxer stuff
[14:25:21 CEST] <JEEB> it might buffer that depending on the container
[14:25:25 CEST] <BtbN> Also, are you sure you aren't just looking at virtual memory?
[14:25:29 CEST] <JEEB> and then there's the IO buffering possibly
[14:25:36 CEST] <th3_v0ice> Nothing else is allocated at that particular moment in time.
[14:25:37 CEST] <JEEB> and yes, virtual memory
[14:26:04 CEST] <th3_v0ice> Its also just opening, not feeding anything to the muxer.
[14:28:42 CEST] <Woodpecker> I have integrated ffmpeg into my Qt (c++) program via the command line options (QProcess). Is it possible or recommended that I use libraries instead? My purposes are fairly rudamentary:
[14:30:56 CEST] <Woodpecker> concatenate forground audio track. concatenate background audiotrack. Overlay both audiotracks. Overlay a video undo said track.
[14:31:11 CEST] <Woodpecker> unto*
[14:33:08 CEST] <JEEB> using the API would let you do a lot of decisions before you run stuff, like indexing the input audio tracks to know if you have to do anything special for them
[14:33:34 CEST] <JEEB> also ffms2 might provide you a simplified API around indexing and loading video or audio frame-exactly
[14:33:41 CEST] <JEEB> that uses the FFmpeg APIs in the background
[14:35:17 CEST] <durandal_1707> i doubt that is needed
[14:35:53 CEST] <JEEB> it really depends
[14:36:30 CEST] <JEEB> also in general the API usage will let you do various stuff without first calling ffprobe on all of your inputs etc
[14:36:40 CEST] <JEEB> be it ffms2 or standard FFmpeg APIs
[14:44:35 CEST] <Woodpecker> JEEB: A simplified API does seem ideal. It does need to have MP3 support, which is probably troublesome given that it only was recently made open source.
[14:44:54 CEST] <JEEB> uhh, what
[14:45:13 CEST] <JEEB> mp3 aka mpeg-1 layer 3 has been a standard for quite a while
[14:45:25 CEST] <BtbN> like, a 20+ years while
[14:45:26 CEST] <JEEB> heck even the patents have expired for it by now :P
[14:45:46 CEST] <Woodpecker> okay okay ;)
[14:45:47 CEST] <JEEB> also the patents etc never stopped people from implementing it
[14:46:04 CEST] <Woodpecker> I thought there was licensing issues around it, anyway
[14:46:47 CEST] <JEEB> yes, if you are planning on distributing commercial software you generally want to check up on what licensing you'd have to pay for when distributing binaries
[14:46:51 CEST] <JEEB> that's 100% separate to FFmpeg etc
[14:46:52 CEST] <JEEB> though
[14:46:57 CEST] <JEEB> patent licensing and such
[14:47:28 CEST] <JEEB> FFmpeg generally doesn't really give a darn, and implements standards as they come and needs come for them to be implemented
[14:47:35 CEST] <BtbN> mp3 is pretty much free to use by now though
[14:47:36 CEST] <JEEB> we don't distribute official binaries
[14:47:48 CEST] <JEEB> yes, mp3 specifically was even OK'd by red hat by now
[14:47:54 CEST] <JEEB> not that this is legal advice in any sense
[14:47:57 CEST] <BtbN> But I'd still rather just use opus. Better in almost every aspect, with compatiblity being the only weak point
[14:48:40 CEST] <Woodpecker> interesting to say the least. Id like to use opus, but I had serious issues when I placed it into an mp4 container and uploaded it to youtube.
[14:48:55 CEST] <JEEB> if you upload to youtube you don't really care
[14:49:13 CEST] <JEEB> just push something lossless up and be done with it, more or less
[14:49:20 CEST] <BtbN> I don't think mp4 supports opus?
[14:49:34 CEST] <JEEB> there's a draft that both google and mozilla want to finish
[14:49:55 CEST] <JEEB> pretty sure FFmpeg can mux that already
[14:50:06 CEST] <BtbN> https://www.chromestatus.com/feature/5100845653819392 yeah, looks like it's a thing already in a half-official state
[14:50:15 CEST] <BtbN> still, just don't use mp4
[14:50:50 CEST] <JEEB> seems like they didn't copy over the latest additions to opus's site https://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html
[14:51:45 CEST] <JEEB> but yes, opus in mp4 is not considered final yet even though various tools can create it already
[14:51:59 CEST] <Woodpecker> BtbN: My reasons for using MP4 was that it was a container that I could create a slideshow in using ffmpeg, that would have virtually no rendering time. I am definitely open to any container that achieves this.
[14:52:26 CEST] <BtbN> Why does the container matter for that?
[14:54:32 CEST] <Woodpecker> BtbN: I dont know. All I know is that I played around with a bunch of containers on ffmpeg, using the slideshow feature, and MP4 was the only one I could find that would create an hour long video with about 80 slides, in about 4 seconds.
[14:55:01 CEST] <Woodpecker> Matroska took something like 3 hours.
[14:55:13 CEST] <BtbN> I don't see how the container is related to that at all. Do you mean you are making a video with ultra low fps?
[14:55:55 CEST] <Woodpecker> BtbN: Yeah. Its a slideshow with no transitions at this point.
[14:56:11 CEST] <Woodpecker> here its better to give an example, one sec,
[14:56:17 CEST] <BtbN> That might be a problem with certain containers when your fps gets lower than their timebase
[14:58:06 CEST] <Woodpecker> BtbN: https://www.youtube.com/watch?v=UZFpsanl5WY << This is a video I made with FFMPEG on the commandline. It probably took something like 30 seconds of render time on all the steps combined.
[14:59:26 CEST] <BtbN> You can always just use two fps filters in a row, one that converts to your 1/60 or whatever frames a second, and one that goes back to 60. Then use libx264 with super long gops, and you will still ger a very small video
[14:59:39 CEST] <BtbN> As most frames are identical
[15:02:23 CEST] <Woodpecker> BtbN: Interesting. Now it is just a matter of what library to import into my qt program, and to learn the API.
[15:02:52 CEST] <BtbN> YouTube will do that anyway I guess
[15:03:09 CEST] <JEEB> yes, youtube will convert your VFR to CFR
[15:03:19 CEST] <JEEB> just to normalize all of its input
[15:03:29 CEST] <BtbN> That Youtube link therte is 720p6
[15:03:34 CEST] <BtbN> 6, not 60
[15:03:41 CEST] <JEEB> oh, fun
[15:03:46 CEST] <JEEB> I guess if it's CFR
[15:56:57 CEST] <kuznetsss> Hello, I am writing C++ application to convert images into H264 video. My application works fine but it doesn't include part of the input images to the end of the output video.
[15:57:16 CEST] <kuznetsss> I have found same problem on Stack Overflow: https://stackoverflow.com/questions/17811987/encoded-images-into-h264-video-are-skipped-and-or-missing
[15:58:18 CEST] <kuznetsss> Is such solution right or it is just hack?
[15:58:56 CEST] <BtbN> That solution from the answer is pretty much nonsense. Encoders don't skip images
[15:59:52 CEST] <BtbN> Missing images at the end usually mean that you are not properly flushing the encoder
[16:01:52 CEST] <JEEB> with ffmpeg.c you have the funky "vsync" logic but with API usage you skip that
[16:02:05 CEST] <JEEB> so everything you pass through should end up in output, as long as you flush the encoder :)
[16:02:53 CEST] <kuznetsss> To flush the encoder I should use NULL instead of the packet in av_interleaved_write_frame()?
[16:03:53 CEST] <JEEB> I think that's muxing
[16:04:03 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[16:04:05 CEST] <JEEB> this is encoding
[16:04:45 CEST] <JEEB> but yes, you should also check if there's similar for muxing, which there might be due to some buffering on that side depending on the exact muxer
[16:06:17 CEST] <kuznetsss> OK, thanks, I will try to flush buffers
[16:55:03 CEST] <King_DuckZ> hi, I've been trying to pin down a bug in my code and I just realised it comes from this: avcodec_find_encoder_by_name("prores_ks")->name == "prores_ks"  <- ok
[16:55:43 CEST] <King_DuckZ> avcodec_find_encoder( avcodec_find_encoder_by_name("prores_ks")->id )->name == "prores" <- wtf?
[17:13:01 CEST] <kuznetsss> JEEB, BtbN flushing buffers doesn't help
[17:15:21 CEST] <kuznetsss> Encoder prints warning when flush occurs: [libx264 @ 0x5561ba24b780] non-strictly-monotonic PTS
[17:17:20 CEST] <Zexaron> Hello
[17:17:34 CEST] <Zexaron> any ideas what this Delayed Frames are? https://github.com/dolphin-emu/dolphin/commit/8fb2eb889d576fb3b298e68f07f7d6094e3372cf#diff-6a6d4269338abd71eaff037290b6f3d5
[17:17:47 CEST] <Zexaron> something to do with the ffmpeg internal buffer?
[17:18:25 CEST] <King_DuckZ> kuznetsss: I had that problem already, you need to set your pts right when you encode
[17:18:37 CEST] <Zexaron> that should just gracefully encode when render stops, no need to cut it short or anything
[17:20:30 CEST] <kuznetsss> King_DuckZ: I use av_packet_rescale_ts() to set pts inside packet
[17:21:52 CEST] <King_DuckZ> kuznetsss: ok, double check that you are increasing the video frame pts too
[17:24:17 CEST] <King_DuckZ> kuznetsss: my problems were I forgot to do ++frame->pts and I wasn't using av_packet_rescale_ts() iirc, I'm checking my code now but that's all I remember
[17:24:46 CEST] <King_DuckZ> it's been months since I dealt with that... but I remember it was horrible
[17:27:00 CEST] <kuznetsss> King_DuckZ: Thanks, the pts of my frames is ok. There is no frame when I do the encoder flushing.
[17:49:29 CEST] <King_DuckZ> ok I fixed my code by getting rid of the id and carrying around the codec string name instead, but imho it's a bit dodgy the result of the statement I typed
[17:50:24 CEST] <JEEB> yea, you are bound to get whatever gets picked first for a specific codec id
[17:50:33 CEST] <JEEB> like for prores you have two separate encoders
[17:50:37 CEST] <JEEB> at the very least
[17:55:58 CEST] <King_DuckZ> imo, there should be a way to go in both directions reliably
[17:56:09 CEST] <King_DuckZ> like codec_id and sub_id or something
[17:57:48 CEST] <JEEB> but yea, you first grabbed prores_ks, then you grabbed the codec id (generic "prores" identifier), and then you asked for prores and the default is the one without suffix which equals the _aw one
[17:58:00 CEST] <JEEB> you can either keep the AVCodec struct around
[17:58:12 CEST] <JEEB> or use the name
[17:58:23 CEST] <JEEB> it's the same for other things which have multiple encoders for a single format
[18:15:42 CEST] <KombuchaKip> Hey everyone. The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE
[19:10:06 CEST] <gsuberland> I'm encoding an extremely large (250GB) UHD resolution 60fps raw AVI into x264 and am getting an unusual performance behaviour. The ffmpeg process appears to read a chunk of data from disk, then process it, then go back and read from disk again. Is this behaviour expected, rather than overlapped IO? (Windows, x64)
[19:10:50 CEST] <gsuberland> the CPU usage goes from ~5% for 2 seconds, back up to ~50% for a second or so, and repeats this pattern.
[19:11:22 CEST] <gsuberland> this is resulting in a speed of about 0.068x
[19:12:26 CEST] <Mavrik> Sounds about right yeah
[19:12:46 CEST] <Mavrik> IIRC the file sources read on demand directly without separate threads
[19:12:58 CEST] <gsuberland> so no overlapped IO?
[19:51:12 CEST] <brimestone> Hey guys. I'm hope to use libav on my Darwin project. Is this the channel to shoot these questions?
[19:51:41 CEST] <JEEB> for the libav* APIs, yes
[19:52:14 CEST] <brimestone> got it, 1st question. Where I can get the libav static libraries?
[19:52:30 CEST] <JEEB> there are no official binaries
[19:52:52 CEST] <JEEB> the FFmpeg site does link to some binaries, which were selected by someone editing the page
[19:53:16 CEST] <JEEB> those binaries generally tend to be all-inclusive, though
[19:53:23 CEST] <JEEB> so their license generally is GPLv3+
[19:53:35 CEST] <JEEB> rather than LGPLv2.1+ or GPLv2+
[19:53:55 CEST] <brimestone> I see. I can find my way around using C in Xcode Swift project, but I'm getting lost including stuff like avformat.h and the like
[19:54:55 CEST] <JEEB> which headers you need depends on which features you require. examples and the doxygen help with that
[19:55:07 CEST] <JEEB> generally what people do is they build FFmpeg and then set --prefix
[19:55:32 CEST] <JEEB> and when they build something against that FFmpeg, you use pkg-config (usually provided by pkgconf nowadays) to read the provided pc files
[19:55:43 CEST] <brimestone> Libav/avformats.h, avfilter.h
[19:55:46 CEST] <JEEB> which would then tell your linker etc where to look for those files
[23:00:21 CEST] <^Neo> hello friends, if I add avpacket side data, will I get it in the avframe corresponding to the packet?
[00:00:00 CEST] --- Tue Oct 23 2018