[01:09:39 CET] <Fiji> hi, i am trying to use CMAKE to build a project that uses ffmpeg libraries and i am getting an issue with trying to link libswscale and use the functions. my cmake file looks like this: https://hastebin.com/sogoneyige.bash , and i am getting errors like this when building: "undefined reference to `sws_getContext'" [01:12:07 CET] <oliv3> Fiji: obviously L22 seems wrong ? [01:12:25 CET] <Fiji> well ok [01:12:26 CET] <Fiji> shit lol [01:12:26 CET] <Fiji> sec [01:13:16 CET] <Fiji> even fixing that it's the same problem [01:13:57 CET] <oliv3> can't help more, i don't use cmake [01:14:06 CET] <Fiji> ok no worries, thank you for the help [08:33:21 CET] <memfrob> Hey hey hey! It's my friends! I like you guys. [08:33:30 CET] <memfrob> Matter of fact, I love you people! [08:33:47 CET] <memfrob> https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=5566 [08:35:49 CET] <memfrob> My exact line is this: ffmpeg.exe -i "gay_porn_x265.mkv" -preset veryslow -c:v h264_amf -c:a aac -ac 2 -b:a 320k "gay_porn_x264.mp4" [08:36:51 CET] <memfrob> If I use `-c:a copy` instead of `-c:a aac -ac 2 -b:a 320k` the message goes away, but when ffmpeg reaches the 10 second mark, the file size is just the same. [08:39:24 CET] <memfrob> -preset doesn't do anything. ultrafast: frame= 246 fps= 14 q=-0.0 Lsize= 3782kB time=00:00:10.77 bitrate=2876.6kbits/s speed=0.603x [08:39:56 CET] <memfrob> placebo: frame= 236 fps= 14 q=-0.0 Lsize= 3646kB time=00:00:10.13 bitrate=2948.4kbits/s speed=0.584x [08:41:32 CET] <memfrob> ultrafast at 10.77 is 3.7MB but placebo at 10.13 is 3.6MB -- this is not right. [08:42:45 CET] <memfrob> `-c:a copy` with `-preset placebo` -- the message: Codec AVOption preset (Configuration preset) specified for output file blah blah blah goes away, but the results do not change. [08:43:51 CET] <memfrob> `-c:a copy -preset placebo`3834kB time=00:00:10.28 -- looks like using h264_amf doesn't accept preset options. [08:46:00 CET] <memfrob> I apologize for all the lines, I'm not the best at expressing myself sometimes. [08:55:01 CET] <memfrob> oh ffs! -crf doesn't work either [08:55:22 CET] <memfrob> so -preset and -crf are both fubar with h264_amf [08:58:45 CET] <memfrob> Using `-q 0` should be lossless but with h264_amf, I get no "Codec AVOption" warning about it. [08:59:49 CET] <memfrob> (and in that line, I forgot to add that -q 0 appears to do absolutely nothing with -c:v h264_amf) [09:03:01 CET] <memfrob> I'm really sorry for blowing up the channel. All I meant was this: -crf -preset and -q are broken with h264_amf -- My last comment until further info is requested. [09:15:40 CET] <c_14> amf doesn't support crf, it only supports constant quantization, constant bitrate, peak constrained vbr and latency constrained vbr [09:16:04 CET] <c_14> and for constant quantization, the options are -qp_i/-qp_p/-qp_b [09:18:40 CET] <c_14> ffmpeg -h encoder=h264_amf should list all that for you [09:22:24 CET] <memfrob> so the equivalent to -crf 18 is -qp_i/p/b all at 18? [09:27:25 CET] <c_14> no [09:27:38 CET] <c_14> crf and quantization parameters are on completely different scales [09:27:53 CET] <c_14> If you want to try constant quantizer you'll just have to try values to see what looks good [09:28:04 CET] <c_14> I'd probably recommend you just use peak-constrained-bitrate though [09:39:30 CET] <memfrob> -rc is default to -1 but there's 4 things to choose from, cqp, cbr, vbr_peak and vbr_latency [09:39:50 CET] <memfrob> Does -rc count from -1, 0 or 1? [09:40:02 CET] <c_14> you can use the listed names [09:40:51 CET] <memfrob> -c:v h264_amf -rc vbr_peak 5000k: Unable to find a suitable output format for '5000k' [09:41:27 CET] <c_14> -b:v 5000k [09:42:06 CET] <memfrob> oh that one! [09:42:14 CET] <memfrob> I thought you meant the one in h264_amf lol [09:46:34 CET] <memfrob> Would you say 5000K is a good balance for x264 between quality and size? [09:47:05 CET] <c_14> I've never used the amf encoder, and it also depends on the video size [09:47:10 CET] <c_14> But it doesn't sound like a terrible idea [09:49:28 CET] <memfrob> c_14, I really appreciate the help. [09:52:38 CET] <memfrob> It might be a good idea to give people a more information message, like "-crf not supported by h264_amf" [09:53:03 CET] <anshul_> Does avcodec_send_packet() and avcodec_receive_frame() works in replacement of avcodec_decode_subtitle2 [09:54:07 CET] <memfrob> I'm going to guess, "no" but I don't know. [09:54:41 CET] <memfrob> avcodec_decode_subtitle2 stands out the most of those 3. [09:55:49 CET] <anshul_> thanks [09:55:52 CET] <memfrob> https://ffmpeg.org/doxygen/4.0/group__lavc__encdec.html [09:58:40 CET] <memfrob> is avcodec_decode_subtitle2 pulled from ffmpeg? Because that function still exists in vlc and mpv: https://github.com/mpv-player/mpv/blob/master/sub/sd_lavc.c#L320 [10:00:18 CET] <memfrob> https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=866 -- he posts the solution near the bottom [10:00:25 CET] <memfrob> maybe it will help your issue? [10:47:12 CET] <memfrob> Is this right? [10:48:16 CET] <memfrob> 5575kbps total bitrate x265: 4.06GB ...... 5317 total bitrate x264: 3.87GB [10:48:23 CET] <memfrob> *5317kbps [10:49:02 CET] <memfrob> the data bitrate is almost identical. 5001 for x265, 4995 for x264 [10:49:13 CET] <memfrob> how is the x264 video smaller?? [10:50:14 CET] <memfrob> somehow with a very similar bitrate, it's smaller by 200MB [11:09:10 CET] <dv_> I need some help with naming. I have a library here that has to mention hw video codecs as well as formats/standards like h264 etc. so I am looking for a terminology that is not confusing. h264 etc. are often called codecs, which is wrong though. so I was thinking of referring to the hw en/decode units as codecs and to h264 etc. as "compression format". "video format" is often also used for YUV color formats, [11:09:13 CET] <dv_> and "video standard" sounds more like PAL, NTSC, HDMI etc. [11:28:00 CET] <fella> depending on your audience i would probably rather stick with the wrong yet common naming convention where h264 is considered a codec. Why do you feel the need to clarify? [11:47:42 CET] <dv_> fella: because calling the hw unit "codec" and h264 also "codec" is confusing [15:30:34 CET] <spottich> re [15:30:48 CET] <spottich> i net help for an windows cmd [15:31:23 CET] <spottich> ffmpeg -y -i rtsp://stream.sdp -c copy -f hls -hls_time 3 -hls_list_size 3 -hls_wrap 10 http://localhost:8090/channel1.mjpg [15:31:44 CET] <spottich> i want to vonvert an rtsp stream to an mjpeg stream [15:31:56 CET] <spottich> convert sorry [15:32:14 CET] <spottich> could anybody help me for the right syntax [15:43:50 CET] <oliv3> about swscale, when i fixed all my bugs on the Open side, i thought it would work with no more modifications on Net but ran into this one. on the other side, guys on #ffmpeg told it was a security flaw/miss/error OpenBSD-side ;) [15:44:23 CET] <oliv3> (that it worked) [15:44:34 CET] <oliv3> oups [16:17:41 CET] <hifi> hey, I'm trying to figure out how to do kmsgrab from AMD discrete GPU and use Intel iGPU to hardware accelerate encoding to H.264. I can do them separately but I haven't yet found the right flags to ffmpeg to actually do that on-the-fly where work with VA-API, reason is my RX 480 can't encode 1080p60 without dropping frames but for some reason the intel iGPU can, here's the grab command line that works with [16:17:48 CET] <hifi> x264, looking for hints how to properly move the buffer ... [16:17:50 CET] <hifi> ... from AMD KMS plane over to Intel to encode: https://pastebin.com/raw/Z4DXqjjJ [16:24:45 CET] <Aerroon> i use ffmpeg to demux mkv files to mp4 files for furrther editing [16:25:12 CET] <Aerroon> i do ffmpeg -i "video.mkv" -vcodec copy -an "video.mp4" [16:25:31 CET] <Aerroon> and i have this video encoded by nvenc that's 3840x2160 [16:25:44 CET] <Aerroon> yet for some reason ffmpeg's output ends up being 3824x2178 [16:26:14 CET] <furq> Aerroon: pastebin the command line and full output [16:28:40 CET] <Aerroon> was in a bat file, so let me run it again [16:30:14 CET] <Aerroon> https://pastebin.com/Sh109B6C [16:31:12 CET] <furq> where's it showing up as 3824x2178 [16:31:21 CET] <Aerroon> in VLC [16:31:36 CET] <Aerroon> and when i import it into premiere it has these slight back bars on the side [16:32:12 CET] <Aerroon> https://cdn.discordapp.com/attachments/303861570231074816/528958415821864978... [16:32:47 CET] <furq> weird [16:33:33 CET] <Aerroon> i know [16:33:44 CET] <Aerroon> at first i thought this was obs doing it and googled it [16:33:52 CET] <Aerroon> and found that other people have had a similar issue [16:34:09 CET] <Aerroon> but then i read more into it and found out that obs doesn't seem to be involved [16:34:16 CET] <Aerroon> and i checked that my original file did not have that resolution problem [16:35:38 CET] <furq> well h264 is never really 3820 wide because it's not mod16, it's 3824 and then there are cropping flags in the video bitstream [16:36:03 CET] <furq> but that shouldn't be changed by remuxing and it shouldn't ever show up in video players [16:36:10 CET] <furq> and also 2178 is not mod16 so ??? [16:36:39 CET] <furq> i would be tempted to say vlc is broken (not for the first time) if you hadn't mentioned premiere was showing borders [16:37:02 CET] <Aerroon> i tried a test render too [16:37:40 CET] <Aerroon> and it certainly came with the borders [16:37:45 CET] <Aerroon> they're rather slight though [16:41:39 CET] <Aerroon> even the preview window in davinci resolve shows me the slight black borders [16:54:24 CET] <Aerroon> i'll test this stuff some more, i'll try to save it in a container that premiere can read to then see if the issue persists even if it doesn't go through ffmpeg, but i'm unable to try that right now [21:28:56 CET] <memfrob> Hi, is ffmpeg.pastebin.com broken? [21:29:14 CET] <furq> yeah but it's the same as pastebin.com anyway [21:29:33 CET] <memfrob> Will use pastebin.com then! [21:33:43 CET] <memfrob> I have an x264 video that is smaller than an x265 video, but the bitrate is almost the same. x265: https://pastebin.com/gKL3RyyA x264: https://pastebin.com/dAx8KKSg [21:35:10 CET] <memfrob> Also, the original source doesn't have any errors, but after re-encoding it through ffmpeg, I see this: Unsupported codec with id 100359 for input stream 2 [21:36:53 CET] <memfrob> There are no subtitles, not in the re-encoded one or the old one. [21:57:55 CET] <memfrob> My PS4 is asking me to connect to the internet to watch videos off my USB drive so hold on a second.. [21:58:24 CET] <BtbN> yay DRM [22:03:46 CET] <memfrob> Cool! All the files work on the PS4, no "unsupported media" messages or audio stretch issues, super fast video playback, etc. [22:03:51 CET] <memfrob> ffmpeg is THE BEST! [22:04:35 CET] <memfrob> And the best part is that it doesn't take very long to do all this because it can use my video card for encoding! [22:07:40 CET] <memfrob> rexxster, I see you're using a Minnesota IP address, how is it there? cold? Do you like hockey? [22:07:48 CET] <BtbN> Keep in mind that hardware encoding will yield notably worse results [22:07:57 CET] <BtbN> The only time you ever want to use it is if you can't spare the CPU time [22:08:21 CET] <memfrob> BtbN, Using -b:v 10000k (if the source bit rate is even higher) solves that issue [22:08:36 CET] <BtbN> x264 at the same bitrate will still be better [22:09:05 CET] <memfrob> hell, I could use a blu-ray and use -b:v 40000k with -quality quality (GPU prioritizes quality over speed) and it'd come close. [22:09:37 CET] <BtbN> Sure you can throw bitrate at it to compensate, but x264 will always have the better quality/bitrate ratio [22:10:46 CET] <memfrob> The real reason you're telling me this is because you're all about morals and royalty free stuff, right? [22:11:26 CET] <BtbN> ? [22:11:59 CET] <memfrob> Using the GPU for encoding, a GPU that has closed source atombios on it and all the rest would make Richard Stallman scream bloody murder. [22:12:18 CET] <BtbN> Yeah, and because I hate it so much I ported it to ffmpeg... [22:12:50 CET] <memfrob> If you hate your own work so much because it's quality is worse, why did you do it? [22:13:48 CET] <memfrob> There's always an agenda behind people's statements, you're advertising away from your own work, which I find crazy. [22:15:50 CET] <BtbN> Your usecase just isn't what hardware encoders are designed for. [22:16:49 CET] <BtbN> There are indeed only very few cases where they are useful. Usually only when the CPU isn't free to do the work instead. [22:16:54 CET] <memfrob> I can hardly tell a difference, and the reason why I can at all is because I used a slightly lower bitrate than the source. [22:18:05 CET] <memfrob> I multitask. My GPU is a R9 290X which is old but still very fast even to this day. It can do 500 things at once. Encoding a movie off the CPU bogs it down. [22:19:34 CET] <memfrob> hardware encoders are designed to encode faster than CPU, and if I can do something in hardware, I will because it's faster. [22:22:43 CET] <furq> there's a reason all the consumer video encoding asics are attached to gpus [22:22:59 CET] <memfrob> So we can use them? [22:23:03 CET] <furq> they're designed for getting a passable quality video without touching the cpu [22:23:14 CET] <furq> which is a nice feature for Pro Gameing [22:23:32 CET] <BtbN> they're not even neccesarily faster than using the CPU [22:23:35 CET] <furq> if you're just doing this to get your videos on another device then sure [22:23:39 CET] <furq> but you shouldn't use it for archival [22:23:40 CET] <BtbN> It's just that they don't use the CPU at all [22:23:50 CET] <memfrob> <furq> if you're just doing this to get your videos on another device then sure [22:23:55 CET] <memfrob> KABOOM!!!!!! [22:24:06 CET] <furq> right [22:24:49 CET] <memfrob> BtbN, If I were you, I'd be happy if someone used something I wrote. [22:24:50 CET] <BtbN> Unless your CPU is really bad, fps wise x264 and nvenc or one of the other hardware encoders won't be that far off of each other [22:25:11 CET] <BtbN> Why would I care what you use? [22:25:27 CET] <furq> BtbN: was it you who wrote the amf stuff [22:25:33 CET] <BtbN> no, nvenc [22:25:35 CET] <furq> oh [22:25:37 CET] <furq> nvm then [22:25:47 CET] <memfrob> That's not what he told me. [22:25:59 CET] <furq> i don't think you mentioned amf before he said that [22:26:07 CET] <furq> and it's generally a safe bet people mean nvenc because that's massively more popular [22:26:07 CET] <memfrob> I said atombios. [22:26:21 CET] <furq> i've never heard that word until just now [22:26:24 CET] <memfrob> I'm actually surprised BtbN isn't narcissistic. [22:28:20 CET] <memfrob> My CPU isn't the greatest btw, my GPU is much better at kicking ass and taking names. Damn companies take forever to pay. [22:28:41 CET] <memfrob> Will upgrade soon to Ryzen (time to get yelled at by Intel fanboys) [22:29:46 CET] <BtbN> The GPU is actually entirely uninvolved with the video encoding. They are terrible at it. It's dedicated silicon that does it. [22:30:26 CET] <memfrob> If it's the minions on the graphics card that do the work, it's still faster than my CPU xD [22:31:15 CET] <memfrob> Now you're arguing semantics. Can you get help? Please? [22:31:42 CET] <BtbN> I'm not arguing at all even... [22:31:54 CET] <memfrob> GPU vs dedicated silicon. [22:32:01 CET] <memfrob> You just _had_ to mention it. [22:32:20 CET] <BtbN> And in what way does it hurt you that you now know about the difference? [22:32:54 CET] <memfrob> Just making an observation. [22:33:14 CET] <memfrob> I gotta run, literally. Sun goes down in an hour. Take care everyone! [00:00:00 CET] --- Mon Dec 31 2018