[FFmpeg-devel] RFC: flag rawvideo input as interlaced
Michael Niedermayer
michaelni at gmx.at
Mon May 16 01:10:11 CEST 2011
On Mon, May 16, 2011 at 12:08:24AM +0200, Stefano Sabatini wrote:
> On date Sunday 2011-05-15 19:47:26 +0100, Mark Himsley encoded:
> > Moved from FFmpeg-user:
> >
> > On 14/05/2011 18:46, Stefano Sabatini wrote:
> > > On date Saturday 2011-05-14 18:20:02 +0100, Mark Himsley encoded:
> > >> On 14/05/2011 10:26, Stefano Sabatini wrote:
> > >>> On date Thursday 2011-05-12 17:07:09 +0100, Mark Himsley encoded:
> > >>> [...]
> > >>>> Anyway...
> > >>>>
> > >>>> What I need is a way to flag rawvideo media when its used as an
> > >>>> input into ffmpeg. Anyone?
> > >>>
> > >>> Mark, did you try with -top?
> > >>
> > >> Hi Stefano,
> > >>
> > >> Yes. Sorry, I should have said that -top was my first guess, but your
> > >> showinfo filter says the rawvideo file is flagged as progressive when I
> > >> have -top 1 in the input files settings.
> > >
> > > Yes, check ffmpeg.c:do_video_out, top_field_first is used for setting
> > > the field type *just before encoding*.
> > >
> > > I wonder what could be a better approach, maybe we could implement a
> > > setprops filter for changing the properties of the video in the
> > > filterchain, and drop -top from ffmpeg.c.
> > >
> > > What do you think of this idea?
> >
> > Your 'setprops' filter idea would work, but I feel it would be better to
> > be able to flag the input file correctly in the first place.
> >
> > Imagine having one input file and outputting it to multiple output files
> > (I'm thinking of an example where you are reading from an input pipe and
> > outputting to MPEG2 and DV at the same time). You'd have to include the
> > 'setprops' filter at the start of both output files filter chains. Where
> > as, if you could supply the -top command against a rawvideo input you'd
> > only need to supply the parameter once.
> >
> > I might just be rambling inanely, but in
> > libavcodec\rawdec.c:raw_decode(), interlaced_frame and top_field_first
> > are set in the AVFrame 'frame' (the second parameter to raw_decode())
> > variable by copying from the AVFrame contained in AVCodecContext.
> >
> > It looks like the only place
> > AVCodecContext->coded_frame->interlaced_frame and
> > AVCodecContext->coded_frame->top_field_first are currently set is in
> > libavdevice\v4l2.c:v4l2_read_packet().
> >
> > So perhaps it might be good to also set those parameters in
> > libavformat\rawvideocodec.c:rawvideo_read_packet().
> >
> > This, at least, flags rawvideo as tff:
>
>
> > diff --git a/libavformat/rawvideodec.c b/libavformat/rawvideodec.c
> > index 127119f..9bdf950 100644
> > --- a/libavformat/rawvideodec.c
> > +++ b/libavformat/rawvideodec.c
> > @@ -39,6 +39,12 @@ static int rawvideo_read_packet(AVFormatContext *s,
> > AVPacket *pkt)
> > pkt->dts= pkt->pos / packet_size;
> >
> > pkt->stream_index = 0;
> > +
> > + if (s->streams[0]->codec->coded_frame) {
> > + s->streams[0]->codec->coded_frame->interlaced_frame = 1;
> > + s->streams[0]->codec->coded_frame->top_field_first = 1;
> > + }
> > +
> > if (ret < 0)
> > return ret;
> > return 0;
> >
> >
>
> > I do not yet understand is how to get the correct value from variable
> > top_field_first in ffmpeg.c into that section of code.
> > ffmpeg.c:opt_input_file() looks like a good place to start.
> >
> > Perhaps, if the input file format is rawvideo and top_field_first is not
> > -1 a field could be set and top_field_first set to -1.
> >
>
> > If that is a reasonable idea, AVFormatParameters would be the structure
> > to extend.
>
> AVFormatParameters is deprecated and we should get rid of it. Instead,
> we could use demuxers/decoders private options when it makes
> sense. I'm not yet sure where the option should be set (if in the
> demuxer or in the decoder), Michael?
I dont think theres a single perfect awnser here
demuxer private options would make it only available for one demuxer
there can be rawvideo in many containers.
a rawvideo decoder private option might work and looks simple.
it wont be available during find_stream_info() though but this seems
a non issue.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110516/7fd8a1f8/attachment.asc>
More information about the ffmpeg-devel
mailing list