[02:16:55 CEST] <cone-376> ffmpeg 03Michael Niedermayer 07master:f762555a9079: avformat/mxfenc: Replace literal numbers by named enum values. [11:27:08 CEST] <cone-221> ffmpeg 03Timo Rothenpieler 07master:1ac03c8dc0a9: configure: add support for libnpp* from cuda sdk 9 [11:27:09 CEST] <cone-221> ffmpeg 03Ricardo Constantino 07master:7fbc0825773e: compat/cuda/ptx2c: strip CR from each line [11:29:23 CEST] <wbs> if anybody cares; I see a lot of discussion around handling and parsing of dash segment file template handling, and potential exploitability around that and so on [11:29:35 CEST] <wbs> ... there's already code that does that, that should be pretty ok, in dashenc.c [11:29:57 CEST] <wbs> so instead of reinventing the wheel, that could be reused/shared, so there's at least a single set of common vulnerabilities, instead of two different sets [11:33:13 CEST] <BtbN> I'm pretty sure dashenc does not parse dash segments. [11:33:24 CEST] <BtbN> it only writes them, which is far more trivial [11:34:09 CEST] <BtbN> dashdec needs a full xml parser though [11:34:24 CEST] <wbs> no, that's not what they are arguing about [11:35:23 CEST] <wbs> within the dash spec, there's a feature that you can have segment names in the form segment-$Bandwidth03d$-$Time$.m4s [11:35:40 CEST] <wbs> so a dash demuxer needs to interpret this and plug in values for bandwidth and time to find the file name to request [11:35:57 CEST] <wbs> now, the dash muxer also has support for this; the user can provide the pattern to use, so the muxer writes filenames in the given pattern [11:36:19 CEST] <BtbN> In that case, the pattern is given on the ffmpeg commandline though. [11:36:32 CEST] <wbs> so? [11:36:42 CEST] <wbs> my point is, there is an exact piece of code that does exactly this [11:36:42 CEST] <BtbN> In the other case, it's given in the file itself. And you don't ever put format strings from input data into the printf family. [11:36:47 CEST] <BtbN> That's a security vulnerability. [11:36:50 CEST] <wbs> exactly [11:37:07 CEST] <BtbN> So there is no issue there in dashenc, as it's not parsing input data. [11:37:16 CEST] <wbs> ... so? [11:37:22 CEST] <wbs> there is code there already, without known vulnerabilities [11:37:23 CEST] <BtbN> ? [11:37:36 CEST] <BtbN> The code in dashenc is vastly different. [11:37:46 CEST] <BtbN> It does a whole diffrent job [11:37:49 CEST] <wbs> dash_fill_tmpl_params [11:38:09 CEST] <wbs> does exactly the same thing that the demuxer needs to do [11:38:23 CEST] <wbs> given a format string and the provided numbers, expand the format string [11:38:33 CEST] <wbs> without blindly passing the string into printf or something like that, that would be insane [11:38:43 CEST] <JEEB> :) [11:38:50 CEST] <wbs> yes, with the muxer, the only attack vector would be the command line user passing a weird option [11:39:01 CEST] <wbs> but despite that, I don't think there is any such vulnerability in the existing code in dashenc [11:39:14 CEST] <BtbN> Yeah, that function does indeed look very reusable [11:39:37 CEST] <wm4> the dash patch also duplicates some nasty code from hls [11:39:38 CEST] <wbs> and there's this huge argument on the mailing list, about how the reimplementation of this exact function should be, with or without potential vulenrabilities [11:39:50 CEST] <wm4> like trying to open segments with correct cookies/useragent [11:39:54 CEST] <BtbN> well, have you told them about the existence of that function? [11:40:03 CEST] <wm4> or this awful "security" bullshit that checks protocol names [11:40:03 CEST] <wbs> I have not, and I'm not going to enter into that mailing list thread [11:40:20 CEST] <wbs> if you care, you can point the masses to this function in dashenc.c, if not, let them keep arguing [12:21:00 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:61e4db4bb730: Add FITS Decoder [12:21:01 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:207f0cff2ac8: Add FITS Demuxer [12:21:02 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:6e02f66f1bc7: Add FITS Encoder [12:21:03 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:df475db9a29e: Add FITS Muxer [12:21:04 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:9d99f0afbeed: FATE: Add FITS tests [12:21:05 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:a4d18a3f54e5: avfilter/vf_lut2: add framesync options [12:21:06 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:2b9fd157342f: avcodec/codec_desc: make FITS description longer [12:52:10 CEST] <arpu> a ffmpeg -re -stream_loop -1 -i testme.flv -c:v copy -an -f flv "rtmp://..." alwys stops after the eos of the file is reached with av_interleaved_write_frame(): Broken pipe [12:52:59 CEST] <arpu> verbose output http://lpaste.net/7901301616186228736 [12:53:08 CEST] <arpu> is this a bug? or i do something wrong? [14:07:55 CEST] Action: JEEB appreciates wm4's http://git.videolan.org/?p=ffmpeg.git;a=commit;h=463b81de2b252691d7541764359... [14:09:18 CEST] <wm4> amusingly it got already broken by the float pixfmt additions [14:09:26 CEST] <JEEB> :D [14:09:49 CEST] <nevcairiel> how so? at least binary 0 is also float 0 :d [14:10:06 CEST] <nevcairiel> or are those yuv floats [14:10:11 CEST] <JEEB> I guess float YCbCr [14:11:09 CEST] <wm4> float are 4 bytes per component [14:11:18 CEST] <wm4> the code can handle only 2 bytes per component [14:11:46 CEST] <wm4> also, half-range yuv doesn't use 0 [15:24:19 CEST] <cone-221> ffmpeg 03Ashish Singh 07master:2a4a26fa4f3c: avfilter/vf_libvmaf: fix pre convert to framesync2 bugs [15:24:20 CEST] <cone-221> ffmpeg 03Ashish Singh 07master:1dc33c123715: configure: require pkg-config for libvmaf [15:33:11 CEST] <kierank> vis_mb_type is broke [15:48:26 CEST] <durandal_1707> kierank: isnt that done with codecview? [16:23:59 CEST] <kierank> durandal_1707: no [16:24:02 CEST] <kierank> mv is codecview [16:58:43 CEST] <JEEB> so do I see correctly that the AAC encoder could in theory handle !1024 nb_sample AVFrames since it has its own internal ff_af_queue, but the audio encoding framework requires AVFrame->nb_samples to be exactly AVCodecContext->frame_size? [16:59:24 CEST] <atomnuker> no [17:00:25 CEST] <JEEB> ok [17:00:43 CEST] <atomnuker> the afq only does packet timestamps and is sometimes used to calculate the last frame's skip samples [17:00:52 CEST] <atomnuker> (on some encoders) [17:01:15 CEST] <atomnuker> so its not a queue for the actual samples but for keeping track of the numer of samples in and out [17:01:43 CEST] <JEEB> ok [17:01:57 CEST] <JEEB> also there's that copy_input_samples thing, which seems to be some sort of a buffer [17:02:02 CEST] <JEEB> will have to see how big it is etc [17:02:14 CEST] <JEEB> ok [17:02:15 CEST] <JEEB> s->planar_samples[ch] = s->buffer.samples + 3 * 1024 * ch; [17:02:17 CEST] <JEEB> so yea [17:02:32 CEST] <JEEB> I will need to cut AVFrames from decoder/filtering to fit the nb_frames [17:02:51 CEST] <JEEB> somehow I hadn't cut myself with this yet [19:10:02 CEST] <cone-221> ffmpeg 03James Almer 07master:350dc01dcb80: fate: remove usage of deprecated AVCodecContext.me_method in vsynth snow tests [19:16:13 CEST] <cone-221> ffmpeg 03James Almer 07master:ec07574a15ba: fate: stop using deprecated filter syntax in hls tests [19:36:53 CEST] <cone-221> ffmpeg 03James Almer 07master:f7d4c60ac475: avfilter/vf_mcdeint: free the AVCodecContext struct properly [19:45:28 CEST] <cone-221> ffmpeg 03James Almer 07master:2b7da70a70fe: postproc: remove usage of deprecated QP_STORE_T define [20:26:37 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:6ccd32c36760: avfilter/af_adelay: remove requirement that at least one delay should be provided [00:00:00 CEST] --- Thu Aug 31 2017