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

[burek]

[02:38:05 CEST] <ZeroWalker> can you obtain the input/output information from SwrContext?
[02:38:13 CEST] <ZeroWalker> like samplerate, format etc
[04:06:18 CEST] <atomnuker> rcombs: got the time to fix yer flac coverart embedding?
[04:06:27 CEST] <rcombs> was there still something wrong with it
[04:06:36 CEST] <rcombs> apart from "is not merged"
[04:07:28 CEST] <atomnuker> I think jamrial had some issues which is why you didn't merge them
[04:09:23 CEST] <ZeroWalker> is there any function that does the linesize etc when using sws to convert? Feels kinda weird as i set it up when i initialize it, but when then using sws_scale i have to give it some information again
[04:37:07 CEST] <jamrial> atomnuker: i asked for some changes i think but it was a while ago
[05:18:42 CEST] <ZeroWalker> guess not;(
[05:38:03 CEST] <cone-913> ffmpeg 03James Almer 07master:8f2f166c99df: avcodec/atrac3p: use float_dsp in ff_atrac3p_power_compensation
[06:12:38 CEST] <rcombs> jamrial: I think this covers all your concerns? https://github.com/rcombs/FFmpeg/tree/cue
[06:16:40 CEST] <ZeroWalker> am i failing to understand how swscale works. Aren't you supposed to feed it the Source raw buffer and linesizes, and a Destination raw buffer and line size. So the Source just needs to be the raw data from whatever source you get it. And the Destination can be an allocated with av_image_alloc
[06:19:38 CEST] <jamrial> rcombs: you're still not flushing the buffered packets on oom. look at mp3enc.c
[06:24:45 CEST] <rcombs> I do feel a little bit uneasy about that OOM behavior
[06:25:04 CEST] <rcombs> because it allows the operation to succeed, with only a log line indicating that something went wrong
[06:25:22 CEST] <rcombs> which the user won't see in all use-cases
[06:25:31 CEST] <jamrial> then you should make it abort, not write the current audio packet
[06:26:13 CEST] <rcombs> that's what I did at first :|
[06:27:10 CEST] <rcombs> still, whatever behavior we land on, it should be consistent
[06:27:34 CEST] <rcombs> so, in general, should ffmpeg recover lossilly from OOM, or fail hard?
[06:27:42 CEST] <jamrial> it either flushes the buffer then continues from the current packet, so the output audio is correct, or it aborts the whole thing
[06:28:05 CEST] <rcombs> is it possible to set AV_EF_EXPLODE on a muxer?
[06:28:33 CEST] <jamrial> imo, what the mp3 muxer does is best. not abort and write the file without the image that didn't show up on time
[06:28:34 CEST] <jamrial> yes
[06:29:06 CEST] <rcombs> maybe make it conditional on that, then
[06:29:46 CEST] <jamrial> you definitely can't make it write the current audio packet without first flushing the buffer. that's a lot of data lost
[06:30:08 CEST] <rcombs> yeah that's clearly wrong
[06:30:44 CEST] <atomnuker> where do you need to allocate and couldn't you use refcounting to avoid it?
[06:33:09 CEST] <atomnuker> I'd also prefer to have the micro bumped once either as a separate commit or with the last commit
[06:34:08 CEST] <rcombs> gotta keep a queue
[06:35:19 CEST] <rcombs> AVPacketList
[06:35:28 CEST] <rcombs> which is pretty small per packet, of course
[06:35:58 CEST] <rcombs> oh, I'm currently using av_copy_packet, which I shouldn't be
[06:40:03 CEST] <jamrial> the packet functions are a mess. there are three different functions that do the same thing in some cases
[06:40:52 CEST] <jamrial> some are supposedly deprecated but not wrapped in deprecation guards, or wrapped in guards but not tagged as such
[06:43:44 CEST] <rcombs> there you go
[06:47:18 CEST] <jamrial> rcombs: next is sharing the flac image code so the ogg muxer can use it :p
[06:48:28 CEST] <rcombs> do you care enough about that to block merge
[06:48:49 CEST] <atomnuker> does ogg really let you mux coverart in?
[06:51:46 CEST] <jamrial> rcombs: of course not
[06:52:06 CEST] <rcombs> alright, any objections to the full patchset now?
[06:52:27 CEST] <jamrial> atomnuker: yeah, it's crazy. it's flac picture format, encoded in base64 and put inside a vorbiscomment tag
[06:52:46 CEST] <rcombs> &wat
[06:52:59 CEST] <rcombs> "you know what would make this better? base64"
[06:53:46 CEST] <rcombs> --nobody, ever
[06:54:04 CEST] <jamrial> --someone, at xiph
[06:55:49 CEST] <jamrial> rcombs: did you get any reviews for the cue and segment patches? if not, send the whole patchset to the ml first
[07:00:02 CEST] <rcombs> 2 of the segment patches got LGTM/looks fine'd; 1 never really got anything
[07:00:21 CEST] <rcombs> cue got one comment about opening arbitrary URLs, which is why it now restricts itself to side-by-side files
[07:01:52 CEST] <atomnuker> just push it, break your f5 key on recent fate tests and check email for coverity complaints
[07:47:00 CEST] <ZeroWalker> is there something special with RGB24 when convering to YV12, cause i get read/write access error, so i assume it reads/writes too much data or something
[07:48:03 CEST] <atomnuker> alignment and padding
[07:48:47 CEST] <atomnuker> (actually IIRC you can give libswscale unaligned input and it'll take a slow path)
[07:49:40 CEST] <ZeroWalker> even aligning to 1 doesn't help
[07:50:42 CEST] <ZeroWalker> i am converting from RGB24 to YV12, i have an AVFrame that's setup for YV12, and RGB24 is raw data so i use av_image_alloc and av_image_fill_arrays to set it up before passing it to sws_scale
[07:55:12 CEST] <ZeroWalker> hmm might  be something else, need to check some stuff out, cause i could get for example YUY2 720x480 work from one source, but it would fail on another, which makes no sense unless the data is different somehow
[07:57:55 CEST] <ZeroWalker> or not, okay this is weird i know i produced a correct output
[08:06:41 CEST] <ZeroWalker> hmm okay well the only thing that works is if the source is RGB32, so it must be something with the padding i guess, YUY2 (YVYU or whatever) doesn't work and neither does RGB24. so i must have something set up wrong
[08:41:17 CEST] <atomnuker> remember rgb is not planar
[08:53:35 CEST] <rcombs> &do we have a policy against defining variables at the top of a block scope?
[08:53:58 CEST] <nevcairiel> no
[08:54:11 CEST] <rcombs> didn't think so
[08:54:19 CEST] <nevcairiel> just not in the middle of code, otherwise the compiler whines
[08:54:39 CEST] <rcombs> (re: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/214361.html )
[08:55:08 CEST] <rcombs> nevcairiel: why do we still have that warning anyway
[08:55:37 CEST] <rcombs> didn't we stop supporting 20th-century compilers at some point
[08:55:39 CEST] <nevcairiel> because we probably still have compilers that don't like it, also its generally not too bad of a idea to stick to i t
[08:55:43 CEST] <atomnuker> tidyness
[08:56:03 CEST] <nevcairiel> the only case is loop variables that I don't think gcc even complains about
[08:56:15 CEST] <nevcairiel> ie. for (int i = 0; ...)
[08:56:23 CEST] <rcombs> it's often tidier, but I wouldn't say always
[08:56:25 CEST] <nevcairiel> technically i guess its  inside some sort of block
[08:58:47 CEST] <thebombzen> IIRC, ANSI C requires variables to be declared at the beginning of their block scope, but ISO C99 doesn't require that anymore
[08:59:12 CEST] <thebombzen> so the for (int i = 0; ...) that stuff is allowed in C99
[09:00:21 CEST] <thebombzen> ah, Wikipedia's C99 article lists this: intermingled declarations and code: variable declaration is no longer restricted to file scope or the start of a compound statement (block), facilitating static single assignment form
[09:44:00 CEST] <rcombs> &huh
[09:44:11 CEST] <rcombs> raise your hand if you've ever heard of a short _first_ frame in FLAC
[10:11:37 CEST] <nevcairiel> that sounds dumb for a lossless codec, its not like it needs decoder priming or anything that might need any magic at the beginning of the stream
[12:24:49 CEST] <ldts> I am hitting a regression when running the fate tests and I'd appreciate some help with it (source-check.sh is complaining about av_clip in a file that doesnt have the call). the trace: https://hastebin.com/umilirokum.cs  
[12:25:10 CEST] <ldts> any suggestions will be very welcome 
[12:25:55 CEST] <nevcairiel> you're reading that wrong, those are the headlines for the next section, you would need to find the headline for the previous section
[12:26:32 CEST] <ldts> ah ok, it is just that I added those new compat files and I thought I had tripped over something. cool. I'll check. thanks!
[12:27:38 CEST] <ldts> also tests/data/fate/source.err is empty ...not sure if it is relevant?
[12:28:07 CEST] <nevcairiel> i would still question including kernel headers however, it should just disable itself if headers are not available - its not like its actually going to run if the kernel is too old
[12:30:18 CEST] <ldts> right, but as the api evolves we cant just check that every single macro is present ...since the kernel will not break userspace -and to avoid build issues- this seems to be the standard solution (the folks at gstreamer have opted for the same btw)
[12:31:27 CEST] <nevcairiel> if they are constantly going to break the headers in incompatible manner, maybe wait until they are done =p
[12:32:14 CEST] <ldts> I dont think it will ever be done :)
[12:32:30 CEST] <ldts> the point is to make sure that the code that we have does compile on all kernels...
[12:33:05 CEST] <ldts> the v4l2 encoder/decoder might not work at runtime (ie if there is an API that it is needed and it is not present in the running kernel)
[12:33:15 CEST] <J_Darnley> ldts: I think the include guard is wrong
[12:33:25 CEST] <ldts> yes I noticed that!
[12:33:27 CEST] <ldts> thanks :)
[12:33:39 CEST] <ldts> I had to rename the file and forgot the include guard...
[12:33:55 CEST] <nevcairiel> my point is that there is no point to compile it if its not going to run anyway, and maintaining a bunch of imported headers should always have a stronger argument then "some systems are too old to build it"
[12:33:56 CEST] <J_Darnley> :) that test is one of the more annoying ones.
[12:35:33 CEST] <ldts> nevcairiel:  I agree with you but how do you propose that happens? an alternative was to test the presence of all the V4L2 calls but that was a massive pain for little gain..
[12:36:09 CEST] <ldts> J_Darnley:  the source test?
[12:36:13 CEST] <J_Darnley> yeah
[12:36:17 CEST] <nevcairiel> well do they really break the headers in incompatible manners all the time? Or do you just need a sufficient recent state and they are not going to remove existing things again?
[12:36:24 CEST] <ldts> I am still trying to figure out where to get the section that is failing...
[12:36:45 CEST] <nevcairiel> because if its the second, you can just check for whatever latest symbol you require and assume everything else is present
[12:37:25 CEST] <nevcairiel> (and the first would be a terrible way to define APIs, especially if they dont have versioning)
[12:43:24 CEST] <ldts> nevcairiel: but backwards compatibility is not broken, it is only that new features are added. And if you try to use the newer features in your code and build it on an old machine it will just not build....it is hard for me to disagree with you because it is about choosing the lesser of two not great options. the way I am posting in v2 only requires updates very few years and if the new calls are required. Didnt NVIDIA do the same adding to compat/nvdec?
[12:45:46 CEST] <ldts> ...was about to post v2 when hit this evil test :) maybe we can have the discussion on the ML just so we can track it?
[12:46:47 CEST] <ldts> as soon as I pass the fate tests will post (tested encoders and decoders - and concurrent hw decoding/encoding)
[12:57:20 CEST] <Shiz> w 25
[13:04:15 CEST] <ldts> nevcairiel:  um, not sure where to look...https://hastebin.com/sirutecusu.diff
[13:34:33 CEST] <ubitux> any objection to the subrip patchset?
[13:49:53 CEST] <BBB> no
[13:50:02 CEST] <BBB> ubitux: did you have an opinion on libvmaf/pkgconfig?
[13:55:33 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07master:46e407554968: avcodec/dirac_vlc: Fix invalid shift
[13:55:34 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07master:880f5c59139e: avcodec/diracdec: Check weight_log2denom
[13:55:35 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07master:b2d9d7226943: avcodec/diracdsp: fix integer overflow
[14:02:11 CEST] <nevcairiel> ldts: just requiring a recent version of a system-provided header is what we do for all sorts of hardware stuff (eg. vaapi), the nvidia stuff is a tad bit special because the headers are not packaged on linux distros and obtaining them from the official source requires registration, so the barrier is just so much higher
[14:07:06 CEST] <jkqxz> The Nvidia stuff also habitually updates to and requires the newest version, because the lack of distribution support allows that.
[14:07:09 CEST] <jkqxz> That isn't true of anything else, which has to work on old versions in old distributions.
[14:08:25 CEST] <jkqxz> I think if it works in sensible older-but-still-supported distributions (e.g. Debian 8, Ubuntu 14.04, CentOS 6) then it's fine; if it doesn't then that's maybe a bit dubious.
[14:14:47 CEST] <ldts> nevcairiel:  jkqxz : just fixed the fate tests I broke (it was just a trivial addition missing in tests/ref/fate/source). will post v2 to the ML and we can continue there if that is ok (the solution of adding v4l2 headers to compat is inline with what other projects with similar requirements is doing...if the ffmpeg project doesnt think it is reasonable, we can certainly have other solutions in line to what you are saying (just like Groucho would say: these 
[14:14:47 CEST] <ldts> are my principles, if you dont like them ..I have others ) 
[14:18:49 CEST] <ldts> (sorry, I just want to get as much input on that compat discussion as possible, that is all)
[14:20:55 CEST] <BtbN> jkqxz, every time the nvidia headers are updated, they require a driver with support for the header version
[14:46:28 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:62b536690d27: avcodec/tiff: Update pointer only when the result is used
[14:46:29 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:10a085a21f2d: avcodec/takdec: Fix integer overflow
[14:46:30 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:b3cf49b6f9a2: avcodec/wavpack: Fix integer overflow
[14:46:31 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:f626a479f412: avcodec/mpeg4videodec: Fix GMC with videos of dimension 1
[14:46:32 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:62e942ab1c04: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo()
[14:46:33 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:750fec58e175: avcodec/apedec: Fix integer overflow
[14:46:34 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:634e9a696d85: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int()
[14:46:35 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:73f42b7b58ca: avcodec/vb: Check vertical GMC component before multiply
[14:46:36 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:d2452b9e20ec: avcodec/cfhd: Fix invalid left shift of negative value
[14:46:37 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:0837678cbd33: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets
[14:46:38 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:965f15551fb0: avcodec/h264_slice: Fix signed integer overflow
[14:46:39 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:be1f146a0f1c: avcodec/wavpack: Fix invalid shift
[14:46:40 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:215d6f897d3e: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise()
[14:46:41 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:51f0580c5f43: avcodec/ylc: Fix vlc of 31 bits
[14:46:42 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:910878e4d90a: avcodec/aacps (fixed point): Fix multiple signed integer overflows
[14:46:43 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:506bbbc09929: avcodec/mjpegdec: Clip DC also on the negative side.
[14:46:44 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:94077cf6735a: avcodec/magicyuv: Check that vlc len is not too large
[14:46:45 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:a2c3c9bc6038: avcodec/aacdec_template: Fix undefined integer overflow in apply_tns()
[14:46:46 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:02bec657f371: avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later
[14:46:47 CEST] <cone-353> ffmpeg 03Vodyannikov Aleksandr 07release/3.1:c6d9d0022093: avcodec/cfhd: Fix decoding regression due to height check
[14:46:48 CEST] <cone-353> ffmpeg 03Brice Waegeneire 07release/3.1:2453c66b0ff8: doc/filters: typo in frei0r
[14:46:49 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:918d45ec82ea: avcodec/aacdec_fixed: fix: left shift of negative value -1
[14:46:50 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:2755c73d55b2: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20()
[14:46:51 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:a0edd7f583b8: avcodec/ylc: Fix shift overflow
[14:46:52 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:65304d33a20f: avformat/oggparsecelt: Do not re-allocate os->private
[14:46:53 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:7f3124e08c30: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2
[14:46:54 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:956f2db21ffc: avcodec/dnxhddec: Move mb height check out of non hr branch
[14:46:55 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:f4c844923831: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH()
[14:46:56 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:54a6c1368cdb: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2
[14:46:57 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:06ce68d8a07d: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2
[14:46:58 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:6274709c1c11: avcodec/takdec: Fix integer overflow in decode_subframe()
[14:46:59 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:6b1c71040d17: avcodec/diracdec: Fix integer overflow in divide3()
[14:47:00 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:acedc53186c4: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0()
[14:47:01 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:6d849e2706d0: avcodec/diracdec: Check weight_log2denom
[14:57:23 CEST] <BtbN> Hm, I wonder if the HLS muxer properly handles a discontinuity if it's writing fmp4 with an initial segment
[15:36:39 CEST] <paras2052> durandal_1707: hi, there is no global header.
[15:36:55 CEST] <paras2052> Each packet has its own header
[15:37:24 CEST] <paras2052> There are slight differences between header of first packet and other packets
[15:38:20 CEST] <durandal_1707> what difference?
[15:39:03 CEST] <paras2052> The first keyword is SIMPLE = T for first packet. For rest it is XTENSION = 'IMAGE'
[15:39:26 CEST] <paras2052> PCOUNT, GCOUNT keywords are not mandatory for first packet but they are for rest
[15:39:58 CEST] <durandal_1707> does first packet have extension?
[15:40:07 CEST] <paras2052> no
[15:40:43 CEST] <durandal_1707> than just do one muxer
[15:41:45 CEST] <paras2052> yes, but the muxer will just append the packets one after another. So, it will be exactly same as RAW muxer. Should i just use that or create separate ?
[15:41:56 CEST] <ubitux> BBB: https://patchwork.ffmpeg.org/patch/4413/ this?
[15:42:30 CEST] <ubitux> "link" is the wrong word here
[15:42:45 CEST] <BBB> that doenst load for me because certificate is revoked :(
[15:43:05 CEST] <BBB> configure: require pkg-config for libvmaf
[15:43:06 CEST] <BBB> that one
[15:43:32 CEST] <ubitux> "This patch makes libvmaf filter link to pkg-config of libvmaf." this sentence is incorrect
[15:43:46 CEST] <ubitux> content of the patch should be fine; though, you may want to add a version check
[15:43:59 CEST] <ubitux> "libvmaf >= 0.1.2" or whatever version
[15:47:10 CEST] <ubitux> seems it was added in git/master only
[15:47:19 CEST] <ubitux> so not available in any release so far
[15:47:31 CEST] <BBB> right
[15:47:38 CEST] <ubitux> like, it was merged 10 days ago
[15:48:25 CEST] <ubitux> you may want to at least wait a release
[15:48:54 CEST] <BBB> okay
[15:49:24 CEST] <ubitux> alternative is to make a fallback on a require that will stay there forever
[15:55:14 CEST] <BBB> the library itself isnt in a release either
[15:55:19 CEST] <BBB> ashish added the library
[15:55:21 CEST] <BBB> and the pkg-config file
[15:55:35 CEST] <BBB> the pkg-config came after the library (a few weeks later) based on comments here
[15:55:45 CEST] <BBB> so the window for lib-but-no-pkgconfig is small
[15:55:47 CEST] <BBB> I think its ok
[15:57:20 CEST] <durandal_1707> paras2052: whatever you prefer
[15:58:02 CEST] <paras2052> okay
[16:02:25 CEST] <ubitux> BBB: https://github.com/Netflix/vmaf/releases
[16:02:31 CEST] <ubitux> i see releases here
[16:07:33 CEST] <BBB> ubitux: but not with the library in it
[16:07:48 CEST] <ubitux> oh, ok
[16:08:00 CEST] <ubitux> well then, no opinion
[16:08:06 CEST] <ubitux> feel free to update desc then
[16:09:17 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:f0f8da545d80: lavc/htmlsubtitles: improve handling broken garbage
[16:09:18 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:55949e3e5189: lavc/tests: add htmlsubtitles
[16:09:19 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:e80037186327: lavc/htmlsubtitles: improve line breaks handling
[16:09:20 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:479ab8c3f842: lavc/htmlsubtitles: handle colors starting with many '#'
[16:09:21 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:1193301758b8: lavc/htmlsubtitles: reindent after previous commits
[16:27:04 CEST] <ubitux> i'll be away for while starting tomorrow, don't expect any answer from me
[16:34:01 CEST] <BBB> sure, np
[16:40:06 CEST] <durandal_1707> ubitux: what you mean?
[16:41:53 CEST] <atomnuker> he's from France
[16:42:11 CEST] <atomnuker> have you been to France during August?
[16:43:39 CEST] <iive> You mean that they are using their one month paid vacation to be on the beach?
[16:44:57 CEST] <atomnuker> dunno what they do, not sure where they all go
[16:46:37 CEST] <atomnuker> is the riviera big enough?
[16:50:11 CEST] <ubitux> i'll just move away from the country as i'm unable to leave the planet
[16:50:15 CEST] <ubitux> will be good enough for a start
[16:53:44 CEST] <atomnuker> do the french have french rivieras elsewhere?
[16:54:09 CEST] <atomnuker> but wait, would a french riviera still be a french riviera if its not french?
[16:54:45 CEST] <atomnuker> I guess the italians have one, but its an italian riviera, not sure if its the same thing
[17:02:19 CEST] <BBB> I thought ubitux was belgian?
[17:04:34 CEST] <J_Darnley> The Belgians also spend their holidy on French beaches.
[17:21:44 CEST] <BBB> I suppose thats true
[17:21:47 CEST] <BBB> so will I, btw ;)
[17:50:42 CEST] <durandal_1707> kierank: where are you going for vacation?
[17:51:02 CEST] <kierank> The pub
[17:52:09 CEST] <durandal_1707> lies. you are always traveling somewhere
[17:53:29 CEST] <kierank> no not really
[17:53:33 CEST] <kierank> compared to people like daemon404
[18:45:16 CEST] <ZeroWalker> what's the format for i420?
[18:47:23 CEST] <nevcairiel> isnt that just yuv420p
[18:48:57 CEST] <FishPencil> Does FFmpeg attempt to detect the input media format from the file extension? If so, where is that code snippet located?
[18:51:23 CEST] <Blubberbub_> AVInputFormat has an extension-property or something like that, i think
[18:52:09 CEST] <FishPencil> Is there some sort of case that defines what decoder to use based on the extension?
[18:53:17 CEST] <J_Darnley> As I understand it avformat will use the demuxer that gives the highest probe score.  If a demuxer only matches by extension then it is supposed to give a fairly low score.
[18:53:19 CEST] <nevcairiel> no, if anything the extension only decides the demuxer, and the demuxer decides the decoder based on the file contents
[18:53:37 CEST] <nevcairiel> although many times files are actually probed for a magic number instead of extension based matching
[18:54:23 CEST] <FishPencil> nevcairiel: Where is the demuxer decided from the extension?
[18:55:03 CEST] <nevcairiel> somewhere in libavformat? :) probably utils.c, if I have to look it up, so can you =p
[18:55:57 CEST] <iive> probe is the used term, and i think the function had it in its name
[18:56:57 CEST] <iive> as J_Darnley  said, the type is decided by content first, and if the content is not definitive enough, then the extension could be used in the mix.
[18:57:29 CEST] <ZeroWalker> nevcairiel, it is? doesn't the "i" makes it, non-P ?
[18:57:34 CEST] <iive> e.g. mpeg video and mp3 share same format 
[18:57:47 CEST] <nevcairiel> ZeroWalker: we dont have separate raw formats for interlaced or progressive
[18:58:13 CEST] <nevcairiel> the "p" stands for planar, not progressive
[18:58:18 CEST] <ZeroWalker> ah my bad, meant
[18:58:22 CEST] <ZeroWalker> interleaved/planar
[18:58:46 CEST] <nevcairiel> The only I420 I know is  planar
[18:58:55 CEST] <nevcairiel> like YV12 just without flipped U/V planes
[18:59:02 CEST] <J_Darnley> FishPencil: if you want to modify a demuxer, first start by locating the file that contains the definition of it.
[18:59:19 CEST] <ZeroWalker> but wait, isn't yuv420p == YV12
[18:59:37 CEST] <nevcairiel> almost but not  quite
[18:59:46 CEST] <nevcairiel> YV12 has the u/v planes in a different order then yuv420p
[19:00:07 CEST] <J_Darnley> yuv420p == I420
[19:00:20 CEST] <ZeroWalker> so what is YV12 in ffmpeg?
[19:00:27 CEST] <nevcairiel> nothing
[19:00:35 CEST] <nevcairiel> take yuv420p and flip data pointers
[19:00:41 CEST] <J_Darnley> We don't have one.  We have the planes in the "correct" order
[19:01:14 CEST] Action: J_Darnley goes afk
[19:01:18 CEST] <ZeroWalker> ah, not sure how to flip them, but i guess it's the [4] array thing?
[19:01:43 CEST] <ZeroWalker> that's good to know, i always thought YUV420P was YV12 (cause, it's yuv, 420 and planar), but it's not that easy xd
[19:01:56 CEST] <ZeroWalker> so is NV12 the same as i420?
[19:02:09 CEST] <iive> no
[19:02:14 CEST] <iive> nv12 is mixed format
[19:02:27 CEST] <iive> it has 2 planes. One pure Y (luminance)
[19:02:43 CEST] <iive> and a second with interleaved UV (chroma)
[19:02:50 CEST] <nevcairiel> we do have a separate NV12 format =p
[19:02:53 CEST] <ZeroWalker> ah
[19:02:57 CEST] <ZeroWalker> oh xd
[19:03:06 CEST] <ZeroWalker> but why are there so many different formats for the same thing?
[19:03:09 CEST] <ZeroWalker> or am i missing something
[19:03:50 CEST] <iive> inteleaved format are more useful for presentation
[19:04:10 CEST] <iive> because you have all the data in one read block.
[19:04:26 CEST] <ZeroWalker> ah, so this is why you often have to use planar in say, avisynth?
[19:05:21 CEST] <iive> planars are easier for software decoding, because their blocks are by separate colors/planes
[19:06:22 CEST] <iive> nv12 is compromise, since uv usually are of the same size and threated in the same way. 
[19:06:53 CEST] <ZeroWalker> wait, so when you say presentation, you don't mean decoding it?
[19:07:12 CEST] <iive> no, i mean turning it into rgb and output to monitor
[19:07:25 CEST] <ZeroWalker> isn't that what decoding is?
[19:07:57 CEST] <iive> decoder turns compressed bitstream into yuv pictures
[19:08:22 CEST] <ZeroWalker> ah thought you meant, Decoding the raw data to rgb or something, then i get it
[19:09:24 CEST] <ZeroWalker> hmm, so how is that other format related, ybcpr (or something?). Think i remember reading that it was able to somehow losslessly convert between RGB and itself
[19:09:41 CEST] <iive> when i say presentetion, this also could include the video card hardware.
[19:10:27 CEST] <ZeroWalker> ah okay
[19:11:02 CEST] <iive> in the past overlays did the yuv->rgv in hardware, so having all the data in one place made things easier for them.
[19:11:37 CEST] <iive> cr cb the official standard nams for U V, they are color differentials.
[19:11:49 CEST] <ZeroWalker> is this like that "Overlay mixer" thing in Windows?
[19:12:05 CEST] <iive> to reg and blue i think.
[19:12:07 CEST] <ZeroWalker> oh so they are the same
[19:13:03 CEST] <iive> yes, overlay is a special trick, unfortunately having more than one at a time is very tricky.
[19:14:16 CEST] <ZeroWalker> oh, how so, doesn't it just take the data and convert it, would think it was a straightforward thing
[19:14:53 CEST] <iive> it does it on the fly.
[19:15:18 CEST] <ZeroWalker> so it has no clue on the source or something?
[19:15:33 CEST] <iive> the overlay is like a second desktop, that is visible only when a specific key color is present on the first fron desktop
[19:15:55 CEST] <iive> fron/front
[19:16:20 CEST] <ZeroWalker> oh, had no clue, thought it was like a renderer
[19:16:47 CEST] <iive> then something like another dac is used that access a second memory region. the dac does the yuv->rgb conversion.
[19:17:19 CEST] <iive> renders usually convert the color into new texutre and then blit it on command.
[19:17:53 CEST] <iive> anyway... that's now video card ancient history.
[19:18:39 CEST] <ZeroWalker> sounds like quite procedure o.o
[19:18:55 CEST] <ZeroWalker> so now it's just handled by the gpu, feed yuv get rgb?
[19:19:08 CEST] <iive> yeh, let the shaders do the work.
[19:20:02 CEST] <ZeroWalker> nice, well don't have much experience with shaders, never really understood how you can use them to convert between colorspaces, as i thought pixelshaders were, per pixel
[19:20:41 CEST] <iive> you read 3 values, you use the formulas, you get 3 results.
[19:20:43 CEST] <JEEB> if you are interested mpv has plenty of stuff in opengl shaders
[19:20:57 CEST] <JEEB> tone mapping, colorspace conversions, scaling
[19:22:22 CEST] <ZeroWalker> ah interesting, will have to give it a look. Is that something to prefer even in ffmpeg, or is the cost too large
[19:24:45 CEST] <JEEB> it would be interesting to see how performant those things would be in ffmpeg use cases
[19:25:10 CEST] <JEEB> but nobody has had the interest to kmplement gpu upload / download or the filters
[19:31:36 CEST] <ZeroWalker> ah thought it was something well known. As i know that it's expensive if you have things on the CPU to than let the GPU handle it (compared to if the GPU had the source to begin with). But have no clue when it would be worth that cost, would imagine it being on very large sources (but what do i know;p)
[19:33:27 CEST] <Blubberbub_> i would expect some speedup for some filters - but one would need to reimplement everything for the gpu. And for chaining filters one would need to make sure to not copy the data all the time
[19:45:27 CEST] <iive> JEEB: i thought that some filters do opencl
[19:59:51 CEST] <JEEB> iive: yes there's opencl filters in FFmpeg but nobody knows if they're actually useful or faster than something on the CPU
[20:35:52 CEST] <RiCON> last time i tried them, they were a bit faster
[20:36:50 CEST] <RiCON> 130fps vs 240fps with an amd 7870
[20:37:16 CEST] <JEEB> what sort of filter did you use?
[20:37:19 CEST] <RiCON> unsharp
[20:37:55 CEST] <RiCON> didn't test too hard, just a single run w/o filter, w/ filter then w/ filter and opencl
[20:39:49 CEST] <RiCON> the only other opencl-enabled filter is deshake
[20:46:58 CEST] <ZeroWalker> hmm, so if i try to convert my i420 source by just feeding the raw buffer as &pointer. and av_image_fill_linesizes for the linesize, the source is basically green
[20:47:09 CEST] <ZeroWalker> so i guess some plane is flipped or something;d
[20:48:22 CEST] <ZeroWalker> oh wait could just use the fill pointers
[21:06:49 CEST] <J_Darnley> Green sounds like you're passing in zeros as the chroma
[21:17:58 CEST] <ZeroWalker> well it probably just got the wrong place as using the fill_pointers solved it. i jsut gave it the main buffer and hoped for the best before it
[21:18:30 CEST] <ZeroWalker> also, the align thing, if you set it to 1, will it cause performance loss even if the data can be aligned to like 32 or something
[21:23:06 CEST] <J_Darnley> I don't know the answer to that.
[21:23:26 CEST] <J_Darnley> I would assume that ffmpeg would copy it into an aligned buffer at some point.
[21:24:02 CEST] <J_Darnley> Many parts of ffmpeg need alignment and assume a buffer to be aligned.
[21:25:51 CEST] <kepstin> i remember seeing someone having issues recently when they used the crop filter, which unaligned the buffer, then ran the result through another filter that expected aligned data :/
[21:26:32 CEST] <J_Darnley> I remember that story too but didn't pay much attention to it.
[21:52:31 CEST] <thardin> is there a way to suppress "Estimating duration from bitrate, this may be inaccurate"? it is 100% accurate in the case I'm poking with
[21:53:30 CEST] <nevcairiel> then calculate it  yourself and set a duration in the demuxer
[21:53:37 CEST] <nevcairiel> the generic code cannot know
[21:53:58 CEST] <thardin> hum-hum.. I don't know the bitrate in read_header
[21:54:10 CEST] <thardin> or I *could*, I just have to open the codec real quick
[22:03:10 CEST] <ZeroWalker> hmm, that might be problematic as it can't ensure the size, though, i guess i could enforce at least align by 4 as that's needed for YV12 anyway, i think
[23:29:29 CEST] <dcherednik> Hi. I am wondering. What is the expected maximum value of input coefficients for AAC psychoacoustic?
[00:00:00 CEST] --- Wed Aug  2 2017