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

burek burek021 at gmail.com
Mon Oct 16 03:05:01 EEST 2017


[01:18:22 CEST] <Glis> Hello - anyone around I could pick the brains of?
[03:22:52 CEST] <koyglreg> Why is there a 16-235 color range for TVs?
[04:11:24 CEST] <CoreX> koyglreg read this https://referencehometheater.com/2014/commentary/rgb-full-vs-limited/
[04:14:14 CEST] <koyglreg> I saw that article.  Maybe I missed something, but it doesn't really explain WHY TVs use 16-235, but only how and why you need to adjust your color space settings sometimes.
[06:37:07 CEST] <SolarAquarion>   -> Running ffmpeg configure script. Please wait...
[06:37:07 CEST] <SolarAquarion> ERROR: libflite not found
[06:37:24 CEST] <SolarAquarion> i have that installed
[06:59:25 CEST] <titbang> do u have the dev package
[08:42:48 CEST] <monoxane> right, i know you guys probably dont give a shit about mpeg-dash but theres nowhere to ask about it so ill do it here, how the hell do you make an mpd file correctly?
[10:14:40 CEST] <marlenka> hi
[10:16:01 CEST] <marlenka> its possible with ffmpeg do a invisible digital watermarking to video and posible read it again back?
[12:45:03 CEST] <diqidoq_> marlenka: define "invisible". Do you mean transparent but existing or hidden in file/code?
[12:46:19 CEST] <diqidoq_> marlenka: Regarding your use case (which I dont know) you can maybe use a subtitle track with transparency (not sure about transparency). A subtitle can later be extracted again. Just a thought to chime in.
[13:32:15 CEST] <SolarAquarion> titbang: I have arch installed
[13:32:33 CEST] <SolarAquarion> Although I don't see libtool files
[13:35:00 CEST] <titbang> not familiar with arch
[13:39:50 CEST] <SolarAquarion> titbang, basically no matter what version of flite i built i don't see the "libtool" files
[14:07:40 CEST] <jonascj> Does "-vf transpose" dictate a reencode?
[14:08:22 CEST] <jonascj> -vf "transpose=2" that is
[14:08:36 CEST] <jonascj> It seems like something which could be done completely lossless
[14:11:24 CEST] <furq> you can't apply any filters without reencoding
[14:11:41 CEST] <jonascj> alright, that was how I thought it was.
[14:11:43 CEST] <furq> if the container and player support it then you can rotate using container metadata
[14:11:54 CEST] <furq> -metadata:s:v:0 rotate=90 or something like that
[14:12:03 CEST] <jonascj> Maybe that landscape vs portrate rotation is just a simple meta data flag specifying oritientation anyway
[14:12:29 CEST] <furq> if this is a phone video then that's usually just a flag, yeah
[14:12:50 CEST] <jonascj> it is a phone video, and I just found an exif tag "Rotation: 270"
[14:12:54 CEST] <jonascj> thanks
[14:46:23 CEST] <titbang> SolarAquarion, i believe libtoolize is a standalone package
[16:23:32 CEST] <SolarAquarion> titbang, i meant the things that can be "libtools" as in provide .la as in -llibflite
[16:56:00 CEST] <FishPencil> Is there a way to see what SIMD optimizations are enabled for a build?
[16:56:19 CEST] <BtbN> unless you disabled them: all
[16:57:12 CEST] <JEEB> for x86_64 everything is built and then enabled per the capabilities of the runtime CPU
[16:57:16 CEST] <JEEB> same for x86
[16:57:17 CEST] <FishPencil> BtbN: Are they dependent on the detected CPU of the compiling machine or anything?
[16:57:48 CEST] <JEEB> for ARM NEON optimizations are also enabled or disabled during runtime
[16:58:57 CEST] <JEEB> for MIPS and PowerPC if you build for a specific thing the SIMD gets enabled
[17:00:32 CEST] <JEEB> but the most common case of "I am on intel and building for intel" has everything compatible built (some SIMD only supports 64bit x86 so for 32bit builds that won't of course be built), and then things get enabled when the library is started
[17:00:45 CEST] <JEEB> so whether you build on a xeon or an atom the result should be the same :P
[17:01:09 CEST] <BtbN> Unless you set a specific --cpu
[17:01:16 CEST] <BtbN> or cpu=host
[17:01:39 CEST] <JEEB> but that's compiler options I think?
[17:01:45 CEST] <JEEB> march=native etc
[17:01:55 CEST] <BtbN> yes, but it still ends up with a build that has instructions old CPUs don't have
[17:01:59 CEST] <JEEB> yes
[17:02:11 CEST] <BtbN> and they are not runtime-detected
[17:02:31 CEST] <FishPencil> What codecs (encoder or decoder) use a lot of SIMD? I'd like to do some testing
[17:02:35 CEST] <JEEB> yes, but generally people don't use that since FFmpeg's configure disables vectorization etc
[17:02:44 CEST] <JEEB> FishPencil: on x86_64 VP9 and AVC (H.264)
[17:02:55 CEST] <JEEB> the decoders, that is
[17:03:26 CEST] <JEEB> VP9 has a lot of modern SIMD made for it because one of the FFmpeg developers decided to start selling a VP9 encoder so he needed the decoding to be fast :)
[17:03:47 CEST] <Mavrik> nice
[17:03:56 CEST] <Mavrik> Is VP9 used outside Google a lot?
[17:04:16 CEST] <FishPencil> JEEB: Are you talking about EVE?
[17:04:20 CEST] <JEEB> not really. the fun fact is how Mozilla then ripped the decoder out of libavcodec and now has that ffvp9
[17:04:29 CEST] <JEEB> FishPencil: yup
[17:04:54 CEST] <FishPencil> JEEB: who was the dev lol
[17:05:10 CEST] <JEEB> uhh, I'm pretty sure his name is on the blog. :D
[17:05:36 CEST] <JEEB> yea, literally on its title
[17:05:42 CEST] <JEEB> https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/
[17:06:39 CEST] <JEEB> Mavrik: although IIRC Netflix uses it for downloads?
[17:06:46 CEST] <JEEB> now that I am reminded
[17:06:52 CEST] <Mavrik> I didn't really check tbh
[17:07:03 CEST] <FishPencil> Did he use FFmpeg for that? Wouldn't that violate even the LGPL
[17:07:06 CEST] <JEEB> Netflix is basically all about "someone else paid these thousands of VPS already so we can just ise it"
[17:07:24 CEST] <JEEB> *use
[17:07:50 CEST] <furq> FishPencil: MPL2 is GPL compatible
[17:08:24 CEST] <furq> actually nvm you mean EVE
[17:08:59 CEST] <furq> the encoder (presumably) doesn't have any ffmpeg code
[17:09:24 CEST] <furq> but if you're selling an encoder then it's probably good if you contribute to a fast decoder or nobody will buy the encoder
[17:10:22 CEST] <FishPencil> And people buy it because it's actually that much better?
[17:10:44 CEST] <JEEB> at least multiple vendors have been testing it according to media
[17:11:09 CEST] <JEEB> mostly places that just need the better quality, and don't care that much about the extra time spent on encodes VS x264
[17:12:03 CEST] <FishPencil> AV1 needs to hurry up
[17:12:31 CEST] <Mavrik> I'd say broadcast industry would grab it
[17:12:42 CEST] <Mavrik> Mostly due to BW costs and the fact that libvpx can't keep to CBR worth a damn
[17:13:02 CEST] <JEEB> VOD side of things is mostly interested because of no realtime requirement
[17:13:07 CEST] <JEEB> broadcast usually requires realtime
[17:15:30 CEST] <c3r1c3-Win> I recall seeing a video of a realtime AV1 encode from the floor of NAB this year.
[17:16:30 CEST] <FishPencil> I didn't even think the spec was done yet
[17:16:58 CEST] <JEEB> it still isn't
[17:17:09 CEST] <JEEB> it was 100% marketing, which is what NAB is
[17:17:22 CEST] <c3r1c3-Win> LOL.
[17:17:41 CEST] <JEEB> c3r1c3-Win: also making an encoder fast is not really a problem :D you don't have to support all features.
[17:17:55 CEST] <JEEB> a friend of mine at VDD was developing an alternative av1 encoder
[17:18:09 CEST] <JEEB> and he was easily getting hundreds/thousands of frames per second
[17:18:10 CEST] <c3r1c3-Win> I thought the essence part of the spec was done, it's the implementations that aren't done and some of the meta-data and container stuff that isn't done.
[17:18:18 CEST] <JEEB> nah, even coding methods
[17:18:28 CEST] <JEEB> they're going for the "soft freeze" at the end of this month
[17:18:35 CEST] <JEEB> let me find you the VDD talk about it
[17:18:36 CEST] <FishPencil> what is the proposed container
[17:18:48 CEST] <JEEB> https://bambuser.com/v/6908002#t=2416s
[17:18:59 CEST] <JEEB> FishPencil: they're doing mappings for all mostly utilized things I would presume
[17:19:12 CEST] <furq> presumably mkv or some subset thereof
[17:19:13 CEST] <c3r1c3-Win> Well it was for... Satellite/Cable transmission system (if I recall correctly). Broadcast is going h264 with ATSC3.0
[17:19:17 CEST] <JEEB> ISOBMFF (mp4) draft has been already poked
[17:19:21 CEST] <furq> but yeah i assume mpegts and whatnot will all work
[17:19:30 CEST] <Mavrik> What's the rationale for AV1?
[17:19:31 CEST] <JEEB> Matroska will most likely get one
[17:19:37 CEST] <Mavrik> Avoiding HEVC patent craziness?
[17:19:40 CEST] <JEEB> Mavrik: "plan B" because HEVC licensing got out of hand
[17:19:41 CEST] <furq> something like that
[17:19:50 CEST] <JEEB> a lot of companies basically decided it's a good idea to have Another Thing
[17:19:57 CEST] <JEEB> even if it doesn't necessarily bear fruit
[17:20:11 CEST] <JEEB> also really sorry for the audio being so low with the VDD talks :P
[17:20:17 CEST] <JEEB> not sure who set up the mic input
[17:20:24 CEST] <JEEB> or if it was just the camera's mic
[17:20:53 CEST] <Mavrik> What's the audio meant to accompany AV1?
[17:20:57 CEST] <furq> probably opus
[17:21:09 CEST] <Mavrik> Also do we have updated HDMI-ARC spec to carry anything that's modern yet? :P
[17:21:11 CEST] <JEEB> opus most likely, which is already in MPEG-TS and there's a draft for ISOBMFF
[17:21:18 CEST] <furq> av1 is mostly vp10 afaik so i assume it'll be all the same supporting stuff as vp9
[17:21:31 CEST] <JEEB> av1 is much less vp10 than how it was a year+ ago
[17:21:35 CEST] <JEEB> it based on the vp10 code, yes
[17:21:39 CEST] <FishPencil> Why even dev it then if we could just do vp10
[17:21:52 CEST] <JEEB> FishPencil: because multiple vendors. Google also moved from vp10 to AV1
[17:21:52 CEST] <furq> what would the difference be
[17:22:06 CEST] <c3r1c3-Win> Because VP10+Thor+Dhalia is better than just VP10
[17:22:10 CEST] <JEEB> furq: basically AV1 has a lot of very good stuff from the daala and thor etc
[17:22:18 CEST] <furq> i know that
[17:22:21 CEST] <JEEB> ok
[17:22:26 CEST] <furq> 16:21:39 ( FishPencil) Why even dev it then if we could just do vp10
[17:22:27 CEST] <furq> i meant this
[17:22:37 CEST] <furq> idk why you'd want them to just make vp10
[17:22:50 CEST] <JEEB> the difference would be that less people would contribute to a standard google project VP10
[17:22:59 CEST] <furq> av1 is more or less the continuation of vp9, plus good shit from other vendors, plus you hopefully get a clean break from libvpx
[17:23:41 CEST] <c3r1c3-Win> Yeah. Doesn't ilbvpx have horrible CBR and multi-threaded capabilities? ;-)
[17:23:53 CEST] <JEEB> while google of course still is a big contributor, it makes a world of difference to have other vendors in there as well
[17:24:24 CEST] <furq> and also you get a standard that isn't "look at the source code, but try to ignore the errata"
[17:24:24 CEST] <Mavrik> Yeah, more pressure to actually to HW decode support and similar
[17:24:37 CEST] <Mavrik> Although Apple forcing HEVC on people is annoying
[17:24:42 CEST] <furq> fuck apple
[17:25:08 CEST] <FishPencil> Apple has pretty much always been behind on these things
[17:25:18 CEST] <furq> it's not behind, it's actively obstructing
[17:25:59 CEST] <FishPencil> Too busy developing tiny DAC's
[17:26:30 CEST] <c3r1c3-Win> JEEB: Thanks for the link. I'll have to finish watching it later (running a stream right now), but that's some interesting stuff.
[17:26:50 CEST] <JEEB> c3r1c3-Win: yea, even if derf's stuff goes way over your head his stuff is generally great to listen
[17:27:24 CEST] <c3r1c3-Win> Well Apple doesn't support VP9, and yet people are using it because Android (generally) supports it, along with desktop hardware (i.e. CPUs and GPUs).
[17:27:39 CEST] <c3r1c3-Win> and by 'people' I really should say companies... large companies.
[17:27:58 CEST] <JEEB> I only know google and maybe netflix using VP9 in any major capacity
[17:28:10 CEST] <c3r1c3-Win> Hell, Safari doesn't get Youtube 4k support because of their lack of VP9 support, LOL.
[17:28:16 CEST] <Mavrik> Yeah, thing is that HEVC covers pretty much all devices
[17:28:19 CEST] <Mavrik> And VP9 doesn't
[17:28:29 CEST] <Mavrik> So when you need to pay for encode/storage... VP9 might not make sense
[17:28:53 CEST] <Mavrik> (Unless you're as big as Netflix/Google which can save money on less bandwidth)
[17:29:12 CEST] <JEEB> on the other hand I've not seen too many cases where I've seen HEVC be good to go
[17:29:20 CEST] <furq> does safari even get 1080p on youtube
[17:29:22 CEST] <JEEB> mostly utilized because it has the 10bit decoders
[17:29:29 CEST] <furq> i thought it was still restricted to the 720p http stream
[17:29:39 CEST] <JEEB> not because of compression improvements
[17:29:43 CEST] <furq> or did apple finally cave on supporting mpeg-dash
[17:29:54 CEST] <JEEB> that was done in JS anyways, no?
[17:29:55 CEST] <Mavrik> furq, noone cares because everyone watches youtube on ipad :P
[17:30:27 CEST] <JEEB> because if we needed actual native DASH support in browsers chromium wouldn't play that stuff either
[17:30:39 CEST] <JEEB> so now we've got all this stuff around JS fed ISOBMFF segments
[17:30:50 CEST] <JEEB> (or webm segments for VP9/opus)
[17:30:53 CEST] <c3r1c3-Win> I can state that the JWPlayer does DASH using JS.
[17:31:13 CEST] <furq> you still need MSE for that to work in js afaik
[17:31:19 CEST] <furq> and apparently iOS safari still doesn't have it
[17:32:09 CEST] <FishPencil> Seems like most of the battle is getting people to actually agree, not development
[17:32:12 CEST] <Mavrik> 4K YT works just fine in Safari
[17:32:36 CEST] <Mavrik> Just gets delivered as H.264
[17:32:55 CEST] <Mavrik> FishPencil, that was always the battle when it comes to formats
[17:33:06 CEST] <furq> yeah
[17:33:22 CEST] <Mavrik> Especially when you have so many rent-seekers
[17:33:33 CEST] <c3r1c3-Win> But it's kinda hard to agree when there's no code to test/spec's to build hardware against.
[17:34:50 CEST] <c3r1c3-Win> I must admit it's been fun seeing HEVC start it's decent into madness and crashing and burning on the licensing front.
[17:34:55 CEST] <FishPencil> We just need one line of formats that aren't gobbled up by MPEG LA to dump development in. Just imagine how nice that would be
[17:36:10 CEST] <FishPencil> "one format to rule them all"
[17:36:12 CEST] <BtbN> mpeg la is not the problem.
[17:36:19 CEST] <BtbN> The other patent pools are.
[17:36:46 CEST] <FishPencil> how about anyone who's a patent pool is a problem
[17:37:21 CEST] <BtbN> mpeg la had very realistic rules and didn't get in the way of normal users.
[17:37:28 CEST] <BtbN> well, still has
[17:38:41 CEST] <c3r1c3-Win> I've never had a problem with them.
[17:43:26 CEST] <FishPencil> Kind of a cool table https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Patent_license_terms
[18:32:48 CEST] <JEEB> c3r1c3-Win: I think the "best" part is that everyone who's read the specification would agree that it's much saner and simpler at various parts than AVC. buut then the corps that decided that MPEG-LA rules wouldn't get them enough shekels :D
[18:33:05 CEST] <JEEB> and yea, that whole thing then led a whole bunch of corps to have a plan B
[18:33:10 CEST] <JEEB> which is what AV1 is
[18:34:33 CEST] <c3r1c3-Win> and so far I'm loving AV1 on all fronts.
[18:35:21 CEST] <JEEB> the problem is of course the implementation at the end of the day. hopefully we will get a proper community around whatever AV1 encoder starts looking most promising
[18:35:59 CEST] <c3r1c3-Win> JEEB: Have you looked at the AV1 source (or even just the commit history)?
[18:36:15 CEST] <JEEB> libaom you mean
[18:36:43 CEST] <JEEB> yea, I've built it every now and then but I'm now mostly waiting for all the experiments that were picked to be enabled by default
[18:37:03 CEST] <JEEB> libaom currently is very slow because it's also the R&D platform / reference
[18:37:48 CEST] <c3r1c3-Win> I've only read the commit history/other's experiences with it.
[19:17:43 CEST] <Fyr> guys, when I try -map 0 -c copy, FFMPEG write: unsupported codec on 0:1 mjpeg.
[19:17:43 CEST] <Fyr> 0:1 - is a cover art. is there a way to make FFMPEG copy cover art?
[19:19:21 CEST] <CoreX> are you trying to copy the whole thing ?
[19:20:18 CEST] <Fyr> yes
[19:20:31 CEST] <CoreX> -c copy should do it then
[19:20:46 CEST] <Fyr> CoreX, it doesn't.
[19:22:16 CEST] <furq> what are the input and output containers
[19:22:35 CEST] <Fyr> input: FLAC, output: OPUS.
[19:23:39 CEST] <furq> https://trac.ffmpeg.org/ticket/4448
[19:23:42 CEST] <furq> there's your problem
[19:24:29 CEST] <Fyr> ='(
[19:24:33 CEST] <furq> apparently opusenc will do it automatically
[19:24:44 CEST] <Fyr> the developers never read the bug tracker.
[19:24:57 CEST] <furq> contributions welcome
[19:25:33 CEST] <Fyr> some of them even 7 years old.
[19:26:04 CEST] <JEEB> well some tickets should just be closed if there is no information etc, but yes - only more or less one guy cares about the issue tracker
[19:27:08 CEST] <JEEB> ffmpeg-devel is the generally read medium on both IRC and ML, but non-technical reports (which is what will mostly get onto the issue tracker) is frowned upon
[19:27:42 CEST] <JEEB> I do poke at some issues on the tracker as I notice them being posted/edited on the -devel IRC channel
[19:28:27 CEST] <JEEB> but those are only such that I have an interest of or happen to know :P
[19:29:36 CEST] <Fyr> could you recommend a tool that converts list of files with copying full information about them, including cover art?
[19:30:27 CEST] <marlenka> its possible with ffmpeg do a invisible digital watermarking to video and posible read it again back? Invisible for Human eyes (copyrights)
[19:30:54 CEST] <marlenka> thx for answers
[19:33:14 CEST] <ayum> Hi, When I using nvenc codec to encoding 1080p at 25 fps stream, CPU used 40~50%, is it normally?
[19:33:35 CEST] <JEEB> marlenka: I don't think there's a filter for that
[19:33:54 CEST] <JEEB> marlenka: of course nothing stops you from making such a filter if you have a standard for that (or just using an overlay)
[19:34:06 CEST] <Fyr> ayum, when I encode with NVENC, it's about 1-2%.
[19:34:31 CEST] <ayum> yes, somewhere wrong
[19:35:10 CEST] <ayum> used old version CUDA will it cause this problem?
[19:36:43 CEST] <Fyr> ayum, do you use only the encoder or both the encoder and the decoder?
[19:37:35 CEST] <ayum> @Fyr, seems my mistake. I use htop to check ffmpeg process CPU usage. it show used 50%, but entire CPU only used 6%.
[19:37:50 CEST] <ayum> perhaps, 50% usage is single core?
[19:38:40 CEST] <ayum> @Fyr, I think it's my mistake, sorry bother you
[00:00:00 CEST] --- Mon Oct 16 2017


More information about the Ffmpeg-devel-irc mailing list