On Thu, 22 Sep 2016 18:50:27 +0200 Stefano Sabatini <stefa...@gmail.com> wrote:
> On date Sunday 2016-09-18 15:28:45 +0200, Stefano Sabatini encoded: > > On date Saturday 2016-09-17 18:42:35 +0200, Paul B Mahol encoded: > > > On 9/17/16, Stefano Sabatini <stefa...@gmail.com> wrote: > > > > On date Sunday 2016-09-04 23:25:56 +0200, Michael Niedermayer encoded: > > > >> On Sun, Sep 04, 2016 at 06:24:37PM +0200, Stefano Sabatini wrote: > > > >> > From: Nicolas George <geo...@nsup.org> > > > >> > > > > >> > With several modifications and documentation by Stefano Sabatini > > > >> > <stefa...@gmail.com>. > > > >> > > > > >> > Signed-off-by: Nicolas George <geo...@nsup.org> > > > >> > --- > > > >> > doc/ffprobe-format.texi | 130 ++++++++++++++++ > > > >> > libavformat/Makefile | 1 + > > > >> > libavformat/allformats.c | 2 + > > > >> > libavformat/ffprobedec.c | 397 > > > >> > +++++++++++++++++++++++++++++++++++++++++++++++ > > > >> > 4 files changed, 530 insertions(+) > > > >> > create mode 100644 doc/ffprobe-format.texi > > > >> > create mode 100644 libavformat/ffprobedec.c > > > >> > > > >> this seems not to apply cleanly > > > >> > > > >> can i pick this from some git repo ? (should work better than patch > > > >> with unavailable ancestors) > > > > > > > > Updated, this should apply cleanly on master. > > > > > > Why we need this hack? > > > > My use case: I need to inject a metadata stream using the ff* > > tools. Metadata must be specified in a textual format. I already > > designed and implemented the fftextdata format, but that was regarded > > too limited. > > > > Example: > > ffmpeg -i input.mp4 -copyts -i data.ffprobe -map 0:v -map 0:a -map 1:0 > > -codec:d copy input+data.ts > > > > With this format we allow to cover my use case, and it provides a more > > generic format for such purposes (since you can specify multiple > > streams). Also, it's inspired by the ffprobe output, so it can be used > > together with ffprobe (via simple text editing) to generate files > > which can be edited and feed to ffmpeg. > > > > It would be possible to use any binary format for injecting the > > metadata, but this approach is not very scriptable. Alternatively a > > custom program to convert a custom textual format to any binary format > > we support, but this would imply an additional step I want to avoid. > > > > That said, if someone want/can propose an alternative path to this I'm > > very open to suggestions. > > 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. 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
