bwdif filter question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bwdif filter question

Mark Filipak (ffmpeg)
Is the input to the bwdif filter fields or frames?

Since, according to previous threads, ffmpeg decoders solely produce frames, Based on this:
https://ffmpeg.org/ffprobe-all.html#bwdif
I honestly can't figure out which it is: fields or frames.

Thanks!

Note: I'm experimenting with virtual identities in my Thunderbird email client because the ffmpeg
archives publish email addresses and I wish to spoof in order to avoid spamming harvesters. So, if
this thread gets screwed up, kindly be tolerant. Thanks!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Bouke-3
>
> Note: I'm experimenting with virtual identities in my Thunderbird email client because the ffmpeg archives publish email addresses and I wish to spoof in order to avoid spamming harvesters.

And the fact that you are a troll has nothing to do with it?


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Carl Eugen Hoyos-2
In reply to this post by Mark Filipak (ffmpeg)


> Am 14.09.2020 um 16:39 schrieb Mark Filipak (ffmpeg) <[hidden email]>:
>
> Is the input to the bwdif filter fields or frames?

In general, FFmpeg’s filter system doesn’t know about fields, only frames that may contain progressive content or interlaced content that you may want to de-interlace.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Filipak (ffmpeg)
In reply to this post by Bouke-3
On 09/14/2020 03:23 PM, Bouke wrote:
>>
>> Note: I'm experimenting with virtual identities in my Thunderbird email client because the ffmpeg archives publish email addresses and I wish to spoof in order to avoid spamming harvesters.
>
> And the fact that you are a troll has nothing to do with it?

How did this list get so bad?
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Himsley-2
In reply to this post by Mark Filipak (ffmpeg)
On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <[hidden email]> wrote:
>
> Is the input to the bwdif filter fields or frames?

The input to every filter in a filter chain is a raster of pixels.
That raster may contain one frame or two fields.
The bwdif filter will interpret a single raster and is designed to
output two rasters, each containing one or the other of the fields
that were contained in the input raster.

--
Mark Himsley
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Video Glossary (was: bwdif filter question)

Mark Filipak (ffmpeg)
On 09/16/2020 09:58 AM, Mark Himsley wrote:
> On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <[hidden email]> wrote:
>>
>> Is the input to the bwdif filter fields or frames?
>
> The input to every filter in a filter chain is a raster of pixels.
> That raster may contain one frame or two fields.
> The bwdif filter will interpret a single raster and is designed to
> output two rasters, each containing one or the other of the fields
> that were contained in the input raster.

Thank you Mark. I note how you've employed the word "raster". I think that's a useful step.

I've spent a month documenting the various macroblock formats (aka syntax) and creating various
diagrams showing what I've learned along the way. The physical structure of frame data may be coming
into focus, at least in my head and in my diagrams.

It appears that the pictures people hold in their heads changes depending on context:
1, Encoded frames (slices, macroblocks, etc.) as found on-disc or in a stream,
2, Picture frames output by an input decoder, and
3, Picture structures v. half-picture structures (i.e. frames v. fields, what you are calling
"rasters") within filter chains.

Each is unique. Each has unique structure and usage. However, undifferentiated names (e.g. "frames",
"fields", "interlace", "deinterlace") are being applied. People are relying on context to fill in
the gaps. But when context goes unsaid, confusion reigns leaving us trapped in a video Tower of Babel.

The confusion is not limited to this mailing list. The folks who wrote and revise the H.222 and
H.242 specifications clearly also relied on context. The result is that H.222 & H.242 seem ambiguous
and confusing.

Appropriate contextual names based on physical data structures should be created to end the
confusion. That is what I'm attempting. I invite interested people to join me in a glossary project.

Regards,
Mark.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Paul B Mahol
In reply to this post by Mark Himsley-2
On Wed, Sep 16, 2020 at 02:58:25PM +0100, Mark Himsley wrote:
> On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <[hidden email]> wrote:
> >
> > Is the input to the bwdif filter fields or frames?
>
> The input to every filter in a filter chain is a raster of pixels.
> That raster may contain one frame or two fields.
> The bwdif filter will interpret a single raster and is designed to
> output two rasters, each containing one or the other of the fields
> that were contained in the input raster.

