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.
> 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