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

[burek]

[00:55:52 CEST] <RossW> Anyone up for a challenge with ffmpeg? I'm creating a video from static jpeg images on 4 input streams, so the resulting video is basically a "quad".
[00:57:07 CEST] <RossW> My issue is that the input files come from 4 to 8 different directories, depending on which inputs are required... so each input "channel" may need to select images from one, the other, or both if its directories.
[00:57:35 CEST] <RossW> It would be wonderful if there was a magic way to make ffmpeg take inputs for each channel from a file....
[00:58:24 CEST] <RossW> Part of the command line goes:
[00:58:43 CEST] <RossW>                 /usr/local/bin/ffmpeg -hide_banner \
[00:58:49 CEST] <RossW>                         -start_number $sn1 -i $picsdir/$c1/%d.jpg -r $fps \
[00:58:53 CEST] <RossW>                         -start_number $sn2 -i $picsdir/$c2/%d.jpg -r $fps \
[00:58:59 CEST] <RossW>                         -start_number $sn3 -i $picsdir/$c3/%d.jpg -r $fps \
[00:59:07 CEST] <RossW>                         -start_number $sn4 -i $picsdir/$c4/%d.jpg -r $fps \
[00:59:54 CEST] <RossW> ... but the problem is when input stream 1 (picsdir/$c1/) needs to ALSO come from a different directory
[01:01:10 CEST] <RossW> The entire command is quite complex because it adds subtitles, overlayed text, logo and other feature-specific images that relate to the input streams.
[01:56:45 CEST] <poutine> I'm streaming via RTP with FEC via ffmpeg w/ prompeg and it works great, let's say from 6 hour mpegts files w/ AVC/h264 streams in them, the problem we have is those 6 hour mpegts files are dynamically created, and our current way of switching (turning off ffmpeg and restarting) is causing monitoring software issues, and admittedly seems like the wrong way to do things
[01:56:58 CEST] <poutine> is there a right way of doing this seamlessly that can be achieved using ffmpeg/OSS world?
[01:57:57 CEST] <JEEB> I would just recommend making your own API client instead of utilizing ffmpeg.c, if that's what you're using
[01:58:19 CEST] <JEEB> ffmpeg.c is really static and made for specific use cases
[01:58:29 CEST] <JEEB> it really isn't built for partial re-initializations etc
[01:58:38 CEST] <poutine> JEEB, I'm not working that low level, I'm just using the command line, was hoping there was something I could pipe the ffmpegs into and it works out the stream to be sent so there's no seams
[01:59:20 CEST] <JEEB> well in theory you could feed it stuff from a pipe and set -rw_timeout XXX -follow 1
[01:59:28 CEST] <JEEB> not sure how well it would work
[01:59:47 CEST] <JEEB> but on the long run, I will bet you will hit a limit where ffmpeg.c will no longer cut it
[02:00:03 CEST] <JEEB> as in, the FFmpeg APIs could do it, but ffmpeg.c is just not meant for that use case
[02:00:44 CEST] <poutine> you're probably right, I'll check out the pipe w/ options and see what's actually going on there
[02:01:06 CEST] <JEEB> at least with files rw_timeout and follow means that libavformat will keep reading
[02:01:12 CEST] <JEEB> until it hitts that rw_timeout
[02:01:19 CEST] <JEEB> so it works with growing files, f.ex.
[02:02:18 CEST] <JEEB> but yea, I've seen plenty of examples where people start doing things with ffmpeg.c, and then at some point it no longer can facilitate what's needed. and the best hacks are when some people then start hacking stuff in the libraries just not to touch the client code... even though it's the wrong place
[02:02:40 CEST] <JEEB> even something as simple as switching streams
[02:02:53 CEST] <JEEB> libavformat has dynamically adding streams
[02:03:23 CEST] <JEEB> and while not nice, it does let you figure out what streams to pick from MPEG-TS f.ex. at a given time
[02:03:38 CEST] <JEEB> (I have had some ideas on how to improve this)
[02:10:09 CEST] <poutine> JEEB, Have you heard of tsduck or multicat being used at all in this capacity?
[02:10:40 CEST] <poutine> I wonder if I can get away with using ffmpeg to RTP/FEC stream the output of it pieced together elsewhere through pipes
[02:22:08 CEST] <giaco> what is this? RTP: dropping old packet received too late. It happens on ffplay and mplayer when the source stops and restarts
[04:15:26 CEST] <Lunchbox> hey
[04:17:31 CEST] <Lunchbox> is the deblock filter not supported when encoding using nvenc?
[04:21:13 CEST] <kepstin> Lunchbox: it should work fine, but depending on what you're doing you might have to use the 'hwdownload' or 'hwupload' filters to transfer the frames between gpu ram and system ram (since most ffmpeg filters run on the cpu)
[04:23:34 CEST] <Lunchbox> the error i'm getting is
[04:23:39 CEST] <Lunchbox> no such filter: 'deblock'
[04:24:06 CEST] <Lunchbox> does hwdownload and hwupload go inside the vf params?
[04:44:56 CEST] <kepstin> oh, there is no filter just named 'deblock'
[04:45:27 CEST] <kepstin> maybe read through https://www.ffmpeg.org/ffmpeg-filters.html to find a filter that does what you want
[04:46:09 CEST] <kepstin> the 'pp' filter can do deblocking for example
[04:46:31 CEST] <Lunchbox> that's what i was using for reference
[04:46:35 CEST] <Lunchbox> https://www.ffmpeg.org/ffmpeg-filters.html#deblock
[04:46:50 CEST] <Lunchbox> i had specific values in mind but using the first example provided doesn't work
[04:46:59 CEST] <Lunchbox> deblock=filter=weak:block=4
[04:47:50 CEST] <kepstin> oh, huh, that filter is really recent
[04:47:59 CEST] <kepstin> you probably don't have a new enough ffmpeg to use it
[04:48:23 CEST] <Lunchbox> shoot
[04:48:25 CEST] <Lunchbox> lol
[04:48:29 CEST] <kepstin> in fact, that must be a post-4.0 addition
[04:52:30 CEST] Action: kepstin checks, and confirms that you'd need an ffmpeg master build from after april 21 to use that filter.
[04:53:27 CEST] <kepstin> the web page filter docs are built from git master, so they're often ahead of the ffmpeg version people have on their systems. you can reference the 'ffmpeg -fitlers' output and 'man ffmpeg-filters' to see what your local ffmpeg supports.
[04:53:43 CEST] <kepstin> except spell -filters correctly
[04:54:10 CEST] <Lunchbox> man i just downloaded 4.0 and saw it still didn't work haha
[04:54:19 CEST] <Lunchbox> i'll try to find that build specifically
[04:54:27 CEST] <Lunchbox> thanks
[04:55:43 CEST] <kepstin> well, you want the latest nightly build
[04:57:10 CEST] <Lunchbox> ya just grabbed it
[04:57:12 CEST] <Lunchbox> it works!
[04:57:17 CEST] <Lunchbox> appreciate the help
[05:15:27 CEST] <Lunchbox> would you happen to know how to achieve results similar to using negative deblock values using these specific parameters?
[05:18:59 CEST] <Lunchbox> the gui i was using before allowed for negative values which would actually increase block visibility
[05:35:27 CEST] <furq> Lunchbox: are you sure it wasn't just setting -deblock
[05:39:18 CEST] <Lunchbox> yes
[05:41:33 CEST] <Lunchbox> negative values are like going backwards from the default deblock values towards no-deblock
[05:41:45 CEST] <Lunchbox> example being tune grain
[05:41:47 CEST] <Lunchbox> https://superuser.com/questions/564402/explanation-of-x264-tune#answer-564404
[05:42:01 CEST] <furq> yeah that's -deblock
[05:42:58 CEST] <furq> that's mapped to --deblock in x264, i assume nvenc has it mapped as well
[05:43:35 CEST] <Lunchbox> oh sick
[05:44:26 CEST] <Lunchbox> not sure how to achieve similar results with ffmpeg
[05:44:39 CEST] <furq> just -deblock -1:-1
[05:45:09 CEST] <Lunchbox> oh wow
[05:45:37 CEST] <Lunchbox> i assumed it had to use the new parameters since it wasn't working before but my ffmpeg version was just too old
[05:48:33 CEST] <Lunchbox> doesn't appear to actually do anything after encoding
[05:50:25 CEST] <furq> shrug
[05:50:33 CEST] <furq> it works for x264, i have no idea about nvenc
[05:51:00 CEST] <Lunchbox> i'll play around with the new options
[05:51:18 CEST] <Lunchbox> hopefully it's possible i just don't understand what each value does yet
[05:51:24 CEST] <Lunchbox> some don't have descriptions
[09:47:11 CEST] <gloomy> Hi :) This is rather off-topic but I don't know where to ask. I have a lot of old DV tapes with family movie and want to digitalise them. The camera is connected to my computer by firewire. Any Idea what kind of software I can use to capture the video stream? Ideally command-line, so that I can pipe the output into ffmpeg and compress it on the fly (I have limited hard drive space and I read DV is around 13Gb/hour)
[09:53:34 CEST] <furq> !indev iec61883 @gloomy
[09:53:34 CEST] <nfobot> gloomy: http://ffmpeg.org/ffmpeg-devices.html#iec61883
[09:53:36 CEST] <furq> maybe that
[09:54:21 CEST] <furq> apparently debian ffmpeg has it as standard so you might be lucky and not have to rebuild
[09:55:11 CEST] <gloomy> I'm on macos which makes it extra complicated as it goes through a thunderbolt adapter, but thanks, I'll start there :)
[10:32:32 CEST] <EJoker> I want to share the tutorial which I have created for FFmpeg 3.4 using latest Android NDK r16b, so that people can compile FFmpeg for android app development.
[10:32:42 CEST] <EJoker> How can it be done?
[10:35:52 CEST] <JEEB> I don't think FFmpeg building for NDK needs anything special
[10:36:09 CEST] <JEEB> also there's a FATE instance doing the cross-compile already
[10:36:24 CEST] <JEEB> but sure, a wiki article on trac is probably the most realistic
[10:36:47 CEST] <JEEB> just make sure you're not using any android specific makefiles etc since those are *not* required
[10:37:13 CEST] <JEEB> http://fate.ffmpeg.org/report.cgi?slot=armv7a-android-gcc-4.4-shared&time=20180503225318
[10:37:19 CEST] <JEEB> this is a darn old thing of course
[11:39:19 CEST] <gloomy> Is it a bad idea/are there any contraindications to installing ffmpeg with /all/ the options?
[11:39:46 CEST] <gloomy> I've been using ffmpeg for two months and I already had to recompile 4 times because of an extra feature I needed
[11:52:29 CEST] <furq> it's not really possible
[11:52:43 CEST] <furq> a lot of libs are platform-specific
[11:53:06 CEST] <furq> and also a lot of them do the same thing
[11:53:31 CEST] <furq> gnutls/openssl/libtls/schannel/securetransport being an obvious example of both of those
[11:59:38 CEST] <gloomy> So any suggestion on how to get the most complete install possible for my platform (macos)?
[12:00:22 CEST] <gloomy> I've been trying to install with libiec61883 as you pointed me to but from what I understand it's a linux library
[12:05:55 CEST] <furq> if libiec61883 is linux only then there's probably no way to do it with ffmpeg on osx
[12:06:50 CEST] <furq> oh
[12:07:05 CEST] <furq> https://www.ffmpeg.org/ffmpeg-devices.html#avfoundation
[12:07:06 CEST] <furq> maybe that?
[13:34:47 CEST] <gloomy> I've been trying for two hours now but I can't get it to recognize the camera. I'll just import it with imovie and do the processing after...
[13:41:58 CEST] <gloomy> It's the first time I do this, so I need some suggestions: I have raw DV files that take a huge amount of space despite very low quality (it's converted from an old analog camera, so, grainy  720x576 video). I want to convert them to a more reasonable size before doing some editing/trying to improve the quality a bit. Is it fine to use a modern lossy encoding like hevc or x264?
[13:43:10 CEST] <gloomy> I know it's generally better to do the editing on the raw files, but I have over 800GB of them and I don't even have the necessary storage to keep them on my laptop while I do editing
[13:43:39 CEST] <gloomy> Or are there good lossless compression schemes that would be better in this case?
[13:45:14 CEST] <furq> dv is lossy, so anything lossless is probably going to turn out larger
[13:46:11 CEST] <furq> if it was me i'd keep the originals and throw them on some cloud storage
[13:47:40 CEST] <furq> on the plus side it's pal dv which means it's 4:2:0 and not 4:1:1
[13:55:12 CEST] <gloomy> But how is the editing experience with such huge files? I can't imagine the amount of ram needed for even short sequences of film
[13:55:48 CEST] <gloomy> (I mean, with a GUI editing software like iMovie or final cut)
[13:55:52 CEST] <Blacker47> gloomy, there is no editing software that tries to put whole video to ram.
[13:56:25 CEST] <furq> you need to decode video to edit it anyway
[13:56:32 CEST] <furq> so it doesn't really make much difference
[13:57:20 CEST] <gloomy> ah, yes, seems legit
[14:02:27 CEST] <gloomy> Alright, I'll get a new hard drive and do the editing from there. Hope iMovie was optimised for that.
[14:09:05 CEST] <furq> also i'm pretty sure DV is a bit smaller than 13GB/hour
[14:09:13 CEST] <furq> probably closer to 10
[14:09:23 CEST] <furq> which is still not great but it's not too bad
[14:11:50 CEST] <Blacker47> furq, no it something on 13 GB/h.
[14:16:40 CEST] <Blacker47> 13,7 GB/h if used with 16-bit audio.
[14:16:56 CEST] <furq> fair enough
[16:54:02 CEST] <YourBuddy> hey guys
[16:54:05 CEST] <YourBuddy> any1 up?
[16:57:27 CEST] <YourBuddy> need help with a subs hardcoded/hidden inside a media file
[18:13:02 CEST] <Trel> Can ffplay be used to output video directly to the video buffer on a machine without X running?
[18:14:12 CEST] <Trel> *framebuffer
[18:20:09 CEST] <JEEB> you might want to look into what drm etc outputs in mpv can do?
[18:20:19 CEST] <JEEB> ffplay is just a PoC thing
[18:21:47 CEST] <Trel> Ah, then I'm thinking probably mplayer or vlc would be the best option for my use.  I'm not opposed to X but it's going on a RPi for the sole purpose of playing a video stream, so I was looking for the lightest possible option.  I've used ffplay to test video so I figured it couldn't hurt to check.
[18:22:07 CEST] <Trel> (I'm 99% sure mplayer can output to framebuffer)
[18:22:21 CEST] <klaxa> framebuffer is not really "light" though
[18:22:24 CEST] <JEEB> mpv is basically 2nd gen fork of mplayer
[18:22:40 CEST] <JEEB> and if you have DRM support you probably want DRM instead of fb
[18:22:47 CEST] <JEEB> since you can do HW rendering there
[18:23:05 CEST] <Trel> DRM as in digital rights, or direct rendering?
[18:23:11 CEST] <JEEB> the latter
[18:23:37 CEST] <JEEB> there seem to be two guys rather actively working on the opengl DRM back-end in mpv
[18:23:59 CEST] <Trel> I'll check that out once we get the Pi then.  I think we're ordering today.
[18:24:30 CEST] <Trel> Thanks
[18:24:44 CEST] <furq> i'm pretty sure mpv can output to fb on an rpi
[18:28:55 CEST] <Trel> Hopefully it gets ordered with Prime so I can do it sooner rather than later.  Most annoying part of the pi is swapping dhcpcd for network manager.  That's the part I hate.
[20:17:28 CEST] <wfbarksdale> why is the timebase for streams an AVRational, in what case would the numerator not be 1? Presumably this only applies to non ISOBMFF files?
[20:51:15 CEST] <kepstin> wfbarksdale: for ntsc video, the natural timebase is something like 1001/30000.
[20:52:23 CEST] <kepstin> various file formats support different timebase representations of course, or sometimes even have fixed timebases.
[20:54:55 CEST] <wfbarksdale> keptin: i see, so pts for NTSC would be 1, 2, 3... instead of 1001, 2002, 3003?
[20:55:58 CEST] <kepstin> usually it's nice to chose a timebase so the frame numbers are simple incrementing integers, yeah.
[20:56:19 CEST] <kepstin> ffmpeg doesn't require that, of course.
[20:59:35 CEST] <kepstin> the 'fps' filter, for example, works by setting the output timebase to the inverse of the requested framerate, then converts the input video to that timebase, dropping/duplicating frames so the result has nice incrementing pts values.
[21:00:25 CEST] <wfbarksdale> i'm working on some c++ abstractions backed by an ffmpeg implementation, and would prefer to represent time as a simple rational
[21:03:33 CEST] <kepstin> that can't be done in general, unless you're ok with having to round some oddball timestamp values (making them non-exact). Facebook wanted to do that, and they ended up picking a really oddball timebase that's just the gcd of a bunch of common rates.
[21:03:38 CEST] <kepstin> https://github.com/OculusVR/Flicks if you're curious.
[21:04:02 CEST] <wfbarksdale> and unfortunately std::chrono needs the "time base" part to be known at compile time. So it is sort of looking like I have to make my own little c++ library to handle the math
[21:04:48 CEST] <kepstin> wfbarksdale: if that's what you want, maybe try that facebook library. It's pretty much that little c++ lib that you'd have to write.
[21:06:22 CEST] <wfbarksdale> ahh, cool! will definitely look at this, thanks!
[21:07:03 CEST] <kepstin> but keep in mind that it doesn't quite match how a lot of video software really works, so you're gonna have to do time conversions anytime you're moving stuff into or out of that format
[21:11:19 CEST] <kepstin> note that ffmpeg internally uses a time base of 1/1000000 (microseconds) in a lot of places where it has to deal with external clocks or sometimes when combining stuff with mismatched timebases.
[22:25:42 CEST] <Derisar> How can I transform a video file to make it minus heavy on the GPU resources? (possibly without reducing resolution)
[22:26:36 CEST] <c_14> you decrease the resolution
[22:26:41 CEST] <c_14> all other processing is usually done on the cpu
[22:27:26 CEST] <Derisar> c_14 but I heard that also changing the codec can help
[22:28:35 CEST] Action: drathir wonder if its planned support for: "Decoder (codec dvb_teletext) not found for input stream #0:3" and stream report as "Subtitle: dvb_teletext "
[22:29:26 CEST] <kepstin> Derisar: changing the codec might change gpu resources if you're doing hardware decoding on the gpu, but note that most gpus do hardware decoding with dedicated hardware, so it doesn't really reduce available resources to other apps.
[22:30:08 CEST] <drathir> Derisar: isnt it designed to not be heavy at gpu with hw acceleration in decoding?
[22:30:24 CEST] <Derisar> kepstin, yes I'm doing hardware decoding
[22:31:06 CEST] <Derisar> drathir I suppose that it depends on the codec
[22:31:11 CEST] <drathir> Derisar: You can at least change profile used for decode but it in theory should incerase file size...
[22:31:59 CEST] <Derisar> drathir also a friend tell me about that but it's a film with various special effects, explosions and such
[22:32:13 CEST] <drathir> dantti: i dont think so, bc its hw acceleration, only profile i guess could get any difference in gpu load exclude resolution ofc...
[22:32:36 CEST] <Derisar> So he telled me that explosions cannot be compressed much because they're entropy
[22:32:41 CEST] <kepstin> Derisar: what's the actual problem that you're having? If it's using hardware decoding, then the only time you should be worrying about resources is if it's not being realtime
[22:33:20 CEST] <Derisar> kepstin, i'm using mpv and audio/video goes in desync
[22:33:29 CEST] <drathir> Derisar: any modern gpu should almost sleep with load on gpu even with high profiles...
[22:33:46 CEST] <Derisar> drathir, my gpu is shit
[22:34:05 CEST] <kepstin> Derisar: then either it's not using the hardware decoder, or the player is doing post-processing that your system can't handle.
[22:34:28 CEST] <Derisar> kepstin, I've set it to do hardware decoding
[22:34:31 CEST] <kepstin> if your gpu is too old, it's possible that the video is in a codec that the hardware doesn't support.
[22:35:16 CEST] <drathir> Derisar: yea searched too in past solutions, but only what i found upgrade gpu was to some decent even weaks ones models...
[22:35:25 CEST] <kepstin> Derisar: it would be helpful to know more about the video format and codecs and system hardware details.
[22:36:25 CEST] <drathir> Derisar: atm im at old radeon which deal fine with avc x264, but after ome changes they disabled x265 decoding on it...
[22:36:25 CEST] <sfan5> make a log file using --log-file=mpv.log and pastebin that, it provides all info kepstin asks for
[22:37:16 CEST] <drathir> Derisar: also check few settings with mpv to tweak hw decoding...
[22:38:30 CEST] <drathir> Derisar: yep it could using hw decoding but movie profile is too high for buildin decoder...
[22:40:40 CEST] <drathir> Derisar: check also xv vs opengl --vo ==hwdec for vaaapi and vdpau...
[22:41:44 CEST] <drathir> vainfo/vdpauinfo/xvinfo if no errors...
[22:42:28 CEST] <drathir> Derisar: i dont think so You get older than r600 ;p
[22:46:05 CEST] <Derisar> https://paste.debian.net/hidden/5fc0775a/
[22:46:16 CEST] <Derisar> drathir, kepstin here's the paste
[22:48:33 CEST] <drathir> Derisar: check vainfo/vdpauinfo
[22:48:59 CEST] <Derisar> drathir, how?
[22:49:26 CEST] <drathir> Derisar: You for sure get better performance with 1080p x264...
[22:49:51 CEST] <drathir> Derisar: that should be command builidin in drivers tools...
[22:50:26 CEST] <drathir> Derisar: one in mesa second in nouveau if good remember...
[22:53:11 CEST] <kepstin> Derisar: yep, the video is hevc codec, and your gpu (amd kabini) doesn't support hevc.
[22:53:27 CEST] <Derisar> Wut
[22:53:58 CEST] <drathir> Derisar: vainfo from command line any output?
[22:54:10 CEST] <Derisar> drathir, what do you mean? Command buildin in driver tools?
[22:54:35 CEST] <Derisar> kepstin, so I should reencode it in yuv420p?
[22:54:58 CEST] <Derisar> drathir, I will try
[22:55:23 CEST] <kepstin> Derisar: it's already yuv420p. You want to re-encode it to h264 codec
[22:55:24 CEST] <drathir> Derisar: reencode to x264 it should be smothly but higher size...
[22:55:40 CEST] <drathir> Derisar: which os?
[22:55:51 CEST] <Derisar> drathir, debian linux
[22:56:10 CEST] <Derisar> kepstin, isn't it hevc?
[22:56:29 CEST] <kepstin> Derisar: it's hevc right now, but your gpu doesn't support hardware decoding hevc
[22:56:33 CEST] <drathir> Derisar: apt-get install vainfo
[22:56:57 CEST] <Derisar> drathir, I was installing it before thanks
[22:57:44 CEST] <drathir> Derisar: hevc is  x265 one based...
[22:58:13 CEST] <drathir> Derisar: now output from console vainfo to some pate service...
[22:58:19 CEST] <Derisar> https://paste.debian.net/hidden/9d484ce4/
[22:58:58 CEST] <kepstin> exactly as I expected the kaveri apu has uvd4, which supports h264 and mpeg2 and vc1 (and maybe xvid/divx, but not on linux)
[22:59:39 CEST] <drathir> Derisar: interesting that mpv reporting hw decoding if there no profile for it...
[23:00:05 CEST] <kepstin> Derisar: to repeat what we've been telling you: transcode the file to h264 (using e.g. the x264 encoder), then your gpu will be able to hardware decode it, and it should play back smoothly.
[23:00:14 CEST] <Derisar> drathir, I've set it to auto
[23:00:28 CEST] <Derisar> kepstin, command option?
[23:00:31 CEST] <drathir> kepstin: honestly thats sounds sad that 10 y.o mb gpu get similar set ;/
[23:00:33 CEST] <Derisar> *options
[23:01:06 CEST] <drathir> Derisar: also auto in mpv mostly not working as excepted ;p
[23:01:49 CEST] <Derisar> drathir, then what should I put in hvdec?
[23:02:10 CEST] <Derisar> s/hvdec=auto/????
[23:02:19 CEST] <drathir> Derisar: mpv --hwdec=vaapi  path_to_file
[23:02:52 CEST] <kepstin> hmm? looks like auto is working as expected.. it tries to hardware decode the file, fails because the hardware can't decode it, then falls back to software decode (which is too slow on this underpowered apu)
[23:03:17 CEST] <drathir> should get something like:
[23:03:19 CEST] <drathir> Using hardware decoding (vaapi).
[23:03:19 CEST] <drathir> VO: [vaapi] 640x360 vaapi[nv12]
[23:03:45 CEST] <Derisar> Wait
[23:03:47 CEST] <kepstin> well, no it won't, because the hardware doesn't support hevc...
[23:03:58 CEST] <Derisar> So that's why that HD video was running smoothly
[23:04:11 CEST] <Derisar> Video: h264 (Main)
[23:04:19 CEST] <kepstin> video in h264 should work fine with the hardware decoder, yes
[23:04:21 CEST] <sfan5> note that vo=vaapi is different hwdec=vaapi
[23:04:43 CEST] <sfan5> vo=vaapi is not required for hwdec, but can improve performance on low-end hardware
[23:05:27 CEST] <drathir> Derisar: but im pretty sure as kepstin say for me stopped work with h265 when they take back/delete HEVC_MAIN  from output list...
[23:06:14 CEST] <drathir> when was present up to 720p was handled on gpu higher get green screen/artefacts...
[23:07:11 CEST] <Derisar> drathir, so that's why vlc when playing some videos with VDPAU gets green artifacts
[23:07:38 CEST] <drathir> sfan5: correct on modern better should give --vo=opengl...
[23:08:03 CEST] <sfan5> you mean vo=gpu, you can just just omit that anyway since it's the default
[23:09:05 CEST] <drathir> sfan5: there was in past too opengl-hq if good remember that one killed performance drastically on old devices...
[23:09:30 CEST] <sfan5> yes that's called profile=gpu-hq now
[23:09:57 CEST] <drathir> nice to know opengl is now default one...
[23:11:21 CEST] Action: drathir need play again with settings in free time maybe some new tricks get found which incerase performance at old devices... ;p who knows...
[23:12:48 CEST] <kepstin> Derisar: anyways, if you want to transcode that video to h264 so you can play it, a command like   "ffmpeg -i original.mkv -map 0 -c copy -c:v libx264 h264copy.mkv" should do the trick. It'll take a while since it's doing the video transcode on the cpu, of course, but the result should be playable.
[23:13:57 CEST] <drathir> and hopefully no big hit in quality too...
[23:15:20 CEST] <kepstin> that'll use crf 23 by default, i think, which some people might find a little low. Should probably be good enough tho. Depends on the source.
[23:15:56 CEST] Action: drathir wonder if there are present devices which support hw acceleration of encode x265?
[23:16:19 CEST] <drathir> with ffmpeg ofc...
[23:16:54 CEST] <kepstin> drathir: yes, most current model nvidia cards, at least some recent intel gpus, and amd rx 300 and later series.
[23:17:41 CEST] <kepstin> iirc amd vega and nvidia 10xx stuff can do vp9 now, too
[23:18:40 CEST] <kepstin> oh wait, you said encode
[23:18:43 CEST] <kepstin> i was thinking decode
[23:19:11 CEST] <drathir> kepstin: oh was surpriised, bc yea mostly is listed decode, but not saw encode yet...
[23:20:15 CEST] <kepstin> hevc encode should work on a decent selection of recent nvidia stuff at least, but probably only when using the proprietary driver
[23:22:41 CEST] <drathir> and probably will shoot into some low profile gtx 10xx ones, bc still should support all pcie ports i guess... and just wait for nouveau support for it...
[23:23:00 CEST] <kepstin> note that the gt 1030 doesn't have any hardware encoder at all.
[23:24:31 CEST] <kepstin> recent amd stuff is supposed to support hardware hevc encoding, but I have no experience with getting that to work in linux (and their h264 encoder wasn't all that good, so I wouldn't expect great results with hevc either)
[23:24:33 CEST] <drathir> kepstin: woow really O.o - noted that crazy indeed...
[23:25:41 CEST] <kepstin> looks like you should be able to 8-bit hevc with intel skylake and 10-bit with intel kaby/coffee lake
[23:26:10 CEST] <kepstin> i dunno how well that's supported in linux, i don't have any intel chips that new :)
[23:26:27 CEST] <drathir> kepstin: more pricey soolution would be just change mb to intel i5/i7 line, but that higher costs, bc all hw need to be replaced... ;p
[23:26:55 CEST] <jkqxz> H.265 encoding does work on my Polaris card, but the card locks up completely (requiring reboot) in some unclear cases if you do much else with it at the same time so I wouldn't say it's production-ready yet.
[23:27:00 CEST] <kepstin> if you were gonna replace all the hardware, i'd just go for a big multicore cpu so you could do software encoding :)
[23:27:38 CEST] <kepstin> oh, huh, my office pc is actually skylake. Maybe I should try the hevc encoder just to see what's up.
[23:28:21 CEST] <jkqxz> Intel does work fine (and stably), but it's not really any better than than H.264 encoder.
[23:29:01 CEST] <drathir> kepstin: i was play with intel gpu a little on customer devices, and suprise works not bad as i thought... exclude intel driver mistakes broke gpu at all from working ;p but just that not so often still ;p
[23:29:24 CEST] <jkqxz> (Though consequently it's not significantly slower either, so it might be nice for things which need H.265.)
[23:31:36 CEST] <drathir> jkqxz: i saw that nvidia ones gt 740m gets too hangsup with paused video probably buffer overload or something similar randomly too...
[23:33:11 CEST] <kepstin> the gt 740m is an annoying model, because there were two versions - one using gk107, one using gk208, and iirc the gk208 version doesn't have a hardware encoder, but the gk107 does.
[23:33:43 CEST] <kepstin> (there's a few other 7xx models with that problem too)
[23:33:46 CEST] <drathir> kepstin: yea with new hw no big deal mostly at cpu handle encoding, but more wondered if there present some nice solution for hw encode (even if its not louf about them ;p)...
[23:33:55 CEST] <drathir> louf/loud*
[23:34:34 CEST] <kepstin> hardware encoders are designed to solve a particular problem: encode video at realtime or faster speeds without using cpu.
[23:34:56 CEST] <drathir> jkqxz: and yea if not crash every start good takes of xx% from cpu load...
[23:35:02 CEST] <kepstin> as a result, they are almost always lower quality than a software encoder could do at the same bitrate.
[23:37:47 CEST] <drathir> kepstin: but would be nice using eg. gpu/cuda for encode calculations too... that in theory should be still multiple times faster in processing data than cpus in theory ofc...
[23:41:26 CEST] <drathir> kepstin: at least them enough cpu smoothly pplay x265 1080p
[23:41:53 CEST] <drathir> kepstin: them mean gt7440m notebooks cpus...
[23:46:07 CEST] <Derisar> kepstin, I used ffmpeg .i original.mkv -c:v libx264 -crf 18 -preset slow -c:a copy h264copy.mkv is it nearly the same?
[23:49:31 CEST] <kepstin> Derisar: your command will be a little slower (the default is -preset medium) and higher quality (because -crf 18 is better than the default)
[23:49:57 CEST] <kepstin> Derisar: since you didn't include "-map 0", if the input has multiple audio or subtitle tracks, they won't all be copied to the output.
[23:50:21 CEST] <drathir> btw its interesting some sources from x264 to x265 gets huge difference in size close to 50% less filesize and other gets less than 10% lower size or sometimes even bigger than source ;p
[23:50:45 CEST] <kepstin> drathir: size has nothing to do with anything
[23:50:59 CEST] <kepstin> I can make an x264 file that's 50% smaller than another x264 file, no problem...
[23:51:06 CEST] <kepstin> just encode at lower bitrate.
[23:52:18 CEST] <drathir> kepstin: thats true, but all that on default settings with quality no visable difference...
[23:53:06 CEST] <drathir> kepstin: and yea bitrate ofc lower for x265...
[23:54:55 CEST] <drathir> but interesting some sources allow auto lowering bitrate other somehow prevent doing that..
[23:56:06 CEST] <kepstin> both x264 and x265 default to an encoding method that is approximately "constant quality" (-crf option), which means that the resulting bitrate will depend on how complex the video content is to encode.
[23:57:08 CEST] <drathir> probably some config options matter for that behaviour, but so far not get clue which one could be that... first thought CABAC frames but looks like no valid pattern with them...
[23:57:28 CEST] <Derisar> kepstin o thx
[23:58:21 CEST] <drathir> kepstin: thats mean some sources could get better/easier 'compressed' other dont...
[23:58:51 CEST] <kepstin> drathir: there's too many variables and encoder features to provide a simple answer, but yes, some videos are easier to compress than others for a given codec.
[23:59:35 CEST] <Durandal> qq: is there a way to specify a null output file for ffmpeg on windows?
[00:00:00 CEST] --- Tue May  8 2018