It also can contain only single fields.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Carl Eugen Hoyos-2
In reply to this post by Mark Himsley-2


> Am 16.09.2020 um 15:58 schrieb Mark Himsley <[hidden email]>:
>
>> On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <[hidden email]> wrote:
>>
>> Is the input to the bwdif filter fields or frames?
>
> The input to every filter in a filter chain is a raster of pixels.
> That raster may contain one frame or two fields.

That may not be wrong (apart from Paul’s comment) but I wonder how useful it is:
No matter if the raster contains one field, two interlaced fields or a progressive frame, the filter will always see an input frame.
The fact that there is metadata that may signal the content is also not necessarily helpful as this metadata is typically wrong (often signalling fields when a frame is provided). That’s why the filter ignores the information by default.

(If you provide only one field, no FFmpeg deinterlacer will produce useful output.)

> The bwdif filter will interpret a single raster and is designed to
> output two rasters, each containing one or the other of the fields
> that were contained in the input raster.

You can request that the filter outputs one instead of two rasters for one input raster.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Filipak (ffmpeg)
On 09/18/2020 03:01 PM, Carl Eugen Hoyos wrote:
>> Am 16.09.2020 um 15:58 schrieb Mark Himsley <[hidden email]>:
>>> On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <[hidden email]> wrote:
>>> Is the input to the bwdif filter fields or frames?
>> The input to every filter in a filter chain is a raster of pixels.
>> That raster may contain one frame or two fields.
> That may not be wrong (apart from Paul’s comment) but I wonder how useful it is:
> No matter if the raster contains one field, two interlaced fields or a progressive frame, the filter will always see an input frame.

"...if the raster contains *one field*...the filter will always see an input *frame*."
How is that possible? How can a frame contain just one field?

> The fact that there is metadata that may signal the content is also not necessarily helpful as this metadata is typically wrong (often signalling fields when a frame is provided).

Can you provide an example (or a link to an example)? I've examined a great number of DSM mpeg
presentation streams ('VOB's & 'm2ts's) and I've not seen a single case. What metadata are you
looking at?
sequence_extension: 'progressive_sequence'?
picture_coding_extension: 'picture_structure'?
picture_coding_extension: 'top_field_first'?
picture_coding_extension: 'repeat_first_field'?
picture_coding_extension: 'progressive_frame'?

> That’s why the filter ignores the information by default.
>
> (If you provide only one field, no FFmpeg deinterlacer will produce useful output.)
>
>> The bwdif filter will interpret a single raster and is designed to
>> output two rasters, each containing one or the other of the fields
>> that were contained in the input raster.

"...interpret a *single raster*...one or the other of the fields...in the *input raster*."
Mark Himsley, how are you defining "raster"? I thought you were equating a "single raster" with a
frame and "two rasters" with fields, but now I'm unsure what you mean.

> You can request that the filter outputs one instead of two rasters for one input raster.

--
COVID-19 perspective, 0 AM UTC, 20 September 2020.
Yesterday, China: 14 new cases, S.Korea: 110, U.S.: 42,533.
Today, U.S.: 4% of world population, 22% of cases, 21% of deaths.
Today, U.S.: Of 4,427,517 resolved cases, 95% lived, 5% died.
22 Jan: U.S. & S.Korea reported 1st cases on the same day.
6 Mar, S.Korea: 140,000 total tests; results in 4 hours.
6 Mar, U.S.: 2000 total tests; results in 1 to 2 weeks.
May, for the first time, U.S. care-homes are required to report.
1 Jun, total care-home deaths, S.Korea: 0, U.S.: 26,000 to 40,000.
5 Aug, U.S. tests still only 1/4 of number needed; 4 day results.
1 Sep, over 60% of U.S. nurses still lack protective equipment.
18 Sep, U.S. doctors & nurses still acutely lack PPE; 1200 dead.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Carl Eugen Hoyos-2
Am So., 20. Sept. 2020 um 06:59 Uhr schrieb Mark Filipak (ffmpeg)
<[hidden email]>:

