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

[burek]

[01:50:43 CET] <solidus-river> do I need to encode audio with a AVFormatContext if it expects it? using libx264
[01:53:29 CET] <klaxa> shouldn't encoding expect an AVCodecContext?
[01:54:39 CET] <klaxa> also you said you were using the new api, according to the docs its deprecated >use avcodec_send_frame()/avcodec_receive_packet() instead
[01:54:57 CET] <klaxa> https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga9395cb802a5febf1f00df31497779169 and https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga5b8eff59cf259747cf0b31563e38ded6
[01:55:21 CET] <klaxa> never used libavcodec though
[02:07:10 CET] <DHE> an AVFormatContext isn't needed for transcoding. but usually you're going to put that data somewhere and an avformat is most commonly used
[02:30:24 CET] <solidus-river> yeah, i'm trying to take framebuffer dumps and encode them to an h264 metroska video, this whoile process has been painstaking, i've tried 2 examples which have each been missing vital parts and apparently I'm still on this old format, the only thing i've gotten to work is outputting raw mpeg1 video
[02:30:36 CET] <solidus-river> the community on this channel has been helpful though
[02:30:55 CET] <solidus-river> its frustrating that there isn't up to date examples or a higher level view of what is expected of me as a library user
[02:31:39 CET] <solidus-river> although of course I'm grateful to have access to a FOSS library that does so much, it seems like documentation is very tribal
[02:32:04 CET] <solidus-river> I'm suprised because I've known ffmpeg as the defacto audio / video encoder since I've started tinkering with those things some 11 years ago
[02:32:19 CET] <DHE> you have looked in the doc/examples directory, right?
[02:32:37 CET] <DHE> some of it is a bit dated and may produce deprecation warnings, but they should still work
[02:34:11 CET] <solidus-river> DHE: I have been using those, they don't work
[02:34:38 CET] <solidus-river> DHE: for example the muxing one is definitely not calling av_register_all or or avcodec_register_all
[02:35:09 CET] <solidus-river> and still on the old api, and I can't get it to work in my project after calling av_register_all, it does not appear to generate a packet ever
[02:35:50 CET] <solidus-river> and I'm not clear on why it is encoding a frame index into the YUV image Cb and Cr components as the examples i've found for mpeg do not do that
[02:36:10 CET] <solidus-river> likewise the example doesn't sent any optional context private settings for H264 encoding which most other examples do
[02:37:17 CET] <kepstin> the defaults for the libx264 codec are actually reasonable, so... :/
[02:37:50 CET] <kepstin> (btw, when encoding with libx264, it will often require a lot of input frames before it starts giving you encoded output)
[02:37:58 CET] <solidus-river> am I choosing the right sample to try to get a working codepath from by working off of https://ffmpeg.org/doxygen/trunk/muxing_8c-example.html
[02:38:20 CET] <solidus-river> kepstin, aye, I've sent it 60*30 frames and gotten no output packets
[02:38:52 CET] <kepstin> well, it shouldn't take that many.
[02:38:56 CET] <DHE> to a point. I'm going to encourage selecting either a bitrate, qp or crf setting because the defaults for those suck
[02:39:10 CET] <kepstin> it must be giving you an error code somewhere...
[02:39:15 CET] <solidus-river> i'm unclear in this new context how to ensure I have written all frames as well, this example doesn't seems to assume that if you are done feeding the video frames as well as not recieved a packet then the encoding is finished
[02:39:37 CET] <solidus-river> i'm checking the return codes of all function calls, it seems to just sit there gobbling up frames in avcodec_encode_video2
[02:40:01 CET] <DHE> libx264 will do that by default. it buffers a lot for bitrate estimation and frame type decision making
[02:40:13 CET] <kepstin> sure, but that shouldn't be more than a few hundred frames
[02:40:17 CET] <kepstin> at max
[02:40:33 CET] <DHE> if it's a problem, you can av_dict_set(&dictptr, "preset", "zerolatency", 0);
[02:40:43 CET] <DHE> 100 sure sounds about right.
[02:42:55 CET] <solidus-river> at this point i'm worried i'm just not doing something vital
[02:43:14 CET] <solidus-river> I've copied the example but I'm not sure that means I've got everything that's necissary done
[02:43:31 CET] <kepstin> can't really tell you without looking at your code :/
[02:43:35 CET] <solidus-river> I'm going to remove any extra steps I had been doing that the example had not, ensure the codec / container is chosen correctly
[02:43:54 CET] <solidus-river> yeah, I'll post another pastebin, i made one earlier but I've since doublec checked and caught a couple things
[02:45:17 CET] <solidus-river> this is the most recent version https://pastebin.com/JLTVTRE2
[02:46:56 CET] <solidus-river> afaik i've gotten everythign from the example except for the use of a temporary frame since my temp frame is an rgb dump from the opengl framebuffer, frame timing checks since I'm manually pushing frames through to match the fps for the expected video time in my render loop, and then some checks to ensure that the codec requires a file to be open since my codec / container is always libx264 and matroska
[02:52:12 CET] <solidus-river> i'm not sure what I'm supposed to pass to avcodec_open2 for the options dict, the example uses some things it reads from the cli params but I don't have any to set afaik so I've been passing NULL as the options dict reference for avcodec_open2, unsure if that is a problem
[02:55:26 CET] <solidus-river> oh interesting, something i've changed makes avcodec_open2 no longer return true, i removed my call to avcodec_get_context_defaults, perhaps i should put that back
[02:56:54 CET] <kepstin> note that in most cases when avcodec_open2 returns failure, it also prints out a log message saying what was wrong
[03:00:47 CET] <solidus-river> yeah, thats been a wierd thing i'm running up against that might explain a lot of my frustration. Those messages might be super helpful, for some reason I'm not getting them
[03:01:28 CET] <solidus-river> I've been assuming its something to do with using a visual studio project that makes normal prints to stderr not show up on output when they come from mingw compiled libs :? honestly not sure at all
[03:02:56 CET] <kepstin> you can install a custom log message handler, if you have some working way of printing output that you can do instead of whatever ffmpeg is doing.
[03:04:05 CET] <solidus-river> how do i grab what ffmpeg is logging in that case though?
[03:04:20 CET] <kepstin> by installing a custom log message handler.
[03:04:28 CET] <kepstin> https://ffmpeg.org/doxygen/2.5/group__lavu__log.html#ga14034761faf581a8b9ed6ef19b313708
[03:04:47 CET] <solidus-river> wierd, i now get a valid mkv h264 encoded video, but when i feed it 60 frames at 60 frames a second, it only out puts 9 packets and the video is much shorter than expected
[03:05:02 CET] <kepstin> solidus-river: are you flushing the codec at eof?
[03:05:20 CET] <kepstin> you need to call _encode2 repeatedly with NULL input frame until it stops giving you output packets
[03:05:54 CET] <solidus-river> kepstin, no, one example had that but the one i copied currently did not, should i put back calls to fflush() as well? or just repeatedly call encode2?
[03:06:03 CET] <kepstin> fflush is unrelated
[03:06:27 CET] <kepstin> just repeatedly call avcodec_encode_video2() until the encoder stops giving you packets
[03:06:44 CET] <kepstin> (the new encoding api makes it a bit more obvious how this is supposed to work)
[03:09:56 CET] <solidus-river> so would the right control flow be to call avcodec_encode_video2 untill i recieve a packet, then keep calling it untill i no longer receive packets?
[03:10:08 CET] <solidus-river> how long should i keep calling it before i give up on waiting for it to give a packet back?
[03:10:28 CET] <kepstin> every time you have an input frame, call avcodec_encode_video2() with that frame
[03:10:44 CET] <solidus-river> then after all are done, call it untill it does not return a packet :?
[03:10:47 CET] <kepstin> when you run out of input frames, call avcodec_encode_video2() with NULL until it stops giving you packets
[03:14:34 CET] <kepstin> (I really do recommend using the avcodec_send_frame() & avcodec_receive_packet() functions instead of avcodec_encode_video2() for new code; imo they're a bit easier to understand and match the codec behaviour better)
[03:15:05 CET] <kepstin> although the code sometimes looks a bit longer because it means 2 function calls and a loop instead of one call.
[03:15:33 CET] <solidus-river> yeah, I'd like to, just not knowing ffmpeg itself and not having existing examples using them its a bit intimidating. I was hoping to get the old flow working before switching over
[03:15:49 CET] <solidus-river> I think the old stuff is working for me now though, although the quality is a bit bad
[03:16:04 CET] <kepstin> well, the api used doesn't change the quality
[03:16:13 CET] <kepstin> that's just up to picking settings for the encoder correctly :)
[03:17:00 CET] <solidus-river> yeah, i have 400000 bitrate which might be low? and then i havent set qwp or crf, i was worried about changing those as I'm not sure what valid values are, is there a high level doc on those types of options I can stare at for a while?
[03:17:23 CET] <solidus-river> or are those more options you get a feel for after encoding a couple videos
[03:17:26 CET] <kepstin> with x264 I usually recommend not setting bitrate.
[03:17:34 CET] <kepstin> you'd normally use "crf" mode
[03:18:25 CET] <kepstin> where the crf option takes a number from, iirc, 0 to 63 or something like that, lower numbers are higher quality, default is 23 or thereabouts. Most people consider around 18 to be "very high" quality.
[03:19:06 CET] <kepstin> note that the results of x264 vary based on the "preset" option as well, slower presets give better efficiency, and the crf scale varies slightly depending on the preset used.
[03:20:11 CET] <gnarface> one thing i found highly unintuitive is that x264 takes *less* cpu power the higher quality you set it
[03:20:31 CET] <gnarface> that's backwards from my experience with other codecs (audio as well as video)
[03:20:42 CET] <kepstin> hmm, it's not a linear relationship
[03:20:50 CET] <kepstin> parts of it take less cpu, other parts take more
[03:21:16 CET] <gnarface> well, on old hardware it's the cpu part that makes a bigger difference
[03:21:18 CET] <kepstin> e.g. as quality goes up, so does the output bitrate, which means the entropy encoder requires more cpu.
[03:21:45 CET] <gnarface> sure, and if you're using like -preset ultrafast it also balloons the file size out to crazy amounts below 18
[03:21:52 CET] <gnarface> so the bandwidth can become problematic too
[03:22:14 CET] <kepstin> ultrafast disables half the codec features tho
[03:22:29 CET] <gnarface> oh?  maybe that's why then
[03:22:42 CET] <kepstin> i mean, it's really not all *that* much better than mpeg2 or something at that point
[03:22:53 CET] <gnarface> it's better
[03:23:07 CET] <gnarface> heh, i've been testing
[03:23:13 CET] <kepstin> but, i mean, it's a super fast threaded encoder that's as good as a *really good* mpeg 2 encoder while being a lot faster.
[03:23:51 CET] <solidus-river> wow, thats significantly better without setting the bitrate
[03:24:06 CET] <gnarface> yea it's happier if you just control it by -crf and -preset
[03:24:24 CET] <kepstin> yeah, if you don't set the bitrate, it'll use crf mode by default, and the default there gives decent, but not great, results.
[03:24:58 CET] <kepstin> adjust the crf option to taste (you can set it as an AVOption, similar to how you're already setting the preset)
[03:25:01 CET] <gnarface> well the fact it's a quality metric not a bitrate metric makes for a nice viewing experience if you're streaming locally
[03:25:51 CET] <gnarface> (though remotely it may screw with buffering if you don't have enough bandwidth)
[03:26:24 CET] <kepstin> you can use crf in combination with vbv for streaming applications. It's a bit tricky tho because some sites (twitch, iirc?) want min bitrate as well as max :/
[03:26:29 CET] <solidus-river> cool, just did one at the default, going to try bumping it up to 40 or so
[03:26:38 CET] <kepstin> higher numbers are lower quality :)
[03:28:09 CET] <solidus-river> :X
[03:28:14 CET] <kepstin> note that when using 8bit x264, crf 0 is lossless (but the recommended way to enable lossless uses a different option)
[03:49:34 CET] <solidus-river> kepstin, gnarface thanks for helping me, I'm going to try to convert it to the new api tomorrow.
[03:50:00 CET] <gnarface> i didn't really help but you're welcome anyway
[03:54:26 CET] <kepstin> new api is simple. call avcodec_send_frame(), then in a loop call avcodec_receive_packet() until it returns AVERROR(EAGAIN)
[03:55:03 CET] <kepstin> when you are done, call avcodec_send_frame with NULL, then in a loop call avcodec_receive_packet() until it returns AVERROR(EOF) (i think)
[05:46:58 CET] <chocolaterobot> kepstin: I uploaded the mkv to youtube and it says "The video has failed to process. Please make sure you are uploading a supported file type." and it links to  https://support.google.com/youtube/troubleshooter/2888402?visit_id=1-636559947622971073-1713140050&hl=en-GB&rd=1
[05:47:56 CET] <kepstin> ah, maybe youtube does need the -pix_fmt yuv420p option then
[05:48:07 CET] <kepstin> (output option, goes before the output filename)
[05:49:26 CET] <chocolaterobot> kepstin: it does not accept MKV, I think
[05:49:37 CET] <kepstin> no, mkv works fine, I use it all the time
[05:50:16 CET] <chocolaterobot> you've uploaded mkv to youtube?
[05:50:57 CET] <chocolaterobot> kepstin: https://support.google.com/youtube/answer/1722171 (Recommended upload encoding settings)
[05:51:28 CET] <kepstin> yes, i have a youtube channel, I typically encode to h264+opus in mkv
[05:52:09 CET] <chocolaterobot> so should the command now look like this: `  ffmpeg -framerate 6 -loop 1 -i image.png -i audio.ogg -c:v libx264 -preset veryfast -c:a copy -shortest -pix_fmt yuv420p  output.mkv` ?
[05:52:22 CET] <kepstin> yeah, give that a try.
[05:52:43 CET] <kepstin> using the recommended settings may, in some cases, cause youtube to make the video available slightly sooner, but that's really about it
[05:53:40 CET] <kepstin> but they accept a really wide variety of input formats (the ingestion frontend uses ffmpeg to decode at least some of them)
[08:24:17 CET] <Johnjay> i'm continually surprised that big corporations use ffmpeg
[08:24:28 CET] <Johnjay> i would have thought they'd use their own big google encoder thing
[08:26:29 CET] <gnarface> usually they do actually
[08:26:42 CET] <gnarface> (but usually it's just a commerical patch on ffmpeg)
[08:27:07 CET] <gnarface> which is actually a healthy way for the industry to function with open source software
[08:27:20 CET] <gnarface> so don't point it out to the plebes, or you'll ruin the magic
[08:28:03 CET] <Johnjay> haha ok
[08:28:21 CET] <Johnjay> also i made a mistake, i read that ilove whoever had changed their nick
[08:28:30 CET] <Johnjay> thought kepstin had said that less than an hour ago
[08:40:49 CET] <Hitechcg> Johnjay: from a company's perspective, they don't have to reinvent the wheel
[08:41:19 CET] <Johnjay> they don't have to but i figured theyd want to
[08:41:30 CET] <Johnjay> but patching ffmpeg is good probably just shows the quality of fffmpeg
[08:41:31 CET] <furq> if it makes you feel better there are plenty of big corporations that don't use ffmpeg
[08:41:44 CET] <gnarface> well one that they were paying the most for, google actually bought to open source
[08:41:50 CET] <furq> i'm pretty sure none of apple's stuff uses it
[08:41:51 CET] <gnarface> and it's now part of ffmpeg
[08:41:55 CET] <Hitechcg> they probably want to in order to keep their super secret source codes proprietary, but using ffmpeg saves money for them
[08:41:59 CET] <Hitechcg> and effort
[08:42:31 CET] <Hitechcg> so the saved money/effort outweighs keeping their super secret source codes proprietary
[08:43:04 CET] <furq> they're under no obligation to contribute source back if they're using it internally
[08:43:15 CET] <furq> or release any of their sources
[08:45:45 CET] <Hitechcg> oh, I was thinking you meant "using" like embedding in a product
[08:46:37 CET] <pmjdebruijn> in that case the customer who gets the binary has rights to get the modified sources :)
[08:46:47 CET] <pmjdebruijn> at least with GPLed sourced
[08:46:50 CET] <pmjdebruijn> *s
[08:46:52 CET] <furq> right
[08:47:08 CET] <furq> but the two biggest companies that i know are using ffmpeg are only using it internally
[08:47:55 CET] <furq> i guess chromium on some platforms counts, but that's always been open-source
[09:00:04 CET] <JEEB> furq: software wise I'd say steam and chromium are probably some of the two biggest?
[09:00:10 CET] <JEEB> which have libav*
[09:09:00 CET] <furq> isn't steam just using CEF
[09:11:29 CET] <JEEB> I just remember it having DLLs for lavc etc
[09:17:09 CET] <gnarface> i used to work tangentially to video production, back when you still had to pay for vp6
[09:17:20 CET] <gnarface> we used ffmpeg as a critical part of the production infrastructure
[09:18:03 CET] <gnarface> we also used mencoder but we switched to ffmpeg because it was fast enough to save money (cpu core counts back then were not what they are now)
[09:18:36 CET] <gnarface> we did not advertise the use of open source software
[09:18:45 CET] <gnarface> i assume many places still are similar
[09:19:22 CET] <gnarface> just quietly using it behind the scenes internally, because it's simply the cheapest option, even including hardware, electricity, and time costs
[09:22:11 CET] <JEEB> yea, pretty much every major site that deals with video probably has FFmpeg there somewhere :P
[09:24:06 CET] <furq> every site that deals with other people's video, sure
[09:25:08 CET] <gnarface> well, we also had final cut
[09:26:13 CET] <gnarface> and it wasn't other people's video
[09:26:52 CET] <gnarface> but there was a lot of it
[09:29:04 CET] <furq> not only those, of course, but something like youtube has no real alternative
[09:29:32 CET] <furq> whereas something like itunes doesn't really need to use it at all (and doesn't as far as i know)
[09:29:46 CET] <gnarface> true, and quite possibly the reason why google open sourced vp8 for us
[09:29:48 CET] <furq> although netflix is in the same boat and i'm pretty sure those guys are using it
[09:30:14 CET] <gnarface> (it may have been a cheaper move for them to give it away than to buy a private license)
[09:30:40 CET] <furq> i suspect they were just sick of paying mpeg licensing fees
[09:30:49 CET] <furq> which turned out to be a smart move given the whole hevc licensing clusterfuck
[09:30:50 CET] <gnarface> heh, well maybe that too
[09:43:18 CET] <StCyr> Hi
[09:44:12 CET] <StCyr> this may sound stupid, but is it possible to run ffplay from a non graphical runlevel and direct it to output its streams to an hdmi port?
[09:45:30 CET] <gnarface> doesn' sound stupid at all to me, but i can tell you use RedHat
[09:45:38 CET] <StCyr> (I want to run the most lightweight distribution possible => I would like to avoid running a graphical interface)
[09:45:51 CET] <StCyr> gnarface: I'm a debianer ;-)
[09:45:58 CET] <gnarface> oh
[09:46:13 CET] <gnarface> well it's important to understand there's no such thing as a graphical or non-graphical runlevel
[09:46:25 CET] <StCyr> hu?
[09:46:38 CET] <gnarface> you can run graphical or non-graphical programs in any runlevel, but RedHat originally used a convention to default starting X11 in just one of them
[09:47:03 CET] <gnarface> it's neither here nor there, but the answer to your question is "yes, that's possible, as long as you don't get confused by thinking it has anything to do with the runlevel"
[09:47:48 CET] <StCyr> gnarface: ok, yeah I understand what you mean. No problem with managing runlevel and Xorg here.
[09:48:01 CET] <gnarface> there's a secondary issue though
[09:48:26 CET] <gnarface> which is that while it's theoretically possible you can get "non-graphical" output on your HDMI port it's not always something hardware/driver allowed
[09:48:40 CET] <gnarface> depends greatly on the drivers and the hardware in question
[09:49:47 CET] <gnarface> that said, if you're booting to a text-mode login and you can see it on the HDMI port, you're probably in good shape
[09:50:51 CET] <gnarface> truthfully, it's probably a lot easier to use Xorg bare, without a window manager, or just with a very low-weight one, than do this though
[09:51:17 CET] <StCyr> gnarface: what do you mean by "you can see it on HDMI"? what's it? the driver?
[09:51:17 CET] <gnarface> unless you're on something like a raspberry pi
[09:51:32 CET] <StCyr> gnarface: that's what I have, a raspberry pi :-)
[09:51:39 CET] <gnarface> dksj;afStCyr: sorry,
[09:51:41 CET] <gnarface> heh
[09:52:03 CET] <gnarface> StCyr: second question first then, your fix is ridiculously simple: omxplayer -o hdmi [filename]
[09:52:36 CET] <StCyr> gnarface: I read about omxplayer. But, omxplayer doesn't seem to support udp input stream...
[09:52:45 CET] <StCyr> (thanks for the help btw)
[09:52:46 CET] <gnarface> StCyr: the answer to the previous, now irrelevant question, was just that by "it" in that context i meant the login prompt itself
[09:53:26 CET] <gnarface> StCyr: yea, everything else about omxplayer besides the rpi console video support is inferior as a player, just use a fifo and pipe your udp stream through that
[09:53:34 CET] <StCyr> ok get it (the "it = login prompt")... makes sense in fact :-D
[09:54:21 CET] <gnarface> if you find anything besides omxplayer that can get acceptable HD video playback performance on a rpi, i'd be interested to know
[09:54:44 CET] <gnarface> i tried a patched version of vlc a while back, and it was still too slow to play standard def. without overclocking the cpu
[09:55:22 CET] <gnarface> omxplayer though will play 1080px60 perfectly though as long as it's the right pixel format
[09:56:08 CET] <gnarface> (i noticed it hates -pix_fmt yuyv422, for example, but loves -pix_fmt yuv420p)
[09:56:21 CET] <StCyr> so, you mean something like this "vlc-i myfile.mkv udp://@239.0.0.1:1234 ---....sending over the wire....---> nc udp://239.00.01:123 | omxplayer -o hdmi ?
[09:56:55 CET] <gnarface> uh, yea, you can simplify it a lot though
[09:57:05 CET] <gnarface> swap vlc for cat
[09:57:29 CET] <gnarface> (your nc syntax looks invalid as far as i know but i think i get what you mean)
[09:57:40 CET] <StCyr> that's interesting...
[09:57:52 CET] <gnarface> ok hang on i can give you an example in pieces, gimme a second
[09:58:06 CET] <StCyr> ok I'm not a "nc" expert. But I guess I'll be able sort that out
[09:58:26 CET] <gnarface> ok, first, on the pi:
[09:58:56 CET] <gnarface> mkfifo ./test
[10:00:03 CET] <gnarface> nc -l -p 8000 > test & omxplayer -p -o hdmi ./test
[10:00:26 CET] <Nacht> https://streamlink.github.io/index.html might be usefull as well
[10:00:29 CET] <Nacht> It can pipe to omx
[10:00:30 CET] <StCyr> ok, I understand what you mean
[10:00:45 CET] <Nacht> I use it to play twitch streams trough my RPI
[10:01:07 CET] <gnarface> StCyr: now, before nc times out, you have to start this on the host (source machine) then: cat [video file] | nc -u [rpi hostname] 8000
[10:01:26 CET] <gnarface> (-u for udp)
[10:01:29 CET] <gnarface> should work
[10:01:41 CET] <gnarface> you can do it with ssh too but it will add delay
[10:01:53 CET] <gnarface> (ssh instead of netcat)
[10:03:03 CET] <gnarface> StCyr: oh, on that omxplayer command, remove "-p" too just keep the "-o hdmi" ... i don't know what -p was for i was just testing stuff
[10:03:20 CET] <furq> uh
[10:03:50 CET] <furq> you should be able to build ffmpeg with --enable-mmal, build sdl2 with --enable-video-directfb, and build mpv against those
[10:04:21 CET] <gnarface> for the pi, furq ?  there's some omx-something hardware support you need to i think... is it available for ffmpeg, do you know?
[10:04:36 CET] <gnarface> need too*
[10:05:09 CET] <gnarface> the cpu in the rpi can't play anything of consequence in software sufficiently
[10:05:11 CET] <furq> yes, but omx is for encoding
[10:05:24 CET] <furq> at least as far as ffmpeg is concerned
[10:05:30 CET] <gnarface> it needs the hardware decoder support too for HD to work
[10:05:31 CET] <furq> --enable-omx for hwenc, --enable-mmal for hwdec
[10:06:02 CET] <gnarface> oh i see, mmal is the decoder part, i didn't know that
[10:06:06 CET] <gnarface> i thought they were both "omx"
[10:06:25 CET] <furq> they're both part of openmax but ffmpeg labels them differently
[10:06:37 CET] <gnarface> i gotcha
[10:06:48 CET] <gnarface> thanks for the clarification, i appreciate that
[10:07:18 CET] <gnarface> the vlc patch helped, but not enough to make it usable for HD
[10:07:35 CET] <gnarface> some of that may have been due to limitations of the Xorg driver though, i don't know
[10:07:36 CET] <furq> also you don't need directfb unless you're trying to do this without x11
[10:07:57 CET] <furq> and obviously your distro's sdl2 might already include directfb
[10:07:57 CET] <gnarface> StCyr specifically did say he wanted to avoid x11
[10:08:00 CET] <furq> yeah
[10:08:08 CET] <gnarface> which on the original rpi seems like a good idea to me, after my experience with it
[10:08:59 CET] <StCyr> sorry, I have to leave for a while (meeting)
[10:09:04 CET] <furq> looks like debian's sdl doesn't link directfb
[10:09:10 CET] <furq> that should all be easy enough to cross-compile though
[10:09:37 CET] <gnarface> you could probably just rebuild the source package on the pi itself
[10:09:43 CET] <furq> sure
[10:09:45 CET] <furq> it'll take a while though
[10:10:13 CET] <gnarface> i guess i don't really know how big of a build SDL is
[10:10:55 CET] <gnarface> debootstrapping a crossbuild chroot on a DSL line isn't exactly a quick process either...
[10:11:38 CET] <furq> you don't really need a chroot for that
[10:13:35 CET] <StCyr> but I'm getting a little bit lost now. Please allow me to re-focus the debate: I've bought a raspeberry pi 3 and I'm looking for the most performant way to output streams received over UDP to its HDMI port (That's why I was thinking about disabling X11: To lower CPU/memory usage on the raspberry).
[10:13:52 CET] <StCyr> What are your advice to have the most performant solution in my case?
[10:13:54 CET] <gnarface> well you do if you're on debian sid and don't want to mangle your install :-p
[10:13:59 CET] <gnarface> furq: ^
[10:14:18 CET] <StCyr> *advices*
[10:14:22 CET] <furq> ffmpeg and sdl2 both definitely respect PREFIX
[10:14:29 CET] <furq> i assume directfb does as well
[10:14:33 CET] <StCyr> (I'll read you later)
[10:14:35 CET] <gnarface> StCyr: my advice was to do exactly that, as you planned, and to use omxplayer to do it
[10:15:21 CET] <gnarface> StCyr: furq suggests it should be possible to rebuild the debian ffmpeg package to do the same thing (so you could use ffplay instead)
[10:15:49 CET] <furq> well you'd use mpv rather than ffplay
[10:16:14 CET] <gnarface> furq: no, it's about if you're building other stuff and the 32-bit/64-bit build dependencies don't always play nice together on the same root
[10:16:40 CET] <gnarface> it's a problem with some of the packages, maybe not any of the ones for ffmpeg i don't know
[10:16:50 CET] <gnarface> but i build wine too
[10:16:55 CET] <gnarface> and it's a mess
[10:16:58 CET] <furq> well if you're on sid then you can just use multiarch for all the dependencies and not have to worry about it
[10:17:32 CET] <furq> also i looked further into it and apparently directfb through sdl is broken and not worth using
[10:17:41 CET] <gnarface> that's what i'm saying exactly is wrong; multiarch isn't ubiquitously supported by all the packages you need for wine, so i didn't know (wouldn't gamble on it) that it is for the dependencies of ffmpeg and sdl2
[10:17:58 CET] <furq> i've used multiarch to build ffmpeg for my pi before
[10:18:39 CET] <furq> all the dependencies that are in the debian armhf ffmpeg package are obviously there
[10:19:16 CET] <furq> with that said you don't really need to include anything if you're just making a static build of mpv
[10:19:25 CET] <furq> there's hardly anything that needs an external lib for decoding
[10:19:54 CET] <gnarface> the default omxplayer build is static too
[10:20:13 CET] <furq> also yeah mpv has its own framebuffer vo now
[10:20:18 CET] <furq> so you should just need ffmpeg with mmal
[10:20:31 CET] <gnarface> the problem i had with the rpi1 in X11 was with the framebuffer driver not having hardware accel support
[10:20:42 CET] <gnarface> it works but it's barely better than a generic framebuffer driver
[10:21:14 CET] <gnarface> i don't need it at all at the console
[10:21:21 CET] <gnarface> it's... part of the kernel and cpu somehow
[10:21:31 CET] <gnarface> arm hardware is weird
[10:21:38 CET] <furq> https://github.com/mpv-player/mpv/wiki/FAQ#Video_on_RPI_doesnt_work_or_is_too_slow
[10:21:40 CET] <Nacht> Can't omxplayer just play the UDP stream ?
[10:21:43 CET] <furq> this all looks nice and simple
[10:21:48 CET] <gnarface> Nacht: hahahaha, NO!
[10:21:48 CET] <Hitechcg> isn't the framebuffer on the GPU?
[10:21:59 CET] <gnarface> Nacht: hilarious, but no.  you have to use a fifo and netcat.
[10:22:15 CET] <furq> can you not just pipe from ffmpeg into omxplayer
[10:22:17 CET] <gnarface> Hitechcg: well they're the same core
[10:22:30 CET] <gnarface> Hitechcg: the memory is in there too
[10:22:32 CET] <Nacht> Let me check, afaik, I'm playing an UDP stream on my rpi's at this moment using UDP
[10:23:02 CET] <Nacht> yup, def playing an UDP stream using omxplayer
[10:23:03 CET] <gnarface> furq: no, omxplayer doesn't even support stdin
[10:23:08 CET] <furq> nice
[10:23:13 CET] <gnarface> oh
[10:23:20 CET] <gnarface> heh, well my build is ancient, maybe i'm not being fair
[10:23:35 CET] <furq> i have a pi 2 here, i should probably actually try some of this shit
[10:23:44 CET] <gnarface> it's actually a really nice video player
[10:23:47 CET] <gnarface> it looks really good
[10:23:52 CET] <gnarface> i mean quality wise
[10:23:55 CET] <Nacht> it's the only valid one for RPi imho
[10:23:56 CET] <gnarface> it sounds good too
[10:23:59 CET] <gnarface> somehow
[10:24:01 CET] <Nacht> due to the hardware support
[10:24:14 CET] <furq> mpv has hwdec support for rpi
[10:24:31 CET] <furq> i might have mentioned it before
[10:24:37 CET] <Nacht> Does it play HLS ?
[10:24:46 CET] <furq> it plays more or less anything ffmpeg does
[10:25:04 CET] <Nacht> Oeh sweet, I'll have to look at that one then. As omxplayer borks on HLS
[10:25:08 CET] <furq> you'll need to build it yourself though
[10:25:13 CET] <furq> https://github.com/mpv-player/mpv/wiki/FAQ#Video_on_RPI_doesnt_work_or_is_too_slow
[10:25:39 CET] <gnarface> i really wish they would fix the framebuffer driver though so we could get accelerated X11
[10:25:42 CET] <gnarface> too*
[10:25:54 CET] <gnarface> i've given up on it
[10:25:55 CET] <Nacht> cheers furq, ill def have a look at that one
[10:25:59 CET] <gnarface> they'll finish the pinebook drivers first
[10:44:20 CET] <fps> durandal_1707: i should have qualified my statement: when i read the API docs.. i find them quite unpenetrable...
[10:45:03 CET] <JEEB> I remember when I first started working on an API client for the new decoding/encoding APIs I really liked this https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[10:45:19 CET] <JEEB> and generally I google "site:ffmpeg.org doxygen trunk KEYWORD" around
[10:48:22 CET] <JEEB> it's not all perfect, but /39
[10:59:58 CET] <StCyr> Hitechcg, Nacht, furq, gnarface: thanks for all your advices. I'll try the netcat+omxplayer solution for now as I prefer not to build softwares when packaged softwares solving my problems exist.
[11:03:44 CET] <gnarface> StCyr: well if you try the ffmpeg rebuild i'd be curious to know how well it works
[11:05:39 CET] <StCyr> gnarface: actually, I'm not sure I understood why I should rebuild ffmpeg... Is it because the build in raspbian doesn't support the raspeberry's hw accelaration?
[11:08:13 CET] <Hitechcg> StCyr: yes
[11:08:37 CET] <Hitechcg> well actually Raspbian builds have hardware encoding enabled but not decoding
[11:08:38 CET] <Hitechcg> idk why
[11:09:10 CET] <StCyr> ok, weird...
[11:09:50 CET] <StCyr> I guess I can download the deb-src to investigate the exact options
[11:11:10 CET] <gnarface> StCyr: yea there's a lot about raspbian that doesn't make sense
[11:11:23 CET] <StCyr> nice :-)
[11:12:07 CET] <Hitechcg> yeah, like hardcoding the swap file to exactly 100MB
[11:13:17 CET] <Hitechcg> their gstreamer does have all hardware decoders/encoders enabled now btw
[11:13:47 CET] <Hitechcg> so you could use gstreamer instead i guess, although this is not the right place for help with that
[11:15:45 CET] <StCyr> guys... so much alternatives... ffmpeg, gstreamer, vlc, omxplayer, mpv,... it'll drive me mad
[11:31:23 CET] <furq> raspbian doesn't customise their ffmpeg builds afaik
[11:31:30 CET] <furq> the standard debian package has omx enabled now
[11:32:51 CET] <furq> also gstreamer and vlc aren't really worth investigating too hard
[11:53:37 CET] <kerio> raspbian is weird
[12:06:28 CET] <aton`> hi, i am trying to dump a video from my webcam /dev/video0 in 1920x1080 with at least 20 fps on my disk. without hardware acceleration, the encoding is too slow. now i installed the h264_nvenc, but it wants a pixel format. now i got a mismatch between available pixel formats: http://dpaste.com/0XARBFV any way to get hardware accelerated encoding?
[12:07:29 CET] <aton`> i.e. webcam supports yuyv422 and mjpg, while h264_enc supports yuv420p nv12 p010le yuv444p yuv444p16le bgr0 rgb0 cuda
[12:16:39 CET] <aton`> ffmpeg -hwaccel cuvid -pixel_format yuv444p -f v4l2 -framerate 20 -video_size 1920x1080 -c:v h264_cuvid -i /dev/video0 -c:v h264_nvenc -f alsa -i plughw:CARD=Mic test.avi
[12:16:50 CET] <aton`> [video4linux2,v4l2 @ 0x145b0c0] Cannot find a proper format for codec 'h264' (id 28), pixel format 'yuv444p' (id 5)
[12:19:13 CET] <aton`> here with proper highlighting and on the demanded pastebin: https://pastebin.com/witQbXfu
[12:46:14 CET] <furq> aton`: neither of the formats in v4l2-ctl are h264
[12:47:22 CET] <furq> also that command isn't doing any hardware encoding
[12:47:48 CET] <furq> wait nvm
[12:47:59 CET] <furq> but yeah get rid of the cuvid stuff and -pixel_format yuv444p
[12:52:39 CET] <aton`> ffmpeg -f v4l2 -framerate 20 -video_size 1920x1080 -i /dev/video0 -f alsa -i plughw:CARD=Mic test.avi -y
[12:52:49 CET] <aton`> this gives me a video of desired quality, but 1-2 fps
[12:54:55 CET] <furq> you still need to use nvenc
[12:55:10 CET] <aton`> furq: the camera supports mjpeg and yuyv422
[12:55:26 CET] <furq> also don't use avi
[12:55:35 CET] <aton`> but when i get the compressed image as mjpeg, its shitty quality already
[12:55:43 CET] <aton`> ok so yuyv422 -> nvenc -> not avi
[12:55:48 CET] <furq> is this a usb2 camera
[12:56:01 CET] <furq> if it is then you'll have to use mjpeg or a lower resolution
[12:56:16 CET] <furq> usb2 isn't fast enough to keep up with 4:2:2 rawvideo at 20fps
[12:56:35 CET] <aton`> https://www.logitech.com/en-us/product/hd-pro-webcam-c920?crid=34
[12:57:09 CET] <furq> that conveniently doesn't mention whether it's usb2 or usb3
[12:57:40 CET] <aton`> Your Logitech Webcam C920 is fully supported with USB 3.0
[12:57:46 CET] <furq> ok good
[12:57:49 CET] <aton`> hm
[12:57:53 CET] <aton`> let me check something
[12:58:04 CET] <furq> well yeah if you've got it connected over usb3 then yuv to nvenc is fine
[13:00:31 CET] <aton`> ok i will try that, thanks for the help
[13:05:09 CET] <jkqxz> C920 is a USB 2 device (though of course it will work in a USB 3.0 port), you will need MJPEG or H.264 to get that resolution and framerate.
[13:05:50 CET] <aton`> http://support.logitech.com/en_us/article/28823
[13:06:13 CET] <aton`> how does it make sense that it supports yuyv422 at full hd and 30 fps then?
[13:06:21 CET] <aton`> if it cannot get that data out
[13:06:45 CET] <jkqxz> It gives you YUV 4:2:2 MJPEGs.
[13:12:30 CET] <furq> i'm not sure why v4l2-ctl isn't listing h264 there given that it should be supported
[13:12:56 CET] <furq> if you can get h264 out of it then you don't need to encode anything
[13:13:25 CET] <BtbN> you do not want to get h264 out of logitech webcams anyway
[13:13:32 CET] <BtbN> it's really terrible
[13:13:40 CET] <furq> it's probably better than mjpeg though
[13:13:52 CET] <BtbN> it's broken constrained baseline h264 with tons of artifacts due to being broken
[13:13:58 CET] <furq> oh fun
[13:13:59 CET] <BtbN> mjpeg is always better
[13:14:06 CET] <BtbN> At least on my C922 it is
[13:14:33 CET] <BtbN> On Windows they even disabled h264 output via driver update at some point
[13:15:12 CET] <furq> nice
[13:15:57 CET] <jkqxz> In my experience C922 and C925 give reasonably sensible H.264, but it does require some tuning because it's the crazy H.264-in-MJPEG-comments format.
[13:17:09 CET] <jkqxz> I don't think it's worth using on earlier cameras, and they've removed it on more recent ones like the BRIO.
[13:17:54 CET] <BtbN> They removed it from my C922 for sure
[13:17:58 CET] <BtbN> cause it used to have it, and now it's gone
[13:18:09 CET] <BtbN> And when I tested it, it was bad enough to warant that
[14:30:08 CET] <fps> ok, i'll build a minimal example to express my problem :)
[14:43:30 CET] <fps> maybe i'll ask before hand.. what does this message from avformat_write_header() tell me: "dimensions not set"
[14:44:11 CET] <fps> does it mean width and height? i did setup width and height for 1] the codec used and 2] as codecpars of the stream. (using ffmpeg 3.2)
[14:44:36 CET] <fps> oh, 3.4
[14:46:19 CET] <DHE> yes, it means width/height needs to be set on the AVFormatContext->codecpar->{width,height} fields
[14:46:39 CET] <DHE> whoops, missing the streams[] entry there
[14:47:30 CET] <fps> ok, what's the preferred paste site for this channel?
[14:48:28 CET] <DHE> no real preference. I would say ones without horrific advertising and that don't do weird javascript things
[14:49:31 CET] <fps> hm, i wouldn't see the ads anyways.. pastesite?
[14:49:55 CET] <fps> 2erm, pastebin.com?
[14:50:22 CET] <fps> https://pastebin.com/75q7mre5
[14:51:15 CET] <fps> this is ripped from a program to be a self contained example that compiles and shows the problem. i'm a complete ffmpeg noob, so there's probably things horribly wrong in there..
[14:51:57 CET] <fps> it must be something about the order of things or pre- or postconditions i'm oblivious to
[14:52:20 CET] <fps> it's line 158 that fails
[15:02:53 CET] <fps> i only go through all this because i used to follow an older example that set AVStream::codec to the AVCodecContext i created and filled with parameters.. with newer ffmpeg i get a deprecation warning and thought "hey let's look into this".. i still almost have no mental model of the ffmpeg API. it seems to be full of weird side effects and interdependencies :)
[15:22:00 CET] <DHE> fps: AVStream::codecpar should be a copy of the AVCodecContext::codecpar
[15:22:21 CET] <DHE> though it means you will need to initialize the encoder ahead of making the output format
[15:37:44 CET] <fps> DHE: thanks.
[15:37:51 CET] <fps> let's try this :)
[15:40:06 CET] <fps> ah, goddammit. at home i only have ffmpeg2.8. ;)
[15:40:11 CET] <fps> upgrading the system :)
[15:40:59 CET] <colekas> hello friends, I'm trying to use ffmpeg with decklink 4k pro card and I'm curious how I can get FFmpeg to use a specific input from the card (it has 4)
[16:33:43 CET] <Pierre__> Hello, I have found this command https://pastebin.com/KX9Zstxf to generate a live stream from a mp4 video.
[16:34:12 CET] <Pierre__> However, i'd like to do the same but for AUDIO only and I can't generate a MPEG Transport stream from audio files only (.aac) how can I do so?
[16:35:06 CET] <DHE> well that outputs to a network socket. how will you deliver this new audio-only stream?
[16:35:33 CET] <Pierre__> I have a HLS server running thanks to mediastreamsegmenter
[16:36:08 CET] <Pierre__> My original command works perfectly fine for a video file (mp4) but I can't why it doesn't work for a simple .aac file
[16:36:47 CET] <furq> remove -vcodec and -vbsf if your source has no video stream
[16:36:57 CET] <furq> also you spelled mpegts wrong in the command
[16:38:24 CET] <DHE> replace those two lines with "-vn" to request no video output instead
[16:38:40 CET] <furq> also i don't think hls supports audio only in mpegts
[16:38:49 CET] <furq> you have to use a segmented adts stream iirc
[16:39:57 CET] <Pierre__> Well audio-only files worked fine with mediafilesegmenter (vod)
[16:40:16 CET] <furq> i could be wrong there, i've never tried it
[16:40:26 CET] <Pierre__> and it generated sequence_.ts files
[16:40:31 CET] <Pierre__> Ok
[16:40:38 CET] <Pierre__> I am going to try furq solution
[16:41:28 CET] <furq> also it's probably worth pointing out that ffmpeg has an hls muxer
[16:41:43 CET] <furq> you could just use that directly instead of going via mediastreamsegmenter
[16:41:46 CET] <Pierre__> Really? Any doc on this?
[16:41:53 CET] <furq> !muxer hls @Pierre__
[16:41:53 CET] <nfobot> Pierre__: http://ffmpeg.org/ffmpeg-formats.html#hls-2
[16:44:50 CET] <Pierre__> Doesn't do anything with the -vn command ...
[16:44:55 CET] <Pierre__> I'm really confused
[17:12:00 CET] <aton`> https://wiki.matthiasbock.net/index.php/Logitech_C920,_streaming_H.264#hardware_decoded_video_playback
[17:12:16 CET] <aton`> they say ffmpeg has a bug there, while h264 works with cvlc
[17:15:39 CET] <Cyb3rn3t> hi All!
[17:17:25 CET] <Cyb3rn3t> so I started build ffmpeg with nvenc, and I used release 3.4 (latest cuda 9.1.3 patch and latest nvidia driver 390)
[17:17:56 CET] <Cyb3rn3t> and I realized that the h264_nvenc encoder speed is dramatically slow
[17:18:31 CET] <Cyb3rn3t> I can see that ffmpeg is using the GPU (on 25% load), but the encoding speed is about 1.1x speed
[17:18:54 CET] <Cyb3rn3t> older version is speed was about 4.5x (gpu on 40%)
[17:19:31 CET] <DHE> if you're using nvidia-settings to view encoding speed, it's not the GPU usage but the video engine utilization
[17:19:57 CET] <Cyb3rn3t> (the current master branch has some bug I guess, because I cannot build w --enable-nvenc option)
[17:20:47 CET] <Cyb3rn3t> @DHE, yes you're right
[17:30:20 CET] <Cyb3rn3t> nobody ?
[18:47:25 CET] <Zborg> if I am doing hardware accelerated video encoding and then start doing something else that uses gpu acceleration will the encoding quality be reduced or will it just go slower?
[18:47:51 CET] <DHE> nvenc is discrete from other GPU tasks. PCI bus saturation would be the main risk
[18:49:53 CET] <Zborg> in such a case will it go slower or will it drop frames/reduce quality
[18:50:08 CET] <Zborg> and what about ati/amd cards?
[18:51:55 CET] <atomnuker> same
[18:52:05 CET] <atomnuker> it won't reduce quality
[18:52:12 CET] <atomnuker> it won't drop frames either
[18:52:53 CET] <Zborg> that's good, I assume that something like running a gba/snes/psx game won't be much of a problem even if they are using opengl?
[19:23:01 CET] <kepstin> note that the hardware encoder on graphics cards is *designed* to be used in combination with running games - for e.g. livestreaming and whatnot.
[19:38:13 CET] <ChocolateArmpits> How come negative timestamps don't appear in my output file? Using debug_ts shows the muxer getting passed negative timestamps, however upon checking out the values in the output file the timestamps are all positive now
[19:41:19 CET] <cobrand> Hi guys, I've got a video with 1 video track and 6 audio tracks (not channels) which are supposed to represent a 5.1 (side) layout. I want to transform those 6 TRACKS in 1 TRACK of stereo. So far I've done '-filter_complex [0:a:0][0:a:1][0:a:2][0:a:3][0:a:4][0:a:5]amerge=inputs=6[aout]' (and then '-ac 2') and I think it's picking up correctly 5.1, but how do I tell it that I want 5.1(side) instead?
[19:43:05 CET] <kepstin> ChocolateArmpits: some output formats can't handle negative timestamps at all, so they'll adjust them to all be positive.
[19:43:21 CET] <ChocolateArmpits> kepstin, I'm using mkv, could that be the case?
[19:43:35 CET] <kepstin> I can't remember for mkv specifically :/
[19:44:21 CET] <ChocolateArmpits> mkv seems pretty beastly, hard to believe negative timestamps would be unsupported
[19:44:56 CET] <ChocolateArmpits> cobrand, use the 'join' filter instead of amerge. It has a channel layout parameter to tell how to arrange the input
[19:46:19 CET] <kepstin> ChocolateArmpits: the matroska muxer does not list AVFMT_TS_NEGATIVE in its capabilities, so I guess not
[19:46:32 CET] <kepstin> it probably just uses an unsigned field for ts or something in the format, i guess
[19:46:38 CET] <cobrand> ChocolateArmpits: I'll check it out, thank you
[19:47:46 CET] <ChocolateArmpits> even using mpegts the timestamps are ultimately corrected to positive in the muxer :/
[19:48:19 CET] <kepstin> yep, mpegts timestamps are an unsigned field
[19:48:25 CET] <kepstin> that's true in most formats
[19:48:40 CET] <kepstin> mov and related formats like mp4 are the main exception
[19:48:43 CET] <kepstin> and ogg, apparently
[19:51:10 CET] <ChocolateArmpits> even then mp4 and mov negative timestamps are off by 8 seconds!
[19:52:36 CET] <ChocolateArmpits> ok this is weird, mpv reports the neg timestamps correctly,
[19:52:44 CET] <ChocolateArmpits> for the file
[19:53:41 CET] <kepstin> note that by default ffmpeg will also "fixup" timestamps on input, which includes making them start at 0 iirc.
[19:54:52 CET] <FishPencil> Can FFmpeg detect a scene change and do something with it? I want to extract a specific scene from part of a video but don't want to find the exact enter/exit frame
[20:00:06 CET] <ChocolateArmpits> kepstin, ok despite the input showing wrong neg timestamps, setting "-seek_timestamps 1 -ss 0" produced the effect that I wanted, so there must be something strange with debug_ts not showing all the frames or something
[20:39:21 CET] <degenerate> hey guys, so i've got this video file: https://uccdn.bid13.com/original_videos/r/k/rkVyOWKPFAfJavjGcgDKtvxUtFpNcGlm2nWYU6bkB5O.mp4 and ...
[20:40:03 CET] <degenerate> ffprobe gives me:  1280x720 [SAR 40:33 DAR 640:297], 5104 kb/s, SAR 1551:1280 DAR 517:240, 30 fps
[20:40:26 CET] <degenerate> i want to get rid of this crazy sample aspect ratio and just have it to SAR 1
[20:40:42 CET] <degenerate> i tried doing: -vf scale=1551:720
[20:41:00 CET] <degenerate> but ffmpeg don't like that cause the odd heigh, it only works with -vf scale=1550:720
[20:41:10 CET] <degenerate> but if i do -vf scale=1550:720 i end up with SAR 1551:1550 :(
[20:41:29 CET] <DHE> most codecs don't like resolutions not a multiple of 2 (at least)
[20:42:07 CET] <degenerate> yeah, i understand that. thats fine. but how do i get this file to a SAR 1 then? can i pass a crop 1 px filter first?
[20:42:14 CET] <durandal_1707> -vf setsar=1
[20:42:26 CET] <degenerate> you gotta be kidding me
[20:42:29 CET] <degenerate> really? its that easy?
[20:42:33 CET] <degenerate> fml
[20:43:20 CET] <DHE> it just stomps on the old sample aspect ratio and forces it to 1:1
[20:43:22 CET] <durandal_1707> depends, what you really need....
[20:43:23 CET] <jkqxz> You should be able to do it without a reencode.  For H.264, "-c:v copy -bsf:v h264_metadata=sample_aspect_ratio=1".
[20:43:46 CET] <degenerate> @durandal_1707 no that does something wonky, that makes the video squished (aspect ratio gets screwed up)
[20:44:16 CET] <degenerate> jkqxz thanks i'll try that
[20:44:18 CET] <DHE> 1551:1550 isn't square but it's damned close. forcing it to 1:1 might make a row of black pixels on screen but not much more
[20:44:34 CET] <degenerate> ohhh force it to 1 after the scale.
[20:44:36 CET] <degenerate> ok that makes more sense
[20:45:11 CET] <degenerate> can i chain video filters? and they happen in order?
[20:45:23 CET] <jkqxz> (That answer is assuming you actually 1:1 pixels in the output, I didn't look at the video to see whether that's actually the right thing.)
[20:45:49 CET] <durandal_1707> degenerate: -vf scale=XXXX,setsar=1,hflip etc
[20:56:41 CET] <degenerate> thanks guys!
[21:05:07 CET] <martastain> Hi. Anyone using cuvid & nvenc on Quadro cards? The same encoding profile takes approx. twice as GPU memory on P5000 than on P2000.
[21:45:21 CET] <degenerate> guy's i'm stumped again, i've got this video: https://usercontent.bid13.com/1520455285-no-audio.mp4
[21:45:26 CET] <degenerate> and i'm trying to crop it with:
[21:45:49 CET] <degenerate> ffmpeg -i 1520455285-no-audio.mp4 -vf pad='ih*16/9:ih:(ow-iw)/2:(oh-ih)/2' temp.mp4
[21:46:06 CET] <degenerate> but i'm getting a weird error
[21:46:06 CET] <degenerate> Input area -136:0:1414:720 not within the padded area 0:0:1280:720 or zero-sized
[21:46:28 CET] <degenerate> Failed to configure input pad on Parsed_pad_0
[21:46:43 CET] <kepstin> your video is wider than 16/9, so you can't pad it to 16/9
[21:46:50 CET] <kepstin> you'll have to crop it instead
[21:46:54 CET] <degenerate> oh ok thanks
[21:47:31 CET] <kepstin> (or alternately, pad it vertically instead of horizontally - make it taller)
[21:48:01 CET] <kepstin> you can put conditionals into the pad command to handle both cases, but it'll start to look pretty ugly.
[21:48:19 CET] <kepstin> the command that is, the video result will look fine ;)
[22:09:02 CET] <pokui> Hi all, are there any options that help maintain as much fidelity if I have H265 in an MKV container and want H264 in an MP4 container? will just using -crf 18 (or similar) work or am I in for lots of experimentation?
[22:14:08 CET] <kepstin> pokui: just use -preset veryslow and adjust the -crf value until you don't notice a quality difference
[22:14:15 CET] <kepstin> that's really all there is to it
[22:14:23 CET] <pokui> thanks. I'll fiddle
[22:14:29 CET] <kepstin> (I mean, you could use a faster preset, but you'll get bigger files)
[22:15:03 CET] <kepstin> note that the same -crf value will give slightly different results when you change the -preset setting.
[22:21:28 CET] <pokui> kepstin: thanks for the tip.
[22:21:40 CET] <pgorley> hi, is there a way to know what codecs a given hwaccel supports? or is the solution just to try it to see if it succeeds or fails?
[22:22:37 CET] <kepstin> hmm, hwaccel codec support is fun, because it can vary depending on the hardware that's installed and stuff like driver versions :/
[22:23:21 CET] <atomnuker> pgorley: the other way around, you can get the AVCodec and check out what's in ->hw_config
[22:24:25 CET] <atomnuker> There's a newer API to init hwaccels, not sure whether it can check as well
[22:28:11 CET] <pgorley> so i would call avcodec_get_hw_config with my AVCodec and see what's there instead of blindly opening the codec and hoping for the best
[22:29:49 CET] <pgorley> atomnuker: thanks, i'll test that out :)
[22:30:11 CET] <pgorley> and yea, i'm already using that new api, so much cleaner than before
[22:30:43 CET] <atomnuker> better ask jkqxz, he should know the proper way
[22:33:21 CET] <pgorley> i'll test it out on my side and ask more questions if i have any
[23:02:09 CET] <lorenz> I have a series of tiff images and a time difference between each frame, I want to make an mp4 file. I've never done variable frame rates like this, is it possible?
[23:02:23 CET] <JEEB> yes
[23:02:38 CET] <JEEB> not sure if possible with ffmpeg.c
[23:02:46 CET] <JEEB> but the API lets you set the PTS
[23:02:55 CET] <lorenz> that's ok
[23:03:31 CET] <lorenz> is there an mp4 encoder from images example in C that I can work from?
[23:03:49 CET] <JEEB> there are various examples under doc/examples
[23:04:14 CET] <JEEB> I think it was the transcode example?
[23:04:23 CET] <lorenz> ok thanks
[23:06:50 CET] <GamleGaz> is it possible to mux frames out of order, if their pts is set to the correct frame index?
[23:07:20 CET] <JEEB> as long as the dts keeps going up, and the PTS is correct
[23:08:03 CET] <JEEB> so you give them to the muxer in coded order as received from an encoder, but of course they can have PTS in various order :P which is normal with b-frames in H.264 for example
[23:08:32 CET] <JEEB> generally the encoders handle that right in libavcodec, and what you need to care about is to have the correct PTS values set in the input
[23:11:07 CET] <GamleGaz> alright, thanks :)
[00:00:00 CET] --- Thu Mar  8 2018