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

[burek]

[00:05:12 CEST] <kepstin-laptop> cool, that makes it easy on the encoder side.
[00:14:01 CEST] <maqr> kepstin-laptop: yeah, a little bit worse for the user though in terms of switching quality quickly
[00:16:23 CEST] <maqr> i wonder if i'd get different behavior with shorter -hls_time
[00:18:51 CEST] <nathanpickles> I am getting an error: http://hastebin.com/ahijivafov.txt
[00:19:18 CEST] <nathanpickles> http://hastebin.com/ahijivafov
[00:20:02 CEST] <maqr> kepstin-laptop: if i'm using a bufsize of 5 sec, and the last segment is only 2 sec... it should still be fine right?
[00:20:05 CEST] <maqr> i assume that's handled somehow
[00:22:00 CEST] <nathanpickles> I think the problem is with -vf scale=-1:360
[00:23:22 CEST] <maqr> actually, nevermind, i'm using a bufsize of 1 sec, it'll be safe and always work
[02:06:19 CEST] <Miesco> Hi
[02:07:14 CEST] <Miesco> I did ffmpeg -i f.mkv -vf subtitles=f.mkv -o f.mp4; how come the quality is decreased significantly?
[02:10:02 CEST] <Miesco> I tried this: @debian ffmpeg$ ./configure --enable-libass --enable-nonfree --enable-libfaac --enable-gpl --enable-libx26
[02:10:07 CEST] <Miesco> Will this help?
[02:21:12 CEST] <Miesco> ~/src/ffmpeg/ffmpeg -i Crouching\ Tiger\ Hidden\ Dragon\ \(2000\)\ 720p.BRrip.Sujaidr\ \(dual\ audio\ chi\,eng\).mkv -c:v libx264 -preset slow -crf 22 -c:a copy -vf subtitles="Crouching\ Tiger\ Hidden\ Dragon\ \(2000\)\ 720p.BRrip.Sujaidr\ \(dual\ audio\ chi\,eng\).mkv" Crouching_Tiger_Hidden_Dragon_\(2000\)_burn.mp4
[02:21:17 CEST] <Miesco> Thats what I typed
[02:21:21 CEST] <Miesco> Is that good quality?
[02:27:42 CEST] <smo_> hi
[02:28:31 CEST] <smo_> i try to convert a m4a 253 kb/s , when i use ffmpeg -i .... -f mp4 it show 128kb/s how can i keep the bitrate ? (if it s not normal)
[04:00:49 CEST] <kyleogrg> hey
[04:01:27 CEST] <kyleogrg> to reduce video file size, is it better to reduce the resolution or the bit rate?  what's a good ratio?
[04:16:17 CEST] <kepstin> I assume you mean reducing resolution & bitrate vs. reducing only bitrate
[04:17:25 CEST] <kyleogrg> in other words, when a video encode size is too large, what should be reduced?
[04:17:40 CEST] <jookiyaya> kyleogrg you cannot reduce bitrate per se
[04:17:56 CEST] <kepstin> doesn't seem that hard to measure; try doing a (two-pass) encode to the same bitrate with one video downscaled, one video not downscaled, see which looks better.
[04:18:01 CEST] <kyleogrg> if i drastically reduced the resolution, that would reduce output size.
[04:18:12 CEST] <jookiyaya> reducing resolution  results in "reducing bitrate"
[04:18:17 CEST] <jookiyaya> kyleogrg you cannot reduce bitrate per se
[04:18:35 CEST] <kyleogrg> hmm, but i'm setting the bitrate...
[04:18:43 CEST] <kepstin> there's nothing stopping you from encoding a smaller video at a higher bitrate than a larger video...
[04:19:08 CEST] <kyleogrg> exactly, so how do i know the resolution-bitrate ratio
[04:19:46 CEST] <kyleogrg> does higher res and lower bitrate look better than lower res and higher bitrate?
[04:19:52 CEST] <kepstin> depends on the video
[04:19:59 CEST] <kepstin> try it and see with your video.
[04:20:00 CEST] <jookiyaya> reducing resolution  results in "reducing bitrate"
[04:20:25 CEST] <jookiyaya> kyleogrg your question makes no sense
[04:20:39 CEST] <kyleogrg> jookiyaya: what do you mean exactly?  because i can set the "bitrate value" right?
[04:20:56 CEST] <jookiyaya> for video?
[04:21:03 CEST] <kepstin> if you reduce the bitrate, you'll get a smaller video. resolution doesn't come into it at all...
[04:21:14 CEST] <kyleogrg> jookiyaya: yeah, it's a video
[04:21:20 CEST] <jookiyaya> what video codec?
[04:21:29 CEST] <kyleogrg> two-pass x265
[04:21:35 CEST] <kepstin> depending on the video source, it might have better quality or might not have better quality if you downscale it before encoding to a particular bitrate.
[04:21:42 CEST] <jookiyaya> don't use  that setting
[04:21:47 CEST] <jookiyaya> use constant quality
[04:22:13 CEST] <kyleogrg> kepstin: you're saying downscaling won't change the file size?  only bitrate?
[04:22:32 CEST] <kepstin> kyleogrg, downscaling doesn't directly change the filesize or bitrate (filesize and bitrate are the same thing)
[04:22:35 CEST] <c_14> downscaling on its own won't change the file size or the bitrate
[04:22:54 CEST] <kyleogrg> then all it does it adjust "quality" right?
[04:22:56 CEST] <jookiyaya> c_14 yes it will
[04:23:22 CEST] <jookiyaya> c_14  lowering resolution will always results in  lower bitrate/filesize
[04:23:26 CEST] <c_14> jookiyaya: no. I can downscale a video and increase bitrate at the same time.
[04:23:51 CEST] <kyleogrg> c_14: yeah, but if you keep bitrate the same and downscale, the size reduces?
[04:23:58 CEST] <jookiyaya> who uses "bitrate" settings on video  these days
[04:23:59 CEST] <c_14> no
[04:24:01 CEST] <kepstin> kyleogrg, bitrate and size *are the same thing*
[04:24:02 CEST] <c_14> because the bitrate is the same
[04:24:08 CEST] <c_14> bitrate is bits per second
[04:24:16 CEST] <c_14> not bits per pixel per second
[04:24:34 CEST] <kyleogrg> ok.  so what is the result of downscaling?
[04:24:35 CEST] <jookiyaya> c_14  why don't you use  constant quality
[04:25:19 CEST] <kepstin> kyleogrg, if you downscale, then the encoder can use more bits on each pixel, which in some videos might change the perceived "quality"
[04:25:41 CEST] <kepstin> (for better or worse, hard to say.)
[04:25:49 CEST] <kyleogrg> uh-huh, ok i got it
[04:25:56 CEST] <c_14> jookiyaya: I usually (but not always) do, I'm just trying to keep you from expressing things as absolute truths that can't be expressed in absolute terms.
[04:26:01 CEST] <c_14> But what kepstin said
[04:26:28 CEST] <kyleogrg> ok, different subject
[04:26:30 CEST] <kyleogrg> vp9
[04:26:46 CEST] <kyleogrg> vp9 vs x265
[04:27:08 CEST] <jookiyaya> kyleogrg  just use constant quality
[04:27:10 CEST] <kyleogrg> any strong opinions?
[04:27:12 CEST] <kepstin> to be honest, in a choice between vp9 and x265, i'd pick x264.
[04:27:27 CEST] <jookiyaya> kepstin why? x264 iso ld
[04:27:32 CEST] <jookiyaya> kepstin why? x264 is old
[04:27:49 CEST] <c_14> It's still the best thing out there for _many_ use-cases.
[04:27:51 CEST] <kepstin> vp9 and x265 are too new :)
[04:27:51 CEST] <jookiyaya> vp9/x265 is newer/better
[04:27:57 CEST] <kyleogrg> jookiyaya: why is constant quality preferable?
[04:28:17 CEST] <kyleogrg> kepstin: you mean they haven't gotten all the bugs out?
[04:28:42 CEST] <kepstin> kyleogrg, mostly they haven't spent as much time finding optimizations and encoding gains as the x264 devs have
[04:29:03 CEST] <jookiyaya> [19:22] <jookiyaya> handbrake recommends to use  Constant quality  yet why do i see so many people use "bitrate/2pass" settings
[04:29:03 CEST] <jookiyaya> [19:25] <dkeav> old habits die hard
[04:29:03 CEST] <jookiyaya> [19:26] <jookiyaya> what is the reason people does not use CQ
[04:29:03 CEST] <jookiyaya> [19:28] <dkeav> because people has the stupids
[04:29:21 CEST] <c_14> x265 and vp9 aren't necessarily bad, x264 is just too damn good
[04:29:44 CEST] <kepstin> if you're encoding to a specific target filesize/bitrate (which are the same thing), 2-pass mode still makes sense...
[04:29:48 CEST] <kyleogrg> jookiyaya: ok, but why exactly is it better?  2pass lets you target a size
[04:30:04 CEST] <jookiyaya> why do you need targetted size?
[04:30:32 CEST] <kepstin> but there's not much cause to do that nowadays unless you're e.g. encoding content for physical disks or something.
[04:30:40 CEST] <c_14> kyleogrg: using a crf allows the encoder to choose where to spend more bits and where to save them. ie if you have some scenes with lots of motion and some with lots of nothing it averages better
[04:30:49 CEST] <kyleogrg> jookiyaya: basically you're saying CQ is better, unless i need to target a size, right?
[04:31:06 CEST] <c_14> kyleogrg: or you're trying to stream and have bandwidth limitations
[04:31:24 CEST] <kyleogrg> c_14: sure.  but 2pass also will distribute bits this way, right?
[04:31:24 CEST] <jookiyaya> kyleorgrg i don't see any reason these days that somebody would require target size
[04:31:43 CEST] <kyleogrg> jookiyaya: ok
[04:32:18 CEST] <kepstin> kyleogrg, in x264 (other codecs differ), two-pass average bitrate mode and crf mode give the exact same quality for a given bitrate.
[04:32:40 CEST] <kepstin> but crf mode lets you pick the quality, and 2pass mode lets you pick the bitrate
[04:32:52 CEST] <kyleogrg> yes
[04:33:23 CEST] <kepstin> (if you start using vbv buffers for streaming, i'm not entirely sure how that interacts)
[04:33:49 CEST] <kyleogrg> many seem to still prefer x264.  although x265 encodes smaller sizes at same quality (right?), i guess it's not as optimized yet
[04:34:12 CEST] <kepstin> x265 can encode smaller sizes at the same quality if you wait longer.
[04:34:19 CEST] <kepstin> a *lot* longer.
[04:34:24 CEST] <kyleogrg> kepstin: yeeees
[04:35:20 CEST] <kyleogrg> and with this kind of thing, will future tweaks (to libx265) make it encode much faster?
[04:35:41 CEST] <kepstin> much faster? probably not.
[04:35:52 CEST] <kyleogrg> yes, the only hope is to have a very fast computer
[04:36:07 CEST] <kepstin> the reason the h.265 standard can compress better than h.264 is that it has more choices the encoder can make on how to compress things
[04:36:18 CEST] <kyleogrg> yes, makes sense
[04:36:22 CEST] <kepstin> in order to determine which choice is good, the encoder has to spend more time if there are more choices
[04:36:51 CEST] <kyleogrg> kepstin: like a chess AI looking farther and farther ahead
[04:37:18 CEST] <kyleogrg> it's exponential
[04:37:33 CEST] <kyleogrg> i wonder if vp9's encoding speed is about the same
[04:37:41 CEST] <jookiyaya> is there really an advantage of using slow setting on x265 ?
[04:37:43 CEST] <kepstin> so the optimizations that can be made are mostly on finding things that are heuristics - basically "the human eye sees motion in this kind of way, so if there's that type of motion, prefer this option"
[04:38:15 CEST] <kyleogrg> kepstin: yeah, which x264 is mature in and x265 is a mere child
[09:41:37 CEST] <kagami_> Hi guys. Probably noob question, but is it possible to use different than the current pixel component in lutrgb filter (or some other similar filter)? I'm trying to set alpha component depending on the red component like this: lutrgb=a=if(r,val,0) but it doesn't work...
[11:28:20 CEST] <Richlv> can i add metadata to a file without encoding/copying it ?
[11:28:39 CEST] <Richlv> the examples on the wiki and elsewhere use input/output files
[11:30:52 CEST] <Dark-knight> if i do a system restore on my computer to an earlier state, will that revert my firefox cookies too?
[11:34:12 CEST] <Anoia> system restore (assuming windows) shouldn;t touch user files, but I can't say for certain
[11:38:07 CEST] <Richlv> http://stackoverflow.com/questions/11474532/how-to-change-metadata-with-ffmpeg-avconv-without-creating-a-new-file says that can't be done...
[12:03:51 CEST] <klaxa|work> Richlv: you cannot really edit files in-place
[12:03:59 CEST] <klaxa|work> you will have to use a temporary file
[12:04:21 CEST] <klaxa|work> (that also adds security against accidentally overwriting sensible data)
[12:05:12 CEST] <Richlv> klaxa|work, thanks, that's what i started doing, yes :)
[12:05:53 CEST] <Richlv> in this case i'm already operating on a copy, so overwriting that would not be a huge issue, but yeah
[13:12:29 CEST] <fffan> does mp4 has 32 bit version and 64 bit version?
[13:13:01 CEST] <klaxa|work> no
[13:13:46 CEST] <fffan> when I muxing mp4 in 32 bit ffmpeg, it crashed when the mp4 is larger than 4G
[13:13:55 CEST] <fffan> 64 bit is ok
[13:16:26 CEST] <klaxa|work> i don't know how things are handled internally, but it sounds like an address-space issue
[13:16:41 CEST] <klaxa|work> it's probably not a problem with mp4 itself
[13:17:05 CEST] <fffan> address space should only 2G for windows user mode application
[13:17:12 CEST] <fffan> my case is 4G
[13:17:44 CEST] <fffan> just look at open broadcast soft, it has a macro
[13:17:54 CEST] <fffan> #ifdef USE_64BIT_MP4   fileOut.OutputQword(0);  #endif
[13:18:09 CEST] <fffan> what is USE_64BIT_MP4?
[13:19:05 CEST] <klaxa|work> oh?
[13:19:26 CEST] <fffan> ?
[13:19:39 CEST] <klaxa|work> maybe there is "64bit mp4" after all
[13:19:51 CEST] <fffan> just google USE_64BIT_MP4
[13:20:17 CEST] <fffan> so what is 64 bit mp4? can anyone tell me?
[13:20:48 CEST] <klaxa|work> i can't because i don't know
[13:21:19 CEST] <klaxa|work> i can only guess that it could be something with addressing data within the mp4 file internally
[13:21:25 CEST] <klaxa|work> like pages for a book
[13:21:29 CEST] <fffan> so klaxa, could you just google USE_64BIT_MP4 and give me some tip?
[13:21:32 CEST] <Anoia> does anyone know of an mercurial clone of the ffmpeg git repo?
[13:21:46 CEST] <Anoia> I have ~4 hours left on a convert :)
[13:21:54 CEST] <fffan> and how to set 64 bit mode mp4 for ffmpeg
[13:23:09 CEST] <klaxa|work> fffan: the easiest would probably be to just use 64 bit ffmpeg
[13:23:38 CEST] <klaxa|work> if that is no option, please file a bugreport, also address the USE_64BIT_MP4 thing from OBS
[13:24:10 CEST] <fffan> yes, it is the easiest way, but I wanna know why? and I believe there are a lot of people still using 32 bit os
[13:24:56 CEST] <fffan> maybe ffmpeg already solved that problem, I just I don't know how to use it correctly
[13:44:56 CEST] <]R[> is there any way to override the max analyzeduration ?
[16:00:55 CEST] <Demos> Hey so I just built ffmpeg on windows using msys2 and mingw32. I used --enable-nonfree --enable-nvenc but when I try and encode a video with -c:v nvenc I get "Failed loading CUDA library", which seems to be printed on line 356 of nvenc.c if the call to LoadLibrary or dlopen fails
[16:04:01 CEST] <Demos> nvcuda.dll is in c:\windows\System32 and c:\windows\SysWOW64
[16:14:31 CEST] <edsonmenegatti> Hi guys, I'm trying to set the metadata of a video stream with the avformat library, however the following code fails to do it http://pastebin.com/BHqw8ai2. Any thoughts on what could be the issue?
[16:22:30 CEST] <mtcjayne> What are some things that still aren't ready regarding DASH playback?
[16:23:06 CEST] <mtcjayne> Is there a timeline or bug tracker milestone of sorts I can use to track the progress?
[16:28:42 CEST] <cousin_luigi> Greetings.
[16:31:45 CEST] <BtbN> mtcjayne, you mean playing das as input format, or the dash muxer?
[16:31:50 CEST] <BtbN> +h
[16:37:04 CEST] <mtcjayne> A Kodi/XBMC developer stated that there is no demuxer in ffmpeg and that until there is Kodi will not be able to support DASH streams. I'm trying to figure out the accuracy of that statement, as he didn't give any citations.
[16:37:44 CEST] <JEEBsv> "DASH" is not as simple as that generally
[16:37:54 CEST] <JEEBsv> I mean, there is a demuxer for the container parts
[16:38:21 CEST] <JEEBsv> but how you find the container parts and if you need to load extra files...
[16:39:23 CEST] <mtcjayne> I know of a library called libdash, whose developer has a reference player that uses ffmpeg.
[16:40:06 CEST] <mtcjayne> Does anyone know of it or have any idea if that's remotely relevant to this type of discussion?
[16:42:51 CEST] <BtbN> basicaly you need a pre-demuxer for dash. Something that parses the xml, and pieces together the resulting mp4, and passes it to the mp4/mov demuxer.
[16:43:03 CEST] <BtbN> No such code currently exists in ffmpeg.
[16:43:52 CEST] <mtcjayne> Is this code likely to be included? What you're describing almost sounds like it's outside ffmpeg's scope.
[16:45:08 CEST] <BtbN> There is no such code that could be included.
[16:45:21 CEST] <BtbN> Someone has to write it first.
[16:45:32 CEST] <BtbN> If you do so, it could be merged.
[16:45:59 CEST] <mtcjayne> That was my concern. It seems to me a lot of people are sitting on their hands hoping it's someone else's job.
[16:46:27 CEST] <BtbN> A lot of people don't need a dash demuxer, so why would they be hoping for that?
[16:46:35 CEST] <mtcjayne> Oh, I had to scroll down. I thought you were saying it WON'T be part of ffmpeg.
[16:48:09 CEST] <mtcjayne> But in response to your comment, I agree. It's a limited use case outside of the web (as far as I can tell) and I would have preferred it be worked on by the small apps that will benefit (Kodi, Kodi addons, etc)
[16:48:54 CEST] <JEEBsv> well the web really doesn't even seem to be using "proper" DASH
[16:49:02 CEST] <JEEBsv> rather they are loading random files from JS
[16:49:11 CEST] <JEEBsv> like 'tube for example
[16:49:31 CEST] <BtbN> youtube is using DASH, and a huge bunch of JavaScript to feed it to the browser.
[16:49:49 CEST] <BtbN> As Browsers don't support JS, but a JavaScript api to feed them with mp4 parts.
[16:49:58 CEST] <BtbN> *don't support DASH.
[16:50:25 CEST] <JEEBsv> yeah, thus "proper" DASH isn't really used on the web
[16:50:36 CEST] <JEEBsv> other than in educational/academic spheres
[16:50:44 CEST] <BtbN> DASH is some scary thing anyway
[16:50:45 CEST] <JEEBsv> and the part of it that is used is already supported
[16:51:06 CEST] <BtbN> mp4 parts... the last container format I'd think about for that.
[16:51:15 CEST] <JEEBsv> what you need is something like youtube-dl that actually then supports the random ways those services are providing you the media parts
[16:51:27 CEST] <mtcjayne> Right. So I'm thinking Kodi needs to implement its own (or someone else's) similar library to get (is it elementary?) streams passed to ffmpeg in their software?
[16:51:36 CEST] <BtbN> It is mp4
[16:51:42 CEST] <JEEBsv> not elementary since the streams are in a container
[16:51:50 CEST] <JEEBsv> 'tube does mp4 and matroska
[16:52:01 CEST] <BtbN> mp4, cut into pieces. With one special piece that contains the moov atom.
[16:52:11 CEST] <JEEBsv> (which is why they implemented the muxer for their matroska "DASH" in ffmpeg IIRC)
[16:52:31 CEST] <JEEBsv> but yeah, mpv just implemented youtube-dl
[16:52:36 CEST] <JEEBsv> so it gets called
[16:52:41 CEST] <JEEBsv> everyone seems happy enough
[16:52:48 CEST] <BtbN> yes, mkv seems like a way better choice for DASH
[16:52:50 CEST] <mtcjayne> OK otherwise is that an accurate description of the issue which I can leave as a comment on their forum?
[16:53:09 CEST] <BtbN> I don't think a propperly made DASH demuxer would be rejected from ffmpeg.
[16:53:19 CEST] <BtbN> It's just that nobody is intersted in writing one.
[16:53:21 CEST] <JEEBsv> but that is not something users actually want :P
[16:53:26 CEST] <mtcjayne> Yeah
[16:53:26 CEST] <JEEBsv> because nothing actually uses DASH
[16:53:36 CEST] <JEEBsv> people just want to watch their youtubes and so forth
[16:53:47 CEST] <JEEBsv> basically just integrate calling youtube-dl and call it a day
[16:53:48 CEST] <BtbN> Steam does, Twitch is experimenting with it.
[16:53:51 CEST] Action: mtcjayne raises his hand
[16:54:10 CEST] <JEEBsv> I'd really be surprised if they're actually doing proper DASH
[16:54:14 CEST] <mtcjayne> I want to watch my 1080p 'Tubes
[16:54:24 CEST] <JEEBsv> mtcjayne: exactly. so you are not needing real DASH
[16:54:31 CEST] <JEEBsv> you just need the glue that gets the streams
[16:54:33 CEST] <BtbN> You need an external tool for youtube anyway
[16:54:35 CEST] <JEEBsv> in other words, youtube-dl
[16:54:45 CEST] <JEEBsv> (it supports various other sites, too)
[16:54:49 CEST] <mtcjayne> I don't really care if it's done properly, but I would like to see progress at all in the project
[16:55:00 CEST] <JEEBsv> no, not proper
[16:55:07 CEST] <JEEBsv> I just mean that it's not fucking DASH
[16:55:24 CEST] <BtbN> JEEBsv, well, at least the DASH reference "player" is able to play it.
[16:55:34 CEST] <mtcjayne> I'd suggested youtube-dl which was dismissed as wacky and "We're waiting on ffmpeg demuxer" /eyeroll
[16:55:47 CEST] <mtcjayne> *hacky
[16:55:48 CEST] <JEEBsv> then XBMC folk are sitll idiots
[16:55:57 CEST] <JEEBsv> *still
[16:56:35 CEST] <JEEBsv> it's a moving target, so anything that grabs videos from sites is bound to be "wacky" or a "hack". The sites can change or block you at any point.
[16:56:39 CEST] <klaxa|work> would it be so hard to make youtube-dl into a library with C-bindings?
[16:56:48 CEST] <JEEBsv> and that kind of shit really should not go into a demuxer
[16:57:00 CEST] <JEEBsv> youtube-dl works just fine how mpv is using it
[16:57:25 CEST] <JEEBsv> it gets the stream and pushes it to the demuxers
[16:57:27 CEST] <JEEBsv> *streams
[16:57:31 CEST] <[fade]> greetings, anyone know how to cut a piece of the video out? like from 2:30 to 3:50? I spend like 3 hours using multiple solutions, nothing works
[16:57:34 CEST] <klaxa|work> oh right, i forgot they do that, do they just call the shellscript?
[16:57:43 CEST] <JEEBsv> it's a python script, but yes
[16:57:43 CEST] <[fade]> using avconv
[16:57:46 CEST] <JEEBsv> it's internally called
[16:58:02 CEST] <mtcjayne> So basically it's not even a Kodi issue.
[16:58:11 CEST] <mtcjayne> It's a Kodi YouTube add-on issue.
[16:58:18 CEST] <BtbN> I don't think xbmc is a bad place to implement a dash demuxer in.
[16:58:22 CEST] <BtbN> It already does so for hls.
[16:58:24 CEST] <mtcjayne> Since they're basically Python anyway
[16:58:32 CEST] <JEEBsv> mtcjayne: or well some plugin, yes
[16:58:41 CEST] <JEEBsv> if it can feed the stuff to the actual demuxers
[16:58:43 CEST] <klaxa|work> [fade]:
[16:58:48 CEST] <mtcjayne> There is even a Kodi youtube-dl library
[16:58:51 CEST] <BtbN> xbmc plugins can't feed raw video.
[16:58:57 CEST] <BtbN> They can only send urls to play.
[16:58:59 CEST] <[fade]> thank you klaxa
[16:59:04 CEST] <JEEBsv> ah
[16:59:21 CEST] <JEEBsv> BtbN: actual true DASH demuxer could go into lavf but it's a real mess and would require xml parsers etc
[16:59:29 CEST] <JEEBsv> or well
[16:59:32 CEST] <JEEBsv> input?
[16:59:34 CEST] <JEEBsv> not sure
[16:59:53 CEST] <mtcjayne> (Where are IRC logs? I'd like this for a record...)
[17:00:03 CEST] <JEEBsv> nfi
[17:00:14 CEST] <BtbN> yes, i don't see an issue with a conformant DASH demuxer.
[17:00:34 CEST] <BtbN> But i see an issue with people sending patches for it, to make it play non-conformant files which they found in the wild.
[17:00:57 CEST] <[fade]> depends on your irc client mtcjayne
[17:01:07 CEST] <mtcjayne> I'm on webchat.
[17:01:48 CEST] <[fade]> in that case, i doubt it has such option
[17:01:50 CEST] <JEEBsv> BtbN: although it goes close to playlists
[17:02:17 CEST] <BtbN> HLS does, but DASH isn't realy comparable to playlists.
[17:02:29 CEST] <BtbN> HLS is nothing more than a fancy playlist.
[17:02:30 CEST] <JEEBsv> HLS is a whole separate piece of horse shit
[17:03:48 CEST] <[fade]> is it possible to remove a piece of the media out using ffmpeg? all i found is cutting and saving that piece, not cutting as in removing it
[17:03:56 CEST] <mtcjayne> BtbN if plugins can only pass URLs does that mean a plugin could demux the DASH XML or no?
[17:04:21 CEST] <BtbN> Nope, it can't.
[17:04:39 CEST] <[fade]> that was an answer to my question, BtbN ?
[17:04:51 CEST] <BtbN> Nope
[17:04:54 CEST] <[fade]> okai :/
[17:04:57 CEST] <mtcjayne> Hmm. At this time I don't see how Kodi would be able to support DASH in any capacity then.
[17:05:08 CEST] <mtcjayne> Due to design decisions they've made.
[17:05:11 CEST] <c_14> [fade]: cut and then concat
[17:05:35 CEST] <[fade]> can you give a bit more info c_14 ? i spend 2+ hours trying multiple options, no sucess
[17:06:17 CEST] <JEEBsv> mtcjayne: can it take input from stdin?
[17:06:55 CEST] <c_14> [fade]: either create 2 files using -ss and -t that contain the parts you want and then use the concat demuxer, or create the 2 parts using trim in a filtegraph and concat with the concat filter
[17:06:59 CEST] <JEEBsv> if yes, then just run youtube-dl yourself and make it output to stdout and pipe to xbmc
[17:07:28 CEST] <BtbN> i don't think you can pipe to xbmc
[17:07:39 CEST] <BtbN> As it's usualy already running
[17:07:48 CEST] <mtcjayne> JEEBsv at that point users would be better served by a standalone media player called by a Kodi add-on.
[17:07:52 CEST] <mtcjayne> I believe.
[17:08:07 CEST] <[fade]> i see, thank you c_14
[17:08:25 CEST] <mtcjayne> Like the addons which can start game emulators and whatnot.
[17:08:29 CEST] <JEEBsv> well if you could just plug mpv there then you could be golden :P
[17:08:38 CEST] <JEEBsv> since mpv can internally call youtube-dl
[17:08:59 CEST] <JEEBsv> mpv "url-to-my-dirty-laundry-videos"
[17:09:36 CEST] <mtcjayne> I'll also contact the guy(s) who made youtube-dl and see if he/they have advice on an implementation.
[17:10:31 CEST] <mtcjayne> I'm beginning to think "hacky" is what Kodi is going to have to aim for. Or "wontfix"
[17:10:53 CEST] <JEEBsv> you can take a look at the mpv youtube-dl code if ye want
[17:11:16 CEST] <mtcjayne> That too.
[17:17:09 CEST] <mtcjayne> Thank you for your comments and discussion
[19:26:54 CEST] <kyleogrg> greetings
[19:26:59 CEST] <kyleogrg> opus
[19:27:25 CEST] <kyleogrg> opus vs aac - is opus better in every way??
[19:30:49 CEST] <Plorkyeran> not compatibility
[19:31:08 CEST] <Plorkyeran> other than that it's not worse than aac
[19:31:13 CEST] <Plorkyeran> at worst
[19:35:59 CEST] <kyleogrg> so it's definitely at least a good as AAC (except compatability)?
[19:38:23 CEST] <kyleogrg> same or better quality at same file size?
[19:41:52 CEST] <c_14> kyleogrg: https://opus-codec.org/comparison/ if you trust comparisons made by the people who designed the codec in the comparison
[19:42:14 CEST] <kyleogrg> c_14: yeah, i've seen that.  do you trust it?
[19:42:51 CEST] <c_14> Whenever I encode to a lossy audio format I use opus, so&
[19:43:39 CEST] <kyleogrg> it's probably fair to say it's very competitive with aac
[19:44:47 CEST] <c_14> yeah
[20:57:06 CEST] <canbal> Anyone know how to register the decoder for timed_id3? I dont want to compile the libs and register all codecs using av_register_all(). However without this  avformat_find_stream_info() hangs
[21:22:35 CEST] <Fyr> guys, how to calculate psnr for audio with ffmpeg?
[21:45:10 CEST] <llogan> Fyr: i don't think you can
[21:46:18 CEST] <Fyr> =(
[21:46:32 CEST] <llogan> perform ABX testing instead.
[22:26:34 CEST] <dna_592> jkhkj
[22:26:35 CEST] <dna_592> hi
[22:27:41 CEST] <dna_592> i'm a developer, and new to ffmpeg libraries, i'm working on a project and even with the code finished i can't compile it
[22:28:10 CEST] <dna_592> it always send me the same message "undefined reference to "av_frame_alloc""
[22:28:46 CEST] <dna_592> i did some research but didn't find anything helpfull
[22:28:52 CEST] <dna_592> can u guys help me?
[22:29:48 CEST] <Fyr> dna_592, I recommend ##ffmpeg-devel
[22:30:15 CEST] <dna_592> ok
[22:30:16 CEST] <dna_592> ty
[23:06:33 CEST] <llogan> Fyr: #ffmpeg-devel is not for user help
[23:58:00 CEST] <kittonian> hi all. i just got a 12-core mac pro (24 threads) and though it is definitely faster doing command line transcoding over my quad-core mac pro 1,1, when i look in activity monitor it only shows 1 thread being used. i tried setting -threads 23 but it still only showed it using 1 thread. is this correct?
[00:00:00 CEST] --- Fri May  1 2015