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

[burek]

[00:09:16 CEST] <jamrial> jkqxz: i think we had that before libav, then you cherry picked a commit that put it on par with libav's once it made it to their tree
[00:12:19 CEST] <jamrial> jkqxz: see commit d1acab82930
[00:13:02 CEST] <jamrial> you're right, though, commited last february, so should be 3.3
[00:13:12 CEST] <jkqxz> It still wasn't in earlier versions.
[00:13:13 CEST] <jamrial> at least the vp8 one
[00:13:26 CEST] <jkqxz> Yeah.
[00:13:26 CEST] <jkqxz> MPEG-2 was at the same time.
[00:13:44 CEST] <jamrial> ok, then that patch should be ok
[00:14:07 CEST] <jamrial> that's the problem of committing old patches that had changelog entries pre written i guess :p
[00:15:41 CEST] <jkqxz> Yeah, MPEG-2 was originally written almost a year ago but I only got around to actually getting it in in January.
[00:15:53 CEST] <atomnuker> jkqxz: are we going to be able to merge the vp8 hwaccel stuff before we release 3.3?
[00:16:08 CEST] <jamrial> atomnuker: 3.3 was already branched out, so no
[00:16:38 CEST] <jamrial> you can backport fixes but not new features
[00:19:31 CEST] <cone-166> ffmpeg 03Mark Thompson 07master:3cbf717425b6: Changelog: fix position of VAAPI MPEG-2/VP8 encode entry
[00:21:16 CEST] <cone-166> ffmpeg 03Mark Thompson 07release/3.3:3c9e1b89a108: Changelog: fix position of VAAPI MPEG-2/VP8 encode entry
[00:23:27 CEST] <jkqxz> atomnuker:  I haven't looked at it again.  I lost interest when people wanted to add stupid hacks to the VP8 decoder to get around existing stupid hacks in the WebP decoder.
[00:29:01 CEST] <atomnuker> jkqxz: do you know if it faster than the software decoder (and around which resolution does it get faster?)
[00:37:16 CEST] <jkqxz> It's the same speed as all the other quick sync type decoders, so it does around 1080p800 on any normal Intel (though less on half-memory-bandwidth setups, which are common on mobile).
[00:39:31 CEST] <kierank> jkqxz: did intel ever expose the promised motion vector assistance api?
[00:39:33 CEST] <jkqxz> It's hard to compare usefully because the frames are on the GPU side.  If you want to use them there then it's faster immediately, if you don't then you have to download them which is also nontrivial.
[00:41:06 CEST] <jkqxz> Standalone motion estimation is exposed in the OpenCL drivers (both Beignet and the proprietary blob).  Is that what you mean?
[00:41:41 CEST] <kierank> yeah
[00:42:27 CEST] <jkqxz> The docs and open-source drivers are also there to write your own directly on the graphics cores, if you want.  (Though they've replaced the core of the VAAPI driver with binary blobs, so that may get harder again in future.)
[00:42:50 CEST] <kierank> interesting
[00:46:26 CEST] <cone-166> ffmpeg 03Jun Zhao 07master:08087f546267: lavc/vaapi_encode: fix p_per_i calculate issue.
[01:04:17 CEST] <wm4> jkqxz: they replaced what with binary blobs?
[03:03:27 CEST] <cone-166> ffmpeg 03Martin Vignali 07master:8163314967ae: libavcodec/exr : fix scanline offset table recreation on big endian
[03:03:28 CEST] <cone-166> ffmpeg 03Martin Vignali 07master:4db2bfa63c4e: fate : add test for exr with offset table set to 0
[09:55:16 CEST] <superware> I'm trying to save a frame as jpeg by following https://gist.github.com/RLovelett/67856c5bfdf5739944ed so I'm calling jpeg_codec = avcodec_find_encoder(AV_CODEC_ID_JPEG2000); jpeg_context = avcodec_alloc_context3(jpeg_codec); jpeg_context->pix_fmt = ctx->pix_fmt; jpeg_context->width = frame->width; jpeg_context->height = frame->height; but avcodec_open2(jpeg_context, jpeg_codec, NULL) fails and returns -22, any ideas?
[10:03:34 CEST] <superware> anyone?
[10:04:46 CEST] <nevcairiel> read the log output of why it errors, also you want #ffmpeg
[10:41:29 CEST] <ubitux> so, should i merge the bitstream api header? (and skip decoders update)
[10:41:41 CEST] <ubitux> so if they add a decoder at least it will work without effort
[10:45:48 CEST] <nevcairiel> its probably fine, a new header thats unused for now doesnt hurt anyone - although i'm sure someone might still complain
[10:46:48 CEST] <superware> nevcairiel: thanks
[11:01:43 CEST] <atomnuker> ubitux: couldn't we postpone that until such a decoder appears?
[11:04:14 CEST] <ubitux> atomnuker: maybe, but it's just an unused ~400 lines header
[11:09:19 CEST] <ubitux> atomnuker: any news on the jpeg thing btw?
[11:10:54 CEST] <mateo`> Hello, would a wrapper around Android surface be interesting for the project (as part of lavc/mediacodec.{c,h}). It would ease the use of Android surfaces regarding uploading their content to a GL_TEXTURE_2D after a frame has been decoded. The user would not have to do its own wrapper and simply use the one provided by FFmpeg if it feets its need. The API would still require the user to provide an
[11:10:56 CEST] <mateo`> instance of an implementation of the OnFrameAvailableListener listener (from the java world; we have no way to create an implementation of an interface using the jni api) which will need to notify a pthread mutex cond in order to work the API I propose.
[11:11:09 CEST] <mateo`> here is the code I use at work: https://github.com/Stupeflix/FFmpeg/commit/981cd75c6b89314a0578bcd441e0abb799307465#diff-3f0401b80b1ba7e643c08e9bcbf61a7dR88
[11:11:26 CEST] <mateo`> indeed, it needs a proper documentation
[11:12:41 CEST] <wm4> mateo`: maybe a small companion lib?
[11:13:10 CEST] <ubitux> libavcompanion
[11:13:41 CEST] <ubitux> libavcompanion - to never be alone in the multimedia world
[11:13:42 CEST] <mateo`> wm4: outside the FFmpeg project then ?
[11:14:15 CEST] <wm4> hm not sure
[11:14:36 CEST] <wm4> jkqxz: could we somehow coerce this into frame mapping?
[11:16:28 CEST] <wm4> anyway, mediacodec sure is terrifyingly bad...
[11:16:45 CEST] <mateo`> I haven't looked at the frame mapping code, does it behave well with GL ? Ie: you need a valid GL context when you attach the texture to the SurfaceTexture
[11:17:04 CEST] <wm4> there's nothing with GL and frame mapping yet
[11:17:29 CEST] <wm4> but I think either frame mapping or something closely related is supposed to be our API to "convert" surface types
[11:20:41 CEST] <mateo`> Just a thought. I wonder if we'll have some GL support in libavfilter support at some point, like gst.
[11:21:35 CEST] <mateo`> anyway the worst part of MediaCodec IMHO, is that the C API does not provide a way to use the surface from the java world ...
[11:24:12 CEST] <wbs> mateo`: do you mean like ANativeWindow_fromSurface, or something completely different? (the last sentence can be understood in many different ways)
[11:28:11 CEST] <mateo`> mmm, I guess I was just wrong, I did not remember that this function existed :(
[11:31:51 CEST] <mateo`> wbs: well, thanks :)
[11:32:30 CEST] <mateo`> wbs: any thoughts about the surface wrapper mentioned above ?
[11:32:31 CEST] <jkqxz> The frame mapping stuff should be able to do that - certainly this was exactly the sort of thing it was intended for.
[11:33:10 CEST] <jkqxz> Though obviously you need hwcontext implementations for both ends, because neither yet exist.  No idea about mediacodec, but GL should fit in sensibly (modulo fun with global state).
[11:34:45 CEST] <wbs> mateo`: dunno, anything that needs the java side implementation ends up pretty messy
[12:48:38 CEST] <superware> I'm trying to save a frame as a jpeg 2000 file, such in https://gist.github.com/RLovelett/67856c5bfdf5739944ed#gistcomment-1916026, but it seems that after encoding the packet data buffer doesn't contain a valid jpeg 2000 file (although the header seems valid), any ideas?, any ideas?
[12:52:40 CEST] <BtbN> I'd guess you need to use a proper muxer, instead of writing the raw packet to a file.
[12:53:37 CEST] <superware> thanks, can you please point me to the right direction?
[14:01:05 CEST] <nevcairiel> rcombs: didnt you talk about streaming to roku at some point here? what kind of streaming format do you use with roku? It seems to lack support for any actually decently streamable format
[14:01:25 CEST] <rcombs> matroska
[14:01:34 CEST] <nevcairiel> that works eh
[14:01:41 CEST] <rcombs> yup
[15:06:54 CEST] <ubitux> meh, our hevc decoder is so slow :(
[15:07:46 CEST] <nevcairiel> should've gotten much better recently
[15:07:56 CEST] <ubitux> it did yes
[15:08:00 CEST] <ubitux> but it's still very slow
[15:08:16 CEST] <nevcairiel> the room for improvement has shrunken quite a bit now that we have idct
[15:08:18 CEST] <BtbN> The downside of having a needlessly fast CPU: You don't notice poorly optimized code anymore
[15:08:27 CEST] <mateo`> yeah release 3.2.4 gives 43fps, head gives 60fps (on a 4k/60fps yuv420 stream)
[15:08:35 CEST] <ubitux> on a i7-6770HQ ^
[15:08:50 CEST] <nevcairiel> BtbN: trying to play any decently high bitrate hevc stream will make you notice, no matter your cpu =p
[15:08:52 CEST] <ubitux>   23.51%  ffmpeg_g  ffmpeg_g            [.] ff_hevc_hls_residual_coding
[15:08:54 CEST] <ubitux>    6.74%  ffmpeg_g  ffmpeg_g            [.] ff_hevc_deblocking_boundary_strengths
[15:08:56 CEST] <ubitux>    6.24%  ffmpeg_g  ffmpeg_g            [.] deblocking_filter_CTB
[15:09:40 CEST] <nevcairiel> ff_hevc_hls_residual_coding is cabac
[15:09:47 CEST] <nevcairiel> if you can optimize that, you'll get a price
[15:10:26 CEST] <nevcairiel> (but it also contains the idct, your breakdown seems very high level)
[15:10:44 CEST] <ubitux> the idct are actually relatively low
[15:10:56 CEST] <nevcairiel> so its really that function and not htings it calls?
[15:11:05 CEST] <ubitux> http://sprunge.us/DddG
[15:11:36 CEST] <nevcairiel> that function is pretty long and complex
[15:11:40 CEST] <nevcairiel> who knows what evils hide there
[15:27:39 CEST] <cone-660> ffmpeg 03Ronald S. Bultje 07master:e72690b18da0: h264: don't sync pic_id between threads.
[15:28:13 CEST] <BBB> durandal_1707: is it ok to push the codec_desc[] patch for adding the intraonly flag to audio codecs with adjusted comments in avcodec.h?
[15:29:05 CEST] <BBB> wm4: for atomic init in ffmpeg.c, can I keep the initializer? I personally find it easier to understand if a variable is explicitly initialized to some value, even if its not strictly required in practice
[15:29:12 CEST] <durandal_1707> yes, but that might give idea to libav folks
[15:29:37 CEST] <ubitux> BBB: the explicit atomic init is fine
[15:29:48 CEST] <ubitux> especially as a oneliner
[15:29:54 CEST] <BBB> durandal_1707: what do you mean?
[15:30:44 CEST] <wm4> BBB: sure
[15:30:47 CEST] <BBB> Im committing and testing a few more as well, you might be able to re-run tsan in a bit and get a much cleaner picture
[15:31:01 CEST] <BBB> (picture meaning lack-of-noise-in-tsan-report)
[15:32:17 CEST] <durandal_1707> BBB: they might invent own stuff
[15:32:27 CEST] <BBB> but thats ok right?
[15:32:41 CEST] <BBB> I mean, we cant prevent it
[15:32:59 CEST] <ubitux> so how many patches are you pushing?
[15:33:10 CEST] <ubitux> BBB: just push the thing, it doesn't matter :)
[15:33:21 CEST] <ubitux> you're nitpicking yourself :P
[15:33:30 CEST] <BBB> I am trying to make sure people are happy
[15:33:41 CEST] <BBB> michaelni asked for adding tsan warnings in patch, so Im doing that
[15:33:46 CEST] <BBB> I agree with him thats valuable
[15:33:56 CEST] <ubitux> yes that's cool
[15:37:01 CEST] <cone-660> ffmpeg 03Ronald S. Bultje 07master:467a0538100b: codec_desc: mark some lossless audio codecs as intraonly.
[15:38:33 CEST] <cone-660> ffmpeg 03Ronald S. Bultje 07master:76d8c77430e9: ffmpeg: make transcode_init_done atomic.
[15:39:53 CEST] <ubitux> BBB: poke me when you want a re-run
[15:40:08 CEST] <BBB> ubitux: ok, tnx
[15:42:09 CEST] <jamrial> BBB: that intra only change should probably get a line in APIChanges and maybe a version bump
[15:42:23 CEST] <BBB> hm& ok
[15:49:25 CEST] <cone-660> ffmpeg 03Ronald S. Bultje 07master:1269cd5b6f54: pthread_frame: call update_context_from_user() after acquiring lock.
[15:51:37 CEST] <cone-660> ffmpeg 03Ronald S. Bultje 07master:1f50baa2b2da: hevc: only write to max_ra and pocTid0 in the first slice.
[16:05:50 CEST] <nevcairiel> ubitux: i did some performance graphing myself and about half of the time in  hls_residual_coding is spent in cabac decoding, but the other half its doing other things
[16:06:50 CEST] <nevcairiel> and yeah idct is minor now
[16:07:40 CEST] <nevcairiel> we need a hero to write cabac magic
[16:08:56 CEST] <durandal_1707> $$$$
[16:09:20 CEST] <nevcairiel> i should get intels performance analyzer again, it had breakdowns down to the lines of the code
[16:09:56 CEST] <nevcairiel> too bad its $899 =p
[16:11:22 CEST] <kierank> perf top can do that
[16:12:32 CEST] <kierank> afaik all these gui things can be done (with difficulty) using perf
[16:25:02 CEST] <BBB> 3 patches to go...
[16:27:56 CEST] <atomnuker> ubitux: I can't replicate the mjpeg thing, valgrind is empty and all the vsynth tests pass except vsynth_lena-ljpeg, but that issue seems to be older than the huffman changes
[16:31:13 CEST] <ubitux> did you valgrind the avi output creation or the 2nd command?
[16:31:37 CEST] <ubitux> fate-vsynth_lena-ljpeg runs 2 things
[16:31:44 CEST] <ubitux> only the first one is affected
[16:33:39 CEST] <atomnuker> the second thing
[16:33:52 CEST] <atomnuker> oh I see, it encodes it
[16:35:16 CEST] <atomnuker> but with 2d453188c23, the commit before the huffman things it still encodes nothing
[16:41:59 CEST] <ubitux> ?
[16:42:03 CEST] <ubitux> it does output something
[16:42:14 CEST] <ubitux> and does not raise any valgrind error
[16:42:43 CEST] <ubitux> (i just tried)
[16:47:49 CEST] <BBB> michaelni: is the png patch ok now? I believe it still addresses your original concern but it doesnt give any asan warnings on the sample you provided
[16:48:30 CEST] <BBB> and is anyone interested in reviewing pthread_frame: allow per-field ThreadFrame owners.? that one is probably tricky, so it needs some knowledge of frame-mt design+h264
[17:16:03 CEST] <BBB> kierank: did you setup a slice-threading helgrind/tsan station?
[17:17:06 CEST] <kierank> No, afl-fuzz
[17:18:06 CEST] <BBB> \o/
[17:19:04 CEST] <BBB> do we have an automated station that runs that?
[17:36:39 CEST] <ubitux> BBB: so no more patches for today?
[17:36:51 CEST] <BBB> Im hoping the png/pthread ones can go in
[17:37:03 CEST] <BBB> they would help a lot in reducing noise from tsan
[17:37:08 CEST] <BBB> one fixes fate-h264
[17:37:24 CEST] <BBB> the other fixes png (which most lavf-* and filter-* tests use as input)
[17:37:35 CEST] <ubitux> ok yeah, 2 important ones
[17:37:55 CEST] <BBB> but I understand if you dont want to wait, I mean, we can always wait for the next thing
[17:38:03 CEST] <BBB> so if youd prefer to get a current snapshot, feel free to
[17:38:15 CEST] <ubitux> i'm going afk for an hour or so, that's why i'm asking :)
[17:38:29 CEST] <ubitux> it's fine, it's going to loop over it relatively soon
[17:38:30 CEST] <BBB> ok lets do it
[17:52:46 CEST] <BBB> ubitux: if you update valgrind to current svn, the vp9-related issue (for vex jit) should be fixed
[18:17:26 CEST] <jamrial> BBB: he's using archlinux, so soon after valgrind tags a release with that revision it will make it to their package manager
[18:33:16 CEST] <BBB> jamrial: ok
[18:33:40 CEST] <BBB> so uh& review for png/frame-mt patches kindly requested if anyone wants to look at boring things :)
[18:33:56 CEST] <BBB> the frame-mt one is interesting because it cleans fate-h264
[18:38:26 CEST] <michaelni> BBB, cannot reproduce the png crash anymore
[18:38:37 CEST] <BBB> michaelni: its fixed in the latest patch
[18:38:43 CEST] <BBB> (thanks for sample)
[18:42:02 CEST] <cone-660> ffmpeg 03Ronald S. Bultje 07master:478f1c3d5e54: png: split header state and data state in two separate variables.
[18:51:46 CEST] <BBB> what is this in idctdsp.c?
[18:51:47 CEST] <BBB> void (*ff_put_pixels_clamped)(const int16_t *block, uint8_t *pixels, ptrdiff_t line_size);
[18:51:48 CEST] <BBB> void (*ff_add_pixels_clamped)(const int16_t *block, uint8_t *pixels, ptrdiff_t line_size);
[18:51:54 CEST] <BBB> and
[18:51:55 CEST] <BBB>     ff_put_pixels_clamped = c->put_pixels_clamped;
[18:51:56 CEST] <BBB>     ff_add_pixels_clamped = c->add_pixels_clamped;
[18:53:09 CEST] <BBB> (it makes tsan unhappy)
[18:54:27 CEST] <nevcairiel> ew global state
[18:55:21 CEST] <BBB> it looks like a diego thing?
[18:55:31 CEST] <BBB> (95c0cec0)
[18:55:33 CEST] <nevcairiel> one single codec uses that it seems
[18:55:55 CEST] <nevcairiel> wait that file is not a codec
[18:56:01 CEST] <nevcairiel> its soime third party code in avcodec o.o
[18:56:07 CEST] <BBB> I guess he moved it from arm to arch-agnostic code
[18:56:13 CEST] <nevcairiel> This file is part of the Independent JPEG Group's software.
[18:56:14 CEST] <nevcairiel> odd
[18:56:19 CEST] <jamrial> why is it like that instead of just making put_pixels_clamped_c and add_pixels_clamped_c use those prefixed names?
[18:56:32 CEST] <nevcairiel> someone wanted optimizations, i guess
[18:57:17 CEST] <nevcairiel> following the u sage chain, this stuff is only used for FF_IDCT_INT .. back in idctdsp
[18:57:24 CEST] <nevcairiel> should be possible to clean this up
[18:57:46 CEST] <nevcairiel> but it has annoying mips implementations =p
[19:00:01 CEST] <BBB> its been around long long before that
[19:00:09 CEST] <BBB> I dont think it originates from diego
[19:00:22 CEST] <BBB> although he moves code around to a point where I cant git annotate my way to the source anymore
[19:00:29 CEST] <nevcairiel> he took it from arm code and made it ever present everywhere
[19:00:31 CEST] <BBB> (git annotate -r e3fcb143^ libavcodec/arm/dsputil_init_arm.c fails for me)
[19:00:32 CEST] <nevcairiel> instead of cleaning it up
[19:00:46 CEST] <BBB> so & how do we fix this hack?
[19:01:04 CEST] <BBB> making the pointer atomic seems silly
[19:01:44 CEST] <BBB> I also have to admit this goes so far down the rabit hole that Im starting to -ENOCARE& :-/
[19:02:22 CEST] <nevcairiel> its annoying because these jref dcts are implemented using other dcts, but dont have a context in there
[19:03:07 CEST] <nevcairiel> (or rather other pixel operations from the dct context)
[19:29:32 CEST] <ubitux> BBB: i'll switch to the svn version of valgrind on my fate instance i guess
[19:29:38 CEST] <BBB> ty!
[19:29:47 CEST] <ubitux> BBB: btw, 3027/3372 ’ 3136/3375
[19:30:16 CEST] <BBB> nice
[19:30:40 CEST] <ubitux> (90% ’ 93%)
[19:30:50 CEST] <BBB> I just pushed the png fix
[19:30:53 CEST] <BBB> that should add another 1% or so
[19:31:00 CEST] <BBB> h264 will also add 2% or so
[19:31:15 CEST] <BBB> (thats the patch I sent 2-3 hrs ago or so)
[20:32:14 CEST] <ubitux> BBB: the png commit didn't seems to have help
[20:32:23 CEST] <BBB> hm...?
[20:32:28 CEST] <ubitux> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-tsan
[20:33:18 CEST] <BBB> let me test some more
[20:35:09 CEST] <BBB> ah, I need to compile liabvutil with -fsanitize=thread also for that to work
[20:35:45 CEST] <ubitux> alright, noop time for me
[20:37:19 CEST] <BBB> argh crap
[20:37:25 CEST] <BBB> I had that fixed in my first iteration of the patch
[20:37:39 CEST] <BBB> but then it got lost in the last version I re-sent after michaelni found a file that broke
[20:37:41 CEST] <BBB> crap crap crap
[20:37:43 CEST] <BBB> sorry
[20:38:43 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:dd3d7ddf2a50: lavc: add a new bitstream reader to replace get_bits
[20:38:44 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:d182d8a6d320: cllc: Convert to the new bitstream reader
[20:38:45 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:adb1ebb36cdf: eamad: Convert to the new bitstream reader
[20:38:46 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:7d957b3f477a: ea: Convert to the new bitstream reader
[20:38:47 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:b25180801bd0: on2avc: Convert to the new bitstream reader
[20:38:48 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:ed006ae4e253: 4xm: Convert to the new bitstream reader
[20:38:49 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:012c4511539f: adpcm: Convert to the new bitstream header
[20:38:50 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:41679be1a2d8: asvdec: Convert to the new bitstream reader
[20:38:51 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:027211920222: atrac: Convert to the new bitstream reader
[20:38:52 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:edd4c19a7811: atrac3plus: Convert to the new bitstream reader
[20:38:53 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:dae9b0b9c6db: avs: Convert to the new bitstream reader
[20:38:54 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:9a23b599431c: bink: Convert to the new bitstream reader
[20:38:55 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:0977a7c2f630: binkaudio: Convert to the new bitstream reader
[20:38:56 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:b4c0daa83c0c: cdxl: Convert to the new bitstream reader
[20:38:57 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:e561146611f5: cljrdec: Convert to the new bitstream reader
[20:38:58 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:942e84d2a3c4: cook: Convert to the new bitstream reader
[20:38:59 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:928f8c7ce360: dss_sp: Convert to the new bitstream reader
[20:39:00 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:d8618570beb5: dvdsubdec: Convert to the new bitstream reader
[20:39:01 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:c43eb731721a: escape124: Convert to the new bitstream reader
[20:39:02 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:2906d8dcb397: escape130: Convert to the new bitstream reader
[20:39:03 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:8df1ac6b785a: exr: Convert to the new bitstream reader
[20:39:04 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:418ccdd7034e: faxcompr: Convert to the new bitstream reader
[20:39:05 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:692ba4fe6445: flashsv: Convert to the new bitstream reader
[20:39:06 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:b37b681f7734: fraps: Convert to the new bitstream reader
[20:39:07 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:799703c3ea3d: g2meet: Convert to the new bitstream reader
[20:39:08 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:2188d5390601: g72x: Convert to the new bitstream reader
[20:39:09 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:b2c56301f945: gsm: Convert to the new bitstream reader
[20:39:10 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:c5e01d91702b: hq_hqa: Convert to the new bitstream reader
[20:39:11 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:1df549bfa2ba: hqx: Convert to the new bitstream header
[20:39:12 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:15d4dbfd4ade: jvdec: Convert to the new bitstream reader
[20:39:13 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:6f94a64bd6ae: nellymoser: Convert to the new bitstream reader
[20:39:14 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:b3441350fade: opus: Convert to the new bitstream reader
[20:39:15 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:770406d1e829: pcx: Convert to the new bitstream reader
[20:39:16 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:0dabd329e84a: qcelp: Convert to the new bitstream reader
[20:39:17 CEST] <cone-660> ffmpeg 03Alexandra Hájková 07master:0b5a26e8bcd2: qdm2: Convert to the new bitstream reader
[20:39:18 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:ee161dac9dcc: Merge commit '0b5a26e8bcd219efe5da3a6d39b588fabf91f2b9'
[20:39:19 CEST] <cone-660> ffmpeg 03Luca Barbato 07master:3c7fa8cbb93d: hlsenc: Fix the openssl support
[20:39:20 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:bc55e8f08bdd: Merge commit '3c7fa8cbb93dba96acb12aef6e00d929c1da1ae8'
[20:41:19 CEST] <cone-660> ffmpeg 03Janne Grunau 07master:e5b0fc170f85: arm: vp9itxfm: Simplify the stack alignment code
[20:41:19 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:ed59d39e76be: Merge commit 'e5b0fc170f85b00f7dd0ac514918fb5c95253d39'
[20:41:19 CEST] <cone-660> ffmpeg 03Martin Storsjö 07master:4d960a11855f: aarch64: vp9itxfm: Use w3 instead of x3 for the int eob parameter
[20:41:19 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:ab827a8349f5: Merge commit '4d960a11855f4212eb3a4e470ce890db7f01df29'
[20:42:46 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:a1d9de304fe6: Fix some mismatches between function parameter and doxygen parameter names.
[20:42:47 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:47d8410daca4: Merge commit 'a1d9de304fe63614e3aa8117fef17491fa80093d'
[20:44:00 CEST] <BBB> ubitux: new patch on ML to fix that
[20:44:11 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:81a3c42abe17: Drop some bogus Doxygen documentation.
[20:44:12 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:98c66e2fe46d: Merge commit '81a3c42abe17e757fe890607f67201a240648993'
[20:45:43 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:97cd7a3dc005: rtpdec_mpeg4: const correctness for parse_fmtp_config()
[20:45:44 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:de9c93bf5393: Merge commit '97cd7a3dc005a0ad1656dbb2af92e9c5d0731f21'
[20:46:50 CEST] <cone-660> ffmpeg 03Ronald S. Bultje 07master:eff2861a757b: png: set AVFrame flags/fields before calling setup_finished().
[20:47:15 CEST] <BBB> ubitux: oops sorry I may be clobbering your tree :(
[20:47:25 CEST] <iive> ubitux: is '0b5a26e8bcd2 skipped or merged?
[20:47:55 CEST] <ubitux> BBB: it's ok :)
[20:48:09 CEST] <ubitux> iive: look at the merge commit
[20:48:38 CEST] <iive> ubitux: the log says it is merged, and it is qdm2 to new bitstream reader
[20:49:15 CEST] <ubitux> "This merge is a noop, see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html"
[20:50:18 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:bdbb8c68668b: doc: Add libxavs section
[20:50:19 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:3d34d5c1cf64: Merge commit 'bdbb8c68668b7610f5a310f5bbb246d2b950426d'
[20:50:58 CEST] <ubitux> huh
[20:51:01 CEST] <ubitux> 5eef983297b5e2eaa785f1e832622480eaa84103
[20:51:15 CEST] <ubitux> since when do we have unused function parameter warnings?
[20:52:21 CEST] <ubitux> the hell is this serie of commits again
[20:53:39 CEST] <ubitux> these 3 commits are really silly, i'll noop them unless someone objects
[20:54:13 CEST] <jamrial> don't we have av_unused for this?
[20:54:21 CEST] <BBB> I think he means function args
[20:54:34 CEST] <ubitux> https://lists.libav.org/pipermail/libav-devel/2016-November/080698.html
[20:54:39 CEST] <ubitux> seems i'm not the only one to think that
[20:54:40 CEST] <BBB> like void func(int a, int b) { if (a) do_something(); } <- b is unused
[20:55:28 CEST] <BBB> ubitux: if you think noop is easier, go for it
[20:55:33 CEST] <BBB> I have no objection
[20:55:36 CEST] <BBB> I agree with antons concern
[20:55:56 CEST] <ubitux> it's not simpler but i don't like that change
[20:56:37 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:5eef983297b5: ape: Restructure DEBUG ifdefs to avoid unused function parameter warnings
[20:56:38 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:367f95af555d: ac3enc: Restructure DEBUG ifdefs to avoid unused function parameter warnings
[20:56:39 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:6427379f23eb: als: Restructure DEBUG ifdefs to avoid unused function parameter warnings
[20:56:40 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:5403069ae149: Merge commit '6427379f23eb4d2b82d8d274c616f68b65a2f723'
[20:58:25 CEST] <ubitux> +        printf("Error running pnmtopng\n");
[20:58:27 CEST] <ubitux> ...
[20:58:36 CEST] <ubitux> at least fprintf(stderr, ...) damnit
[21:01:59 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:b8cd7a3c8df2: dvbsub: Check for errors from system()
[21:02:00 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:9f7ba0ac9d2b: Merge commit 'b8cd7a3c8df2c3aac8d7a0b5a02d83caf61bd769'
[21:02:13 CEST] <BBB> michaelni: can I entice you to review pthread_frame: allow per-field ThreadFrame owners.?
[21:02:19 CEST] <BBB> jamrial: or you?
[21:03:51 CEST] <cone-660> ffmpeg 03Diego Biurrun 07master:b34c6cd57a2e: dvbsub: cosmetics: Group all debug code together
[21:03:52 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:7650bccdb1f6: Merge commit 'b34c6cd57a2e8aad5f773aea933f77883de320ec'
[21:05:10 CEST] <cone-660> ffmpeg 03Andreas Cadhalpun 07master:f92d7bdfddfa: libopusdec: default to stereo for invalid number of channels
[21:05:10 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:d1c2c210bfee: Merge commit 'f92d7bdfddfaac04b3bb31f2749d173ca1d8ba6d'
[21:07:18 CEST] <durandal_1707> have you seen latest channel layout api from libav devs?
[21:09:59 CEST] <cone-660> ffmpeg 03Anton Khirnov 07master:1dd2b6c91ca5: examples/qsvdec: switch to the hwcontext API
[21:10:00 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:4069394fd402: Merge commit '1dd2b6c91ca5f26207805720d4f5564de60b241b'
[21:10:15 CEST] <cone-660> ffmpeg 03Anton Khirnov 07master:44c9f374f188: examples/qsvdec: convert to the new decoding API
[21:10:16 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:54e195cf52b6: Merge commit '44c9f374f188f92927b7a4aad2101289d446b814'
[21:13:10 CEST] <atomnuker> ubitux: the valgrind warning only seems to occur when accessing s->out_format or s->huffman, this is odd
[21:14:08 CEST] <atomnuker> unless MpegEncContext is only partially allocated or is really some other struct
[21:14:32 CEST] <cone-660> ffmpeg 03Anton Khirnov 07master:f27e262dbdea: examples/encode_audio: switch to the new audio encoding API
[21:14:33 CEST] <cone-660> ffmpeg 03Clément BSsch 07master:a434657de9dc: Merge commit 'f27e262dbdea1991b22e08b639ac03e642a3482c'
[21:16:34 CEST] <ubitux> atomnuker: no idea... if you think it's a valgrind bug you can maybe isolate the issue somehow
[21:16:42 CEST] <ubitux> and make a test case for a bug report
[21:16:56 CEST] <ubitux> but i'd check closely first :p
[21:19:16 CEST] <ubitux> there is currently a fate instance running with a svn valgrind if you want to wait for it, just in case
[21:20:32 CEST] <atomnuker> there's no way its a valgrind bug, the thing has never betrayed me
[21:21:15 CEST] <atomnuker> it did crash once I think after it told me to fix my program but it did its job nevertheless
[21:22:20 CEST] <durandal_1707> hmm, no more cluster fuzz commits?
[21:30:03 CEST] <atomnuker> I see where the bug is now, priv_data is pointing to LJpegEncContext rather than MpegEncContext
[21:32:07 CEST] <ubitux> :)
[21:33:23 CEST] <atomnuker> its always been pointing there despite being used for other things, it just never got above the allocated size
[21:46:09 CEST] <kierank> BBB: i can setup a machine to do tsan + sliced threads if you want but I don't know if fate actually has sliced threads samples
[21:46:23 CEST] <BBB> for h264 theres a couple
[21:46:41 CEST] <BBB> vp9/hevc probably also (tiles)
[21:47:17 CEST] <kierank> does ffmpeg actually run in sliced threads mode during fate?
[21:48:37 CEST] <BBB> make THREAD_TYPE=slice THREADS=2 fate
[21:48:41 CEST] <BBB> IIRC
[21:48:59 CEST] <kierank> I will look at doing that tomorrow
[21:54:56 CEST] <ubitux> BBB: i added that one
[21:55:01 CEST] <ubitux> it will come up at next run
[21:55:04 CEST] <BBB> ty
[21:55:28 CEST] <kierank> ok
[21:55:29 CEST] <ubitux> i was waiting for the current one to go green but it took me second to add this one so...
[21:55:42 CEST] <ubitux> i'll increase the number of threads when it's green
[21:55:44 CEST] <ubitux> just in case
[21:57:24 CEST] <ubitux> it would be nice to have such instance on another arch though
[21:57:37 CEST] <ubitux> typically where atomics are handled differently
[21:57:44 CEST] <ubitux> or maybe with other compilers (i'm using gcc)
[22:04:59 CEST] <durandal_1707> ok to push smthing?
[22:11:31 CEST] <ubitux> durandal_1707: yes
[22:13:42 CEST] <atomnuker> ubitux: patches sent to the ML
[22:14:25 CEST] <atomnuker> fate passes with huffman enabled by default now
[22:16:54 CEST] <ubitux> i see no patches
[22:17:43 CEST] <atomnuker> should appear soon then
[22:28:57 CEST] <kierank> that ami_stuff guy is doing some kind of service to humanity
[22:32:59 CEST] <durandal_1707> yes, big one
[22:36:16 CEST] <cone-660> ffmpeg 03Paul B Mahol 07master:7e59393d40b7: avfilter/vf_pad: add aspect option
[22:58:25 CEST] <chatter29> hey guys
[22:58:31 CEST] <chatter29> allah is doing
[22:58:36 CEST] <chatter29> sun is not doing allah is doing
[22:58:38 CEST] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
[23:04:11 CEST] <ubitux> BBB: valgrind svn didn't seem to help
[23:04:16 CEST] <BBB> :(
[23:04:24 CEST] <BBB> the author said it was fixed
[23:04:27 CEST] <BBB> ohwell
[23:04:57 CEST] <ubitux> mmh
[23:05:08 CEST] <ubitux> maybe it actually used the system libraries for some reason
[23:05:27 CEST] <ubitux> well, i'll see that later
[23:10:41 CEST] <cone-660> ffmpeg 03James Almer 07master:c169ab4112c0: avcodec/Makefile: fix truehd encoder dependencies
[23:31:21 CEST] <BBB> clang/llvm devs are funny
[23:31:38 CEST] <BBB> I managed to get a true statement to trigger an assert (it used to crash the compiler) and apparently its still my fault
[23:49:34 CEST] <philipl> BBB: You're holding it wrong.
[23:49:49 CEST] <BBB> but they wont tell me how to hold it correctly
[23:51:28 CEST] <philipl> If you were holding it correctly, they wouldn't need to tell you how to do it.
[00:00:00 CEST] --- Tue Apr  4 2017