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

[burek]

[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/unknown.png
[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