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

[burek]

[00:03:04 CET] <cone-193> ffmpeg 03Michael Niedermayer 07master:40063a900b6d: ffserver: Clear avio context after closing it
[00:03:04 CET] <cone-193> ffmpeg 03Michael Niedermayer 07master:a00cc2e40d40: ffserver: Clear avio context after closing it in rtp_new_av_stream()
[00:03:04 CET] <cone-193> ffmpeg 03Will Kelleher 07master:0eac93da0fd5: qsvenc: write a53 caption data to SEI
[01:06:33 CET] <rcombs> alright, I think all I need to finish up this patch series is a lavf version bump
[01:10:01 CET] <rcombs> does adding fields to  AVOutputFormat need a minor or a micro bump?
[01:10:30 CET] <rcombs> also, adding a new public API to lavf
[01:13:31 CET] <jamrial> minor
[01:14:26 CET] <rcombs> jamrial: for both?
[01:14:32 CET] <rcombs> (they're in different commits)
[01:14:33 CET] <jamrial> yeah
[01:14:34 CET] <jamrial> micro is for things like new avoptions in decoders/demuxers, or changes to existing ones
[01:14:42 CET] <rcombs> alright
[01:15:07 CET] <jamrial> if they are going to be commited at the same time, you can probably just bump once for both
[01:16:00 CET] <rcombs> should that go in the second bump-needing commit, or in a separate one?
[01:18:09 CET] <jamrial> in the second should be ok
[01:24:55 CET] <jamrial> rcombs: you should also add a couple lines to apichanges
[01:25:05 CET] <rcombs> oh good point
[01:25:17 CET] <rcombs> and maybe to to Changelog as well
[01:28:29 CET] <jamrial> if it's just a new API then apichanges is enough
[01:28:39 CET] <jamrial> you're not adding a new component or feature
[01:30:20 CET] <rcombs> I'd call it a feature, even if it's not exposed as one
[01:38:28 CET] <wm4> sometimes API changes are indeed in the changelog
[01:38:38 CET] <wm4> "not exposed"?
[01:43:49 CET] <rcombs> wm4: like, it's not a new public API or component or anything
[01:44:28 CET] <rcombs> it's new internal handling that makes some things easier
[01:45:20 CET] <wm4> but it makes live easier for the API user by not having to do the BSFing manually, right?
[01:45:28 CET] <rcombs> yeah
[01:45:36 CET] <rcombs> or the ffmpeg.c user
[01:49:08 CET] <wm4> well that makes it even more visible
[01:49:17 CET] <wm4> and should definitely be mentioned in the changelog
[02:02:52 CET] <cone-193> ffmpeg 03Ganesh Ajjanagadde 07master:5a41a5a4f57d: avfilter/af_compand: use hypot()
[02:02:53 CET] <cone-193> ffmpeg 03Ganesh Ajjanagadde 07master:7b11eead1b4e: avcodec/ac3: always use hardcoded tables
[11:15:52 CET] <JEEB> do I see correctly that MPEG-2 Video doesn't have >8bit coding? It does have intra_dc_precision but that seems to be something else, right?
[13:19:40 CET] <kierank> JEEB: correct
[13:27:16 CET] <cone-627> ffmpeg 03Michael Niedermayer 07master:8e7f4520226d: avformat/dump: Fix integer overflow in av_dump_format()
[13:27:16 CET] <cone-627> ffmpeg 03Michael Niedermayer 07master:3a9cb18855d2: avutil/integer: Fix av_mod_i() with negative dividend
[13:27:17 CET] <cone-627> ffmpeg 03Michael Niedermayer 07master:25e37f5ea92d: avutil/mathematics: Do not treat INT64_MIN as positive in av_rescale_rnd
[14:46:39 CET] <ubitux> lol poor Ganesh is on rampage
[14:50:51 CET] <wm4> ...
[14:55:51 CET] <ubitux> that "FFMPEG API" is going to be golden
[14:55:56 CET] <ubitux> +thread
[15:04:23 CET] <BtbN> QNAP is using ffmpeg for the Media Transcoding in their NAS!
[15:04:34 CET] <BtbN> ffmpeg version 0.8.10, Copyright (c) 2000-2011 the FFmpeg developers, built on Nov 18 2015 03:42:44 with gcc 4.8.2 20131014 (prerelease)
[15:05:05 CET] <BtbN> And they build it with --disable-yasm.
[15:05:23 CET] <wm4> something something idiots
[15:05:24 CET] <kierank> if they are remuxing probably not a big deal
[15:05:29 CET] <kierank> but yes if they are transcoding yes
[15:05:32 CET] <BtbN> They are transcoding.
[15:05:40 CET] <kierank> from what to what?
[15:05:46 CET] <wbs> BtbN: is it x86 or something else?
[15:05:50 CET] <BtbN> arm
[15:06:02 CET] <wm4> then --disable-yasm is just redundant
[15:06:22 CET] <wbs> wm4: cargo culted configure options, who would have ever heard of that
[15:06:34 CET] <BtbN> kierank, basicaly everything you want. They built a Transcode-WebUI
[15:06:53 CET] <wm4> it's always fun when one of those uncountable combinations of configure flags actually cause problems
[15:07:10 CET] <BtbN> It's actualy a quite short configure line.
[15:07:22 CET] <BtbN> --prefix=/opt/cross-project/arm/linaro/arm-linux-gnueabihf/libc/usr --enable-cross-compile --cross-prefix=arm-linux-gnueabihf- --disable-static --enable-shared --disable-yasm --arch=arm --target-os=linux --disable-armvfp --enable-gpl --disable-encoder=snow --disable-decoder=snow
[15:08:24 CET] <BtbN> Hm, enable-gpl though.
[15:08:25 CET] <wm4> why disable the best codec
[15:08:58 CET] <wm4> but I suppose they still want to encode to SVQ
[15:09:04 CET] <wm4> (really, why disable snow specifically)
[15:13:17 CET] <atomnuker> they must hate wavelets
[15:15:36 CET] <fritsch> or they don't know what it is
[15:16:06 CET] <fritsch> or fell in love with fourier 20 years ago and are afraid of getting further spatial information
[15:16:10 CET] <fritsch> one does not know
[15:20:33 CET] <wm4> fritsch: btw. did you say you'd bisect the mp4 mp3 failure?
[15:20:40 CET] <wm4> or was that someone else
[15:20:49 CET] <fritsch> wm4: i could - if it is wanted
[15:21:02 CET] <fritsch> someone said, that we should talk with the handbrake dev before that
[15:21:25 CET] <wm4> yeah, I didn't follow this so well (I know there was some other change that fixed something else)
[15:21:28 CET] <fritsch> i was the oppinion that if "quicktime cannot play it - one dos not have to care too much"
[15:21:35 CET] <fritsch> yes, this one:
[15:21:40 CET] <wm4> that's probably true
[15:21:51 CET] <fritsch> https://trac.ffmpeg.org/ticket/4938
[15:21:56 CET] <fritsch> fixes something similar
[15:22:15 CET] <fritsch> would be funny if this commit would break the new file :-)
[15:22:38 CET] <wm4> depends what the default for parsing is
[15:22:53 CET] <fritsch> bisecting should be easy to do
[15:23:04 CET] <fritsch> as one can just use ffplay and directly see if it's working
[15:23:06 CET] <fritsch> on master
[15:23:11 CET] <fritsch> while start at ~ 2.7
[16:14:41 CET] <BBB> nevcairiel: thanks for the review, I found a bigger issue that seems to cover all cases mozilla reported in a single patch
[16:14:46 CET] <BBB> nevcairiel: so & gj!
[16:16:10 CET] <durandal_1707> can somebody make me permanent op on #ffmpeg?
[16:18:59 CET] <BBB> oh, also, mozilla apparently ships ffvp9: https://bugzilla.mozilla.org/show_bug.cgi?id=1210219
[16:19:01 CET] <BBB> I didnt know that
[16:19:21 CET] <BBB> maybe I should give firefox a try again, chrome doesnt ship ffvp9
[16:20:50 CET] <fritsch> wm4: dies reverting the mentioned "fix" make it work again?
[16:21:01 CET] <wm4> fritsch: didn't try yet
[16:29:38 CET] <ubitux> fucking threading
[16:29:41 CET] <ubitux> i hate it so much
[16:30:12 CET] <ubitux> atomic signaling which aren't shit atomic
[16:32:15 CET] <wm4> what's your problem?
[16:32:28 CET] <wm4> and what isn't atomic?
[16:34:10 CET] <ubitux> see http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184281.html
[16:34:42 CET] <ubitux> two senders are waiting, the receiver is able to signal unlock and re-acquire the fucking mutex before any of the other wakes up
[16:35:21 CET] <wm4> well, pthread_cond_signal is basically an optimization to wake up only exactly 1 thread
[16:35:30 CET] <ubitux> yes but not instantly
[16:35:46 CET] <ubitux> apparently
[16:35:51 CET] <wm4> ?
[16:36:10 CET] <ubitux> look at the log
[16:36:47 CET] <wm4>     RECEIVER: acquired lock
[16:36:47 CET] <wm4>     RECEIVER: reading a msg from the queue
[16:36:47 CET] <wm4>     RECEIVER: signal the cond
[16:36:47 CET] <wm4>     RECEIVER: acquired lock
[16:36:49 CET] <wm4> no unlock?
[16:37:01 CET] <ubitux> i just didn't print it
[16:37:04 CET] <ubitux> but it unlocks
[16:37:12 CET] <ubitux> (after signal)
[16:37:46 CET] <JEEB> def/win28
[16:37:52 CET] <JEEB> welp, sorry
[16:38:12 CET] <wm4> if senders can block, then a single signal is definitely wrong
[16:38:26 CET] <wm4> hm
[16:38:28 CET] <wm4> or is it
[16:38:40 CET] <ubitux> it wouldn't be wrong if there were 2 conditions
[16:38:59 CET] <ubitux> i'm going the simple way and broadcasting everyone
[16:39:13 CET] <ubitux> (both recv & senders everytime)
[16:39:25 CET] <wm4> is it even supposed to have multiple readers and writers?
[16:39:47 CET] <ubitux> now it is
[16:40:04 CET] <ubitux> and i'm assuming yes
[16:40:17 CET] <ubitux> since it's used like this in ffmpeg.c
[16:40:23 CET] <ubitux> (1 thread per file)
[16:40:40 CET] <ubitux> (used for packets queue)
[16:40:52 CET] <wm4> sounds fine then (but why does ffmpeg.c need that)
[16:41:58 CET] <ubitux> -i in1 -i in2 -i in3 ...
[16:42:04 CET] <ubitux> parallel demuxing
[16:42:17 CET] <wm4> shouldn't it have multiple queues then?
[16:46:18 CET] <ubitux> dunno, didn't look closely
[16:51:52 CET] <nevcairiel> BBB: i'm not sure i like the new patch, it makes integration with hwaccel harder, can we have a way that only sets ctx->pix_fmt in one place, ever? :)
[16:52:57 CET] <nevcairiel> BBB: maybe write into s->pix_fmt and only set ctx->pix_fmt in update_size?
[16:54:09 CET] <ubitux> what's up with the mozilla reports btw? the security ml just got flooded by them or sth?
[17:09:17 CET] <nevcairiel> they started using ffmpeg over gst recently
[17:09:18 CET] <nevcairiel> iirc
[17:09:45 CET] <ubitux> ah, yeah right ok
[17:09:54 CET] <Daemon404> over gst? sadface
[17:10:03 CET] <nevcairiel> i mean, instead of
[17:10:08 CET] <Daemon404> OH
[17:10:11 CET] <Daemon404> ok
[17:31:13 CET] <BBB> nevcairiel: ctx->pix_fmt is only set in read_colorspace_details(), so Im not sure theres an issue
[17:32:59 CET] <BBB> nevcairiel: I guess youre concerned because you want a single place where updates to ctx->pix_fmt are callbacked into hwaccel, right?
[17:33:07 CET] <BBB> nevcairiel: I think that doesnt change, its still update_size()
[17:47:27 CET] <Mo_YouVisit> Hello!
[17:54:12 CET] <Mo_YouVisit> I have been looking into converting equirectangular panoramic video into cubic video, but have not come across anyone who has created an FFMPEG filter for doing so.
[17:54:34 CET] <Daemon404> tha sounds incredibly niche
[17:54:36 CET] <Daemon404> so i am not surprised
[17:54:38 CET] <Mo_YouVisit> I would like to avoid having to write the filter from scratch, does anyone know of someone who has been working on something similar or a forum where I can ask around?
[17:54:50 CET] <Mo_YouVisit> Thats what I figured
[17:56:11 CET] <durandal_1707> do you have samples of both videos
[17:56:27 CET] <Mo_YouVisit> Yes
[17:56:29 CET] <wm4> here's the right place to ask I'd say
[17:56:55 CET] <Mo_YouVisit> There are applications that convert Equirectangular videos to Cubic but it requires the conversion to happen manually and we would like to automate the process
[17:57:47 CET] <durandal_1707> I can write it if I know how it works
[17:58:04 CET] <Mo_YouVisit> That would be amazing, I already found a Java implementation that works
[17:58:13 CET] <durandal_1707> application name?
[17:58:34 CET] <durandal_1707>  Java is trivial to RE
[18:00:11 CET] <nevcairiel> BBB: there is 4 lines that set ctx->pix_fmt
[18:00:18 CET] <Mo_YouVisit> What is RE, I thought ffmpeg filters were written in C?
[18:00:20 CET] <Compn> Mo_YouVisit : i remember reading about a filter to convert files into a 360 , like omnimax . lets see if i can find it
[18:00:31 CET] <nevcairiel> BBB: in distinctly different places in the code
[18:00:38 CET] <Mo_YouVisit> The java code can be found here http://os.ivrpa.org/panosalado/downloads in EquirectangularToCubic.zip
[18:00:56 CET] <Mo_YouVisit> The conversion is doen in Equi2Rect.java
[18:01:27 CET] <BBB> nevcairiel: theyre all inside read_colorspace_details, or in the bug clause surrounding intraonly frames (where that syntax element is missing from the bitstream)
[18:01:29 CET] <BBB> nevcairiel: so ...
[18:01:36 CET] <BBB> nevcairiel: what is your practical worry?
[18:01:37 CET] <nevcairiel> BBB: personally I would just use s->pix_fmt everywhere in vp9.c, and only sync that to ctx->pix_fmt when needed, ie. never actually read ctx->pix_fmt
[18:01:49 CET] <nevcairiel> thats how most other decoders work
[18:01:49 CET] <BBB> but that reintroduces the bug
[18:01:56 CET] <nevcairiel> how so
[18:01:58 CET] <durandal_1707> Mo_YouVisit: than its even easier
[18:02:04 CET] <BBB> where s->bytesperpixel is not in sync with ctx->pix_fmt
[18:02:16 CET] <nevcairiel> why does it matter, s-> is private, and if ctx->pix_fmt is never read
[18:02:20 CET] <BBB> if read_csp_details ssets s->bytesperpixel, it needs to set ctx->pix_fmt also
[18:02:26 CET] <nevcairiel> i cant read the damn mozilla bug because they are paranoid tards
[18:02:32 CET] <BBB> theres nothing in it
[18:02:34 CET] <BBB> just a file
[18:02:42 CET] <Mo_YouVisit> durandal_1707: how so?
[18:03:21 CET] <nevcairiel> BBB: in practice, any place that sets ctx->pix_fmt needs to call the hwaccel code and handle errors and whatnot
[18:03:29 CET] <nevcairiel> I like to have that once
[18:03:39 CET] <nevcairiel> not 4 times
[18:03:49 CET] <BBB> so lets do it in update_size()?
[18:03:58 CET] <BBB> what hwaccel code do we need to call?
[18:04:08 CET] <durandal_1707> Mo_YouVisit: I will look at it when I go back home
[18:04:55 CET] <nevcairiel> thats what I was suggesting, just don't ever read ctx->pix_fmt and only set it in update_size, instead use (a new) s->pix_fmt throughout the entire decoder, then this one doesn't desync, and no harm is done
[18:05:02 CET] <Mo_YouVisit> durandal_1707: Thank you! I will stay on IRC, just in case my email is mo.ben at youvisit.com 
[18:05:06 CET] <BBB> nevcairiel: we cant do that
[18:05:09 CET] <nevcairiel> why not
[18:05:15 CET] <BBB> nevcairiel: ctx->pix_fmt is used for buffer allocation
[18:05:21 CET] <BBB> so we need to set that, not a placeholder
[18:05:32 CET] <BBB> its functionally confirmed in update_size
[18:05:36 CET] <nevcairiel> are buffers allocated before update_size?
[18:05:44 CET] <BBB> nope, but theres error paths before it
[18:06:09 CET] <nevcairiel> then i dont see the problem
[18:06:13 CET] <BBB> so right now the error path allows us to a) set s->bytesperpixel, b) set s->pix_fmt (although its a local variable), then error out
[18:06:22 CET] <BBB> and never reach c) set ctx->pix_fmt
[18:06:29 CET] <BBB> this causes the two to be out of sync
[18:06:40 CET] <BBB> then the next (inter) frame continuous where internal state left off (being invalid)
[18:06:44 CET] <Compn> Mo_YouVisit: nevermind, cant find what i was looking for.
[18:06:45 CET] <BBB> continues
[18:06:50 CET] <BBB> and all kind of shit happens
[18:06:54 CET] <nevcairiel> which doesnt really do harm, you didnt reach any code that would need it, and the next frame would call update_size and update ctx->pix_fmt if needed
[18:06:55 CET] <BBB> so I want them to always be synced
[18:06:58 CET] <Mo_YouVisit> Compn: Thats ok, thanks for the help!
[18:07:13 CET] <BBB> the next frame never calls update_size
[18:07:22 CET] <BBB> because the internal state is inconsistent
[18:08:12 CET] <BBB> you reviewed the original patch, you can see that we check for subsample+bpp changes through fmt
[18:08:19 CET] <BBB> if fmt never changes because we went into an error path
[18:08:23 CET] <BBB> the buffers are never reallocated
[18:08:34 CET] <BBB> but internal variables like s->bpp and so on are changed
[18:08:37 CET] <BBB> thats a huge issue
[18:08:40 CET] <nevcairiel> i don't see how changing which variable you check against makes any kind of difference there
[18:08:51 CET] <nevcairiel> you do the same check
[18:09:06 CET] <BBB> ok, lets start from zero
[18:09:19 CET] <durandal_1707> Mo_YouVisit: do you have input samples?
[18:09:20 CET] <BBB> do you see how s->bytesperpixel and ctx->pix_fmt get inconsistent in the current code?
[18:09:33 CET] <BBB> if you trigger an error path between read_colorspace_details and update_size
[18:09:41 CET] <BBB> (of which theres a couple)
[18:10:35 CET] <BBB> regardless of whether that inconsistency is a problem or not, just, do you see theyll be inconsistent
[18:10:38 CET] <nevcairiel> thats why I am suggesting you introduce s->pix_fmt which is always in sync with s->bpp, then you can use both these variables to check the internal state, and always keep everythign fine and dandy - and all that on top of your current patch which adds last_fmt to track changes
[18:11:02 CET] <nevcairiel> just only have one central place as late as possible that updates ctx->pix_fmt
[18:11:06 CET] <BBB> but why
[18:11:06 CET] <nevcairiel> like, in update_size
[18:11:15 CET] <BBB> I dont see why add an extra variable thats just a copy
[18:11:19 CET] <BBB> soooooo many variables
[18:11:26 CET] <nevcairiel> because its not a copy for hwaccel
[18:11:48 CET] <nevcairiel> s->pix_fmt would be yuv420p while ctx->pix_fmt would be pix_fmt_dxva2
[18:11:50 CET] <nevcairiel> or something
[18:11:57 CET] <nevcairiel> that allows you to still do the proper checks
[18:12:10 CET] <BBB> aaaaaaha
[18:12:10 CET] <BBB> ok
[18:12:14 CET] <BBB> that starts to explain things
[18:12:20 CET] <BBB> so you dont ever want me to check ctx->pix_fmt, ever
[18:12:24 CET] <nevcairiel> right
[18:12:35 CET] <nevcairiel> never read that one, as hwaccels change it
[18:12:36 CET] <BBB> ctx->pix_fmt should be write-only
[18:12:50 CET] <BBB> now were getting somewhere
[18:12:51 CET] <BBB> ok
[18:14:33 CET] <nevcairiel> it was a bit annoying in my current hwaccel patch as it is, but because you used a local variable i could work around it
[18:14:45 CET] <nevcairiel> but by moving the setting into the reading function, it gets difficult
[18:15:14 CET] <BBB> ok, Ill change that
[18:15:45 CET] <durandal_1707> how this filter should be named?
[18:15:58 CET] <BBB> re-testing with asan, will take an hour or so
[18:16:07 CET] <BBB> (compiling ffmpeg is sooooooooooooo sloooooooooooooow)
[18:16:44 CET] <nevcairiel> there is still one weird thing left regarding pixfmts
[18:16:54 CET] <nevcairiel> because vp9 is so crazy and supports ref frames in different sizes
[18:17:23 CET] <BBB> that doesnt affect pixfmt though
[18:17:35 CET] <nevcairiel> no, but there is a check that checks if the ref is the same pixfmt
[18:17:42 CET] <nevcairiel> which can be slightly difficult
[18:17:46 CET] <nevcairiel> i'll have to re-visit that
[18:18:09 CET] <BBB> is the avframe->format using hwaccel or native pixfmt?
[18:18:14 CET] <nevcairiel> hwaccel
[18:18:17 CET] <nevcairiel> which is the problem
[18:18:22 CET] <BBB> hum&. right
[18:18:27 CET] <nevcairiel> i'll think on that
[18:18:32 CET] <nevcairiel> dont worry about it yet
[18:18:43 CET] <BBB> that would mean its currently broken right?
[18:18:54 CET] <nevcairiel> i hacked around it in an ugly way
[18:19:00 CET] <BBB> ?
[18:19:19 CET] <nevcairiel> I told it to consider a hwaccel foirmat equal to yuv420p
[18:19:31 CET] <nevcairiel> which is generally true, but still ugly
[18:19:55 CET] <BBB> hahahahha
[18:19:57 CET] <BBB> so ugly
[18:20:57 CET] <nevcairiel> actually
[18:21:13 CET] <nevcairiel> hm no
[18:21:51 CET] <nevcairiel> well i'll think on a solution
[18:22:15 CET] <nevcairiel> there is also a problem with the location of that check
[18:22:31 CET] <nevcairiel> it checks the format before update_size is called, so it doesnt even know if the hwaccel is used
[18:22:43 CET] <nevcairiel> maybe I need to move that to another place to be sure
[18:24:17 CET] <nevcairiel> will have to re-visit this
[18:24:45 CET] <BBB> better this way?
[18:24:48 CET] <BBB> (new patch on ML)
[18:25:15 CET] <BBB> nevcairiel: we can move that check down, its not critical where its placed, just that its done before read_header returns
[18:25:23 CET] <BBB> so moving it below update_size is called is fine
[18:28:24 CET] <nevcairiel> BBB: patch looks fine, a quick grep shows ->pix_fmt isnt accessed anywhere else otherwise, so that seems ok
[18:28:37 CET] <BBB> right, I ctrl-fed that also :-p
[19:04:20 CET] <Mo_YouVisit> durandal_1707: I have an input uploaded here: http://video-us-east-1.youvisit.com/242477/2880_30_3.mp4 I guess it would make sense for it to be named EquirectangularToCubic
[19:05:42 CET] <Compn> Mo_YouVisit : did you see this https://github.com/eVRydayVR/ffmpeg-unwarpvr/
[19:06:12 CET] <Compn>  i guess thats just unwarping some edges for occulus rift
[19:07:02 CET] <Mo_YouVisit> Compn: Yes I have, that is just to remove barrel distortion like you said
[19:10:50 CET] <Compn> i thought there was another one
[19:10:51 CET] <Compn> for mplayer
[19:11:10 CET] <Compn> possibly using opengl for panoramic warping
[19:11:21 CET] <Compn>  guh if i can find it
[19:11:30 CET] <Compn>  not important i guess
[19:15:06 CET] <Compn> yes
[19:15:13 CET] <Compn> planetarium mplayer
[19:15:23 CET] <atomnuker> how does filter_complex deal with files having different bit depths?
[19:15:32 CET] <atomnuker> swscale?
[19:15:57 CET] <nevcairiel> probably
[19:16:02 CET] <nevcairiel> depends on what filters you use
[19:16:35 CET] <wm4> filters can announce what formats they want on their inputs
[19:17:15 CET] <Compn> ah thats just distorted fishe ye
[19:17:58 CET] <Mo_YouVisit> Yeah, there are a lot of distortion correction filters out there but not many for changing between projections
[19:18:12 CET] <Compn> fair enough, sorry for the noise : )
[19:18:23 CET] <Mo_YouVisit> No problem, appreciate the help!
[19:26:40 CET] <Compn> whos working on filters and wants to merge that unwarp filter?  https://github.com/eVRydayVR/ffmpeg-unwarpvr/
[19:26:45 CET] <Compn> ubitux?
[19:26:48 CET] <Compn> :P
[19:26:54 CET] Action: Compn runs
[19:27:06 CET] <fritsch> wm4: starting to bisect now
[19:29:31 CET] <charlie_youvisit> if the unfolded cube is this
[19:29:34 CET] <charlie_youvisit> http://imgur.com/xtt2UZ3
[19:29:59 CET] <charlie_youvisit> with faces labeled as Left, Front, Right, Back, Up, Down
[19:30:15 CET] <charlie_youvisit> we'd like the final video to be packaged like this:
[19:30:22 CET] <charlie_youvisit> http://imgur.com/2PiDuh3
[19:33:27 CET] <charlie_youvisit> where the black bar is an 8 bit separation to avoid compression artifacts
[19:34:01 CET] <charlie_youvisit> *8 pixel, not 8 bit
[19:39:58 CET] <kierank> interesting discovery today that dirac decoder has bugs
[19:45:44 CET] <Compn> are bbc still using dirac ?
[19:46:26 CET] <kierank> yes
[19:46:28 CET] Action: kierank is too
[19:46:36 CET] <atomnuker> didn't you hear, wavelets are the next big thing in video encoding
[19:47:00 CET] Action: atomnuker realizies it's not 2004 and wavelets suck for low-bitrate stuff
[19:51:34 CET] <ubitux> Compn: i don't care
[19:51:38 CET] <fritsch> wavelets :-)
[19:51:39 CET] <fritsch> hehe
[19:51:40 CET] <ubitux> but thx i guess
[19:51:47 CET] <fritsch> the train is already driven further ...
[19:51:56 CET] <fritsch> after it was quite popular at our institute ...
[19:53:58 CET] <Daemon404> atomnuker, bbc uses it as a mezzanine, as is tradition
[19:54:04 CET] <Daemon404> so no low bitrate
[19:54:58 CET] <fritsch> I also think it's not really ture what @atomnuker said - at least not in general
[19:55:02 CET] <fritsch> and not for all pairs
[19:55:08 CET] <fritsch> (there are too many specialized)
[19:55:40 CET] <fritsch> s/pairs/families/
[19:56:05 CET] <Daemon404> it's true for all practical purposes currently
[19:56:43 CET] <fritsch> makes me wonder a bit, cause already in 90s special wavelet for very low bitrate video has been suggested
[19:57:29 CET] <Daemon404> we also loved VQ and codebooks in the 90s ;)
[19:57:30 CET] <fritsch> hybrids, using the wavelet for the intraframe pictures
[19:57:34 CET] <fritsch> hehe
[20:10:55 CET] <Compn> zlib, zlib everywhere!
[20:13:57 CET] <TD-Linux> well wavelets are still around, vp9 and daala use wavelets for lossless
[20:14:29 CET] <fritsch> as they are in industrial image processing for defect classification
[20:14:35 CET] <TD-Linux> daala also uses the haar wavelet for screencasting because it performs better on text than the DCT
[20:14:41 CET] <fritsch> and if there is no argument left, you say: jpeg 2000
[20:15:23 CET] <TD-Linux> I've actually seen good jpeg 2000 encoders!
[20:15:45 CET] <TD-Linux> but most, along with jpeg 2000 and the selection of the 9/7 wavelet, are based around hyperoptimizing PSNR
[20:16:48 CET] <durandal_1707> I will just push my filters without waiting for ganesh approval, as he appears to dislike me in general
[20:17:23 CET] <llogan> which filters?
[20:19:30 CET] <fritsch> TD-Linux: performs better means: better compression while psnr still better ,right?
[20:19:51 CET] <fritsch> TD-Linux: which is kind of clear for the edges that this text has ...
[20:22:48 CET] <durandal_1707> llogan: sidechaingate, apulsator, aemphasis
[20:24:50 CET] <TD-Linux> fritsch, yeah, looks better at the same bitrate
[20:24:51 CET] <llogan> durandal_1707: i looked at apulsator docs. LGTM other than a few nits that I don't care about, but i'm sure ganesh will point them out.
[20:25:39 CET] <llogan> (i forgot to send apulsator LGTM email/noise earlier)
[20:26:17 CET] <TD-Linux> also wavelets are used for DC coeffs in H264 and daala as well, in the former for speed, in the latter for flexibilty with varying block size
[20:26:46 CET] <fritsch> yeah I wondered that the others sounded that negative about them
[20:26:53 CET] <TD-Linux> really the only place they died was for the primary transform for natural images, where they give a worse coding gain.
[20:27:39 CET] <llogan> Timothy_Gu: did you ever look into a twitter bot to squawk releases? (I didn't) someone on twitter complained about my slowness/laziness. i don't tihnk it's important unless you are bored and want to look busy in class
[20:28:09 CET] <TD-Linux> they were overhyped because they gave ridiculous PSNR numbers, and for features that no one wanted (multiresolution images), hence the hate :)
[20:28:31 CET] <fritsch> TD-Linux: in germany the state "sponsored" new science project - if you had "wavelets" in the name ...
[20:28:44 CET] <fritsch> so everyone started to be a wavelet specilist
[20:29:10 CET] <fritsch> for classification: find the wavelet that displays the defect best ... while a simple highpass would have been sufficient
[20:29:21 CET] <fritsch> or using the scales ... "just for fun"
[20:29:25 CET] <fritsch> this is a scale 7 error
[20:29:29 CET] <fritsch> this one a scale 4
[20:29:37 CET] <fritsch> and classifiing on the scale
[21:23:05 CET] <durandal_1707> is checking for cabs and cexp enough for aemphasis?
[21:35:30 CET] <durandal_1707> ok so if there's no more comments I gonna push aemphasis
[21:40:30 CET] <Daemon404> g 42
[21:41:30 CET] <llogan> durandal_1707: several users have wanted to change color of background and waveforms for showwavespic. what do you think about that feature?
[21:48:51 CET] <durandal_1707> ah, they can do something with colorchannelmixer
[21:49:22 CET] <durandal_1707> but showwaves filter outputs into gray only
[21:49:58 CET] <durandal_1707> could open bug report maybe saste wants to work on that
[21:51:13 CET] <llogan> i gave a shitty example using colorbalance
[21:51:44 CET] <llogan> ill make the feature request. maybe later today.
[21:58:43 CET] <cone-202> ffmpeg 03Paul B Mahol 07master:cde75e3150ff: avfilter/vf_histogram: remove deprecated stuff
[22:06:00 CET] <durandal_1707> you can use colorlevels too
[22:12:06 CET] <cone-202> ffmpeg 03Michael Niedermayer 07master:736e2e2c3008: avfilter/vf_shuffleframes: Assert that the case of an uninitialized ret does not occur
[22:12:27 CET] <ubitux> why is ff_aac_tableinit inlined in a .h?
[22:16:50 CET] <KGB> [13FFV1] 15dericed opened pull request #15: Definition updates (06master...06definition-updates) 02http://git.io/vRvIR
[22:17:52 CET] <andrey_utkin> hi! would a change to vf_scale introducing per-frame reevaluation of scaling factor, allowing to use timestamp/frame number as constant, be welcome? I need to implement "popping" of overlays. Got it working with large sendcmd files, but that's ugly. I see no other way.
[22:50:37 CET] <Daemon404> ubitux, liekly because it is shared in the enc and dec
[22:56:17 CET] <fritsch> wm4: [6ec688e1bc76dd93151cbca1c340162ae4b10d77] mp3: enable packed main_data decoding in MP4
[22:57:15 CET] <wm4> ok
[22:57:23 CET] <fritsch> i will bisect to finish (1 step left)
[22:57:38 CET] <fritsch> but I am quite sure that's exactly it
[22:58:22 CET] <fritsch> you see the commit? i really wonder what this commit does
[22:58:27 CET] <fritsch> especially at the beginning
[22:58:44 CET] <fritsch> it removes some "framesize" checking
[22:58:49 CET] <fritsch> and enables AVSTREAM_PARSE_FULL
[22:59:14 CET] <fritsch> i will update the bugreport after bisecting is finishd
[22:59:25 CET] <wm4> seems like it rather removes AVSTREAM_PARSE_FULL, except in a special case
[22:59:27 CET] <fritsch> but from an uneducated guess it seems the parse_full is not working
[22:59:32 CET] <fritsch> jep
[23:00:02 CET] <wm4> but I really wonder why does it change the decoder and a single demuxer at the same time
[23:01:46 CET] <fritsch> is luca barbato online here?
[23:01:53 CET] <fritsch> "In order to accept this, this patch removes unnecessary frame size checking on mp3 decoder.
[23:01:56 CET] <fritsch> "
[23:02:05 CET] <fritsch> i always find it funny if it seems - that those were necessar
[23:02:06 CET] <fritsch> y
[23:02:40 CET] <nevcairiel> the real problem in that patch is limiting the parsing to a few select samples only
[23:02:45 CET] <fritsch> yes
[23:02:56 CET] <fritsch> that seems "adventurous"
[23:03:01 CET] <fritsch> (in the right spelling of course)
[23:04:04 CET] <wm4> fritsch: he's lu_zero on Libav, but talking to him would be rude, because you're using and discussing FFmpeg, not Libav
[23:04:52 CET] <j-b> fritsch: query lu_zero and he will answer
[23:05:40 CET] <fritsch> wm4: okay
[23:05:45 CET] <fritsch> i don't want to be rude :-)
[23:05:54 CET] <fritsch> i just reverted his patch, fixed the hunks
[23:05:59 CET] <fritsch> and will now retest latest stable
[23:06:08 CET] <fritsch> this bug has caused me headaches a very long time
[23:06:12 CET] <fritsch> not only in this special mp4
[23:06:21 CET] <fritsch> but always from time to time with handbrake encodes
[23:06:31 CET] <wm4> I mean as long as you don't assume lu_zero is a ffmpeg dev it's probably ok
[23:06:40 CET] <fritsch> ah okay
[23:06:47 CET] <fritsch> i thought this libav / ffmpeg thing is over
[23:06:47 CET] <wm4> but then I'd also try to reproduce it with Libav
[23:06:54 CET] <wm4> haha, no
[23:07:03 CET] <wm4> (and reasonably speaking, ffmpeg could have broken it on merge)
[23:07:09 CET] <fritsch> a let's see
[23:07:17 CET] <fritsch> what cehoyos says
[23:07:30 CET] <nevcairiel> better dont
[23:07:37 CET] <nevcairiel> it'll just frustrate you
[23:07:52 CET] <fritsch> hahaha
[23:08:00 CET] <fritsch> hihi - i love people with principles :-)
[23:08:08 CET] <fritsch> if that fritsch guy does not provide ffmpeg -i info
[23:08:12 CET] <fritsch> i won't say thank you
[23:08:14 CET] <fritsch> it's okay :-)
[23:09:11 CET] <fritsch> Okay - let's play this game - i bet he checks it himself - as he is eager to close the bug
[23:09:30 CET] <fritsch> while I think from a user pov I invested enough time ...
[23:10:54 CET] <kierank> michaelni: did you see the ffv1 segfault?
[23:16:31 CET] <nevcairiel> fritsch: i think he just meant to point out that he already identified the regression in his comment
[23:16:47 CET] <fritsch> nevcairiel: ah!
[23:16:57 CET] <fritsch> man, if he would communicate more clearly
[23:17:10 CET] <fritsch> i could have saved myself that bisect
[23:17:40 CET] <fritsch> yeah - there it is
[23:17:43 CET] <fritsch> but he was not sure .-)
[23:17:55 CET] <fritsch> Regression since ae215e2b / 6ec688e1
[23:18:02 CET] <fritsch> 6ec688e1 <- was it in deed
[23:18:13 CET] <nevcairiel> one is the commit, the other is the commit that merged it
[23:21:01 CET] <fritsch> oki
[23:21:03 CET] <fritsch> thx
[23:22:02 CET] <fritsch> oki
[23:22:07 CET] <fritsch> (including a typo)
[23:23:10 CET] <nevcairiel> reverting should only be the last resort, usually there was a reason for the commit in the first place - fixing one sample at the expense of another is going to turn weird fast
[23:24:14 CET] <fritsch> when reading the commit message
[23:24:20 CET] <fritsch> i think it is even wrong
[23:24:23 CET] <nevcairiel> in this case specifically, wm4 already send a patch always enabling parsing again in movdec, and apparently that breaks something
[23:24:42 CET] <fritsch> let me test something
[23:25:14 CET] <wm4> yes, I got 2 failing samples, but didn't pursue it further
[23:25:36 CET] <wm4> (my patch might just be complete garbage)
[23:26:27 CET] <fritsch> http://sprunge.us/hWUJ
[23:26:33 CET] <fritsch> ^^ yours also does this, right?
[23:26:52 CET] <nevcairiel> nah it removes another block of guessing
[23:26:54 CET] <nevcairiel> there is two now
[23:27:00 CET] <fritsch> okay
[23:27:02 CET] <nevcairiel> but end result is the same
[23:27:05 CET] <nevcairiel> parse full is set
[23:27:29 CET] <fritsch> wm4: can you link me the non working sample?
[23:27:34 CET] <nevcairiel> https://dl.dropboxusercontent.com/u/76042064/packed_maindata.mp3.mp4
[23:28:04 CET] <wm4> yes, that
[23:28:05 CET] <fritsch> yeah :-)
[23:28:33 CET] <fritsch> btw. my old mpv version that played "the denis sample" also fails with this one
[23:28:45 CET] <fritsch> gstreamer stutters
[23:28:55 CET] <fritsch> makes tuut ... tuuut
[23:29:00 CET] <wm4> and quicktime?
[23:29:10 CET] <fritsch> mpg123 fails to decode
[23:29:20 CET] <fritsch> only linux here, sorry
[23:29:37 CET] <fritsch> so - if ffmpeg cannot play _this_ fail it's not really a regression :-)
[23:29:48 CET] <fritsch> but the denis file is played by all others / including older ffmpeg version
[23:29:53 CET] <nevcairiel> if it works today and doesnt tomorrow, its a regression
[23:29:54 CET] <nevcairiel> :D
[23:30:04 CET] <fritsch> this worked?
[23:30:20 CET] <nevcairiel> i would assume the linked file works wiith current git master
[23:30:32 CET] <wm4> meanwhile I'm trying to write a recursive function in shell (god, fuck shell)
[23:30:36 CET] <fritsch> it does not work with ffmpeg 2.7.3
[23:30:42 CET] <nevcairiel> thats not git master
[23:30:42 CET] <nevcairiel> :P
[23:30:52 CET] <fritsch> wait I try
[23:30:54 CET] <fritsch> with master
[23:30:56 CET] <fritsch> two seconds
[23:31:00 CET] <wm4> was 2.7.3 before that change that broke it?
[23:31:12 CET] <fritsch> that's the funny part: i cannot say exactly
[23:31:19 CET] <fritsch> first I bisected between 2.7.0 and latest master
[23:31:22 CET] <fritsch> and only got bad
[23:31:29 CET] <fritsch> then I started earlier 2k14
[23:31:43 CET] <durandal_1707> wm4: so what doesn't suck?
[23:31:48 CET] <fritsch> this packed_maindata.mp3.mp4 is broken with master, too
[23:31:49 CET] <fritsch> :-)
[23:31:54 CET] <fritsch> so not sure which regression you search
[23:32:24 CET] <nevcairiel> 6ec688e1bc76dd is not in 2.7, it was commited in june, long after the 2.7 branch
[23:32:33 CET] <fritsch> good
[23:32:42 CET] <wm4> durandal_1707: nothing, but shell sucks a _lot_
[23:33:04 CET] <wm4> it's literally like trying to do precision mechanics with stone age tools
[23:33:11 CET] <fritsch> nevcairiel: okay - so basically there is no ffmpeg versio nat all that can play your dropbox file?
[23:33:18 CET] <durandal_1707> what you need shell for?
[23:33:28 CET] <fritsch> can windows media player play it :-)
[23:33:28 CET] <wm4> durandal_1707: ffmpeg's build system
[23:33:38 CET] <wm4> can vlc play it?
[23:33:51 CET] <wm4> can anything? what can?
[23:33:56 CET] <fritsch> wm4: don't you also have a computer? :-)
[23:34:24 CET] <wm4> yeah, but just enough time to waste my time on irc
[23:34:57 CET] <fritsch> i tried mplayer, mpv, ffmpeg 2.7.3, ffmpeg-master, ffmpeg-master with the revert we talked, mpg123, totem
[23:35:03 CET] <fritsch> no one made that play
[23:35:17 CET] <durandal_1707> Start wmp...
[23:35:33 CET] <fritsch> need a windozer for this
[23:35:49 CET] <fritsch> but before you search regression you should find a version that actually played it (TM)
[23:36:39 CET] <durandal_1707> old mplayer
[23:36:50 CET] <fritsch> is there a non old mplayer?
[23:36:54 CET] <fritsch> durandal_1707: that means you can play it?
[23:37:07 CET] <durandal_1707> nah
[23:37:26 CET] <nevcairiel> fritsch: using ffmpeg master it errors a lot on the console, but the audio isnt too broken
[23:37:29 CET] <fritsch> vlc does not detect the stream
[23:37:42 CET] <fritsch> nevcairiel: the same is true for the denis sample
[23:37:58 CET] <fritsch> do you use ffplay to actually hear what comes out?
[23:38:11 CET] <nevcairiel> nah i dont have sdl, i transcoded to flac :D
[23:39:02 CET] <fritsch> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/204316
[23:39:04 CET] <fritsch> ^^ so
[23:44:07 CET] <cbsrobot-> packed_maindata.mp3.mp4 cannot be played in quicktime
[23:45:16 CET] <fritsch> cbsrobot-: thx
[23:45:37 CET] <fritsch> nevcairiel: i reverted the wrong commit from master, when retesting plain master - ffplay from master can play it
[23:46:58 CET] <fritsch> good night
[23:47:23 CET] <cbsrobot-> durandal_1707: are you still interested in filter propositions ?
[23:51:29 CET] <durandal_1707> cbsrobot-: which one?
[23:54:50 CET] <cbsrobot-> durandal_1707: implementing LEQ(A) LEQ(M) and/or ITU-R 468 audio meter
[23:55:36 CET] <durandal_1707> hmm is there some documentation?
[23:56:03 CET] <durandal_1707> lavfi have peak meter
[23:56:08 CET] <cbsrobot-> bacly https://en.wikipedia.org/wiki/ITU-R_468_noise_weighting
[23:56:20 CET] <cbsrobot-> it's a weighted meter
[23:59:24 CET] <nevcairiel> could probably steal the K weighting from the ebur128 filter and modify the weights for the 468 curve
[00:00:00 CET] --- Wed Dec  2 2015