>
> On 09/18/2020 03:01 PM, Carl Eugen Hoyos wrote:
> >> Am 16.09.2020 um 15:58 schrieb Mark Himsley <[hidden email]>:
> >>> On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <[hidden email]> wrote:
> >>> Is the input to the bwdif filter fields or frames?
> >> The input to every filter in a filter chain is a raster of pixels.
> >> That raster may contain one frame or two fields.
> >
> > That may not be wrong (apart from Paul’s comment) but I wonder how useful it is:
> > No matter if the raster contains one field, two interlaced fields or a progressive
> > frame, the filter will always see an input frame.
>
> "...if the raster contains *one field*...the filter will always see an input *frame*."
> How is that possible? How can a frame contain just one field?

The following makes little sense, it is just meant as an example:
$ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -

Here, the input to the bwdif consists of frames that contain one field
(of the original input).

> > The fact that there is metadata that may signal the content is also not necessarily
> > helpful as this metadata is typically wrong (often signalling fields when a frame is provided).
>
> Can you provide an example (or a link to an example)? I've examined a
> great number of DSM mpeg presentation streams ('VOB's & 'm2ts's) and
> I've not seen a single case. What metadata are you looking at?
> sequence_extension: 'progressive_sequence'?
> picture_coding_extension: 'picture_structure'?
> picture_coding_extension: 'top_field_first'?
> picture_coding_extension: 'repeat_first_field'?

I would expect that most commercial encodings you have uses
one of the above, independently of the content...

> picture_coding_extension: 'progressive_frame'?

... while this is unusual, even for movies in PAL streams.

Otoh, I typically saw pal dvb streams, maybe my claim is
only true for them.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Filipak (ffmpeg)
On 09/20/2020 05:44 PM, Carl Eugen Hoyos wrote:

> Am So., 20. Sept. 2020 um 06:59 Uhr schrieb Mark Filipak (ffmpeg) <[hidden email]>:
>> On 09/18/2020 03:01 PM, Carl Eugen Hoyos wrote:
>>>> Am 16.09.2020 um 15:58 schrieb Mark Himsley <[hidden email]>:
>>>>> On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <[hidden email]> wrote:
>>>>> Is the input to the bwdif filter fields or frames?
>>>> The input to every filter in a filter chain is a raster of pixels.
>>>> That raster may contain one frame or two fields.
>>> That may not be wrong (apart from Paul’s comment) but I wonder how useful it is:
>>> No matter if the raster contains one field, two interlaced fields or a progressive
>>> frame, the filter will always see an input frame.
>> "...if the raster contains *one field*...the filter will always see an input *frame*."
>> How is that possible? How can a frame contain just one field?
>
> The following makes little sense, it is just meant as an example:
> $ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -
>
> Here, the input to the bwdif consists of frames that contain one field
> (of the original input).

Thanks, Carl Eugen. Kindly forgive my ignorance -- I can't read 'C' code and probably couldn't find
the relevant code section if my life depended on it.

If bwdif is the *only* filter, then, from previous discussions, I understand that its input (i.e.
the decoder's output) is raw frames (e.g. 720x576)? If raw frames, then I can understand the above
to mean that the filter is 'fed' only one field (e.g. 720x288). Logically, to me, that would be a
frame (i.e. a 720x288 frame), but no matter (let's forget that). However, even then, the filter is
receiving only one field. How can it 'deinterlace' a single field? I'm mystified. Does it line
double in such a circumstance? Or does it deinterlace the current single field with the next single
field one frame later?

>>> The fact that there is metadata that may signal the content is also not necessarily
>>> helpful as this metadata is typically wrong (often signalling fields when a frame is provided).
>>
>> Can you provide an example (or a link to an example)? I've examined a
>> great number of DSM mpeg presentation streams ('VOB's & 'm2ts's) and
>> I've not seen a single case. What metadata are you looking at?
>> sequence_extension: 'progressive_sequence'?
>> picture_coding_extension: 'picture_structure'?
>> picture_coding_extension: 'top_field_first'?
>> picture_coding_extension: 'repeat_first_field'?
>
> I would expect that most commercial encodings you have uses
> one of the above, independently of the content...

Based on my experience, and to the best of my knowledge, every MPEG PS & TS have all 5 metadata
values. Certainly, every MPEG stream *I've* parsed have all 5.

>> picture_coding_extension: 'progressive_frame'?
>
> ... while this is unusual, even for movies in PAL streams.

For what it's worth, I have only one PAL movie, "The Man Who Would Be King", from Australia. It has
all 5 metadata values and appears to be a regular MPEG PS.

Regarding 'progressive_frame', ffmpeg has 'interlaced_frame' in lieu of 'progressive_frame'. I think
that 'interlaced_frame' = !'progressive_frame' but I'm not sure. Confirming it as a fact is a side
project that I work on only occasionally. H.242 defines "interlace" as solely the condition of PAL &
NTSC scan-fields (i.e. field period == (1/2)(1/FPS)), but I don't want to pursue that further
because I don't want to be perceived as a troll. :-)

- Mark.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Carl Eugen Hoyos-2


> Am 21.09.2020 um 01:56 schrieb Mark Filipak (ffmpeg) <[hidden email]>:
>
> How can it 'deinterlace' a single field?

It can’t and that is what I explained several times in my last two mails.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Filipak (ffmpeg)
On 09/21/2020 03:33 AM, Carl Eugen Hoyos wrote:
>
>
>> Am 21.09.2020 um 01:56 schrieb Mark Filipak (ffmpeg) <[hidden email]>:
>>
>> How can it 'deinterlace' a single field?
>
> It can’t and that is what I explained several times in my last two mails.

Here is what you wrote:
"The following makes little sense, it is just meant as an example:
$ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -"

That "explains" nothing. Worse, it seems crass and sarcastic. The perfect word is "snarky". Do you
know that word? It's a word invented by the man who wrote "Alice In Wonderland". Sometimes it seems
that what you write is meant to pull people down a psychedelic rabbit hole and into a fantasy world.

Just because something is possible with ffmpeg, if it doesn't make sense to do it, don't mention it.
If you do mention it and you write that it makes "little sense", then explain why it makes little sense.

In this case, it doesn't make "little sense". It makes *no* sense.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Paul B Mahol
On Mon, Sep 21, 2020 at 08:11:59AM -0400, Mark Filipak (ffmpeg) wrote:

> On 09/21/2020 03:33 AM, Carl Eugen Hoyos wrote:
> >
> >
> > > Am 21.09.2020 um 01:56 schrieb Mark Filipak (ffmpeg) <[hidden email]>:
> > >
> > > How can it 'deinterlace' a single field?
> >
> > It can’t and that is what I explained several times in my last two mails.
>
> Here is what you wrote:
> "The following makes little sense, it is just meant as an example:
> $ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -"
>
> That "explains" nothing. Worse, it seems crass and sarcastic. The perfect
> word is "snarky". Do you know that word? It's a word invented by the man who
> wrote "Alice In Wonderland". Sometimes it seems that what you write is meant
> to pull people down a psychedelic rabbit hole and into a fantasy world.
>
> Just because something is possible with ffmpeg, if it doesn't make sense to
> do it, don't mention it. If you do mention it and you write that it makes
> "little sense", then explain why it makes little sense.
>
> In this case, it doesn't make "little sense". It makes *no* sense.

Please refrain from attacking other people on this mailing list.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Filipak (ffmpeg)
On 09/21/2020 09:26 AM, Paul B Mahol wrote:

> On Mon, Sep 21, 2020 at 08:11:59AM -0400, Mark Filipak (ffmpeg) wrote:
>> On 09/21/2020 03:33 AM, Carl Eugen Hoyos wrote:
>>>
>>>
>>>> Am 21.09.2020 um 01:56 schrieb Mark Filipak (ffmpeg) <[hidden email]>:
>>>>
>>>> How can it 'deinterlace' a single field?
>>>
>>> It can’t and that is what I explained several times in my last two mails.
>>
>> Here is what you wrote:
>> "The following makes little sense, it is just meant as an example:
>> $ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -"
>>
>> That "explains" nothing. Worse, it seems crass and sarcastic. The perfect
>> word is "snarky". Do you know that word? It's a word invented by the man who
>> wrote "Alice In Wonderland". Sometimes it seems that what you write is meant
>> to pull people down a psychedelic rabbit hole and into a fantasy world.
>>
>> Just because something is possible with ffmpeg, if it doesn't make sense to
>> do it, don't mention it. If you do mention it and you write that it makes
>> "little sense", then explain why it makes little sense.
>>
>> In this case, it doesn't make "little sense". It makes *no* sense.
>
> Please refrain from attacking other people on this mailing list.

I am not attacking Carl Eugen. I'm trying to help him.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

kumowoon1025
In reply to this post by Mark Filipak (ffmpeg)
Morning,

> Regarding 'progressive_frame', ffmpeg has 'interlaced_frame' in lieu of 'progressive_frame'. I think that 'interlaced_frame' = !'progressive_frame' but I'm not sure. Confirming it as a fact is a side project that I work on only occasionally. H.242 defines "interlace" as solely the condition of PAL & NTSC scan-fields (i.e. field period == (1/2)(1/FPS)), but I don't want to pursue that further because I don't want to be perceived as a troll. :-)

I'm not entirely aware of what is being discussed, but progressive_frame = !interlaced_frame kind of sent me back a bit, I do remember the discrepancy you noted in some telecopied material, so I'll just quickly paraphrase from what we looked into before, hopefully it'll be relevant.

The AVFrame interlaced_frame flag isn't completely unrelated to mpeg progressive_frame, but it's not a simple inverse either, very context-dependent. With mpeg video, it seems it is an interlaced_frame if it is not progressive_frame, and it shouldn't result where mpeg progressive_sequence is set.

Basically, the best you can generalize from that is the frame stores interlaced video. (Yes interlaced_frame means the frame has interlaced material) Doesn't help at all... But I don't think it can be helped? Since AVFrames accommodates many more types of video frame data than just the generations of mpeg coded.

I think it was often said (not as much anymore) that "FFmpeg doesn't output fields" and I think at least part of the reason is this. At the visually essential level, there is the "picture" described as a single instance of a sequence of frames/fields/lines or what have you depending on the format and technology; the image that you actually see.

But that's a visual projection of the decoded and rendered video, or if you're encoding, it's what you want to see when you decode and render your encoding. I think the term itself has a very abstract(?) nuance. The picture seen at a certain presentation timestamp either has been decoded, or can be encoded as frame pictures or field pictures.

Both are stored in "frames", a red herring in the terminology imo. The AVFrame that ffmpeg deals with isn't necessarily a "frame" as in a rectangular picture frame with width and height, but closer to how the data is  temporally "framed," e.g. in packets with header data, where one AVFrame has one video frame (picture). Image data could be scanned by macroblock, unless you are playing actual videotape.

So when interlace scanned fields are stored in frames, it's more than that both fields and frames are generalized into a single structure for both types of pictures called "frames" –  AVFrames, as the prefix might suggest, also are audio frames. And though it's not a very good analogy to field-based video, multiple channels of sound can be interleaved.

I apologize that was a horrible job at quickly paraphrasing but if there was any conflation of the packet-like frames and picture-like frames or interlaced scanning video lines and macro block scanning I think the info might be able to shift your footing and give you another perspective, even if it's not 100% accurate.

Regards,
Ted Park

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Filipak (ffmpeg)
On 09/21/2020 11:24 AM, Edward Park wrote:
> Morning,
Hi Ted!
>
>> Regarding 'progressive_frame', ffmpeg has 'interlaced_frame' in lieu of 'progressive_frame'. I think that 'interlaced_frame' = !'progressive_frame' but I'm not sure. Confirming it as a fact is a side project that I work on only occasionally. H.242 defines "interlace" as solely the condition of PAL & NTSC scan-fields (i.e. field period == (1/2)(1/FPS)), but I don't want to pursue that further because I don't want to be perceived as a troll. :-)
>
> I'm not entirely aware of what is being discussed, but progressive_frame = !interlaced_frame kind of sent me back a bit, I do remember the discrepancy you noted in some telecopied material, so I'll just quickly paraphrase from what we looked into before, hopefully it'll be relevant.
>
> The AVFrame interlaced_frame flag isn't completely unrelated to mpeg progressive_frame, but it's not a simple inverse either, very context-dependent. With mpeg video, it seems it is an interlaced_frame if it is not progressive_frame ...

No so, Ted. The following two definitions are from the glossary I'm preparing (and which cites H.262).

'progressive_frame' [noun]: 1, A metadata bit differentiating a picture or halfpicture
   frame ('1') from a scan frame ('0'). 2, H.262 §6.3.10: "If progressive_frame is set
   to 0 it indicates that the two fields of the frame are interlaced fields in which an
   interval of time of the field period exists between (corresponding spatial samples)
   of the two fields. ... If progressive_frame is set to 1 it indicates that the two
   fields (of the frame) are actually from the same time instant as one another."

interlace [noun]: 1, H.262 §3.74: "The property of conventional television frames [1]
   where alternating lines of the frame represent different instances in time."
   [1] H.262 clearly limits interlace to scan-fields and excludes concurrent fields
       (and also the non-concurrent fields that can result from hard telecine).
   2, Informal: The condition in which the samples of odd and even rows (or lines)
   alternate.
   [verb], informal: To weave or reweave fields.

  -- A note about my glossary: "picture frame", "halfpicture frame", and "scan frame" are precisely
and unambiguously defined by (and differentiated from one another by) their physical structures
(including any metadata that may demarcate them), not by their association to other features and not
by the context in which they appear. I endeavor to make all definitions strong in likewise manner.

>... and it shouldn't result where mpeg progressive_sequence is set.
>
> Basically, the best you can generalize from that is the frame stores interlaced video. (Yes interlaced_frame means the frame has interlaced material) Doesn't help at all... But I don't think it can be helped? Since AVFrames accommodates many more types of video frame data than just the generations of mpeg coded.

Since you capitalize "AVFrames", I assume that you cite a standard of some sort. I'd very much like
to see it. Do you have a link?

> I think it was often said (not as much anymore) that "FFmpeg doesn't output fields" and I think at least part of the reason is this. At the visually essential level, there is the "picture" described as a single instance of a sequence of frames/fields/lines or what have you depending on the format and technology; the image that you actually see.

H.262 refers to "frame pictures" and "field pictures" without clearly delineating them. I am calling
them "pictures" and "halfpictures".

> But that's a visual projection of the decoded and rendered video, or if you're encoding, it's what you want to see when you decode and render your encoding. I think the term itself has a very abstract(?) nuance. The picture seen at a certain presentation timestamp either has been decoded, or can be encoded as frame pictures or field pictures.

You see. You are using the H.262 nomenclature. That's fine, and I'm considering using it also even
though it appears to be excessively wordy. Basically, I prefer "pictures" for interlaced content and
"halfpictures" for deinterlaced content unweaved from a picture.

> Both are stored in "frames", a red herring in the terminology imo ...

Actually, it is frames that exist. Fields don't exist as discrete, unitary structures in macroblocks
in streams.

>... The AVFrame that ffmpeg deals with isn't necessarily a "frame" as in a rectangular picture frame with width and height, but closer to how the data is  temporally "framed," e.g. in packets with header data, where one AVFrame has one video frame (picture). Image data could be scanned by macroblock, unless you are playing actual videotape.

You singing a sweet song, Ted. Frames actually do exist in streams and are denoted by metadata. The
data inside slices inside macroblocks I am calling framesets. I firmly believe that every structure
should have a unique name.

> So when interlace scanned fields are stored in frames, it's more than that both fields and frames are generalized into a single structure for both types of pictures called "frames" –  AVFrames, as the prefix might suggest, also are audio frames. And though it's not a very good analogy to field-based video, multiple channels of sound can be interleaved.

Interleave is not necessarily interlaced. For example, a TFF YCbCr420 frameset has 7 levels of
interleave: YCbCr sample-quads, odd & even Y blocks (#s 1,2,3,4), odd & even Y halfmacroblocks, TFF
Y macroblock, TFF Cb420 block (#5), TFF Cr420 block (#6), and macroblock. but only 3 interlacings:
TFF Y macroblock, TFF Cb420 block, and TFF Cr420 block.

> I apologize that was a horrible job at quickly paraphrasing but if there was any conflation of the packet-like frames and picture-like frames or interlaced scanning video lines and macro block scanning I think the info might be able to shift your footing and give you another perspective, even if it's not 100% accurate.
>
> Regards,
> Ted Park

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Carl Eugen Hoyos-2
In reply to this post by Mark Filipak (ffmpeg)
Am Mo., 21. Sept. 2020 um 14:16 Uhr schrieb Mark Filipak (ffmpeg)
<[hidden email]>:

>
> On 09/21/2020 03:33 AM, Carl Eugen Hoyos wrote:
> >
> >> Am 21.09.2020 um 01:56 schrieb Mark Filipak (ffmpeg) <[hidden email]>:
> >>
> >> How can it 'deinterlace' a single field?
> >
> > It can’t and that is what I explained several times in my last two mails.
>
> Here is what you wrote:
> "The following makes little sense, it is just meant as an example:
> $ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -"
>
> That "explains" nothing. Worse, it seems crass and sarcastic.

No.
This was an example to show you how you can feed one field to
a filter in our system, this is what you had asked for, I used the
filter that is the topic in this mailing list thread.
In addition, I explained - not only but including above - that this
is not a useful example for an interlace filter, just as feeding a
progressive frame is not useful.

Please understand that I have shown significantly more patience
with you then with most other users here and significantly more
patience than most people on this mailist list (including the silent
ones) have with you. I can only ask you to accept the answers you
receive instead of interpreting every single one of them as a
personal attack just because they don't match what you expect.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Mark Filipak (ffmpeg)
On 09/21/2020 06:07 PM, Carl Eugen Hoyos wrote:

> Am Mo., 21. Sept. 2020 um 14:16 Uhr schrieb Mark Filipak (ffmpeg)
> <[hidden email]>:
>>
>> On 09/21/2020 03:33 AM, Carl Eugen Hoyos wrote:
>>>
>>>> Am 21.09.2020 um 01:56 schrieb Mark Filipak (ffmpeg) <[hidden email]>:
>>>>
>>>> How can it 'deinterlace' a single field?
>>>
>>> It can’t and that is what I explained several times in my last two mails.
>>
>> Here is what you wrote:
>> "The following makes little sense, it is just meant as an example:
>> $ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -"
>>
>> That "explains" nothing. Worse, it seems crass and sarcastic.
>
> No.
> This was an example to show you how you can feed one field to
> a filter in our system, this is what you had asked for ...

I didn't ask for that. That was in your reply to a comment from Mark Himsley.
"No matter if the raster contains one field, two interlaced fields or a progressive frame, the
filter will always see an input frame."
I simply asked how a deinterlacing filter would handle an input that has only one field. It's a
question that, I note, you have not answered except that it "makes little sense", to which I agreed.

>... I used the
> filter that is the topic in this mailing list thread.
> In addition, I explained - not only but including above - that this
> is not a useful example for an interlace filter, just as feeding a
> progressive frame is not useful.

I agree in both cases of course.

> Please understand that I have shown significantly more patience
> with you then with most other users here and significantly more
> patience than most people on this mailist list (including the silent
> ones) have with you. I can only ask you to accept the answers you
> receive instead of interpreting every single one of them as a
> personal attack just because they don't match what you expect.

Paul Mahol accused me of attacking you. That's absurd of course. Now you accuse me of feeling
attacked. How would you know what I feel? I don't feel attacked.

You and Paul need to get your stories aligned. :-)


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: bwdif filter question

Bouke-3

> On 22 Sep 2020, at 00:44, Mark Filipak (ffmpeg) <[hidden email]> wrote:
>
> Paul Mahol accused me

He was not the only one.
Go away!

and no, this is not aimed at you, but to the rest of the bunch to NOT FEED THE TROLL
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12