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

[burek]

[00:01:19 CEST] <TwinTailed> flux: that has to do with EOF? ^
[00:02:13 CEST] <flux> perhaps
[00:03:00 CEST] <flux> you could ie. dump both those audio tracks and compare in audacity if it's the last frame that's missing. I guess it likely is.
[00:03:11 CEST] <flux> audacity or an audio editor of your choice
[00:03:17 CEST] <TwinTailed> flux: did u see the state machine code? its exacly 70 lines in total
[00:04:07 CEST] <TwinTailed> flux: how do i dump audio as WAV or MP4 using ffmpeg cli?
[00:05:13 CEST] <flux> ffmpeg -i foo.mp4 -map 0:1 foo.wav perhaps if audio is stream id 1
[00:06:26 CEST] <TwinTailed> flux: on my video, it says [mov,mp4,m4a,3gp,3g2,mj2 @ 01dc1780] moov atom not found
[00:06:49 CEST] <TwinTailed> flux: invalid data found when processing input
[00:06:59 CEST] <flux> well, that's a broken file.
[00:07:08 CEST] <TwinTailed> flux: isn't ffmpeg libav supposed to be the one dealing with atoms/boxes?
[00:07:16 CEST] <flux> how did you get all those dump_streams work with that?
[00:07:45 CEST] <TwinTailed> flux: they just worked it seems
[00:07:53 CEST] <flux> and what is giving that error?
[00:08:06 CEST] <TwinTailed> flux: nvm
[00:08:25 CEST] <TwinTailed> flux: it seems i have ctrl+c while transcoding
[00:08:46 CEST] <TwinTailed> flux: so there exists a 700kb file :P my bad
[00:09:18 CEST] <TwinTailed> flux: done, will compare them now
[00:10:20 CEST] <flux> so it seems your code keeps sending avcodec_send_packet(pC[pkts->stream_index], NULL); in state 1
[00:10:41 CEST] <flux> I don't know if that's harmful, but certainly it's not required. it's expected yo send the NULL exactly once.
[00:11:25 CEST] <flux> and after determining the stream is in EOF state you should stop reading from it
[00:13:33 CEST] <TwinTailed> flux: https://s22.postimg.org/um4uu62m9/lastframe.png
[00:13:44 CEST] <TwinTailed> flux: audacity screenshot, seems last frame is missing
[00:13:53 CEST] <flux> maybe you should do these tests with much shorter files, like 3 frames, so you can step it through manually and see that it works as you expect..
[00:14:26 CEST] <TwinTailed> flux: as if i know how to hexedit atoms :P
[00:14:46 CEST] <flux> you could use ffmpeg to make a shorter test file..
[00:24:05 CEST] <TwinTailed> flux: For encoding, call avcodec_receive_packet(). On success, it will return an AVPacket with a compressed frame. Repeat this call until it returns AVERROR(EAGAIN) or an error.
[00:24:13 CEST] <TwinTailed> flux, thats from the doxygen doc
[00:24:21 CEST] <TwinTailed> flux: what does it mean?
[00:28:29 CEST] <flux> it has a special mention about AVERROR_EOF in the text describing its use
[00:28:50 CEST] <TwinTailed> flux: read that long ago
[00:29:15 CEST] <flux> so I'm not quite sure what you are asking.. seems pretty clear to me?
[00:29:21 CEST] <flux> on success, it will return a frame
[00:29:25 CEST] <flux> hmm, a packet that is
[00:29:33 CEST] <flux> and if it returns EAGAIN, it has no data
[00:29:35 CEST] <TwinTailed> what does it mean "repeat this call"
[00:29:56 CEST] <flux> for example in a while loop
[00:30:12 CEST] <flux> I don't believe it's essential to do it right away, but it's probably helpful for performance
[00:30:29 CEST] <TwinTailed> oh
[00:32:31 CEST] <TwinTailed> flux: might [libx264 @ 01f9d940] forced frame type (3) at 2045 was changed to frame type (1) warning be the cause?
[00:32:37 CEST] <TwinTailed> many of those warnings
[00:33:57 CEST] <trueroll> hi can anyone tell me how to configure to build with clang?  it looks for g++ and fails (cause it's clang++)
[00:34:34 CEST] <c_14> --cc=clang --cxx=clang++
[00:34:36 CEST] <c_14> probably
[00:34:41 CEST] <flux> twintailed, no, because they come from the video codec, not the audio codec
[00:34:54 CEST] <TwinTailed> flux: yeah, true
[00:34:59 CEST] <trueroll> @c_14 I'll try that real quick
[00:38:02 CEST] <trueroll> hmm now I'm getting a different error but it's using the right compiler now thx
[00:39:24 CEST] <TwinTailed> flux: have u got anything for me to try to fix this missing frame from audio stream?
[00:46:12 CEST] <trueroll> ah darn, still fails the C compiler test
[00:48:01 CEST] <trueroll> oh the config.log has errors in it
[00:50:31 CEST] <trueroll> is CPU=armv7-a invalid?
[00:51:49 CEST] <trueroll> sorry I mean -march=armv7-a
[00:52:56 CEST] <flux> twintailed, I suggest you log each invocation of your functions, keep track of the number of frames processed per track, and see where the discrepancy comes from
[00:53:10 CEST] <flux> twintailed, I mean, in the end it means you write one audio track frame too ltitle to the file
[00:53:30 CEST] <TwinTailed> flux: will do, thanks for your time :)
[00:53:51 CEST] <TwinTailed> trueroll: are using a raspberry pi or an ARM device?
[00:54:19 CEST] <TwinTailed> trueroll: if you are using a normal pc, then yes using -march=armv7 is invalid
[00:54:39 CEST] <trueroll> I'm cross compiling from mac to android (arm)
[00:54:46 CEST] <TwinTailed> ah
[00:54:58 CEST] <TwinTailed> then its ok
[00:55:02 CEST] <TwinTailed> but what are the errors?
[00:55:11 CEST] <trueroll> error: unknown target CPU 'armv7-a'
[00:59:09 CEST] <trueroll> take a look? http://pastebin.com/yMRDe8t3
[01:04:57 CEST] <TwinTailed> trueroll: CLang supports armv7, so i don't know why its failing
[01:05:45 CEST] <trueroll> hmm
[01:06:47 CEST] <TwinTailed> trueroll: shouldnt u use ./configure before make?
[01:08:11 CEST] <TwinTailed> trueroll: https://github.com/taka-no-me/android-cmake/issues/1
[03:42:46 CEST] <Keridos> is it normal if I convert a RGB x264 video to x264 with yuv444p it has normal colors (like the original had) but if I select yuv420p the colors change dramatically?
[03:43:18 CEST] <Keridos> even if I upscale the video I can clearly see a difference, but upscaling should completely remove the subsampling loss
[03:59:49 CEST] <klaxa> Keridos: even with yuv444p it is ever so slightly different
[04:00:12 CEST] <klaxa> the answer is yes, this is normal, rgb <-> yuv conversion is not lossless
[04:00:24 CEST] <klaxa> they store information quite differently
[04:06:49 CEST] <Keridos> yuv444p looks very good though
[04:07:13 CEST] <Keridos> but yuv420 looks weird although I almost doubled the resolution and it downscales on my screen
[04:07:34 CEST] <Keridos> technically it should look almost like the 444 output when downscaled
[04:18:24 CEST] <TwinTailed> Keridos: Many video players only support yuv420p, so if compatibility is a concern, use 420p
[04:19:14 CEST] <Keridos> twintailed, I am testing uploading to youtube
[04:19:36 CEST] <Keridos> apparently auv444 uploads are much better in color than my own yuv420p tests
[04:19:57 CEST] <Keridos> my own tests had a brighter appearence
[04:20:20 CEST] <Keridos> interestingly I guess that youtube *should* automatically convert to yuv420p
[04:21:06 CEST] <Keridos> so my best guess is that when I convert to yuv420p and scale the video it seems to first do the color conversion then the scaling
[04:21:48 CEST] <Keridos> if it was the other way round i should technically see almost no difference since afaik yuv444p and yuv420p just decrease the resolution of the colors in pixels, not the color range itself
[05:48:42 CEST] <Keridos> is there any good free video editing software for 4k 60fps yuv444 workflow?
[06:16:11 CEST] <Keridos> ah i finally got the yuv420p stuff upscaled to look fine
[06:51:07 CEST] <jesseg> Hmmm.. slackware linux 64, 14.2.. How do I get ffmpeg to register in pkg-config when I build/install it?
[06:55:40 CEST] <Keridos> that sounds like it belongs in the slackware linux channel tbh
[06:56:09 CEST] <furq> by ffmpeg do you mean libavcodec etc
[06:56:11 CEST] <furq> there is no ffmpeg.pc iirc
[07:03:56 CEST] <jesseg> furq, Keridos yeah I'm trying to build something that needs to find libavformat via pkg-config
[07:04:38 CEST] <jesseg> ffmpeg builds, installs, and runs, but does not seem to be found in pkg-config
[07:04:59 CEST] <jesseg> so other apps that need libavformat can't find it
[07:05:41 CEST] <furq> do you have anything under $PREFIX/lib/pkgconfig
[07:06:37 CEST] <jesseg> 358 files which seem to end in the name .pc
[07:06:59 CEST] <jesseg> one of which is libavformat..
[07:07:02 CEST] <jesseg> .pc
[07:07:02 CEST] <orge> i want to split h264 video without recording, as close as possible to some desired time points. so is it possible to do something like search for all keyframes, get the best pair for my desired video section (i'm assuming ffmpeg doesn't do this - i would), then split the video based on those keyframes?
[07:07:22 CEST] <orge> s/recording/reencoding/
[07:09:56 CEST] <jesseg> furq, so maybe my pkg-config is just broken?
[07:10:52 CEST] <furq> maybe the default pkg-config path is different on slackware
[07:11:54 CEST] <furq> what do you get if you just run `pkg-config --libs libavcodec`
[07:12:55 CEST] <jesseg> furq, hmmm, you know what, I have a /usr/lib and a /usr/lib64, and PKG_CONFIG_PATH  lists only /usr/lib64 while libavformat.pc is in /usr/lib/pkgconfig/
[07:13:01 CEST] <jesseg> so I bet that's my problem
[07:13:23 CEST] <furq> PKG_CONFIG_PATH is normally unset, although idk how slackware does things
[07:13:29 CEST] <furq> but yeah you should just be able to add /usr/lib to it
[07:13:42 CEST] <jesseg> I probably got a slight scramble when I set up for 32/64 bit program support
[07:14:42 CEST] <jesseg> furq, ha! Now it's listing (Added it to path.) Thanks!
[07:16:18 CEST] <furq> orge: i'm pretty sure ffmpeg just cuts at the closest keyframe to the specified time
[07:24:21 CEST] <jesseg> furq, How can I compile libavcodec (and all of ffmpeg's libraries) with -fPIC? mlt seems to need it.
[08:19:38 CEST] <furq> jesseg: you probably just want --enable-shared
[09:46:10 CEST] <orge> mkv containing audio, video, and subtitles are inputted. `ffmpeg -ss 40 -i in.mkv -t 5 -map 0 -c copy out.mkv` is the command. output is then ~20s of nothing followed by the 5s region i'm looking for. it's not because the video or audio keyframes are that far back though, it seems to because the last subtitle
[09:46:36 CEST] <orge> was about 20s ago. this seems like strange behavior
[09:51:55 CEST] <orge> (the subtitle from 20s ago doesnt persist into the region where the audio/video starts and if i just map audio and video then i get what i want) how can i fix this?
[11:13:55 CEST] <Snicksie_> hi all, I'm trying to convert some videos from x265 to x264, but the resulting quality is not satisfiable at all (crf=23). Can I find out from existing videos (from another source, that I only have in x264) what their crf value is, so I can use that same value for my x265 videos?
[11:14:44 CEST] <furq> mediainfo will show you
[11:14:51 CEST] <furq> just use 18-20 though
[11:15:14 CEST] <furq> 23 is quite low even for hd stuff
[11:17:15 CEST] <Snicksie_> allright, I'll take a look at mediainfo :)
[11:21:24 CEST] <Snicksie_> nice thanks, that works furq :)
[11:57:35 CEST] <Snicksie> so I tried to convert a video once more with crf=18, but the quality is still as bad as ever... even with a crf of 10 or lower there's no difference... is there anything wrong in the way I execute ffmpeg? :)
[11:57:53 CEST] <Snicksie> ffmpeg -i $i -c:s copy -crf 18 -c:a copy $newname
[11:59:36 CEST] <Snicksie> filesize doesn't seem to change depending on the crf, which is also unexpected
[12:02:09 CEST] <furq> what's $newname
[12:02:25 CEST] <furq> if it's not a container which defaults to x264 then you need to specify -c:v libx264
[12:04:03 CEST] <Snicksie> $newname is something.mkv, but your right, aparently the output format is Format settings, Matrix                  : Default (H.263)
[12:04:11 CEST] <Snicksie> that seems incorrect
[12:04:59 CEST] <furq> matroska should default to x264
[12:05:49 CEST] <furq> there's no harm in specifying though
[12:06:54 CEST] <Snicksie> that resulted in Unknown encoder 'libx264'
[12:07:27 CEST] <furq> your ffmpeg wasn't built with libx264 then
[12:08:28 CEST] <Snicksie> yeah, I'll rebuild, as soon as I find where I compiled it last time :p
[12:10:15 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[12:10:18 CEST] <furq> just use that if you're on linux
[12:13:44 CEST] <Snicksie> apparently last time I used the git repo, any harm in that? :p
[12:14:18 CEST] <Snicksie> ah this one is as well, seems perfect
[12:14:19 CEST] <furq> if you really want to compile it yourself then sure
[12:14:28 CEST] <furq> but unless you need some weird libs then those static builds are pretty much fine
[12:16:34 CEST] <Snicksie> allright, that seems to be reencoding slower, so I hope this will give me the quality I've been looking for :)
[12:20:53 CEST] <Snicksie> thanks, quality looks great so far!
[12:32:03 CEST] <markvandenborre> does anyone know about ways to accelerate vp9 encoding significantly
[12:32:30 CEST] <markvandenborre> from the standard "throw a file at the libvpx encoder" method?
[12:32:37 CEST] <markvandenborre> that one is horrendously slow
[12:34:37 CEST] <markvandenborre> if possible, we would like to offer vp9 streaming of our FOSS conference
[12:35:04 CEST] <markvandenborre> but it looks as if nothing much comes even close to allowing that
[12:35:34 CEST] <markvandenborre> there's a recent mali gpu that offers hardware acceleration, but no FOSS support for that
[12:35:50 CEST] <markvandenborre> and few others seem to do it
[12:37:18 CEST] <markvandenborre> the only option I could think of would be an experiment with somewhat delayed streaming
[12:37:55 CEST] <markvandenborre> where one could put multiple cores to work by feeding them slices
[12:38:11 CEST] <markvandenborre> then cobbling things back together afterwards
[12:38:26 CEST] <markvandenborre> is there any option for that kind of crude peudo-multithreading?
[12:38:29 CEST] <markvandenborre> in ffmpeg?
[12:39:16 CEST] <markvandenborre> or am I thinking stupid things?
[12:58:03 CEST] <markvandenborre> is there anything better for vp8?
[13:17:43 CEST] <ChocolateArmpits> markvandenborre: new line of intel processors support hardware encoding
[13:19:38 CEST] <ChocolateArmpits> Simple slicing won't work as you can't just simply combine encoded frames afterwards
[13:19:48 CEST] <ChocolateArmpits> I mean parts of a frame
[13:19:51 CEST] <furq> the intel vp9 stuff is only partially accelerated afaik
[13:20:03 CEST] <furq> but you can use sliced multithreading with libvpx
[13:21:51 CEST] <furq> markvandenborre: use -tile-columns and -threads
[13:22:10 CEST] <furq> -tile-columns 2 -threads 4 is recommended for 720p and 1080p according to an old mailing list post
[13:22:46 CEST] <furq> you lose a bit of encoding efficiency but it should be much faster (which shouldn't be difficult)
[13:23:15 CEST] <radia> What do I write if i don't want to use VP9? I want to use VP8 instead.
[13:23:22 CEST] <furq> -c:v libvpx
[13:23:39 CEST] <furq> or -c:v vp8 might work these days
[13:25:20 CEST] <furq> markvandenborre: there's also -speed which is something like x264 -preset
[13:25:27 CEST] <furq> -speed 4 is the fastest, 0 is the slowest
[13:26:35 CEST] <ChocolateArmpits> Do these options while increasing speed not throw the video quality down to the stone age?
[13:26:49 CEST] <furq> they sure do
[13:29:37 CEST] <furq> well, -speed does
[13:29:49 CEST] <furq> sliced multithreading isn't that bad
[13:32:28 CEST] <markvandenborre> furq: ChocolateArmpits : thanks a lot
[13:32:35 CEST] <markvandenborre> will experiment with those!
[13:37:21 CEST] <furq> -speed 4 actually looks pretty much fine with -crf
[13:37:39 CEST] <furq> i'm guessing this is going to be mostly static shots of guys standing awkwardly near laptops
[13:38:18 CEST] <furq> explaining why enlightenment 17 is actually good and not bad like you thought it was
[13:47:05 CEST] <markvandenborre> heh, this is about https://fosdem.org
[13:47:27 CEST] <markvandenborre> so some of the developers behind that project might be there, yes :p
[13:49:53 CEST] <ritsuka> you should fund a FOSS  conference to speed up vp9 ;)
[13:50:04 CEST] <markvandenborre> and not a lot of changes in camera view expected
[13:50:24 CEST] <markvandenborre> ritsuka: there is an actual open media devroom at fosdem
[13:50:52 CEST] <markvandenborre> so the joke is not as far fetched as you would think :-)
[13:53:08 CEST] <markvandenborre> I know that for h264, there are some projects that do hardware acceleration with dedicated c66x asicswith a FOSS patch to ffmpeg
[13:53:26 CEST] <markvandenborre> just making sure noone knows about anything like that for vp8 or vp9?
[13:58:05 CEST] <markvandenborre> we have a few rather powerful servers, but they're mostly powerful due to them beingr quad hexacore multithreaded...
[14:04:29 CEST] <Mavrik> markvandenborre, libvpx should have a speed option for both VP8 and VP9
[14:04:38 CEST] <Mavrik> which kinda determines CPU usage vs. quality
[14:04:49 CEST] <Mavrik> tweaking that should at least get you to 30fps on a decent quad core
[14:05:11 CEST] <furq> 25, you mean
[14:06:55 CEST] <Mavrik> Whatever he's targeting.
[14:17:59 CEST] <PannenkoekenNL> How do I set the language of audio stream 1 to Chinese (chi) and audiostream 2 to Malay (may) for 150 .mp4 files in one folder?
[14:29:24 CEST] <markvandenborre> Mavrik: will have a look
[14:30:05 CEST] <markvandenborre> these machines are rather old (Xeon E7530)
[14:30:14 CEST] <markvandenborre> but they have a lot of cores available
[14:32:38 CEST] <markvandenborre> which is what I was looking to optimise encoding of live streams for
[14:33:18 CEST] <markvandenborre> since we have 24 rooms in parallel, some optimisation effort is warranted...
[14:34:03 CEST] <furq> if you can get tile-columns working then i'd expect you to get 25fps at 720p
[14:35:10 CEST] <markvandenborre> furq: that's exactly what we're targetting
[14:37:07 CEST] <furq> i guess if all else fails you could look for some westmere-ep chips with a higher base clock
[14:37:32 CEST] <furq> actually nvm that's a different socket
[14:38:11 CEST] <markvandenborre> yeah, we're trying to get the most out of the existing hardware
[14:38:23 CEST] <furq> i guess if all else fails you would actually just use h264
[14:38:34 CEST] <markvandenborre> if we can reliably squeeze webm/vp9 out of it, we wil
[14:38:36 CEST] <markvandenborre> l
[14:38:54 CEST] <markvandenborre> otherwise it will be h264 streams and reencoding webm afterwards
[14:39:39 CEST] <markvandenborre> cpu time is ridiculously cheap nowadays
[14:40:06 CEST] <furq> i guess westmere-ex would fit but i bet those are still expensive
[14:40:10 CEST] <furq> westmere-ep stuff is really cheap now
[14:40:26 CEST] <markvandenborre> the problem is mainly that for our solution, we really need the initial encoding to be on site
[14:40:56 CEST] <markvandenborre> and we know we can do the h264 stuff with existing hardware...
[14:41:16 CEST] <markvandenborre> with almost zero expenses for post conference webm reencoding
[15:43:30 CEST] <markvandenborre> furq: so if we would need new hardware, this might be hard to justify
[15:43:48 CEST] <markvandenborre> furq: thx again for your hints
[15:43:50 CEST] <furq> i only suggested upgrading because westmere-ep is really cheap now
[15:44:04 CEST] <furq> i imagine westmere-ex isn't because it's a rarer socket
[15:44:12 CEST] <markvandenborre> k
[15:44:19 CEST] <markvandenborre> will keep that in mind
[15:45:03 CEST] <furq> ep is lga1366 which is no good
[18:53:40 CEST] <Cork> anymore know if there is a program to clean up white buzz from video copied from old vhs tapes?
[18:56:50 CEST] <Spring> Cork, there's probably some AviSynth script for that
[18:57:03 CEST] Action: Spring is afk
[19:06:48 CEST] <Cork> thx, will look
[19:53:03 CEST] <TwinTailed> [libav], when transcoding to h264, i am getting a missing audio frame (last frame)
[19:53:17 CEST] <TwinTailed> i am dealing with EOF correctly I guess
[19:53:33 CEST] <TwinTailed> video frames are all there, just the audio frame is missing
[20:06:10 CEST] <ChocolateArmpits> TwinTailed: Maybe the audio stream lasts longer than the video stream?
[20:06:26 CEST] <ChocolateArmpits> Did you try updating your build of ffmpeg ?
[20:06:48 CEST] <ChocolateArmpits> You can try -longest command, it will encode until the longest stream
[20:06:49 CEST] <orge> it seems that `ffmpeg -ss 40 -i "out5.mkv" -t 5 -map 0 -c:v copy -c:a flac out6.mkv` will have video starting from the closest keyframe before 40s, and audio starting from exactly 40s. is there a way to make the audio seek match the video seek, if that makes sense
[20:07:10 CEST] <TwinTailed> ChocolateArmpits: avformat read_packet should read me all packets, regardless which is more, and i am not looping depending on the number of frames
[20:07:19 CEST] <ChocolateArmpits> orge: Use -ss after the input
[20:07:22 CEST] <TwinTailed> and yes i am using yesterday's build
[20:07:40 CEST] <TwinTailed> ChocolateArmpits: I am using Libav not ffmpeg CLI
[20:07:49 CEST] <TwinTailed> ffmpeg's libav of course
[20:07:52 CEST] <ChocolateArmpits> TwinTailed: sorry can't help with api
[20:09:34 CEST] <orge> ChocolateArmpits, it seems that this changes the behavior so that the video starts at the closest key frame AFTER the specified time, and audio audio still starts at the specified time
[20:10:21 CEST] <ChocolateArmpits> orge: Well then you need to transcode the video frames
[20:10:44 CEST] <orge> ChocolateArmpits, i'm trying to copy video frames and transcode audio, for speed
[20:11:16 CEST] <ChocolateArmpits> You frames copied from a middle of a gop will be garbled on playback
[20:11:21 CEST] <ChocolateArmpits> frames copied *
[20:12:44 CEST] <orge> i'm not trying to copy the video from a specific frame
[20:13:18 CEST] <ChocolateArmpits> So you want the audio to match the video frame ?
[20:13:55 CEST] <orge> yeah, i want the audio frames to be the exact same window as the video frames, which are determined by the keyframes
[20:14:10 CEST] <orge> i feel like this should be possible with transcoded audio, but maybe ffmpeg just doesn't support it?
[20:14:46 CEST] <ChocolateArmpits> They behave separately
[20:15:22 CEST] <ChocolateArmpits> I did something similar a few times, you will have to get the closest keyframe location using ffprobe and then use the time there as the seek point
[20:15:50 CEST] <orge> okay. can you throw some helpful commands my way? :p
[20:21:27 CEST] <ChocolateArmpits> orge: hmm before anything, try -async 1
[20:23:54 CEST] <ChocolateArmpits> it -should- cut off audio frames at the very start
[20:24:01 CEST] <ChocolateArmpits> Haven't tested it
[20:25:10 CEST] <orge> doesn't seem to do anything at all. according to the docs "This option has been deprecated. Use the aresample audio filter instead. "
[20:28:57 CEST] <orge> but it stretches/squeezes instead of cutting, so i'm gonna go with the ffprobe method
[21:26:54 CEST] <TwinTailed> [libav], when transcoding to h264, i am getting a missing audio frame (last frame)
[22:27:28 CEST] <krs_> Is there any PPA for Ubuntu 16.04 providing FFmpeg with libvpx and libopus ?
[22:46:22 CEST] <twizz> Hi - i'm looking to have a polling volumedetect (every second) on a running RTMP stream, that outputs to a file. Possible with FFMPEG?
[23:04:07 CEST] <Snicksie>  /wc
[23:29:26 CEST] <s0126h> is it true no computer/CPU is powerful enough to decode  8K video
[23:30:52 CEST] <JEEB> heavily depends on the format as well as the decoder's amount of optimizations as well as what picture rate is used with the content
[23:31:24 CEST] <JEEB> like, let's take the HEVC decoder there is in libavcodec. it's slow, so even 2160p30 is hard pressed on many quad cores
[23:31:27 CEST] <s0126h> so it's a yes ro some 8k video
[23:31:29 CEST] <s0126h> for*
[23:31:52 CEST] <JEEB> it's so generic that it doesn't make sense :P
[23:32:21 CEST] <s0126h> so nothing can decode  4k hevc video?
[23:32:28 CEST] <JEEB> no?
[23:32:44 CEST] <s0126h> other than getting  special hardware decoders
[23:32:47 CEST] <JEEB> ugh
[23:33:30 CEST] <JEEB> you seem to not grasp the idea of "there's different types of content, there's different picture rates, there's different systems, there's different implementations of a format"
[23:34:30 CEST] <Spring> is HEVC more taxing for decoding than AVC currently?
[23:35:02 CEST] <Spring> as it's already possible to capture at resolutions like 4K in games currently using the latter
[23:35:20 CEST] <JEEB> that's encodin
[23:35:22 CEST] <JEEB> *encoding
[23:35:44 CEST] <JEEB> the best example lately for decoding is the HEVC decoder which is currently slow, if you were dumb to think that's the only decoder around you'd say that 2160p30 and 2160p60 are really hard to achieve on it with many systems. but you can't say something is impossible. a good example of that is the fact that there are patches that optimize the decoder in a way that certain types of systems handle 2160p60 just
[23:35:45 CEST] <Spring> I know, two different comments
[23:35:50 CEST] <JEEB> fine
[23:36:35 CEST] <JEEB> so in general people who say "X is impossible with CPUs" are the marketing people who know they're making an overbroad statement and who might not be afraid to lie
[23:36:55 CEST] <JEEB> but of course if you start discussing details that's no longer as raffing for marketing
[23:37:38 CEST] <s0126h> jeeb why do you keep using 2160  example    most people use  1080p or 4k or 8k
[23:37:59 CEST] <JEEB> 2160p usually refers to 16:9 2160p
[23:38:06 CEST] <JEEB> while 4K refers to something wider than 16:9
[23:38:10 CEST] <JEEB> same for 8K
[23:38:41 CEST] <JEEB> of course the marketing people don't care and utilize the wording "4K" for 3840x2160
[23:39:47 CEST] <JEEB> and 2160p is the current high-end of end user production encodes
[23:39:57 CEST] <JEEB> 2160p60 being a thing
[23:40:10 CEST] Action: Spring takes thing
[23:40:46 CEST] <Spring> HEVC sounds like it has ways to go
[23:41:28 CEST] <JEEB> HEVC as a format is good, but it's currently being killed off by the sales/marketing/whatever folk who thought they didn't get enough from AVC licensing
[23:41:42 CEST] <JEEB> and libavcodec-wise nobody really cares to optimize things :P
[23:41:52 CEST] <s0126h> what is cheaper to use  right now?    avc or  hevc
[23:42:01 CEST] <JEEB> in what sense cheaper?
[23:42:08 CEST] <s0126h> licensing ee
[23:42:09 CEST] <s0126h> fee
[23:42:32 CEST] <JEEB> probably AVC I'd say, HEVC is kind of in the middle of bullshit because we have multiple patent pools and then some lone actors doing licensing
[23:42:45 CEST] <JEEB> one of the main things for AVC was that if you needed a license you got it from a single place
[23:42:53 CEST] <s0126h> is mpeg2 expired now and free?
[23:43:01 CEST] <JEEB> dunno, haven't looked at that stuff :P
[23:43:02 CEST] <Spring> AV1 is the chosen 1
[23:43:23 CEST] <JEEB> Spring: yeah - different companies sure picked up on that as the HEVC mess started rolling
[23:43:30 CEST] <JEEB> we'll see how it ends
[23:43:47 CEST] <s0126h> jeeb  i see,  sounds like hevc is in mess right now  with all the patent/licensing
[23:44:14 CEST] <JEEB> almost would make me feel sorry for the format if it was a person :P
[23:44:24 CEST] <JEEB> because HEVC does have good things in it
[23:45:18 CEST] <s0126h> with all the patents/licensing  how is  x264/x265  completely free then
[23:58:51 CEST] <JEEB> s0126h: software licenses and patent licensing are a completely different thing
[23:59:18 CEST] <JEEB> esp. if you don't provide binaries. neither x264 or x265 do that
[23:59:29 CEST] <s0126h> why? both makes money for the author/inventor
[00:00:00 CEST] --- Sun Oct  2 2016