[FFmpeg-devel] [PATCH 5/5] src_movie: implement multiple outputs.

Stefano Sabatini stefasab at gmail.com
Mon Jul 23 16:10:37 CEST 2012


On date Monday 2012-07-23 13:42:52 +0200, Nicolas George encoded:
> Le sextidi 6 thermidor, an CCXX, Stefano Sabatini a écrit :
> > A stream spec may contain a program_id or a stream_id, I don't know if
> > they could contain the '+' character.
> 
> They are integers too, for the moment at least.
> 
> > I suppose for the moment we can keep '+' and de-escape the spec list
> > in case of need (e.g. by using av_get_token() instead of av_strtok()).
> 
> We can change that if it actually becomes necessary, since it requires more
> code (malloc checking).
> 
> > (Unrelated note, may be useful to match the language of the stream in
> > case it is specified).
> 
> I agree. In fact, any kind of metadata matching would be nice.
> 
> > doxy may help
> > and here
> > and here too
> 
> Added.
> 
> > >         av_log(log, AV_LOG_WARNING, "Stream specifier \"%s\" %s\n", spec,
> > >                already ? "matched only already used streams" :
> > matched only by already used stream?
> 
> I believe we usually say that a stream specifier matches a stream (or a
> regexp matches a string), not the other way around.
> 
> > nit++: drop the final dot, should be more consistent with most libav* messages
> 
> Done.
> 
> > Also since this is a PAWE, maybe: "Loop with several streams is currently unsupported"
> 
> Adopted.
> 
> > can be simplified with the newly added avfilter_get_buffer_ref_from_frame()
> 
> Indeed.
> 
> > *to* the requested output.
> 
> Fixed.
> 
> > >     if (!ret)
> > >         ret = pkt->size;
> > why this?
> 
> Some video decoders return 0 for success instead of the number of used
> bytes.
> 
> > &movie->pkt == pkt?
> > In this case is less confusing to use just pkt->size consistently.
> 
> Changed.
> 
> New version attached.
> 
> 
> > Unrelated, and feel free to not reply, I wonder how we should specify
> > the options for the codec/format (this is especially relevant for a
> > sink movie with multiple inputs). We could specify the options using
> > an AVDictionary -> string serializer (like implemented in a recent
> 
> (about that patch, I believe it has not yet been pushed)
> 
> > patch), but then we need to specify the stream/format to which the
> > options apply.
> > 
> > A possibility would be to apply stream specifier to options, for
> > example:
> > movie=a=1:v=1:
> > fopts='probesize=1M, cryptokey=0xdeadbeef':
> > copts='codec:a0=rawaudio, sample_fmt:a=u8, codec:v0=rawvideo, pix_fmt:v0=rgb24'
> 
> Using stream specifiers would be a good idea, especially since this is
> consistent with what ffmpeg does.
> 

> OTOH, requiring the user to know the difference between a format option and
> a stream option is not very practical. Especially since that difference may
> be tricky: pix_fmt, for example, is actually an option of the rawvideo
> format, not a stream option.
>
> The best course of action is IMHO to do like ffmpeg: take all options
> together and be smart about what they apply too. Due to the way the API is
> done, this may not be too complicated: if we have the options in a dict, I
> believe this would work:
> 
>   avformat_input_file(..., &dict);
>     /* takes the format options, leaves what it does not know */
>   avformat_find_stream_info(..., &dict); /* idem */
>   for (all selected streams) {
>       dict2 = filter_by_stream_specifier(dict);
>       avcodec_open2(..., dict2);
>   }
> 

> An additional bonus of doing that is that it does not require a second round
> of escaping: the options can be inserted flatly into the movie argument.

Example? I believe this would require a movie option anyway, something
along the lines:
movie=in.avi:v=2:a=1:opts=...

[...]

No more comments from me, thanks.
-- 
FFmpeg = Furious and Frenzy Mastering Powered Elitarian Game


More information about the ffmpeg-devel mailing list