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

[burek]

[00:50:01 CET] <faLUCE> furq: well, I implemented the AAC encoding, and I can hear audio, but I still see the adaptation field in the mpegts header. So, I have this damned pcr again... In addition,  audioCodec->capabilities & AV_CODEC_CAP_VARIABLE_FRAME_SIZE == 0, so it seems that this codec doesn't support VBR
[00:52:07 CET] <faLUCE> I don't even understand if it's me that has to set AV_CODEC_CAP_VARIABLE_FRAME_SIZE , or it's left to the encoder
[00:52:49 CET] <atomnuker> variable frame size is only supported by s302m
[00:53:18 CET] <atomnuker> that's a property which just says you can feed the encoder any number of samples per frame
[00:53:30 CET] <atomnuker> for aac you have to feed in 1024 samples per frame
[00:53:50 CET] <atomnuker> VBR is something completely different to that
[00:54:17 CET] <atomnuker> VBR means your output packets are going to vary in size
[00:54:58 CET] <atomnuker> which they always do because AAC is only VBR
[00:56:05 CET] <faLUCE> atomnuker: the problem is that for audio packets the muxer sends an adaption field and pcr... is there a way to set it with variable muxrate ?
[00:56:42 CET] <faLUCE> atomnuker: or is it available only for s302m ?
[00:57:20 CET] <faLUCE> if the pcr  is sent through http, the receiver relies on it for buffering, and it messes up stuff
[00:57:36 CET] <faLUCE> (I don't have this problem with video)
[01:03:18 CET] <faLUCE> otherwise I don't find any other way to stream audio only with low latency.... maybe pseudo-raw mp2 or aac? (without mpegts container)
[01:08:16 CET] <atomnuker> faLUCE: I don't get what the problem is, you give the muxer packets and that's it, no?
[01:11:09 CET] <DHE> the mpegts muxer is writing PCR fields which is called for by the mpegts standard but apparnetly causes VLC to have a shit fit
[01:11:46 CET] <JEEB> whiich could be worked around by just switching the container to something else the receiving end supports :P
[01:12:59 CET] <DHE> what's a good alternative streaming format? ogg? does that support AAC audio?
[01:13:02 CET] <kepstin> aac is always gonna be fairly high algorithmic latency, unless you're talking about AAC-LD which I have no idea what anything supports it...
[01:15:11 CET] <JEEB> DHE: fragmented ISOBMFF, matroska are some of the more supported things. and then there's NUT if you're using libavformat on both sides.
[01:15:29 CET] <JEEB> it's mostly a case of what the client supports rather than what's a nice alternative
[01:15:41 CET] <faLUCE> I wonder if I can stream the mpga or aac container only. It has all the infos needed (samplerate, codec)
[01:15:58 CET] <JEEB> nothing stops you from doing that :P
[01:16:33 CET] <faLUCE> JEEB: I know but I have to spend much time for it
[01:17:09 CET] <JEEB> which, fortunately, is none of my concern
[01:17:38 CET] <faLUCE> then I wonder which is the most common way to stream http audio
[01:17:51 CET] <kepstin> if you want tostream audio only with low latency, why aren't you doing opus in rtp or something like that?
[01:18:10 CET] <faLUCE> kepstin: I don't want to use rtp
[01:18:17 CET] <kepstin> (you could do that by being a webrtc endpoint, if you want to talk to a browser)
[01:18:27 CET] <faLUCE> kepstin: few players support a good rtp client
[01:19:03 CET] <faLUCE> kepstin: the main advantage of http is that it's supported by all the players
[01:20:12 CET] <kepstin> hmm, with any sort of http streaming, you're gonna be dealing with pretty big buffers on the client side, so "low latency" on the encoder side isn't really something worth worrying about.
[01:20:26 CET] <faLUCE> kepstin: really not.
[01:20:35 CET] <faLUCE> I can stream audio+video with low latency
[01:20:39 CET] <faLUCE> (200ms)
[01:21:01 CET] Action: kepstin wouldn't call 200ms low, but he mostly does telephony/conferencing stuff.
[01:21:26 CET] <faLUCE> kepstin: it's low for my purposes
[01:21:57 CET] <faLUCE> but I don't understand how to mux audio only
[01:23:47 CET] <kepstin> hmm, if I controlled the player side, and had to use straight http streaming, I'd probably just used opus in ogg container. Should work perfectly fine, ogg is streamable.
[01:26:23 CET] <faLUCE> kepstin: but ogg doesn't seem to support AAC
[01:26:34 CET] <furq> it supports opus though
[01:26:36 CET] <kepstin> yeah, well, aac sucks for low latency stuff anyways
[01:26:49 CET] <faLUCE> I have to try opeus then
[01:26:51 CET] <faLUCE> opus
[01:26:53 CET] <furq> mpegts supports opus as well afaik
[01:27:00 CET] <kepstin> iirc most aac encoders will have 50-100ms of algorithmic delay?
[01:27:02 CET] <furq> but you'll want to check anything you might want to use to playback this stream supports it
[01:27:09 CET] <furq> and supports it in mpegts
[01:27:25 CET] <faLUCE> furq: vlc mplayer and ffplay
[01:28:13 CET] <furq> do you have control over which players are used
[01:30:31 CET] <faLUCE> furq: yes
[01:30:44 CET] <furq> do you need vlc support then
[01:30:56 CET] <furq> does it work with mp2 audio in mpv or some other player which doesn't suck
[01:31:23 CET] <faLUCE> furq: I just have to try opus+ogg
[01:31:31 CET] <furq> fair enough
[01:32:14 CET] <faLUCE> so, the remaining alternatives are ogg and matroska
[01:32:17 CET] <faLUCE> from what I see
[01:43:20 CET] <faLUCE> well, CODEC_ID_OPUS is not found with avcodec_find_encoder(). I tried also VORBIS, but it supports only two channels (and I have a mono input)
[01:43:50 CET] <furq> is your ffmpeg built with libopus
[01:44:23 CET] <faLUCE> furq: probably not. Let's recompile
[01:44:25 CET] <faLUCE> thnks
[02:01:59 CET] Action: ParkerR sees mention, greps log, just another mass spam mention like usual :(
[03:07:21 CET] <the_k> how come i can't find -strftime in the documentation
[03:07:25 CET] <the_k> is it depreciated?
[03:12:38 CET] <thebombzen> the_k: man ffmpeg-all has it
[03:14:26 CET] <thebombzen> this example is straight from the docs: ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1 "%Y-%m-%d_%H-%M-%S.jpg"
[03:15:18 CET] <thebombzen> it's an option for the segment muxer and the image2 muxer
[03:15:23 CET] <thebombzen> see ffmpeg-formats or ffmpeg-all
[03:16:21 CET] <the_k> i'm not sure what you mean by ffmpeg-all
[03:16:30 CET] <the_k> is that a different project?
[03:16:51 CET] <the_k> or a switch... -that doesn't seem to work
[03:17:41 CET] <thebombzen> the_k: the documentation, as in "man ffmpeg-all" or "man ffmpeg-formats"
[03:18:04 CET] <thebombzen> if you want the HTML reference, see this page: https://ffmpeg.org/ffmpeg-formats.html
[03:18:06 CET] <the_k> right
[03:18:09 CET] <the_k> well i'm on windows
[03:18:14 CET] <the_k> so i'm looking at the docu online
[03:18:19 CET] <thebombzen> see the above link
[03:18:20 CET] <the_k> i searched for -all and found nothing
[03:18:41 CET] <thebombzen> as for ffmpeg-all, it totally exists: https://ffmpeg.org/ffmpeg-all.html
[03:18:56 CET] <thebombzen> it's all on the website
[03:19:12 CET] <the_k> searching in that page for "-all" finds nothing
[03:19:20 CET] <the_k> oh
[03:19:23 CET] <the_k> i seeee
[03:19:31 CET] <the_k> that's the entire documentation!
[03:19:43 CET] <thebombzen> yes
[03:19:45 CET] <thebombzen> yes it is
[03:19:52 CET] <thebombzen> that's what ffmpeg-all means. it means "all the documentation"
[03:19:58 CET] <the_k> gotcha!
[03:20:30 CET] <the_k> ok right i see strftime in this documentation page
[03:20:41 CET] <thebombzen> or rather, it's all the documetation for the ffmpeg tool and any related libraries
[03:20:53 CET] <the_k> but not on http://ffmpeg.org/ffmpeg.html "ffmpeg Documentation"
[03:21:08 CET] <thebombzen> well that's because ffmpeg is a command line tool
[03:21:14 CET] <thebombzen> it tells you how to use ffmpeg.c
[03:21:31 CET] <thebombzen> (often times here we call the CLI tool ffmpeg.c to disambiguate it from the FFmpeg project)
[03:21:36 CET] <the_k> so what is strftime a part of
[03:21:50 CET] <thebombzen> strftime is an option for the image2 muxer and the segment muxer
[03:21:59 CET] <the_k> CLI means command line interface?
[03:22:01 CET] <thebombzen> yes
[03:22:05 CET] <the_k> riiight
[03:22:08 CET] <the_k> ok
[03:22:14 CET] <thebombzen> the image2 muxer and the segment muxer are part of libavformat
[03:22:25 CET] <thebombzen> so ffmpeg-formats would have information on demuxer and muxer options
[03:22:26 CET] <the_k> ok makes sense
[03:23:21 CET] <the_k> strftime 1|0
[03:23:21 CET] <the_k> Use the strftime function to define the name of the new segments to write
[03:24:07 CET] <the_k> so these are not DOS vars? name_%Y-%m-%d-%H;%M;%S.ts
[03:24:15 CET] <the_k> i assumed they were
[03:24:30 CET] <furq> %Y% would be a batch var
[03:24:57 CET] <the_k> yeah that's right
[03:25:03 CET] <the_k> ah ok
[03:25:15 CET] <furq> also if you're who i think you are, https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[03:25:30 CET] <the_k> i was here the other nigth talking to u
[03:25:36 CET] <the_k> last night
[03:26:32 CET] <furq> actually i just remembered i made this damn thing months ago so i wouldn't have to keep pasting segments of the docs and then forgot about it
[03:26:35 CET] <furq> i should bring it in here
[03:27:16 CET] <furq> !muxer segment
[03:27:16 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[03:27:19 CET] <furq> there
[03:27:26 CET] <furq> if you hate my bot please tell me and i will make it leave
[03:27:50 CET] <thebombzen> !encoder hevc_nvenc
[03:27:59 CET] <furq> !encoder list
[03:27:59 CET] <nfobot> furq: aac, ac3_fixed, amrnb, amrwbenc, dvdsub, encoders, flac, hap, jpeg2000, libfdk_aac, libkvazaar, libmp3lame, libopenh264, libopus, libshine, libtheora, libtwolame, libvorbis, libvpx, libwavpack, libwebp, libx264, libx264rgb, libx265, libxvid, mpeg2, png, prores, snow, vc2, wavpack
[03:27:59 CET] <thebombzen> hmmm
[03:28:06 CET] <furq> it only has the ones listed on the site
[03:28:29 CET] <thebombzen> !hwaccel list
[03:28:34 CET] <nfobot> furq: Available functions: muxer demuxer encoder decoder filter source sink indev outdev protocol bsf
[03:28:42 CET] <furq> idk if there's a parseable list of hwaccels in the docs
[03:28:44 CET] <thebombzen> I'm 0-2 lol
[03:28:57 CET] <thebombzen> !muxer matroska
[03:28:57 CET] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-formats.html#matroska
[03:29:01 CET] <furq> there you go
[03:29:15 CET] <furq> !muxer matroska @thebombzen
[03:29:15 CET] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-formats.html#matroska
[03:29:27 CET] <furq> and that's all the features
[03:29:33 CET] <thebombzen> that's a very disappointinly small list of muxer options
[03:29:35 CET] <thebombzen> for matroska
[03:33:01 CET] <furq> the web docs for muxers and encoders are missing a bunch of stuff
[03:33:10 CET] <faLUCE> furq: the problem with ogg is that only the FIRST packet (stream header) contains the infos about the codec. (mpegts collects this info at each packet). Then I wonder... is there anylibav function for getting the header of a muxed packet? I searched a lot but could not find anyone
[03:33:12 CET] <furq> you're better off just using -h encoder for that
[03:34:58 CET] <the_k> furq, even if i lower the fps and bitrate of the server's livestream - ffmpeg keeps dropping frames ("error while decoding MB ...")
[03:35:33 CET] <furq> pastebin the command
[03:35:42 CET] <the_k> if i remove the piped command on the end that piped it to mpv then it saves to disk fine
[03:35:44 CET] <the_k> sure
[03:35:46 CET] <furq> oh right
[03:35:52 CET] <furq> maybe just don't pipe it to mpv then ;_;
[03:36:02 CET] <the_k> well
[03:36:08 CET] <the_k> if i do that then it would save bandwidth
[03:36:18 CET] <furq> that shouldn't make any difference
[03:36:20 CET] <the_k> enough to make a difference to what i can do with the stream
[03:36:30 CET] <furq> ffmpeg only decodes the stream once
[03:36:38 CET] <the_k> the hq stream is 1.5mb/s
[03:36:47 CET] <the_k> so 1.5mb to save a continuous stream to disk
[03:36:58 CET] <furq> piping to mpv should effectively be free
[03:37:02 CET] <furq> pastebin the command anyway
[03:37:04 CET] <the_k> then 1.5mb to show a realtime stream so i can see it
[03:37:16 CET] <furq> there's only one 1.5mbit
[03:37:23 CET] <furq> it only downloads and decodes the stream once
[03:37:36 CET] <the_k> then if someone else wants to view the stream... that's it.. they have to view the secondary low quality stream .. or it breaks EVERYthing
[03:38:00 CET] <the_k> yes that's why this would be good... to take the input and use it twice
[03:38:19 CET] <the_k> otherwise i have to connect and take a second stream off it
[03:38:37 CET] <the_k> it would be good if this stupid camera's multicast mode worked but it doesn't
[03:39:04 CET] <the_k> and i'm not sure if i could use ffmpeg to save that too so i'm not so worried about trying to get that working
[03:40:02 CET] <furq> pastebin the command
[03:40:06 CET] <the_k> sec
[03:40:18 CET] <the_k> http://pastebin.com/HA8uyaZ4
[03:40:36 CET] <furq> yeah that's probably breaking because you're transcoding the stream
[03:40:52 CET] <furq> add another -c copy just before -f nut
[03:41:00 CET] <the_k> ok
[03:41:23 CET] <the_k> [NULL @ 0000000002d900a0] Unable to find a suitable output format for 'nut'
[03:41:37 CET] <the_k> nut: Invalid argument
[03:41:47 CET] <furq> -c copy -f nut -
[03:41:52 CET] <the_k> oh crap
[03:42:40 CET] <the_k> getting lots of "max delay reaced. need to consume packet"
[03:42:57 CET] <the_k> and the mpv stream stops and starts
[03:43:17 CET] <the_k> RTP: missed xxxx packets
[03:43:55 CET] <furq> weird
[03:44:04 CET] <furq> i don't see how adding a second output would cause that if you're copying
[03:44:12 CET] <the_k> well it does
[03:44:13 CET] <the_k> :)
[03:45:26 CET] <the_k> ah wait
[03:45:49 CET] <the_k> i was copying an old command i was testing with segment_time 10 in it
[03:45:57 CET] <furq> also like i said, the whole thing will drop out if mpv closes
[03:45:59 CET] <the_k> now i'm back to 24hrs there
[03:46:02 CET] <furq> there's no less fragile way i know of
[03:46:07 CET] <the_k> and it's better but still doing the same thing
[03:46:26 CET] <the_k> yeah if mpv closes that's fine.. i'd just restart it
[03:46:32 CET] <the_k> it hasn't crashed on me
[03:46:35 CET] <the_k> and i woudln't close it manually
[03:48:12 CET] <the_k> 3rd time running and this time it's fine...
[03:48:18 CET] <the_k> really stable
[03:48:32 CET] <the_k> it missed 158 , then 59., then 2 packets.. then stablized
[03:48:45 CET] <thebombzen> srunge.us over quoto
[03:48:52 CET] <thebombzen> not sure if my fault
[03:49:03 CET] <thebombzen> like if I sent too much or if it's global
[03:49:20 CET] <the_k> http://pastebin.com/raw/xezD2ubh
[03:50:00 CET] <faLUCE> furq: well, I got it. It works (just had to add the header at the beginning of the stream). Both mplayer and ffplay can hear the http audio stream without the mpegts problems
[03:50:19 CET] <faLUCE> vlc doesn't support opus, however.
[03:50:23 CET] <thebombzen> wut
[03:50:30 CET] <thebombzen> >vlc doesn't support opus
[03:50:33 CET] <thebombzen> ...really?
[03:50:36 CET] <furq> vlc is garbage though so who cares
[03:50:45 CET] <thebombzen> vlc not supporting opus is very surprising
[03:50:53 CET] <thebombzen> given that it's got avcodec
[03:51:06 CET] <furq> maybe it's an ancient vlc or just a wonky build
[03:51:13 CET] <faLUCE> thebombzen: but I compiled it from scratch. Maybe I did not configure it when compiling
[03:51:20 CET] <furq> that could also explain why it was shitting the bed because of your pcr
[03:51:26 CET] <thebombzen> pcr?
[03:51:41 CET] <furq> https://en.wikipedia.org/wiki/MPEG_transport_stream#PCR
[03:51:42 CET] <faLUCE> furq: no, also other versions of vlc do the same thing
[03:51:56 CET] <furq> vlc wasn't working for him with audio-only streams because the pcr was set incorrectly(?)
[03:51:59 CET] <furq> even though it shouldn't matter
[03:52:00 CET] <thebombzen> lol people here love to give vlc shit but tbh it's a lot better than anything not mplayer-based
[03:52:15 CET] <the_k> furq: would it be possible to get rid of the DTS error that it takes a second to fix? it seems like to get this working it needs a kind of headstart
[03:52:20 CET] <thebombzen> compare to quicktime or windows media player which most people use or realplayer or itunes or whatever
[03:52:27 CET] <faLUCE> furq: a possible reason for that problem is that in each case vlc wants the STREAM header
[03:52:34 CET] <thebombzen> vlc isn't really that bad in the grand scheme of things
[03:52:41 CET] <furq> it's pretty bad
[03:52:42 CET] <faLUCE> now I just have to check
[03:52:49 CET] <thebombzen> furq: compared to what?
[03:52:55 CET] <thebombzen> like compared to mpv? yea it sucks
[03:52:58 CET] <furq> yup
[03:53:06 CET] <thebombzen> compared to basically anything else? not rally
[03:53:24 CET] <thebombzen> recall that most people use quicktime/itunes/windowsmediaplayer crap
[03:53:27 CET] <furq> i'm constantly seeing "savvy" people using/recommending vlc though
[03:53:36 CET] <thebombzen> well mpv is a CLI player
[03:53:48 CET] <furq> even old mplayer frontends are better than vlc though
[03:53:55 CET] <thebombzen> hmm
[03:54:00 CET] <furq> and mpc-hc on windows
[03:54:06 CET] <thebombzen> mpc-hc? never heard of it
[03:54:18 CET] <thebombzen> either way the biggest issue with vlc is that I found a big bug that the devs aren't willing to fix
[03:54:19 CET] <faLUCE> anyway, this ogg container seems good
[03:54:22 CET] <furq> https://mpc-hc.org/
[03:54:27 CET] <faLUCE> and it's completaly open
[03:54:45 CET] <furq> i've been using it for years, it's nice
[03:54:51 CET] <thebombzen> ohey it's big buck bunny
[03:54:58 CET] <furq> even the directshow stuff isn't a huge deal any more thanks to lav filters
[03:55:00 CET] <thebombzen> I'm not gonna switch over to mpc-hc just cause I use mpv
[03:55:11 CET] <thebombzen> but it's a good thing to recommend it seems
[03:55:13 CET] <furq> well yeah if i hadn't been using mpc-hc for the best part of a decade i'd switch to mpv
[03:55:25 CET] <furq> i'm only sticking with it because of inertia
[03:55:54 CET] <furq> whenever i get rid of this godforsaken windows install i'll definitely be using mpv
[03:56:38 CET] <thebombzen> I"m looking at the thirdparty libraries and I don't see avcodec or avformat, which is interesting
[03:57:08 CET] <thebombzen> ah there it is
[03:57:14 CET] <thebombzen> apparently LAV Filters includes more than just libavfilter
[03:58:20 CET] <thebombzen> wow okay this is really greasy
[03:58:39 CET] <thebombzen> I'm making beef bowl for dinner and I didn't realize 80/20 was so much fat
[03:58:49 CET] <thebombzen> I mean literally 1/5 but it's all melting off like crazy
[03:59:54 CET] <faLUCE> [00007f4d7cc4e168] core decoder error: Codec `Opus' (Opus Audio) is not supported . this is really sad
[04:00:22 CET] <faLUCE> and there's not any opus configure flag
[04:01:32 CET] <faLUCE> I'm wrong... I compiled vlc with a previous compiled version of ffmpeg without opus
[04:02:47 CET] <furq> i don't know if lav filters actually includes libavfilter
[04:03:22 CET] <furq> filters refers to directshow filters
[04:03:30 CET] <furq> which includes decoders, because microsoft are good at naming things
[04:03:36 CET] <furq> and demuxers
[04:19:52 CET] <the_k> furq: would it be possible to get rid of the DTS error that it takes a second to fix? it seems like to get this working it needs a kind of headstart
[04:20:12 CET] <furq> no idea
[04:20:20 CET] <the_k> ok
[04:20:58 CET] <the_k> and it's not possible to view it in realtime without transcoding it?
[04:26:23 CET] <faLUCE> LOOOOL! I just saw that VLC says "bad PCR value" even wih a OGG http stream
[04:26:56 CET] <faLUCE> they made a mess
[05:52:27 CET] <mantas322> Hi guys
[05:52:32 CET] <mantas322> I have a tricky question
[05:53:09 CET] <mantas322> Is it possible to use FFMPEG to convert *.MTS format into GoPro Studio acceptable *.MP4???????
[05:53:13 CET] <mantas322> with audio?
[06:51:19 CET] <kepstin> mantas322: if the 'mts' files are mpeg TS, and you know what formats gopro studio accepts, then probably, yes?
[18:08:08 CET] <zoli> hi. with wich parameter can I downsize my original video with lowering the fps ?
[18:08:46 CET] <zoli> is it -r?
[18:13:31 CET] <DHE> you want -s
[18:39:35 CET] <zoli> DHE: tx, what is the difference between -r and -s?
[18:44:09 CET] <furq> -r is fps, -s is size
[18:44:11 CET] <furq> sounds like you want both
[19:23:14 CET] <DHE> or under certain interpretations a lower bitrate... do be specific
[20:08:50 CET] <Franciman> Is it possible to make av_read_frame discard frames that don't belong to a given AVStream?
[20:20:49 CET] <kuroro> hello, i need to cut up lots of videos into 3 second segments, currently im just using "ffmpeg -ss <time> -i input.mp4 -t <duration> -c:v libx264 -c:a libfdk_aac segment_name.mp4" multiple times (i.e. 1200 times for a 60 minute video)
[20:21:09 CET] <kuroro> is there a more efficient/faster way to go about this?
[20:23:19 CET] <kuroro> i.e. should i use libavcodec directly in a c program and do the splitting in memory instead of having to shell out to a new ffmpeg process each time and incur overhead of system calls. and is there a library/wrapper that already does this instead of having to write one myself
[20:26:56 CET] <JEEB> there's a segment muxer somewhere in lavf
[20:27:01 CET] <JEEB> never used it personally
[20:27:14 CET] <JEEB> also the DASH muxer writes segments into separate files, just like the HLS one
[20:30:10 CET] <furq> !muxer segment @kuroro
[20:30:10 CET] <nfobot> kuroro: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[20:35:52 CET] <kuroro> ah cool awesome. works for fixed segment durations. thanks
[20:36:39 CET] <kuroro> i also have cases where segment durations are widely varied though
[20:37:34 CET] <furq> you can use -segment_times for that
[20:41:24 CET] <kuroro> interesting
[20:58:24 CET] <thebombzen> segment muxer is the hot topic these days
[21:02:08 CET] <kuroro> oh yeah haha, i guess most people are using for hls
[21:02:12 CET] <kuroro> using it*
[21:05:39 CET] <JEEB> there's a hls muxer for that, though?
[21:07:42 CET] <DHE> even though DASH is technically the standard, HLS is popular mainly because apple pushes it
[21:08:11 CET] <kuroro> oh yeah true, probably. personally i mostly want to cut videos into word segments
[21:08:20 CET] <Franciman> hey, I set an AVStream discard value to AVDISCARD_ALL, but in av_read_frame I get exactly one packet from that stream. How is that possible?
[21:08:21 CET] <furq> hls is popular because it works everywhere
[21:08:31 CET] <furq> which i guess is because of apple pushing it
[21:08:50 CET] <kuroro> yeah with iphone, ipad adopting hls, it only makes sense people are gravitating towards it
[21:09:15 CET] <furq> well they've not so much adopted hls as refused to adopt dash
[21:09:35 CET] <furq> desktop browsers don't support hls but you can at least hack it into working without too much fuss
[21:09:41 CET] <JEEB> well they did adopt ISOBMFF in HLS
[21:09:50 CET] <JEEB> so now you can at least for some modes use the same segments
[21:09:58 CET] <furq> in theory at least
[21:10:13 CET] <JEEB> DRM had some differences which might lead you to contain multiple versions
[21:10:21 CET] <JEEB> or create them on-demand
[21:10:35 CET] <JEEB> (different AES modes)
[21:11:48 CET] <DHE> key distribution is a fun topic for other reasons as well. the HLS spec only specifies how to provide a URL to the key, not how to actually protect it. HTTP authentication, cookies, or something more creative?
[21:12:58 CET] <JEEB> well not like fairplay follows that spec
[21:13:11 CET] <JEEB> unless they let you define custom protocols and it's using one of those
[21:13:36 CET] <DHE> besides http? maybe...
[21:14:09 CET] <JEEB> I haven't tried fairplay yet, although some people seem to be pushing it lately... I wonder if they got it through the hollywood rights owners
[21:14:20 CET] <JEEB> since I remember only seeing other vendors' names until now :P
[21:17:30 CET] <thebombzen> how do you get a browser to work with HLS
[21:17:33 CET] <thebombzen> Javascript magic?
[21:18:19 CET] <DHE> basically. decrypt the data if needed and reassemble the stream as an MP4 for the built-in decoders
[21:18:34 CET] <kerio> thebombzen: i use safari
[21:18:36 CET] <kerio> U(  )W
[21:18:46 CET] <thebombzen> >safari
[21:19:02 CET] <thebombzen> plz
[21:19:11 CET] <DHE> some browsers do support HLS.  yeah safari, and I know chrome mobile does.
[21:19:24 CET] <thebombzen> Linux why would I use Safari
[21:19:24 CET] <JEEB> MS decided to go both ways and implemented both HLS and MPEG-DASH in edge
[21:19:33 CET] <thebombzen> interesting
[21:19:34 CET] <JEEB> natively that is
[21:19:54 CET] <thebombzen> prediction: Chrome will implement HLS, then Firefox will copy it
[21:19:59 CET] <JEEB> chrome and firefox mobile most likely just pass things to the native media framework
[21:20:17 CET] <thebombzen> what is the "native media framework" on Linux
[21:20:20 CET] <JEEB> neither have shown any signs of implementing HLS or MPEG-DASH natively
[21:20:31 CET] <JEEB> thebombzen: none. closest are either gstreamer or libav* :P
[21:20:42 CET] <thebombzen> cause I don't use gstreamer and I never thought of FFmpeg as a "media framework"
[21:21:07 CET] <JEEB> it isn't as simple as gstreamer, but pretty much the next thing after that :P
[21:21:08 CET] <thebombzen> does avformat support hls segments with mpegts
[21:21:15 CET] <kerio> hey, ffmpeg supports hls
[21:21:23 CET] <JEEB> in any case, chrome and firefox only do that on mobile
[21:21:36 CET] <JEEB> since HLS is most likely supported in the media framework there
[21:21:36 CET] <thebombzen> cause if libavformat does then there shouldn't be any real work needed for them
[21:21:37 CET] <BtbN> they don't support HLS because of license/patents on mpegts
[21:21:50 CET] <thebombzen> ...really?
[21:21:58 CET] <thebombzen> License/Patents on mpegts
[21:22:14 CET] <thebombzen> are causing the two most used browsers to be unable to support it?
[21:22:18 CET] <JEEB> more likely they feel they can just pass the parsing into JS :P
[21:22:24 CET] <JEEB> like hls.js and flv.js do
[21:22:31 CET] <JEEB> (it's perverse but that's how it's going)
[21:22:35 CET] <thebombzen> is there any reason to use flv anymore
[21:22:38 CET] <JEEB> no
[21:22:48 CET] <BtbN> Because rtmp exists and is the standard
[21:22:51 CET] <thebombzen> what was the purpose of flv originally
[21:22:53 CET] <JEEB> other than RTMP but that isn't really a reason nowadays any more
[21:23:00 CET] <thebombzen> oh RTMP yea okay
[21:23:03 CET] <BtbN> rtmp is the most widely used ingest protocol
[21:23:17 CET] <BtbN> And it's essentialy flv over tcp
[21:23:20 CET] <thebombzen> but does FLV support modern codecs
[21:23:23 CET] <thebombzen> like Opus
[21:23:29 CET] <JEEB> yea. thankfully some solutions have started taking in other stuff
[21:23:29 CET] <thebombzen> or are you stuck with AAC
[21:23:33 CET] <furq> you're stuck with aac
[21:23:37 CET] <BtbN> "stuck"
[21:23:45 CET] <BtbN> AAC is fine enough, and you want good player support anyway
[21:23:47 CET] <furq> i mean i guess that's a big deal for low latency, but then so is rtmp
[21:23:52 CET] <thebombzen> "aac is fine enough"
[21:24:00 CET] <furq> it is tbh
[21:24:01 CET] <thebombzen> well given that you can't encode it without --enable-nonfree
[21:24:06 CET] <furq> sure you can
[21:24:18 CET] <BtbN> Just don't use libfdk
[21:24:20 CET] <JEEB> that limitation was removed after atomnuker improved the encoder
[21:24:22 CET] <furq> you can't encode aac-he without nonfree
[21:24:26 CET] <furq> but he sucks anyway
[21:24:26 CET] <JEEB> ^this
[21:24:36 CET] <thebombzen> yea but the native aac encoder isn't experimental, but that doesn't mean it's anywhere as good as libopus (or libvorbis)
[21:24:52 CET] <JEEB> sure, you choose your weapons depending on what you're aiming
[21:25:05 CET] <JEEB> if your clients can support opus or vorbis you should look for other stuff like icecast
[21:25:05 CET] <thebombzen> like libopus is good enough to be fine for most purposes at 128k
[21:25:17 CET] <JEEB> and the internal AAC encoder isn't?
[21:25:23 CET] <thebombzen> avcodec's aac isn't in my experiences no
[21:25:25 CET] <JEEB> that would surprise me
[21:25:29 CET] <furq> sounds fine to me
[21:25:43 CET] <JEEB> since it was "OK" before the updates at that rate (while not being good)
[21:25:53 CET] <furq> bearing in mind how much stuff is out there using 128k mp2
[21:26:06 CET] <thebombzen> that's not really an excuse
[21:26:15 CET] <thebombzen> anyway the trac wiki says this: libopus > libvorbis >= libfdk_aac > aac
[21:26:28 CET] <thebombzen> for Encode/HighQualityAudio
[21:26:39 CET] <furq> well yeah but the wiki is often talking out of its arse
[21:26:45 CET] <thebombzen> it's written by us isn't it
[21:26:48 CET] <furq> cf. literally every page about streaming
[21:27:06 CET] <furq> if by "us" you mean "anyone on the internet" then sure
[21:27:07 CET] <JEEB> edited by someone without any data I guess? but yes, I do agree that fdk-aac most likely is in some ways better. to what extent is debatable
[21:27:20 CET] <furq> i'm not necessarily saying that's wrong, but i wouldn't treat it as gospel
[21:27:28 CET] <JEEB> I do agree that libvorbis and libopus are nice
[21:27:36 CET] <furq> the aac page says "aac >= fdk_aac"
[21:27:46 CET] <furq> so it's not even consistent within the wiki
[21:27:46 CET] <thebombzen> really? lol I knew the wiki was out of date
[21:27:55 CET] <thebombzen> but internally inconsistent is pretty bad
[21:28:08 CET] <thebombzen> what major changes did atomnuker make to the aac encoder
[21:28:16 CET] <thebombzen> it "doesn't suck anymore" but that's not really descriptive
[21:28:26 CET] <JEEB> pretty much a rewrite, he gave a talk on it at VDD '15
[21:28:31 CET] <furq> well yeah the problem is that people who'd write correct information would want to base it on actual evidence
[21:28:34 CET] <furq> and there isn't any yet
[21:28:44 CET] <furq> so the people who are basically just making shit up get to run the show
[21:28:54 CET] <furq> cf. literally every page about streaming
[21:29:05 CET] <thebombzen> yea the streaming pages have been somewhat useless
[21:29:06 CET] <JEEB> thebombzen: https://www.youtube.com/watch?v=QiV60eGY11o&list=PLQLpBN3oI7E44HIdTOovThc1MNHLchgHE&index=3
[21:29:14 CET] <thebombzen> JEEB: thanks
[21:29:24 CET] <thebombzen> speaking of streaming, I have a question:
[21:29:45 CET] <thebombzen> I have a webcam, and I want to stream it point-to-point with UDP with very low latency
[21:31:29 CET] <thebombzen> I try using: ffmpeg -probesize 32 -f v4l2 -video_size 3840x1080 -i /dev/video0 -c:v libx264 -preset:v superfast -tune:v zerolatency -crf:v 26 -x264-params intra-refresh=yes -f mpegts udp://localhost:12555
[21:31:37 CET] <thebombzen> and playing it with:
[21:31:49 CET] <thebombzen> ffplay -probesize 32 -f mpegts udp://localhost:12555
[21:31:59 CET] <thebombzen> the issue is I encur significant latency doing this
[21:32:03 CET] <thebombzen> the idea is sub-100ms
[21:32:19 CET] <thebombzen> but for some reason this command incurs about 150 to 200ms of latency, which is weird
[21:32:36 CET] <furq> don't you need to do some weird stuff with the vbv to get single-frame latency
[21:32:38 CET] <thebombzen> using -avioflags +direct -fflags +nobuffer doesn't help much
[21:32:42 CET] <kerio> does zerolatency enable slice-based threading
[21:32:45 CET] <furq> kerio: yes
[21:32:54 CET] <kerio> oh, that's why it sucks? :D
[21:32:59 CET] <thebombzen> furq: not quite sure what "vbv" is
[21:33:00 CET] <furq> that's the biggest reason, yeah
[21:33:07 CET] <JEEB> yeah, libx264's zerolatency tune is the one thing that optimizes for latency well
[21:33:14 CET] <JEEB> lavf/lavc can be a crapshoot
[21:33:28 CET] <thebombzen> but I guess my question is
[21:33:37 CET] <thebombzen> why does the above command not work
[21:33:40 CET] <thebombzen> why is there so much latency
[21:33:55 CET] <kerio> buffering in ffplay?
[21:33:57 CET] <kerio> i'd use mpv
[21:34:02 CET] <thebombzen> I thought that but I don't think it is
[21:34:05 CET] <thebombzen> mpv didn't change anything
[21:34:22 CET] <JEEB> yeah, everything lavf-based would have to be optimized
[21:34:27 CET] <thebombzen> plus, if I play from the webcam with: ffplay -probesize 32 -f v4l2 -video_size 3840x1080 -i /dev/video0
[21:34:29 CET] <JEEB> including mpv
[21:34:36 CET] <thebombzen> that has very low latency
[21:34:43 CET] <kerio> thebombzen: mpv with -cache=no?
[21:34:53 CET] <thebombzen> --cache=no? hmmm
[21:35:06 CET] <kerio> that's just one thing tho
[21:35:15 CET] <furq> have you tried using rtp instead of mpegts
[21:36:20 CET] <thebombzen> I tried using rtp, but ffmpeg complains that I need an SDP file
[21:36:38 CET] <thebombzen> the muxer spits one out on stdout, but it doesn't say anywhere how to specify it to the video player
[21:36:46 CET] <faLUCE> thebombzen: don't use ffmpeg for rtsp
[21:36:46 CET] <furq> > foo.sdp
[21:36:59 CET] <thebombzen> furq: I didn't install this OS yesterday
[21:37:11 CET] <thebombzen> "it doesn't say anywhere how to specify it to the video player"
[21:37:50 CET] <c_14> mpv foo.sdp
[21:38:23 CET] <thebombzen> that works?
[21:38:26 CET] <thebombzen> okay
[21:38:27 CET] <furq> yeah
[21:39:13 CET] <faLUCE> When open a matroska stream with mp2 codec it says:  "[matroska @ 0x39e2860] Codec for stream 0 does not use global headers but container format requires global headers"  ... do you know anything about that? Matroska supports mp2, from what I read...
[21:39:16 CET] <thebombzen> well when I try that I just get "error reading packet"
[21:40:45 CET] <thebombzen> http://0x0.st/VOz.txt
[21:41:03 CET] <thebombzen> that's what happens why I try RTP
[21:43:02 CET] <thebombzen> Also, if I try to go over plain UDP and play it with "mpv --cache=no udp://localhost:12555" it has enormous latency
[21:43:07 CET] <thebombzen> like 1000ms
[21:43:41 CET] <kerio> do you really need a container tho
[21:43:58 CET] <thebombzen> no, I just need the video to go over udp with low latency
[21:44:26 CET] <thebombzen> but how am I supposed to be able to deal with connection dropping without an mpegts or other container
[21:44:28 CET] <thebombzen> raw h264 doesn't do that
[21:45:44 CET] <faLUCE> thebombzen: If I can suggest you, just leave ffmpeg for rtsp/udp stuff. You don't have any control on it. I tried it for years. Use live555 instead
[21:46:15 CET] <thebombzen> I've never heard of that. can you give me some tips (or a pointer)
[21:46:22 CET] <faLUCE> thebombzen: in addition, udp has nothing to do with low latency
[21:46:31 CET] <thebombzen> it doesn't I know but I need UDP
[21:46:54 CET] <thebombzen> or rather UDP is better than TCP for the implemenation (independent of the latency)
[21:46:56 CET] <faLUCE> thebombzen: if I may ask, why would you need udp ? udp is intended for very low bw
[21:47:13 CET] <faLUCE> but it has many disadvantages
[21:47:20 CET] <thebombzen> the webcam is going to be mounted on a rover which is driving around terrain far away
[21:47:28 CET] <thebombzen> sending video to us so we can drive it
[21:47:45 CET] <faLUCE> thebombzen: ok, but I don't understand why would you choose UDP instead of tcp
[21:47:46 CET] <thebombzen> that's why we need low latency. as for why udp instead of tcp? cause tcp plays less well with random connection drops
[21:48:06 CET] <thebombzen> and we're prone to random connection drops
[21:48:07 CET] <faLUCE> thebombzen: really not. Rtp has an internal mechanism for avoiding that
[21:48:15 CET] <thebombzen> if that's true then sure
[21:48:28 CET] <faLUCE> UDP is only used when you want to reduce bw
[21:48:32 CET] <thebombzen> My requirements are the latency has to be very low and it has to be resilient to connection dropping
[21:48:40 CET] <thebombzen> but that's about it
[21:48:45 CET] <thebombzen> anything else is really my choice
[21:49:09 CET] <faLUCE> thebombzen: you have to do that: before experimenting latency with RTP/RTSP you have to be sure that all the stuff works
[21:49:14 CET] <faLUCE> and you can't do that with ffmpeg
[21:49:22 CET] <thebombzen> although I've never used rtsp or live555 before so is there some sort of tutorial
[21:49:23 CET] <faLUCE> thebombzen: http://live555.com/
[21:49:28 CET] <thebombzen> I looked at that
[21:49:43 CET] <faLUCE> thebombzen: it's very easy to use and well documented
[21:49:48 CET] <kerio> does dvb-s/dvb-t use mpegts?
[21:50:03 CET] <JEEB> pretty much all broadcast does
[21:50:03 CET] <thebombzen> I'm looking at the website and I don't know where to begin
[21:50:20 CET] <faLUCE> thebombzen: well. it's easy. Start with the examples
[21:50:32 CET] <faLUCE> there's an example for streaming raw h264 data
[21:50:42 CET] <thebombzen> there is no example on the page
[21:50:46 CET] <faLUCE> thebombzen: wait
[21:51:16 CET] <faLUCE> thebombzen: http://live555.com/liveMedia/faq.html#liveInput
[21:51:19 CET] <thebombzen> I believe you that it's really easy and well-documented but the homepage is not really that helpful
[21:51:40 CET] <faLUCE> thebombzen: you have to code in C++, though.
[21:51:55 CET] <thebombzen> >_>
[21:52:02 CET] <thebombzen> can I just tell it to read from /dev/stdin
[21:52:14 CET] <faLUCE> yes
[21:52:19 CET] <thebombzen> excellent
[21:52:23 CET] <faLUCE> no, sorry
[21:52:26 CET] <thebombzen> :(
[21:52:28 CET] <faLUCE> no /dev/stdin
[21:52:34 CET] <faLUCE> but you can make a pipe
[21:52:52 CET] <thebombzen> "Even simpler, if your operating system represents the encoder device as a file, then you can just use the name of this file (instead of "test.*").)"
[21:53:04 CET] <thebombzen> that sounds remarkably like telling it to read from /dev/stdin and then piping x264
[21:53:06 CET] <faLUCE> thebombzen: yes, because it's event looped
[21:53:14 CET] <thebombzen> uh
[21:53:19 CET] <faLUCE> thebombzen: exactly, what I said. Make a pipe
[21:53:32 CET] <thebombzen> well yea that's clearly part of /dev/stdin
[21:53:34 CET] <faLUCE> but anyway, explain better what you are doing
[21:53:38 CET] <thebombzen> if I want to be clever I could use process substitution
[21:53:46 CET] <thebombzen> but not necessary
[21:53:54 CET] <faLUCE> do you have to read h264 frames from a device-encoder ?
[21:54:22 CET] <thebombzen> um
[21:54:33 CET] <faLUCE> or do you encode locally the frames?
[21:54:42 CET] <thebombzen> well the webcam spits out yuyv422 frames
[21:54:46 CET] <thebombzen> I have to encode them on the fly
[21:55:02 CET] <faLUCE> ok, then you use x264, right?
[21:55:08 CET] <thebombzen> yea
[21:55:13 CET] <faLUCE> ok, wait
[21:55:19 CET] <thebombzen> I'm still really not sure what to do
[21:55:34 CET] <thebombzen> you say "it's well documented" but it appears that it's only well documented for someone who already knows what they're doing with it
[21:55:43 CET] <faLUCE> thebombzen:
[21:55:46 CET] <faLUCE> "Alternatively, if your encoder presents you with a sequence of frames (or 'NAL units'), rather than a sequence of bytes, then a more efficient solution would be to write your own "FramedSource" subclass that encapsulates your encoder, and delivers audio or video frames directly to the appropriate "*RTPSink" object"
[21:56:02 CET] <faLUCE> this is what you have to do
[21:56:12 CET] <thebombzen> wait so live555 has no reference CLI tools?
[21:56:15 CET] <thebombzen> I have to write my own?
[21:56:36 CET] <faLUCE> thebombzen: you have to make a subclass, and rewrite a method. few lines of code
[21:56:43 CET] <thebombzen> don't know C++
[21:56:52 CET] <thebombzen> I feel like "v4l2 -> x264 -> stream" has go to be so common that someone has done it before
[21:56:57 CET] <thebombzen> this just feels like reinventing the wheel
[21:56:59 CET] <faLUCE> thebombzen: then, believe me,  just avoid  rtsp/rtp
[21:57:20 CET] <thebombzen> well then what should I use lol
[21:57:25 CET] <faLUCE> thebombzen: currently there's only support with c++ for rtsp/rtp
[21:57:38 CET] <faLUCE> thebombzen: there are other libs, in C, but they are not good
[21:57:49 CET] <thebombzen> I don't know C either. you're missing the point
[21:58:14 CET] <thebombzen> I'm not looking for a LIBRARY I'm looking for an APPLICATION
[21:58:21 CET] <faLUCE> thebombzen: if you don't know C, how can you gat separate frames?
[21:58:22 CET] <thebombzen> ffmpeg.c does exactly what I need but it's too slow
[21:58:24 CET] <faLUCE> get
[21:58:34 CET] <thebombzen> I have no idea what you're talking about
[21:58:44 CET] <thebombzen> I'm trying to stream from a webcam point to point with ultra-low latency
[21:58:48 CET] <thebombzen> why do I need to get "separate frames"
[21:59:00 CET] <faLUCE> thebombzen: you said that you use x264 for encoding
[21:59:19 CET] <faLUCE> well, x264 takes a planar image and encodes it
[21:59:37 CET] <faLUCE> but if you don't code, how do you split the encoded stream into frames?
[21:59:43 CET] <thebombzen> I don't
[21:59:45 CET] <thebombzen> my video player does
[21:59:55 CET] <thebombzen> when I stream the h264 stream, I don't decode it
[22:00:01 CET] <faLUCE> thebombzen: then  you can't control params like low latency and similar things
[22:00:09 CET] <thebombzen> um
[22:00:13 CET] <faLUCE> unless you are very lucky
[22:00:22 CET] <thebombzen> I'm really confused
[22:00:49 CET] <faLUCE> thebombzen: in order to control the latency, you have to manage lot of different buffers
[22:01:08 CET] <thebombzen> the idea is to take the v4l2 yuyv422 input, encode it with x264, stream the h.264 stream point-to-point over the network, decode, it and display it
[22:01:12 CET] <thebombzen> this really isn't that hard
[22:01:12 CET] <faLUCE> the v4l buffer, the x264 buffer, the network buffers (input/output)
[22:01:20 CET] <thebombzen> the latency doesn't have to be perfectly exact
[22:01:22 CET] <thebombzen> it just has to be very low
[22:01:33 CET] <thebombzen> I don't care if it's 20ms or 18ms or 35ms or whatever
[22:01:34 CET] <thebombzen> that's not important
[22:01:42 CET] <faLUCE> thebombzen: ok, even if it has to be low, you have to control many buffers
[22:01:49 CET] <faLUCE> now, you have two choices:
[22:01:57 CET] <thebombzen> only if the CLI TOOLS DON'T ALREADY CONTROL THOSE BUFFERS WHICH IS WHAT I'M ASKING
[22:02:00 CET] <thebombzen> why is this so hard
[22:02:15 CET] <faLUCE> 1) control the buffers of the programs run by CLI (---> set them with arguments)
[22:02:21 CET] <thebombzen> YES THAT WAS THE QUESTIN
[22:02:23 CET] <faLUCE> 2) control the buffers in the code
[22:02:23 CET] <thebombzen> HOW DO I DO THAT
[22:02:34 CET] <faLUCE> thebombzen: be calm, I'm trying to explain
[22:02:43 CET] <thebombzen> you're really not listening
[22:02:53 CET] <faLUCE> if your choice is 1), it's not easy
[22:02:59 CET] <thebombzen> everything you've said about controlling buffers is something I know about
[22:03:09 CET] <thebombzen> the question is "how do I make it so these CLI tools don't have such a high latency"
[22:03:11 CET] <thebombzen> which is the question
[22:03:19 CET] <furq> but what's the question
[22:03:21 CET] <faLUCE> thebombzen: I'm trying to answer, be calm
[22:03:34 CET] <faLUCE> these buffers are HARD to control with CLI
[22:03:43 CET] <thebombzen> I already asked it
[22:04:15 CET] <thebombzen> I'm trying to stream point-to-point very low latency, but when I try using the ffmpeg tools there is a significant latency incurred
[22:04:23 CET] <thebombzen> what do I do to fix this
[22:04:28 CET] <faLUCE> thebombzen: I know that, I'm explaining what
[22:04:31 CET] <faLUCE> why
[22:04:36 CET] <thebombzen> I know why
[22:04:40 CET] <thebombzen> the question is how do I not do that
[22:04:44 CET] <thebombzen> I know there's internal buffers
[22:04:57 CET] <thebombzen> I tried using -fflags +nobuffer and -avioflags +direct and -probesize 32 and stuff
[22:05:06 CET] <thebombzen> none of them helped much
[22:05:20 CET] <thebombzen> if the answer is "don't use ffmpeg.c" then what CLI tool should I be using for this
[22:05:25 CET] <faLUCE> thebombzen: if you know ALL the buffers, and you know how to set them with CLI then... you should do all what you want. but I'm sure you DON't know all the buffers
[22:05:27 CET] <thebombzen> this is all stuff I've said above
[22:05:44 CET] <thebombzen> well knowing that ffmpeg has internal buffers doesn't necessarily mean I no how to disable them
[22:06:14 CET] <faLUCE> thebombzen: you need to control them
[22:06:19 CET] <thebombzen> well obviously
[22:06:23 CET] <thebombzen> that's sort of the whole point
[22:06:28 CET] <faLUCE> for example: do you know how to control the v4l buffer?
[22:06:38 CET] <faLUCE> do you know how to control the tcp buffer?
[22:06:55 CET] <faLUCE> if you want to control them with  CLI::.. IT'S HARD
[22:06:56 CET] <thebombzen> no, but the v4l buffer is not the bottleneck
[22:06:59 CET] <JEEB> in any case, lavf and lavc have plenty of buffer points and I'm not sure if anyone here has correctly noted how to minimize all of them
[22:07:16 CET] <thebombzen> JEEB: if it can't be done with lavf/lavc what should I use instead
[22:07:19 CET] <BtbN> disabling buffers usually leads to a very bad experience overall
[22:07:19 CET] <JEEB> you most likely can do it, but if someone has done that already properly it's not documented
[22:07:22 CET] <BtbN> They exist for a reason
[22:07:29 CET] <JEEB> thebombzen: not saying it can't be done
[22:07:33 CET] <faLUCE> the only way to minimize is doing that through software, for a specific video device
[22:07:38 CET] <JEEB> it's just that the defaults are not aimed for it and thus you have to go through things :P
[22:07:50 CET] <thebombzen> well yes I know that
[22:07:54 CET] <thebombzen> what are those things I must go through
[22:08:03 CET] <thebombzen> sub-100ms point-to-point really doesn't sound like something that nobody has figured out how to do
[22:08:07 CET] <JEEB> that's the thing, you only start looking into that when you try to optimize for that use case
[22:08:16 CET] <JEEB> and nobody seems to have documented that :P
[22:08:16 CET] <furq> thebombzen: http://archive.is/gUP7m
[22:08:19 CET] <faLUCE> thebombzen: anyway, vlc has better control of the buffers than ffmpeg
[22:08:28 CET] <furq> that doesn't deal with the libav* or v4l buffers but it might help
[22:08:31 CET] <faLUCE> thebombzen: start with vlc before
[22:08:39 CET] <thebombzen> lol recommending vlc
[22:08:44 CET] <thebombzen> no I get you
[22:08:49 CET] <furq> http://vpaste.net/gEvjj
[22:08:51 CET] <thebombzen> I just find it funny since people spend so much time her trashing vlc
[22:08:52 CET] <furq> specifically that bit of comment 8
[22:08:56 CET] <JEEB> basically the only thing I know is that libx264 (the library) is very good with the zerolatency tuning, but that's thus the simplest part of the equation
[22:09:07 CET] <faLUCE> thebombzen: I'm not recommending vlc. I'm saying that in the vlc interface you can see easily all the WORKING options
[22:09:21 CET] <faLUCE> JEEB: zerolatency is not enough
[22:09:24 CET] <faLUCE> it's a minimal part
[22:09:32 CET] <furq> he just said that
[22:09:34 CET] <faLUCE> the main problem is the receiver's buffer
[22:09:38 CET] <JEEB> well yes
[22:09:56 CET] <JEEB> "but that's thus the simplest part of the equation"
[22:10:02 CET] <faLUCE> anyway, don't do that with CLI.
[22:10:15 CET] <JEEB> because it's the one component that is known to have simply usable low latency parameters :P
[22:11:06 CET] <faLUCE> in addition: NEVER use ffmpeg as rtp streamer
[22:11:12 CET] <furq> thebombzen: packet size is ?pkt_size= in the udp muxer, which iirc you want to set to your router's MTU
[22:11:29 CET] <furq> s/muxer/protocl
[22:11:35 CET] <faLUCE> never use UDP as well, except if you well know what you are doing
[22:11:37 CET] <furq> there's also a buffer_size option in there you'll want to check
[22:12:08 CET] <furq> also i am aware this isn't necessarily the answer, but it's easier to check this stuff than learn C
[22:12:34 CET] <faLUCE> furq: in the receiver there are at least 4 different buffers
[22:12:40 CET] <furq> yes there are
[22:12:53 CET] <faLUCE> furq: if you sum them to at least 8 buffer of the sender....
[22:13:06 CET] <faLUCE> you can understand that with CLI it's almost impossible to control the latency
[22:13:16 CET] <furq> probably!
[22:13:24 CET] <furq> i guess we'll find out shortly
[22:14:01 CET] <faLUCE> furq: good luck :-)
[22:14:12 CET] <furq> i'm not the one who needs luck, i'm not doing anything
[22:14:28 CET] <furq> i'm just sat here laughing at irc, and that's already going extremely well
[22:14:53 CET] <faLUCE> [22:13] <furq> i guess we'll find out shortly
[22:19:08 CET] <thebombzen> are x264 units in kbps or in bps
[22:19:31 CET] <furq> bits iirc
[22:19:37 CET] <JEEB> lavc works in bps
[22:19:40 CET] <JEEB> libx264 works in kbpx
[22:19:42 CET] <JEEB> *kbps
[22:19:50 CET] <JEEB> thus if you work with the lavc libx264 wrapper that takes in bps
[22:19:51 CET] <thebombzen> what about -x264-params and ffmpeg.c
[22:19:53 CET] <furq> maxrate and bufsize are ffmpeg options though, so those should be bps
[22:20:00 CET] <JEEB> -x264-params goes straight into libx264
[22:20:10 CET] <thebombzen> I'm using -x264-params vbv-bufsize
[22:20:13 CET] <thebombzen> should I not do that?
[22:20:17 CET] <furq> shrug
[22:20:24 CET] <furq> i'm just reading this off a blog post
[22:20:26 CET] <JEEB> it's OK to use it, but -maxrate and -bufsize are mapped to those
[22:20:57 CET] <JEEB> -maxrate and -bufsize utilize bits per sec, and -x264-params's vbv-bufsize is in kbps because that one gets passed into libx264 API as-is
[22:21:03 CET] <JEEB> (that's what the option is for)
[22:21:12 CET] <furq> apparently slice-max-size is in bytes
[22:21:34 CET] <JEEB> sounds feasible
[22:21:35 CET] <furq> i guess that makes sense since packet size is in bytes as well
[22:21:38 CET] <JEEB> yea
[22:21:39 CET] <thebombzen> so the latency isn't gone
[22:22:11 CET] <thebombzen> these are the encoder options -c:v libx264 -preset:v superfast -x264-params slice-max-size=4096:vbv-maxrate=10000000:vbv-bufsize=166667:intra-refresh=yes -crf 26 -tune zerolatency -f mpegts udp://127.0.0.1:12555
[22:22:12 CET] <furq> i'd probably doublecheck all the x264 options with x264 --fullhelp
[22:22:28 CET] <thebombzen> but either way
[22:22:34 CET] <faLUCE> thebombzen: hint: modify keyint. the player waits for a reference frame, before it displays something.
[22:22:45 CET] <thebombzen> I don't care about startup delay
[22:22:49 CET] <thebombzen> I just care about latency
[22:22:55 CET] <furq> slice-max-size should be the same value as udp://0.0.0.0:12345/?pkt_size=
[22:23:04 CET] <furq> and iirc that should probably be 1488 or whatever your router MTU is
[22:23:08 CET] <kerio> faLUCE: we have no i-frames here
[22:23:09 CET] <thebombzen> well I'm localhost
[22:23:22 CET] <furq> you want this to go over th enetwork eventually though don't you
[22:23:24 CET] <thebombzen> testing on localhost that is
[22:23:31 CET] <thebombzen> so I just set some artificial parameters there
[22:23:34 CET] <furq> either way i think you need to set the packet size to the same thing
[22:23:37 CET] <faLUCE> kerio: there are reference frames, though
[22:24:41 CET] <thebombzen> faLUCE: progressive intra refresh
[22:24:57 CET] <furq> thebombzen: and yeah vbv-maxrate in x264-params is in kbps, not bps
[22:25:10 CET] <thebombzen> oh hmm
[22:25:11 CET] <furq> so i'm guessing 10 million is a bit too high
[22:25:16 CET] <thebombzen> lol
[22:25:18 CET] <thebombzen> it's crf
[22:25:20 CET] <thebombzen> so that's just no maxrate
[22:25:40 CET] <thebombzen> same with vbv bufsize?
[22:25:44 CET] <furq> bufsize is kbit as well yeah
[22:25:53 CET] <kerio> i thought the whole point of that whole low latency h264 thing was to have a constant size
[22:26:01 CET] <JEEB> no
[22:26:09 CET] <JEEB> the whole point was low latency
[22:26:12 CET] <kerio> yeah ok but
[22:26:20 CET] <JEEB> constant size is a separate requirement for specific use cases
[22:26:38 CET] <thebombzen> just tested with this: -c:v libx264 -preset:v superfast -x264-params slice-max-size=4096:vbv-maxrate=10000000:vbv-bufsize=166667:intra-refresh=yes -crf 26 -tune zerolatency -f mpegts udp://127.0.0.1:12555
[22:26:39 CET] <furq> the point is that the maximum frame size is the same as the buffer size
[22:26:47 CET] <thebombzen> wait where did it go
[22:26:53 CET] <thebombzen> ah there it is
[22:26:54 CET] <thebombzen> -c:v libx264 -preset:v superfast -x264-params slice-max-size=512:vbv-maxrate=10000:vbv-bufsize=166:intra-refresh=yes -crf 26 -tune zerolatency -f mpegts udp://127.0.0.1:12555?pkt_size=512
[22:26:55 CET] <thebombzen> this
[22:27:16 CET] <furq> did it help at all
[22:27:19 CET] <thebombzen> not really
[22:27:33 CET] <thebombzen> I played it with: ffplay -probesize 32 -f mpegts -i udp://127.0.0.1:12555
[22:27:40 CET] <JEEB> &21
[22:27:42 CET] <thebombzen> I don't think it's a player buffer because if I just ffplay the input
[22:27:47 CET] <thebombzen> it works fine
[22:27:51 CET] <thebombzen> as in very low latency
[22:28:02 CET] <faLUCE> thebombzen: you will do lot of tests, but at the end you will have to fight with the receiver's delay
[22:28:11 CET] <faLUCE> beware of wasting time
[22:28:15 CET] <thebombzen> >the receiver's delay
[22:28:22 CET] <thebombzen> do you mean me? I'm the receiver
[22:28:29 CET] <thebombzen> I have access to both ends
[22:28:35 CET] <furq> he means the player
[22:28:37 CET] <faLUCE> thebombzen: I mean the player
[22:28:40 CET] <furq> see
[22:28:42 CET] <thebombzen> well the player isn't hte bottleneck
[22:28:48 CET] <thebombzen> which is literally what I just said
[22:28:57 CET] <faLUCE> thebombzen: the player is the main problem in those things
[22:29:05 CET] <furq> in fairness you don't know if it buffers udp differently from v4l
[22:29:07 CET] <thebombzen> well I literally just said it isn't
[22:29:14 CET] <thebombzen> but whatever
[22:29:25 CET] <furq> i'd be more concerned about the muxer delay though
[22:29:25 CET] <thebombzen> "the player is the main problem"
[22:29:27 CET] <faLUCE> thebombzen: then, good luck to you too
[22:29:34 CET] <thebombzen> clearly I'm trying to fix something else
[22:30:44 CET] <thebombzen> I tried using a different client like VLC
[22:30:50 CET] <thebombzen> it doesn't even like the udp stream
[22:31:25 CET] <furq> there are a bunch of udp options you can try messing with fwiw
[22:31:28 CET] <furq> https://ffmpeg.org/ffmpeg-protocols.html#udp
[22:32:08 CET] <furq> i doubt a 64KB buffer size is going to have an impact on a 10mbit stream though
[22:34:05 CET] <thebombzen> oh wow lots of decoder errors
[22:36:48 CET] <thebombzen> https://i.imgur.com/z209VFI.png
[22:36:59 CET] <kerio> that's not errors
[22:37:00 CET] <thebombzen> that's what I get by setting the buffer_size and fifo_size
[22:37:02 CET] <kerio> that's glitch art
[22:37:19 CET] <kerio> https://www.reddit.com/r/glitch_art/
[22:37:54 CET] <thebombzen> Okay.
[22:38:05 CET] <furq> i'm sure that's adequate consolation
[22:45:46 CET] <thebombzen> you're right that ffplay might buffer differently for v4l2 than udp
[22:45:52 CET] <thebombzen> so I'm going to try a different client (vlc)
[22:46:00 CET] <thebombzen> mpv appears to make everything worse for some reason
[22:51:13 CET] <thebombzen> >attempt to build from git master
[22:51:16 CET] <thebombzen> -Werror
[22:51:19 CET] <thebombzen> really dude
[22:52:46 CET] <thebombzen> to those of you who use -Werror you just make it impossible to compile your stuff
[22:54:06 CET] <JEEB> what version of waf are you using?
[22:54:20 CET] <JEEB> I'm pretty sure the one that mpv uses in its repo isn't doing Werror
[22:54:22 CET] <thebombzen> not mpv
[22:54:23 CET] <thebombzen> vlc
[22:54:25 CET] <JEEB> ok
[22:54:29 CET] <thebombzen> mpv compiles fine for me
[22:54:32 CET] <DHE> -Werror isn't a good idea for other reasons. gcc warnings vary by version
[22:54:38 CET] <thebombzen> yea that's why I hate it
[22:55:08 CET] <thebombzen> people who use -Werror just make it so anyone with a different version might randomly not compile
[22:55:12 CET] <JEEB> for development it's "passable", but anything released should be buildable without it :)
[22:55:22 CET] <thebombzen> well to be fair it's git master
[22:55:44 CET] <thebombzen> ah well I found out why
[22:55:51 CET] <JEEB> kind of surprised Werror would be used though, since I would guess FFmpeg linking/headers would cause a lot of warnings :P
[22:55:51 CET] <thebombzen> it was -Werror=implicit-function-declaration
[22:55:54 CET] <JEEB> or at least some
[22:56:02 CET] <thebombzen> which really should be an error in the first place
[22:56:08 CET] <JEEB> yea
[22:56:21 CET] <JEEB> and yes, as I remember building VLC it didn't have a full Werror
[22:56:32 CET] <JEEB> would have been surprised if j-b or remi had added it
[22:57:09 CET] <thebombzen> ah so apparently luaL_checkint -> luaL_checkinteger
[22:57:17 CET] <thebombzen> and the vlc devs didn't get the memo
[22:57:36 CET] <JEEB> lua 5.2 => 5.3?
[22:57:42 CET] <JEEB> 5.3 isn't used by many projects
[22:57:46 CET] <JEEB> due to all the changes
[22:58:11 CET] <thebombzen> yea I have 5.3 installed
[22:58:43 CET] <furq> are you on one of those distros that thinks only packaging lua 5.3 is good because it's the latest
[22:58:45 CET] <JEEB> I'd guess mpv specifically checks for older than 5.3 and doesn't enable it
[22:58:53 CET] <JEEB> and thus no failures there
[22:58:58 CET] <JEEB> since IIRC 5.3 support never went in
[22:59:01 CET] <thebombzen> wait so I have 5.1, 5.2 and 5.3 installed
[22:59:07 CET] <JEEB> ah
[22:59:09 CET] <thebombzen> but VLC doesn't like htat
[22:59:20 CET] <JEEB> the pc file for which do you have?
[22:59:25 CET] <furq> doesn't vlc still use 5.1
[22:59:32 CET] <JEEB> you can use 5.1 or 5.2 I would guess
[22:59:35 CET] <furq> if this is a debian-alike then the lua pcs should be versioned
[22:59:39 CET] <JEEB> 5.3 is where a lot of changes happened
[22:59:49 CET] <furq> although maybe update-alternatives is doing something funky
[23:00:08 CET] <thebombzen> update-alternatives?
[23:00:19 CET] <thebombzen> okay so apparently I only had one random library that depended on lua5.3
[23:00:21 CET] <furq> the debian thing which manages symlinks for multiple package versions
[23:00:29 CET] <thebombzen> so I just ran pacman -Rcs lua
[23:00:32 CET] <furq> oh it's arch
[23:00:33 CET] <furq> nvm then
[23:00:33 CET] <thebombzen> and let's hope it works
[23:00:51 CET] <thebombzen> well now it says it can't find lua
[23:00:55 CET] <thebombzen> ;p
[23:01:40 CET] <furq> i'm pretty sure you need 5.1 fwiw
[23:02:16 CET] <thebombzen> checking for LUA... no
[23:02:16 CET] <thebombzen> configure: WARNING: No package 'lua5.2' found, trying lua 5.1 instead
[23:02:26 CET] <furq> https://www.videolan.org/developers/vlc/share/lua/README.txt
[23:02:29 CET] <furq> maybe this is out of date though
[23:02:40 CET] <furq> also "LUA" nice work
[23:03:27 CET] <thebombzen> ah that's because it's lua52.pc
[23:03:31 CET] <thebombzen> not lua5.2.pc
[23:03:40 CET] <JEEB> the file name doesn't matter
[23:03:44 CET] <JEEB> it's the package name in the pc file
[23:04:28 CET] <furq> idk how people using lua are still unaware that's an issue
[23:04:44 CET] <furq> the pc files are named differently on every distro and every other weekday
[23:05:56 CET] <thebombzen> you say it doesn't matter
[23:06:02 CET] <thebombzen> but my symbolic link begs to disagree
[23:06:09 CET] <furq> i think either works
[23:06:14 CET] <JEEB> well, then I misunderstood how pkg-config works :P
[23:06:20 CET] <JEEB> because it has the package name and version there
[23:06:49 CET] <thebombzen> http://0x0.st/VOG.pc
[23:07:01 CET] <thebombzen> does it?
[23:07:03 CET] <furq> what
[23:07:16 CET] <furq> why would they call it lua52.pc when the libname is lua5.2
[23:07:21 CET] <furq> oh wait it's because arch sucks
[23:07:29 CET] <thebombzen> why is this arch's problem
[23:07:38 CET] <furq> because they're the ones who made the pc
[23:07:43 CET] <thebombzen> the maintainer did
[23:07:45 CET] <thebombzen> not the distro
[23:07:51 CET] <furq> the distro picks the maintainers
[23:08:06 CET] <furq> the maintainer does definitely suck though
[23:08:20 CET] <thebombzen> well debain sucks because of the FFmpeg maintainer right
[23:08:22 CET] <thebombzen> ohwait
[23:08:29 CET] <furq> not any more
[23:08:56 CET] <furq> anyway at least it's not every rpm distro which only packages lua 5.3 because "it's the latest"
[23:09:32 CET] <thebombzen> well arch generally only packages "the latest"
[23:09:38 CET] <thebombzen> but they have old version #ed packages
[23:09:42 CET] <thebombzen> like python and python2
[23:09:45 CET] <thebombzen> or lua and lua52 and lua51
[23:10:12 CET] <furq> well yeah most distros do that but they're capable of knowing when to make an exception
[23:11:15 CET] <furq> anyway lua is pretty cool. i like it
[23:11:55 CET] <thebombzen> except when I get a "version mismatch in a precompiled chunk"
[23:11:56 CET] <thebombzen> um
[23:12:01 CET] <thebombzen> I only ahve one version of lua installed
[23:12:18 CET] <furq> you'll be needing 5.1 then
[23:12:37 CET] <furq> that's fucking dumb if that's the issue and vlc's autoconf shit checks for 5.2
[23:12:57 CET] <furq> but yeah if they have precompiled bytecode for 5.1 then you can't run that with 5.2
[23:13:27 CET] <BtbN> lua also breaks its API with every release
[23:13:31 CET] <furq> i don't know why they would precompile bytecode and then not do an explicit version check at build time, but that's their problem
[23:14:08 CET] <gurki> im a bit confused. ffmpeg tells me that it "failed to load the nvenc library". strace tells me its looking for some libnvidia-encode.so. i guesstimate its referring to what can be built using the nvenc sdk. building said sdk fails at the step "cannot find -lnvidia-encode" - which is kind of correct, as i do not have such a library in my cuda 7.5 installation.
[23:14:34 CET] <gurki> the thing i actually wnt to do is encode h264 using a nvidia gpu
[23:14:37 CET] <gurki> any ideas?
[23:14:38 CET] <BtbN> The library comes from the nvidia driver, the CUDA SDK is not needed at all.
[23:15:05 CET] <thebombzen> interestingly, if I try to play the UDP stream with ffplay, it's okay-ish
[23:15:09 CET] <thebombzen> VLC won't play it at all
[23:15:14 CET] <gurki> assuming i cannot make changes to the driver as i do not have root on that system ...
[23:15:52 CET] <BtbN> if the driver isn't installed properly, you obviously can't use it.
[23:16:39 CET] <gurki> i kind of fail to understand how encoding stuff is a driver-related thing Oo
[23:16:40 CET] <furq> thebombzen: like i was saying, vlc sucks
[23:17:04 CET] <BtbN> How would it _not_ be driver related? It's using encoding hardware on the card, so of course it needs a driver.
[23:17:10 CET] <furq> gurki: it's a hardware encoder. you need drivers to access the hardware
[23:17:15 CET] <furq> like with most hardware
[23:17:26 CET] <gurki> ah. i kind of thought it d do some cuda-stuff
[23:17:32 CET] <gurki> makes sense in that case
[23:17:34 CET] <BtbN> CUDA also needs a driver.
[23:17:39 CET] <furq> yeah
[23:17:46 CET] <furq> it's not cuda though, it's a separate asic
[23:17:49 CET] <gurki> cuda works. hence my hope for it being some cuda stuff ;)
[23:17:50 CET] <furq> it doesn't use the actual gpu at all
[23:18:12 CET] <BtbN> it uses it to copy around frames and packets
[23:18:28 CET] <furq> it doesn't use the actual gpu very much
[23:18:30 CET] <BtbN> If CUDA works and nvenc doesn't, I'd guess you are using an ancient nvidia driver.
[23:18:43 CET] <gurki> 375.20 to be precise
[23:18:53 CET] <BtbN> that's more than recent enough, it's not installed properly then.
[23:19:07 CET] <furq> are you sure your card has nvenc
[23:19:13 CET] <gurki> its a gtx 1050
[23:19:21 CET] <BtbN> it's not even finding the library
[23:19:45 CET] <BtbN> Have you tried latest ffmpeg master?
[23:21:33 CET] <gurki> no i havent as nvidia told me to use some specific commit version and apply some specific patch.
[23:21:39 CET] <gurki> will try using master
[23:21:41 CET] <gurki> gimme a sec
[23:22:40 CET] <thebombzen> Figures.
[23:22:44 CET] <thebombzen> x264 requires 10bit input
[23:22:54 CET] <BtbN> what? No it doesn't.
[23:23:44 CET] <thebombzen> my build does
[23:23:46 CET] <thebombzen> I have to recompile it
[23:25:09 CET] <DHE> 8-bit is the default...
[23:25:18 CET] <DHE> you have to go out of your way to get the 10-bit version
[23:28:00 CET] <gurki> BtbN: sadly, no difference :(
[23:28:49 CET] <gurki> oh. i thought the problem has been clear. pasting ...
[23:29:50 CET] <BtbN> Well, I'm like 90% sure your driver is not installed correctly.
[23:30:24 CET] <DHE> there's been updates to nvenv that are not backwards compatible. even a 1 year old version of the nvidia driver won't work anymore
[23:30:38 CET] <DHE> (much to my own dismay)
[23:30:42 CET] <BtbN> The driver is super recent.
[23:30:47 CET] <BtbN> It's not even finding the .so
[23:30:56 CET] <BtbN> Just search your system for libnvidia-encode.so.1, if it doesn't exist or isn't in a standard location, the driver is not installed properly.
[23:30:59 CET] <gurki> http://pastebin.com/UMgPEbrk
[23:31:11 CET] <BtbN> "Cannot load libnvidia-encode.so.1"
[23:31:14 CET] <BtbN> yeah
[23:31:22 CET] <gurki> ya thats been my very first message in this #
[23:31:42 CET] <BtbN> no, that was without the .1
[23:32:02 CET] <gurki> my bad.
[23:32:12 CET] <BtbN> And I suspected some distributor to remove the plain .so symlink, and latest master checks the correct one
[23:32:35 CET] <BtbN> But yeah, your driver is not installed properly.
[23:33:18 CET] <gurki> is there a way to get this a bit more specific? admins are gonna smash my head for telling them "something is not installed properly" ^^
[23:33:25 CET] <gurki> yes i know, lib x is missing
[23:33:27 CET] <gurki> apart from that?
[23:33:35 CET] <BtbN> that's pretty much it
[23:33:37 CET] <gurki> (is it worth trying cuda stuff?)
[23:33:38 CET] <BtbN> you need that library
[23:33:42 CET] <BtbN> cuda stuff?
[23:33:49 CET] <gurki> encoding using cuda, and not that asic
[23:34:02 CET] <BtbN> You'll have to write a CUDA based encoder for that first.
[23:34:05 CET] <DHE> the ASIC API involves going around CUDA. you need both
[23:34:07 CET] <BtbN> And GPUs are bad at encoding videos.
[23:34:15 CET] <BtbN> You don't want to use them for it.
[23:35:04 CET] <BtbN> The nvidia-encode library is a standard part of the nvidia drivers for a while now. And for you it's plain missing, or not in the right location.
[23:35:19 CET] <CoJaBo> Depends on the usecase; if you need realtime, you can't beat GPU-accel :P
[23:35:23 CET] <BtbN> You can search for it, and adjust LD_LIBRARY_PATH if it's in some obscure location.
[23:35:36 CET] <BtbN> CoJaBo, it's not GPU-accel, it's a dedicated ASIC
[23:35:47 CET] <BtbN> GPUs are not well suited for video de/encoding workloads.
[23:36:08 CET] <DHE> if you NEED realtime and minimal  CPU pentalty, sure. if quality matters, use x264
[23:42:14 CET] <thebombzen> DHE: well yes
[23:42:18 CET] <thebombzen> I had a 10bit version compiled
[00:00:00 CET] --- Mon Jan 30 2017