[FFmpeg-user] Zeroing 'top_field_first' & 'repeat_pict' -- Possible?

Mark Filipak markfilipak.windows+ffmpeg at gmail.com
Sat Apr 25 16:07:53 EEST 2020


On 04/25/2020 08:54 AM, Paul B Mahol wrote:
> On 4/25/20, Mark Filipak <markfilipak.windows+ffmpeg at gmail.com> wrote:
>> On 04/25/2020 05:15 AM, Paul B Mahol wrote:
>>> On 4/25/20, Mark Filipak <markfilipak.windows+ffmpeg at gmail.com> wrote:
>>>> ffprobe reports:
>>>>
>>>> frames.frame.0.interlaced_frame=0
>>>> frames.frame.0.top_field_first=1
>>>> frames.frame.0.repeat_pict=1
>>>> frames.frame.1.interlaced_frame=0
>>>> frames.frame.1.top_field_first=0
>>>> frames.frame.1.repeat_pict=0
>>>> frames.frame.2.interlaced_frame=0
>>>> frames.frame.2.top_field_first=0
>>>> frames.frame.2.repeat_pict=1
>>>> frames.frame.3.interlaced_frame=0
>>>> frames.frame.3.top_field_first=1
>>>> frames.frame.3.repeat_pict=0
>>>>
>>>> Is there an ffmpeg way to zero those metadata flags in the input prior to
>>>> the decoder so that the
>>>> decoder thinks that the input is solely progressive?
>>>
>>> No, are you now mixing filtering and decoding?
>>
>> No. I wrote "prior to the decoder". Did you notice? In contrast to "prior to
>> the decoder", I assume
>> that filters operate on frames/fields/pixels prior to the output.
> 
> Just in case: INPUT->[PARSER->]DEMUXER->[BITSTREAM_FILTER->]DECODER->FILTER->MUXER->ENCODER

Thanks so much. For an architecture guy like me, that process flow is pure gold. May I ask more?

INPUT -- This means the command line, yes?
PARSER -- (optional? or would this be a parser that I would write?)
BITSTREAM_FILTER -- This would filter an MPEG stream, yes? I initially looked at 'mpeg2_metadata' to 
manipulate the above metadata flags and was disappointed/bewildered that there is no such directive.


More information about the ffmpeg-user mailing list