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

[burek]

[00:00:12 CET] <durandal_1707> but dynamic dimensions are still not defined well
[00:00:47 CET] <cone-102> ffmpeg 03Andreas Cadhalpun 07master:38622007c4bd: vf_libopencv: add support for opencv 3
[00:01:31 CET] <durandal_1707> for example, when to update buffersink dimensions
[00:02:14 CET] <durandal_1707> when it have mix of different frames
[00:03:05 CET] <durandal_1707> so link dimensions are useless and frame should be used directly
[00:03:42 CET] <durandal_1707> instead of link w and h
[00:05:32 CET] <durandal_1707> but if you prefer I can force all inputs to have same dimension
[00:09:43 CET] <ubitux> no, streamselect should support it
[00:09:44 CET] <nevcairiel> jamrial: this dts-in-wav that michaelni found broken is ...odd.  Its not even in the usual 14b dts-in-wav format, but a 16b LE bitstream, which is like the rarest format ever, and has giant audio frames
[00:09:54 CET] <ubitux> lavf should make the constraints
[00:12:15 CET] <nevcairiel> the frames are literally padded with 12kb of zeros
[00:17:10 CET] <durandal_1707> if because of that new dts decoder blocked?
[00:22:49 CET] <kierank> nevcairiel: is it not spdif?
[00:23:00 CET] <kierank> hence the padding
[00:24:41 CET] <nevcairiel> i suppose someone could have created it with an spdif encoder, but strictly speaking spdif needs BE dts, not LE
[00:29:21 CET] <durandal_1707> blocking because of some dumb sample is bad
[00:33:45 CET] <nevcairiel> lets see if foo96 shows up to comment on the issue, I dumped my analysis and idea for solution on the ML
[00:33:51 CET] <nevcairiel> 86*
[00:39:03 CET] <jamrial> dcadec cli can't decode it either. it reports it's a "20bit 5.1 48khz" stream before failing
[00:39:47 CET] <jamrial> current ffdca decoder has apparently no issues decoding it, and doesn't show any warnings
[00:40:08 CET] <nevcairiel> The error that triggers is an overread check in the new decoder
[00:40:25 CET] <nevcairiel> but it doesnt overread the input, just the designated frame size in the core header
[00:40:48 CET] <nevcairiel> which should probably be a warning or explode condition, not a general error
[00:44:57 CET] <nevcairiel> If i just disable the error, it decodes and seemingly sounds fine
[00:55:47 CET] <kierank> no idea how to fix this fuzz crash
[02:57:04 CET] <atomnuker> From Debian's Chromium changelog: * Use ld.gold to avoid memory exhaustion while linking (closes: #812569).
[02:58:18 CET] <atomnuker> I think they've almost ran out of libraries to statically link now
[04:17:44 CET] <Plorkyeran> it's awesome how gold still isn't the default
[04:17:48 CET] <Plorkyeran> after something like a decade
[05:41:36 CET] <rcombs> https://gist.github.com/f5ca1ee40e622309ae8d I gave up on trying to figure out the cause of this and sent https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188045.html instead
[10:07:38 CET] <flux> I wonder, has it been considered that an AV_OPT_JSON might be useful in some cases?
[10:16:00 CET] <durandal_1707> what would that do?
[10:22:34 CET] <flux> well, pass in a complex argument such as { "track": 5, "tunables": [1, 2, 3] }
[10:23:04 CET] <flux> in practice the alternative is to use AV_OPT_STRING and figure out a minimal protocol for doing the same
[10:23:20 CET] <flux> potentially doing it in a different by every piece of code needing it :)
[10:24:13 CET] <flux> another thing is that it would eventually provde a way to use the direct structured representation as the argument, bypassing the json generation and parsing altogether
[10:24:38 CET] <flux> (when used as a library that is)
[10:27:20 CET] <durandal_1707> patch welcome :P
[10:27:44 CET] <flux> really? because if it's acceptable then it might just happen ;-)
[10:27:56 CET] <durandal_1707> ubitux: sent new version
[10:28:50 CET] <durandal_1707> flux: how would you know where and how to store data ?
[10:29:09 CET] <flux> durandal_1707, it would work just like the rest of the (ie. encoder) options
[10:30:09 CET] <flux> durandal_1707, so basically you have a context where there would be, say, Structured tunables; and then 00~{ "tunables", "Track tunables", offsetof(Context, tunables),   AV_OPT_TYPE_JSON, {.structured = NULL}, .flags = AV_OPT_FLAG_ENCODING_PARAM }
[10:30:59 CET] <nevcairiel> I don't see the benefit, instead of setting a struct of options, the options should just be seperate options so that you can get the automatic options documentation and set them using the existing options api
[10:32:01 CET] <flux> I can see that viewpoint, but the data I'm thinking of writes a set of parameters to potentially all the tracks (I'm not actually discussing the kind of the data until the project is able to be published)
[10:32:33 CET] <flux> it might work in this case if there was a possibility to reuse an option multiple times, but I don't think it is?
[10:35:36 CET] <nevcairiel> not to mention that inputting json strings over the CLI API would be terrible, while using the existing syntax even for a long list of options is equally verbose, but not quite as annoying
[10:36:05 CET] <flux> well, I'm not really pursuing the JSON syntax as is, but only the ability to parse something more than individual strings or integers or such
[10:36:24 CET] <flux> for example how would one pass a list of integers as an option?
[10:37:06 CET] <nevcairiel> use a string, split it into integers wherever its needed
[10:37:13 CET] <jkqxz> I was wondering about JSON options, too.  Passing them on the command line is nasty but possible, and being able to say "load them from this text file" would make it much nicer.
[10:37:34 CET] <flux> nevcairiel, and if maybe I need to pass a list of such lists?
[10:37:47 CET] <nevcairiel> don't
[10:37:50 CET] <flux> :-)
[10:37:52 CET] <nevcairiel> keep options simple =p
[10:38:07 CET] <flux> so if I want to pass complex data, add a new API?
[10:39:33 CET] <flux> it would be sort of elegant to have one place for providing setup data, simple or complex
[10:41:55 CET] <nevcairiel> codec-specific API is never a good idea
[10:45:37 CET] <nevcairiel> we havent really had a need for anything to have extremely complex options, the most complex is probably things like x264 which have a wild mixture of native ffmpeg options and their own private x264opts which is a list of options inside a string field
[10:48:03 CET] <flux> maybe the right solution for my track/encoder-specific (but it really could be applied to other encoders in principle) would be adding a field type to AVPacketSideDataType and go that way
[10:54:28 CET] <flux> nevcairiel, thanks for the feedback! it is always nice to know upfront what kind of changes might be approved and what not :).
[10:56:01 CET] <nevcairiel> in general, complex public user-facing APIs will be under serious scrutiny, since once we have them we're stuck with them for a long time. So best is always to use what we have instead of forcing new API
[10:57:32 CET] <flux> well, let's say ISO MP4 has very many features..
[11:11:02 CET] <wm4> durandal_1707: in my opinion lavfi simply doesn't support dynamic reconfiguration, and the process command code in vf_scale and vf_crop is a bug
[11:11:16 CET] <wm4> if you want dynamic reconfiguration, it should be figured out properly
[11:11:33 CET] <wm4> without introducing random inconsistencies all over the place
[11:13:48 CET] <durandal_1707> not really, its possible just that you need to use frame width/height instead of outlink/pads
[11:16:46 CET] <wm4> no, that's a random inconsistency
[11:17:14 CET] <wm4> and "happens to work sometimes" is not "figured out properly"
[11:20:12 CET] <durandal_1707> noted that we disagree
[11:20:57 CET] <wm4> I hate this style of development, and it's a reason why the ffmpeg API is traditionally so bad
[11:21:24 CET] <wm4> no clear concept of how it should work
[11:21:29 CET] <wm4> inconsistencies all over the place
[11:21:40 CET] <wm4> some things just crashing on format changes
[11:22:04 CET] <ubitux> reconfiguration should definitely be defined better (and tested)
[11:22:24 CET] <ubitux> (yes i know thx captain obvious)
[11:22:56 CET] <ubitux> do we even have a flag for filters supporting configuration changes?
[11:23:24 CET] <wm4> according to durandal_1707 the flag is "if it doesn't crash"
[11:23:25 CET] <ubitux> i remember some kind of broken list of filters somewhere
[11:30:07 CET] <durandal_1707> the scale filter should rescale if filter doesnt support it
[11:31:41 CET] <durandal_1707> but note that there is already inconsistency and crashes, they are just more easily accessible with streamselect
[11:32:36 CET] <wm4> what about other parameters like pixfmt, timebase, aspect
[11:33:09 CET] <wm4> and inserting a scale filter would be very ugly (is this really what a user would want in most cases?)
[11:38:56 CET] <durandal_1707> timebase can already be changed with settb
[11:39:46 CET] <durandal_1707> format/layout/samplerate needs new graph
[12:10:55 CET] <wm4> so format change support is worthless anyway
[12:13:40 CET] <cone-119> ffmpeg 03Hendrik Leppkes 07master:c2869b4640f0: avutil: add P010 pixel format
[12:13:40 CET] <cone-119> ffmpeg 03Hendrik Leppkes 07master:2e31434d84bb: swscale: add P010 input support
[12:15:19 CET] <wm4> now only the dxva change is missing
[12:15:35 CET] <nevcairiel> someone should simd the p010 input support, its so fucking slow
[12:23:56 CET] <ubitux> always perplexed when the first video frames have negative ts
[12:23:58 CET] <ubitux> :(
[12:24:31 CET] <kierank> what's P010?
[12:27:38 CET] <nevcairiel> NV12 in 10-bit, see https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578%28v=vs.85%29.aspx
[12:27:40 CET] <jkqxz> A really unhelpfully named fourcc.
[12:28:17 CET] <nevcairiel> actually the names arent that bad if you understand the naming scheme, once you do you can just understand what P010, P016, P210, P216 etc are just from their name
[12:29:24 CET] <wm4> I really think there's no way to defend fourcc naming conventions
[12:29:38 CET] <wm4> (same for subsampling)
[12:29:50 CET] <nevcairiel> its just 4 letters, its not like you can put that much meaningful details in them : p
[12:29:55 CET] <jkqxz> The "four" part of it is rather too low.
[12:30:19 CET] <nevcairiel> I still prefer  P010 or NV12 over the apple equivalent
[12:30:50 CET] <nevcairiel> or android mediacodec
[12:30:54 CET] <nevcairiel> way too verbose names :D
[12:30:56 CET] <wm4> you don't like kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange?
[13:31:00 CET] <atomnuker> michaelni: getting somethin odd here, your dirac decoder golomb reading patches actually slightly reduce performance
[13:31:21 CET] <atomnuker> this very naive way of reading is a bit faster: https://0x0.st/HnV.diff
[13:40:18 CET] <atomnuker> michaelni: btw, this is what the specs give as examples: https://0x0.st/HnW.png
[13:41:17 CET] <atomnuker> I've noticed that the length of each coefficient is basically the distance from the start to the first 1 in an even position
[14:42:18 CET] <michaelni> atomnuker, reading bits, one at a time even if faster is a dead end, reading multiple symbols will be faster
[14:42:48 CET] <michaelni> also which commits made it slower ?
[14:44:33 CET] <michaelni> of course iam fine with changing to 1 bit reading if that is faste then the current code until somone implements something better ...
[14:45:30 CET] <atomnuker> it's fine, I think I can completely avoid any loops
[14:46:37 CET] <atomnuker> just showing 16 bits, ANDing those with 87381 to remove any 1s at odd positions
[14:47:11 CET] <atomnuker> then just doing an ff_log2 will give you the length of the entire golomb code
[14:47:58 CET] <atomnuker> then starting from the original coefficient, removing the 1 at the end (after shifting it by the length to avoid garbage)
[14:48:21 CET] <atomnuker> and adding +1 to the coefficient for every single odd bit which is 1
[15:01:37 CET] <kierank> michaelni: are there any examples of how to read multiple symbols?
[15:06:03 CET] <michaelni> there are plenty but i think they are about slightly different situations,  huffyuv is one, also we merged symbols frequently for inner loops of othe important decoders, AC VLC but these have small sets of VLCs so a fixed number of symbols can be merged
[15:08:14 CET] <michaelni> for dirac if one would lets say read 12bit and look in a table that could contain 12 symbols or fewer down to less than 1 complete symbol
[15:09:19 CET] <michaelni> there are many many ways to use this, one could have such 12bit table that lists the complete symbols if any + the number of bits to move forward
[15:09:45 CET] <michaelni> and a fall back to handle symbols that are longer than 12bit
[15:21:15 CET] <durandal_1707> why nobody writes simd for utvideo?
[15:22:15 CET] <kierank> because utvideo
[15:22:49 CET] <Compn> maybe scared of author changing a bunch of code ?
[15:22:56 CET] <Compn> or no one cares about weeaboo codecs?
[16:04:41 CET] <durandal_1707> Compn: kierank doesnt use it
[16:07:32 CET] <ubitux> is it well supported to have a 1/tb ` samplerate for audio?
[16:08:44 CET] <kierank> mpegts does it
[16:08:48 CET] <kierank> mkv as well
[16:09:08 CET] <ubitux> ok
[16:43:49 CET] <atomnuker> nevcairiel: "output" is the keyword here, I could change the pointers of the AVFrame I was given during the second field, but then I'd need to free the pointers I replaced and the new pointers to the data from my frame would get freed as well
[16:44:05 CET] <atomnuker> so I'd still end up doing an allocation
[16:44:40 CET] <atomnuker> and all of this just to save what is basically a memcopy
[16:45:00 CET] <nevcairiel> a memcpy of raw image data is always worth saving
[17:33:22 CET] <Daemon404> so uh
[17:33:29 CET] <Daemon404> why is github not being updated
[17:36:57 CET] <cone-213> ffmpeg 03Michael Niedermayer 07master:f3ace85d8869: avutil/opt: check for and handle errors in av_opt_set_dict2()
[17:36:58 CET] <cone-213> ffmpeg 03Vittorio Gambaletta (VittGam) 07master:6e448fb97ee2: ffmpeg_opt: Move the 'process manually set programs' block above 'process manually set metadata' in open_output_file().
[17:36:59 CET] <cone-213> ffmpeg 03Vittorio Gambaletta (VittGam) 07master:74658a8b4db3: ffmpeg_opt: Allow -metadata option to set metadata on programs.
[18:09:12 CET] <kierank> ffmpeg and udp...
[18:09:36 CET] <durandal_1707> yes?
[18:09:56 CET] <durandal_1707> push cfhd?
[18:09:59 CET] <jermy> ...sitting in a tree? Where are you going with this?
[18:11:02 CET] <jermy> (and the answer is: it could do with a much larger default fifo_size for higher bandwidth content)
[18:11:54 CET] <kierank> durandal_1707: I will do that at fosdem
[19:02:03 CET] <Timothy_Gu> Daemon404: 09:53 <@Timothy_Gu> kierank: I'm running a cron job that updates the GitHub mirror every hour
[19:22:33 CET] <durandal_1707> anybody against dvaudio patch?
[19:23:03 CET] <durandal_1707> I would like to close 4 years old bug
[19:43:01 CET] <kierank> J_Darnley: are you coming on friday?
[20:11:56 CET] <J_Darnley> kierank: You mean the beer drinking, rihgt?
[20:12:01 CET] <J_Darnley> I might.
[20:15:28 CET] <durandal_1707> michaelni: does it make sense to visualize concealed pixels with codecview filter?
[20:18:27 CET] <J_Darnley> durandal_1707: re. the dvaudio patch: is there a source for the numbers in dv_get_audio_sample_count()?  Or would someone who knows dvaudio be able to see where they come from?
[20:19:49 CET] <J_Darnley> I guess I also want to ask the same about the shuffle assignment in dv_get_audio_sample_count().
[20:20:25 CET] <durandal_1707> its from dv_profile.c
[20:20:58 CET] <durandal_1707> and dc code from demuxer
[20:21:21 CET] <durandal_1707> It's ripped from dc container
[20:21:28 CET] <durandal_1707> *dv
[20:22:25 CET] <Compn> durandal_1707 : you test with all dvaudio samples ?
[20:22:35 CET] <Compn> or if not, its not important, can be fixed later..
[20:24:40 CET] <J_Darnley> Okay, I see.  No other comments from me about the patch.
[20:25:07 CET] <durandal_1707> Compn: yes
[20:25:30 CET] <durandal_1707> all have been tested
[20:51:46 CET] <J_Darnley> kierank: what time did you plan to arrive at the beer event?
[20:51:53 CET] <kierank> dunno
[20:51:57 CET] <kierank> 7/8 I guess
[20:52:03 CET] <kierank> I think the current plan is to visit bruges
[20:53:31 CET] <J_Darnley> I guess I'll try to have dinner early(ish) and then get the bus.
[20:53:32 CET] <Daemon404> kierank, hopefully one can get in at that time
[20:53:33 CET] <michaelni> durandal_1707, error concealment visualization sounds certainly interresting
[20:53:45 CET] <kierank> Daemon404: I always get in at about 9
[20:53:47 CET] <kierank> and squeeze in
[20:54:05 CET] <Daemon404> my first year i arrived aroudn then and i could not get in until diego argued with a guy for 15 mins
[20:54:44 CET] <Daemon404> (last year i arrived at 5 and that was a mistake)
[20:55:20 CET] <J_Darnley> Were you out cold by the time anyone else arrived?
[20:55:42 CET] <kierank> I remember last year you lot were all drunk when I arrived
[20:55:57 CET] <Daemon404> J_Darnley, left at midnight
[20:56:03 CET] <Daemon404> s/left/dragged off by coworker/
[20:58:24 CET] <Daemon404> maybe 7-8 this year.
[21:33:22 CET] <llogan> i'm back now. everything is going to be ok, citizens.
[21:42:16 CET] <J_Darnley> Praise the LLord.  For he has returned.
[21:49:16 CET] <llogan> facebook made a ffilter: https://github.com/facebook/transform
[21:49:30 CET] <llogan> unfortunately, icense.
[21:49:38 CET] <llogan> license
[21:52:24 CET] <atomnuker> that AVOption usage...
[21:54:15 CET] <wm4> what about it? except that there are 50 or so
[21:56:18 CET] <atomnuker> did not use BOOL, use strings and have synonyms
[21:59:50 CET] <TD-Linux> llogan, seriously WTF is that license
[22:00:12 CET] <jamrial_> atomnuker: bool avoption is not in 2.8, so maybe that's why
[22:01:11 CET] <TD-Linux> does anyone actually recognize that license?
[22:09:01 CET] <J_Darnley> Is it not a bsd variant?
[22:09:53 CET] <cone-213> ffmpeg 03Ivan 07master:a0174f67298b: avformat/flvenc: copyts in FLV muxer
[22:10:46 CET] <J_Darnley> aw :( duckduckgo couldn't find it for me
[22:11:15 CET] <jkqxz> Seems to be used on several facebook things and nowhere else.
[22:12:01 CET] <JEEB> classic
[22:13:49 CET] <BtbN> I don't understand what this filter does oO
[22:15:25 CET] <J_Darnley> Ha ha ha.  Now I'm getting results for ANPR or ALPR
[22:18:49 CET] <J_Darnley> Dammit search engines!  When I "quote a string" I want that exact string!
[22:20:00 CET] <durandal_1707> llogan: isn't that panorama filter I wrote, I mean does same thing
[22:20:30 CET] <durandal_1707> name of filter is extremely verbose
[22:20:52 CET] <llogan> not sure. didn't get to look at it because one of my servers went down after i pasted link.
[22:21:17 CET] <llogan> i've come to hate being a server bitch
[22:36:06 CET] <BBB> michaelni: how does input frame ownership in AVCodec video encoding implementations work? particularly when talking about internal frame queues
[22:36:26 CET] <BBB> michaelni: should I always copy if I want an internal frame queue? or is there some trick?
[22:39:03 CET] <nevcairiel> just try to ref the frame, if its refcounted yay, otherwise it should automatically make a copy for you?
[22:40:51 CET] <BBB> but the input is const AVFrame *, not AVFrame *
[22:41:00 CET] <BBB> you cant modify the refcount if its const
[22:41:47 CET] <BBB> I also dont see libx264.c of libvpxenc.c ref the input frame
[22:42:00 CET] <BBB> although m honestly not sure how they work, they may just copy
[22:42:10 CET] <nevcairiel> probably do
[22:42:22 CET] <nevcairiel> since their api cant rely on any external refcounting
[22:47:46 CET] <michaelni> the refcount isnt in AVFrame its in AVBuffer. i think const AVFrame should work
[22:52:36 CET] <BBB> michaelni: http://pastebin.com/rg24e3vB
[22:52:40 CET] <BBB> I dont think that works
[22:54:02 CET] <BBB> oh as a struct it does?
[22:54:03 CET] <BBB> hm
[22:54:09 CET] <BBB> pointer
[22:54:28 CET] <BBB> nvm
[23:13:50 CET] <cone-213> ffmpeg 03Paul B Mahol 07master:df7b165e878e: avfilter/vf_zscale: make it possible to override input frame parameters
[23:17:47 CET] <cone-213> ffmpeg 03Paul B Mahol 07master:e9e623369d7b: avcodec: add Ulead DV audio decoder
[23:34:45 CET] <cone-213> ffmpeg 03Paul B Mahol 07master:11bc4fd653fa: avcodec/dvaudiodec: only stereo makes sense
[23:47:11 CET] <durandal_1707> no more merges?
[23:48:35 CET] <Daemon404> not sure why nevcairiel hasnt
[23:48:42 CET] <Daemon404> i can pitch in again...
[23:49:50 CET] <wm4> you could switch to cherry-picks
[23:50:04 CET] <wm4> not sure if easier?
[23:51:00 CET] <Daemon404> i personally would not
[23:51:21 CET] <J_Darnley> I think people want merges so that you can find the commit hash in ffmpeg
[00:00:00 CET] --- Wed Jan 27 2016