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

[burek]

[01:14:38 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:3e3e095fc903: avformat/options_table: Set the default maximum number of streams to 1000
[01:14:39 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:9519b2560e18: avformat/utils: Print verbose error message if stream count exceeds max_streams
[01:14:40 CET] <cone-947> ffmpeg 03Chris Cunningham 07release/3.2:533431d5af92: avformat/mp3dec: fix msan warning when verifying mpa header
[01:14:41 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:7643e8584f3a: avutil/random_seed: Improve get_generic_seed() with higher precission clock()
[01:14:42 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:07df85b9586f: swscale/swscale: Fix dereference of stride array before null check
[01:14:43 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:ceeeccc86211: avutil/random_seed: Reduce the time needed on systems with very low precission clock()
[01:14:44 CET] <cone-947> ffmpeg 03Matt Wolenetz 07release/3.2:2481f1320a7f: lavf/utils.c Protect against accessing entries[nb_entries]
[01:14:45 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:cd81993070e8: avcodec/mjpegdec: Check for rgb before flipping
[01:14:46 CET] <cone-947> ffmpeg 03Tobias Rapp 07release/3.2:d5154c055bab: avformat/avidec: skip odml master index chunks in avi_sync
[01:14:47 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:7d222736c27e: avcodec/omx: Do not pass negative value into av_malloc()
[01:14:48 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:3442c20c4d38: avcodec/bsf: Fix av_bsf_list_free()
[01:14:49 CET] <cone-947> ffmpeg 03Andreas Cadhalpun 07release/3.2:41fc098a8612: libopenmpt: add missing avio_read return value check
[01:14:50 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:bd6c1d5149fb: avcodec/pngdec: Fix off by 1 size in decode_zbuf()
[01:14:51 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:14f555683a98: avcodec/mjpegdec: Check remaining bitstream in ljpeg_decode_yuv_scan()
[01:14:52 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:dd36b3a06a0a: avcodec/vp56: Check for the bitstream end, pass error codes on
[01:14:53 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:dc2d3856f300: avcodec/utils: correct align value for interplay
[01:14:54 CET] <cone-947> ffmpeg 03Frank Liberato 07release/3.2:cc662476031b: avformat/flacdec: Check avio_read result when reading flac block header.
[02:43:10 CET] <Zeranoe> A little off topic, but what editors/IDEs are the devs using for FFmpeg?
[02:43:54 CET] <atomnuker> gedit
[02:59:46 CET] <cone-947> ffmpeg 03Andreas Cadhalpun 07release/3.2:884cd3caa5cc: swscale: save ebx register when it is not available
[03:42:53 CET] <BBB> Zeranoe: XCode
[04:14:17 CET] <Zeranoe> Why isn't there a hwcontext file for OpenCL?
[04:14:56 CET] <Zeranoe> (I'm more asking if there's a reason that there shouldn't be)
[09:41:33 CET] <jkqxz> Zeranoe:  There should be.  Making it standalone isn't particularly useful, though, because all you can do is upload/process/download.  It's only once you have mapping between hardware formats that it becomes of significant value.  <https://lists.libav.org/pipermail/libav-devel/2016-November/080223.html>
[09:42:11 CET] <wm4> you mean mapping to cuda surfaces and such?
[09:42:22 CET] <wm4> oh wait cuda was nvidia's opencl, so maybe not
[09:42:35 CET] <wm4> but maybe vaapi surfaces or d3d11 textures
[09:42:37 CET] <jkqxz> VAAPI / QSV is the target there.
[09:43:15 CET] <jkqxz> D3D whatever will also work.
[09:43:37 CET] <wm4> what's the use case? filters?
[09:45:01 CET] <jkqxz> Yeah.  Run filters on your frames on the GPU without them ever coming to CPU memory.
[10:03:45 CET] <wm4> jkqxz: currently I'm thinking of doing d3d11va -> d3d11 video proc (scaling/deint) -> qsv encoding, what do you think of that?
[10:27:28 CET] <hyponic> Hello.. I am having an issue that requires libzvbi / ffmpeg to be modified. I am willing to pay someone to modify libzvbi / ffmpeg to do what i need. If you have the skill to do so or know who does please let me know.
[10:36:44 CET] <kierank> what do you need?
[10:36:49 CET] <hyponic> what i am trying to achieve is convert teletext subtitles to dvbsubtitles.
[10:37:31 CET] <hyponic> kierank https://trac.ffmpeg.org/ticket/5913
[11:08:32 CET] <jkqxz> wm4:  I think it's a thing?  I certainly agree with the sentiment of using the platform decoder (VAAPI/DXVA) instead of QSV and only mapping to QSV for encode.
[11:10:13 CET] <wm4> if by "thing" you mean mapping d3d11 to qsv, yes that seems to exist, haven't tried it yet though
[11:13:10 CET] <jkqxz> That bit should be easy; you just make the QSV structure with references to the underlying platform surface.  I have hwmap support for VAAPI <-> QSV in libav, but it needs better (not entirely hacked) device setup to be useful in filtering.
[12:36:25 CET] <Polochon_street> hi wm4, I'm the one working on the duplicate id3 tags, quick question, how do you check after a read_header that the demuxer has (or hasn't) set any tag?
[12:39:30 CET] <wm4> Polochon_street: if the demuxer did, it would add something to ->metadata, right?
[12:39:39 CET] <Polochon_street> that's what I was doing, perfect!
[12:39:53 CET] <Polochon_street> I thought there was something more than just checking s->metadata
[12:40:09 CET] <Polochon_street> thanks!
[12:40:33 CET] <wm4> so basically I'm saying it should do what you did, but in utils.c for all demuxers
[12:40:44 CET] <wm4> not sure if the id3 reading code can be changed to that
[12:40:47 CET] <wm4> +do
[12:55:11 CET] <Polochon_street> wm4: alright thanks for your help, I've submitted the new version :)
[13:13:05 CET] <wm4> libswscale/bayer_template.c:197:1: internal compiler error: in have_bool_attr, at recog.c:2044
[13:13:06 CET] <wm4> wat
[13:14:24 CET] <wm4> this is with mingw... very annoying
[13:15:37 CET] <wm4> and now the machine froze... so much for this
[13:27:06 CET] <Polochon_street> wm4: is « Discarding ID3 tags because more suitable tags were found. » message for the id3 tags issue fine by you?
[13:28:26 CET] <wm4> Polochon_street: yeah, sounds good (maybe "ID3 tag" instead of plural?)
[13:29:48 CET] <Polochon_street> okay, done :)
[13:57:07 CET] <Polochon_street> wm4: I'll make a last patch, but I didn't get which line is redundant in the duplicate ID3 patch?
[14:00:45 CET] <wm4> Polochon_street: hm actually it's not redundant
[14:01:11 CET] <wm4> I was thinking av_dict_free(&id3_meta); is always called in the end, but it actually is done only in the failure case
[14:01:15 CET] <wm4> so my comment was wrong
[14:02:15 CET] <Polochon_street> okay, but don't you think the av_dict_free(&id3_meta) should be called after the if ... else?
[14:03:16 CET] <wm4> yeah it still needs to be freed in the case when both tags are present and the id3 one is rejected
[14:03:37 CET] <wm4> sure is tricky
[14:04:04 CET] <wm4> Polochon_street: also you can just do "s->metadata = id3_meta; id3_meta = NULL;" in the case when only the id3 tag exists
[14:04:37 CET] <Polochon_street> so in both if and else, or right after? Even if the id3 tag doesn't exist, it is safe to free it right?
[14:05:01 CET] <wm4> yes, it's safe to free if it's NULL
[14:06:37 CET] <Polochon_street> wm4: something like http://sprunge.us/AiOd would do?
[14:11:22 CET] <wm4> Polochon_street: unfortunately the "return AVERROR_INVALIDDATA;" can still leak it
[14:11:42 CET] <wm4> maybe move av_dict_free(&id3_meta); into the else branch, before the return happens
[14:12:55 CET] <Polochon_street> it looks like this now http://sprunge.us/aTfj
[14:13:21 CET] <wm4> looks good
[14:16:59 CET] <Polochon_street> alright I'll send it to the ML after lunch, thanks :)
[15:26:19 CET] <durandal_1707> atomnuker: is it possible to code arbitary fir filter which would use user supplied coefficients, just using ffmpeg code?
[15:39:15 CET] <atomnuker> durandal_1707: check out psy_hp_filter() in libavcodec/aacpsy.c
[15:39:30 CET] <atomnuker> PSY_LAME_FIR_LEN is the order, psy_fir_coeffs[] are the coefficients
[15:39:59 CET] <atomnuker> I think if you change those to what you need and remove the  32768.0f normalization at the end it should work
[15:42:06 CET] <atomnuker> or just code it yourself, the first formula from the wikipedia page looks simple
[15:43:21 CET] <atomnuker> (at least its not a serial filter where the previous output modifies the current output, fuck those well)
[15:47:24 CET] <durandal_1707> atomnuker: i mean fir filter as used in sox
[15:47:57 CET] <durandal_1707> user supplies some  floats and thats it
[15:48:34 CET] <durandal_1707> our rdft works only with power of two
[15:50:48 CET] <atomnuker> I guess not, if the user supplies floats you count them, figure the order out and run the filter
[15:51:09 CET] <atomnuker> (who'd want that when you can apply arbitrary expressions in the frequency domain though)
[15:53:57 CET] <durandal_1707> atomnuker: people puts coefficients of size 128 into wav file as 16bit pcm
[15:54:12 CET] <durandal_1707> 128 samples
[15:55:59 CET] <atomnuker> damn, I guess you just convert them to float, you can probably see how sox does it if it can do it
[16:00:33 CET] <durandal_1707> i think i will limit it power of 2 sizes
[16:22:39 CET] <cone-165> ffmpeg 03Paul B Mahol 07master:ee8e00b70396: avfilter: add abitscope multimedia filter
[17:08:50 CET] <durandal_1707> ubitux: didnt you wanted to write such filter?
[17:09:34 CET] <ubitux> which one? abitscope?
[17:31:52 CET] <durandal_1707> ubitux: arbitrary FIR
[17:32:26 CET] <ubitux> ah yeah indeed
[17:33:16 CET] <ubitux> but i gave up with life since working on subtitles and libav merges, so i'm ok with not writing it myself ;)
[17:40:57 CET] <ubitux> 17:42:12 <@ubitux> http://hajo.me/blog/2014/12/28/how-surround-sound-for-headphones-works/
[17:40:59 CET] <ubitux> 17:42:18 <@ubitux> this one might be interesting
[17:41:01 CET] <ubitux> 17:43:00 <@ubitux> also a generic FIR filter can be written relatively easily
[17:41:05 CET] <ubitux> this is indeed what triggered be at that time
[17:41:18 CET] <ubitux> (Feb 15 2015)
[17:41:58 CET] <ubitux> i guess i wanted an arbitrary fir filter system to experiment stuff
[17:54:49 CET] <durandal_1707> what about libav bitstream reader?
[17:55:17 CET] <durandal_1707> it have some good and bad points
[17:59:48 CET] <ubitux> we have a few thousands commits to merge before reaching the bitstream reader
[17:59:56 CET] <ubitux> so you have time
[18:07:34 CET] <atomnuker> the benchmark linked here had some unacceptably big regressions on 32 bits and only huffyuv had gains in some cases
[18:10:59 CET] <durandal_1707> atomnuker: isnt it other way around?, smaller - better
[18:12:03 CET] <iive> no
[18:12:11 CET] <atomnuker> performance gains go the other way around
[18:12:47 CET] <iive> we had bitstream reader that worked on same concepts, storing 64 bits in a tmp buffer, but it was slower, back in the time before 64 bit.
[18:12:51 CET] <ubitux> the 32-bit tests are on x86 or arm btw?
[18:13:36 CET] <iive> think of it like this. each memory access is one operation.
[18:13:51 CET] <iive> you read the buffer and you shift it. that's 2 operations.
[18:14:54 CET] <iive> on 32 bit, with 64 bit buffer, you have 2 ops for reading and 2 ops for shifting. making 4 operations.
[18:19:33 CET] <iive> if you use 32 bit buffer on 32 bit,  then you have 2 ops, however reading directly from the bitstream buffer also takes 1 or 2 ops.
[18:21:59 CET] <atomnuker> you still have to AND the buffer with (1 << bits) - 1
[18:22:34 CET] <iive> the buffer helps also with the overflow checks. you can skip checks for the end of the bitstream, Once again, it gives better results with bigger cache.
[18:25:42 CET] <iive> s/the buffer/ the cache
[18:25:44 CET] <iive> sorry
[18:35:28 CET] <iive> atomnuker: memory operations could be the slowest ones, if we have cache miss (video trashes a lot of data). Second comes conditions&branches. Logical operations are among the fastest especially if you don't have data dependency.
[18:48:05 CET] <iive> (just to be clear, by shifting above i mean writing the shifted values back to the cache buffer)
[19:23:01 CET] <wm4> isn't it only a few hundred commits
[19:23:04 CET] <wm4> not a few thousands
[19:57:44 CET] <ubitux> wm4: sorry yes, thousands obviously
[19:57:53 CET] <ubitux> hundreds*
[19:57:56 CET] <ubitux> damn it
[20:16:23 CET] <BBB> haha
[20:19:44 CET] <cone-619> ffmpeg 03Joel Cunningham 07master:f3778108d3eb: tcp: set socket buffer sizes before listen/connect/accept
[21:33:19 CET] <jamrial> 3.3 changelog looks a bit short. we should pad it :p
[21:36:47 CET] <wm4> the delayed merges show
[21:42:44 CET] <jamrial> i guess. but it's mostly that durandal_1707 wrote a billion filters for the last couple releases
[21:42:57 CET] <jamrial> so those got a lot of entries
[22:22:41 CET] <ubitux> billion, thousands or hundreds?
[22:56:59 CET] <llogan> anyone want to write RELEASE_NOTES?
[22:59:34 CET] <atomnuker> can audio encoders get fed NULL frames in between encoding (before they get NULL at the end to flush)?
[23:06:33 CET] <wm4> hmmm I would guess no, but wasn't there something weird about 0 sized packets that transport sid data for changing something
[23:06:39 CET] <wm4> *side
[23:30:59 CET] <cone-619> ffmpeg 03James Almer 07master:1ae39429e4c4: avformat/matroskadec: ProjectionPrivate is optional on Equirectangular projections
[23:46:39 CET] <philipl> BtbN: should mention dynlink cuda in changelog.
[23:46:58 CET] <BtbN> hm
[23:47:22 CET] <BtbN> yeah, maybe
[00:00:00 CET] --- Fri Jan 27 2017