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

[burek]

[00:00:17 CEST] <nevcairiel> its fun when people upload samples to place where no developer other than carl can find them =p
[00:00:59 CEST] <BBB> crap the ssim one is also broken
[00:01:56 CEST] <llogan> "...I know there are people like you who do not understand such things"
[00:03:25 CEST] <llogan> trash talkin'
[00:06:05 CEST] <nevcairiel> so who do i ask? I suppose michaelni_ would know
[00:10:08 CEST] <iive> atomnuker: shouldn't assertion cause program abort?
[00:10:34 CEST] <iive> atomnuker: also, if you have fix, why not commit it right away and wait for more bugreports.
[00:10:52 CEST] <llogan> nevcairiel: it's a videolan server i think, so maybe on of them if all else fails.
[00:11:16 CEST] <nevcairiel> i got it now :)
[00:14:50 CEST] <wm4> how?
[00:16:01 CEST] <nevcairiel> i was told the secret
[00:17:42 CEST] <llogan> who was the fount of knowledge?
[00:18:07 CEST] <nevcairiel> beastd and michael both told me at the same time, more or less :p
[00:20:23 CEST] <wm4> can I know the secret too? I had it, but apparently it's out of date now
[00:21:32 CEST] <nevcairiel> my client is being weird, did you get the url
[00:23:13 CEST] <wm4> yes
[01:08:10 CEST] <cone-206> ffmpeg 03Ganesh Ajjanagadde 07master:a7c5005d7bec: avdevice/pulse_audio_common: add av_warn_unused_result
[01:12:02 CEST] <llogan> kierank: that is the most useless patch i've ever seen
[01:12:11 CEST] <kierank> I know
[01:12:43 CEST] <nevcairiel> this one r ight here, or which one
[01:12:53 CEST] <kierank> the legal one
[01:12:53 CEST] <nevcairiel> oh the legal thing
[01:14:03 CEST] <Daemon404> "grammer fixes" made me smile.
[01:14:31 CEST] <nevcairiel> i saw that, typo'ing in a typo-fix mail is always funny
[01:15:11 CEST] <Daemon404> i am probably guilty of this.
[01:23:35 CEST] <llogan> oops. forgot the "web/" in my patch
[01:26:18 CEST] <llogan> ...not that i don't agree that the logo shenanigans was a bullshit move
[01:58:50 CEST] <wm4> llogan: did you remove the image too?
[02:04:56 CEST] <llogan> wm4: no, sorry. i forgot it.
[02:07:06 CEST] <llogan> doesn't appear to be in the git repo, so i can delete it next time i log into server, but i don't think it would hurt to leave it
[02:48:05 CEST] <J_Darnley> I think I finally reached the end of today's internet.  Everywhere I go I just see the same things as I did earlier.
[02:51:25 CEST] <pross> whats at the end? are there no 'this page is still under construction'
[02:55:47 CEST] <J_Darnley> It just loops so that you don't realise you've reached the end and gone back to the begining.
[02:56:42 CEST] <J_Darnley> But it has a shuffle so you don't see things in the same order
[02:57:13 CEST] <J_Darnley> So the things you overlooked the first time make it seem like new
[10:06:25 CEST] <__gb__> nevcairiel mateo` , I think you can work or slightly extend the current hwaccel api to support frame level decode
[10:06:34 CEST] <__gb__> we had discussed that in the past iirc (well, 5+ years ago) :)
[10:06:45 CEST] <__gb__> start_frame(), end_frame() are not enough?
[10:08:38 CEST] <nevcairiel> there is a difference to consider here though, if it just wants the entire bitstream and still decodes that frame immediately, it might work, but if its a full decode API with its own delay and re-order handling and whatnot, the hardware decoder and the avcodec code would not agree on which frame is which and you get all kinds of trouble
[10:09:40 CEST] <mateo`> __gb__: the problem is that you can't expect the decoder to return immediately a frame after pushing one into it
[10:10:08 CEST] <__gb__> mateo`, no sync api?
[10:10:20 CEST] <mateo`> i'm submitting the whole frame bitstream on end_frame but it's not enough 
[10:11:15 CEST] <__gb__> wm4 or luca had other views iirc to address async apis, but I did not follow that discussion
[10:11:54 CEST] <nevcairiel> chaining a full blown decoder through the hwaccel API will likely not work, so a separate decoder in avcodec is best
[10:12:13 CEST] <nevcairiel> hwaccels rely on the software decoder still performing re-ordering and all that
[10:12:22 CEST] <nevcairiel> if the hwaccel tries to do that itself, its going to be weird
[10:14:09 CEST] <BtbN> How would it even happen that a decoder doesn't return a frame imediately? Aren't the frames ordered so there are no references to frames not parsed yet?
[10:14:32 CEST] <mateo`> __gb__: there is a sync api, but you can't expect a 1 input - 1 output mapping afaik
[10:14:36 CEST] <nevcairiel> it would happen if it tries to do the re-ordering into  display order
[10:14:45 CEST] <nevcairiel> instead of just being a slice decoder
[10:18:34 CEST] <__gb__> btw, what kind of hwaccel is it? you probably can indeed get inspiration from mmal, qsv, vt, etc.
[10:20:59 CEST] <mateo`> i've looked at qsv yesterday and i'm about to go this way, ie: creating a separe decoder
[10:24:32 CEST] <mateo`> __gb__: the api let you feed a single nal per buffer to the decoder, when the decoder has enough buffer, you can buffer out of it in two distinct ways
[10:25:40 CEST] <mateo`> the first one is cpu buffer in the format the decoder has decided (and you have no control over it) and it could be painful to deal with (it's device depend)
[10:26:43 CEST] <mateo`> the second one is having the decoder output to a surface from where you can render direct on screen or render to a 2D texture
[11:22:35 CEST] <canaar> What is the need to SDL mutex in ffplay? Started reading the code today morning.
[11:26:11 CEST] <wm4> canaar: it uses threads
[11:26:20 CEST] <wm4> I'm pretty sure there are some race conditions left
[11:27:11 CEST] <canaar> Can you summarize in short what kind of race condition? Race amongst multiple threads?
[11:29:53 CEST] <wm4> yes
[11:29:55 CEST] <wm4> I don't remember
[11:30:03 CEST] <wm4> just be very careful with this code
[11:30:50 CEST] <canaar> Why, can it damage my hardware?
[11:30:58 CEST] <nevcairiel> no, but it can just break
[11:31:12 CEST] <wm4> canaar: in theory they could crash or glitch ffplay
[11:37:31 CEST] <cone-769> ffmpeg 03Michael Niedermayer 07master:573334da8242: avformat/mov: Autodetect mp3s which need parsing
[11:38:42 CEST] <wm4> michaelni: such patches should go through review
[11:40:44 CEST] <michaelni> do you see a problem in the code? 
[11:42:46 CEST] <michaelni> if theres a problem i can revert but i tested this and found no case where it failed
[11:43:25 CEST] <nevcairiel> why not enable mp3 parsing all the time instead of relying on some heuristic? would it cause problems?
[11:44:00 CEST] <nevcairiel> such heuristic conditions always smell a bit
[11:46:43 CEST] <michaelni> there are some files which contain packets which seem to have a framesize different from what their headers indicate, if run through the parser they break
[11:47:09 CEST] <michaelni> https://dl.dropboxusercontent.com/u/76042064/packed_maindata.mp3.mp4 <-- this (url found by searching for the filename didnt double check its the right file)
[11:50:05 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:ca09eacbced6: avfilter: add shuffleframes filter
[12:38:10 CEST] <cone-769> ffmpeg 03Tom Butterworth 07master:a60539bb5e30: avcodec/hap: set bits_per_coded_sample
[12:38:55 CEST] <cone-769> ffmpeg 03Ronald S. Bultje 07master:0c7b44a01c15: vf_psnr/ssim: don't crash if stats_file is NULL.
[12:44:16 CEST] <wm4> michaelni: does libswresample clamp output values, or can it return out of range values? (if rematrix_maxval is higher than 1)
[12:56:43 CEST] <michaelni> values should be clamped to within the representable range, so for float&double values outside -1.0 .. 1.0 are possible as these can be represented
[13:00:13 CEST] <wm4> would some clipping be possible? simple clipping, and possibly soft clipping?
[13:00:34 CEST] <wm4> (and also, lavfi af_volume should also clip)
[13:05:23 CEST] <michaelni> it could certainly be added
[13:55:31 CEST] <nevcairiel> wm4: __gb__: I re-posted my hwaccel frame-mt patch with a proper long commit message, if you want to read it again to make sure i didnt write too much crap =p
[14:32:37 CEST] <__gb__> nevcairiel, sounds ok to me. probably add a minor note in APIchanges, since this is an indirect change in application programming model?
[14:33:02 CEST] <__gb__> and how long before j-b yells at us since vlc is another major player around? :)
[14:35:14 CEST] <j-b> 2seconds
[14:36:08 CEST] <wm4> __gb__: requiring an APIchanges entry sounds fair
[14:44:02 CEST] <cone-769> ffmpeg 03Ganesh Ajjanagadde 07master:8ed79c45b47f: avutil/qsort: use the do while form for AV_QSORT, AV_MSORT
[14:48:06 CEST] <cone-769> ffmpeg 03Ganesh Ajjanagadde 07master:e6a93e59adee: configure: add -Wstrict-prototypes when available
[14:49:41 CEST] <Daemon404> one day i will correctly remember snprintf's return value
[14:49:47 CEST] <Daemon404> today is not that day
[14:49:57 CEST] <av500> 42
[14:50:14 CEST] <Daemon404> i always mess up causwe it's like "it's X, except when Y is true, then it is Z"
[14:50:29 CEST] <wm4> just blame C for being unnecessarily complex
[14:51:16 CEST] Action: av500 never checks that value anyway
[14:51:20 CEST] <av500> what can go wrong...
[14:51:22 CEST] <Daemon404> i legitimately forgot about the radix/locale problem though
[14:51:32 CEST] <Daemon404> i just dont think of !english a lot :X
[14:51:39 CEST] <J_Darnley> It use Windows like conventions, the return is a status and a returned value is done through a pointer argument.
[14:52:05 CEST] <Daemon404> i personally like languages with multiple return values
[14:52:10 CEST] <Daemon404> ret, err = func(...)
[14:52:13 CEST] <wm4> I'm still not clear how ffmpeg handles the local issue
[14:52:20 CEST] <Daemon404> wm4, probably "it doesnt"
[14:52:24 CEST] <J_Darnley> (Try C99 and structs then)
[14:52:30 CEST] <wm4> I think there was a hack at least for parsing
[14:52:38 CEST] <Daemon404> oic
[14:52:59 CEST] <Daemon404> wm4, i am also surprised we use a union to read float values
[14:53:05 CEST] <Daemon404> i wouldnt think that is nto very portable
[14:53:14 CEST] <Daemon404> and depends on the float impl for that arch
[14:53:27 CEST] <wm4> heh, yeah
[14:53:34 CEST] <wm4> and all while we have intfloat stuff?
[14:53:39 CEST] <wm4> or softfloat
[14:53:42 CEST] <wm4> or what it was called
[14:53:43 CEST] <Daemon404> the intfloat stuff uses unions
[14:53:49 CEST] <Daemon404> softfloat is ... as its name says
[14:54:37 CEST] <wbs> intfloat is the right way; whoever says "what about non-ieee" doesn't know what they're talking about. the only case where it'd fail is when the fpu and cpu use a different endianness; some old (very much deprecated and very much not available anywhere) arm fpus did that
[14:55:33 CEST] <wbs> (and using unions are important; just doing *(int32_t*)&myfloat can fail if the compiler is aliasing-aware)
[14:55:40 CEST] <Daemon404> i know that much
[14:55:44 CEST] <Daemon404> aliasing rules are insane
[14:56:01 CEST] <Daemon404> i am not 100% informed about why "what about non-ieee" is a red herring though
[14:56:07 CEST] <Daemon404> (unless you mean they simply dotn exist in practice)
[14:56:44 CEST] <wbs> everything since 1985 has been ieee-754, more or less
[14:56:50 CEST] <Daemon404> ok
[14:56:51 CEST] <ubitux> note: i'm working on a midly high level async api for ffmpeg, i will try to provide a PoC by the end of next week
[14:57:03 CEST] <wbs> worrying about 64 bit 'int' is more real of an issue :P
[14:57:06 CEST] <Daemon404> ubitux, i assume it will be optional
[14:57:08 CEST] <Daemon404> for sanity
[14:57:16 CEST] <ubitux> Daemon404: it's on top of current api
[14:57:25 CEST] <Daemon404> that sounds insane :D
[14:57:31 CEST] <ubitux> :)
[14:57:37 CEST] <Daemon404> wbs, ofc
[14:57:37 CEST] <ubitux> it will be optional ofc.
[14:57:52 CEST] <Daemon404> ubitux, model it after mmal
[14:57:54 CEST] <Daemon404> wm4 will love you
[14:58:07 CEST] <ubitux> it's already modeled
[14:58:09 CEST] <wm4> mmal is a pretty general async API
[14:58:21 CEST] <ubitux> an implementation is already in progress
[14:58:23 CEST] <ubitux> i need a few days
[14:58:25 CEST] <Daemon404> wm4, ive heard nothing but bad things; perhaps its the impl which is bad
[14:58:26 CEST] <wm4> really
[14:58:32 CEST] <wm4> ubitux: post us the API changes for review
[14:58:42 CEST] <wm4> Daemon404: from who?
[14:58:53 CEST] <wbs> wm4: I don't think it's bad; it's pretty much exactly how any such api is
[14:59:03 CEST] <wm4> yes, the API is sort of fine
[14:59:04 CEST] <wbs> (the same for mediacodec/omx/whatever, just with less boilerplate than omx)
[14:59:18 CEST] <wm4> just the integration with lavc is terrible, and the RPI decoder itself can behave terribly too
[14:59:24 CEST] <wm4> (you can crash the GPU so easily)
[14:59:38 CEST] <wm4> although when it works it does its thing properly
[14:59:38 CEST] <Daemon404> wm4, a couple people here + elsewhere
[14:59:49 CEST] <Daemon404> maybe i am thinking of a different hwaccel api
[15:00:07 CEST] Action: ubitux discovers av_thread_message_queue @_@
[15:00:15 CEST] <Daemon404> i was pretty sure it was mmal on teh rpi though
[15:00:38 CEST] <wm4> Daemon404: if you want a sync API, mmal is definitely very hard to use
[15:00:56 CEST] <wm4> (and lavc makes it a bit harder because of 1:1 input/output)
[15:01:51 CEST] <Daemon404> right
[15:02:11 CEST] <Daemon404> 1:1 i/o has bit be lots, and not even with async apsi
[15:02:12 CEST] <Daemon404> apis*
[15:11:35 CEST] <cone-769> ffmpeg 03Ganesh Ajjanagadde 07master:8738885c7d65: Revert "configure: add -Wstrict-prototypes when available"
[15:12:26 CEST] <Daemon404> lul
[15:13:47 CEST] <J_Darnley> . . .
[15:21:50 CEST] <wm4> what
[15:22:11 CEST] <wm4> "Missed it, it is already enabled. Reverted."
[15:22:12 CEST] <wm4> ok
[15:22:15 CEST] <nevcairiel> not even waiting a full day and pushing due to "lack of review", then reverting immediately because it was wrong
[15:22:34 CEST] <nevcairiel> and people questioned me when I wondered why we give new developers push access right away
[15:22:48 CEST] <wm4> meh
[15:27:11 CEST] <Daemon404> nevcairiel, it was not a day
[15:27:13 CEST] <Daemon404> it was like 16 hrs
[15:27:41 CEST] <nevcairiel> "not even a day"
[15:28:14 CEST] <Daemon404> look, reading is hard, you cant expect me to read my own native language 
[15:28:15 CEST] <Daemon404> pfft.
[15:28:43 CEST] <nevcairiel> and here I am even writing a foreign language so you pleebs understand my brilliance!
[15:42:50 CEST] <Daemon404> wm4, the least bad way i see of doing this is uselocale() but that is still prone to issues im sure...
[15:42:57 CEST] <Daemon404> this, being using a . for teh radix
[15:43:14 CEST] Action: Daemon404 stabs whoever thought changing the radix with locale is a good idea
[15:43:48 CEST] <wm4> fuck locales
[15:43:58 CEST] <wm4> fuck library devs who want you to set locale to non-C
[15:44:01 CEST] <wm4> (yes they exist)
[15:44:12 CEST] <Daemon404> also impressive that C provides no way to ingest such strings
[15:44:13 CEST] <Daemon404> afaict?
[15:44:17 CEST] <Daemon404> maybe im just dumb
[15:45:58 CEST] <nevcairiel> C, strings, two things which if they appear in a sentence together will make your life harder
[15:47:33 CEST] <wm4> somehow I rarely have trouble with C and strings
[15:47:47 CEST] <wm4> it's just everyone else who insists on doing stupid tricky crap that breaks very quickly
[15:48:00 CEST] <Daemon404> i do, but only with locales and encodings
[15:48:20 CEST] <Daemon404> c++11 has codecvt or w/e
[15:49:03 CEST] <Daemon404> and the non-C language i use most has teh concept of "runes"
[15:49:09 CEST] <Daemon404> and a string can be made up of a set of 'runes'
[16:01:25 CEST] <durandal_1707> that revert is funny, how he could miss flag several lines bellow
[16:04:04 CEST] <J_Darnley> By not putting things in alphabetical order.
[16:04:23 CEST] <nevcairiel> I even told him that the flag was active for me, hence how I found the warning
[18:15:01 CEST] <BBB> awh man
[18:15:02 CEST] <BBB> flags
[18:15:15 CEST] <BBB> michaelni: I hope you understand Im having swscale flashbacks here, and that is not pretty
[18:32:47 CEST] <Compn> BBB : you want to sponsor michaelni to rewrite swscale ? 
[18:32:49 CEST] <Compn> :P
[18:39:35 CEST] <kierank> I'd sponsor Compn to shut up =p
[18:40:20 CEST] <michaelni> BBB, sws flags are rather messy as they contain some multivalue things that should be in their own int. do you think the swr clip case will need more values or would otherwise benefit from being in its own int ?
[18:42:06 CEST] <BBB> Im not so concerned about this flag, Im concerned about adding new features through flags and the flags field eventually blowing out of proportion the same way that swscale became the mess that it is
[18:42:34 CEST] <BBB> (and dont get me wrong, I dont want anyone to spend time fixing it - I just am trying to convey the idea that we can prevent that mess from ever happening to swr)
[18:58:13 CEST] <cone-769> ffmpeg 03Tom Butterworth 07master:abae43a7d41d: Add myself as maintainer for Hap
[19:04:12 CEST] <mateo`> i would like to wrap in an avframe the cpu buffer (nv12) which comes from the mediacodec api and associate a release callback (i'm not using any hwaccel for now). I've looked at what videotoolbox was doing, frame->buf[0] = av_buffer_create, but i wonder how to map correctly the different planes in the avframe. Is it ok to map them using the frame->data pointers ?
[19:04:50 CEST] <mateo`> is there a call to init the field of the avframe depending on the parameters of the avctx ?
[19:09:22 CEST] <wm4> mateo`: the rule is: all AVFrame.data memory must be covered by a AVBufferRef (also, one AVBufferRef can cover multiple plane pointers, if the plane data is in the same memory alloc)
[19:13:08 CEST] <mateo`> wm4: thanks a lot !
[19:20:32 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:dd456245b638: avformat/msf: extend format long description
[19:20:33 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:8dea76180c3b: avcodec: extend long decription for adpcm psx codec
[19:20:34 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:dfc64f4ddf4b: avformat/svag: extend format long description
[19:20:35 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:a03fe8adba30: avformat/ads: extend format long description
[21:13:09 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:daabc59c645c: avformat/genh: add ADPCM IMA DVI support
[21:55:12 CEST] Action: J_Darnley must not send a snarky reply to the user mailing list.
[21:58:35 CEST] <wm4> to what thread
[21:58:59 CEST] <JEEB> I am only a masochist enough to be on the #ffmpeg IRC channel
[21:59:08 CEST] <JEEB> I don't want that kind of stuff on my mail client, too :D
[22:02:41 CEST] <BBB> hahaha thats funny
[22:02:50 CEST] <BBB> video encoding costs money
[22:03:04 CEST] <BBB> please help me
[22:03:25 CEST] <J_Darnley> wm4: the javascript one
[22:03:56 CEST] <wm4> must have missed it
[22:04:02 CEST] <wm4> oh, the user ml
[22:04:14 CEST] Action: J_Darnley thinks he said that
[22:04:29 CEST] <J_Darnley> Yes "GPL implications of ffmpeg in the crowser"
[22:04:32 CEST] <J_Darnley> uh
[22:04:36 CEST] <J_Darnley> browser
[22:04:39 CEST] <TD-Linux> the js one is actually a fairly reasonable question though the answer should be obvious reading the license
[22:05:04 CEST] <J_Darnley> I agree
[22:05:15 CEST] <J_Darnley> My reply was completely off topic and not useful in any way.
[22:05:29 CEST] <J_Darnley> 'I think you mean "waste the client's computing power".'
[22:06:36 CEST] <TD-Linux> hey man, you have to put the client's $2000 facebook machine to good use
[22:14:00 CEST] <Daemon404> hey hey hey
[22:14:03 CEST] <Daemon404> they use twitter too probably.
[23:50:48 CEST] <mateo`> are the frames that come out a decoder are supposed to be valid (if the user keeps a ref) after the decoder has been destroyed ?
[23:53:23 CEST] <wm4> yes
[23:53:43 CEST] <nevcairiel> if thats a problem, you can ref the decoder object from the frame
[23:53:46 CEST] <nevcairiel> i do that in dxva
[23:53:52 CEST] <mateo`> i'm asking because if I wrap a mediacodec output buffer in an avframe, if the user decide to keep it after the decoder has been destroyed, i don't see how the release callback can still work
[23:54:08 CEST] <mateo`> as it needs the mediacodec context
[23:55:49 CEST] <mateo`> nevcairiel: i will do that then :) (and look at what you've done in dxva)
[23:57:38 CEST] <wm4> nevcairiel: dxva frames are not valid after the decoder has been destroyed?
[23:57:57 CEST] <nevcairiel> technically they are
[23:58:05 CEST] <nevcairiel> but some drivers can be a bit annoyed when you do that
[23:58:09 CEST] <wm4> lol
[23:58:23 CEST] <nevcairiel> it caused issues on clips with resolution changes
[23:58:33 CEST] <nevcairiel> since you trash the original decoder and create a new one
[23:59:07 CEST] <wm4> I'd totally expect that some other drivers fuck up if you keep more than 1 decoder alive
[23:59:23 CEST] <nevcairiel> nah
[23:59:35 CEST] <nevcairiel> simultaneous stream decoding is supported on pretty much all of them
[00:00:00 CEST] --- Sat Oct 24 2015