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

[burek]

[01:48:24 CEST] <durandal_1707> why is overlay code so extremly convoluted?
[02:50:53 CEST] <cone-162> ffmpeg 03Michael Niedermayer 07master:2793ebd6cb8e: avformat/hlsenc: implement program_date_time
[04:35:07 CEST] <philipl> BtbN: vp9-in-mkv content is getting mangled by cuvid because the timebase is "0/1", so the pts values get wiped out during the rescale.
[04:35:54 CEST] <philipl> same for vp8
[04:36:36 CEST] <philipl> I've also got some hevc mkvs with 0/1.
[04:41:52 CEST] <philipl> I don't think avctx->time_base can actually be trusted for mkv content...
[04:46:21 CEST] <philipl> What's the rationale for rescaling? Certainly their use of a long long means it'll hold whatever pts value we have.
[04:47:25 CEST] <philipl> In the crystalhd code, where I had a real problem with the hardare mangling pts values, I ended up implementing a separate pts queue and putting token values into the frames and then matching up the real pts later.
[09:00:35 CEST] <tmm1> i'm trying to work up a patch to fix https://trac.ffmpeg.org/ticket/5677 and could use a second pair of eyes from someone who understands h264 nal/sei format
[09:01:17 CEST] <tmm1> seems i have an off-by-one somewhere, since I see "SEI type 4 size 568 truncated at 567" when decoding my generated h264 file
[09:02:42 CEST] <tmm1> http://paste.ubuntu.com/23149072/ is patch, i'm guessing the bug is in vtenc_cm_to_avpacket() around line 138 of the diff
[09:47:54 CEST] <jkqxz> tmm1:  Who is meant to be doing the emulation prevention there?  What about adding the RBSP trailing bits?  (Either of those could easily give you an off-by-one in size.)
[09:49:18 CEST] <BtbN> philipl, yes, Weave is documented as "do nothing"
[09:49:30 CEST] <BtbN> a decoder which deinterlaces seemed weird
[09:49:42 CEST] <BtbN> adding an option to enable it wouldn't be too terrible though
[09:52:02 CEST] <durandal_1707> why? It does nothing
[09:53:54 CEST] <davy> hello
[09:54:13 CEST] <BtbN> durandal_1707, well, it supports more than just Weave, which does something then.
[09:54:29 CEST] <BtbN> Weave is the disabled state
[09:54:44 CEST] <BtbN> BOB or Motion-Adaptive would be an enabled one
[09:55:10 CEST] <davy> I'm having an issue opening https streams with avformat_open_input, where I'm getting the following error:
[09:55:15 CEST] <davy> * https @ 0x1287f1fe0] Setting default whitelist 'http,https,tls,rtp,tcp,udp,crypto,httpproxy'( [tls @ 0x128b57550] error:140A90F1:SSL routines:SSL_CTX_new:unable to load ssl2 md5 routines(
[09:55:24 CEST] <BtbN> first: wrong channel
[09:55:39 CEST] <davy> which channel then?
[09:55:42 CEST] <BtbN> second: your OpenSSL is built with sane presets, which disable SSL2 (and possibly SSL3)
[09:55:57 CEST] <BtbN> And the server is ancient, requiring SSL2
[09:56:12 CEST] <BtbN> So, complain to the server hoster.
[09:58:02 CEST] <davy> when building ffmpeg, how can I tell which version of openssl it's using
[09:58:22 CEST] <davy> also, the server im using does not support ssl2 according to this report: https://www.ssllabs.com/ssltest/analyze.html?d=bffdotfm.s3.amazonaws.com
[09:58:24 CEST] <davy> nor ssl3
[09:58:56 CEST] <davy> it seems like ffmpeg is trying open the endpoint with ssl2...which is incorrect
[10:03:47 CEST] <tmm1> jkqxz: thanks, this is my first time looking at the h264 stream format so that's very helpful
[10:04:02 CEST] <tmm1> i added a RBSP at the end and that seems to have fixed it
[10:04:36 CEST] <tmm1> i'm not sure about emulation prevention.. i suppose i probably need to do it. are there any helpers in ffmpeg i can use to do the replacement?
[10:57:23 CEST] <cone-610> ffmpeg 03Paul B Mahol 07master:8cfe60ef3933: doc/filters: itemize shuffleframes & shuffleplanes examples
[10:57:23 CEST] <cone-610> ffmpeg 03Paul B Mahol 07master:ae31ab807001: avfilter/vf_shuffleframes: unbreak filter
[11:13:13 CEST] <jkqxz> tmm1:  I don't think there is a standard one.  I wrote <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h26x.c;hb=HEAD> to do it.
[11:14:32 CEST] <jkqxz> tmm1:  How big can your SEI block be?  You want to implement the size encoding properly if it can ever be bigger than 255 bytes.
[11:16:53 CEST] <cone-610> ffmpeg 03Paul B Mahol 07master:26a19f8e9278: fate: add shuffleframes test
[11:39:47 CEST] <cone-610> ffmpeg 03Sergey Volk 07master:347cb14b7cba: avformat/mov: Fix potential integer overflow in mov_read_keys
[13:33:42 CEST] <ubitux> michaelni: how do you see moving the time_base/ticks_per_frame copy heuristics from ffmpeg into lavf (where it is actually legit to use AVStream->internal->avctx)?
[13:33:57 CEST] <ubitux> can we avoid adding any public symbol?
[13:34:11 CEST] <JEEB> sounds a not-so-bad idea
[13:37:34 CEST] <ubitux> michaelni suggested that yesterday, but i didn't realize that it would actually solve the st->codec access
[13:37:52 CEST] <ubitux> so now i'm trying to see how it could fit
[13:38:31 CEST] <ubitux> like, there is nothing -afaik- in lavf that put into relationship two streams
[13:38:50 CEST] <ubitux> like, avformat_stream_copy_params or whatever
[13:38:57 CEST] <ubitux> doing "smart" things
[13:49:22 CEST] <michaelni> ubitux, whatever works and you like iam fine with
[13:49:57 CEST] <ubitux> i'm questioning if you see a way of not adding a symbol but have it implicitely done in another existing function of the api
[13:51:41 CEST] <ubitux> like, maybe at the creation/init of the output format/stream we could have an extra parameters such as an input format/stream
[13:55:39 CEST] <michaelni> ubitux, its sure possible without a new symbol but i cannot think of a way thats not ugly
[13:55:57 CEST] <michaelni> i dont think we should add more ugly code
[13:57:07 CEST] <ubitux> ok well then, if the proper way is to add a new symbol, it would be nice if it actually helps ffmpeg CLI as most as possible, as if it was a real user and not a way for us to move around hacks
[13:57:25 CEST] <ubitux> so let's ask the question: what function would be the most useful one?
[13:57:51 CEST] <michaelni> enable_world_peace() 
[13:58:32 CEST] <Shiz> lol
[13:58:37 CEST] <ubitux> av_stream_copy(AVStream *dst, const AVStream *src, enum AVTimingPolitic tp)?
[13:59:00 CEST] <ubitux> should it be at format level instead? (and risking pulling many things from ffmpeg cli)
[14:01:01 CEST] Action: michaelni wonder is AVStream should get a pointer to its parent AVFormatContext, quite off topic but it could simplify quite some code maybe
[14:02:04 CEST] <michaelni> wonderS iF
[14:10:24 CEST] <Shiz> >avtimingpolitic
[14:10:26 CEST] <Shiz> que
[14:13:12 CEST] <ubitux> ;)
[14:13:20 CEST] <ubitux> i didn't know how to name it
[14:13:27 CEST] <ubitux> it's basically about that "copy tb" thing
[14:14:33 CEST] <ubitux> maybe, enum AVTimebaseCopyFrom { AVTBCF_AUTO, AVTBCF_DEMUXER, AVTBCF_DECODER }
[14:14:49 CEST] <ubitux> (and something for the value=2 which i don't know wtf it means
[14:14:51 CEST] <ubitux> )
[14:15:44 CEST] <ubitux> AVTBCF_R_TIMEBASE probably
[14:16:10 CEST] <ubitux> (but works only for avi currently)
[14:26:40 CEST] <Chris2A> hello there !
[14:26:50 CEST] <Chris2A> Is there anyone interested in building an ffmpeg module for an Android project ?
[14:27:26 CEST] <Chris2A> Oh sorry it's off topic here
[15:39:56 CEST] <Shiz> ubitux: maybe AVTimebaseSource ?
[15:40:16 CEST] <ubitux> fine with me
[15:59:25 CEST] <mateo`_> michaelni: regarding the gb->buffer_end - gb->buffer overflow, would something like this http://sprunge.us/NLXi better ?
[16:02:23 CEST] <michaelni> mateo`_, yes
[16:02:53 CEST] <ubitux> isn't the check is redundant?
[16:03:25 CEST] <ubitux> we will hopefully never get sizeof(vps->data)>INT_MAX :p
[16:03:46 CEST] <mateo`_> oh right ...
[16:29:42 CEST] <iive> could nal_size become negative? e.g. overread?
[17:39:05 CEST] <ubitux> mmh, in the end i think it makes sense to actually have that timebase and ticks_per_frame inside codecpar
[17:41:39 CEST] <ubitux> because even if i'm introducing sth like avformat_stream_apply_codec_parameters(), you don't want to pass the codec context but only its parameters
[17:42:15 CEST] <ubitux> all you want in the end is copy the codec parameters from the input stream to the other
[17:42:59 CEST] <ubitux> (in the practical case, the decoder context might disappear or might be unrelated to the input stream)
[17:43:05 CEST] <ubitux> (input* decoder context)
[18:31:42 CEST] <durandal_1707> Anyone needs highbitdepth support for overlay filter?
[18:33:57 CEST] <jamrial> durandal_1707: imo what needs high bit depth support the most is w3dif
[18:34:26 CEST] <durandal_1707> interlace must die
[18:35:58 CEST] <durandal_1707> highbitdepth interlace is, what to say, I can't find proper word
[18:37:45 CEST] <jkqxz> You would condemn such files to never be deinterlaced, such that interlaced video lives on forever?
[18:57:16 CEST] <BtbN> this nvenc crash is weird
[18:57:28 CEST] <BtbN> it shouldn't crash, even when copying the full 1088 instead of 1080 lines
[19:08:44 CEST] <cone-957> ffmpeg 03Timo Rothenpieler 07master:8ebe1dddfb5a: avcodec/nvenc: use frame size instead of surface size
[20:48:33 CEST] <cone-957> ffmpeg 03Michael Niedermayer 07master:837e72b01608: avcodec/alsdec: Fix mlz memleak
[20:48:35 CEST] <cone-957> ffmpeg 03Michael Niedermayer 07master:f2192e0f0399: avcodec/alsdec: Fix raw_mantissa memleak
[20:48:36 CEST] <cone-957> ffmpeg 03Michael Niedermayer 07master:2f7a12fab5a2: avcodec/mlz: clear dict on allocation to ensure there are no uninitialized values
[20:48:36 CEST] <cone-957> ffmpeg 03Michael Niedermayer 07master:c0fc83ed41ed: avcodec/mlz: Check offset before writing
[21:39:02 CEST] <philipl> BtbN: any thoughts on the pts rescaling?
[22:23:52 CEST] <cone-957> ffmpeg 03Michael Niedermayer 07master:2d3099ad8ee6: avcodec/svq3: Reintroduce slice_type
[22:23:53 CEST] <cone-957> ffmpeg 03Michael Niedermayer 07master:037422178d7f: avcodec/alsdec: Fix reading 0 mantisse bits
[00:00:00 CEST] --- Fri Sep  9 2016