On Fri, 23 Sep 2016 19:46:16 +0200 Stefano Sabatini <stefa...@gmail.com> wrote:
> On date Friday 2016-09-23 09:34:19 +0200, wm4 encoded: > > On Thu, 22 Sep 2016 18:50:27 +0200 > > Stefano Sabatini <stefa...@gmail.com> wrote: > [...] > > > Ping. I'd like to commit this if there are no objections. Also, > > > possibly add a muxer to generate output directly readable by the > > > demuxer (this way we don't need ffprobe for generating the output, and > > > we avoid the ordering issue). > > > > I'm sorry to jump in as a nay-sayer, but it looks like a quite fishy > > concept and I still don't get why it's supposed to be needed. The > > documentation also doesn't say what this is supposed to be useful for. > > I'll extend the documentation to add some possibly useful use cases. > > My use case: I need to build a data stream with scripting/manual > editing. Since I don't want to have to rely on a binary format (which > is not ideal for that use case) I needed a format simple enough to be > written and analysed without special tools, but with a simple text > editor. I still don't get it. Your description makes me think of something like EDL, but that doesn't seem to have anything to do with it. > Also, if coupled with a muxer it allows to create an output, tweak it > (e.g. to change the timestamps) and feed it to FFmpeg, which might be > useful from time to time to test/debug specific features. > > The alternative might be to build a tool for converting to > custom-format to a "binary" format accepted by FFmpeg, but I want > to avoid the need for an additional tool. > > This format is my second attempt after the fftextdata format, which > was regarded too limited. This one is based on the ffprobe default > output (although it's simplified). > > > It's also potentially a security issue (lots of text parsing, and can > > construct inputs which might be tricky for API users). > > > > I probably can't stop you from pushing this, but at least it shouldn't > > be enabled by default. > > I understand the security concerns, and I have no objections against > disabling this by default if developers prefer this way. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel