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

[burek]

[00:27] <cone-846> ffmpeg.git 03wm4 07master:a66893ac9498: avformat/utils: check for malloc failure
[00:27] <cone-846> ffmpeg.git 03wm4 07master:a963fdb0ea3f: lavu/dict: check for malloc failures
[02:23] <Compn> i always wanted to make a bonzai tree though.
[02:52] <cone-846> ffmpeg.git 03Lou Logan 07master:10ef8f063bfa: doc: add FFREPORT example
[03:14] <jamrial> Daemon404: any idea why your icl fate machine started to fail the vc1 tests three weeks ago?
[04:19] Action: Compn late to the bpg party
[04:21] <jamrial> what party?
[04:28] <Compn> the 'lets burn webp party'
[04:28] <Compn> :P
[07:40] <arwa> Can anyone give me a list of filters in which fft is used?
[08:45] <j-b> 'morning
[12:01] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:b898c49ba1b6: avfilter/vf_uspp: assert that the qp_type is valid
[12:01] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:792a5004a14e: avfilter/vf_uspp: Add grayscale support
[12:05] <michaelni> arwa, "git grep -l fft libavfilter/*.c" might produce a list of such filters in libavfilter, why do you ask ?
[12:07] <arwa> because I had a talk with saste regarding my next task, and we decided to go with - http://david.li/filtering/
[12:09] <arwa> Though, right now I have started porting fspp, I think to go with fft next.
[12:19] <ubitux> dctdnoiz already uses such mechanism
[14:20] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:498396f80c2e: avfilter/vf_unsharp: use av_freep() avoid leaving stale pointers in memory
[14:20] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:43fb40c3c321: avfilter/vf_kerndeint: use av_freep(), avoid leaving stale pointers in memory
[16:29] <cehoyos> michaelni: The uspp filter always initializes the snow encoder with PIX_FMT_YUV420P, no matter the input pix_fmt of the filter: Is this correct?
[16:36] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:d7de48f0df82: avformat/mov: Simplify code by using OFFSET() and FLAGS macros
[16:36] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:3ab82e9206fe: avcodec/libxvid_rc: Avoid strerror() for thread saftey
[16:36] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:5d0cfb58ef99: avcodec/dvdsubdec: Avoid strerror() due to thread saftey
[17:27] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:354fda7698bf: avfilter/vf_uspp: fix used pix_fmt
[17:27] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:3dd5f7aaa091: avfilter/vf_uspp: fix used chroma subsampling factors
[17:27] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:609a73b6ff30: avfilter/vf_uspp: fix gray pixfmt handling
[17:42] <ubitux> michaelni: how does this chroma subsampling works with odd dimensions?
[17:42] <ubitux> you sure we don't need FF_CEIL_RSHIFT()?
[17:44] <wm4> michaelni: should the h264 decoder _always_ behave the same as if the codec was freshly opened after avcodec_flush_buffers()?
[17:44] <michaelni> ubitux, FF_CEIL_RSHIFT is probably needed, want to fix it ?
[17:44] <ubitux> michaelni: not really :)
[17:44] <ubitux> maybe arwa can do it and test it though
[17:45] <wm4> michaelni: this file seems to make it behave differently; after seeking back to the start (i.e.  avcodec_flush_buffers() + feeding the same packets again), it outputs a different frame with different timestamp: http://filebin.ca/1kVfSxfnFpxa/excerpt_000.mkv 
[17:45] <michaelni> ubitux, good idea
[17:45] <wm4> michaelni: the file is probably broken, so you don't need to care much, but maybe avcodec_flush_buffers() is supposed to be more robust in general
[17:46] <michaelni> wm4, without having looked at the file yet, its possible i think
[17:54] <nevcairiel> in some streams its possible that behaviour changes slightly, ie. if you dont have extradata, and you decoded a few packets and it got SPS/PPS from them, and you then flush and start over, it will be able to start decoding earlier since the flush wouldnt clear the SPS/PPS AFAIK
[17:54] <nevcairiel> but thats an unlikely explanation for mkv
[18:48] <ubitux> fucking AVPicture
[18:49] <wm4> haha
[18:50] <wm4> let's hate it together!
[18:50] <ubitux> my main complain currently is that i need to move that whole crap to lavu before i can move the subtitles themselves
[18:50] <ubitux> because there is "AVPicture" in the subtitles struct, which is part of the ABI
[18:50] <wm4> michaelni: the same user posted another file that exhibits this issue; apparently it's produced by some camera: http://filebin.ca/1kWAopaL0YC0/P1000424.MP4
[18:50] <ubitux> (and API)
[18:51] <wm4> isn't the AVPicture struct source compatible to AVFrame?
[18:51] <ubitux> ?
[18:52] <wm4> and also ABI compatible, in a way (there are still plenty of API users who alias AVPicture and AVFrame)
[18:52] <wm4> well, both have data and linesize fields at the same offsets
[18:52] <wm4> so I'm wondering if #define AVPicture AVFrame could work
[18:52] <wm4> of course it's break ABI of AVSubtitle
[18:53] <wm4> hmm, also sizeof(AVFrame) is not part of ABI, so maybe it won't work
[18:53] <ubitux> after thinking quite a bit about the issue i'm trying to solve, the saner approach is first to move the AVSubtitle* to lavu (just like it was done with AVFrame)
[18:54] <ubitux> the issue is that there is a "AVPicture pict" in one of these struct
[18:54] <wm4> hm, yeah
[18:54] <ubitux> and these struct are public; changing this even with an alias is going to cause a nice shitstorm
[18:54] <ubitux> so i'm first moving the the AVPicture, but i'm not exactly sure if i can move the code itself
[18:55] <ubitux> ...and i'm kind of uncomfortable moving only the header (defining the struct) to lavu
[18:56] <nevcairiel> the hevc decoder is weird. on this particular stream, everytime a IRAP frame arrives, it discards any delayed frames and doesn't output them, which results in missing frames of course, and I can't tell if the bitstream is just broken or the decoder has a bug.
[18:56] <ubitux> (the next step is to add heap allocation function for AVSubtitle and make them mandatory; but i want to make such changes when it's in its definitive place -- lavu)
[18:57] <ubitux> (so i can later add fields to AVSubtitle etc)
[18:57] <wm4> ubitux: API users will hate you for such incremental steps too
[18:57] <ubitux> what do you mean?
[18:57] <wm4> especially if they're hard to notice (like changing a public struct from user-alloctable to a mandatory alloc function)
[18:57] <ubitux> moving to lavu makes no api change
[18:57] <wm4> ok
[18:57] <ubitux> that's the point
[18:58] <ubitux> and when it's in lavu we can work on rebuilding it
[18:58] <ubitux> i initially planed to rebuild the whole thing in a new structure in lavu, but it was way too big and couldn't be done incrementally
[18:59] <ubitux> (like, i had to redesign the bitmap representation etc, i can't do that mixed with text reworking etc)
[18:59] <wm4> whatever you do, if breaking changes are needed, make sure the API user has to do it only once
[18:59] <ubitux> so yeah, 1) move to lavu with no user change (abi or api)
[18:59] <wm4> but it's probably better to just add a new API
[18:59] <ubitux> 2) make it possible to change it with heap alloc
[18:59] <ubitux> 3) change the api.
[18:59] <wm4> and leave the old one around (still working)
[18:59] <ubitux> no really, it's not
[19:00] <wm4> maybe for you (as ffmpeg developer)
[19:01] <ubitux> the problem is that adding a new structure means i have to redesign the whole thing, and it's going to be too much
[19:01] <Daemon404> [17:57] <@ubitux> moving to lavu makes no api change <-- god i love library incest
[19:01] <Daemon404> moving it to a *different lib* makes no api change?
[19:01] <ubitux> like, i started adding a brand new AVTextSubtitle but i actually needed to have the bitmap version as well
[19:01] <ubitux> and so it was causing way too much changes
[19:02] <ubitux> Daemon404: it's just the header definition
[19:02] <ubitux> Daemon404: lavc already has a dep on lavu and will include the lavu header to make it transparent
[19:02] <ubitux> the structures don't change
[19:02] <Daemon404> yes, it's only nto noticable due to incest/inbreeding
[19:03] <ubitux> see 7ecc2d403ce5c7b6ea3b1f368dccefd105209c7e
[19:04] <Daemon404> yes that should have had an api num bump
[19:04] <Daemon404> because someone did it in the past doesnt make it correct
[19:05] <ubitux> yeah i'll probably bump indeed
[19:05] <ubitux> but technically, it should be transparent for the app
[19:05] <Daemon404> "the app" being ffmpeg
[19:05] <ubitux> and really, it's a step needed if i want to evolve the api
[19:05] <Compn> ubitux : so instead of moving text encoding detection from demuxer to lavu, we should just make the config file call the subtitle demuxer to detect encoding ? :)
[19:05] <ubitux> if i'm starting to design a brand new subtitle api, i need to rethink the whole text and bitmap thing, as well as eventually cc and shit
[19:05] <Compn> if i understand it correctly ...
[19:06] <ubitux> and given the time it took me to figure out what to do with just text
[19:06] <Daemon404> well i dont really think subtitles should be in lavu
[19:06] <Daemon404> but :V
[19:06] <ubitux> i don't want to start an endless design discussion that will take years to figure out
[19:06] <Compn> ubitux : just do whatever it is that you will maintain
[19:06] <ubitux> Daemon404: and you think AVFrame has its place here?
[19:06] <Compn> and ignore the haters! 
[19:06] <Compn> maintainer rights ! :)
[19:06] <Daemon404> ubitux, i do not, no
[19:07] <ubitux> Daemon404: well, that's a design decision that makes sense to me (think lavfi)
[19:07] <Daemon404> the only reason things get shoved into lavu is that people are in denial about the libraries intertangledness
[19:07] <Compn> (libav will rewrite it anyway)
[19:07] <ubitux> i know you don't like it but well..
[19:07] <Daemon404> so it feels "less dirty" to put it in "utilities"
[19:07] <ubitux> the point is making a common structure for lavc and lavfi
[19:07] <wm4> AVFrame is just in lavu because they didn't want lavfi to depend on lavc
[19:07] <Daemon404> yep.
[19:07] <wm4> (cue to canned laughter)
[19:07] <ubitux> yes, and that's my point as well for subtitles
[19:08] <Daemon404> so basically
[19:08] <Daemon404> [18:07] <@Daemon404> the only reason things get shoved into lavu is that people are in denial about the libraries intertangledness
[19:08] <ubitux> and also now, i want subtitles to be treated the same as frames
[19:08] <ubitux> because they're the same layer
[19:08] <wm4> and you have these problems all because you pretend the libs are independent
[19:08] <ubitux> Compn: this is not about text encoding stuff; i don't want to deal with that 
[19:08] <wm4> it would be easier if you'd drop that
[19:08] <Compn> wm4 : tell that to j-b ?
[19:08] <ubitux> wm4: i'm fine with merging all the libs into one
[19:09] <wm4> Compn: well j-b is a fan of this idea too, I think
[19:09] <ubitux> wm4: but that's not a decision i want to make just for subtitles
[19:09] <Compn> one lib to rule them all
[19:09] <ubitux> i doubt j-b will be a fan of having a "libffmpeg" pulling hundreds of filters
[19:09] <ubitux> but well.
[19:10] <Compn> i've asked j-b to include lavfi in vlc...
[19:10] <kierank> Compn: lol
[19:10] <Compn> iirc he said no
[19:10] <iive> Compn: you are still alive. this is a good sign.
[19:10] <Compn> it takes a lot to kill an mplayer troll
[19:11] <iive> lol
[19:11] <Daemon404> i think if you ask j-b, hell give you his usual response to what he wants separated
[19:11] <Daemon404> "PUT THE CLI IN A SEPARARTE REPO THAN ITS LIBS"
[19:11] <Compn> but like everyone who hated lavfi when it started, the only people who matter are the users. and the users want filtering, all the filters.
[19:11] <Daemon404> caps and emphasis his.
[19:11] <wm4> hm yeah what did j-b want again
[19:11] <wm4> was it merging all libs, or separating them _properly_?
[19:12] <wm4> j-b: ping
[19:12] <Daemon404> i dont know.
[19:12] <j-b> wm4: pong
[19:12] <j-b> are we trolling again?
[19:12] <wm4> yes
[19:12] <wm4> troll time
[19:12] <j-b> that's why you ping me?
[19:12] <j-b> EVERYTHING IS CRAP :)
[19:12] <j-b> what's the question?
[19:12] <wm4> j-b: your thoughts about the library separation
[19:12] <j-b> Do it
[19:13] <j-b> libavutil
[19:13] <Compn> we should get fabrice back here to take ffmpeg into the next level. javascript ffmpeg.
[19:13] <j-b> libavcodec+libavformat, until decoupled
[19:13] <j-b> libavfi
[19:13] <j-b> etc..
[19:13] <Daemon404> you mean lavf+libavdevice+lavc obv
[19:13] <wm4> what would you rather habe? merge them all into one physical lib? or decouple them completely?
[19:13] <Daemon404> since libavdevice canablizes lavf
[19:13] <Daemon404> ;)
[19:13] Action: Daemon404 runs
[19:13] Action: ubitux suggest to add libbpg to the ffmpeg repository
[19:13] <j-b> and ffmpeg/avconv/what-not, aka tools in a splitted one
[19:13] Action: Compn +1 on libbpg
[19:13] <j-b> wm4: of course split them
[19:14] <j-b> wm4: some can't be decoupled for now: aka lavc+lavf
[19:14] <Daemon404> j-b, you act as if having mplayer in a separate rpeo ever stopped the inbreeding and internals abuse ;)
[19:14] <j-b> but the rest has no reason to.
[19:14] <j-b> Daemon404: point taken
[19:14] <Compn> Daemon404 : i think what j-b wants is for us to work on the libs and drop ffmpeg cli itself
[19:14] <wm4> j-b: what about things like AVFrame, which have to do a lot to do with video, but are not libc replacements like most of lavu?
[19:14] <j-b> No
[19:14] <kierank> Compn: nice straw man
[19:14] <Compn> :)
[19:14] <ubitux> Compn: no, they won't have an example of code anymore :(
[19:14] <Compn> could be wrong...
[19:14] <j-b> Compn: I want you to eat the same food you give us
[19:15] <wm4> well said
[19:15] <Daemon404> well they do eat it
[19:15] <j-b> aka, have ffmpeg/ffprobe/ffwhatever handle multiple libavcodec/libavformat versions
[19:15] <Compn> j-b : if vlc has problem with some code, why not just send patch to fix whatever the problem is ?
[19:15] <Daemon404> thats why apis are designed solely for ffmpeg cli
[19:15] <wm4> <j-b> aka, have ffmpeg/ffprobe/ffwhatever handle multiple libavcodec/libavformat versions <-so sadistic :)
[19:15] <ubitux> j-b: isn't what actually debian/ubuntu packages are doing?
[19:15] <ubitux> afaict they have a different package for tools
[19:15] <ubitux> relying on libs
[19:15] <Compn> j-b : why not just use internal ffmpeg and abandon versions ? :P
[19:15] <wm4> ubitux: they're trying it, badly
[19:15] <ubitux> or i'm wrong?
[19:15] <j-b> and have people be able to upgrade ffmpeg, because of a cool feature that ubitux does, without having to upgrade libavcodec
[19:15] <Compn> >mplayer
[19:16] <Daemon404> wm4, luckily most of my code only has to support HEAD
[19:16] <wm4> ubitux: the result is that the too close coupling in combination with separate packages per lib only causes problems
[19:16] <Daemon404> or id have offed myself long ago
[19:16] <j-b> or because a new flag was introduced
[19:16] <iive> j-b: what about merging all libraries into a single one. libffmpeg ?
[19:16] <kierank> iive: noooo
[19:16] <kierank> nooo
[19:16] <wm4> Daemon404: I support multiple releases of ffmpeg and libav
[19:16] <Daemon404> yes ive been down that road before
[19:16] <j-b> iive: what's the use-case?
[19:16] <wm4> and it's terrible
[19:17] <j-b> Anyway, I really need to run
[19:17] <Daemon404> j-b, one could argue: what's the use case of split libs
[19:17] <Daemon404> ok cya
[19:17] <kierank> Daemon404: not having to add 20MB of crap to my static builds
[19:17] <j-b> Daemon404: all multimedia frameworks have a split between codec, demuxers and input
[19:17] <Daemon404> if the libraries werent coded insanely, a linker could actually do that for you
[19:18] <iive> j-b: no inter lib dependency. a lot of external structures would become internal, easier to change things without breaking external applications.
[19:18] <Daemon404> kierank, you should try static linkign with libraries that arent coded in such a way that force you to included 20mb of code you dont use when linking
[19:18] <Daemon404> it's great.
[19:19] <ubitux> j-b: i would say it's possible in theory; but honestly can't tell
[19:19] <ubitux> i believe we're kind of careful on such issues
[19:19] <kierank> Daemon404: i'm a little pleased nobody said i should use shared libs
[19:19] <wm4> Daemon404: so you want support for enabling only individual codecs at link-time?
[19:20] <Daemon404> wm4, no
[19:20] <Daemon404> but teh way codecs are inited and such causes them to ALL be included
[19:20] <Daemon404> because theyre all registered
[19:20] <Daemon404> and such
[19:20] <Daemon404> DCE and work properly
[19:20] <Daemon404> cant*
[19:20] <wm4> that's what I said... so you want "av_register_codec(av_codec_h264());" or something
[19:21] <wm4> so the linker can pull in things that are required, and ignore all the other codecs
[19:21] <Daemon404> wasnt that the api with the hilarious circular dep problem
[19:21] <Daemon404> i.e. you need it registered to get he id, but you need teh id to register
[19:21] <Daemon404> or something
[19:21] <wm4> the current codec register API is worthless and broken, yes
[19:21] <JEEB> yeah, or at least it's not exactly simple to use. tried to help someone on #ffmpeg with that
[19:21] <JEEB> because you can only list the codecs by already having them registered
[19:22] <Daemon404> michaelni tried to fix it, im not sure what came of that
[19:22] <JEEB> you can only register stuff that you create yourself, pretty much?
[19:22] <wm4> Daemon404: there's now an API for whitelisting codecs per context
[19:22] <cehoyos> nevcairiel: the hevc decoder is weird. on this particular stream <- which stream is this?
[19:26] <nevcairiel> cehoyos: http://www.demo-uhd3d.com/fiche.php?cat=uhd&id=22
[19:26] <nevcairiel> unfortunately, the site is somewhat slowish
[19:26] <Daemon404> those take ages dl yeah
[19:26] <Daemon404> i think they rate limit
[19:26] <Daemon404> a lot.
[19:27] <Daemon404> different routing made no diff for me
[19:27] <nevcairiel> i think i found the part of the spec that the decoder ignores, but my understanding is not good enough to be certain
[19:28] <kierank> Daemon404: yeah they block threaded download too
[19:28] <Daemon404> yes
[19:29] <cehoyos> Smart idea to combine zip with a slow download speed so you cannot interrupt easily...
[19:29] <cehoyos> nevcairiel: Didn't you have your own ftp server?
[19:30] <nevcairiel> its a TS file so i could probably just cut it into pieces
[19:30] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:53496aa7f3d1: avformat/utils: Do not estimate the container bitrate from the streams if one video stream lacks the bitrate
[19:34] <nevcairiel> if anyone else cares to investigate, the spec says no_output_of_prior_pics_flag should only be evaluated if NoRaslOutputFlag is 1 (which it only is on the first IRAP at the beginning or after a flush), instead our decoder does it always
[19:41] <nevcairiel> cehoyos: http://files.1f0.de/samples/big/UHD_ENT_Transformer_Quad_chunk_0.ts
[19:43] <nevcairiel> its technically a regression since 2eddf3a6efd80aa6e9d7f42ad9a892a82c5ece70 which implemented this feature (incompletely, apparently)
[19:43] <cehoyos> That's faster, thank you
[19:46] <cehoyos> Defintitely a regression, I will open a ticket tomorrow if you don't beat me.
[19:47] <cehoyos> Do you get audio??
[19:47] <nevcairiel> i might do it later with the technical details i found
[19:47] <nevcairiel> i do get audio
[19:48] <cehoyos> I get audio too now, but not with ffmpeg -i file ;-(
[19:48] <nevcairiel> i overwrite the default analyze duration and whatnot, so maybe that helps
[19:49] <cehoyos> No, not related to analyzeduration and probesize
[19:50] <cehoyos> Audio is also a regression...
[19:52] <cehoyos> Sorry, it does work with increased analyzduration, I had a typo in my command line.
[22:18] <cone-962> ffmpeg.git 03Michael Niedermayer 07master:d5a263f480fb: fix "than" typo
[22:18] <cone-962> ffmpeg.git 03Rob Sykes 07master:4b6f2253741f: swresample/soxr_resample: fix error handling
[23:35] <cone-962> ffmpeg.git 03Clément BSsch 07master:d823edee8d34: avcodec: fix wording in AVSubtitleRect doxy
[00:00] --- Sun Dec 14 2014