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

[burek]

[00:04:44 CET] <kerio> levo: ffmpeg -i yourthing.webm -c:v rawvideo -c:a copy out.mkv
[00:04:53 CET] <kerio> prepare for humongous file
[00:04:54 CET] <kerio> s
[03:25:20 CET] <Phi> Can a giant spoon be utilised as a weapon?
[03:25:37 CET] <Phi> Also, I need help getting FFMPEG to use the h264_qsv codec
[03:25:47 CET] <Phi> C++ style, Windows, MSVC
[04:20:57 CET] <Phi> no ideas?
[05:14:21 CET] <FishPencil> Phi: You're going to need to be more specific. Massively more specific
[05:16:51 CET] <Phi> I'm wearing white socks
[05:16:56 CET] <Phi> white cotton
[05:17:27 CET] <Phi> also I'm getting "error -40: Function not implemented", and "error initialising internal MFX structure"
[05:17:38 CET] <Phi> ffplay with h264_qsv works fine
[05:17:48 CET] <Phi> and the same code decodes the H264 fine with libx264
[05:18:11 CET] <Phi> the error -40 appears in avcodec_open2 on the h264 codec
[05:19:15 CET] <Phi> correction, "h264_qsv : Error initializing an internal MFX session", "avcodec_open2 failed with error -40: Function not implemented."
[05:19:39 CET] <dsc_> have you tried changing socks
[05:19:54 CET] <Phi> I wasn't wearing socks earlier, but all that happened was I was a bit cold
[05:20:00 CET] <Phi> also Trump got elected
[05:20:03 CET] <Phi> is that important?
[05:20:15 CET] <dsc_> what did you call my mother?
[05:20:28 CET] <Phi> a trumpet
[05:20:48 CET] <Phi> so tell me, about this error, how do I trumpet?
[05:21:12 CET] <dsc_> videos are an illusion. they're just images played sequentially, your eyes deceive you. 80 years ago we we're still riding horses.
[05:22:15 CET] <Phi> I was there when they played the first cinema film
[05:22:28 CET] <Phi> there was a stampede when the film of the train was shown
[05:22:30 CET] <dsc_> did you also jump away
[05:22:41 CET] <dsc_> rightly so.. rightly so
[05:24:05 CET] <Phi> this newfangled technology
[05:24:13 CET] <Phi> back in my day the world only had two colours
[05:24:24 CET] <Phi> and we walked sixteen miles over countryside to get to 'em
[05:25:40 CET] <Phi> now it's YUV420P and NV12 in H264 over RTSP in a TCP tunnel and ffmpeg doesn't know how to H264 QSV properly
[05:25:57 CET] <Phi> makes me nostalgic
[05:26:27 CET] <dsc_> stop insulting my mother
[05:26:42 CET] <dsc_> seriously though I have no idea what you're doing and I can't help you
[05:26:55 CET] <Phi> seems like this channel alright XD
[05:26:59 CET] <dsc_> I just use vlc_player.exe
[05:27:05 CET] <dsc_> lol
[05:27:11 CET] <Phi> same
[05:27:16 CET] <dsc_> jokes on you for not using gstreamer
[05:27:20 CET] <Phi> I tried it
[05:27:25 CET] <Phi> massively bloated
[05:27:29 CET] <Phi> same with OpenCV
[05:27:45 CET] <Phi> at least FFMPEG can actually open network streams
[05:29:14 CET] <Phi> good thing I'm paid per hour to gaze blankly at generic unhelpful ffmpeg error messages
[05:30:47 CET] <dsc_> hey
[05:30:55 CET] <dsc_> perhaps you can help me
[05:31:55 CET] <Phi> *looks skeptical*
[05:32:03 CET] <dsc_> if you wanted to generate thumbnails from a remote .mp4 you know for a fact is $some_codec, what's the most efficient way to achieve that (without generating loads of bandwidth)
[05:32:22 CET] <dsc_> because in theory you'd only need the MOOV ATOM and some keyframes right? RIGHT??? RIGHT.
[05:32:33 CET] <Phi> um
[05:32:38 CET] <Phi> have you tried turning it off and back on again
[05:32:48 CET] <dsc_> yes
[05:32:52 CET] <Phi> is it plugged in?
[05:33:04 CET] <Phi> if so I'm lost
[05:33:09 CET] <dsc_> stop insulting my mother
[05:33:17 CET] <Phi> you have too many mothers
[05:33:22 CET] <dsc_> :( yes
[05:33:48 CET] <Phi> same-sex marriage
[05:33:53 CET] <Phi> social commentary
[05:34:01 CET] <dsc_> hey you're getting paid answer my question please thanks
[05:34:08 CET] <Phi> did I mention trump
[05:34:09 CET] <Phi> I have a very high rate
[05:34:27 CET] <dsc_> you have a very high rate
[05:34:47 CET] <Phi> much like your MP4s
[05:34:56 CET] <dsc_> rude
[05:35:20 CET] <Phi> you may be able to abuse progressive downloading
[05:35:20 CET] <Phi> by specifying start/end times
[05:35:43 CET] <Phi> if you pass HTTP Keep-Alive with it
[05:36:04 CET] <dsc_> lets say my mp4 is not optimized for progressive downloads but the protocol (HTTP, whatever) does support seekable parameters (accept-range)
[05:36:24 CET] <Phi> I don't want to say that
[05:36:26 CET] <Phi> http://www.adobe.com/devnet/video/articles/mp4_movie_atom.html
[05:37:04 CET] <Phi> MP4 uses H264 internally, which is a mix of predictive frames and keyframes
[05:37:44 CET] <Phi> you could then abuse the GP size and bitrate of all the streams, and guess at what byte start you need
[05:38:17 CET] <Phi> but that's a big ask so you might be better off asking someone more experienced
[05:39:12 CET] <dsc_> someone who is not experiencing "avcodec_open2 failed with error -40: Function not implemented."
[05:39:15 CET] <dsc_> got it :P
[05:39:33 CET] <Phi> stop insulting my mother
[05:40:49 CET] <dsc_> mother not implemented
[05:41:00 CET] <Phi> you'd just need to guarantee you have a keyframe in x bytes you read
[05:41:12 CET] <dsc_> yeah that.
[05:41:41 CET] <Phi> for that you'd need keyframe size and num bytes inbetween (GP size tells you how many keyframes are around), plus MP4 header offset
[05:42:07 CET] <dsc_> what's GP size again?
[05:42:19 CET] <dsc_> and with MP4 header you mean MOOV ATOM?
[05:42:37 CET] <Phi> no
[05:42:40 CET] <Phi> I mean start of MP4
[05:42:51 CET] <Phi> where it gives jargon about MP4 container details
[05:42:55 CET] <dsc_> cool
[05:43:00 CET] <Phi> e.g. "here's video/audio streams in this file"
[05:43:09 CET] <dsc_> one would hope it contains information about bitrates, keyframes and such, yes.
[05:43:15 CET] <Phi> GP size is something to do with number of keyframes per second
[05:43:25 CET] <dsc_> cool
[05:43:42 CET] <Phi> anyway, bedtime for me
[05:43:45 CET] <Phi> it's nearly 5am
[05:43:50 CET] <dsc_> 5:39am here
[05:43:50 CET] <Phi> which means I should be paid more
[05:43:55 CET] <dsc_> lol
[05:43:57 CET] <dsc_> oki
[05:43:58 CET] <Phi> your clock must be wrong
[05:43:58 CET] <dsc_> bye
[05:44:00 CET] <dsc_> no
[05:44:04 CET] <dsc_> your clock is off
[05:44:09 CET] <Phi> it's that Trump effect
[05:44:17 CET] <dsc_> silly english people
[05:45:20 CET] <Phi> at least the British didn't elect panic so much about Brexit the economy nosedived
[05:45:30 CET] <Phi> also electing trump
[05:45:33 CET] <Phi> also I'm tired
[05:45:47 CET] <Phi> man who runs in front of car gets tired, man who runs behind car gets exhausted
[12:12:30 CET] <Filarius22> I need downscale algorithm for x2 smaller what will give average of 2x2 pixels
[14:18:19 CET] <Sander^home> Hi. Do anyone know if the apple's aptX sound encoding normally used with bluetooth 4.0 is lossless? it says its destinct lossless on google search, wondering what that means.
[14:20:13 CET] <Sander^home> The alternative, which is AAC, is lossy. I guess thats why apple most likely did use aptX
[15:01:05 CET] <fred1807> My script use this to show the resolution of video: ffprobe -v error -of csv -select_streams v:0 -show_entries stream=height,width "$i" , problem is that this is not working on a debian machine, I get error: Unrecognized option 'select_streams'   . Can I calculate screen resolution of ffprobe version there is on debian wheezy ?
[15:03:04 CET] <furq> fred1807: https://www.johnvansickle.com/ffmpeg/
[15:05:20 CET] <furq> i wouldn't bother with the ffmpeg in wheezy, it's ancient
[15:05:25 CET] <furq> there are countries which are younger than ffmpeg 0.8
[15:05:36 CET] <vans163> Phi: But did you hear about the man who got run over by the 18 wheeler?
[15:07:01 CET] <furq> https://en.wikipedia.org/wiki/South_Sudan
[15:07:04 CET] <furq> this country, if you were wondering
[15:15:13 CET] <fred1807> those binaries will work on wheezy?  I am giving it a try
[15:17:55 CET] <furq> wheezy uses linux 3.2 so it should work fine
[17:07:39 CET] <Sander^home> Have anyone considered making a installer wrapper which only includes those codecs which compiles?
[17:11:47 CET] <Sander^home> I've heard cmake is supposed to be pretty good at that.. and its becoming more and more popular.
[17:14:33 CET] <Sander^home> Its always a struggle to remove that single codec with a repository someone had a compilation error in, becouse I wanted to include as many codecs as possible.
[17:16:58 CET] <Sander^home> Alernatively, a continuisly updates known working installation from source recepie with history of previously working recepies whould be nice.
[17:18:47 CET] <JEEB> what?
[17:18:58 CET] <JEEB> I mean, the configure script is exactly for that
[17:19:32 CET] <JEEB> also wtf is an "installer wrapper"!?
[17:19:58 CET] <JEEB> also cmake has nothing to do with "installers"
[17:20:12 CET] <JEEB> it's a yet another build system, with its own good and bad sides
[17:21:15 CET] <Sander^home> I tend to run configure a few times to figure out which codecs I need to remove to make it compile.
[17:21:29 CET] <JEEB> ...
[17:22:03 CET] <JEEB> I mean, that sounds like you don't know what you want and/or you are in no control of what dependencies are installed
[17:22:28 CET] <JEEB> you get 99% of all decoders and most of the internal encoders by just doing "./configure" without any parameters
[17:22:47 CET] <JEEB> because most stuff is within FFmpeg and do not require 3rd party libraries
[17:23:00 CET] <JEEB> then you know that you want AVC encoding with libx264 for example
[17:23:12 CET] <JEEB> so you make sure your system has x264 in there in one way or another
[17:23:26 CET] <JEEB> since libx264 is GPL you add `--enable-gpl --enable-libx264`
[17:23:41 CET] <JEEB> and configure will tell you if you've installed your dependencies incorrectly
[17:23:55 CET] <JEEB> the idea is not for the configure script to silently ignore what you specified and it cannot find
[17:24:04 CET] <Sander^home> There is always a little known unknown codec library I wanted to include, which dosnt compile.
[17:24:35 CET] <JEEB> "doesn't compile" in what sense
[17:25:06 CET] <Sander^home> In the sense that the maintainer of that library didnt port it to the newest version of ffmpeg yet.
[17:25:07 CET] <JEEB> because there's a difference in "I want it but I do not make sure it is available" and "the wrapper is broken"
[17:25:12 CET] <JEEB> eh
[17:25:23 CET] <JEEB> that sounds like a dependency that wants FFmpeg instead of an FFmpeg build issue
[17:26:04 CET] <JEEB> for example with libx264 if x264 changed its API then it's the FFmpeg wrapper that hasn't been updated if the build breaks (generalization)
[17:26:07 CET] <Sander^home> Well, its way too  many diffrent codes, which makes it a big chance to get into that problem at any time.
[17:26:12 CET] <JEEB> ...
[17:26:59 CET] <Sander^home> cmake is the only tool I know of, which can be used as a compiler wrapper.
[17:27:07 CET] <JEEB> that is bullshit
[17:27:23 CET] <JEEB> this all just sounds like you don't understand (or cannot express) your issue at hand and are looking at incorrect ways of going around it
[17:27:30 CET] <JEEB> you might want to think about it a bit more and explain it better
[17:27:54 CET] <JEEB> I do btw agree that the build system is not perfect in FFmpeg but whatever you've said right now does not get fixed by any build system
[17:28:02 CET] <JEEB> 18
[17:32:45 CET] <Sander^home> Its possible to make cmake generate the right parameters to configure for including the right codecs.
[17:33:54 CET] <Sander^home> And if it fails compiling, it can remove one codec at a time.
[17:34:06 CET] <JEEB> you're looking at it from the wrong side IMHO. if you really _need_ all of what you're setting to be enabled, then make sure that stuff is available. that's how usually people script this stuff
[17:34:13 CET] <Sander^home> Maybe its possible with someting diffrent than cmake too..
[17:34:33 CET] <JEEB> you're talking about something that is not even build system related, plain scripting for eff's sake :P)
[17:35:17 CET] <JEEB> if you are OK with building without something then you shouldn't be pushing that option to configure in the first place
[17:35:40 CET] <JEEB> trying to find out what the receipient system has or doesn't have like that just doesn't make much sense :P
[17:35:50 CET] <JEEB> and enabling a build without something you need
[17:44:18 CET] <Sander^home> ffmpeg is pretty special as alot of distributions includes it even if the standar recepie fails, becouse it got so many diffrent optional dependencies.
[17:45:13 CET] <JEEB> what you just wrote just makes no sense :P
[17:45:44 CET] <Sander^home> There is always some small codec which breaks.
[17:46:27 CET] <JEEB> "a lot of distributions include it, even if the standard 'recipe' fails"
[17:46:37 CET] <JEEB> ^ this, does not, make sense
[17:47:30 CET] <JEEB> also you are giving mixed signals whether something FFmpeg uses has had an API change and either an old or new version breaks, or if something that utilizes FFmpeg breaks.
[17:48:04 CET] <Sander^home> x11 is in the same situation. require a manual compilation becouse of too many sublibraries.
[17:51:02 CET] <Sander^home> cmake can be used as a testing suite, which can figure out both compile time errors and runtime errors.
[17:52:40 CET] <Sander^home> configure can only do compiletime errors I belive.
[17:52:44 CET] <JEEB> you're looking at the incorrect solutions for a problem you have still not explained properly
[17:53:28 CET] <JEEB> because what you're saying right now for cmake is not something you can't do with the current thing :P or any other goddamn scripted thing
[17:58:24 CET] <Sander^home> cmake can be used to build itself.
[17:58:58 CET] <Sander^home> thats pretty rarely.
[17:59:12 CET] <JEEB> "scripting language X can be used to build the interpreter for itself"
[17:59:18 CET] <JEEB> no, it is not
[17:59:34 CET] <furq> i don't really understand what's being proposed here but i would just like to say that i hate cmake on a deeply personal level
[17:59:54 CET] <JEEB> the person just has no idea and seems to have seen some random buzzwords together with cmake
[18:00:04 CET] <furq> and i think the current build system is pretty good
[18:00:27 CET] <JEEB> his first idea was to iterate over configurations with cmake to build the least limited build with the stuff a system has already available (?)
[18:00:34 CET] <JEEB> even though the goddamn word he then proceeds to use is "need"
[18:00:42 CET] <furq> i'm not saying it's my fault that i don't understand
[18:00:44 CET] <JEEB> and if you need something you usually try to make it available
[18:01:00 CET] <JEEB> instead of trying to provide a build that then doesn't have what you need
[18:01:17 CET] <Sander^home> There is a cmake function which can be defined, which can explain how to build any package, including cmake itself.
[18:01:36 CET] <JEEB> "a function can be created that explains how a thing is compiled"
[18:01:46 CET] <JEEB> that pretty much covers any scripting language
[18:02:31 CET] <JEEB> seriously, please try to explain a) what your problem is b) how you are currently thinking of solving it and maybe you will finally be able to explain it so that both sides gain something from it
[18:05:01 CET] <pomaranc> I don't think he knows
[18:05:40 CET] <dragmore88> IPTABLES: Is there a way to tell iptables that it should ignore eth1 ?
[18:06:21 CET] <dragmore88> sorry, wrong window ;)
[18:06:49 CET] <Sander^home> cmake add_custom_command
[18:06:59 CET] <Sander^home> I belive thats the right thing.
[18:10:55 CET] <Sander^home> x11 (windows manager) have too many screencard dependencides and ffmpeg have too many media codec dependencies. Which makes them both abit hard to build.
[18:11:25 CET] <Sander^home> sorry, *graphic card*
[18:11:25 CET] <furq> x11 isn't a window manager
[18:14:29 CET] <Sander^home> windowing system might be a better word according to wikipedia atleast;-)
[18:16:36 CET] <Sander^home> X Window System
[18:17:36 CET] <DHE> well, ffmpeg can have a huge number of dependencies, sure. but you can build it with very few as well. I have a headless server with ffmpeg installed. no X11, no hardware support whatsoever
[18:24:57 CET] <Sander^home> Yep. and cmake is perfect for making recepies for building distribution spesific packages and at the same time havine a test to figure of if a codec does work as intended or not, so it becomes quicker for the maintainer to check if it breaks a given build or not.
[18:26:03 CET] <Sander^home> *having*
[18:26:47 CET] <Sander^home> The hard thing is to get the framework in place with the first test tho.
[18:33:18 CET] <Sander^home> I remember it was a huge debate back in the days to take in ffmpeg in some distros becouse it did break, but they decided to do it anyway, becouse it did "break by design" with a good reputation:) I guess thats why some of the distros which is into contiues integration for building the os dosnt include ffmpeg, Ubuntu's distro spesific wrapper which is called juju might solve it for ubuntu, but not for every other distro tho.
[18:36:13 CET] <Sander^home> DHE: Yep, Its pretty amazing how those dependencies and subdepencendies works:)
[18:37:15 CET] <DHE> yeah. I still agree with JEEB though. if you want you can build a version of ffmpeg with video encoders supported (decode only). so I don't see what the issue is
[18:37:36 CET] <DHE> if you want x264 support in ffmpeg, install x264 (dev libraries if distributed separately) and then build ffmpeg with --enable-libx264. done
[18:37:58 CET] <DHE> *without video encoders
[18:38:08 CET] <pomaranc> there is actually a cmake for ffmpeg with a lot of the dependecies
[18:38:29 CET] <pomaranc> it creates a static build with everything inside
[18:41:29 CET] <furq> what does any of this have to do with cmake
[18:42:50 CET] <Sander^home> furq: well, cmake can be used to alot of diffrent things, just like awk:)
[18:46:52 CET] <DHE> lots of things have lots of uses. an MCSE certificate can be used for kindling when building a campfire for example...
[18:47:04 CET] <DHE> (joke)
[18:47:31 CET] <markvandenborre> have there been big improvements in webm vp9 encoding between ffmpeg 3.1.x and ffmpeg 3.2.x?
[18:47:45 CET] <JEEB> libvpx handles VPx encoding
[18:47:47 CET] <DHE> ffmpeg uses libvpx to do the heavy lifting
[18:47:50 CET] <furq> ffmpeg doesn't have a builtin vpx encoder
[18:47:57 CET] <furq> too slow ;_;
[18:48:06 CET] <DHE> JEEB wins
[18:48:06 CET] <JEEB> so it really depends on if you also upgrade libvpx while at it
[18:48:45 CET] <markvandenborre> hm, it seems like I have 1.3 on Debian stable and 1.6 on debian testing
[18:48:59 CET] <markvandenborre> I'll have to look at the libvpx release notes then
[18:49:08 CET] <markvandenborre> makes a really big difference at first sight
[18:49:28 CET] <markvandenborre> (we want to release the fosdem.org videos for 2017 in webm too as a matter of principle)
[18:50:27 CET] <markvandenborre> that's about 500 hours of talks
[18:50:48 CET] <markvandenborre> so looking if this is even feasible at all
[18:51:32 CET] <DHE> with an E5-2699v4 all things are possible. :)
[18:53:11 CET] <JEEB> modern libvpx can be relatively OK speed-wise, but I wish google cared about rate control and bang-for-buck :)
[18:54:07 CET] <JEEB> maybe the addition of non-GOOG entities with libaom will help in the future, but we will have to see
[18:54:38 CET] <markvandenborre> my laptop running debian testing does multithreaded libvpx it seems
[18:54:56 CET] <markvandenborre> but my testing server running debian stable (libvpx) nothing at all
[18:55:29 CET] Action: markvandenborre is giving it an upgrade to debian testing (libvpx 1.6.0)
[18:55:34 CET] <markvandenborre> curious about speed differences
[18:56:05 CET] <JEEB> yeah, they did add some support for mt encoding
[18:58:38 CET] <Sander^home> Is there a lossless sound format good for streaming?
[18:59:00 CET] <JEEB> flac is being standardized for ISOBMFF so you can utilize it with MPEG-DASH
[18:59:02 CET] <Sander^home> Maybe FLAC is that theese days?
[18:59:18 CET] <JEEB> also of course if you are just pushing stuff through HTTP without any DASH or HLS or whatever
[18:59:28 CET] <JEEB> you can just push FLAC in matroska or even in ogg, maybe :P
[19:00:00 CET] <markvandenborre> JEEB: seems the main multithreading code came in libbpx 1.4.0
[19:00:06 CET] <JEEB> something like that, yes
[19:00:36 CET] <JEEB> I've been poking at libvpx every now and then and so far mostly been disappointed :/
[19:01:01 CET] <JEEB> that said, I am not limited to formats that supposedly are "patented by people who are OK with people using the format without any payments under all circuimstances"
[19:01:17 CET] <JEEB> (because there is no such thing as "patent-free" formats unless they're just ancient)
[19:01:52 CET] <Sander^home> Wondering if bluetooth 4.0 SBC will have a free lossless format soon.
[19:02:03 CET] <JEEB> (and no, libx265 hasn't really impressed me much more - at least compared to the complexity and high bitrate detail retention)
[19:02:10 CET] <JEEB> (of libx264)
[19:02:30 CET] <JEEB> but yes, upgrading libvpx if you are going to encode in VP9 sounds like a VeryGoodIdea
[19:02:55 CET] <JEEB> at least from the initial version in debian stable you had
[19:12:33 CET] <Sander^home> Is there a list of which hardware types likes x86 or arm that flac/ogg/aac compiles on?
[19:13:51 CET] <BtbN> everywhere where a C compiler exists?
[19:15:28 CET] <DHE> there are no mandatory ASM bits in the codecs. pure C is available everywhere
[19:15:29 CET] <Sander^home> I'm thinking about os's which is made for small embedded chips
[19:15:43 CET] <DHE> then cross-compile
[19:17:41 CET] <furq> markvandenborre: if you have a bunch of videos then you might want to encode them in parallel
[19:18:03 CET] <furq> libvpx's multithreading is a bit crap in general
[19:20:49 CET] <Sander^home> DHE: any list of already working cross compiles?
[19:21:17 CET] <DHE> not off the top of my head. it will depend on the chip. I'm guessing ARM. google can help you out
[19:25:47 CET] <markvandenborre> furq: that's the problem... we have full day coverage that we want to split
[19:26:14 CET] <markvandenborre> I'm hardly getting to 0.3x realtime on 720p content
[19:26:40 CET] <Sander^home> DHE: I know raspbian (raspberry pi) did have to do a small codec elemination last time they did a release.
[19:27:11 CET] <markvandenborre> that is on Atom C2750  @ 2.40GHz (4 cores/8 threads)
[19:27:36 CET] <markvandenborre> these are our streaming machines
[19:28:27 CET] <markvandenborre> maybe we need to cut up first indeed, as you suggest furq, then process the mp4 into webm
[19:28:54 CET] <markvandenborre> only we were hoping to survive on pseudo cutting using nginx http mp4
[19:29:32 CET] <markvandenborre> ... in which case processing smaller files would not work of course
[19:31:58 CET] <Sander^home> DHE: what about QNX?
[19:35:09 CET] <DHE> uhh... I only have ARM and MIPS (on linux) experience at this time.
[19:37:06 CET] <ElAngelo> is there any licensing on uploaded media to the bugtracker?
[19:42:39 CET] <Sander^home> I belive WEBM was released to public domain, or something, anyone know which type of adaptive sound codec they are using there?
[19:42:45 CET] <Sander^home> for streaming.
[19:43:30 CET] <Sander^home> Some years back I belive they didnt define any.
[19:43:37 CET] <furq> vorbis or opus
[19:49:51 CET] <markvandenborre> any other suggestions on how to speed  up webm encoding?
[19:51:36 CET] <thebombzen> the problem with cmake is that it's generally awful
[19:52:13 CET] <thebombzen> I tend to dislike build systems that don't use configure, make, make install
[19:56:33 CET] <markvandenborre> furq (or others)
[19:56:44 CET] <markvandenborre> do you know if there is anything like HLS for vp9?
[19:57:36 CET] <markvandenborre> that would immediately solve much of the problem
[19:58:42 CET] <furq> dash supports webm
[19:58:47 CET] <Sander^home> markvandenborrie: do you know if webm is figuring out when to turn off adaptive streaming?
[20:01:32 CET] <DHE> HLS officially only supports H264 and AAC... that's apple for ya
[20:01:45 CET] <DHE> unless it's changed. HLS is still a draft and subject to frequent reviews
[20:02:03 CET] <markvandenborre> I was mostly referring to the chunks bit
[20:02:18 CET] <Sander^home> encoding is quicker when there is enough bandwith to not have adaptive streaming on, to change that without interuppion migh be a problem.
[20:02:52 CET] <markvandenborre> Sander^home: not entirely sure what you mean
[20:03:10 CET] <markvandenborre> the streaming machines have plenty of bandwidth
[20:04:01 CET] <markvandenborre> this is more about making chunks that can be converted to webm more efficiently, then recombined (or whatever)
[20:04:46 CET] <Sander^home> markvandenborre: if both endes have pleny of bandwith, you do want to have adaptive streaming off to speed up encoding.
[20:05:28 CET] <markvandenborre> Sander^home: either I don't understand what you want to say very well, or you don't understand what we want to do very well
[20:05:52 CET] <markvandenborre> I'm looking into possibilities to add webm as an option for the conference videos we publish
[20:05:58 CET] <markvandenborre> as soon after the conference as possible
[20:06:05 CET] <markvandenborre> this does not have to be live streaming
[20:06:20 CET] <markvandenborre> we simply don't have the encoding to do 25 live webm streams in parallel
[20:06:34 CET] <markvandenborre> s/the encoding/the encoding power/
[20:07:04 CET] <Sander^home> Becouse adaptive streaming devides one picture frame up in packages, so its possible that a recieving device with low banwith can drop packages to decide to only decode eg. 70% of one frame, just like jpg's gets abit blurry.
[20:11:20 CET] <markvandenborre> Sander^home: thx for the hint
[20:14:45 CET] <Sander^home> markvandenborre: if the reciving end have low cpu, then you want adaptive streaming on so a few packages can be dropped before coming to the cpu.
[20:15:11 CET] <markvandenborre> there's no issue there really
[20:15:41 CET] <markvandenborre> there already is mp4 for that
[20:16:10 CET] <markvandenborre> this is purely about giving people who prefer free formats out of principle
[20:16:18 CET] <markvandenborre> an alternative: webm
[20:16:50 CET] <markvandenborre> and I'm thinking about a good and practical way to do that
[20:17:08 CET] <markvandenborre> (if it can be done without piles of effort)
[20:17:26 CET] <Sander^home> one format with flow control, another with adaptive streaming, thats why there is in need of two I guess.
[20:17:38 CET] <Sander^home> two formats.
[20:18:35 CET] <markvandenborre> we are planning to do hls and dash
[20:19:01 CET] <markvandenborre> plus hopefully webm files if we can manage to
[20:19:34 CET] <markvandenborre> (not webm streaming)[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C
[20:20:19 CET] <furq> is there a time constraint here that's preventing you from just encoding them slowly
[20:21:38 CET] <furq> also i assume there'll be someone attending fosdem who's willing to donate a few cpu hours on a beefy server
[20:22:43 CET] <markvandenborre> we could throw sponsor money at it indeed, but would rather avoid that
[20:23:20 CET] <markvandenborre> encoding slowly is not really an option
[20:23:56 CET] <markvandenborre> as the use of those videos degrades with every day after the conference itself
[20:24:52 CET] <Sander^home> thebombzen: I agree that the cmake script is abit messy, but becouse cmake also can call itself, then its possible to easy have configuration files inside each codec, which defines if it should be included or not on a condition.
[20:25:47 CET] <thebombzen> Sander^home: I understand your frustration with doublechecking what works. that is, wanting to include the maximum number of codecs that work just for the sake of having the maximum number, and disabling ones you cannot make work.
[20:26:05 CET] <thebombzen> but people who have that sort of idea aren't the target audience of the maintainers.
[20:26:56 CET] <thebombzen> It's far more important that you satisfy the people who want extremely consistent results.
[20:26:59 CET] <Sander^home> the cmake script is a one time thing to make, each codec's config file needs to be changed when something breaks.
[20:27:42 CET] <thebombzen> Also, another thing is you keep saying "something breaks" but realize that if FFmpeg stops being compatible with a library after FFmpeg updates, that's not that library's fault
[20:27:50 CET] <thebombzen> that's called an FFmpeg regression. In other words, it's a bug.
[20:28:25 CET] <thebombzen> When that happens, submit a bug to trac with the tag "regression" and it'll probably get fixed very fast, cause regressions are high priority.
[20:29:52 CET] <thebombzen> You keep saying "FFmpeg breaks all the time" but that's most likely something unstable on your end. I've discovered that in the last few years any time ffmpeg wouldn't find a library, it's because of something wrong with my system and not with the source.
[20:29:57 CET] <Sander^home> there can be a cmake codec config directory with a folder for each os arc, everything outside the ffmpeg path.
[20:30:26 CET] <thebombzen> Not all systems with the same OS are the same. Every system is different.
[20:31:31 CET] <thebombzen> For example, Ubuntu-based systems are really weird and very different from more primitive systems
[20:33:21 CET] <thebombzen> but again, people who want their builds to have the maximum possible number of external libraries whose wrappers will compile, those people are not the target audience.
[20:33:45 CET] <thebombzen> it's far more important to satisfy people who know exactly what they want, and enable exactly those things, and have an increase in consistency.
[20:40:13 CET] <Sander^home> thebombzen: Maybe ubuntu juju is trying to finetune parameters of a codec inside for given cpu on compiletime?
[20:40:30 CET] <thebombzen> I have no idea what you just said
[20:43:46 CET] <Sander^home> juju is ubuntu's spesific compile wrapper, which is something simular to cmake, but more tied into ubuntu's .deb format, for fitting together complex packages with configuration commands (instead of cmake's configuration files).
[20:48:45 CET] <Sander^home> Yeah, I agree, its more important to finetune the paramerers for each invidual case. But its also nice to make it a single downloadable script to install on any distro from source. Makes it easier included in more distro's
[20:50:23 CET] <furq> we already have one of those
[20:50:25 CET] <furq> it's called configure
[20:50:42 CET] <JEEB> which is why usually in that case that script installs dependencies as required... instead of trying to check which configure flags will happen to work on a specific machine
[20:59:30 CET] <Sander^home> I guess configure dosnt "include the maximum number of codecs that work just for the sake of having the maximum number, and disabling ones you cannot make work."
[21:06:19 CET] <Sander^home> thebombzen: I've submitted a few bugs earlier like that, didnt think about marking it with regression tho..
[21:08:58 CET] <Sander^home> if more people run more regression tests all the time, codec developers will probably get faster feedback on codec bugs after they submit it.
[21:10:23 CET] <Sander^home> As long as making packages for several os'es is on by default.
[21:13:16 CET] <Sander^home> I guess some distro's have figured that out on its own..
[21:13:33 CET] <Sander^home> raspberry pi havent yet..
[21:14:03 CET] <Sander^home> raspbian.
[21:15:06 CET] <zyme> I just call them ardrino's for some reason,
[21:15:46 CET] <zyme> But every time I spell check it I find that I've slaughtered it.
[21:21:43 CET] <zyme> It's just a SoC made for either use by the people who made Cryix CPU's right?
[21:31:18 CET] <Sander^home> Its nice as you can choose between arm avl and intel on arduino, but only run one program at a time without any os. After what I know, there is not any good instructions about if its possible to cross compile the c compiler against it, to be able to compile linux programs on it.
[21:46:46 CET] <zyme> I believe there is a sdk to do exactly that, and I've been told there's also a basic Debian build avalible for it if you wan't to make an uber cheap pc out of one.
[21:53:07 CET] <Sander^home> Yeah. you can use eg codebender to create c++ apps for arduino. But didnt find out how to compile programs that require c yet for it.
[21:55:15 CET] <Sander^home> i'm unsure about if arduino have comparable cpu type so cross compilation can be done.
[21:59:06 CET] <Sander^home> if eg raspberry's arm processor is simular enough to support cross compiling of c to arudino's simular arm processor, that could possibly work if those two arm processors is in the family.
[22:02:17 CET] <furq> you don't need a similar cpu to cross compile
[22:02:19 CET] <furq> that's the whole point
[22:04:38 CET] <kerio> how do i start a video at a certain time?
[22:04:47 CET] <kerio> i probably want to add black frames at the beginning
[22:04:59 CET] <kerio> (compared to the audio)
[22:05:17 CET] <Sander^home> furq: You do need a simular cpu when you want to add a new programming language on a cpu where there is no programming language.
[22:17:49 CET] <Sander^home> furq: Well, the crosscompilation tools dosnt run on arduino. And to be able to get c on it, I guess it could be possible to get a working crosscompilation tool working on another arm os
[22:19:21 CET] <Sander^home> I havent found good instrunctions on how to get a crosscompilation enviroment working on raspberry.
[22:21:20 CET] <Sander^home> To cross compile for raspberry i've tried when it first came out.
[22:21:47 CET] <Sander^home> I tried to cross compile on it too, but failed.
[22:21:59 CET] <JEEB> it's nothing special. install a cross-compiler for the OS you have on it :P
[22:22:17 CET] <JEEB> f.ex. if you have debian (raspbian) on it, you install the armv7 toolchain on debian
[22:22:20 CET] <JEEB> done
[22:30:53 CET] <Sander^home> raspbian have a selected number of packages compeard to debian. Have to check if thats available at a later point I guess:)
[22:31:32 CET] <BtbN> isn't raspbian just the debian arm archives + some special RPi software?
[22:32:53 CET] <JEEB> BtbN: yes
[22:33:10 CET] <JEEB> Sander^home: I mean you'd be cross-compiling on another machine :P
[22:33:32 CET] <JEEB> of course you can compile on the ARM thing as well
[22:33:36 CET] <JEEB> but that's just slow
[22:34:36 CET] <Sander^home> JEEB do you know about an arm motherboard supporting stock debian?
[22:34:52 CET] <furq> the rpi
[22:37:05 CET] <pprkut> Hi! I have a video file where the timestamp resets to 0 sometime during playback. I'd like to split the video according to those resets. Is there any way I can do this?
[22:37:10 CET] <furq> the pi 1 is armv6 so you have to run debian armel, which is less than ideal on a hardfloat cpu
[22:37:28 CET] <furq> the 2 and zero are armv7, so regular debian armhf works fine (with a custom kernel)
[22:37:41 CET] <furq> and the 3 is aarch64 so that ought to work fine as well
[22:38:59 CET] <Sander^home> JEEB, furq: thats right, using Debian armhf on rpi
[22:41:58 CET] <Sander^home> furq, JEEB: got any details on any recepie on how to do this?
[22:46:35 CET] <relaxed> Sander^home: have you seen https://www.johnvansickle.com/ffmpeg/ ?
[22:52:55 CET] <Sander^home> relaxed: nice overview:)
[22:56:29 CET] <Sander^home> Whould be nice with something like that for more arcs/os'es, I guess cmake is one way of streamlining it:)
[22:59:50 CET] <Sander^home> If there is compiler diffrences between architectures, then a bug can occour on one cpu, but not on another.
[23:11:31 CET] <Sander^home> One way of testing if there is a compiler diffrence between two types of cpu's which affects encoding quality, is to encode between two diffrent no loss formats, back and forth, if it becomes the same file on two diffrent cpu types, then the compiler on both platform is bugfree.
[23:13:57 CET] <Sander^home> I guess thats only a problem for platforms with few developers.
[23:16:44 CET] <Sander^home> A good way of testing if the cpu and compiler have a matching assembler interface.
[23:17:08 CET] <Sander^home> FLAC is one such noloss format, is there another one?
[23:23:07 CET] <Sander^home> I guess wav and flac is a good match?
[23:25:15 CET] <BtbN> why not just do a full fate run?
[23:38:29 CET] <Sander^home> Its a good test to see if the compiler mature enough to use in production for a new cpu family.
[23:38:42 CET] <Sander^home> is mature enough*
[23:38:43 CET] <Filarius22> any way to highlight keyframes (maybe graph on top of video) ? I need to check where exactly on video keyframes of X264 codec is located
[23:41:01 CET] <Sander^home> Some lesser used platforms might have a few glitches which is hard to notice at first.
[23:46:21 CET] <DeadSix27> Something I don't quite get, is google using a modified avc that breaks the 5.2 level and supports 8k?
[23:46:22 CET] <Sander^home> Some few old but very stable embedded platforms have a few assembler bugs by design, which sometimes gets hidden by the programming language and sometimes not.
[23:47:00 CET] <furq> Filarius22: -vf "drawtext=text=%{pict_type}"
[23:47:16 CET] <DeadSix27> (but then again, i have barely an idea how this works anyway, just assumed that 5.2 really the upper limit here, yet the 8k one magically plays in my player despite breaking the lvl 5.2 limit)
[23:48:27 CET] <GuiToris> hello! Could someone help me? I have this interesting phenomenon. If I trim a video, like  $ ffmpeg -i input.mp4 -ss 00:00:10 -to 00:00:20 -c copy output.mp4 I will have a new output.mp4 video which doesn't have picture at the beginning. Why is that, and how can I avoid it?
[23:52:32 CET] <DeadSix27> nvm was just a weird issue on errors, debugging it showed me x264 couldnt allocate enough memory
[23:52:54 CET] <DeadSix27> (which made me realise i didnt use the 64bit version :p)
[23:54:08 CET] <DeadSix27> (or better, its a warning (the profile one) but didnt display the libx264 error @normal loglevel, so i assumed that was the error, but it wasnt)
[23:56:27 CET] <FishPencil> The libbluray package contains a "mpls_dump" tool that can be used to show chapter information for a mpls(m2ts) stream. It shows the chapter information in "ticks" time, such as "Time (ticks): 524280". Any idea what that unit is, or how I can get it into sec/ms?
[00:00:00 CET] --- Sun Nov 13 2016