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

[burek]

[00:00] <cone-621> ffmpeg.git 03Anton Khirnov 07master:73bb8f61d48d: hevcdsp: remove an unneeded variable in the loop filter
[00:01] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:226b290f9f73: Merge commit '73bb8f61d48dbf7237df2e9cacd037f12b84b00a'
[00:27] <cone-621> ffmpeg.git 03Pierre Edouard Lepere 07master:1a880b2fb845: hevc: SSE2 and SSSE3 loop filters
[00:27] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:706f81a2c275: Merge commit '1a880b2fb8456ce68eefe5902bac95fea1e6a72d'
[00:36] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:d4a9e89b2796: avcodec/x86/hevcdsp_init: make license header consistent
[00:36] <cone-621> ffmpeg.git 03James Almer 07master:bfb3b2b7a6ec: x86/hevc_idct: add 12bit idct_dc
[01:24] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:8b1d54ba40ff: doc/examples/muxing: free swr context at the end
[01:25] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:a98cadef7fe1: doc/examples/muxing: Move samples_count to OutputStream
[01:25] <cone-621> ffmpeg.git 03Anton Khirnov 07master:22e9fe06ebb6: doc/examples/muxing: add alloc_audio_frame() and use it to simplify code.
[01:30] <J_Darnley> Well clang still can't compile ffmpeg here.
[01:30] <J_Darnley> I don't know why I was so disappointed though.
[01:56] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:fbd46e2f1cae: doc/examples/muxing: Always use swr, simplifies code slightly
[01:56] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:d1ce43a3e8fe: doc/examples/muxing: mark correct frame as writeable
[02:23] <cone-621> ffmpeg.git 03Diego Biurrun 07master:7215fcf84032: avformat: Mark AVOutputFormat argument in avformat_query_codec as const
[02:23] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:57e7d9d92978: Merge commit '7215fcf84032118ecd9fb54fb14154d69fea638d'
[02:29] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:29228dbd24fd: fate/hevc: add BUMPING bitstream test
[02:37] <michaelni> mraulet, about adcdabb4dd062694fb8de6df0faecaad1c36ba33, is it completely useless to test the older files ?
[02:38] <michaelni> because that seemed to remove them
[02:50] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:7bb3e70c06ea: fate/hevc: add flags unaligned
[02:50] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:e97f5bef95a2: fate/hevc: adding CONFWIN_A conformance test
[03:57] <cone-621> ffmpeg.git 03Chris \"Koying\" Browet 07master:ad91bf854b55: avcodec/h264_mp4toannexb_bsf: fix issue when sps/pps are already in the bistream
[10:02] <ubitux> michaelni: sad & diff_pixels are needed externally currently or not yet?
[11:59] <michaelni> ubitux, "libavfilter/vf_deshake.c:    #define CMP(i, j) deshake->c.sad[0](NULL, src1 + cy * stride + cx, \"
[11:59] <michaelni> ubitux, libavfilter/vf_mpdecimate.c:            pdsp->diff_pixels(block,
[12:04] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:c437765be762: doc/examples/muxing: Exchange tmp_frame and frame
[12:36] <cone-621> ffmpeg.git 03Anton Khirnov 07master:541427ab4d5b: eamad: use the bytestream2 API instead of AV_RL
[12:36] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:c2ef844aa74c: Merge commit '541427ab4d5b4b6f5a90a687a06decdb78e7bc3c'
[12:46] <ubitux> michaelni: i don't consider them external
[12:46] <michaelni> well ABI wise they are external
[12:47] <ubitux> accessing them through avpriv is not ok?
[12:48] <ubitux> currently that what we do, unless i'm mistaken
[12:48] <michaelni> i really dont care, but you pile up APIs that must be maintained for years
[12:49] <michaelni> i mean avpriv in libavutil, then if its used externally add av and then whatever libav will use
[12:49] <ubitux> i just wanted to make sure it wasn't that urgent to export sad & friends properly
[12:49] <ubitux> so i can do that properly
[12:49] <ubitux> you were talking about the debian packaging; by that you were talking about dct stuff for mplayer typically, no?
[12:49] <michaelni> no
[12:50] <ubitux> :(
[12:50] <ubitux> i don't understand the issue & hurry then
[12:50] <michaelni> libavfilter is AFAIK a seperate package in how libav is packaged and how the various ffmpeg debian packages are packaged but i didnt double check
[12:51] <michaelni> so libavfilter is external as far as debian & ubuntu are concerned
[12:52] <ubitux> it's external but they can access avpriv symbols nevertheless
[12:52] <ubitux> so basically avpriv_dsputil_init() should still be accessible
[12:52] <ubitux> i guess the concern is about ABI stability?
[12:54] <michaelni> yes, didnt i say this in my patch?
[12:55] Action: michaelni has the feeling people had only the goal to flame and didnt care beyond that
[12:55] <michaelni> "This provides a public sustainable API/ABI for DSP functions."
[12:56] <michaelni> the goal was to add something that can be kept compatible and can be extended long term
[12:56] <michaelni> i understand people dont like its "dsputil look"
[12:56] <michaelni> but that sadly is the easiest way to do it
[12:57] <ubitux> there is nothing that hard in exporting it properly, but yes i requires some little more amount of time
[12:57] <ubitux> i was just wondering about the urgency
[12:57] <michaelni> it should have been fixed years ago really
[12:59] <michaelni> but IMO fixing it before 2.4 is pretty much mandatory
[13:00] <ubitux> sure
[13:00] <ubitux> when is 2.4?
[13:00] <michaelni> in the past we didnt notice as it worked in practice, but now as we noticed we should not leave such ABI issue unfixed
[13:00] <ubitux> really i was just asking if i need to submit a patch tonight or if i have one week or two to make things clean
[13:01] <michaelni> a week should be fine
[13:01] <ubitux> ok
[13:01] <ubitux> (note: i'm just working on the lavu/pixelutils one)
[13:01] <ubitux> (with the different sad & diff)
[13:02] <michaelni> but note, if by the time of 2.4 release i have no other solution then i will push the one we have as i refuse to release with such a bug in the ABI
[13:02] <ubitux> can you do the AVDCT one?
[13:03] <michaelni> i sure can rename the stuff
[13:03] <michaelni> and remove non dct 
[13:04] <michaelni> about radically changing API to fast/slow style i have no idea how to do that
[13:04] <michaelni> removing arch specific identifiers i can do too but i see only disadvantages from that
[13:05] <michaelni> it would make debuging harder
[13:05] <michaelni> if we ever need to debug
[13:05] <iive> are you talking about dct?
[13:06] <michaelni> yes
[13:06] <iive> fast/slow is wrong metrics... a number of algorithms have specific error tolerance that is needed for properly decoding some samples
[13:07] <michaelni> the suggestion was fast vs accurate
[13:08] <iive> well, float dct is the most accurate, but when you have used old mpeg2 butchering fdct, it have introduced errors, that must be matched by the decoding one.
[13:08] <iive> you are well aware of the early xvid green tilting.
[13:08] <michaelni> yes, but the idcts probably (but who knows) wont be used for decoding
[13:09] <iive> ?
[13:09] <ubitux> the important thing is just to not export the cpu-specific option names for dct names
[13:09] <ubitux> FF_IDCT_SIMPLEMMX, FF_IDCT_ALTIVEC, ...
[13:09] <ubitux> this should not be visible to the user
[13:09] <michaelni> iive, its about exporting (i)dcts properly so libavfilter and libmpcodecs can use them through proper public API/ABI
[13:10] <michaelni> ubitux, user should use avoptions
[13:10] <ubitux> yes, but not "simplemmx" or "altivec"
[13:10] <iive> if there is proper api, somebody would come with the idea to use it for decoders too.
[13:10] <michaelni> there are entries in the AVOption table for "simplemmx" or "altivec" currently IIRC
[13:10] <ubitux> you don't want to pick the cpu optimization at idct level
[13:11] <iive> the question here is, e.g. is idct_simple_C and idct_simple_MMX produsing same output?
[13:11] <ubitux> you have the av cpu_flags stuff for that
[13:11] <michaelni> iive, no
[13:11] <iive> and what could match the altivec dct.
[13:12] <ubitux> iive: if not, then "optimized", "nonoptimized" or stuff like that
[13:12] <michaelni> also nothing matches the xvid sse one if you dont have sse 
[13:12] <ubitux> maybe just "simple+bitexact" for C
[13:12] <michaelni> IIRC
[13:12] <ubitux> "simple" for simple with optim (mmx/altivec/whatever)
[13:12] <michaelni> and some of the simple arm ones differ in values from C simple
[13:12] <michaelni> ubitux, mmx simple == permutated C simple
[13:13] <michaelni> mmx is bitexact IIRC just permuted differently than C simple
[13:13] <ubitux> whatever fills correct
[13:13] <ubitux> but please something understand for the user and not a cpu flags soup with different behaviour exported to the users
[13:13] <ubitux> it's insane
[13:13] <BBB> I dont think it has to match (simplemmx vs. simplec), the swscale mmx isnt bitexact either
[13:14] <BBB> so using -cpuflags for selecting simplec vs. simplemmx is fine
[13:14] <ubitux> exactly
[13:14] <michaelni> ok so what about the xvid IDCT ?
[13:14] <ubitux> "xvid"
[13:14] <michaelni> FF_IDCT_XVIDMMX
[13:15] <michaelni> theres no C version
[13:15] <ubitux> "xvid" + warning if "bitexact" or !intel cpu
[13:15] <ubitux> >?
[13:15] <iive> how about keeping the internal number, but also providing a table so the applications could pick dct on their own. e.g. the table would have cpu_flags for capabilities, error ranges and stuff like that.
[13:16] <ubitux> remember, it's something we show to the user: if you want to change it later it will be incredibly harder because of the deprecation process
[13:16] <ubitux> so we better get it right, or at worse not complete for a start
[13:17] <michaelni> well, i guess we could just leave the idct and dct_algo options out
[13:17] <ubitux> yes, better export only the needed bits, and make possible to add later
[13:18] <michaelni> and once some volunteer implemented their favorite API and added themselfs to MAINTAINERs we can allow people to select the (i)dct they want for the external API
[13:19] <michaelni> should i leave the *_algo in there under #if 0 or remove completely ?
[13:22] <michaelni> ubitux, also if *dct_algo is removed its no longer possible to select bitexact (i)dcts
[13:23] <iive> you don't like the idea with the table?
[13:26] <michaelni> iive, iam happy about anything, but as i dont understand what people are trying to fix i cant help/choose how to fix it
[13:26] <michaelni> that is i dont understand what wrong people see in the AVDSP API
[13:28] <michaelni> the *dct_algo allows selecting the implementation, one could conceivable wrap that under some other system but for debuging i need to know the impleentation and want to select it i dont think it would help a developer if he had to select an implementation by using a set of speed/permutation/aan/float flags
[13:28] <michaelni> it might appear prettier of course
[13:29] <michaelni> iive, a table of attrbutes for the implementations would make sense for sure
[13:31] <michaelni> if such a table is wanted (BBB & ubitux ?) i could look into it but it feels a bit orthogonal to the API question but maybe i misuderstood
[13:33] <ubitux> as i said, i have 2 concerns: having AVDSP with a lot of unrelated stuff (but this will be fixed with having only a AVDCT API), and the fact that we have CPU-specific flags at this user-idct-level feels extremely wrong
[13:33] <ubitux> and in both cases, removing stuff from either of the two in the future will be extremely hard
[13:33] <ubitux> because it is a public api
[13:34] <ubitux> (and in both cases we *will* need to remove them to make a decent interface)
[13:34] <michaelni> ubitux, ok if i leave idct_algo with "auto" and "simple" options so we can at least select bitexact mode ?
[13:35] <michaelni> aka force simple idct
[13:35] <ubitux> of course, we can have "auto" (whatever than means), "simple", "bitexact", or even "xvid" 
[13:35] <ubitux> i just don't want "mmx" or "altivec" in them :p
[13:36] <ubitux> (because it's handled at another level with -cpuflags)
[13:36] <ubitux> what's "auto" btw?
[13:36] <michaelni> do what the user would prefer
[13:36] <michaelni> works 99.9999% of the time for decoders
[13:37] <michaelni> like if cpu has MMX and its a xvid file use xvid mmx idct
[13:37] <michaelni> otherwise pick the fastest
[13:37] <ubitux> wouldn't that just be the default value for AVOption?
[13:37] <michaelni> auto would be default
[13:38] <michaelni> but auto isnt bitexact
[13:38] <ubitux> > and its a xvid file
[13:38] <ubitux> how is that defined with the current interface?
[13:38] <michaelni> isnt
[13:38] <ubitux> then there is no need for a "auto"?
[13:39] <michaelni> auto does more
[13:39] <michaelni> <michaelni> otherwise pick the fastest
[13:39] <ubitux> you just need a dct type option, and a dct flags option, right?
[13:40] <michaelni> or rather "fastest which is good quality" for decoders
[13:40] <ubitux> like dct->{default,simple,xvid} flags->{bitexact,fast,...}?
[13:41] <michaelni> where do simple with and without permutation fall in that ?
[13:41] <ubitux> (fast being assumed with ~bitexact actually, and dct->defautl could be dropped with a default value on simple)
[13:41] <michaelni> and where does the arm simple one with IIRC different rounding ?
[13:41] <ubitux> flags +permutation ?
[13:42] <ubitux> arm ’ current cpu optim if ~bitexact?
[13:42] <ubitux> (and if the dct and flags option are inconsistent, we can just warn)
[13:44] <michaelni> ubitux, ok but what use case does this fix ?
[13:44] <ubitux> it makes a simple and clean interface for users
[13:44] <michaelni> no user ever used it
[13:44] <ubitux> because it was messy
[13:44] <ubitux> (and private?)
[13:45] <michaelni> we lacked support for setting it from filters i think
[13:45] <michaelni> but let me ask differently, why does a user want to change the (i)dct algo for a filter ?
[13:46] <ubitux> no idea, but you seemed to be willing to make it possible for the user to customize it
[13:46] <ubitux> i was going to suggest something like "dct": ["simple","aan","xvid"], "flags": ["permuted","bitexact"]
[13:46] <michaelni> i wanted a way to debug code i maintain
[13:46] <ubitux> (actually, "dctint" so we could have floats ones later)
[13:46] <iive> I actually like the idea of having the idct_algo and the only publicly defined option set to auto.
[13:47] <ubitux> "dct_algo": ["simple","aan","xvid"], "idct_algo": ["simple","aan","xvid"], "flags": ["permuted","bitexact"] ?
[13:48] <ubitux> we can of course have only "simple" exported as a start
[13:48] <ubitux> assuming that's what we only need
[13:48] <michaelni> ubitux, i probably wont use this for debuging
[13:48] <ubitux> debugging is not for the users
[13:48] <michaelni> for debuging i need to select the algorithm used and cycle through them maybe to see which works if one doesnt
[13:49] <ubitux> i don't mind a mess internally
[13:49] <michaelni> yes, so i asked why a user wants to change that option
[13:49] <ubitux> well, he probably doesn't
[13:49] <michaelni> and what sense xvid or aan makes to a user in a filter 
[13:49] <michaelni> like spp
[13:49] <ubitux> (but in that case why are you exporting everything in the first place?)
[13:50] <michaelni> <michaelni> i wanted a way to debug code i maintain
[13:50] <ubitux> by having everything exported to the user?
[13:50] <ubitux> sorry i don't follow you here
[13:52] <michaelni> what do you suggest ? put it under #if DEBUG ?
[13:53] <ubitux> if it's just for you, why isn't avpriv just fine?
[13:55] <michaelni> the *dct API is for filters which are used by users, selecting the (i)dct implementation is something i as maintainer of the (i)dcts and filters using them would like to be able to do
[13:56] <ubitux> ok
[13:56] <ubitux> then what about having first fields as public as following ones as private in the AVDCT (heap allocated) context?
[13:56] <ubitux> s/as following/and following/
[13:57] <michaelni> ubitux, how does that work ?
[13:57] <ubitux> and you can customize the idct type and stuff by hitting those fields while debugging
[13:57] <michaelni> how do i select the (i)dct algorithm from the command like with private fields in a struct ?
[13:58] <ubitux> avdct->idct_tpe = whatever in your filter
[13:58] <ubitux> you're debugging, so you can just add a line in the code, no?
[13:58] <michaelni> "debuging" might be due to a user telling me he sees wierd artifacts in a filters output, so i run ffmpeg and cycle trough the idcts to check if it makes a differece
[13:59] <michaelni> if i have to change the code to select the IDCT what use is any API to me ?
[14:00] <iive> i just want to point out few things. 1. selecting dct cannot be done by signle criteria. 2. it must be extensible without breaking api
[14:00] <iive> that's why I think it is best to have idct_algo that uses the same values as internal ffmpeg. but don't expose these values through the public api. 
[14:01] <iive> have a different method for selecting them. e.g. table or avoptions.
[14:01] <iive> this way for debugging a power user might try giving different numbers to it, without knowing what these numbers represent.
[14:02] <wm4> I never understood why DSP functions need a "context", but oh well
[14:02] <ubitux> michaelni: well and the (i)dct_algo + flags options would not be fine for that?
[14:03] <ubitux> if so, i would not like it at all but you could just mark the current avoptions as "advanced/expert/unstable/warning/dontlookatit" whatever so we can change them whenever we feel the need to
[14:05] <BBB> that sounds useful
[14:05] <ubitux> but really, having meaningful option to implicit the selection would feel saner
[14:05] <BBB> but yes, my primary concern was to not have AVDSP, but instead something more contained, like AVDCT
[14:06] <michaelni> iam happy with anything with which i can simply and quickly cycle through the (i)dcts from the command line or select a specific one
[14:07] <BBB> I like ubitux idea of marking the values were currently arguing about (simple$cpu) as experimental so we can change them
[14:07] <michaelni> thats perfectly fine with me, they all can be marked as experimental or debug
[14:08] <ubitux> is it really hard to drop the "mmx" and "altivec" and replace it with a ±bitexact flag?
[14:09] <michaelni> it can probably be done
[14:21] <BBB> ubitux: we can do that later, as long as its not a baked-in part of the API
[14:22] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:b051a1bbb965: avcodec/arm/idctdsp_init_arm*: Only select non bitexact IDCTs by default when bitexact is not set
[14:37] <ubitux> BBB: avoption are exported to the user
[14:37] <ubitux> if you change them it's technically an api change
[14:38] <ubitux> it these options are not meant to be used to the user we need to explicit it in order to change them later
[14:42] <BBB> right, so mark them as experimental, we have a flag for that in AVOptions, right?
[14:45] <michaelni> i dont think we have a flag for that, we could add one (but some user apps wont know about it then) or add it to the help text 
[14:46] <BBB> up to you guys
[14:46] <BBB> has anyone done subidct tries for hevc? like what ffvp9 does
[14:46] <BBB> given the 4x4 forced scanorder, it should work even better for hevc in some cases than it does for vp9
[14:52] <kurosu> BBB: I think openhevc does it for 32x32, using 16x16
[14:53] <kurosu> from what mraulet told me
[14:53] <kurosu> rather, from what I interpreted from something mraulet said
[14:55] <kurosu> on the other hand they haven't implemented intermediate count of coeffs between dc-only and full
[14:56] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:fbeb634e4dda: avcodec/ppc/idctdsp: Only select non bitexact IDCTs by default when bitexact is not set
[15:48] <ubitux> michaelni: s/expermintal/experimental/g
[15:49] <ubitux> michaelni: s/debuging/debugging/g
[15:49] <michaelni> both fixed
[15:56] <ubitux> except a few nits i'm fine with that
[15:56] <ubitux> michaelni: don't forget a stdint.h in the header
[15:57] <ubitux> otherwise checkheaders will break
[15:57] <ubitux> mmh, maybe it's included in the opt.h though
[16:02] <michaelni> ubitux, opt.h uses intXY_t so it has to be
[17:19] <BBB> kurosu: thats a code structure thing, not a speedup
[17:19] <BBB> kurosu: a speed up would be to do the topleft (half in each dimension) sub16x16 for 32x32
[17:19] <BBB> thats different from doing a 16x16 idct
[17:22] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:932ff7095696: avcodec: add avdct
[17:22] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:e3fac208246f: avfilter/vf_spp: use AVDCT
[17:50] <cone-621> ffmpeg.git 03Christophe Gisquet 07master:36284ae98153: x86: hevc_mc: replace one lea by add
[19:16] <cone-621> ffmpeg.git 03Christophe Gisquet 07master:81943a10b500: x86: hevc_mc: load less data in epel filters
[19:26] <michaelni> ubitux, whats the status of "Jul 23 08:02:28 <ubitux>	(michaelni: i'll test the icecast thing so please don't apply in a hurry ;))" ?
[19:26] <ubitux> ah yeah, i wanted to do that
[19:26] <ubitux> give me an hour or two
[19:27] <michaelni> ubitux, sure, also dont hesitate to review or apply if you consider the code ready
[19:53] <ubitux> ePirat: ping
[19:53] <ePirat> ubitux?
[19:54] <ubitux> i'm currently testing the icecast patch, but i'm not able to make it work
[19:54] <ePirat> ubitux, why? what error do you get?
[19:54] <ubitux> i can start pushing, and after something like 2 seconds of push (i see a few data set) it's like the connexion is closed
[19:54] <ubitux> without any message
[19:54] <ePirat> which icecast version?
[19:55] <ubitux> 2.4.0
[19:55] <ubitux> i should probably enable the logs though
[19:55] <ePirat> yes please do so and give me the output of error log
[19:55] <ePirat> without this I have no way to discover whats going on
[20:01] <ubitux> ePirat: your patch strip the last character of the password
[20:01] <ePirat> o_O
[20:01] <ubitux> with that fixed it works fine
[20:02] <ePirat> I have no Idea how it is possible that the last character is removed
[20:02] <ubitux> going to look
[20:03] <ePirat> did the password contain : or @ ?
[20:03] <ubitux> standard ascii
[20:03] <ePirat> provided in the url or using the option?
[20:04] <ubitux> url
[20:04] <ePirat> please try specifying it using the option 
[20:04] <ePirat> if it works then I know better what to look for
[20:07] <ubitux> av_strlcpy(s->pass, p, strlen(auth) - user_len);  this one is incorrect
[20:07] <ubitux> you have a off by one
[20:07] <ePirat> I wonder why&
[20:07] <ubitux> the latest character gets replaced with a 0
[20:08] <ubitux> you can't reproduce?
[20:09] <ePirat> no
[20:09] <ePirat> just a second
[20:09] <ubitux> i'm using the latest patch (that doesn't compile) on ffmpeg-devel
[20:09] <ubitux> (you have a missing ");" on one of the av_log line)
[20:10] <ePirat> wtf
[20:11] <ePirat> I see&
[20:11] <ubitux> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-July/160181.html
[20:11] <ubitux> +                av_log(h, AV_LOG_WARNING, "Streaming ogg but appropriated content type NOT set!\n"
[20:11] <ePirat> thats weird&
[20:11] <ubitux> i fixed that because it was obvious but well
[20:12] <ubitux> anyway, try with "login:password at ..."
[20:12] <ubitux> you'll get user=[login] pass=[passwor]
[20:12] <ubitux> even though auth=[login:password]
[20:12] <ePirat> ok just a second
[20:20] <ePirat> you are right&
[20:21] <ubitux> you just miss a +1 in the pass len
[20:21] <ubitux> but make sure it works as expected with 0 or 1 character len for either pass or login or both
[20:22] <ubitux> "", "a:", ":b", "a:b" need to work :p
[20:22] <ePirat> weird is: exactly the same code for the auth stuff works on avconv
[20:23] <ubitux> is "auth" including the "@" in avconv? or maybe their strlcpy has an issue?
[20:24] <ubitux> (or it's a bug on our side?)
[20:25] <ePirat> ah wait seems it's broken there too& must have been when applying some of the recommended changes that I missed the +1
[20:28] <ubitux> ePirat: btw, you should automatically guess the content_type
[20:29] <ePirat> it is impossible 
[20:29] <ubitux> you can use the mount point extension
[20:29] <ePirat> no, as this can be anything
[20:29] <ubitux> and you're able to guess what we are streaming
[20:30] <ePirat> I cannot guess if video or audio
[20:30] <ubitux> aren't you able to suggest the correct content_type in the warning?
[20:30] <ubitux> at least try to automatically set it to this
[20:30] <ubitux> with a warning "-content_type not set, assuming foo/bar"
[20:31] <ePirat> Ok
[20:31] <ePirat> my way of guessing it is _very_ lazy
[20:31] <ubitux> it's good enough
[20:31] <ePirat> can you maybe help me with the password problem?
[20:32] <ubitux> yes of course
[20:32] <ePirat> I have no idea why I would need a +1 since the user_len already has a +1 for the \0& but it seems I need it&
[20:32] <ubitux> because of the ':'?
[20:34] <ePirat> ah right
[20:34] <ubitux> why aren't you doing strlen(p) instead btw?
[20:34] <ubitux> actually...
[20:34] <ubitux> you could just do s->pass = av_strdup(p);
[20:34] <ubitux> after the p++
[20:35] <ubitux> you could even replace the ':' with a '\0' and do the same for the login
[20:37] <ubitux> ePirat: so... sep=strchr(auth,':'); if (sep) { *sep=0; login=av_strdup(auth); pass=av_strdup(sep+1); }
[20:37] <ubitux> with just a if (!login || !pass) return AVERROR(ENOMEM)
[20:37] <ubitux> and you're good
[20:37] <ePirat> ah& let me try. would be great
[20:38] <ePirat> I would still need the memory allocated, right?
[20:38] <ubitux> that's what av_strdup does
[20:38] <ePirat> oh great
[20:39] <ubitux> btw, unrelated, but for the cat_header() function, please use AVBPrint
[20:39] <ubitux> it exists for exactly that purpose
[20:39] <ePirat> what does it do?
[20:39] <ubitux> it's an api for growing texts
[20:40] <ePirat> ah I think I looked at it but it seemed very complicated
[20:40] <ubitux> basically, you would just do av_bprint(bp, "%s: %s\r\n", key, value);
[20:40] <wm4> yes this AVBPrint thing could be simpler
[20:40] <wm4> it confuses me too
[20:41] <ubitux> it's not really complex...
[20:41] <wm4> let's just call it odd API design
[20:41] <wm4> and whatever is up with this FF_PAD_STRUCTURE thing
[20:41] <ubitux> you don't need to look at that
[20:41] <wm4> (also probably UB strictly speaking)
[20:42] <ePirat> ubitux, how would I need to initialized the login var when using av_strdup?
[20:42] <ubitux> ?
[20:42] <wm4> ubitux: well you have to "initialize" and "finalize" it
[20:43] <ePirat> char *login = NULL; login=av_strdup(auth); ?
[20:44] <ubitux> s->user = av_strdup(auth); ?
[20:44] <ePirat> i removed user from the context, since it is only needed in the open function
[20:45] <ubitux> so... what's your problem?
[20:47] <ePirat> just unsure how to initialize the variable
[20:47] <ubitux> why do you want to initialize it?
[20:49] <ePirat> it is needed?
[20:50] <ubitux> i'm sorry i don't know what you're asking me :p
[20:50] <ePirat> :P I will just try if it works how I am thinking it works
[20:52] <ubitux> btw
[20:52] <ubitux> ./ffmpeg -re -i ~/samples/audio/rondo.flac -content_type application/ogg -method PUT ... 
[20:53] <ubitux> this works for me to push on icecast
[20:57] <ePirat> yes I know
[20:59] <ePirat> wow thanks ubitux 
[20:59] <ePirat> simplified my auth code _a lot_
[21:00] <ubitux> it's too bad the protocol hasn't access to the AVFormat
[21:00] <ubitux> +Context
[21:00] <ePirat> yes :/
[21:00] <ePirat> I am suprised no protocol needed this before
[21:01] <ubitux> because you could have used the metadata for the name/description/...
[21:02] <ePirat> 13 lines instead of 30 for splitting the auth string \o/
[21:03] <wm4> <ePirat> I am suprised no protocol needed this before <- there are plenty of protocols which are not implemented as protocols, but directly as avformats
[21:04] <ubitux> ePirat: why do you need to split that btw?
[21:05] <ePirat> ubitux, password can be specified using command line argument, most times it is not needed to set a username.
[21:05] <ePirat> and a lot users do not even know what username they should use
[21:06] <ePirat> ubitux, how do I do error handling with av_bprint(bp, "%s: %s\r\n", key, value); ?
[21:07] <ubitux> you don't
[21:07] <ubitux> you will at the finalize step
[21:08] <ePirat> using av_bprint_is_complete() ?
[21:09] <ubitux> yes
[21:09] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:f285056810e6: doc/examples/muxing: fix "-flags" option
[21:09] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:3d93ba562243: configure: fix memalign hack auto detection
[21:10] <ePirat> ubitux, is there an example somewhere? I don't get how to init the buffer
[21:11] <ubitux> av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED); should be fine
[21:12] <ePirat> what is bp?
[21:12] <ubitux> AVBPrint bp;
[21:12] <ePirat> ah
[21:12] <ePirat> I was afraid using this
[21:12] <ePirat> I tought it be might too much for my usecase :P
[21:13] <ubitux> it will simplify your code
[21:14] <ePirat> how do I get the string at the end?
[21:14] <ubitux> you can use bp.str 
[21:14] <ePirat> ah
[21:15] <ubitux> you can also finalize into a buffer
[21:15] <ubitux> iirc
[21:16] <ubitux> (so you can close the context right away and get a persistent allocated string)
[21:18] <ePirat> these things are so hard to find
[21:19] <ePirat> already had 3 things that I could replace with already in place av functions
[21:20] <ubitux> btw, you could move the NOT_EMPTY check in your header-growing function
[21:21] <ePirat> ?
[21:22] <ubitux> instead of if (NOT_EMPTY(val)) headers = cat_header(headers, key, val);
[21:22] <ubitux> move the NOT_EMPTY(val) into cat_header
[21:22] <ubitux> so you gain a few lines
[21:28] <ePirat> ubitux, ok
[21:29] Action: ePirat wonders if it will work :P
[21:29] <ubitux> :)
[21:35] <ePirat> kawoom
[21:35] <ePirat> I get "variable has incomplete type 'struct AVBPrint'"
[21:37] <ePirat> and av_bprintf() does not seems to exist 
[21:37] <ubitux> ?
[21:38] <ubitux> #include "libavutil/bprint.h"
[21:38] <ePirat> oh& *derp*
[21:45] <Timothy_Gu> ubitux, db0company: new fateserver: http://i.imgur.com/7zjjM9w.png
[21:46] <ubitux> awesome yellow :))
[21:47] <Timothy_Gu> it really took me a while to find this new color...
[21:48] <ubitux> "yellow"?
[21:48] <Timothy_Gu> more: http://i.imgur.com/X1U9vfy.png http://i.imgur.com/iLNndy8.png
[21:48] <Timothy_Gu> yeah.
[21:48] <Timothy_Gu> I need to darken it enough to be fit with the new website, but not dark enough so that it isn't yellow anymore.
[21:49] <ubitux> what about some orange?
[21:49] <ubitux> probably less aggressive on a dark design
[21:49] <Timothy_Gu> Mobile-on-desktop view: http://i.imgur.com/IIGX0UZ.png http://i.imgur.com/IvJRF4P.png
[21:50] <Timothy_Gu> <ubitux> probably less aggressive on a dark design  what do you mean?
[21:50] <ubitux> this yellow is extremely violent
[21:51] <ubitux> orange would be less aggressive for the eyes
[21:51] <Timothy_Gu> ok. Can you try to find a color? It takes me 15 minutes to find one color...
[21:51] <Timothy_Gu> Test bed is http://4aa17da1.ngrok.com/
[21:52] <ubitux> http://paletton.com
[21:52] <ePirat> ubitux, uh I get a segfault now& dunno why&
[21:53] <ubitux> Timothy_Gu: dunno, try #ffb700 maybe
[21:54] <Timothy_Gu> http://i.imgur.com/QYpxBnE.png
[21:54] <ubitux> sounds better
[21:55] <ubitux> ePirat: can't guess what it is
[21:58] <Timothy_Gu> ubitux: found #ffe010
[21:59] <ubitux> don't like #ffb700?
[21:59] <Timothy_Gu> no
[21:59] <Timothy_Gu> looks like cr*
[21:59] <Timothy_Gu> http://i.imgur.com/piFh14i.png
[21:59] <Timothy_Gu> ^ this is mine
[22:00] Action: ubitux prefers orange
[22:05] <michaelni> Timothy_Gu, do you have time/interrest to add branch support to fate.ffmpeg.org ?
[22:08] <cone-621> ffmpeg.git 03Janne Grunau 07master:42eb9154a83e: fate: support testing of release branches
[22:08] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:7f53f1136346: Merge commit '42eb9154a83e9a7aedb1168b2f1112af765cf2b5'
[22:09] <michaelni> Timothy_Gu, that is the server side for the last commit
[22:27] <Timothy_Gu> michaelni: not really, sorry
[22:28] <michaelni> ok, anyone else ? (iam no perl developer so it should be alot less work for someone who knows perl a bit)
[22:28] <Timothy_Gu> fateserver is supposed to be open source (ISC), but Libav doesn't even give a dang
[22:29] <Timothy_Gu> by the way I didn't know perl either and I learned it as I fix fateserver ;)
[22:31] <michaelni> mraulet, commit adcdabb4dd062694fb8de6df0faecaad1c36ba33 removes some fate tests, is that intended ?
[22:33] <michaelni> Timothy_Gu, ill find someone to update it or ill do it myself, my todo list just is a bit long so if someone reading this knows perl, please ping me/reply
[22:33] <mraulet> michaelni, yes
[22:34] <wm4> in ffprobe, how do I disable a stream and then seek?
[22:34] <mraulet> those tests have been removed from jctvc conformance test suite
[22:34] <mraulet> and the other one have been added
[22:34] <michaelni> mraulet, i understand but we want to support everything also older files
[22:35] <michaelni> but i dont know if they maybe just excercise things that are already covered by others
[22:37] <mraulet> when the numbering increases, it is supposed to be a new bitstream with same features
[22:38] <mraulet> but anyway in the commit I forgot to delete golden references
[22:40] <mraulet> we can keep both they are still passing
[22:40] <mraulet> through the decoder
[22:43] <michaelni> i suggest we keep both, but you know this stuff so ill do what you prefer
[22:43] <michaelni> mraulet, if its keeping both i already have a diff for that locally
[22:44] <mraulet> you can keep both
[22:44] <BBB> whats the difference between avpriv_find_start_code and hevc_find_frame_end, conceptually?
[22:44] <BBB> theyre both looking for 0x000001nn sequences, no?
[22:45] <mraulet> I have yuv checking here and it is still correct
[22:45] <mraulet> yes
[22:45] <mraulet> oops BBB yes
[22:45] <mraulet> too many thread at the same time :-)
[22:45] <BBB> Im just backreviewing a decoder...
[22:45] <BBB> so I randomly ramble
[22:53] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:449e3c8515a5: fate/hevc: update fate with 9 bitstreams - all of them testing HEVC version 1
[22:56] <ePirat-> ubitux, got everything to work, I will send in a new patch tomorrow, need to check things and do some cleanup.
[23:09] <trn> Hello there.  
[23:09] <Timothy_Gu> trn: hi
[23:10] <Timothy_Gu> michaelni, ubitux: do you guys think the texi patches are OK to be applied to FFmpeg tree?
[23:10] <Timothy_Gu> michaelni: and also you didn't respond to my last email about the installation of makeinfo.
[23:12] <trn> I'll make a long story short, I have a proposed patch/idea.
[23:14] <cone-621> ffmpeg.git 03Carl Eugen Hoyos 07master:6898c14959d6: Fix standalone compilation of the legacy mpegvideo decoder.
[23:15] <trn> Timothy_Gu: Original issue: pastebin.com/h35TPp5N - I fixed it by adding a new option that adds AVFMT_TS_DISCONT flag via the ffmpeg command-line.
[23:15] <michaelni> Timothy_Gu, ill look into makeinfo install but noz sure when, might be a week or 2 before i do it, dont hesitate to ping me about it if i havt done it in a week
[23:15] <trn> Timothy_Gu: A similar patch was added do the same for FLV, and my use comes up using NUT or FFM as an internal stream format.
[23:16] <trn> I see Michael N added a similar patch for Live FLV via NGIN, situation in the same here, but unlikely to be seen in the wild.
[23:16] <trn> Oh, Mr. N is here :)
[23:16] <trn> michaelni: Awesome project BTW.
[23:19] <michaelni> trn, patches should be submitted to the ffmpeg-devel mailing list, and if you have a bug report that should go to trac, but AVFMT_TS_DISCONT for nut sounds wrong without knowing excatly what the issue is about
[23:20] <trn> michaelni: I'm abusing NUT essentially for something it isn't designed for.
[23:21] <trn> Where a stream is constructed from 5 or 6 fragments, where each fragment will start with 0 DTS.
[23:21] <trn> Other than resetting the DTS is otherwise monotonically increasing.
[23:23] <trn> The fragments that produce the final streams are constructed on the fly by multiple machines and they don't have any knoweldge of other machines in the cluster, and the streams may or may not be infinite in length.
[23:23] <trn> So I can't come up with any effective strategy to avoid having to reset DTS input.
[23:24] <iive> save them in separate tracks?
[23:24] <trn> Not possible as they aren't usually saved anywhere except being buffered.
[23:25] <iive> sorry, I didn't understand what you are doing.
[23:25] <BBB> can anyone explain me the mp4 and annexb format? Im sure this is documented somewhere but our code is so & undocumented& thats its just easier to ask
[23:25] <BBB> so mp4 is extradata: sps+pps, and frame data is actual slice nals
[23:26] <trn> live: Essentially an application that accepts input as multiple streams, presents an operator a way to edit the streams on a short time-delay to cut segments or switch between them, and then an output stream that is constructed after the operator...
[23:26] <BBB> but isntead of having start codes, they have length field markers, which are 2 bytes (BE) for sps/pps extradata, and N-bytes (1-4) for the slice nals, where N is coded in the first data byte of the extradata, right?
[23:26] <BBB> (first 2 bits infact)
[23:26] <trn> Then users are connecting and based on device capabilities it decides watch formats and codecs to encode to to stream the output.
[23:27] <trn> Real life: 15 input cameras -> human to switch them or beep bad-language -> output stream to TV and/or live streaming connecting clients
[23:27] <BBB> so what I dont understand is, why does sps/pps have 3x0,1 as a startcode, instead of 2x0,1?
[23:27] <iive> trn: you know that you can have multiple audio streams in a single file, each with different language (for example). you can also have multiple video streams.
[23:28] <ubitux> Timothy_Gu: i don't know, i'm a bit overbooked currently
[23:28] <Timothy_Gu> ok, no problem.
[23:28] <cone-621> ffmpeg.git 03Carl Eugen Hoyos 07master:54326e0c5016: Fix standalone compilation of the legacy mpegvideo decoder.
[23:28] <cone-621> ffmpeg.git 03Carl Eugen Hoyos 07master:bcb7220d1cf9: Fix standalone compilation of the webm_dash_manifest demuxer.
[23:28] <trn> live: Well aware, we're actually using 4 video and 8 audio streams 
[23:29] <iive> e.g. like dvd angle. it makes much more sense to save the streams as separate tracks that interleave them into a single video stream.
[23:29] <mraulet> BBB I dont think there is any rules on the number of zeros before a SPS and a PPS or whatever nalu type
[23:29] <trn> iive: The problem is that the streams are all live input.
[23:29] <mraulet> you can go into the HEVC spec for that
[23:30] <mraulet> you dont need ISO base media file format aka mp4
[23:30] <iive> trn: why is that a problem?
[23:30] <trn> iive: Because if the stream disconnects and reconnects, DTS is reset.
[23:30] <ubitux> BBB: mp4 specs can be found @ http://standards.iso.org/ittf/PubliclyAvailableStandards/c061988_ISO_IEC_14496-12_2012.zip
[23:30] <ubitux> (BBB: can't help you much more sorry)
[23:30] <iive> aha, there are holes in reception..
[23:31] <trn> iive: Exactly.
[23:31] <trn> Or there shouldn't be, but it isn't a perfect world. :)
[23:31] <Timothy_Gu> does anyone know if you can distribute ISC-licensed software without a license?
[23:32] <BBB> mraulet: so if you have 0x00 0x00 0x01, thats a valid start code right?
[23:33] <BBB> and the 4th byte is the naltype I suppose?
[23:33] <mraulet> yep
[23:34] <BBB> ok got it
[23:34] <mraulet> but you can have a number of infinte 0 before a start code
[23:35] <mraulet> so the most important zeros are the last ones
[23:35] <mraulet> to sync the decoders
[23:37] <trn> iive: Funny too that using a 900kbps video stream with x264 high profile 4.1 for TV output hasn't caused a single complaint when using massaging the incoming stream with ffmpeg hqdn3d before compressing :)
[23:38] <trn> Makes me wonder what Netflix is doing to look so bad.  Sometimes they look worse than our 1Mb H.264 baseline 3.0 stream.
[23:38] <mraulet> BBB: do you have a VP9 sample similar to those available here? ftp://ftp.kw.bbc.co.uk/hevc/hm-10.0-anchors/bitstreams/
[23:39] <trn> Anyway, I'll send my patch over to the mailing list.  It's simple enough I don't mind keeping it local in case it isn't found appropriate.
[23:39] <mraulet> by chance
[23:39] <BBB> mraulet: theyre on the google server
[23:39] <BBB> download libvpx and run ...
[23:39] <BBB> (looking)
[23:40] <iive> my test shows that using -nr 150 or 200 produces almost the same compression gain for far less cpu. and almost no visible loss.
[23:40] <BBB> make testdata
[23:40] <BBB> thatll download them all in your current directory
[23:41] <trn> BBB: Do you know if there is any AVS or HVEC 4K/8K test streams available?
[23:41] <BBB> mraulet: theres a few longer samples here: https://people.gnome.org/~rbultje/vp9/
[23:41] <BBB> 4k? not that I know, I went only up to 1080p in my tests
[23:42] <BBB> 4k is easy to encode yourself if you have a sample
[23:42] <BBB> but I dont think any are provided by google
[23:42] <trn> BBB: I know I 4K sample at http://www.elecard.com/en/download/videos.html
[23:42] <trn> I don't know any 8K.
[23:42] <BBB> mraulet: ok just use the provided settings from my dir and encode your own 5-frame sample then (if thats enough)
[23:43] <mraulet> 500 :-)
[23:43] <trn> Since I'm working on a live editing system, I know sports people are going to be demanding 4K and more soon.
[23:44] <BBB> uh...
[23:44] <BBB> ok
[23:44] <BBB> that might take you a day with my settings
[23:44] <mraulet> 10sec video decoding just to compare with hevc
[23:44] <BBB> use a higher speed=X setting
[23:44] <BBB> or wait a day
[23:44] <mraulet> ok
[23:44] <BBB> or ask google to use their datacenter
[23:44] <mraulet> i ll check with tos
[23:44] <mraulet> there are hevc samples
[23:45] <Timothy_Gu> trn: I know there are some 4K samples here: http://xhmikosr.1f0.de/samples/2160p/
[23:45] <trn> mraulet: HEVC samples at http://www.elecard.com/en/download/videos.html have 1920x1080 and a few 4K HEVC.
[23:45] <trn> Timothy_Gu: Cool, thanks.
[23:47] <cone-621> ffmpeg.git 03Lou Logan 07master:db0578a0e783: doc/decoders: mention native Opus decoder
[23:50] <Timothy_Gu> BBB: do you think VP9 is better than HEVC? I know it's a pretty lame question, but just wanna know.
[23:50] <BBB> I expect it to be competitive
[23:50] <BBB> sometimes better, sometimes worse
[23:50] <BBB> depends on the sample
[23:51] <BBB> overall itll be about the same, I expect, but thatll depend a lot on the encoder more so than the format
[23:51] <BBB> that is, if you get a great encoder that can encode quickly and still get most quality similar to the ref encoder (or better)
[23:51] <BBB> than thatll win you any contest
[23:53] <Timothy_Gu> OK. Another question is how can VP9 decoding _ever_ be faster than H.264 or VP8, like it does here at one thread: http://blogs.gnome.org/rbultje/files/2014/02/etv_decspeed.png
[23:55] <mraulet> because he did a great job
[23:55] <mraulet> :-)
[23:55] <BBB> Timothy_Gu: how not
[23:55] <BBB> Timothy_Gu: I do comparisons by _same quality_
[23:55] <wm4> and libvpx doing a terrible job...
[23:56] <BBB> Timothy_Gu: thats a really important distinction
[23:56] <BBB> wm4: its comapred to ffh264 and ffvp8, not libvpx
[23:56] <Timothy_Gu> oh ok
[23:56] <wm4> isn't the orange line libvpx?
[23:56] <BBB> wm4: yes, but he meant compared to ffh264/vp8, not libvpx
[23:56] <wm4> sure
[23:56] <BBB> Timothy_Gu: ok, so a few basics in video profiling - esp. at high bitrate, most time is spent in coefficient decoding
[23:56] <mraulet> in HEVC cabac is taking a lot of time
[23:57] <wm4> sorry my statement was confusing
[23:57] <BBB> Timothy_Gu: in hevc, thats cabac, in vp9, thats rac
[23:57] <BBB> Timothy_Gu: those take an enormous amount of time and cannot really be efficiently parallelized (simd'ed)
[23:57] <BBB> you can, in hardware, but not really on x86, imo
[23:57] <Timothy_Gu> what does RAC stand for?
[23:58] <BBB> Timothy_Gu: so, if you can, for same quality, reduce bitrate (=~ number of coefficients), then it means you only have half coefficients, and thus half time spent on coefficient decoding (relatively)
[23:58] <BBB> RAC = something artichmetic coder
[23:58] <BBB> I forgot what the r stands for
[23:58] <mraulet> but if you remove twice the bitrate as it is the case for hevc then you are going faster
[23:58] <BBB> range
[23:58] <mraulet> seconding what BBB is saying
[23:58] <BBB> Timothy_Gu: as mraulet says, basically
[23:59] <BBB> mraulet: so, I can spent twice the time in more complicated prediction, idcts of higher resolution, etc. - but if most of my time is coefficient decoding and I slashed that by half, I still win
[23:59] <BBB> oops
[23:59] <BBB> Timothy_Gu: ^^ that was for you
[23:59] <BBB> Timothy_Gu: thats why vp9 for same-quality beats vp8/h264 in decoding time (sometimes)
[23:59] <Timothy_Gu> so vp9 is better than I thought
[00:00] --- Mon Jul 28 2014