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

[burek]

[00:00:51 CEST] <durandal_1707> i wonder how hw scopes work...
[00:02:44 CEST] <cone-455> ffmpeg 03Philip Langdale 07master:d3eb317b862c: ffmpeg_vdpau: Ignore decoder's max supported level
[01:27:34 CEST] <Compn> as long as no one deletes muh lowres.
[01:27:35 CEST] <Compn> :P
[01:29:19 CEST] <kierank> yes
[01:54:14 CEST] Action: rcombs scrolls up
[01:54:23 CEST] Action: rcombs finds this truncated issue description:
[01:54:30 CEST] <rcombs> (Incompatibilities between XBMC/Kodi & mkvalidator relating to how FFmpeg &)
[01:54:48 CEST] Action: rcombs headtilt
[01:58:03 CEST] <BBB_> the annoying thing is that half of these things scheduled for removal dont work
[01:58:17 CEST] <BBB> like, Im trying to build ffmpeg with half of these things set to 0
[01:58:21 CEST] <BBB> and it just doesnt work
[01:58:24 CEST] <BBB> its not just that it doesnt build
[01:58:33 CEST] <BBB> once you get it to build, fate fails on everything
[01:59:03 CEST] <BBB> (AVFormatContext.flags = bitexact is no longer automatically copied from AVCodecContext.flags = bitexact)
[01:59:09 CEST] <BBB> hugely annoying
[01:59:17 CEST] <BBB> why dont we hae a fate station for this?
[02:00:35 CEST] <wm4> lol
[02:00:57 CEST] <wm4> sometimes I wonder why bother with this ifdeffery shit
[02:08:40 CEST] <BBB> dunno
[02:08:48 CEST] <BBB> Im slowly trying to untangle some of this mess
[02:08:59 CEST] <BBB> but all I have is a laptop so running fate trillions of times takes forever :(
[03:01:08 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07master:7f769ae41e0d: avcodec/rv30: fix switching back to the original resolution
[03:20:53 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07master:3afca32561d9: swscale/swscale-test: Fix slice height in random reference data creation.
[05:01:48 CEST] <Taniey>  ask some questions about drawtext: I import windows fonts to centos 6.5 ,and use ttmkfdir to reload the windows fonts, so  I can use the filter 'drawtext' of ffmpeg with version 2.7.2  to draw some text video , but some characters not in ansii table can`t draw to the video ,how can i resolve about this?
[05:02:08 CEST] <Taniey> command like this: 
[05:06:52 CEST] <Taniey>  ffmpeg.exe -y -i .\Ice.Age.Continental.Drift.2012.720sp.mkv -filter_complex "drawtext=textfile=\'drawtext.txt\':font=\
[05:06:52 CEST] <Taniey> 'arial\':fontsize=48:fontcolor=00ffff:x=50:y=200" -sn -codec:v h264 -codec:a aac -strict -2 out.mkv
[05:16:12 CEST] <Taniey> content of drawtext.txt like this: 'test draw text
[05:16:13 CEST] <Taniey> L¤¸
[05:16:13 CEST] <Taniey> 'D5JFJ)'
[05:19:38 CEST] <Taniey> content of drawtext.txt contain : Korean ,english, etc.
[05:22:38 CEST] <Taniey> command :
[05:22:42 CEST] <Taniey> ffmpeg -y -i Ice.Age.Continental.Drift.2012.720sp.mkv -filter_complex "drawtext=textfile=\'drawtext.txt\':font=\'arial\':fontsize=48:fontcolor=00ffff:x=50:y=200" -sn -codec:v h264 -codec:a aac -strict -2 out.mkv
[06:42:21 CEST] <Taniey> anybody know about this question.
[07:48:03 CEST] <Taniey> ffmpeg drawtext filter draw Arabic string is reversed. the Arabic string in text is like [abcd], but draw on video is like [dcba],is it right?
[07:50:26 CEST] <Taniey> how can i use ffmpeg drawtext filter to draw bold fonts ?
[07:58:01 CEST] <ubitux> Taniey: you need --enable-libfribidi
[07:58:34 CEST] <Taniey> bold fonts?
[07:58:41 CEST] <ubitux> text reverse
[07:59:08 CEST] <Taniey> how can I use the command?
[07:59:41 CEST] <ubitux> at build time
[07:59:48 CEST] <Taniey> how can I spell the command?
[08:00:03 CEST] <ubitux> also, these are questions for #ffmpeg
[08:00:15 CEST] <ubitux> ./configure --enable-libfribidi
[08:02:33 CEST] <Taniey> i am sorry , i know how configure this option ,but the ffmpeg command is same like other ffmpeg drawtext ?
[08:03:01 CEST] <ubitux> to fix the reversed text string, yes
[08:05:31 CEST] <Taniey> thanks ,i will try it.
[08:06:09 CEST] <Taniey> can you know about other two question?
[08:13:01 CEST] <BtbN> philipl, well, I'm at a point where i'd at least hope to get _something_
[08:13:08 CEST] <BtbN> But it just tells me "invalid parameter"
[08:13:14 CEST] <BtbN> And there are hundrets of parameters.
[09:37:19 CEST] <j-b> 'morning
[10:22:07 CEST] <__gb__> hi BtbN, generally, you can get more information through the companion source code to the VA intel-driver :)
[10:23:21 CEST] <BtbN> You mean simply reading through the code of it? Or is there some kind of tool for that?
[10:23:43 CEST] <BtbN> The intel driver is unhappy about some parameters i'm setting, but it doesn't tell me which one.
[10:24:09 CEST] <__gb__> yes, through the code, doesn't INTEL_DEBUG report the line number?
[10:24:59 CEST] <BtbN> You mean the VA_INTEL_DEBUG environment variable?
[10:25:25 CEST] <__gb__> BtbN, for hevc specifics, as a hint, you can see dxva2 code, the VA-API seems to have built after that so that some people could just reuse some code in some driver
[10:25:27 CEST] <__gb__> yes
[10:26:02 CEST] <BtbN> I set that to 3, but there is no additional output except for one line confirming it was set to 3.
[10:29:53 CEST] <__gb__> if you get some INVALID_PARAMETER (18) for hevc, the most plausible cause could be that VAPictureParameterBufferHEVC sanity checks failed
[10:30:13 CEST] <__gb__> most probably ReferenceFrames[].flags
[10:30:36 CEST] <__gb__> ?
[10:31:08 CEST] <__gb__> and unfortunately, error reporting/debug is somewhat involved
[10:31:29 CEST] <__gb__> you'd probably want to instrument intel_decoder_check_hevc_parameter() if that is the one failing for you
[10:31:43 CEST] <nevcairiel> BtbN: just be happy you have soem way to debug, with dxva2 you get nothing, either it works, or it doesnt =p
[10:32:05 CEST] <__gb__> there is always a way if you have sources :)
[10:32:13 CEST] <nevcairiel> windows things dont give out sources
[10:32:43 CEST] <__gb__> BtbN, btw, I was about to start hevc decode this week, but go on if you want :)
[10:33:04 CEST] <nevcairiel> but by carefully comparing the dxva2 hevc spec, the actual hevc spec, and the avcodec code, it eventually worked out to find the exact values that need to go in there
[10:33:18 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commits/vaapi_hevc that's what i have so far.
[10:33:23 CEST] <nevcairiel> luckily microsoft defined a decent spec, and not only provides headers without explanation
[10:34:55 CEST] <wm4> <nevcairiel> windows things dont give out sources <- pretty sure the intel linux department gets to see the sources of the intel windows department (or at least it sounds so)
[10:35:06 CEST] <nevcairiel> well within a company certainly
[10:35:07 CEST] <__gb__> I believe that spec is jointly defined by the 3 GPU vendors too?
[10:35:11 CEST] <nevcairiel> but that doesnt help me :p
[10:35:20 CEST] <__gb__> wm4, absolutely not
[10:35:34 CEST] <__gb__> unless you want to be contaminated and inadvertally leak out some IP
[10:35:47 CEST] <BtbN> comparing the picture flags the gst decoder sets, and the one I set so far, it seems not too unlikely that something is missing there
[10:36:35 CEST] <__gb__> I'd say I also have reasons to believe that some people get to RE some things to better understand some things
[10:37:11 CEST] <wm4> interesting
[10:37:49 CEST] <__gb__> probably faster than getting through several layers
[14:07:32 CEST] <wm4> lol is ffmpeg-devel now about recommending nvenc-compatible devices
[14:07:47 CEST] <JEEB> lol
[15:19:51 CEST] <Compn> that would probably be a good idea to recommend compatable devices that are known to work with ffmpeg 
[15:19:59 CEST] <Compn> but hey, i care about users...
[15:49:34 CEST] <BBB> so what is the proposed mechanism for having media-type specific defaults for codec options?
[15:51:04 CEST] <BBB> (Im looking at the av_opt_set_defaults2 deprecation and it breaks everything, which is expected)
[15:51:19 CEST] <BBB> (because libav removed ab, we didnt, so we now use audio default bitrate for video streams also)
[15:51:48 CEST] <durandal_170> huh?
[15:54:08 CEST] <durandal_170> isnt it -b:a ?
[15:54:31 CEST] <cone-075> ffmpeg 03Carl Eugen Hoyos 07master:84170d4be053: lavc/mjpegdec: Detect more CMYK images.
[15:54:33 CEST] <BBB> FF_API_OLD_AVOPTIONS removes av_opt_set_defaults2, which has a mask/flag, which is used in avcodec_get_context_defaults3 to have a masked default set
[15:54:46 CEST] <BBB> so after removal, we call av_opt_set_defaults without mask/flag
[15:54:53 CEST] <BBB> (or I assume thats the intention)
[15:54:56 CEST] <BBB> in the table, we have this:
[15:55:07 CEST] <BBB> {"b", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 = AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX, A|V|E},
[15:55:12 CEST] <BBB> {"ab", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 = 128*1000 }, 0, INT_MAX, A|E},
[15:55:28 CEST] <BBB> if we remove the mask, video streams now cant mask the audio ab out, so we use the audio bitrate for video streams
[15:55:32 CEST] <BBB> all fate results change as a result
[15:55:36 CEST] <BBB> so& what is the intention here?
[15:55:49 CEST] <BBB> do we want to keep the mask? do we want to follow libav and remove ab?
[15:55:54 CEST] <BBB> something else?
[15:56:07 CEST] <BBB> (AV_CODEC_DEFAULT_BITRATE = 200 * 1000)
[15:57:04 CEST] <Daemon404> git blame and ask the person who wrote it?
[15:57:15 CEST] <BBB> it obviously comes from libav
[15:57:18 CEST] <BBB> and michael merged it
[15:57:26 CEST] <Daemon404> so ask teh author?
[15:57:36 CEST] <Daemon404> or is this one of those "i cant talk to X because Y"
[15:57:43 CEST] <BBB> no, libavs intention is obvious
[15:57:45 CEST] <BBB> remove av"
[15:57:48 CEST] <BBB> ab
[15:57:59 CEST] <BBB> but we didnt take that part of the patch when we merged it
[15:58:01 CEST] <BBB> and its unclear why
[15:58:05 CEST] <Daemon404> oh.
[15:58:06 CEST] <BBB> because thats why it breaks
[15:58:24 CEST] <Daemon404> probably because carl and otehr ffmpeg devs have a huge hardon for "not breaking user's scritps ever"
[15:58:24 CEST] <BBB> so I guess my question is: what is the intention of not merging ab?
[15:58:37 CEST] <BBB> ...
[15:58:53 CEST] <BBB> then why merge it at all
[15:58:59 CEST] <Daemon404> don't ask me.
[15:59:28 CEST] <Daemon404> this same bullheadedness led to other problems and hilariousness
[16:00:19 CEST] <nevcairiel> because -b:a is hard to type, obviously
[16:00:27 CEST] <BBB> much harder than -ab, yes
[16:00:36 CEST] <BBB> statistically speaking, about 33% harder
[16:00:48 CEST] <BBB> plus its a non-alphanumerical character, so 17 extra bonus points for that
[16:00:54 CEST] <BBB> 50% harder
[16:00:56 CEST] <nevcairiel> it requires the shift key too!
[16:00:59 CEST] <nevcairiel> at least on german keyboards
[16:01:02 CEST] <nevcairiel> dont ask me where it is on US
[16:01:09 CEST] <Daemon404> shift semicolon
[16:01:10 CEST] <BBB> also shift (under emicolon)
[16:02:17 CEST] <durandal_170> You do not type -ab all the time
[16:02:23 CEST] <iive> michael doesn't merge anymore, does he?
[16:02:33 CEST] <Daemon404> iive, this was long long in the past
[16:06:55 CEST] <nevcairiel> BBB: worst case just make both have the same default
[16:07:41 CEST] <nevcairiel> the default bitrate is probably crappy for video no matter what, though
[16:17:12 CEST] <BBB> so are people generally ok with me just doing what libav did and thus effectively bumping the default audio bitrate to 200k?
[16:17:56 CEST] <BBB> (Im not suggesting anyone ever encode anything without setting a bitrate, but it affects fate so this will cause a lot of changes)
[16:18:23 CEST] <BBB> (to refs)
[16:19:29 CEST] <BBB> Ill just go ahead and do it
[16:19:36 CEST] <BBB> I cant imagine anyone even remotely caring about this cruft
[16:19:54 CEST] Action: Daemon404 waits for carl
[16:20:36 CEST] <iive> BBB: actually people expect the bitrate to be appropriate value for the used codec
[16:20:48 CEST] <Daemon404> iive, that was never true
[16:20:48 CEST] <Daemon404> ever
[16:20:53 CEST] <BBB> iive: patch welcome
[16:21:07 CEST] <iive> Daemon404: it's still true. But ffmpeg never did it :)
[16:21:10 CEST] <nevcairiel> some codecs have specific defaults, but i dont think any include a bitrate
[16:21:23 CEST] <Daemon404> iive, yes that's what i meany
[16:21:27 CEST] <Daemon404> meant*
[16:25:02 CEST] <BtbN> Hm, this is strange. While debugging into libva-intel-driver, i end up in the avc sanity check code, not in the hevc one.
[16:26:19 CEST] <nevcairiel> .. and thats why its not working! :)
[16:26:24 CEST] <iive> BBB: i'm more afraid by the bikeshed factor ...
[16:26:26 CEST] <nevcairiel> did you verify that it actually works with gst
[16:27:11 CEST] <BtbN> nope
[16:27:14 CEST] <BtbN> nevcairiel, https://gist.github.com/BtbN/96e9dbf6d3d10e592c5d
[16:27:22 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_decoder_utils.c?id=1.6.0#n1206
[16:27:39 CEST] <BtbN> it even says the profile parameter is HEVC Main
[16:27:44 CEST] <BtbN> why does it enter that branch?!
[16:27:58 CEST] <nevcairiel> they share the same value? :)
[16:29:07 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/va.h?id=libva-1.6.0#n283
[16:29:08 CEST] <BtbN> nope
[16:29:55 CEST] <nevcairiel> souce not matching your binary?
[16:30:09 CEST] <BtbN> Very unlikely
[16:30:21 CEST] <BtbN> The backtrace alone is quite obvious
[16:30:33 CEST] <BtbN> intel_decoder_sanity_check_input called with profile=profile at entry=VAProfileHEVCMain
[16:30:39 CEST] <BtbN> branches into intel_decoder_check_avc_parameter
[16:31:54 CEST] <BtbN> __gb__, any idea what might be going on here?
[16:32:21 CEST] <nevcairiel> i find it odd that the first two lines in your backtrace dont have a address anymore
[16:33:01 CEST] <BtbN> propably caused because i reverse-stepped through it
[16:35:16 CEST] <BtbN> nope, a normal backtrace also shows no addresses
[16:35:31 CEST] <BtbN> i'd guess they got inlined or something?
[16:43:22 CEST] <nevcairiel> the one call before that is in another file, makes inline unlikely, but maybe you use lto =p
[16:52:56 CEST] <BtbN> Ok, tracing it again I actualy end up in the right function...
[16:53:35 CEST] <BtbN> And it actualy points to a usefull error.
[16:53:47 CEST] <BtbN> pic_width/height_in_luma_samples seems to be wrong.
[16:55:31 CEST] <nevcairiel> how can that be wrong
[16:55:48 CEST] <BtbN> Because "pp->pic_width_in_luma_samples  = h->ps.sps->min_cb_width;" is wrong.
[16:56:05 CEST] <nevcairiel> yeah well that is the wrong value =)
[16:56:34 CEST] <BtbN> Now the question is, is ctb_width/height the right one, or do i have to calculate it myself
[16:58:01 CEST] <nevcairiel> if it actually wants luma samples, then give it avctx->coded_width
[16:58:23 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_decoder_utils.c?id=1.6.0#n1158
[16:58:28 CEST] <BtbN> that's the sanity check that fails
[16:59:47 CEST] <nevcairiel> or sps->width for that matter
[17:00:04 CEST] <BtbN> That already is in that unit?
[17:00:20 CEST] <nevcairiel> its in samples
[17:00:22 CEST] <nevcairiel> ie. pixels
[17:00:32 CEST] <nevcairiel> min_cb_width is just derived from that
[17:00:33 CEST] <nevcairiel> sps->min_cb_width  = sps->width  >> sps->log2_min_cb_size;
[17:01:40 CEST] <nevcairiel> sps->width seems appropriate for that variable name anyway
[17:11:08 CEST] <__gb__> BtbN, btw,  I'd like to submit to ML & push by EOW if no strong objections the following: https://github.com/gbeauchesne/FFmpeg/tree/10.vaapi.lavc.fixes
[17:11:37 CEST] <__gb__> this should allow you to extend the internal va context with anything else you'd like without breaking the public api/abi
[17:12:29 CEST] <__gb__> BtbN, pic_width_in_luma_samples is the encoded width
[17:14:21 CEST] <__gb__> wrt. slice_data_byte_offset, my notes from recent discussions have the following: make sure to supply slice-data with the start code prefix in there
[17:14:47 CEST] <__gb__> though, the open source driver seems to work either way, for now
[17:14:54 CEST] <BtbN> btw., do you have any idea why VASliceParameterBufferBaseHEVC is a thing?
[17:15:04 CEST] <BtbN> it seems like a very strange and annoying api break
[17:15:46 CEST] <__gb__> where do you see VASliceParameterBufferBaseHEVC?
[17:16:04 CEST] <__gb__> *Base* data structures are meant for "short-mode" decoding
[17:16:54 CEST] <__gb__> which is not implemented in the open source driver
[17:16:56 CEST] <BtbN> So far VASliceParameterBufferBase was used by ffmpeg to initialize the slice param buffers, because those base params worked for all structures
[17:17:08 CEST] <BtbN> It only contains the first 3 values of all SliceParamBuffer structs
[17:17:13 CEST] <__gb__> that was used because michael didn't want it to return void * :)
[17:17:13 CEST] <BtbN> for all of them, except HEVC
[17:17:43 CEST] <__gb__> I'd say, just don't care about it, return the usual VASliceParameterBufferHEVC allocated buffer
[17:19:00 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/va.h#n1213 <-> http://cgit.freedesktop.org/vaapi/libva/tree/va/va_dec_hevc.h#n210
[17:19:34 CEST] <BtbN> It's the same structure, with the same 3 values. But slightly diffrent size for one, so it's incompatible and makes the common ffmpeg vaapi code for allocating the slice param buffer useless for hevc
[17:19:37 CEST] <__gb__> it is indeed very annoying that that member was shortened to fit an extra slice_data_byte_offset...
[17:20:36 CEST] <__gb__> iirc, you still have the option to post-fix the value in vaapi_hevc.c right?
[17:21:41 CEST] <BtbN> yes, i could do that. Not very pretty though. Currently i just duplicated the entire alloc function for hevc
[17:22:23 CEST] <__gb__> some people argued that on LSB platforms it was safe to still use the original Base struct and only change slice_data_byte_offset
[17:22:45 CEST] <__gb__> s/LSB/little-endian/
[17:26:38 CEST] <cone-075> ffmpeg 03Michael Niedermayer 07master:21566b21d57e: avfilter: add scale2ref filter
[17:29:20 CEST] <BtbN> __gb__, the changes look nice btw. I think i'll rebase ontop of them right away
[17:29:43 CEST] <__gb__> (my personal point would have been: if something is called Base/Common, there are strong reasons to believe that this would really be base/common, forever)
[17:34:11 CEST] <BtbN> Was this change done at a later point, to squeeze another field in there without changing the size?
[17:53:49 CEST] <BBB> nevcairiel: Im happy to ignore, but theyll do it anyway. Making it impossible to do it does make life easier
[18:12:05 CEST] <klaxa> AV_OPT_TYPE_BIANRY is giving me a lot of trouble
[18:12:07 CEST] <klaxa> https://gist.github.com/klaxa/fa446a0141167924bfee
[18:12:16 CEST] <klaxa> that's the code i have + output up until a segfault
[18:12:37 CEST] <klaxa> i'm allocating a sockaddr_storage struct in tcp.c, but when i try to get it with av_opt_get() i get a segfault
[18:13:08 CEST] <klaxa> av_opt_get() is trying to read the memory location but the memory address of *dst is invalid and i don't know why
[18:14:11 CEST] <klaxa> you can get the full repo here: http://git.klaxa.eu/?p=ffmpeg.git;a=shortlog;h=refs/heads/ffserver_http_api_broken2
[18:15:31 CEST] <BBB> did you try valgrind or did you try debugging how much it allocates and how much it writes?
[18:16:49 CEST] <klaxa> no i didn't, when i fill the sockaddr_storage struct with getpeername() it gets populated properly, i later read the address and port with getnameinfo() so i assumed it got allocated correctly?
[18:17:04 CEST] <klaxa> the address and port are correct too
[18:17:08 CEST] <BBB> Im not talking about that memory
[18:17:11 CEST] <klaxa> ah
[18:17:16 CEST] <BBB> Im talking about the memory allocated by av_malloc in that function
[18:17:24 CEST] <BBB> the segfault is when it writes into that memory
[18:17:33 CEST] <BBB> that suggests it wasnt allocated properly, or too short, or sth
[18:18:49 CEST] <klaxa> the address itself is invalid, the for loop with snprintf() segfaults with i == 0
[18:18:59 CEST] <klaxa> but i don't understand why it is incorrect
[18:19:13 CEST] <klaxa> >==960==  Address 0x100007fdad70002 is not stack'd, malloc'd or (recently) free'd
[18:19:19 CEST] <klaxa> that's the address of bin
[18:19:39 CEST] <klaxa> which should be the address of TCPContext->sock_addr?
[18:27:47 CEST] <BBB> what is len?
[18:28:07 CEST] <klaxa> 16
[18:28:27 CEST] <klaxa> which is the correct value (from sizeof(struct sockaddr_storage))
[18:28:59 CEST] <klaxa> it is set after getpeername() populated sock_addr
[18:29:18 CEST] <BBB> does * (deref) take precedence over +?
[18:30:32 CEST] <BBB> I guess it does (unlike ++)
[18:30:54 CEST] <BBB> valgrind complains about invalid write, right? not invalid read?
[18:32:00 CEST] <klaxa> yes
[18:33:27 CEST] <klaxa> here's a screenshot from my debugger: http://dedi.klaxa.eu/public/nemiver_av_opt_get_segfault.png
[18:33:58 CEST] <klaxa> maybe that helps
[18:37:09 CEST] <klaxa> ah wait
[18:37:43 CEST] <klaxa> valgrind does say invalid read
[18:39:32 CEST] <klaxa> https://gist.github.com/klaxa/13143d5f782eba28671e
[18:39:39 CEST] <klaxa> that's the valgrind log
[18:41:36 CEST] <wm4> what debugger is this?
[18:41:41 CEST] <klaxa> nemiver
[19:15:52 CEST] <wm4> BBB: if you're not on linux, and need help to beat the vdpau shit into working, I could help
[19:29:33 CEST] <BBB> wm4: that would be lovely, can you apply that patch, disable the three vdpau version checks, and get it to compile?
[19:30:10 CEST] <BBB> (extra-cflags=-DFF_API_BUFS_VDPAU=0 -DFF_API_CAP_VDPAU=0 -DFF_API_VDPAU=0)
[19:55:52 CEST] <wm4> BBB: I'm not sure which patches I have to apply and in which order, do you just have a git tree?
[19:56:19 CEST] <BBB> [PATCH 1/2] lavc: put remaining bits of vdpau-in-decoder under FF_API_CAP_VDPAU.
[19:56:51 CEST] <BBB> [PATCH 2/2] lavu: comment out wrong value check in get_version() after api bump.
[19:56:53 CEST] <BBB> these two
[19:59:34 CEST] <wm4> the first patch fails to apply
[19:59:42 CEST] <wm4> error: patch failed: libavcodec/vc1dec.c:672
[20:00:04 CEST] <wm4> that's why a git branch would be better
[20:04:59 CEST] <Compn> BBB : default bitrates can break in different containers with certain codecs.  i forgot which one but at least mp2 gives error in some default command lines 
[20:05:26 CEST] <Compn> i'm not saying to not remove whate ver, i'm just letting you know that ive run into such problems (and yes forgot to  report it lol)
[20:05:58 CEST] <Compn> and why mp2 is default for some container i have no idea...
[20:06:32 CEST] <jamrial> wm4: i can apply it with "patch -p1". it warns about line offset and fuzz, but it applies
[20:06:54 CEST] <BBB> $ git push github HEAD:api
[20:06:55 CEST] <BBB> error: unable to push to unqualified destination: api
[20:06:56 CEST] <BBB> The destination refspec neither matches an existing ref on the remote nor
[20:06:57 CEST] <BBB> begins with refs/, and we are unable to guess a prefix based on the source ref.
[20:06:58 CEST] <BBB> error: failed to push some refs to 'git at github.com:rbultje/ffmpeg.git'
[20:06:59 CEST] <BBB> ?
[20:07:12 CEST] <BBB> I feel stupid, but uhm& wtf?
[20:07:18 CEST] <BBB> did I forget how github worked?
[20:07:28 CEST] <Compn> do you have api branch on github ?
[20:07:32 CEST] <BBB> no
[20:07:36 CEST] <BBB> Im trying to create it
[20:07:39 CEST] <Compn> you have to create it first then
[20:07:48 CEST] <Compn> (i dont know how)
[20:08:09 CEST] <ubitux> BBB: git push -u github api ?
[20:08:21 CEST] <ubitux> (you are in a local api branch, right?)
[20:08:33 CEST] <jamrial> use -n first to simulate the push
[20:09:04 CEST] <BBB> my local branch has no name
[20:09:14 CEST] <BBB> detached branch
[20:09:39 CEST] <nevcairiel> That might be a problem, those things don't work well
[20:10:08 CEST] <BBB> ubitux: ty
[20:10:10 CEST] <BBB> wm4: https://github.com/rbultje/ffmpeg/tree/api
[20:10:14 CEST] <wm4> BBB: thanks
[20:10:38 CEST] <BBB> current cflags: -DFF_API_BUFS_VDPAU=0 -DFF_API_SET_DIMENSIONS=0 -DFF_API_ASPECT_EXTENDED=0 -DFF_API_ERROR_RATE=1 -DFF_API_MB_TYPE=0 -DFF_API_MAX_BFRAMES=0 -DFF_API_INPUT_PRESERVED=0 -DFF_API_NORMALIZE_AQP=1 -DFF_API_GMC=1 -DFF_API_MV0=1 -DFF_API_CODEC_NAME=0 -DFF_API_AFD=0 -DFF_API_OLD_FILTER_OPTS=0 -DFF_API_OLD_FILTER_REGISTER=0 -DFF_API_LAVF_BITEXACT=1 -DFF_API_LAVF_CODEC_TB=0 -DFF_API_XVMC=0 -DFF_API_XVMC=0 
[20:10:39 CEST] <BBB> -DFF_API_CAP_VDPAU=0 -DFF_API_DEBUG_MV=0 -DFF_API_EMU_EDGE=0 -DFF_API_UNUSED_MEMBERS=0 -DFF_API_OLD_AVOPTIONS=0 -DFF_API_VDPAU=0 -DFF_API_DLOG=0
[20:10:45 CEST] <BBB> so you see I still have a bunch to go :(
[20:11:18 CEST] <wm4> so I add --extra-cflags='-DFF_API_BUFS_VDPAU=0 -DFF_API_CAP_VDPAU=0 -DFF_API_VDPAU=0' to configure?
[20:12:02 CEST] <BBB> yeah
[20:12:26 CEST] <BBB> probably also -DFF_API_OLD_AVOPTIONS=0 
[20:12:36 CEST] <BBB> since that one causes a fate change which is part of my tree
[20:15:10 CEST] <wm4> http://privatepaste.com/c30098c967
[20:15:34 CEST] <wm4> I can try to make it compile (slightly later)
[20:15:37 CEST] <BBB> right, so I tihnk each of these codecs with vdpau need to be under #if FF_API_VDPAU
[20:15:47 CEST] <BBB> theres a bunch in various places
[20:15:52 CEST] <BBB> (they are replaced by hwaccel)
[20:16:09 CEST] <BBB> FF_API_CAP_VDPAU is also fine, I mean, theyre the same thing essentially
[20:16:19 CEST] <nevcairiel>  That shit will never be removed as long as Carl can stall the entire dev process though
[20:16:19 CEST] <j-b> a1m
[20:17:11 CEST] <BBB> nevcairiel: Ill just push the change that removes it
[20:17:15 CEST] <BBB> Im happy to fight over it with carl
[20:17:26 CEST] <Compn> i dont think the list of api in version.h is what you think it is.
[20:17:35 CEST] <Compn> should probably make a new list...
[20:17:49 CEST] <BBB> ?
[20:18:31 CEST] <Compn> nevermind
[21:20:51 CEST] <BBB> so Im onfused about fate
[21:21:07 CEST] <BBB> I have one particular test that gives non-consistent results after removing the +bitexact flag forward (fate-lavf-mov)
[21:21:17 CEST] <BBB> so 3 runs of lavf-mov gives 3 different diffs
[21:21:30 CEST] <BBB> however, V=1 gives me a command that, when run, gives the same result every time
[21:29:23 CEST] <BBB> aha its the rtp hinting
[21:29:25 CEST] <BBB> wth
[21:32:27 CEST] <wm4> so I got kind of sidetracked, but I'll look at the vdpau things now
[21:34:46 CEST] <BBB> wbs: how did libav fix it? I dont see anything obvious on the libav side on getting rtp hinting to be bitexact for the fate-lavf-mov test
[21:35:36 CEST] <wm4> BBB: oh I get it... the vdpau decoder should have been disabled at config time
[21:35:41 CEST] <wm4> I'm not sure how we do this
[21:35:57 CEST] <wm4> disable a configure entry on a deprecation
[21:37:43 CEST] <BBB> I dont think we have methods for that yet
[21:37:56 CEST] <BBB> can we just #if FF_API_VDPAU && CONFIG_&_DECODER?
[21:38:01 CEST] <BBB> its knidna weird but ..
[21:39:08 CEST] <wm4> no, because the gloarious allcodecs.c crap ruins it
[21:39:19 CEST] <wm4> glorious even (but that works too)
[21:39:34 CEST] <BBB> but you can #if the registrations?
[21:39:35 CEST] <BBB> right?
[21:39:48 CEST] <BBB> #if 0
[21:39:52 CEST] <BBB> REGISTER_ENCDEC(..)
[21:39:52 CEST] <BBB> #endif
[21:39:53 CEST] <BBB> etc.
[21:40:47 CEST] <wm4> no
[21:40:54 CEST] <wm4> because that file is parsed by configure
[21:41:11 CEST] <jamrial> it's being done for mpeg_xvmc
[21:41:19 CEST] <jamrial> it's inside a FF_API_XVMC guard
[21:41:26 CEST] <BBB> we can ignore the configure check
[21:41:45 CEST] <BBB> as long as any CONFIG_BLA_VDPAU_DECODER is within a FF_API_VDPAU
[21:42:00 CEST] <wm4> jamrial: right, I guess it disabled it at runtime, even if configure still can enable it
[21:42:21 CEST] <wm4> doing that then
[21:47:24 CEST] <wm4> "make: *** No rule to make target 'libavutil/reverse.c', needed by 'libavcodec/qdm2_tablegen.o'.  Stop."
[21:47:45 CEST] <wm4> I still had --enable-hardcoded-tables for testing
[21:47:59 CEST] <wm4> but I'm going to do what everyone does, and ignore compilation failures with this option
[21:48:16 CEST] <wm4> at least I can choose to intentionally code-rot optional features I don't like
[21:48:19 CEST] <wm4> !!!111
[21:48:41 CEST] <BBB> muahahhaah
[21:48:45 CEST] <BBB> isnt that what everyone does?
[21:48:48 CEST] <BBB> ...
[21:48:49 CEST] Action: BBB runs
[21:50:04 CEST] <wm4> hm same error
[21:50:05 CEST] <wm4> confusing
[21:50:10 CEST] <jamrial> i insist the reverse stuff in lavc should be undone. including lavu/reverse.c from lavc headers and c files is ugly
[21:50:49 CEST] <wm4> what does this tablegen stuff help with anyway?
[21:51:53 CEST] <Daemon404> init time
[21:51:55 CEST] <Daemon404> in theory.
[21:52:00 CEST] <Daemon404> emphasis on theory
[21:52:26 CEST] <atomnuker> really really memory constrained embedded systems?
[21:54:02 CEST] <BBB> like, those that cant play video anyway? :)
[21:54:29 CEST] <Daemon404> tabglgen is also for audio ;)
[21:57:39 CEST] <BBB> hm...
[21:57:47 CEST] <BBB> I guess audio only is one use case yes
[21:58:17 CEST] <Daemon404> yeah but nobody uses sw aac.
[22:03:39 CEST] <iive> what do you mean by sw aac?
[22:11:37 CEST] <wm4> BBB: http://sprunge.us/GFaQ
[22:12:01 CEST] <wm4> man how much code the old vdpau decoders duplicate
[22:12:19 CEST] <wm4> and it was done only because of mplayer (though to be fair, it helped finding bugs in the new code)
[22:12:37 CEST] <BBB> \o/
[22:12:45 CEST] <BBB> do you want to send it to the ML?
[22:12:52 CEST] <BBB> Ill add it to my queue so I can push it at the same time
[22:13:03 CEST] <BBB> or actually Ill just take this and set --author=..
[22:13:36 CEST] <wm4> just take it and squash it or whatever you want
[22:13:58 CEST] <wm4> I couldn't test with mpv, because mpv would crash due to the ABI mismatch caused by defining the FF_... directly
[22:14:43 CEST] <BBB> oh &
[22:14:44 CEST] <BBB> hm ...
[22:14:46 CEST] <BBB> right
[22:14:55 CEST] <BBB> I had not thought about that
[22:15:00 CEST] <BBB> ohwell
[22:15:11 CEST] <wm4> hm actually let me just edit version.h
[22:16:06 CEST] <Daemon404> iive, as in many embedded devices do not use software aac decoding
[22:18:22 CEST] <iive> Daemon404: and i've seen it used in embedded device firmware for the "hw" decoder.
[22:19:00 CEST] <jamrial> people bothered to write aac/ac3/mp3 asm for mips/arm, so some certainly do use sw decoding
[22:19:25 CEST] <nevcairiel> and there is apparently still systems without floating point units
[22:21:08 CEST] <durandal_170> we really should move forward, ff in ffmpeg have it
[22:36:27 CEST] <BBB> wm4: btw thanks for helping, it does sort of feel like everyone is bikeshedding over nothingnesses all over the place, good to get at least some positive feedback
[22:52:34 CEST] <BBB> does anyone want to look into the mov rtp hinting bitexact flag transfer issue?
[22:52:45 CEST] Action: BBB desperately looks for volunteers
[22:53:28 CEST] <wm4> I just bumped all libs majors, and now libavfilter has problems
[22:53:57 CEST] <wm4> tries to use AVFilterBufferRef and FF_QSCALE_...
[22:56:27 CEST] <BBB> I havent fixed FF_QSCALE yet
[22:56:32 CEST] <BBB> that one is really hard :(
[22:56:39 CEST] <BBB> AVFilterBufferRed, Andreas posted a patch for that
[22:56:45 CEST] <BBB> it might not have been applied to my tree yet
[22:57:02 CEST] <wm4> what's the deal with FF_QSCALE? is it just dead code?
[22:58:03 CEST] <BBB> & no & I mean
[22:58:08 CEST] <BBB> it depends how you define dead
[22:58:24 CEST] <BBB> it feeds into lavfilter -> postprocess filters
[22:58:31 CEST] <BBB> which use q to set filter strength
[22:58:44 CEST] <BBB> and then use a codec-specific scale modifier (since scales mean different things between codecs)
[22:59:17 CEST] <BBB> its utterly broken if you ask me, conceptually, since any new codec needs to add new api to postprocess to get anything to work, rather than scaling to a common unit
[22:59:40 CEST] <BBB> but what do I know, I dont design code, I just fix crap other people leave behind before they fall off the earth :(
[23:00:09 CEST] <wm4> blame people like cehoyos (KEEP ALL THE FEATURES)
[23:00:12 CEST] <BBB> libav doesnt have this issue because they deleted libpp
[23:00:58 CEST] <wm4> anyway, I guess this means we undeprecate FF_QSCALE, since nobody will fix it, but there are certain people refusing to delete it too
[23:01:29 CEST] <ubitux> why was ff_dlog in libavcodec&
[23:01:46 CEST] <ubitux> it obviously belongs in lavu
[23:01:47 CEST] <j-b> oh boy, a 7MB SSA file with moving subtitles, in a wave-pattern
[23:02:04 CEST] <ubitux> j-b: need
[23:02:22 CEST] <ubitux> j-b: probably just an usual lua-template generated
[23:02:23 CEST] <j-b> for 1:20 video
[23:02:44 CEST] <ubitux> does it include the generating code?
[23:03:00 CEST] <wm4> j-b: that's nothing
[23:03:07 CEST] <BBB> wm4: Im currently thinking to postpone deprecation& I dont know if itll ever go anywhere, indeed
[23:03:09 CEST] <wm4> j-b: I've seen 70MB files for the same length, and larger
[23:03:26 CEST] <BBB> wm4: but I consider it hugely unsatisfactory design, so undeprecation seems like me saying its ok, which it isn't
[23:03:27 CEST] <j-b> https://trac.videolan.org/vlc/ticket/15257#comment:1
[23:03:29 CEST] <wm4> BBB: from my point of view, it looks like QSCALE goes nowhere
[23:03:34 CEST] <j-b> wm4: sorry, master.
[23:04:10 CEST] <wm4> j-b: in libass there are actually people trying to fix such issues
[23:04:12 CEST] <wm4> kind of
[23:04:13 CEST] <jamrial> qscale_type element from AVFrame (used by av_frame_{get,set}_qp_table which is called by these pp filters) is deprecated with FF_API_AVFRAME_LAVC
[23:04:25 CEST] <jamrial> but the av_frame_{get,set}_qp_table functions are not
[23:04:35 CEST] <ubitux> doesn't include the code :(
[23:04:40 CEST] <ubitux> too bad
[23:07:25 CEST] <ubitux> j-b: actually sounds like classic karaoke
[23:07:52 CEST] <ubitux> not really evolved
[23:07:55 CEST] Action: ubitux disappointed
[23:08:14 CEST] <wm4> I don't want to know what "evolved" is
[23:08:38 CEST] <ubitux> well i mean, it's just vibrating kara with a small blur
[23:09:40 CEST] <ubitux> when you see shit like this https://www.youtube.com/watch?v=HWn4pxNu67I
[23:09:46 CEST] <ubitux> it's way more interesting :)
[23:12:37 CEST] <ubitux> https://www.youtube.com/watch?v=MDQTUwFcb2c or this e ~
[23:13:11 CEST] <ubitux> the result is really silly, but i admire so much the performance
[23:13:29 CEST] <ubitux> i think it's pretty sick to be able to do stuff like this
[23:13:51 CEST] <wm4> you could even do much more if it didn't use an inefficient old format designed for subtitles
[23:13:54 CEST] <j-b> h god
[23:14:06 CEST] <BBB> jamrial: so deprecate the functions
[23:14:16 CEST] <BBB> jamrial: and make it side-data
[23:14:22 CEST] <BBB> jamrial: or whatever you think is right
[23:14:23 CEST] <BBB> anyway
[23:14:43 CEST] <BBB> I have 4 issues to go and then Ill call it a day, Ive posted more than enough bikesheddy patches
[23:14:55 CEST] <BBB> and here I thought I would do something useful today :(
[23:15:30 CEST] <ubitux> j-b: you don't watch enough animes
[23:15:45 CEST] <ubitux> j-b: why do you think ffmpeg uses ass as internal format for decoded subtitles
[23:15:48 CEST] <ubitux> ass to rule them all
[23:16:10 CEST] <wm4> that's not a good match either
[23:16:12 CEST] <jamrial> BBB: how are they bikesheddy?
[23:16:26 CEST] <BBB> not a single one has been approved
[23:16:34 CEST] <wm4> ass is merely the most powerful format which ffmpeg supports most completely
[23:16:39 CEST] <ubitux> libass is pretty much the only usable subtitles engine supersetting almost any sub format
[23:16:50 CEST] <BBB> and half of them generate responses like but but but -ab is used in user scripts"
[23:18:06 CEST] <wm4> I wonder if I should start LGTM spam in reply to your patches
[23:18:16 CEST] <wm4> (moral support??)
[23:20:19 CEST] <ubitux> j-b: https://www.youtube.com/watch?v=C0wT7r9da9c if you hadn't enough
[23:20:29 CEST] <ubitux> anyway, afk
[23:21:23 CEST] <BBB> moral support is nice
[23:21:26 CEST] <BBB> lgtm spam is also nice
[23:21:32 CEST] <jamrial> BBB: "fate: move -flags +mv0 -> -mpv_flags +mv0." is pretty straighforward so it should be ok to commit
[23:22:41 CEST] <kierank> ubitux: omg
[23:22:46 CEST] <jamrial> same with the dbl -> i64 libvpx one
[23:24:22 CEST] <BBB> those are subtitles?
[23:24:24 CEST] <BBB> wth
[23:24:32 CEST] <BBB> :D
[23:27:48 CEST] <wm4> now my mail client is acting up, what a POS
[23:29:00 CEST] <BBB> how dare you approve patches that mplayer overlords would frown on!
[23:29:12 CEST] <BBB> (thats your mail client talking right there)
[23:54:49 CEST] <rcombs> ubitux: one ass to rule them all
[23:54:52 CEST] <rcombs> one ass to bind them
[23:54:58 CEST] <rcombs> erm, find them
[23:55:14 CEST] <rcombs> y'know I'm not as into LOTR as I should be
[00:00:00 CEST] --- Tue Aug 18 2015