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

[burek]

[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=463b81de2b252691d75417643597c42684bf830d
[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