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

[burek]

[00:02:49 CEST] <tdjones> Is it recommended to add separate fate tests for different audio channel configurations (mono, stereo, 5.1, etc)?
[00:04:52 CEST] <sfan5> anyone know whether android's mediacodec could support decoding motion jpeg?
[00:06:37 CEST] <atomnuker> tdjones: no, avoid getting more fate tests for encoders in until an encoder is feature complete
[00:06:57 CEST] <atomnuker> or is an encoder for a lossless format
[00:09:59 CEST] <tdjones> atomnuker: Alright, I figured so but wanted to check
[00:11:32 CEST] <atomnuker> however yes, having mono, stereo and 5.1 tests should cover 100% of what encoders use wrt multichannel
[00:15:05 CEST] <tdjones> I understand
[01:05:46 CEST] <J_Darnley> What the..?  Why does ffmpeg limit to 16 threads when the MAX_THREADS define is 64?
[01:07:11 CEST] <nevcairiel> limit where and what? mine doesnt =p
[01:09:11 CEST] <J_Darnley> In vc2enc, I printed avctx->thread_count; that was 16.
[01:09:13 CEST] <iive> J_Darnley: have you solved the buffer issue?
[01:09:18 CEST] <J_Darnley> iive: yes
[01:09:24 CEST] <J_Darnley> My own silly mistake
[01:09:25 CEST] <iive> what was it?
[01:09:28 CEST] <iive> :D
[01:09:48 CEST] <iive> hapens all the time.
[01:10:32 CEST] <J_Darnley> The transform buffer is not a plane.  The transform uses a contiguous region of it.  I was offsetting the base pointer like a plane which mean neighbouring slices were writing to the same place.
[01:11:15 CEST] <J_Darnley> Not a problem when it is all linear because it is a temp/scratch buffer.
[01:11:41 CEST] <J_Darnley> Thanks for the help.  You too BBB and nevcairiel
[01:12:12 CEST] <J_Darnley> to continue: ffmpeg also printed "Application has requested 24 threads.  Using a thread count greater than 16 is not recommended."
[01:12:26 CEST] <J_Darnley> ... when I set -threads 24
[01:12:35 CEST] <nevcairiel> thats normal, it complains if you use more then cpu cores, but it doesnt do anything but log that
[01:12:37 CEST] <iive> well, messages are easier to find.
[01:13:12 CEST] <J_Darnley> Huh?  This server has 24 threads (2sockets, 6core, hyperthreading)
[01:13:35 CEST] <nevcairiel> maybe thats a hardcoded value then for dumb reasons
[01:13:50 CEST] <J_Darnley> it is in avcodec/pthreads.c
[01:14:24 CEST] <nevcairiel> the only time its really setting thread_count is if you have it at 0
[01:14:32 CEST] <nevcairiel> dont see where it might be overriding a requested value
[01:14:33 CEST] <J_Darnley> Ah.  That seems to be MAX_AUTO_THREADS
[01:16:38 CEST] <iive> i like the comment before its define :}
[01:18:04 CEST] <J_Darnley> hahaha
[01:18:13 CEST] <nevcairiel> sounds like some hack fix in response to some stupid trac ticket
[01:19:38 CEST] <nevcairiel> although surprisingly it is not from trac, but it remains some clumsy hack
[01:21:09 CEST] <iive> git blame says that file is from 2013
[01:27:28 CEST] <drv> it got moved around - it was originally introduced in ea4d5f48373ab856e01a3cf05426db6e823e01d1
[01:34:15 CEST] <ZeroWalker> well i am at least getting some audio now after swr conversion. Though it's glitchy, not sure if the conversion is wrong or if it has to do with the timestamps, as normally it's set by time when the capture occurs. But if i use swr there will be some buffering, so it will set the timestamp that happens to be when the buffer gets full. Though i think that would be fine as it should still be an interval that causes it to keep 
[01:34:15 CEST] <ZeroWalker> up
[02:32:04 CEST] <ZeroWalker> no ideas;d
[02:33:32 CEST] <cone-956> ffmpeg 03Wan-Teh Chang 07master:ea1ca17be230: avcodec/x86/cavsdsp: Delete #include "libavcodec/x86/idctdsp.h".
[02:33:32 CEST] <cone-956> ffmpeg 03Wan-Teh Chang 07master:b77e26b28525: avcodec/hevcdec: hevc_await_progress: declare |y| only if used.
[02:33:32 CEST] <cone-956> ffmpeg 03Wan-Teh Chang 07master:99c5ac20397e: avcodec/h264: Declare the local variable decode_chroma as const.
[04:46:39 CEST] <ZeroWalker> so with the avcodec_send_frame, isn't it possible to get a callback or something when it's done, rather then check, cause if you check all the time, isn't it the same as the previous API versions?
[04:50:53 CEST] <wm4> lol apparently US police uses jpeg2000 to store high resolution fingerprints
[04:51:12 CEST] <wm4> and for lower resolution, WSQ (whatever that is)
[04:51:27 CEST] <wm4> according to wikipedia
[04:53:45 CEST] <atomnuker> ZeroWalker: its not async, you give it packets and it won't return until there's something to do
[04:54:12 CEST] <atomnuker> you don't need to poll it, there'll always be something to do
[04:54:22 CEST] <atomnuker> either feed it more packets or get a frame out
[04:55:35 CEST] <atomnuker> wm4: that kinda makes sense, both are wavelet based so both don't have blocking artifacts (and don't have to bodge them with filters)
[04:56:10 CEST] <TD-Linux> jpeg2000 is heavily used for US government contracts
[04:56:17 CEST] <ZeroWalker> so if i am capturing, it would just be "Send/Receive" whenever a frame is to be encoded?
[04:56:20 CEST] <TD-Linux> most government satellites also use jpeg2000
[04:56:52 CEST] <TD-Linux> the ability to progressively download higher resolutions is very useful
[05:03:19 CEST] <ZeroWalker> cause well, i was wondering if one could use this Send frame thing to let the encoder handle audio frames, so you can just push it and it will encode whenever it gets enough.
[05:03:48 CEST] <ZeroWalker> cause been having a point solving that, especially since it's all timestamp bound for video and audio for me
[05:58:49 CEST] <ZeroWalker> i can't use swr_convert_frame, i get "Output Changed", and i don't understand what it's supposed to mean. What does it mean "changed", i can't seem to find any information on it
[06:13:01 CEST] <wm4> doesn't the doxygen say? if in doubt, look at libavresample's doxygen, where this was apparently stolen from
[06:23:26 CEST] <ZeroWalker> you talking to me, or someone else?
[08:57:57 CEST] <ZeroWalker> okay i finally got it working, probably had it somewhat working before, but of course i had this stupid mistake of having the swr channel layout (input or if it was output) to the Channel count instead -_-
[08:58:32 CEST] <ZeroWalker> now i do however get a constant delay, but that's expected, probably a pain but it's solvable;d
[08:59:35 CEST] <ZeroWalker> now there's cleanup to do, and i am kinda confused wham to actually free some stuff, cause i never understand when a function makes a copy of it or not, cause some are referenced count, clean up themselves etc, now my expertise:(
[10:08:58 CEST] <durandal_1707> michaelni: you broke another codec again ^
[10:09:33 CEST] <thebombzen> we should have a tvshow series starring michael but instead of calling it "code breakers" it's "codec breakers"
[10:24:26 CEST] <FlowerCodec> hello everyone.
[10:26:04 CEST] <stevenliu> hi
[10:26:55 CEST] <FlowerCodec> haha dashixiong...
[10:29:26 CEST] <kierank> durandal_1707: yes but it doesn't have a maintainer so michaelni can push when he want
[10:30:30 CEST] <kierank> did you know I maintain the moon and sky
[10:30:45 CEST] <kierank> you can maintain the trees
[10:30:53 CEST] <kierank> we just have to make a file saying so
[10:36:25 CEST] <durandal_1707> kierank: there was before addition: every single patch must be sent to maintainer before pushing, looks like it got removed
[10:37:22 CEST] <durandal_1707> you just add such sentence in maintainers file
[11:52:12 CEST] <michaelni> durandal_1707, thebombzen kierank, patch posted which fixe ticket 6546
[11:52:28 CEST] <thebombzen> well okay
[11:55:31 CEST] <michaelni> also reviews for any other patch i post are welcome. I have the feeling most of the patches i post get no review
[12:33:35 CEST] <J_Darnley> Does avcodec employ any tricks for edge extension other than just copying to a larger buffer and duplicating data?
[12:44:45 CEST] <kierank> J_Darnley: no, that's the way to do it per slice afaik
[13:01:31 CEST] <J_Darnley> I thought as much
[13:12:25 CEST] <michaelni> J_Darnley, "git grep edge_emu" if you want to see some of the code that deal with edge extension
[13:22:40 CEST] <J_Darnley> thanks, I'll check it out
[13:25:06 CEST] <kierank> J_Darnley: it's not comparable edge extension
[14:10:36 CEST] <kierank> J_Darnley: when michaelni means edge extension he means edge of frame
[14:10:39 CEST] <kierank> we mean edge of slice
[14:11:03 CEST] <kierank> if you want to do it inplace I guess you could allocate a larger buffer
[14:11:18 CEST] <J_Darnley> I know that.
[14:11:35 CEST] <J_Darnley> I'm still going to look at it to se if it provides anything useful
[14:11:36 CEST] <kierank> might be easier to do the edge extension in a scratch buffer, I dunno
[14:11:37 CEST] <kierank> ok
[14:12:31 CEST] <J_Darnley> I believe the spec or those white papers say you should duplicate even and odd samples rather than just the edge one or a mirror
[14:12:45 CEST] <kierank> yes
[17:21:08 CEST] <cone-621> ffmpeg 03James Almer 07master:7c9d2ad45f4e: avcodec/dca: remove GetBitContext usage from avpriv_dca_parse_core_frame_header()
[17:21:09 CEST] <cone-621> ffmpeg 03foo86 07master:67af24da0dc2: MAINTAINERS: add myself
[17:38:01 CEST] <cone-621> ffmpeg 03Kaustubh Raste 07master:ef1b4bdf4456: libavutil/mips: Updated msa generic macros
[17:38:02 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:1196e53b7013: doc: Add initial documentation explaining undefined behavior and SUINT
[17:38:03 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:edc88646ee40: avcodec/diracdec: Check dimensions which are closer to what is allocated in alloc_sequence_buffers()
[21:28:10 CEST] <cone-621> ffmpeg 03Vittorio Giovara 07master:0a243bedec0a: zscale: Factor out format initialization
[21:28:11 CEST] <cone-621> ffmpeg 03Vittorio Giovara 07master:2e91a96d7bc9: zscale: Factor out graph building
[21:28:12 CEST] <cone-621> ffmpeg 03Vittorio Giovara 07master:dc9735eb67ca: hevc: Make sure to update the current frame transfer characteristic
[21:28:13 CEST] <cone-621> ffmpeg 03Vittorio Giovara 07master:d24a82d2e2b7: ffprobe: Print color properties from show_frames
[00:00:00 CEST] --- Sat Jul 22 2017