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

Sat Aug 27 03:05:02 EEST 2016

[00:13:05 CEST] <cone-556> ffmpeg 03Burt P 07master:9d5e3c3f59aa: af_hdcd: for easier maintenance alongside libhdcd
[00:13:06 CEST] <cone-556> ffmpeg 03Burt P 07master:ec220a8c1ca5: af_hdcd: av_frame_free(out) if av_frame_copy_props() fails
[01:06:00 CEST] <Shiz>  /w 21
[02:15:44 CEST] <cone-556> ffmpeg 03Jan Sebechlebsky 07master:bcd115316234: libavcodec/bsfs: Fix bsf option setting
[06:36:42 CEST] <durandal_1707> looks like yuvj will not die ever
[11:21:34 CEST] <cone-356> ffmpeg 03Davinder Singh 07master:b07d4a0fb20d: avfilter: added motion estimation and interpolation filters
[11:31:59 CEST] <DHE> regarding ticket #5799 -- seriously? console output does not validate a memory leak
[11:44:50 CEST] <durandal_1707> ignore Carl
[11:46:37 CEST] <DHE> I'm looking to see if I can reproduce it better than needing actual TV signals. but since it's based on side data, I don't think i can create a reproducer using only testsrc or such
[11:47:04 CEST] <DHE> I do have 12+ hours of TV saved just for reproducing this...
[11:47:33 CEST] <JEEB> the only thing I'd do if you can't somehow generate a nice input for it, is to simplify the command line
[11:48:17 CEST] <DHE> it looks like outputting to mpeg2 is the magic bit, so I could just drop the audio processing entirely and simplify the bitrate constraints
[11:48:32 CEST] <DHE> I'll give it a test run in the morning before updating the ticket with the simplified output
[11:48:45 CEST] <DHE> I was hoping that the stack dump would be enough to run it down by someone who understands it better than I
[11:49:49 CEST] <DHE> the only problem with the stack trace is that gcc inlined a function
[11:50:49 CEST] <JEEB> I will take a wild guess and say it has something to do with the props copying
[11:51:39 CEST] <DHE> it's odd that it doesn't actually leak the data - points are kept somewhere. but the number of allocations counted by valgrind is always roughly the number of frames processed thus far
[11:51:47 CEST] <DHE> *pointers are kept
[11:53:05 CEST] <BtbN> DHE, there seems to be an issues with av_frame_new_side_data in https://github.com/FFmpeg/FFmpeg/blob/500662784341373d625af629cad94826beca3bc8/libavutil/frame.c#L330
[11:53:09 CEST] <BtbN> or I misunderstand the code
[11:53:50 CEST] <BtbN> av_frame_new_side_data allocates a buffer using av_mallocz, and returns that buffer. And I don't see where frame_copy_props ever frees that.
[11:54:17 CEST] <BtbN> Or does av_dict_copy do that?
[11:54:36 CEST] <DHE> I honestly have no idea what's going on there. I would agree with you, except mysteriously valgrind reports no leaked memory on a clean shutdown.
[11:54:45 CEST] <DHE> unless there are circular references and valgrind doesn't track that
[11:55:22 CEST] <BtbN> ah. frame_new_side_data does "frame->side_data[frame->nb_side_data++] = ret;"
[11:55:47 CEST] <DHE> shouldn't that be freed when the new frame is freed?
[11:55:51 CEST] <BtbN> Yes
[11:56:01 CEST] <BtbN> but it's applied on the coded_frame in avctx
[11:56:05 CEST] <BtbN> which is there for the entire runtime
[11:56:13 CEST] <BtbN> to it just keeps appending another sidedata for the entire runtime
[11:56:38 CEST] <DHE> oh.. so the saved coded_frame just ends up with a massive list of side_data items?
[11:56:45 CEST] <BtbN> Yep
[11:56:52 CEST] <DHE> well then
[11:56:55 CEST] <BtbN> Using av_frame_copy_props for filling the coded_frame seems wrong in the first place.
[12:01:56 CEST] <BtbN> DHE: https://gist.github.com/d06a87934870c984246d23dde353bc29
[12:01:59 CEST] <BtbN> can you try this?
[12:02:36 CEST] <BtbN> Hm, nevermind. The actual data also needs to be freed.
[12:02:55 CEST] <BtbN> That would just cause an actual leak.
[12:04:17 CEST] <DHE> it'll be a few hours before I can test any candidate fix
[12:19:55 CEST] <flux> should (in libavformat/movenc.c) mov->track[*].st->id be unique among tracks?
[12:28:27 CEST] <flux> hmm, or for that matter, should mov->tracks[x].st be unique
[13:00:33 CEST] <cone-356> ffmpeg 03Davinder Singh 07n3.1.3:HEAD: avfilter: added motion estimation and interpolation filters
[14:41:08 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:330f4ef48c63: avformat/options_table: Add missing identifier for very strict compliance
[14:41:09 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:0aaf66fb2e22: avcodec/mjpegdec: Do not try to detect last scan but apply idct after all scans for progressive jpeg
[14:41:10 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:3bbef6082aee: avformat/oggparseopus: Check that granule pos is within the supported range
[14:41:11 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:fc6f314838dc: avformat/utils: Check bps before using it in a shift in ff_get_pcm_codec_id()
[14:41:12 CEST] <cone-356> ffmpeg 03Chris Cunningham 07release/2.8:345231336fd2: libavformat/oggdec: Free stream private when header parsing fails.
[14:41:13 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:500cf2e159fd: swresample/rematrix: Use error diffusion to avoid error in the DC component of the matrix
[14:41:14 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:67c7f8ca143d: swresample/rematrix: Use clipping s16 rematrixing if overflows are possible
[14:41:15 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:8857dc6cd856: ffmpeg: Check that r_frame_rate is set before attempting to use it
[14:41:16 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:2e0af764b32f: avformat/utils: Do not compute the bitrate from duration == 0
[14:41:17 CEST] <cone-356> ffmpeg 03Chris Cunningham 07release/2.8:c1c6cb21b7d2: avformat/utils: Check negative bps before shifting in ff_get_pcm_codec_id()
[14:41:18 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:90b27febc6ac: avformat/avidec: Detect index with too short entries
[14:41:19 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:9fe101291008: doc/developer.texi: Add a code of conduct
[14:41:20 CEST] <cone-356> ffmpeg 03Thomas Guilbert 07release/2.8:669fc1338f25: avformat/oggparseopus: Fix Undefined behavior in oggparseopus.c and libavformat/utils.c
[14:41:21 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:2bbbd3e50a8f: avcodec/bmp_parser: Fix state
[14:41:22 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:ffb503c9a14c: avcodec/mpegvideo: Deallocate last/next picture earlier
[14:41:23 CEST] <cone-356> ffmpeg 03Vivekanand 07release/2.8:5af0ada44271: avformat/allformats: Making av_register_all() thread-safe.
[14:41:24 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:76fd8145a1e2: avfilter/af_amix: dont fail if there are no samples in output_frame()
[14:41:25 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:731848ef8083: avcodec/bmp_parser: Fix frame_start_found in cross frame cases
[14:41:26 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:591c0b527c50: avcodec/bmp_parser: Fix remaining size
[14:41:27 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:166921c23eb4: avcodec/bmp_parser: reset state
[14:41:28 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:003fa5c3e3c3: avcodec/bmp_parser: Check fsize
[14:41:29 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:a4484854db89: avformat/mpegts: Do not trust BSSD descriptor, it is sometimes not an S302M stream
[14:41:30 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:04987035ffca: avcodec/utils: check skip_samples signedness
[14:41:31 CEST] <cone-356> ffmpeg 03Umair Khan 07release/2.8:1dd34bdb09ad: avcodec/alsdec: fix max bits in ltp prefix code
[14:41:32 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:8a32f19d5bd3: avcodec/alsdec: Check r to prevent out of array read
[14:41:33 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:bfca58ee2f4c: avcodec/h264: Fix off by 1 context count
[14:41:34 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:d9ad05abce33: MAINTAINERs cleanup (remove myself from things i de facto dont maintain)
[14:41:35 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:ed7fe48445c7: avcodec/mpegvideo: Do not clear the parse context during init
[14:41:36 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:40ffbe7678b7: avcodec/mpc8: Correct end truncation
[14:41:37 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:087bd8fbdfb9: avfilter/vf_telecine: Make frame writable before writing into it
[14:41:38 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:9fefd76eec20: avcodec/flac_parser: Raise threshold for detecting invalid data
[14:41:39 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:4a0b0cffc15a: avformat/format: Fix registering a format more than once and related races
[14:41:40 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:054db631200c: avformat/mov: Check sample size
[14:41:41 CEST] <cone-356> ffmpeg 03Sasi Inguva 07release/2.8:0f6e244bb009: libx264: Increase x264 opts character limit to 4096
[14:41:42 CEST] <cone-356> ffmpeg 03Kacper MichajBow 07release/2.8:d3ecb2453913: libavutil/opt: Small bugfix in example.
[14:41:43 CEST] <cone-356> ffmpeg 03Kacper MichajBow 07release/2.8:73e09e371bda: libavformat/rtpdec_asf: zero initialize the AVIOContext struct
[14:41:44 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:da12d544bf0b: avcodec/vp9_parser: Check the input frame sizes for being consistent
[14:41:45 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:486aa4fe39db: ffplay: Fix invalid array index
[14:41:46 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:942c3bfbdfd1: avformat/oggdec: Fix integer overflow with invalid pts
[14:41:47 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:3a6b27caf878: avcodec/ffv1enc: Fix assertion failure with non zero bits per sample
[14:41:48 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:3988470ee355: avcodec/raw: Fix decoding of ilacetest.mov
[14:41:49 CEST] <cone-356> ffmpeg 03Hendrik Leppkes 07release/2.8:65fff8e71ac9: cmdutils: remove the current working directory from the DLL search path on win32
[14:41:50 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:7a2329fac1ea: avcodec/h264: Put context_count check back
[14:41:51 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:7132e71a841c: Update for FFmpeg 2.8.8
[14:41:52 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:e965fedf7e94: avformat/swfdec: Fix inflate() error code check
[14:41:53 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:2b135f266dd3: avcodec/indeo2: check ctab
[14:41:54 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:33ec0280f38a: avcodec/diracdec: Check numx/y
[14:41:55 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:5a96b4b443d5: libavcodec/wmalosslessdec: Check the remaining bits
[14:41:56 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07release/2.8:562f2ba4ed07: avcodec/aacenc: Tighter input checks
[14:41:57 CEST] <cone-356> ffmpeg 03James Almer 07release/2.8:2f9bc30956fc: cmdutils: check for SetDllDirectory() availability
[14:52:47 CEST] <BtbN> I think I'll just by a GTX1060 next month. And hope it works at all in my PC.
[14:53:10 CEST] <JEEB> unless your PCI-e is derped, it should
[14:53:29 CEST] <JEEB> also I'll probably just grab the 1080 because WhyNot >_>
[14:53:49 CEST] <BtbN> I can't afford a 1080 right now.
[14:54:02 CEST] <BtbN> I just need something more recent than Kepler for NVENC stuff
[14:54:14 CEST] <BtbN> Can't test any HEVC patches, let alone the HEVC10 one on the ML.
[14:54:56 CEST] <BtbN> I have a Sandy Bridge board, which has only PCIe 2.0. To get my GTX760 running, i had to get an experimental BIOS update from ASUS via mail.
[14:55:50 CEST] <BtbN> Current plan is, to get a GTX1060 now, wait until Kaby Lake comes out, get a board with the new 200 series Chipset and an i7-7700k.
[14:56:20 CEST] <BtbN> And run it with the same 1060 for the time being, until I can upgrade to a 1080.
[15:04:02 CEST] <JEEB> yeah, the 1060 is pretty alright compared to f.ex. 960
[15:04:06 CEST] Action: JEEB has the 960 atm
[15:09:53 CEST] <BtbN> I have a 760 right now, so anything is an improvement.
[15:10:20 CEST] <BtbN> I don't want to go for the 1060 3GB edition though. 3GB doesn't seem worth it.
[15:13:55 CEST] <JEEB> if you don't game, probably not
[15:14:14 CEST] <JEEB> I've got a 2160p screen so games are starting to want more than 3GiB of VRAM
[15:19:08 CEST] <BtbN> I only have 1080p, and the most I'd go for would be 1440p
[15:19:24 CEST] <BtbN> But still, 3GB just isn't that much anymore. And the card is also slower with less cores.
[15:39:02 CEST] <RiCON> BtbN: 1060 can handle 1440p as well, not highest settings-well but well enough
[15:39:24 CEST] <BtbN> The 1440p screen I'll get will be 144Hz though
[15:39:53 CEST] <RiCON> with gsync?
[15:41:13 CEST] <RiCON> if not, just better to turn vsync off
[15:41:42 CEST] <nevcairiel> if you are a gamer at all, then go get gsync, its just brilliant
[15:44:11 CEST] <BtbN> Was thinking about the Acer XB271HUbmiprz
[15:45:24 CEST] <nevcairiel> i have th acer xb270, ie. the predecessor to that, can recommend
[15:46:01 CEST] <BtbN> But that will be in over a year. 1060 first, new PC, 1080, and finally the screen.
[16:40:11 CEST] <ubitux> i'm not really convinced by the results of mestimate
[16:41:09 CEST] <durandal_1707> default me?
[16:41:57 CEST] <ubitux> esa, exhaustive one
[16:42:15 CEST] <ubitux> but that might be only optimized for encoding
[16:43:23 CEST] <durandal_1707> that one is slowest
[16:51:14 CEST] <ubitux> durandal_1707: yes, but the result don't seem much relevant
[16:51:31 CEST] <ubitux> at least from an optical flow PoV
[16:51:47 CEST] <ubitux> ofc when targetting encoders that's another story
[16:52:09 CEST] <ubitux> but here i have a video with panning on half of it, and i just see shuffles of directions
[16:52:49 CEST] <ubitux> the encoded mvs used are actually much better
[16:57:49 CEST] <ubitux> durandal_1707: wget http://b.pkh.me/sfx-sky.mov and then ./ffplay -flags2 +export_mvs sfx-sky.mov -vf codecview=mv=pf vs ./ffplay sfx-sky.mov -vf mestimate,codecview=mv=pf
[16:58:43 CEST] <ubitux> in this case, if you're going to try to interpolate some kind of global motion (in a meaningful way, not encoder optimized), you'd better use the existing encoded mvs
[16:59:35 CEST] <durandal_17> yes, i agree
[17:00:32 CEST] <durandal_17> ubitux: expor_mvs is lavc option?
[17:00:47 CEST] <ubitux> yes
[17:00:56 CEST] <ubitux> flags2 are accessible in AVCodecContext
[17:01:04 CEST] <ubitux> so decoders can export them through frame side data
[18:37:33 CEST] <durandal_17> lol libav fixing pcx bugs, we fixed 4 years ago
[19:05:00 CEST] <izacarias> I'm interesting in extract information about QoE from ffmpeg... like initialization time, number of video stops, sum of video downtimes...
[19:05:01 CEST] <izacarias> Does anyone know if there is an easy way to do it?
[20:27:51 CEST] <rcombs> so, lavc currently exports a lot of HEVC profiles as FF_PROFILE_HEVC_REXT
[20:28:26 CEST] <rcombs> that macro expands to 4, which is technically what they're coded as in general_profile_idc, but isn't very helpful to the user
[20:41:16 CEST] <cone-688> ffmpeg 03Michael Niedermayer 07master:7827813f8cb3: avfilter/motion_estimation: Fix warning: variable dir_x set but not used
[20:47:31 CEST] <cone-688> ffmpeg 03James Almer 07master:ba3f32d07134: tools/crypto_bench: simplify gcrypt functions using a macro
[20:47:32 CEST] <cone-688> ffmpeg 03James Almer 07master:cf16d620765a: tools/crypto_bench: add support for des
[20:48:40 CEST] <BtbN> rcombs, there's more than MAIN and MAIN10?
[20:50:01 CEST] <rcombs> BtbN: https://puu.sh/qPmPj/e2da1efb1f.png
[20:50:38 CEST] <rcombs> the differences between them all are specified in what used to be XXX_reserved_zero_44bits
[20:52:41 CEST] <rcombs> which is replaced by everything below general_frame_only_constraint_flag here: https://puu.sh/qPmXb/2202504f00.png
[20:57:47 CEST] <rcombs> https://puu.sh/qPnj2/fb263e2cae.png
[20:58:07 CEST] <BtbN> this must be new
[20:58:13 CEST] <rcombs> version 2, 2015
[20:58:23 CEST] <rcombs> so& relatively new?
[20:59:05 CEST] <rcombs> wonder what portion of it lavc decodes properly and just doesn't export usefully in avctx->profile and what portion it doesn't handle at all
[20:59:46 CEST] <cone-688> ffmpeg 03Paul B Mahol 07master:e3fbfa561ebb: doc/filters: fix anequalizer docs
[20:59:56 CEST] <rcombs> came up because apparently some consumer device manufacturers document support for Main 4:2:2 10
[21:00:40 CEST] <rcombs> (kinda weird that there's no Main 4:2:2 8-bit profile, but there is a Main 4:4:4 8-bit one?)
[21:02:14 CEST] <rcombs> I mean, you could set the flags to 0b11110000 and effectively have a "main 4:2:2" (8-bit), it's just not documented as such
[21:02:18 CEST] <fritsch> rcombs: that 4:2:2 10 <- is probably a typo
[21:02:21 CEST] <fritsch> isn't it?
[21:02:48 CEST] <rcombs> fritsch: it's consistent everywhere in the spec where the profiles are discussed
[21:03:23 CEST] <fritsch> and in the detailed discussion it gets clear, that they really have that 2:2?
[21:03:42 CEST] <rcombs> you mean in the HEVC spec, or in the device documentation?
[21:03:47 CEST] <fritsch> device documentation
[21:04:00 CEST] <rcombs> all I've got for that is https://www.samsungdforum.com/Tizen/Spec#2016TVSpec
[21:04:10 CEST] <rcombs> "HEVC (H.265 - Main, Main10, Main4:2:2 10 )"
[21:04:25 CEST] <fritsch> nice, my tv
[21:04:31 CEST] <fritsch> i already tried main and main10
[21:04:33 CEST] <fritsch> which both worked
[21:04:38 CEST] <fritsch> but did not have Main 4:2:2 10
[21:05:08 CEST] <rcombs> as in, you didn't have a sample, or you tried it and it didn't work?
[21:05:29 CEST] <rcombs> if the former, would love if you could find a sample and test
[21:05:31 CEST] <fritsch> yeah, sorry: I did not have a sample
[21:05:57 CEST] <rcombs> wouldn't put it past Samsung to fuck up device docs so would be good to confirm
[21:06:13 CEST] <fritsch> if you have a sample I can try and test
[21:06:31 CEST] <rcombs> I'll look around
[21:07:33 CEST] <JEEB> funky @ 4:2:2
[21:07:41 CEST] <rcombs> apparently there's a paper on best-effort decoding 4:2:2 10 as 4:2:0 8
[21:08:08 CEST] <JEEB> so far even the most funkiest broadcasts have been 4:2:0 10bit BT.2020-NCL
[21:08:39 CEST] <fritsch> including the new german DVB-T2
[21:08:49 CEST] <fritsch> 1080p hevc 10 bit
[21:09:01 CEST] <JEEB> the BT.2020 part is the most surprising
[21:09:05 CEST] <fritsch> world is waiting on intel to release their broxton / kabilake
[21:09:58 CEST] <BtbN> I'll get a Kaby Lake i7-7700k the moment it comes out
[21:10:07 CEST] <BtbN> But it will be running Windows.
[21:10:43 CEST] <rcombs> no idea where to find samples for this tbh
[21:10:47 CEST] <fritsch> btw. nvidia vdpau also has no 10 bit hevc decoding support as of now, right?
[21:10:56 CEST] <jamrial> that tv supports vp9 4k but no opus?
[21:11:11 CEST] <BtbN> The only API from nvidia that supports 10bit is NVENC
[21:11:24 CEST] <fritsch> BtbN: might be the first time amd (christian könig) will implement it first
[21:11:33 CEST] <fritsch> and send patches to libvdpau / if needed
[21:11:35 CEST] <jamrial> only vorbis, so no full webm support
[21:11:42 CEST] <rcombs> I'll see if I can get some from Samsung or someone
[21:11:47 CEST] <fritsch> i don't use the TVs decoding caps at all
[21:11:48 CEST] <BtbN> Nvidia supports decoding it just fine in their hardware. They expose it via DXVA2 on windows i think?
[21:12:00 CEST] <fritsch> yes, they do
[21:12:08 CEST] <fritsch> but not via vdpau
[21:17:11 CEST] <RiCON> http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-VDPAU-1.0-Released this mentions main10 support
[21:18:24 CEST] <fritsch> afaik that's yet another phoronix article
[21:18:43 CEST] <BtbN> https://cgit.freedesktop.org/vdpau/libvdpau/tree/include/vdpau/vdpau.h#n2490
[21:18:44 CEST] <fritsch> they get the prepared values from libvdpau
[21:18:47 CEST] <BtbN> it does indeed have the profiles
[21:18:51 CEST] <fritsch> but not what the driver supports
[21:18:52 CEST] <fritsch> yes
[21:19:00 CEST] <fritsch> but that does not mean the driver supports it
[21:19:37 CEST] <BtbN> I can't find any 10 bit YUV pixel formats though
[21:21:21 CEST] <fritsch> interally conversion to RGB :-(
[21:21:24 CEST] <fritsch> and downscaling?
[21:21:32 CEST] <fritsch> or converting to yuv 8 bit?
[21:35:59 CEST] <rcombs> inb4 it's that "best-effort decode-as-4:2:0-8-bit" thing
[21:39:04 CEST] <BtbN> DHE, https://gist.github.com/BtbN/42f8f581149920dc28da1afe71310948
[21:41:15 CEST] <DHE> BtbN: so now we don't copy side data into coded_frame ?
[21:41:28 CEST] <DHE> conceptually it should work
[21:43:32 CEST] <BtbN> I don't think there is supposed to be side data in there anyway
[21:43:43 CEST] <BtbN> it was deprecated before side data even existed
[21:44:03 CEST] <DHE> makes sense
[21:44:18 CEST] <DHE> but the TV signal would include closed captions as side data
[21:44:33 CEST] <BtbN> Which just comes out with the normal frame side-data
[21:44:45 CEST] <BtbN> It's just the side data in the coded_frame that's removed here.
[21:45:29 CEST] <BtbN> The fact that it accumulates an ever growing list of sida_data elements and nothing explodes because of it should be quite clear about how many users of that exist
[21:45:51 CEST] <DHE> well, that's only used by API users. ffmpeg itself doens't use it
[21:47:01 CEST] <DHE> I'm running the patch now in the same test
[21:49:37 CEST] <BtbN> ./ffmpeg -f lavfi -i testsrc -c:v mpeg2video -s 320x240 -f null -y /dev/null
[21:49:43 CEST] <BtbN> that command does not grow indefinitely for me
[21:49:55 CEST] <BtbN> without any patch, that is
[21:49:55 CEST] <DHE> testsrc produces side data?
[21:50:00 CEST] <BtbN> oh
[21:50:01 CEST] <BtbN> good point
[21:50:31 CEST] <DHE> 20 minutes of encoding and memory usage seems to have long peaked out.
[21:50:43 CEST] <DHE> that's 20 minutes of video, not wall clock
[21:51:22 CEST] <BtbN> ah
[21:51:30 CEST] <BtbN> you can make it emit side_data, using mb_info
[21:53:28 CEST] <BtbN> mpeg2video doesn't seem to be the right codec to trigger that
[21:54:52 CEST] <DHE> my source is ~14 hours of TV broadcast totaling around 54 GB
[21:55:04 CEST] <BtbN> I mean the mpeg2video encoder
[21:55:21 CEST] <BtbN> is not in mpegvideo_enc.c
[21:56:30 CEST] <BtbN> i wonder why valgrind says it's being called
[21:56:50 CEST] <DHE> memory usage is still increasing, but at a much slower rate. not sure if it's just normal memory variation or not...
[21:57:12 CEST] <atomnuker> DHE: that's like, what, 8 mbps/second?
[21:57:19 CEST] <DHE> ?
[21:57:31 CEST] <atomnuker> (54*1024.0)/(14*60*60.0)
[21:57:33 CEST] <BtbN> I'm confused as to why that change had any effect. mpeg2video is not in mpegvideo_enc.c
[21:58:02 CEST] <atomnuker> most broadcast stuff I've seen won't go below 20 mbps
[21:58:07 CEST] <nevcairiel> mpeg2 encoding does use mpegvideo_enc internally
[21:58:12 CEST] <DHE> atomnuker: over 1 hour of video processed, RAM usage increased 3 megabytes...
[21:58:18 CEST] <nevcairiel> even if the main thing is in another file
[21:58:29 CEST] <DHE> atomnuker: it's H264 video, which is much lower bitrate. 7 to 8.5 is what I see, depending on the carrier
[21:58:56 CEST] <BtbN> nevcairiel, ah, now i see the chain.
[21:59:01 CEST] <BtbN> The valgrind output is very lacking then
[21:59:01 CEST] <DHE> MPEG-2 in HD will go way up to 15 or even 18 megabits at times. ATSC broadcasts cap out near that
[21:59:32 CEST] <DHE> BtbN: inlined functions do that. valgrind points at the correct line, but names the wrong function doing it
[21:59:45 CEST] <BtbN> but a function which has a symbol is plain missing
[22:01:38 CEST] <DHE> next time I'll have to compile with --disable-optimizations
[22:02:28 CEST] <BtbN> nah, it's fine. I think that workaround should fix it.
[22:03:04 CEST] <DHE> I'm going to want to run it under valgrind though. I'm still seeing a slow memory usage though, it's just a lot slower. seems to be around 1 megabyte per 20 minutes of video processed..
[22:03:31 CEST] <DHE> just need to convince myself it's allocator noise or it's actually a hidden allocation somewhere
[22:04:45 CEST] <BtbN> Well, is it gone when you disable the coded_frame api?
[22:07:22 CEST] <DHE> I didn't valgrind that version. Just ran it for an extended period and watched it with `top`. Looking at the overnights, I think I'm going to have to valgrind both
[23:07:12 CEST] <durandal_1707> I gonna apply vaguedenoiser
[23:12:59 CEST] <cone-688> ffmpeg 03Michael Niedermayer 07master:0c7979b43d5b: avfilter/motion_estimation: Fix pre processor formating
[23:14:32 CEST] <durandal_1707> michaelni: how much is frame multithreading doable in lavfi?
[23:18:31 CEST] <cone-688> ffmpeg 03Paul B Mahol 07master:0429ff4be674: avfilter: add vaguedenoiser filter
[23:20:19 CEST] <michaelni> durandal_1707, a filter could implement frame multitherading without any changes to avfilter core. It could be done throgh core with multiple filter instances filtering several frames at once,  there are probably more options and i wonder if this wasnt discussed before on ML
[23:48:51 CEST] <jamrial> nevcairiel: does "make fate-h264-conformance-cvfc1_sony_c HWACCEL=dxva2" fail for you?
[23:54:51 CEST] <jkqxz> jamrial:  It will.  That one has cropping on the left and top.
[23:55:29 CEST] <jamrial> ah
[23:55:34 CEST] <jamrial> kinda pointless having that fate option then, i guess
[00:00:00 CEST] --- Sat Aug 27 2016