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

[burek]

[01:03:52 CET] <tmm1> i need to bump lavc minor
[01:04:00 CET] <tmm1> looks like i should increment it, set micro to 100
[01:04:25 CET] <tmm1> should that be a separate commit, or included with the feature change
[01:05:23 CET] <tmm1> ok past commits include the bump in the same commit
[01:05:24 CET] <atomnuker> include that in the commit
[01:06:33 CET] <tmm1> thanks. how about APIchanges
[01:06:49 CET] <tmm1> for http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226138.html, i just added an option but it changes the default behavior of the mediacodec decoders
[01:07:05 CET] <tmm1> most of the other api changes are for specific headers and public functions
[01:07:53 CET] <tmm1> i guess i can tie it to mediacodec.h because it affects hw context for the decoder only
[01:08:54 CET] <thealexbarney> BTW, atomnuker: https://github.com/Thealexbarney/VGAudio/blob/74cb2a9de2588fd9b9349c8f744539d9e7d2811b/src/VGAudio/Containers/At9/At9DataChunk.cs#L15-L17
[01:10:20 CET] <thealexbarney> Apparently an older version of Sony's encoder lies about the block size
[01:10:53 CET] <thealexbarney> Files aren't very common, but they're out there 
[01:13:33 CET] <thealexbarney> Glad I kept these. Out of 30-40 GB of ATRAC9 audio, there were only ~115 MB of files that had at least one frame using fine precision for the spectral coefficients. https://mega.nz/#!yYEXgCQY!dbzuQukXdeGk8BbraioJPhgO4G15Brhgy67EJiz7a7A
[01:15:06 CET] <atomnuker> thealexbarney: also some files can't be decoded correctly
[01:15:29 CET] <atomnuker> "Air (2016-09-08)(Key)(Prototype).7z"
[01:15:51 CET] <atomnuker> pretty much everything there has random corruptions every few seconds
[01:17:07 CET] <thealexbarney> This is the one with filenames like "psvpcm00_00000000.at9"?
[01:17:11 CET] <atomnuker> yeah
[01:18:45 CET] <thealexbarney> They seem to play fine with my library https://github.com/Thealexbarney/LibAtrac9
[01:18:54 CET] <thealexbarney> Do you have your source anywhere?
[01:23:31 CET] <cone-766> ffmpeg 03Aman Gupta 07master:2a0eb8685728: avcodec/mediacodecdec: add delay_flush option
[01:23:32 CET] <cone-766> ffmpeg 03Aman Gupta 07master:823a758543e2: avcodec/mediacodecdec: add more trace logging of input/output buffers
[01:24:15 CET] <atomnuker> thealexbarney: https://github.com/atomnuker/FFmpeg/blob/exp_atrac9/libavcodec/atrac9dec.c
[01:24:24 CET] <atomnuker> if I use your library then I still get corruption
[01:24:37 CET] <atomnuker> the C version anyway
[01:25:40 CET] <thealexbarney> You do? Which files, specifically?
[01:26:12 CET] <atomnuker> psvpcm00_00000006.at9
[01:27:05 CET] <thealexbarney> Here's a collection of files with encoding settings meant to hit every code path in my encoder as many times as possible for quick testing https://mega.nz/#!yM8WGRaa!NMmbsOgftciuA_ILlXMm3lkCoucCCZQpbEAK5mes4Mk
[01:27:07 CET] <atomnuker> my decoder is still quite dirty because I had to transplant a lot of code from your C library because I wasn't sure if I were screwing it up
[01:27:15 CET] <thealexbarney> At 48000 Hz, at least
[01:27:22 CET] <atomnuker> including band extension?
[01:27:25 CET] <thealexbarney> Yes
[01:28:26 CET] <thealexbarney> Here's a larger archive where I used more shotgun-y encoding settings https://mega.nz/#!yM8WGRaa!NMmbsOgftciuA_ILlXMm3lkCoucCCZQpbEAK5mes4Mk
[01:28:42 CET] <atomnuker> you sure those are all valid?
[01:28:51 CET] <atomnuker> one of them has version 2 signalled
[01:29:07 CET] <atomnuker> or do you include broken invalid files which you can decode anyway?
[01:30:13 CET] <thealexbarney> they're all valid
[01:30:28 CET] <thealexbarney> Version 2 means it uses band extension
[01:31:55 CET] <cone-766> ffmpeg 03Haihao Xiang 07master:00ae5c1d3d87: lavc/vaapi_encode: Don't return error if the underlying driver doesn't support B frames
[01:32:23 CET] <gagandeep> kierank: what are the 4 channels used in cineform?
[01:33:17 CET] <atomnuker> thealexbarney: what's 5_br120_nb18_ib10_g02_bex0_sf1_d0_wb0_slc0.at9?
[01:33:31 CET] <atomnuker> and 5_br096_nb18_ib06_g00_bex0_sf1_d1_wb1_slc0.at9
[01:33:50 CET] <atomnuker> wb? slc? sf1? d1?
[01:34:30 CET] <gagandeep> kierank: also what is a_width and a_hieght used in subband struct
[01:36:12 CET] <thealexbarney> atomnuker Bitrate 96kbps, 18 bands, intensity stereo starts at band 6, gradient mode 0, band extension off, superframe on, dual mono off, wide band on, slc off. I forget what slc does off the top of my head
[01:37:01 CET] <atomnuker> I hope its not "corrupts the output", because my decoder chokes on it
[01:37:51 CET] <thealexbarney> I didn't hear any issues with psvpcm00_00000006.at9 and my C decoder
[01:39:02 CET] <thealexbarney> Wide band is an "encoder-only" setting
[01:39:14 CET] <thealexbarney> No special decoder support needed
[01:39:15 CET] <atomnuker> is it one of those files with incorrect blockalign setting?
[01:39:17 CET] <kierank> gagandeep: allocated_width and height
[01:39:26 CET] <kierank> gagandeep: yuv and alpha
[01:39:28 CET] <kierank> or rgb and alpha
[01:39:43 CET] <kierank> gbr is just a convenience
[01:39:56 CET] <thealexbarney> atomnuker, No, these were all encoded with a recent version of Sony's encoder
[01:40:09 CET] <thealexbarney> Wait, misread that
[01:41:58 CET] <thealexbarney> No, the blockalign field is fine 
[01:47:21 CET] <gagandeep> kierank: thanks, i was not aware of alpha
[01:53:56 CET] <atomnuker> jkqxz: do you have any idea what would cause AVFilter->uninit to be called on every frame?
[01:54:21 CET] <atomnuker> this happened after I switched from manually allocating frame and buffer to ff_get_video_buffer
[01:57:32 CET] <jkqxz> Some frame property is changing and making it reinitialise.
[02:03:08 CET] <atomnuker> jkqxz: also seems like short files with under 10 frames will segfault if decoding with vaapi
[02:03:21 CET] <atomnuker> vp8 in particular
[02:05:18 CET] <atomnuker> https://0x0.st/smv4.webm
[02:05:25 CET] <atomnuker> ./ffmpeg_g -vaapi_device /dev/dri/renderD129 -hwaccel vaapi -hwaccel_output_format vaapi -i out.webm -f null -
[02:07:41 CET] <jkqxz> -threads 1
[02:09:03 CET] <jkqxz> VP8 hwaccel is not thread-safe.  There was a patch ages ago but elenril didn't like it and noone ever cared.
[02:11:14 CET] <atomnuker> got a link?
[02:13:29 CET] <jkqxz> <https://lists.libav.org/pipermail/libav-devel/2016-November/080413.html>
[02:16:12 CET] <atomnuker> seems alright to me
[02:16:50 CET] <jkqxz> That was before the other stuff was sorted out, and it does work a bit differently.
[03:28:04 CET] <wm4> "https: Unable to parse 'fm=0; Expires=Wed, 07 Mar 2018 22:35:36 UTC; Path=/; Domain=.twitter.com; Secure; HTTPOnly'"
[03:28:18 CET] <wm4> anyone familiar with cookies?
[03:28:42 CET] <wm4> I wouldn't expect that something like twitter actually sends broken cookies headers
[03:47:14 CET] <Compn> wm4 : for mpv playback of twitter video or regular web browser ?
[03:47:34 CET] <wm4> if you haven't noticed this is a ffmpeg channel
[03:47:42 CET] <wm4> so, with libavformat
[03:47:58 CET] <Compn> ah
[03:48:42 CET] <Compn> compare it to curl/wget cookie grabbing
[03:50:32 CET] <wm4> compare what
[04:20:35 CET] <wm4> it's because twitter sets cookies that expire a few seconds in the past
[04:21:06 CET] <wm4> parsing expired cookies returns an error, which then triggers a generic error message
[04:24:07 CET] <rcombs> so is there still no way for a codec to indicate that it doesn't have any output available yet, but will at some point, without needing to send more input
[04:24:15 CET] <wm4> (actually the origin is unclear)
[04:24:37 CET] <wm4> rcombs: it needs to block in that situation
[04:24:51 CET] <wm4> polling doesn't make sense, you'd just waste CPU this way or so
[04:24:54 CET] <rcombs> slooooooooooow
[04:25:01 CET] <wm4> slow?
[04:25:29 CET] <rcombs> trying to deal with e.g. android, which can buffer input and output (but only to some extent)
[04:25:53 CET] <wm4> we could add async notifications (then the API would be async), but I suppose your problem is that you don't get any notification at all
[04:26:17 CET] <rcombs> if you send input, then block on output, you'll waste time blocking when you could be sending more input
[04:26:36 CET] <rcombs> but it's also possible to fill up the input buffers, but also not have any output available yet
[04:27:11 CET] <wm4> wouldn't you just request more input if you don't have output in this situation then
[04:27:47 CET] <rcombs> well if the input buffer is full then you'd end up returning EAGAIN, but then not being able to send the additional input later
[04:28:26 CET] <wm4> what do you mean by the latter?
[04:29:11 CET] <rcombs> like, let's say you return EAGAIN from receive_[output] repeatedly, so the consumer keeps calling send_[input]
[04:29:23 CET] <cone-766> ffmpeg 03Yingming Fan 07master:80798e385780: checkasm/hevc_sao : add hevc_sao for checkasm
[04:29:35 CET] <rcombs> eventually the input buffer fills up and you have to return EAGAIN there
[04:30:26 CET] <rcombs> but if by that point the codec still isn't done with the first frame, the consumer would end up calling receive_[output] again and getting EAGAIN there as well
[04:30:44 CET] <rcombs> and there's no handling for the "EAGAIN from both send and receive" case
[04:31:06 CET] <rcombs> which I guess I'd like to be "do something else for a while", like (en|de)code other streams
[04:31:52 CET] <rcombs> how does the threading code handle this anyway
[04:32:51 CET] <rcombs> but yeah android doesn't distinguish "you need to send more input" from "you need to wait longer"
[04:56:46 CET] <wm4> yeah, "EAGAIN for both in and output" is invalid
[04:56:51 CET] <wm4> the API doesn't allow it
[04:57:03 CET] <wm4> and it would make no sense to allow it, because you'd have polling
[04:57:07 CET] <wm4> anyway
[04:57:27 CET] <wm4> so you say the decoder is like a bounded FIFO, so if you put in enough input, it can't consume more input
[04:57:37 CET] <wm4> but it doesn't mean it has to produce output either
[04:58:03 CET] <wm4> you only know when the actual decoder past that FIFO has consumed more packets from the FIFO
[04:58:37 CET] <wm4> so basically: send_packet -> FIFO (unknown, but possibly static size) -> some internal async media codec thing -> receive_frame
[04:59:06 CET] <wm4> and what you're hitting is that the FIFO gets full, while the internal async thing has done nothing yet
[05:00:53 CET] <rcombs> yeah
[05:02:15 CET] <rcombs> the android "receive output" and "get input buffer" functions have a timeout arg, which you can set to 0 (poll), -1 (block forever), or any positive integer (block for N amount of time)
[05:03:08 CET] <wm4> so you need to block until the decoder consumes at least some input, or outputs anything
[05:03:08 CET] <rcombs> and I _think_ if you set it to -1, it'll still return immediately if it needs more input
[05:03:16 CET] <wm4> eh
[05:03:40 CET] <tmm1> how is mediacodec such a disaster
[05:03:46 CET] <rcombs> but then you'd be blocking the consumer from getting anything else done while the async codec works
[05:03:55 CET] <wm4> well in the worst case you need another thread, so you can block on both input and output at the same time
[05:04:01 CET] <wm4> (if mediacodec allows that)
[05:04:09 CET] <rcombs> good question
[05:04:13 CET] <wm4> (if it doesn't, there's probably no way to use mediacodec correctly LOL)
[05:05:04 CET] <wm4> yeah... some of this complexity is because we're wrapping an async API as sync one, but most of it is just mediacodec really being a disaster
[05:15:13 CET] <rcombs> also I guess if you don't call ff_decode_get_packet every time, it just drops packets on the floor
[05:17:53 CET] <rcombs> looks like it _should_ be safe to call those at the same time?
[05:22:27 CET] <rcombs> oh yeah lol I forgot I had a dumb hack to determine which case I'm in
[05:22:51 CET] <rcombs> if output isn't immediately available, I attempt to get an input buffer, and I hold onto it
[05:23:10 CET] <rcombs> if I get one, I EAGAIN, and then next time around, I reuse that one
[05:23:15 CET] <rcombs> if not, I wait with a long timeout
[05:23:32 CET] <rcombs> (once you receive an input buffer, there's no way to give it back without sending data)
[05:45:36 CET] <gagandeep> kierank: now looking in the codec.h of cineform-sdk i see tags (enum) and you have used them in cfhd.c, after that there are something called flags in codec.h, how are those macros to be used
[05:46:20 CET] <gagandeep> also the tag INTERLACED_FLAGS = 63 has data = 0 in av_log
[07:00:55 CET] <tmm1> rcombs: have you seen mediacodecdec.c it basically does the same thing
[07:01:17 CET] <rcombs> haven't looked at it recently
[07:02:49 CET] <tmm1> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mediacodecdec.c#L394-L470
[08:49:17 CET] <ldts> peak3d please let me know what you decide to investigate in the end.  it seems Allwiner decoder falls in the same category than Rockchips. 
[11:11:28 CET] <cone-053> ffmpeg 03Paul B Mahol 07master:2f147588f7be: avfilter/vf_vaguedenoiser: fix plane copy for >8 bit depth formats
[11:32:39 CET] <rcombs> wm4: (might fall asleep before you reply but) remind me, did you have an issue with hls.c potentially updating AVFormatContext::duration and AVFormatContext::start_time mid-stream on live playlists
[11:34:16 CET] <cone-053> ffmpeg 03Calvin Walton 07master:e4edc567a077: libavfilter/vf_fps: Rewrite using activate callback
[11:34:17 CET] <cone-053> ffmpeg 03Calvin Walton 07master:2b2c8b22da9f: libavfilter/vf_fps: Minor cleanups
[11:47:22 CET] <wm4> rcombs: me? no, but I have no idea how it affects utils.c (also why you'd want that)
[11:56:57 CET] <cone-053> ffmpeg 03Carl Eugen Hoyos 07master:9fe61b61074b: lavfi/drawutils: Do not claim to support P016.
[14:10:10 CET] <nevcairiel> rcombs: i dont particularly care about duration, but changing start_time mid-stream would disrupt playback for me
[14:26:36 CET] <durandal_1707> why is libav-devel mailing list archive down?
[22:17:17 CET] <wm4> jkqxz: so what happens if you attempt to transcode with vaapi between incompatible pixfmts? like say jpeg with some weird pixfmt to h264
[22:32:48 CET] <atomnuker> decoding will fail so nothing will happen
[22:36:48 CET] <atomnuker> it appears it will convert yuv422p to yuv420p/nv12 somewhere if encoding to e.g. h264
[22:38:18 CET] <atomnuker> and forcing sw_format of yuv422p using scale_vaapi and feeding that into an encoder will just output all green yuv420p
[22:40:08 CET] <wm4> I meant without readback, so I suppose scale_vaapi would somehow have to be involved (preferably auto-inserted)
[22:40:24 CET] <wm4> but if explicitly using that doesn't work then -> ???
[22:45:02 CET] <atomnuker> the encoder would probably error out
[23:05:17 CET] <cone-771> ffmpeg 03Rodger Combs 07master:63d875772d26: lavc/videotoolbox: fix threaded decoding
[00:00:00 CET] --- Fri Mar  9 2018