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

Sat Nov 16 03:05:02 EET 2019

[00:18:42 CET] <barhom> anyone know of a guide to get scale_npp cuda drivers on debian 10 running? Is it as easy as downloading some apt-get ? Unfortunately nvidia only supports ubuntu 18.04 of the deban-live variants
[00:24:05 CET] <BtbN> You just need the propietary nvidia driver, nothing else.
[00:27:49 CET] <barhom> BtbN: I already install the nvidia driver. I also get nvidia-smi
[00:28:04 CET] <BtbN> Then you're good.
[00:28:56 CET] <barhom> Im not sure thats true, lets give it a try to see if it will compile with cuda
[00:29:04 CET] <barhom> compiling with nvenc is fine
[00:31:06 CET] <BtbN> You need clang to compile the cuda filters.
[00:33:01 CET] <BtbN> But there really are no runtime dependencies that go beyond what ships with the driver.
[00:33:23 CET] <barhom> BtbN: My biggest issue was compiling with --enable-cuda and not having to download 2gb of CUDA library
[00:33:31 CET] <barhom> Im doing everything in ram and I want to avoid downloading the whole library
[00:33:36 CET] <barhom> I just found this thanks to you, https://patchwork.ffmpeg.org/patch/14142/
[00:34:50 CET] <BtbN> FFmpeg does not use the CUDA SDK, at all. Only exception being scale_npp, which uses libnpp.
[00:36:05 CET] <barhom> Thats what I am trying to get installed, scale_npp
[00:36:39 CET] <BtbN> And why not use scale_cuda instead, which does not need libnpp?
[00:37:50 CET] <barhom> probably because I do not know about it, it is not mentioned here https://devblogs.nvidia.com/nvidia-ffmpeg-transcoding-guide/
[00:38:27 CET] <barhom> BtbN: scale_cuda, is that the same as "nvcuvid resize"?
[00:38:56 CET] <barhom> I'd like to be able to scale 1:N
[00:39:07 CET] <BtbN> It's a scaler, written in CUDA.
[00:39:23 CET] <BtbN> Not as flexible as npp with all its algorithms, but it gets the job done.
[00:40:31 CET] <barhom> Im compiling with "  --enable-cuda \, --enable-cuvid \, --enable-nvenc \, --enable-nonfree && \" for now.
[00:40:48 CET] <barhom> IsI assume thats enough to have the scaler then
[00:41:01 CET] <BtbN> There is no --enable-cuda. You want --enable-cuda-llvm
[00:41:36 CET] <BtbN> also no --enable-cuvid or --enable-nvenc. And non of it is nonfree anymore.
[00:41:41 CET] <BtbN> You must be using some ancient version.
[00:41:54 CET] <barhom> BtbN: Im compiling myself
[00:42:16 CET] <BtbN> That doesn't change the fact that you must be compiling something ancient if those options still exist.
[00:42:38 CET] <barhom> my best guess is that its just ignoring those options, Im compiling against git
[00:43:00 CET] <barhom> can you recommend me what flags to keep/add of those I pasted?
[00:43:09 CET] <BtbN> Just pass --enable-cuda-llvm and --enable-ffnvcodec then and everything should be enabled.
[00:43:09 CET] <barhom> --enable-cuda-llvm instead of --enable-cuda
[00:43:14 CET] <barhom> remove something else?
[00:43:18 CET] <BtbN> Everything else.
[00:43:25 CET] <barhom> great
[00:43:34 CET] <BtbN> Except other stuff like libx264 and the like of course
[00:43:51 CET] <barhom> yeh
[00:44:05 CET] <barhom> these things should be in the ubuntu compilation guide
[00:44:08 CET] <BtbN> You technically don't even need to pass those, since they are autodetected if the dependencies are found.
[00:44:37 CET] <BtbN> Feel free to put them in there, I don't use Ubuntu.
[00:44:56 CET] <barhom> neither do I, debian here. Just that it seems like thats the goto guide
[00:59:05 CET] <barhom> BtbN: Do you know if ffmpeg can guess the correct nvidia decoder instead of having to specify h264_cuvid or mpeg2_cuvid ?
[00:59:25 CET] <barhom> Makes the whole scripting more complicated if I have to find out what the input codec is
[05:32:43 CET] <montana> why is vorbis rated so high in ffmpeg page
[06:01:03 CET] <pink_mist> what page
[06:01:45 CET] <montana> libopus > libvorbis >= libfdk_aac > aac > libmp3lame >= eac3/ac3 > libtwolame > vorbis > mp2 > wmav2/wmav1
[06:01:48 CET] <montana> that page
[06:02:34 CET] <pink_mist> uh
[06:02:51 CET] <pink_mist> I expected a link
[06:03:15 CET] <pink_mist> I have no clue what page you're trying to point to
[06:05:30 CET] <montana> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
[06:06:45 CET] <pink_mist> alright, I can tell you as much as the author of that section was convinced that libvorbis was the second best quality-wise
[06:07:03 CET] <pink_mist> but vorbis, which you asked about, is not
[06:07:07 CET] <pink_mist> it's almost at the bottom
[06:07:19 CET] <pink_mist> so I think you're confused
[06:07:31 CET] <montana> sorry i meant libvorbis
[06:15:26 CET] <pink_mist> I mean, what kind of reason are you looking for?
[06:15:49 CET] <pink_mist> it's listed in the order of best to worst
[06:15:55 CET] <pink_mist> so it's better than most things
[06:16:02 CET] <pink_mist> at least according to the one who made the list
[06:17:15 CET] <montana> pink_mist if you do 5 pass encoding with vorbis, it sounds horrible
[06:18:18 CET] <pink_mist> lmfao
[06:18:26 CET] <montana> what is funny?
[06:18:36 CET] <pink_mist> what do you think?
[06:18:45 CET] <pink_mist> doing more than one pass is idiotic
[06:18:50 CET] <montana> no it's not
[06:18:55 CET] <pink_mist> yes. yes it is.
[06:19:05 CET] <montana> 5 pass is realitic
[06:19:15 CET] <pink_mist> no, that's amazingly stupid
[06:20:03 CET] <montana> everytime you upload video/audio to youtube, it transcode again
[06:20:15 CET] <pink_mist> yes, which is why you shouldn't do that
[06:20:19 CET] <montana> it doesn't do bypass video/audio
[06:20:27 CET] <pink_mist> doing that is idiotic
[06:20:33 CET] <montana> so what if i downloaded a youtube video clip and edit and re upload it
[06:20:44 CET] <montana> that's 2 pass
[06:20:53 CET] <montana> actually 3
[06:21:16 CET] <pink_mist> you should always use lossless stuff when you're editing things
[06:21:19 CET] <montana> that's 3 pass already in that scenario
[06:21:50 CET] <montana> it's not realistic to do lossless (especially for video)
[06:22:16 CET] <pink_mist> that's why people who want things to look good need high-end computers
[06:22:30 CET] <pink_mist> if you don't do things losslessly as much as possible, it will look like utter shit
[06:22:53 CET] <pink_mist> but for audio, even a regular computer should be able to handle lossless stuff without any problem
[06:23:24 CET] <montana> ask youtube then for why transcoding audio
[06:23:30 CET] <montana> everytime you upload
[06:23:56 CET] <pink_mist> why should I? I know perfectly well why youtube does that.
[06:24:09 CET] <pink_mist> that doesn't mean that what they're doing will result in good quality
[06:24:47 CET] <montana> my point is multiple pass is very realistic situation
[06:25:02 CET] <pink_mist> and my point is that if you do multiple passes you get shit
[06:25:26 CET] <montana> pink_mist  opus still sounds good after 20 pass
[06:25:40 CET] <montana> [20:35] <montana> after doing 20 pass,  opus sounds still pretty good, how is opus so good  where vorbis is horrible
[06:25:40 CET] <montana> [20:51] <+jmspeex> montana: With Opus, if you don't crop of anything, the frames stay aligned, whereas with Vorbis they don't (because transients are handled differently)
[06:25:40 CET] <montana> [20:52] <+jmspeex> If to were to randomly add/remove a few ms at the beginning, Opus and Vorbis would likely sound more similar
[06:25:41 CET] <pink_mist> yeah, that's probably why opus is at the front of the list
[06:27:09 CET] <Bugz000> *sips tea* i don't believe any "lossy" compression should be used in this day and age
[06:27:28 CET] <pink_mist> especially not while you're editing
[06:27:33 CET] <Bugz000> absolutely
[06:27:34 CET] <Reinhilde> there are places
[06:27:46 CET] <montana> Bugz000 for music yes,  but what about  radio/talk podcast? you don't need lossless
[06:27:55 CET] <pink_mist> if you're editing, yes you do
[06:27:55 CET] <Reinhilde> but not in archival or editing
[06:28:23 CET] <montana> i use nothing but lossless for high quality music
[06:28:35 CET] <montana> but not for  radio/podcast content
[06:29:14 CET] <Bugz000> montana you need quality to be maintained regardless of how many times it's put through an editor.
[06:30:23 CET] <montana> bugz even  32kbps mono is enough for podcast content
[06:30:54 CET] <montana> lossless is like 700kbps
[06:30:55 CET] <Bugz000> i'm sure it is
[06:31:02 CET] <Bugz000> lossless doesn't imply high data rate
[06:31:09 CET] <Bugz000> lossless simply means no loss of existing data
[06:31:17 CET] <pink_mist> you should just get the damned transcript and have some text-to-voice thing read it out for you, that way it'll be like 15 bytes/sec
[06:31:29 CET] <Bugz000> half the images and videos you see online have been compressed by so many different algorithms from different sites it's an absolute mess...and i hear it in audio on videos too, specially when music is played, lossless compression across all media will stop this
[06:31:51 CET] <montana> pink_mist lol i care about people's emotion/accent/etc
[06:33:55 CET] <Bugz000> for distribution online i understand lossy compression, i mean youtube lose literally billions of dollars a year on youtube, it's a complete money pit for them, in power, bandwidth, and storage costs
[06:34:10 CET] <Bugz000> so if they can shave off even 50mb from each video that's monumental for them, but for editing, lossless pls.
[06:34:26 CET] <montana> youtube loses money?
[06:34:52 CET] <Bugz000> google can soak it, but yes, youtube is a money pit atm, source? a friend who works there
[06:35:09 CET] <montana> then why are there so many youtube like sites out there
[06:36:11 CET] <Bugz000> they also don't have to handle the couple hundred terabytes of data uploaded to their systems daily
[06:36:22 CET] <Reinhilde> montana: lossless could be as low as 400kb/s
[06:36:37 CET] <Reinhilde> for mono 48khz
[06:36:54 CET] <pink_mist> I mean, the transcript idea is actually lossless too :P
[06:37:16 CET] <pink_mist> just a different kind of lossless
[06:37:39 CET] <Bugz000> montana if any of those "youtube-like-sites", just for an hour, took the load that the youtube infrastructure takes on, they'd be overloaded in an instant rofl
[06:38:47 CET] <Bugz000> funnily enough the closest thing to youtubes infrastructure is likely pornhub hahaha
[06:38:52 CET] <Reinhilde> Bugz000: that's the whole point, having multiple of these sites, ideally with higher barriers to entry, to take the load off of any single
[06:39:02 CET] <montana> Bugz000 is that mean pornhub loses money too?
[06:39:34 CET] <Bugz000> nah, sex sells better than "Jason building a box-steel gokart in his moms garage"
[06:41:37 CET] <Bugz000> Reinhilde sadly people are lazy and like a one-place solution, people feel comfortable with "household name" brands, i figure this is why google have youtube, they saw it's potential, idk if you're a member of the youtubers union but you should join, tons of info about what youtube are up to
[06:42:15 CET] <Bugz000> they recently released a new clause, in a super simplified way saying; if a video doesn't bring in revenue, youtube will delete it at their own discretion
[06:42:41 CET] <Reinhilde> which is basically the end of youtube as it has ever existed
[06:42:47 CET] <Bugz000> they're heading to be the next netflix i think
[06:42:57 CET] <Bugz000> yeah pretty much, the union is going nuts rofl
[06:43:27 CET] <Reinhilde> i'm in canada, how do i join the syndicat des youtubeurs
[06:43:28 CET] <montana> Bugz000 netflix is losing money too?
[06:43:38 CET] <Bugz000> i mean i get it though, from their perspective, already losing money, hosting literal billions of hours of useless, sometimes 4k video, which is earning them nothing is literally where the money is going
[06:43:39 CET] <Reinhilde> (i don't know if i used the right word)
[06:43:58 CET] <Bugz000> montana, at nearly £10 a month for maybe 200 movies? i don't think so
[06:44:20 CET] <Bugz000> https://youtubersunion.org/
[06:44:32 CET] <Bugz000> https://www.facebook.com/groups/youtuberunion/
[06:44:47 CET] <Bugz000> https://www.youtube.com/user/JoergSprave
[06:45:29 CET] <Bugz000> Jorgsprave with the union, Fairtube, is in works with IG METALL which is the oldest and largest trade union in the world
[06:45:55 CET] <Bugz000> they are trying to force youtube to play by the rules
[06:47:37 CET] <Bugz000> watch all the fairtube videos, it explains why people aren't moving to new platforms, whats going on, what needs to change so on so on
[06:48:16 CET] <Bugz000> but yah, youtube ARE losing money with youtube, hence why Youtube Red started, and now they're trying to hack down the "free content" and migrate everyone to "red" members rofl
[06:48:43 CET] <Bugz000> google are losing money with youtube*
[06:49:16 CET] <pink_mist> <Bugz000> Jorgsprave with the union, Fairtube, is in works with IG METALL which is the oldest <-- looking at wikipedia, it seems to have been foundedin 1949, while LO, which is a swedish union was founded in 1898
[06:49:29 CET] <Bugz000> oh, maybe its the oldest in germany then
[06:49:43 CET] <Bugz000> nice tho :D 1898 jesus
[06:51:18 CET] <Bugz000> funny story, the other day my friend (works on the frontpage of google/youtube) made a bad query across the google dev network, crashed part of youtube, then the flood of people rushing to google to search "youtube not working" then crashed google for several areas
[06:51:21 CET] <Bugz000> lool
[06:51:33 CET] <pink_mist> lol
[06:52:12 CET] <Bugz000> the gods of the internet are mortal after all
[06:52:28 CET] <Bugz000> just requires 1/4 of the global population to simultaneously google something
[06:54:19 CET] <Bugz000> https://www.facebook.com/groups/youtuberunion/permalink/861266717602632/
[06:54:33 CET] <Bugz000> here's a post regarding the changes to youtube (deleting non-profitable videos)
[06:57:32 CET] <SpiritHorse> 'force youtuve to play by the rules' -- hah!
[06:58:35 CET] <SpiritHorse> youtube doesn't owe anyone a damn thing.  if anything quite the opposite.
[06:59:17 CET] <Bugz000> actually the moment they had people sign a partnership agreement is the moment they should start acting like an employer
[06:59:27 CET] <Bugz000> it's clearly stated in EU law, they've broken several, rofl
[07:00:23 CET] <Bugz000> if they didn't want to owe anyone anything then they shouldn't have started paying creators
[07:02:10 CET] <Bugz000> and then they shouldn't have started demonetising creators videos yet still show their own adverts on someone elses work
[07:04:03 CET] <Bugz000> (that said i've not seen a single advert in over a decade due to 2 layers of ad/tracker/script blocking so i'm just a thief really :p )
[07:04:12 CET] <Bugz000> 3 layers sorry
[07:04:26 CET] <Bugz000> Brave, UBO and pihole <3
[07:04:51 CET] <SpiritHorse> they aren't employees
[07:05:00 CET] <SpiritHorse> so they won't and will never be treated like ones
[07:05:30 CET] <Bugz000> brave is the newest addition after google made noises about making DNS requests an API rather than raw requests so they can keep a table that has 2000 entries you can alter, and that's it, with the aim to kill ad blockers....
[07:06:43 CET] <Bugz000> they aren't employers, but they qualify in every way to BE employers, ergo, just because they say they aren't employers doesn't mean they aren't employers, ergo, they are in breach of EU law and IG METALL is threatening to come down on them like a legal ton of bricks , but will ask to play nice first
[07:07:00 CET] <Bugz000> it's in the videos dude go watch them
[07:07:07 CET] <Bugz000> i'm not going to sit and type it all out for you rofl
[07:08:00 CET] <SpiritHorse> right, and this is not a very original argument against YT
[07:08:10 CET] <SpiritHorse> it has been tried against YT and lots of other megacorps and they all fail
[07:08:55 CET] <SpiritHorse> and no, I'm not going to watch a video seething with bias about how pissed off someone is the internet isn't their personal piggy bank
[07:09:02 CET] <Bugz000> https://www.youtube.com/watch?v=oZZ5Kouj_hQ
[07:09:27 CET] <Bugz000> it's not bias, it's a partnership with a huge trade union's legal team rofl
[07:09:32 CET] <Bugz000> watch that, enjoy
[07:09:41 CET] <SpiritHorse> it's like the DoorDash people who want to be "employees".  yeah, no.
[07:09:54 CET] <Bugz000> watch the video and get back to me :)
[07:11:37 CET] <bugz000|afk> pink_mist oh IG metall is the largest independant trade union on the planet
[07:11:38 CET] <bugz000|afk> thats it
[07:11:39 CET] <bugz000|afk> haha
[07:11:51 CET] <SpiritHorse> Google probably has a team of people who deal with this nonsense
[07:11:59 CET] <SpiritHorse> https://www.cnet.com/news/the-youtubers-union-is-demanding-change-thats-nothing-new-for-google/
[07:12:20 CET] <SpiritHorse> seems like they are well versed in getting hit with baseless threats/lawsuits/etc and can handle it quite well *shrug*
[07:14:40 CET] <bugz000|afk> SpiritHorse https://youtu.be/oZZ5Kouj_hQ?t=477
[07:16:13 CET] <bugz000|afk> brb :)
[11:11:34 CET] <BtbN> barhom, just don't use cuvid anymore, it's effectively deprecated. The native hwaccel nvdec is preferred.
[12:04:21 CET] <montana> what is the link for  #ffmpeg and #ffmpeg channel logs
[12:04:24 CET] <montana> i forgot the link
[12:07:07 CET] <montana> what is the link for  #ffmpeg and #ffmpeg-dev channel logs
[12:07:33 CET] <montana> what is the link for  #ffmpeg and #ffmpeg-devel channel logs
[12:10:36 CET] <pink_mist> https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/
[12:17:55 CET] <montana> pink_mist thanks
[12:19:36 CET] <barhom> BtbN: Why do I have to use hwupload_cuda before I hit "scale_cuda" in my "-vf" filter? I thought decoding with -hwaccel means packets stay in GPU memory
[12:20:03 CET] <barhom> that is only the case with "-hwaccel nvdec/cuda". When I use "-hwaccel cuvid" I do not need to use hwupload_cuda
[12:20:47 CET] <BtbN> barhom, unless you set the hwaccel_output_format to cuda, it will download the frames.
[12:20:59 CET] <barhom> also thanks for the llvm tip yesterday, I managed to get scale_cuda to work!
[15:36:18 CET] <Radiator> Hi everyone !
[15:37:47 CET] <Radiator> I'm doing a zero latency decoder using ffmpeg libs in C++. It works wonderfully, problem is that once I try 4k it all crashes and there's definitely latency
[15:38:16 CET] <BtbN> You easily run out of RAM with 4K stuff
[15:39:45 CET] <Radiator> I have 32GB and I'm doing OK in terms of percentages
[15:40:15 CET] <BtbN> And your CPU usage?
[15:40:24 CET] <Radiator> I'm around 20%
[15:40:35 CET] <BtbN> You only have one core?
[15:40:36 CET] <Radiator> But I'm using HWacceleration
[15:40:43 CET] <Radiator> No I have 4 cores
[15:40:52 CET] <BtbN> so 20% could be close to 100% on one core
[15:40:52 CET] <Radiator> It's a i7
[15:41:22 CET] <Radiator> Correct
[15:44:56 CET] <Radiator> I'm using the graphic correct to decode. I don't understand why VLD would work quite nice compared to my implementation whose 4/5 seconds behind
[16:12:43 CET] <Anderssen> Hey guys, can ffmpeg produce an output like a diagram (or a table) which shows the bitrate of a video file, like x-axis: time, y-axis: bitrate?
[16:31:29 CET] <Hello71> ffprobe -show_packets | something | dot
[16:36:39 CET] <nicolas17> dot?
[16:37:57 CET] <furq> https://manpages.debian.org/buster/graphviz/dot.1.en.html
[16:38:11 CET] <nicolas17> how would that help with an x-y chart?
[16:42:31 CET] <Radiator> Regarding my issue, here is a log from ffmpeg libs : https://pastebin.com/N6b8LEE2
[16:43:09 CET] <Anderssen> Hello71: show_packets seems to be a good start; although the output is like 10% size of the video file ;)
[16:45:44 CET] <Anderssen> although one can do something with "grep size" and "grep duration"
[16:45:48 CET] <furq> Anderssen: ffprobe -select_streams v:0 -show_entries packet=size -of default=nk=1:nw=1 foo.mkv
[16:46:56 CET] <furq> or -show_entries packet=size,duration -of csv
[16:50:13 CET] <Anderssen> furq: that's pretty good, thanks
[17:35:04 CET] <Radiator> Do you guys have an idea how to handle rtsp stream better than specifying ```rtsp_transport tcp``` ?
[17:36:28 CET] <JEEB> that depends on the rtsp stream
[17:37:45 CET] <Radiator> It's a 4K camera
[18:38:56 CET] <Pinhole> I'm encoding for live hls streaming.  Works fine on pc, but android chrome shows the video garbled and green.  Anyone seen this and have a fix?
[18:39:00 CET] <Pinhole> ffmpeg -re -i source.mp4 -c:v h264 -flags +cgop -c:a aac -hls_allow_cache 0 -hls_time 10 -hls_list_size 0 -hls_flags second_level_segment_duration -use_localtime 1 -strftime 1 -hls_segment_filename 'live/live.%08s.%%08t.ts' -f hls 'live/live.m3u8'
[18:39:21 CET] <JEEB> Pinhole: you leave awfully a lot of stuff unspecified
[18:39:29 CET] <JEEB> including which H.264 encoder is being utilized
[18:39:43 CET] <JEEB> also you don't make sure that the format is something that hardware decoders can take
[18:39:48 CET] <JEEB> as in, output format
[18:39:59 CET] <JEEB> please post the log in a pastebin or so, preferably with -v verbose or something
[18:47:49 CET] <Pinhole> https://paste.centos.org/view/fa9525f4
[18:49:09 CET] <JEEB> that should work. 4:2:0 YCbCr
[18:49:11 CET] <JEEB> 720p
[18:49:24 CET] <JEEB> and high profile, level 3.1
[18:49:42 CET] <kurosu> Some very old Android devices do not support "high" profile, but would then simply refuse to play
[18:49:47 CET] <JEEB> true
[18:49:54 CET] <kurosu> level should be ok if high is supported
[18:49:58 CET] <kurosu> it's not that extreme
[18:49:58 CET] <JEEB> -profile:v main
[18:50:03 CET] <JEEB> yea
[18:50:07 CET] <JEEB> definitely not extreme
[18:50:16 CET] <JEEB> I'd expect most stuff be able to do level 4
[18:50:23 CET] <JEEB> main|level 4
[19:17:35 CET] <Pinhole> I've experimented now with -profile:v main -level 3.1 and  -profile:v baseline -level 3.0.  Seems to still not be happy.
[19:18:35 CET] <JEEB> dunno. try android exoplayer and its debug logging
[19:18:55 CET] <JEEB> I couldn't see anything specifically wrong with the encoding settings and I'm way too tired to see the HLS related options
[19:25:01 CET] <ChocolateArmpits> Pinhole, set -bf 2
[19:25:16 CET] <ChocolateArmpits> I think the default is 3 frames which can cause problems
[19:26:04 CET] <ChocolateArmpits> I mean I had browser rendering problems with that
[19:27:43 CET] <Pinhole> still green
[19:27:52 CET] <ChocolateArmpits> welp
[19:28:30 CET] <ChocolateArmpits> oh you set baseline before, figures why then this wouldn't work
[21:26:01 CET] <montana> okay it was mkver
[22:32:42 CET] <arnaud-ro> hi
[22:33:18 CET] <arnaud-ro> any idea why  while restreaming some hls stream that have splitted audio video segments , ffmpeg is remuxing them but then the resulting stream has audio/video non synced
[23:43:37 CET] <void09> is there any flag/switch to make it select the nearest keyframe so that it always includes the given timestamp ? right now the default is just nearest, which can leave some frames out if i give it a precise timestamp
[00:00:00 CET] --- Sat Nov 16 2019