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). -- FFmpeg = Fundamental and Fundamental Mere Ponderous Elastic Gargoyle _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel