Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions

2020-12-27 Thread Mark Filipak (ffmpeg)

On 12/27/2020 01:23 PM, Paul B Mahol wrote:

On Sun, Dec 27, 2020 at 6:45 PM Mark Filipak (ffmpeg) 
wrote:


On 12/27/2020 06:19 AM, Paul B Mahol wrote:

On Sun, Dec 27, 2020 at 5:00 AM Mark Filipak (ffmpeg) <

markfili...@bog.us>

wrote:


Decimation with ppsrc=1 malfunctions.



Paul fixed this somewhat, but it's still in trouble.
Since I eliminated threading and decimation as the cause, I suspect that
frames numbers are being
bollixed.

The report package is here:
https://www.dropbox.com/t/zu4cezneCJIsdmUu



decimate filter only drops frames, it never fixes combing.


Of course.


Do you know exact telecine pattern used in your samples?


Look at 'source.mkv frames 1018-1029.png'. I have a scenario that explains
why a sober engineer
would be forced to do what was done, but what's the point? Combing is not
the issue. The issue is
that the duplicate (modulo 5) frames found in preprocessed.mkv are not
being removed from source.mkv.

source.mkv & preprocessed.mkv are 172 frames. target.mkv should be 138
frames. It is 138 frames, but
they are the wrong frames. Worse, the frames removed are not modulo 5 but
vary instead. The only
cause I could imagine was a mixup due to a threading mixup but
single-threading didn't solve the
problem.


I really wonder what is your real motivation to write so long text
basically saying nothing.


My motivation (as always) is to get the best possible transcode given the 
existing source video.


Decimate filter removes duplicated decombed frames from field match
processing.


Combed or decombed, what does that matter? What matters is duplicated frames.


Using it for anything other is pointless.

For default cycle of 5 it removes single frame from every 5 frames than
have the lowest threshold.


In preprocessed.mkv every 5th frame is a repeat of frame 4. This is confirmed because decimating 
prepreocessed.mkv succeeds. However, applying decimate=ppsrc=1 does not remove the correct frames 
from source.mkv. How can that happen?



If you wish to drop every fixed X-th frame from every cycle frames of 5 use
shuffleframes or select filter.


I can't (easily) predict in advance which frame is the repeat. Simply removing it via decimate 
solves the first step of the problem no matter which frame is the repeated frame.


Decimate would work with source.mkv if source.mkv didn't have frame numbers burned in. But 
source.mkv does have frame numbers burned in. My approach is to cut out the burned-in frame numbers 
from source.mkv and save the target as 'preprocessed.mkv', then use preprocessed.mkv as the template 
(via decimate=ppsrc=1) to drop the correct frames from source.mkv. Bbut that didn't work. It appears 
that between preprocessed.mkv and the decimation of source.mkv, the frame numbers are getting mixed up.


Now, I know that the problem isn't with preprocessed.mkv. I know that because if I decimate 
preprocessed.mkv, the correct frames are dropped. So the problem must be the communication between 
decimate=ppsrc=1 and the handler that's dropping frames from source.mkv.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions

2020-12-27 Thread Mark Filipak (ffmpeg)

On 12/27/2020 07:30 AM, Carl Eugen Hoyos wrote:

Am 27.12.2020 um 12:19 schrieb Paul B Mahol :

Do you know exact telecine pattern used in your samples?


I don’t think the sample is telecined...


It must have been. Now, bear with me.
1, The original video was p24:
[A/a][B/b][C/c][D/d]
2, Later, it was telecined:
[A/a][B/b][B/c][C/d][D/d]
3, Later, a modulo-5 frame was dropped [1]:
[A/a][B/c][C/d][D/d]
4, Later, a modulo-4 frame was repeated:
[A/a][B/c][C/d][D/d][D/d]

[1] Dropping a frame in lieu of detelecine was a mistake. Perhaps the engineer 
was drunk.


... or at least whatever was done with it can’t be undone (even the description 
confirms this)...


Ah! But it can be undone (sort of):
Decimate to:
[A/a][B/c][C/d][D/d]
Then synthesize a frame:
[A/a][B/B][B/c][C/d][D/d]
Then detelecine:
[A/a][B/B][C/c][D/d]


... so this part of the discussion seems moot.


I agree. It's moot because it doesn't bear on why decimate=ppsrc=1 isn't 
working correctly.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions

2020-12-27 Thread Mark Filipak (ffmpeg)

On 12/27/2020 06:19 AM, Paul B Mahol wrote:

On Sun, Dec 27, 2020 at 5:00 AM Mark Filipak (ffmpeg) 
wrote:


Decimation with ppsrc=1 malfunctions.



Paul fixed this somewhat, but it's still in trouble.
Since I eliminated threading and decimation as the cause, I suspect that
frames numbers are being
bollixed.

The report package is here:
https://www.dropbox.com/t/zu4cezneCJIsdmUu



decimate filter only drops frames, it never fixes combing.


Of course.


Do you know exact telecine pattern used in your samples?


Look at 'source.mkv frames 1018-1029.png'. I have a scenario that explains why a sober engineer 
would be forced to do what was done, but what's the point? Combing is not the issue. The issue is 
that the duplicate (modulo 5) frames found in preprocessed.mkv are not being removed from source.mkv.


source.mkv & preprocessed.mkv are 172 frames. target.mkv should be 138 frames. It is 138 frames, but 
they are the wrong frames. Worse, the frames removed are not modulo 5 but vary instead. The only 
cause I could imagine was a mixup due to a threading mixup but single-threading didn't solve the 
problem.


Over to you...  :-)
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Decimation with ppsrc=1 malfunctions

2020-12-26 Thread Mark Filipak (ffmpeg)

Decimation with ppsrc=1 malfunctions.

Paul fixed this somewhat, but it's still in trouble.
Since I eliminated threading and decimation as the cause, I suspect that frames numbers are being 
bollixed.


The report package is here:
https://www.dropbox.com/t/zu4cezneCJIsdmUu

Expires Jan 2, 2021.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] https://github.com/BtbN/FFmpeg-Builds/releases guidance needed

2020-12-24 Thread Mark Filipak (ffmpeg)

Never mind. I figured it out based on the sizes of the 'exe' files.
I downloaded 'ffmpeg-N-100461-gb0a882cc93-win64-gpl-vulkan.zip'.






On 12/24/2020 06:23 AM, Gyan Doshi wrote:



On 24-12-2020 02:33 pm, Mark Filipak (ffmpeg) wrote:

Here:
https://github.com/BtbN/FFmpeg-Builds/releases
are these:
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-shared-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-shared.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-shared-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-shared.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-gpl-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-gpl-shared-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-lgpl-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-lgpl-shared-4.3.zip

Sorry to have to ask [1], but what are they? Which one do I download if I have an Intel Core 
i7-6700HQ CPU with Intel(R) HD Graphics 530 & NVIDIA GeForce GTX 980M?


The ones with 'N-' are git builds;   the n4.3.1 are release builds.

gpl and lgpl are the licenses for the binaries contained in them. gpl ones will 
have more libraries.

'shared'  ones have the libav libs in separate files with the ff*.exe files dynamically linked to 
them. The ones without shared are statically linked and have everything in the exe.


vulkan is a new-ish API for processing on a GPU. You can use the few vulkan filters currently in 
libavfilter.  Your graphics driver must support Vulkan else ffmpeg won't run. Yours should.


Regards,
Gyan


I like sausage, but please don't tell me what's in it.  :-]

If I want everything, and I want to be able to say that I found a bug using the latest git version, 
what do I download?


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] https://github.com/BtbN/FFmpeg-Builds/releases guidance needed

2020-12-24 Thread Mark Filipak (ffmpeg)

On 12/24/2020 06:23 AM, Gyan Doshi wrote:



On 24-12-2020 02:33 pm, Mark Filipak (ffmpeg) wrote:

Here:
https://github.com/BtbN/FFmpeg-Builds/releases
are these:
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-shared-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-shared.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-shared-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-shared.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-gpl-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-gpl-shared-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-lgpl-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-lgpl-shared-4.3.zip

Sorry to have to ask [1], but what are they? Which one do I download if I have an Intel Core 
i7-6700HQ CPU with Intel(R) HD Graphics 530 & NVIDIA GeForce GTX 980M?


The ones with 'N-' are git builds;   the n4.3.1 are release builds.

gpl and lgpl are the licenses for the binaries contained in them. gpl ones will 
have more libraries.

'shared'  ones have the libav libs in separate files with the ff*.exe files dynamically linked to 
them. The ones without shared are statically linked and have everything in the exe.


vulkan is a new-ish API for processing on a GPU. You can use the few vulkan filters currently in 
libavfilter.  Your graphics driver must support Vulkan else ffmpeg won't run. Yours should.


Regards,
Gyan


I like sausage, but please don't tell me what's in it.  :-]

If I want everything, and I want to be able to say that I found a bug using the latest git version, 
what do I download?


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] https://github.com/BtbN/FFmpeg-Builds/releases guidance needed

2020-12-24 Thread Mark Filipak (ffmpeg)

Here:
https://github.com/BtbN/FFmpeg-Builds/releases
are these:
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-shared-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-shared.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-gpl.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-shared-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-shared.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl-vulkan.zip
ffmpeg-N-100459-ga7f9b3b954-win64-lgpl.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-gpl-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-gpl-shared-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-lgpl-4.3.zip
ffmpeg-n4.3.1-26-gca55240b8c-win64-lgpl-shared-4.3.zip

Sorry to have to ask [1], but what are they? Which one do I download if I have an Intel Core 
i7-6700HQ CPU with Intel(R) HD Graphics 530 & NVIDIA GeForce GTX 980M?


[1] There's no guide at https://github.com/BtbN/FFmpeg-Builds/releases. There's no guide at 
https://ffmpeg.org/download.html. And searching for "gpl-shared-vulkan", for example, just produces 
links back to https://github.com/BtbN/FFmpeg-Builds/releases & links to URLs in Chinese. I also read 
the FAQs and Wikis. Maybe I'm just unlucky, eh? Finally, there's the ffmpeg-user archive, but no way 
to search it. Oh dear.


Guidance is much appreciated.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ppsrc=1 decimation doesn't work or isn't correct or throws exception

2020-12-22 Thread Mark Filipak (ffmpeg)

On 12/22/2020 07:35 AM, Paul B Mahol wrote:

On Tue, Dec 22, 2020 at 12:21 PM Mark Filipak (ffmpeg)  
wrote:

On 12/22/2020 04:47 AM, Paul B Mahol wrote:

On Tue, Dec 22, 2020 at 1:28 AM Mark Filipak (ffmpeg) markfili...@bog.us wrote:

Here is a link to the bug report package:
https://www.dropbox.com/s/euz4q3daogulhwi/ERROR%20ppsrc%3D1%20DECIMATION%20DOESN%27T%20WORK%20OR%20ISN%27T%20CORRECT%20OR%20THROWS%20EXCEPTION.zip?dl=0

Fixed another bug, this one was from beginning of filter addition. It
happened only if dimension of both inputs where not same.


Thank you, Paul. This process worked well.

I wish you and your loved ones a healthy and satisfying 2021.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ppsrc=1 decimation doesn't work or isn't correct or throws exception

2020-12-22 Thread Mark Filipak (ffmpeg)

On 12/22/2020 04:47 AM, Paul B Mahol wrote:

On Tue, Dec 22, 2020 at 1:28 AM Mark Filipak (ffmpeg) 
wrote:


Here is a link to the bug report package:

https://www.dropbox.com/s/euz4q3daogulhwi/ERROR%20ppsrc%3D1%20DECIMATION%20DOESN%27T%20WORK%20OR%20ISN%27T%20CORRECT%20OR%20THROWS%20EXCEPTION.zip?dl=0

A friend assures me that anyone can download the zip file (though inside
dropbox it appears others
can only view the files).

Everything you developers need are in the zip. But do let me know if
there's any problem.



I think I fixed this, feel free to test with latest ffmpeg that have
decimate filter fix.


Hi Paul. I did run the latest git full build. Operation is improved over the previous, but it still 
has problems. I very carefully constructed the package I put in dropbox. You should find it quite 
complete. Go get it. And good hunting.


Regards,
Mark.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ppsrc=1 decimation doesn't work or isn't correct or throws exception

2020-12-21 Thread Mark Filipak (ffmpeg)
Here is a link to the bug report package: 
https://www.dropbox.com/s/euz4q3daogulhwi/ERROR%20ppsrc%3D1%20DECIMATION%20DOESN%27T%20WORK%20OR%20ISN%27T%20CORRECT%20OR%20THROWS%20EXCEPTION.zip?dl=0


A friend assures me that anyone can download the zip file (though inside dropbox it appears others 
can only view the files).


Everything you developers need are in the zip. But do let me know if there's 
any problem.


On 12/21/2020 07:13 PM, Mark Filipak (ffmpeg) wrote:
I'm trying to file a bug report but there appears to be no way to get the report to you. I have some 
very short video samples and the ffmpeg report files. I spent 4 hours on this to make it so clear it 
will be very easy to replicate. But trac.ffmpeg.org won't accept it.


...Frustrated. Four hours. What a waste of my time.

On 12/21/2020 02:52 PM, Mark Filipak (ffmpeg) wrote:

Win10-1803.

The sources & fault documentaion files are here: To be determined -- trac.ffmpeg.org rejects it, 
too big (2,847,812 bytes) -- got any suggestions?



RUNME.CMD : ffmpeg -i preprocessed.mkv -i source.mkv -filter_complex "decimate='ppsrc=1'" 
target.mkv -y


I ran RUNME.CMD 40 times.

33 times, RUNME.CMD didn't do anything: target.mkv = 0 bytes.

3 times, RUNME.CMD seemed to work but the decimation was wrong.
source.mkv frames:   1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 
1028 1029
target.mkv frames are:   1018  1020 1021 1022 1023 1024 1025  1027 
1028 1029
target.mkv frames should be: 1018  1020 1021 1022 1023  1025 1026 1027 
1028

'source.mkv frames 1018-1029.png' shows a source fragment that was made prior to frame number 
insertion but including my structure notation.


4 times, RUNME.CMD threw an "ffmpeg.exe - Application Error" exception:
"The instruction at 0x7FF6086540D9 referenced memory at 0x. The memory could 
not be read."

or
"The instruction at 0x referenced memory at 0x. The memory could 
not be written."

or
"The exception unknown software exception (0x4015) occurred in the application at location 
0x7FF6083E2424."



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ppsrc=1 decimation doesn't work or isn't correct or throws exception

2020-12-21 Thread Mark Filipak (ffmpeg)
I'm trying to file a bug report but there appears to be no way to get the report to you. I have some 
very short video samples and the ffmpeg report files. I spent 4 hours on this to make it so clear it 
will be very easy to replicate. But trac.ffmpeg.org won't accept it.


...Frustrated. Four hours. What a waste of my time.

On 12/21/2020 02:52 PM, Mark Filipak (ffmpeg) wrote:

Win10-1803.

The sources & fault documentaion files are here: To be determined -- trac.ffmpeg.org rejects it, too 
big (2,847,812 bytes) -- got any suggestions?



RUNME.CMD : ffmpeg -i preprocessed.mkv -i source.mkv -filter_complex 
"decimate='ppsrc=1'" target.mkv -y

I ran RUNME.CMD 40 times.

33 times, RUNME.CMD didn't do anything: target.mkv = 0 bytes.

3 times, RUNME.CMD seemed to work but the decimation was wrong.
source.mkv frames:   1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 
1028 1029
target.mkv frames are:   1018  1020 1021 1022 1023 1024 1025  1027 
1028 1029
target.mkv frames should be: 1018  1020 1021 1022 1023  1025 1026 1027 
1028

'source.mkv frames 1018-1029.png' shows a source fragment that was made prior to frame number 
insertion but including my structure notation.


4 times, RUNME.CMD threw an "ffmpeg.exe - Application Error" exception:
"The instruction at 0x7FF6086540D9 referenced memory at 0x. The memory could not 
be read."

or
"The instruction at 0x referenced memory at 0x. The memory could not 
be written."

or
"The exception unknown software exception (0x4015) occurred in the application at location 
0x7FF6083E2424."


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] ppsrc=1 decimation doesn't work or isn't correct or throws exception

2020-12-21 Thread Mark Filipak (ffmpeg)

Win10-1803.

The sources & fault documentaion files are here: To be determined -- trac.ffmpeg.org rejects it, too 
big (2,847,812 bytes) -- got any suggestions?



RUNME.CMD : ffmpeg -i preprocessed.mkv -i source.mkv -filter_complex 
"decimate='ppsrc=1'" target.mkv -y

I ran RUNME.CMD 40 times.

33 times, RUNME.CMD didn't do anything: target.mkv = 0 bytes.

3 times, RUNME.CMD seemed to work but the decimation was wrong.
source.mkv frames:   1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 
1028 1029
target.mkv frames are:   1018  1020 1021 1022 1023 1024 1025  1027 
1028 1029
target.mkv frames should be: 1018  1020 1021 1022 1023  1025 1026 1027 
1028

'source.mkv frames 1018-1029.png' shows a source fragment that was made prior to frame number 
insertion but including my structure notation.


4 times, RUNME.CMD threw an "ffmpeg.exe - Application Error" exception:
"The instruction at 0x7FF6086540D9 referenced memory at 0x. The memory could not 
be read."

or
"The instruction at 0x referenced memory at 0x. The memory could not 
be written."

or
"The exception unknown software exception (0x4015) occurred in the application at location 
0x7FF6083E2424."

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] frame number question

2020-12-20 Thread Mark Filipak (ffmpeg)

On 12/20/2020 01:49 PM, Paul B Mahol wrote:

On Sun, Dec 20, 2020 at 12:03 AM Mark Filipak (ffmpeg) 
wrote:

For the developers:
At what point are frame numbers assigned?


Libavfilter does not really care about frame numbers much.
It internally just count number of frames that get into filter and number
of frames that get out filter.


I would guess: When they leave the decoder. Am I right?


Decoder also does not care of frame numbers.


Example:
If '-vf decimate' removes frame[(n+1)%5==2], are frames renumbered at that
point or are the frames
left as frame[0], frame[2], frame[3], frame[4], frame[5], frame[7],
frame[8], frame[9], etc.

If you prefer I discover this on my own, that's okay, but I don't know how
to put the frame number
(as text) into the frames so that when I frame-step through the video I
can see the frame numbers.
If you could help with that, I'm pretty sure I can take the rest of the
needed steps on my own.


As mentioned above, each filter counts frame numbers from 0, and the frames
that goes out of filter are also starting from 0.
There are no gaps.


Ah! So, frame number, i.e. 'n' or %{n}, is a dynamically assigned number (starting with '0') that's 
reassigned, frame-by-frame, by each element of a filter chain.



Each frame that is decoded/filtered have no count number assigned to them
at all.
Understood: That frame number is not actually part of the video stream (TS or PS). I think that's 
what you meant.


Thanks, Paul. The information you supplied would make a good addition to the 
documentation.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] frame number question

2020-12-19 Thread Mark Filipak (ffmpeg)

For the developers:
At what point are frame numbers assigned?
I would guess: When they leave the decoder. Am I right?

Example:
If '-vf decimate' removes frame[(n+1)%5==2], are frames renumbered at that point or are the frames 
left as frame[0], frame[2], frame[3], frame[4], frame[5], frame[7], frame[8], frame[9], etc.


If you prefer I discover this on my own, that's okay, but I don't know how to put the frame number 
(as text) into the frames so that when I frame-step through the video I can see the frame numbers. 
If you could help with that, I'm pretty sure I can take the rest of the needed steps on my own.


Thanks Kindly,
Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] decimate=ppsrc question

2020-12-17 Thread Mark Filipak (ffmpeg)

On 12/17/2020 01:43 AM, Carl Eugen Hoyos wrote:




Am 17.12.2020 um 06:23 schrieb Mark Filipak (ffmpeg) :

ffmeg -i SOURCE -vf decimate=ppsrc TARGET


The decimate filter only makes sense in a filter chain after the fieldmatch 
filter.

Carl Eugen


The source video [1] is a 24p movie with a modulo 4 frame repeat (to 30p).

The command line I used:

ffmpeg -i SOURCE -map 0 -vf decimate -codec:v libx265 -x265-params crf=16:qcomp=1.00 -codec:a copy 
-codec:s copy -dn TARGET


ffmpeg did a fine job but there is still just a bit of jitter.

The question is this:
Can anyone kindly give me a usage example of this:

ffmeg -i SOURCE -vf decimate=ppsrc TARGET
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] decimate=ppsrc question

2020-12-16 Thread Mark Filipak (ffmpeg)

Can anyone kindly give me a usage example of this:
ffmeg -i SOURCE -vf decimate=ppsrc TARGET

I'm totally dumbfounded by this:
"ppsrc
Mark main input as a pre-processed input and activate clean source input stream. This allows 
the input to be pre-processed with various filters to help the metrics calculation while keeping the 
frame selection lossless. When set to 1, the first stream is for the pre-processed input, and the 
second stream is the clean source from where the kept frames are chosen. Default is 0."


Specifically:
"the first stream is for the pre-processed input": What is a pre-processed 
input? How processed?
"the second stream": What 2nd stream? Are there 2 inputs? If so, does that mean I need to use a 
filter complex? Or are there 2 passes? If so, how do I form the command line?

"clean source": What is a clean source? How is it made clean (whatever that 
means)?

Thanks for your help.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] FFMPEG has trouble processing file while VLC plays mp2ts just fine

2020-12-15 Thread Mark Filipak (ffmpeg)

On 12/15/2020 04:06 AM, serge2school wrote:

Hello,

I have a major problem trying to read a video file using ffmpeg, while VLC
has no trouble replaying it.

The video file can be processed by ffmpeg, but it loses pts, skips multiple
frames, and overall acts if video is broken.  This is especially evident
with silencedetect ... in VLC everything is pristine. Can someone please
help?


My experience in such cases is to run a test by transcoding video only and excluding audio ('-an'). 
If that works, then remux the transcodeed video with the original audio and subtitles and you're 
done. I don't know why that works but I suspect the audio has some time stamp errors that are 
leading ffmpeg astray.



ffmpeg -i dd.m2ts -af silencedetect=noise=0.001 -f null -
ffmpeg version 3.4.8-0ubuntu0.2 Copyright (c) 2000-2020 the FFmpeg
developers
   built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
   configuration: --prefix=/usr --extra-version=0ubuntu0.2
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libflite --enable-libfontconfig
--enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm
--enable-libmp3lame --enable-libmysofa --enable-libopenjpeg
--enable-libopenmpt --enable-libopus --enable-libpulse
--enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy
--enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora
--enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid
--enable-libzmq --enable-libzvbi --enable-omx --enable-openal
--enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm
--enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv
--enable-libx264 --enable-shared
   libavutil  55. 78.100 / 55. 78.100
   libavcodec 57.107.100 / 57.107.100
   libavformat57. 83.100 / 57. 83.100
   libavdevice57. 10.100 / 57. 10.100
   libavfilter 6.107.100 /  6.107.100
   libavresample   3.  7.  0 /  3.  7.  0
   libswscale  4.  8.100 /  4.  8.100
   libswresample   2.  9.100 /  2.  9.100
   libpostproc54.  7.100 / 54.  7.100
[mpeg2video @ 0x557cbc2dede0] Invalid frame dimensions 0x0.
 Last message repeated 2 times
[mpegts @ 0x557cbc2da840] start time for stream 3 is not set in
estimate_timings_from_pts
[mpegts @ 0x557cbc2da840] PES packet size mismatch
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 4
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 5
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 6
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 7
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 8
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 9
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 10
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 11
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
[mpegts @ 0x557cbc2da840] Could not find codec parameters for stream 12
(Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
Input #0, mpegts, from 'dd.m2ts':
   Duration: 00:01:00.52, start: 12727.730011, bitrate: 16626 kb/s
   Program 1040
 Metadata:
   service_name: F|%F%l?1
   service_provider:
 Stream #0:0[0x111]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002),
yuv420p(tv, bt709, top first), 1440x1080 [SAR 4:3 DAR 16:9], 29.97 fps,
29.97 tbr, 90k tbn, 59.94 tbc
 Stream #0:1[0x112]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz,
stereo, fltp, 246 kb/s
 Stream #0:2[0x116]: Data: bin_data ([6][0][0][0] / 0

[FFmpeg-user] ffmpeg x265 report v. '-x265-params' -- guide desired

2020-12-11 Thread Mark Filipak (ffmpeg)

I did a transcode from H.264 to H.265 via Handbrake, then tried ffmpeg. Results:
  74,903,299 bytes  made_via_handbrake.mkv   ...beautiful
  25,038,616 bytes  made_via_ffmpeg.mkv   ...a bit of plastic-face -- full 
output at end

So, I need to tweak ffmpeg's x265 parameters, but how?

How can I relate this output:
  x265 [info]: HEVC encoder version 3.4+27-g5163c32d7
  x265 [info]: build info [Windows][GCC 10.2.0][64 bit] 8bit+10bit+12bit
  x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX 
FMA3 BMI2 AVX2
  x265 [info]: Main profile, Level-4 (Main tier)
  x265 [info]: Thread pool created using 8 threads
  x265 [info]: Slices  : 1
  x265 [info]: frame threads / pool features   : 3 / wpp(17 rows)
  x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
  x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
  x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
  x265 [info]: Keyframe min / max / scenecut / bias  : 23 / 250 / 40 / 5.00
  x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2
  x265 [info]: b-pyramid / weightp / weightb   : 1 / 1 / 0
  x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
  x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
  x265 [info]: Rate Control / qCompress: CRF-28.0 / 0.60
  x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
  x265 [info]: tools: b-intra strong-intra-smoothing lslices=6 deblock sao
with the list of options here: https://ffmpeg.org/ffmpeg-codecs.html#Options-30?

There is a clue (I think): "x265 --help"... I stumbled on this:
https://ffmpeg.org/general.html#x265.
On that page is a link to here:
http://x265.org/developers.html.
I took the link but was almost immediately assaulted by a pornographic game.

Oh, dear. Does anyone have a guide to x265 they can share?



ffmpeg -i b:\BDMV\STREAM\00204.m2ts -map 0 -codec:v libx265 -codec:a copy -codec:s copy 
made_via_ffmpeg.mkv
ffmpeg version 2020-12-09-git-e5119a-full_build-www.gyan.dev Copyright (c) 2000-2020 the FFmpeg 
developers

  built with gcc 10.2.0 (Rev5, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads 
--disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 
--enable-gmp --enable-lzma --enable-libsnappy --enable-zlib --enable-libsrt --enable-libssh 
--enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 
--enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp 
--enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg 
--enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi 
--enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid 
--enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx 
--enable-libglslang --enable-vulkan --enable-opencl --enable-libcdio --enable-libgme 
--enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame 
--enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc 
--enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis 
--enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband 
--enable-libsoxr --enable-chromaprint

  libavutil  56. 62.100 / 56. 62.100
  libavcodec 58.115.102 / 58.115.102
  libavformat58. 65.100 / 58. 65.100
  libavdevice58. 11.103 / 58. 11.103
  libavfilter 7. 92.100 /  7. 92.100
  libswscale  5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc55.  8.100 / 55.  8.100
[mpegts @ 026acb0fb4c0] start time for stream 2 is not set in 
estimate_timings_from_pts
[mpegts @ 026acb0fb4c0] start time for stream 3 is not set in 
estimate_timings_from_pts
[mpegts @ 026acb0fb4c0] start time for stream 4 is not set in 
estimate_timings_from_pts
[mpegts @ 026acb0fb4c0] Could not find codec parameters for stream 2 (Subtitle: 
hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090)): unspecified size

Consider increasing the value for the 'analyzeduration' (0) and 'probesize' 
(500) options
[mpegts @ 026acb0fb4c0] Could not find codec parameters for stream 3 (Subtitle: 
hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090)): unspecified size

Consider increasing the value for the 'analyzeduration' (0) and 'probesize' 
(500) options
[mpegts @ 026acb0fb4c0] Could not find codec parameters for stream 4 (Subtitle: 
hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090)): unspecified size

Consider increasing the value for the 'analyzeduration' (0) and 'probesize' 
(500) options
Input #0, mpegts, from 'b:\BDMV\STREAM\00204.m2ts':
  Duration: 00:02:38.98, start: 11.650667, bitrate: 18758 kb/

Re: [FFmpeg-user] DV to bob deinterlaced HEVC

2020-11-12 Thread Mark Filipak (ffmpeg)

On 11/12/2020 02:10 PM, Matti Haveri wrote:

My current plan to convert 4:3 PAL .dv to HEVC as a batch:

for i in *.dv; do ffmpeg -i "$i"
-vf bwdif=1,scale=788:576,crop=768:576:10:0,setsar=sar=1/1
-c:v libx265 -crf 18 -preset slow -tag:v hvc1
-c:a aac -b:a 128k "${i%.*}_converted.mp4"; done

In my tests bwdif has less artifacts than yadif.

I guess it is better to deinterlace first, then scale?

4:3 PAL .dv 720x576 (PAR 128/117) to square pixels:

a) scale to 788x576 then crop to 768x576 or:
b) crop to 702x576 then scale to 768x576

http://web.archive.org/web/20140218044518/http://lipas.uwasa.fi/~f76998/video/conversion/

I chose to scale, then crop because the different order
'crop=702:576:9:0,scale=768:576' produces the following alert
(maybe this is just a cosmetic issue?):

"[swscaler @ 0x1123e2000] Warning: data is not aligned!
This can lead to a speed loss"

I guess it doesn't matter in which order libx265 options -crf, -preset
etc are?

CRF 18-20(-22) seems like a sweet spot. CRF 24 or higher produce very
ugly artifacts to noisy parts of the footage.

There seems to be not much or any difference in quality between
-preset slow vs medium.

25fps vs 50fps difference is there but not so great as I expected.

- Matti
Do some research, Matti. If the PAL DVD is a movie, note its running time and compare to an NTSC DVD 
or Blu-ray running time. If the PAL DVD running time is 4% fast, then the video is actually p24. For 
movies, that's almost always the case. If so, try forcing 24FPS and let me know how it goes. If the 
video is okay (and it probably will be), then you will need to extract the audio, subs, and chapters 
separately, stretch them by 25/24, and merge them with the video -- you could try mkvmerge (or 
MKVToolNixGUI). Again, let me know how it goes.


Regards,
Mark.

--
11 Nov 2020 -- early in the pandemic.
Yesterday's new cases, China: 17, S.Korea: 146, U.S.: 142,906.
Yesterday's new deaths, China: 0, S.Korea: 2, U.S.: 1,479.
Today, U.S.: 4% of world population, 20% of cases, 19% of deaths.
Today, U.S. mortality: Of 7,143,501 resolved cases, 4% are dead.
Today, U.S. dead, pandemic: 247,398 (9 mo.), WWII: 419,000 (47 mo.).
Today, U.S. total cases: 3.2%. To reach herd immunity: at least 60%.
2021+ (no vaccine), U.S. reaches herd immunity, 8-million U.S. dead.
22 Jan: U.S. & S.Korea report 1st cases on the same day.
 6 Mar, testing to date, S.Korea: 140,000, U.S.: 2000.
 6 Mar, test results, S.Korea: 4 hours, U.S.: 1 to 2 weeks.
 1 Jun, total care-home deaths, S.Korea: 0, U.S.: 33,000 +/- 7,000.
 5 Aug, U.S. testing: only 1/4 of number needed; 4 day results.
 1 Sep, Nursing Assoc report: Over 60% of U.S. nurses lack PPE.
18 Sep, U.S. doctors & nurses still acutely lack PPE; 1200 dead.
15 Oct, projected GDP, China: up 1.9%, U.S.: down 3.6%.
19 Oct, CDC report: U.S. test results still take 3 days, average.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] sudo: ffmpeg: command not found

2020-10-29 Thread Mark Filipak (ffmpeg)

On 10/29/2020 02:09 PM, amindfv--- via ffmpeg-user wrote:

On Thu, Oct 29, 2020 at 10:38:58AM +0100, Reindl Harald wrote:

jesus christ how dumb are people?


Nobody is born knowing how to install ffmpeg; seems like more of a lack of 
knowledge than intelligence, and others on the mailing list were happy to pass 
along that knowledge.


It's pointless to 'reason' with Reindl. His rudeness is incurable. When I read his posts, I don't 
have to look at who wrote it. I know it's him.


--
29 Oct 2020 -- early in the pandemic.
Yesterday, new cases, China: 42, S.Korea: 103, U.S.: 81,581.
Today, U.S.: 4% of world population, 20% of cases, 20% of deaths.
Today, U.S. mortality: Of 6,166,342 resolved cases, 4% are dead.
Today, U.S. dead, pandemic: 233,130 (9 mo.), WWII: 419,000 (47 mo.).
Today, U.S. total cases: 2.8%, to reach herd immunity: at least 60%.
2021+ (no vaccine), U.S. reaches herd immunity, 8-million U.S. dead.
22 Jan: U.S. & S.Korea report 1st cases on the same day.
 6 Mar, testing to date, S.Korea: 140,000, U.S.: 2000.
 6 Mar, test results, S.Korea: 4 hours, U.S.: 1 to 2 weeks.
 1 Jun, total care-home deaths, S.Korea: 0, U.S.: 33,000 +/- 7,000.
 5 Aug, U.S. testing: only 1/4 of number needed; 4 day results.
 1 Sep, Nursing Assoc report: Over 60% of U.S. nurses lack PPE.
18 Sep, U.S. doctors & nurses still acutely lack PPE; 1200 dead.
15 Oct, projected GDP, China: up 1.9%, U.S.: down 3.6%.
19 Oct, CDC report: U.S. test results still take 3 days, average.
22 Oct, U.S. President: "We're rounding the corner. It's going away."
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] MPEG TS+PS parser

2020-10-16 Thread Mark Filipak (ffmpeg)

On 10/16/2020 10:14 PM, Carl Zwanzig wrote:

On 10/15/2020 1:44 AM, Mark Filipak (ffmpeg) wrote:

Got any suggestions how I should proceed?


I hate to say this, but you're rather reinventing the wheel (and building it 
out of toothpicks).


You're absolutely right, Carl.


There are a fair number of mpeg-ts parsers already out there in a variety of 
languages ...


Really? Do you mean VOBEdit? All that I've seen are formatted as pretty pictures and all that I've 
seen have errors. I want a plain text format but I can't paste it here because it's too wide for email.


... and the kind 
of structure you've used is going to be slow and resource-intensive. If nothing else, if you're 
using the bash shell use a case statement to separate out the translations (instead of passing 
everything through one HUGE pipeline).


(This is not a task for pattern substitution.)


Oh, I know that. I just wanted to get started. Looking at the output (such as it is), I could see 
cases where, for example, bogus start_codes (\x00 00 01) are inside private streams (and elsewhere).


I used SNOBOL about 35 years ago to quickly write very powerful parsers. I'm 
looking at Unicon now.

--
Pandemic perspective, 17 October 2020 - early in the pandemic:
Yesterday, China: 24 new cases, S.Korea: 47, U.S.: 71,687.
Today, U.S.: 4% of world population, 21% of cases, 20% of deaths.
Today, U.S. dead, pandemic (8 mo): 223,644, WWII (4 yrs): 419,000.
Today, U.S.: Of 5,619,045 resolved cases, 96% lived, 4% 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, S.Korea: 0 total care-home deaths, U.S.: 33,000 +/- 7,000.
5 Aug: U.S. tests still only 1/4 of number needed; 4 day results.
1 Sep: Over 60% of U.S. nurses report lack of protective equipment.
18 Sep: U.S. doctors & nurses still acutely lack PPE; 1200 dead.
?? 2021: U.S. gains herd immunity, 10 million dead, civil conflict.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] search a DVD via the following regex - small correction

2020-10-11 Thread Mark Filipak (ffmpeg)

Sorry, I left out a '|', now corrected.

I need a way to search a DVD via the following regex, then display the hex of the captured bytes; 
either a Windows or a Linux method will do.


/\x00\x00\x01\xB5(\x11.|\x12.|\x13.|\x14[^\x82]|\x15.|\x16.|\x17.|\x18.|\x19.|\x1A.|\x1B.|\x1C.|\x1D.|\x1E.|\x1F.)/

The DVD barcode and returned captured bytes would be very valuable to me (and perhaps to many 
users). A script that I could run on my own would really float my boat.


Thanks so much,
Mark.

Of course you want to know why, eh?

I have yet to see a DVD that has this: 0x00 00 01 B5 1? ??, where '? ??' is other than '4 82' (i.e. 
MP@ML plus !progressive_sequence plus 4:2:0). The above regex performs such a match.


It's the 'sequence_extension' header ID metadata followed by 'profile_and_level_indication' -- the 
allowed combinations are shown in the table, below -- followed by 'progressive_sequence' followed by 
'chroma_format'.


0x00 00 01 B5 11 2 High@HighP
0x00 00 01 B5 11 4 High@High
0x00 00 01 B5 11 6 High@High1440
0x00 00 01 B5 11 8 High@Main
0x00 00 01 B5 11 A High@Low
0x00 00 01 B5 12 2 SpaciallyScalable@HighP
0x00 00 01 B5 12 4 SpaciallyScalable@High
0x00 00 01 B5 12 6 SpaciallyScalable@High1440
0x00 00 01 B5 12 8 SpaciallyScalable@Main
0x00 00 01 B5 12 A SpaciallyScalable@Low
0x00 00 01 B5 13 2 SNRScalable@HighP
0x00 00 01 B5 13 4 SNRScalable@High
0x00 00 01 B5 13 6 SNRScalable@High1440
0x00 00 01 B5 13 8 SNRScalable@Main
0x00 00 01 B5 13 A SNRScalable@Low
0x00 00 01 B5 14 2 Main@HighP
0x00 00 01 B5 14 4 Main@High
0x00 00 01 B5 14 6 Main@High1440
0x00 00 01 B5 14 8 Main@Main<<== all DVDs?
0x00 00 01 B5 14 A Main@Low
0x00 00 01 B5 15 2 Simple@HighP
0x00 00 01 B5 15 4 Simple@High
0x00 00 01 B5 15 6 Simple@High1440
0x00 00 01 B5 15 8 Simple@Main
0x00 00 01 B5 15 A Simple@Low
0x00 00 01 B5 18 E Multi-view@Low
0x00 00 01 B5 18 D Multi-view@Main
0x00 00 01 B5 18 B Multi-view@High1440
0x00 00 01 B5 18 A Multi-view@High
0x00 00 01 B5 18 5 4:2:2@Main
0x00 00 01 B5 18 2 4:2:2@High

--
COVID-19 update:
28 Sep, U.S. deaths pass half of all U.S. dead in 4 years of WWII.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] search a DVD via the following regex

2020-10-11 Thread Mark Filipak (ffmpeg)
I need a way to search a DVD via the following regex, then display the hex of the captured bytes; 
either a Windows or a Linux method will do.


/\x00\x00\x01\xB5(\x11.|\x12.|\x13.|\x14[^\x82]|\x15.|\x16.|\x17.|\x18.|\x19.|\x1A.|\x1B.|\x1C.|\x1D.|\x1E.\x1F.)/

The DVD barcode and returned captured bytes would be very valuable to me (and perhaps to many 
users). A script that I could run on my own would really float my boat.


Thanks so much,
Mark.

Of course you want to know why, eh?

I have yet to see a DVD that has this: 0x00 00 01 B5 1? ??, where '? ??' is other than '4 82' (i.e. 
MP@ML plus !progressive_sequence plus 4:2:0). The above regex performs such a match.


It's the 'sequence_extension' header ID metadata followed by 'profile_and_level_indication' -- the 
allowed combinations are shown in the table, below -- followed by 'progressive_sequence' followed by 
'chroma_format'.


0x00 00 01 B5 11 2 High@HighP
0x00 00 01 B5 11 4 High@High
0x00 00 01 B5 11 6 High@High1440
0x00 00 01 B5 11 8 High@Main
0x00 00 01 B5 11 A High@Low
0x00 00 01 B5 12 2 SpaciallyScalable@HighP
0x00 00 01 B5 12 4 SpaciallyScalable@High
0x00 00 01 B5 12 6 SpaciallyScalable@High1440
0x00 00 01 B5 12 8 SpaciallyScalable@Main
0x00 00 01 B5 12 A SpaciallyScalable@Low
0x00 00 01 B5 13 2 SNRScalable@HighP
0x00 00 01 B5 13 4 SNRScalable@High
0x00 00 01 B5 13 6 SNRScalable@High1440
0x00 00 01 B5 13 8 SNRScalable@Main
0x00 00 01 B5 13 A SNRScalable@Low
0x00 00 01 B5 14 2 Main@HighP
0x00 00 01 B5 14 4 Main@High
0x00 00 01 B5 14 6 Main@High1440
0x00 00 01 B5 14 8 Main@Main<<== all DVDs?
0x00 00 01 B5 14 A Main@Low
0x00 00 01 B5 15 2 Simple@HighP
0x00 00 01 B5 15 4 Simple@High
0x00 00 01 B5 15 6 Simple@High1440
0x00 00 01 B5 15 8 Simple@Main
0x00 00 01 B5 15 A Simple@Low
0x00 00 01 B5 18 E Multi-view@Low
0x00 00 01 B5 18 D Multi-view@Main
0x00 00 01 B5 18 B Multi-view@High1440
0x00 00 01 B5 18 A Multi-view@High
0x00 00 01 B5 18 5 4:2:2@Main
0x00 00 01 B5 18 2 4:2:2@High

--
COVID-19 update:
28 Sep, U.S. deaths pass half of all U.S. dead in 4 years of WWII.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-04 Thread Mark Filipak (ffmpeg)

Correction:
"if your sampling frequency exceeds Nyquist" was "if your sampling frequency exceeds Nyquist/2" 
(which was an inadvertent mistake). Sorry.



On 10/04/2020 09:44 PM, Anatoly wrote:

On Sun, 4 Oct 2020 10:37:41 -0400

-snip-

Are you watched "Part 2" ?
https://www.youtube.com/watch?v=ht4Mv2wIRyQ


I don't think spacial image resolution is
related to frequency at all.

Then watch mentioned above video at 8:07
He didnt explain this, but those plots actually is so called frequency
responces (attenuation vs frequency).
What do you see on upper plot there?


What the upper graph shows is the frequency response of the serial bitstream from the photosite 
array through the analog-to-digital converter. Nyquist does indeed apply to that, but only because 
the camera forms the samples in a limited amount of time and the analog-to-digital converter is 
multiplexed (shared) by the photosites -- Fo is the sampling frequency, so the resolution of the 
analog-to-digital converter is artificially limited (filtered) to Fo/2. But that is not directly a 
property of the picture's resolution. It's a property of the camera design that limits the camera's 
resolution. Pictures are not made of sine waves. Coded pictures are DCT encoded but Nyquist has 
nothing to do with that part because DCT is done entirely in the digital domain, after sampling, and 
time is not a factor in the digital domain.


The sampling system limits resolution, yes. And that limit is Fo/2, yes. But pictures don't have a 
Nyquist frequency, no matter what number of samples/line or lines/frame. And pictures are not made 
of sine waves. You are getting lost in the camera design.



X axis is "spatial frequency / line pairs" as distance between two pairs
of lines of picture of alternating black and white lines.


(line pairs)/(picture height) -- I assume "line pairs" means the horizontal distance between 
vertical lines -- is a pretty odd frequency scale, and calling that a spacial frequency is pretty 
bogus. The bottom line is this: Nyquist applies to serial analog-to-digital conversion frequency, 
not to the ultimate resolution. It says that if your sampling frequency exceeds Nyquist, you're 
going to get aliasing. That's the kernel of the presentation and you are misinterpreting what is 
being presented.


In other words, the Nyquist frequency is a function of each particular camera and the frequency at 
which that camera does analog-to-digital conversion.


The premise that to get 720x480, frames should be sampled at 1440x960 is bogus. I've read that so 
many times that I put it into the glossary without really thinking about it. But it's wrong.


Oh, and did I say that pictures are not made of sine waves?

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-04 Thread Mark Filipak (ffmpeg)

On 10/04/2020 09:44 PM, Anatoly wrote:

On Sun, 4 Oct 2020 10:37:41 -0400

-snip-

Are you watched "Part 2" ?
https://www.youtube.com/watch?v=ht4Mv2wIRyQ


I don't think spacial image resolution is
related to frequency at all.

Then watch mentioned above video at 8:07
He didnt explain this, but those plots actually is so called frequency
responces (attenuation vs frequency).
What do you see on upper plot there?


What the upper graph shows is the frequency response of the serial bitstream from the photosite 
array through the analog-to-digital converter. Nyquist does indeed apply to that, but only because 
the camera forms the samples in a limited amount of time and the analog-to-digital converter is 
multiplexed (shared) by the photosites -- Fo is the sampling frequency, so the resolution of the 
analog-to-digital converter is artificially limited (filtered) to Fo/2. But that is not directly a 
property of the picture's resolution. It's a property of the camera design that limits the camera's 
resolution. Pictures are not made of sine waves. Coded pictures are DCT encoded but Nyquist has 
nothing to do with that part because DCT is done entirely in the digital domain, after sampling, and 
time is not a factor in the digital domain.


The sampling system limits resolution, yes. And that limit is Fo/2, yes. But pictures don't have a 
Nyquist frequency, no matter what number of samples/line or lines/frame. And pictures are not made 
of sine waves. You are getting lost in the camera design.



X axis is "spatial frequency / line pairs" as distance between two pairs
of lines of picture of alternating black and white lines.


(line pairs)/(picture height) -- I assume "line pairs" means the horizontal distance between 
vertical lines -- is a pretty odd frequency scale, and calling that a spacial frequency is pretty 
bogus. The bottom line is this: Nyquist applies to serial analog-to-digital conversion frequency, 
not to the ultimate resolution. It says that if your sampling frequency exceeds Nyquist/2, you're 
going to get aliasing. That's the kernel of the presentation and you are misinterpreting what is 
being presented.


In other words, the Nyquist frequency is a function of each particular camera and the frequency at 
which that camera does analog-to-digital conversion.


The premise that to get 720x480, frames should be sampled at 1440x960 is bogus. I've read that so 
many times that I put it into the glossary without really thinking about it. But it's wrong.


Oh, and did I say that pictures are not made of sine waves?

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-04 Thread Mark Filipak (ffmpeg)

On 10/04/2020 03:52 AM, Rodney Baker wrote:

On Sunday, 4 October 2020 7:13:20 ACDT Mark Filipak (ffmpeg) wrote:

On 10/03/2020 02:05 PM, Anatoly wrote:

On Sat, 3 Oct 2020 11:05:03 -0400


-snip-


You should learn than what spectrum is.


Oh, please. Be easy with me. I'm just a simple electrical engineer.


And how any complex waveform
(with it's "information density") may be represented as a sum of many
simple sinewaves.


Ah, now that would be a Taylor series, no? It's been about 4-1/2 decades but
I think it's a Taylor series.


[...]

Fourier, not Taylor. All images are made up of sine waves.


You're kidding, eh?

I just posted this: Demystifying Digital Camera Specifications (was Glossary: 
Nyquist)

You should read it.

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Demystifying Digital Camera Specifications (was Glossary: Nyquist)

2020-10-04 Thread Mark Filipak (ffmpeg)



Demystifying Digital Camera Specifications

Here:
https://www.provideocoalition.com/panavision_posts_demystifying_digital_camera_specifications_videos/
is a blog by Jim Feeley that mentions a video presentation by John Galt of Panavision and Larry 
Thorpe of Canon titled "Demystifying Digital Camera Specifications".


The link that Jim Feeley provides is dead. I've searched for a current link so that I could share it 
here but I couldn't find the video.


I have it, either complete or as 7 parts.

20-08-10  19:04   397,590,171 Demystifying Digital Camera Specifications 
.mkv
20-08-10  18:5176,493,280 Demystifying Digital Camera Specifications, 
Pt 1 .mkv
20-08-10  18:5443,846,576 Demystifying Digital Camera Specifications, 
Pt 2 .mkv
20-08-10  18:5646,831,671 Demystifying Digital Camera Specifications, 
Pt 3 .mkv
20-08-10  18:57   106,638,385 Demystifying Digital Camera Specifications, 
Pt 4 .mkv
20-08-10  18:5745,627,889 Demystifying Digital Camera Specifications, 
Pt 5 .mkv
20-08-10  18:5828,933,720 Demystifying Digital Camera Specifications, 
Pt 6 .mkv
20-08-10  18:5849,218,650 Demystifying Digital Camera Specifications, 
Pt 7 .mkv

Anyone who wants one or all should contact me.
-OR-
Part 1 is on youtube: https://www.youtube.com/watch?v=gqq8QKMmtYg
I assume the other parts are there, too.


On 10/04/2020 05:00 AM, Anatoly wrote:

On Sat, 3 Oct 2020 21:22:38 -0400
"Mark Filipak (ffmpeg)"  wrote:



Here's what I visualize:
Imagine a heat map -- one of those colorful images ...reds and
yellows and greens and blues. Then, imagine a screen in front of it,
between you and the heat map. The screen is the final samples (ex:
720x480).

Now write down temperature for every cell of your screen and draw x-Y
plot: temperature vs cell number in grid line.


That's sampling.


I think you'll agree that neither the screen nor the underlying heat
map are serial in nature. Oh, they're transported as a sort-of raster

That doesn't really matter. Now you have x-Y plot of some function and
you can process it mathematically as you wish.


I totally agree.


-- that's for sure -- but that's not how they're made and I don't
think that Fourier applies.

Then you must dont't think that you can JPEG compress your screen
image, because all JPEG/MPEG-like things works that way.


Compression and resolution aren't related. Compression that is lossy spoils resolution, but that 
doesn't mean that there's a functional relationship between them.


You know, I'm going to remove reference to Nyquist. I don't think spacial image resolution is 
related to frequency at all. I don't think that the photons that fall on one pixel affect the 
photons that fall on nearby pixels in any way -- I'm discounting quantum mechanics for the 
pixel-to-pixel distances involved. That 'said', if the resulting image is scanned, rastered into 
lines of pixel values and sent as a serial analog signal, then Nyquist definitely applies. But 
that's not what's happening in a CCD or in the human eye.


There is an exception. If a CCD's photosensors are 'read' and analog-to-digital converted serially 
(one photosensor at a time) -- and that is probably the case -- then Nyquist most definitely 
applies, but it applies to the analog-to-digital conversion, not to some fictional analog 
'frequency' within the image.


I think people have taken a temporal channel concept (Nyquist) and have tried to stretch it to fit a 
spacial situation. I don't buy it. Photons that are broadside loaded into a camera (or into an eye) 
is not a serial stream (i.e. not a raster). Nyquist doesn't apply.



Thank you. Do you think I should just post the whole thing? I can't.

Not here, but maybe on github?


Not github. I'm a human being. Github is for Martians.

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-03 Thread Mark Filipak (ffmpeg)

On 10/03/2020 05:12 PM, Michael Koch wrote:

Am 03.10.2020 um 22:43 schrieb Mark Filipak (ffmpeg):

On 10/03/2020 02:05 PM, Anatoly wrote:

On Sat, 3 Oct 2020 11:05:03 -0400

-snip-

You should learn than what spectrum is.


Oh, please. Be easy with me. I'm just a simple electrical engineer.


And how any complex waveform
(with it's "information density") may be represented as a sum of many
simple sinewaves.


Ah, now that would be a Taylor series, no?


Joseph Fourier just turned around in his grave...

Michael


Well, I've done some reading and it appears I need to tuck my tail between my legs and slink away. 
From what I've read, Nyquist sampling is in the frequency domain, but I honestly don't see how 
Fourier applies to spacial resolution, even given that MTF is used to characterize CCD and CMOS 
response. Bear with me now...


Here's what I visualize:
Imagine a heat map -- one of those colorful images ...reds and yellows and greens and blues. Then, 
imagine a screen in front of it, between you and the heat map. The screen is the final samples (ex: 
720x480). The underlying heat map could also be 720x480, but if it is of higher resolution (ex: 
1440x960), then the slope of color changes in the heat map are more precise and the positions of the 
true colors that show through the screen (manifested as more accurate values) are slightly more 
accurate. It's equivalent to rescreening a screened print image (ex: 200 dpi rescreened to 100 dpi).


I think you'll agree that neither the screen nor the underlying heat map are serial in nature. Oh, 
they're transported as a sort-of raster -- that's for sure -- but that's not how they're made and I 
don't think that Fourier applies.


The reason I cite a heat map rather than an ordinary image is that it makes it easier to visualize 
the image formed as an energy distribution; an energy map if you will -- heat is energy.


The physical response to energy is not instantaneous. Responding to energy change requires time, and 
looking up & down or left & right, for example, exposes your eyes to changing energy. So it's a 
2-step process: 1, the response of the sampling process to the underlying heat map, and 2, the 
response of your eyes to the content of the samples (i.e. the screen). That's what I meant by double 
gaussian.


Why gaussian? Every real case of energy transfer that I've seen (outside of quantum mechanics) is 
ruled and regulated by gaussian factors, from fluid flow to capacitor charge. Is the exponential 
function gaussian. Gosh, I think so, but I can't find any justification right now.


I've consulted my copy of Feynman but he didn't have anything to say about 
Nyquist.

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-03 Thread Mark Filipak (ffmpeg)

On 10/03/2020 08:09 PM, Jim DeLaHunt wrote:

On 2020-10-03 08:44, Mark Filipak (ffmpeg) wrote:
-snip-> When you say, "My goal (for a long time) is to differentiate hard telecine from pseudo NTSC 
(which
I'm calling d-NTSC).… [using] MPEG-PS metadata", it sounds to that your goal is to describe 
different content structures in the context of an MPEG-PS stream.


That is exactly what I'm doing. I've been (manually) parsing a lot of video sequences (meaning the 
stream beginning with 'sequence_header_code': 0x00 00 01 B3, and ending with 'sequence_end_code': 
(0x00 00 01 B7 -- I'm not interested in the transport packages, though I've parsed them, too) 
looking for clues to formats. I spent over a month just figuring out macroblock structures.


The right document for doing this 
work is a guide to or explanation of MPEG-PS stream contents. As part of describing a content 
structure, it is probably quite helpful to list the metadata values which identify that structure. 
But this document is not a glossary.


Why not? (That question is rhetorical ... I appreciate that you have a right to 
your own opinion.)

It also sounds to me like you are coining the term "d-NTSC" to name one kind of content structure. 
It is perfectly in scope to define names in such a guide or explanation.  But it sounds like you 
aren't claiming that the term "d-NTSC" is [also] defined by some other document, such as the H.262 
specification. Fine.


H.262 (and presumably MPEG) don't name things. For example, H.262 refers to d-NTSC & d-PAL (i.e. 
scan-frames) by citing metadata thusly: "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 [1] 
exists between (corresponding spatial samples) of the two fields." -- how cumbersome! I'm just 
assigning names to the 30/1.001 Hz & 25 Hz versions.


In the glossary, I would expect to see a term, e.g. "d-NTSC", and then one or more entries 
describing meanings of that term, each with an explanation of the term and a cross-reference to 
where the term is defined or used in an important way, e.g. to "Mark's Guide to MPEG-PS Stream 
Content Structures", section X.Y, "pseudo-NTSC content".


Or simply put, what you are drafting in this thread is an entry in Mark's Guide to MPEG-PS, not a 
glossary entry. In my humble opinion.


So, I take it that, to you, a glossary is a snack whereas a meal must be some sort of treatise and 
that you think a meal is required. I disagree, but maybe you're right.


Perhaps a presentation of my motives is in order? -- I DO have an axe to grind. 
:-)

Treatises drive me nuts. I better understand a complicated subject by hacking between and among 
concise definitions. I rarely read treatises because they always seem to explain by citing use 
cases. With each use case, the architecture comes into better focus, but it does take relearning 
over and over and that takes so much time. I'm a computer system architect. Kindly just give me the 
structure and the procedure and I'll put it together. I don't need use cases. (Code would probably 
be sufficient, but I don't know 'C'.)


When presented with a treatise, what I do is scan it -- I never exhaustively read it -- and build a 
glossary. Then, to really understand the topic, I scan the glossary, pulling threads together in my 
mind until I've formed an architecture. Then I test the architecture against the treatise's use 
cases. I don't think I'm alone in this. In the case of ffmpeg, everything seems to be use cases and 
it drives me postal.


--
--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-03 Thread Mark Filipak (ffmpeg)

On 10/03/2020 05:12 PM, Michael Koch wrote:

Am 03.10.2020 um 22:43 schrieb Mark Filipak (ffmpeg):

On 10/03/2020 02:05 PM, Anatoly wrote:

On Sat, 3 Oct 2020 11:05:03 -0400

-snip-

You should learn than what spectrum is.


Oh, please. Be easy with me. I'm just a simple electrical engineer.


And how any complex waveform
(with it's "information density") may be represented as a sum of many
simple sinewaves.


Ah, now that would be a Taylor series, no?


Joseph Fourier just turned around in his grave...


Is Nyquist a consequent of Fourier or Taylor?

The factor in spacial resolution is not sampling frequency or whether the sampling clock is a square 
wave or any particular wave. It's geometric. It's the geometry of the energy that reaches the eye 
and the eye's response (rods & cones). I think the issue is one of gaussian response, an issue of slope.


The gaussian rules the world of analog to digital conversion just as it rules the world of particle 
interactions. I don't see Fourier as applying to that.


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-03 Thread Mark Filipak (ffmpeg)

On 10/03/2020 02:05 PM, Anatoly wrote:

On Sat, 3 Oct 2020 11:05:03 -0400

-snip-

You should learn than what spectrum is.


Oh, please. Be easy with me. I'm just a simple electrical engineer.


And how any complex waveform
(with it's "information density") may be represented as a sum of many
simple sinewaves.


Ah, now that would be a Taylor series, no? It's been about 4-1/2 decades but I think it's a Taylor 
series.



Then you'll understand that all that may be simplified to the
picture I draw, and to that the definition of Nyquist-Shannon theorem
literally states (again):
"If a function x(t) contains no frequencies higher than B hertz, it is
completely determined by giving its ordinates at a series of points
spaced 1/(2B) seconds apart.
A sufficient sample-rate is therefore anything larger 2B samples per
second."


Again, you bring up signals and sample rate. A video frame is not a signal. A camera or a film 
scanner has a sample rate, but that sample rate is not bandwidth limited -- i.e. there is no 
(realistic) limit to the analog image frequency, so 2B samples is meaningless. Even for a single, 
static picture, Nyquist still applies.


Sorry, but I don't see that you disagree with my glossary entry:

Nyquist sampling: The principle [1] that, to most faithfully reproduce an image at a given digital 
display's resolution, samples must be made at or above twice the display's resolution, both 
horizontally & vertically.
[1] The Nyquist principle applies to film sampling and to digital cameras, but, provided that 
resolution is unchanged, not to transcoding (because the transcoder inputs are already digital). As 
proved by the improved sharpness of SD media made from 2K flim samples, SD mastering prior to the 
advent of 2K sampling (e.g. DVDs mastered from film before the advent of HD) generally ignored the 
Nyquist principle and were undersampled. HDs sampled at 2K and 4K UHDs are likewise undersampled.



Maybe it's a fun to discuss such a things, but I think here is not
right place to do it, beacuse it has no straight relation to ffmpeg
usage.


If not ffmpeg.org, then where? doom9.org? -- no organization there, a
glossary would get lost. Or Wikipedia? Ha!

I really don't know. Maybe because of my prsonal approach that is to
create my own resources for my own projects, then just link to it.

The audience is here. ...Perhaps Wikipedia some day.


Then I may wish you to show worthy draft of your project to audience
before the audience gets completely bored. Good luck!


Thank you. Do you think I should just post the whole thing? I can't.

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-03 Thread Mark Filipak (ffmpeg)

On 10/01/2020 10:42 PM, Jim DeLaHunt wrote:

On 2020-10-01 15:37, Mark Filipak (ffmpeg) wrote:


On 2020-10-01 15:30, Jim DeLaHunt wrote:


It is an improvement that you are now stating the context, "MPEG-PS binary metadata values". You 
omitted that context before. But you continue to put #2 in the glossary entry, and I continue to 
be of the opinion that the glossary is the wrong place for the content.   The details of the 
table formatting of #2 is a side issue in this discussion.


What is #2?



"#1" and "#2" is your notation, in a message I quoted in my reply. You elided that quote in your 
reply.


Ah! Thank you, Jim. ...senior moment :-)

I INTERRUPT THIS PROGRAM FOR AN IMPORTANT ANNOUNCEMENT.

The text two paragraphs below was my original response. I include it just for the sake of 
completeness and for Jim's benefit, however, things have... progressed (in a way).


My goal (for a long time) is to differentiate hard telecine from pseudo NTSC (which I'm calling 
d-NTSC). I thought I'd found the differentiation: The combined values of 'progressive_sequence' and 
'progressive_frame' MPEG-PS metadata. I was wrong. The video that I thought was hard telecined was 
actually soft telecined. When I realized my error, I revised my response:

"'progressive_sequence' = 0 & 'progressive_frame' = 1 means that the frame is soft 
telecined",
and only then realized that I'd screwed the pooch: that I still had no way to differentiate hard 
telecine from d-NTSC. I'm withdrawing the d-NTSC & d-PAL entries and will rework them when I can, in 
fact, differentiate d-NTSC & d-PAL from hard telecine. (sigh!)


WE NOW RESUME OUR REGULARLY SCHEDULED PROGRAM.

If I understand your point, it is that the definition is followed by a table (of sorts) that you 
think is content and not a suitable part of the definition. Okay, let me try to explain and maybe 
you can suggest a better way, eh?


The 'table' isn't really a table. It's the metadata values that are necessary for the d-NTSC frame 
to be a d-NTSC frame. I provide it so that readers can verify that, "Yes, indeed, I'm looking at a 
d-NTSC frame". The big clue is that 'progressive_sequence' (from the sequence_extension metadata 
structure) and 'progressive_frame' (from the picture_coding_extension metadata structure) are both 
zero. My friend, it took me months to figure that out because H.262 doesn't put things together. 
Here's the straight dope:

'progressive_sequence' = 1 means the frame is a picture.
'progressive_sequence' = 0 & 'progressive_frame' = 0 means that the frame is 
d-NTSC or d-PAL.
'progressive_sequence' = 0 & 'progressive_frame' = 1 means that the frame is 
soft telecined.

Without that info, you can't tell d-NTSC from hard telecined unless you single step through the 
video frames and know what to look for.


The other metadata in the 'table' is the rest of the stuff that distinguishes d-NTSC from d-PAL: 
width, height, aspect ratio, etc.


So, you see, the metadata has to be part of the definition, or at least that's 
what I think.

Do you have a better idea?

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-03 Thread Mark Filipak (ffmpeg)

On 10/03/2020 06:41 AM, Anatoly wrote:

On Fri, 2 Oct 2020 20:47:57 -0400
"Mark Filipak (ffmpeg)"  wrote:

-snip-

By the way, I've given up trying to make an illustration of
2-dimensional Nyquist sampling. It's too hard.

I think is's easy. Just slale dows to every one dimesion to tart from.
Lets draw XY plot of one line of our picture of alternating black-white
stripes

Voltage ^
   -or-  |
Light   |
intencity   | bwbw
 | ___   ___
 |/   \ /   \
 |___/ \___/ \_
 |___> Time -or- position

 --||||--- samples

   ____
  / \__/ \__/ \__/ \_  sampling freq -or- distance.

Here we are digitizing 4 pixels. Does not matter how they are separated
one from another - temporarily (analogue video signal) or spatialy
(laying on CCD silicone surface). Nyquist criteria says that to
digitize (somehow) 4 pixels we need to take 4 samples. Note that
our "signal" frequency (again, temporal or spatial) is 1/2 of sampling
frequency. That is it.


Where's the twice the display resolution in your diagram?

My understanding of Nyquist is limited. I think that it's based on the information density present 
in a signal having amplitude S, that transitions from S to S+d(S) (not black to white) and that it 
therefore defines a minimal slope (hence, the connection to bandwidth). I, myself, question that 
bandwidth is an adequate metric and whether 'information' is adequately characterized, but science 
only 'sees' what it can measure, eh? I'll stick with a definition based on energy density (which, in 
the listening and the seeing, has a gaussian profile and is based on physics).



Maybe it's a fun to discuss such a things, but I think here is not
right place to do it, beacuse it has no straight relation to ffmpeg
usage.


If not ffmpeg.org, then where? doom9.org? -- no organization there, a glossary would get lost. Or 
Wikipedia? Ha!


The audience is here. ...Perhaps Wikipedia some day.

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-02 Thread Mark Filipak (ffmpeg)

On 10/02/2020 02:15 PM, Eduardo Alarcón wrote:

El vie., 2 oct. 2020 a las 7:34, Anatoly ()
escribió:


On Thu, 1 Oct 2020 20:25:30 -0400
"Mark Filipak (ffmpeg)"  wrote:

When sampling an analog voltage, resolution is the ability to resolve
voltage value within a certain period of time (i.e. within a given
channel bandwidth). When sampling a visual field of view however,
resolution is the ability to resolve stationary edges that vary
spacially, going from light to dark or dark to light. It's the same
gaussian energy transfer issue (i.e. that transferring energy
requires time) with the same signal-to-noise issues and the same
handy half-power shorthand, but it applies to ... wait for it ...
human eyes! Human eyes resolve edges only so good, even totally black
abutting totally white. There is nothing you can do about that, and
staring at the edge doesn't bring it into higher resolution. However,
if the image source itself has fuzzy edges because it was sampled at
lower than Nyquist, then the result in our brains is a double
gaussian, the first from the CCD and the second from our eyes. It's
that double gaussian that is avoided by spacially sampling at higher
than 2x the display resolution.



I think this is wrong, Nyquist theorem or principles apply to sampling of a
signal, nothing to do with eyes or brain, ...


Not correct. It's not biological, but it does apply to biology, specifically, 
to the eyes.

Okay, 2 thought experiments:
1 - Imagine a film scanner sampling a film frame line by line. Isn't the scanner making a signal 
that the sampler uses to make samples? If you think that Nyquist applies only to signals, then, 
there's your signal.
2 - What about a CCD array that makes all the samples at one time? Doesn't that expand the signal to 
2 dimensions?



... it describes the minimum sampling rate ...


Nyquist has nothing to do with rate. If Wikipedia says otherwise, then Wikipedia is wrong. Rate only 
applies to broadcast media like television. Rate determines bandwidth needed (which may be more than 
what's allowed for channels), but bandwidth is meaningless in a film scanner or a camera because 
they are not broadcast.


What Wikipedia may be referring to is the bandwidth needed for digital TV. That really has nothing 
to do with Nyquist. But then, Wikipedia isn't written by experts, is it? I can see how it would 
mislead you.


By the way, I've given up trying to make an illustration of 2-dimensional Nyquist sampling. It's too 
hard.


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-02 Thread Mark Filipak (ffmpeg)

On 10/02/2020 06:34 AM, Anatoly wrote:

On Thu, 1 Oct 2020 20:25:30 -0400
"Mark Filipak (ffmpeg)"  wrote:

On 10/01/2020 07:43 PM, Anatoly wrote:

On Wed, 30 Sep 2020 19:21:59 -0400
"Mark Filipak (ffmpeg)"  wrote:
   

Nyquist [adjective]: 1, Reference to the Nyquist-Shannon sampling
 theorem. 2, The principle [1] that, to most faithfully
reproduce an image at a given digital display's resolution, the
samples must be made at or above twice the display's resolution,
both horizontally & vertically [2].

Sorry, but this is wrong.
from
https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
"If a function x(t) contains no frequencies higher than B hertz, it
is completely determined by giving its ordinates at a series of
points spaced 1/(2B) seconds apart.
A sufficient sample-rate is therefore anything larger 2B samples per
second."
Let's say we have 640 horisontal dots (pixels) per line in NTSC
system.

-snip-
Yes, yes, of course. You are correct, but this is different.

The source is not an NTSC analog signal. The source is analog streams
of photons striking a CCD imager array, frame by frame, and applies
to the image regardless whether the image is moving or stationary,
and regardless of exposure time (which affects brightness, not
resolution). The source is a 2-dimensional, lighted field of view in
a camera or film scanner transferring light energy to produce charge
in photo transistors over a spacial area. It's not temporal as is the
case when sampling a changing analog voltage.

Yet I think replacing Voltage with Light Intencity and Time with X
coordinate on analoguie video signal graph changes nothing, if you are
about moving to spatial domain.


When sampling an analog voltage, resolution is the ability to resolve
voltage value within a certain period of time (i.e. within a given
channel bandwidth). When sampling a visual field of view however,
resolution is the ability to resolve stationary edges that vary
spacially, going from light to dark or dark to light. It's the same
gaussian energy transfer issue (i.e. that transferring energy
requires time) with the same signal-to-noise issues and the same
handy half-power shorthand, but it applies to ... wait for it ...
human eyes! Human eyes resolve edges only so good, even totally black
abutting totally white. There is nothing you can do about that, and
staring at the edge doesn't bring it into higher resolution. However,
if the image source itself has fuzzy edges because it was sampled at
lower than Nyquist, then the result in our brains is a double
gaussian, the first from the CCD and the second from our eyes. It's
that double gaussian that is avoided by spacially sampling at higher
than 2x the display resolution.


So you want to say that if I watching picture on 640x480 dots
display, my brain "effectively" can percept only 320x240 dots.


Hi Anatoly,

The issue is not biology, The issue is pure physics.

In your scenario, your eyes do see 640x480. Your brain does see 640x480. But in order to cleanly 
'see' a black-white edge inside those 640x480 dots, the 640x480 dots need to be made from 1280x960 
samples within the camera. If the camera made 640x480, then, yes, you would see that edge at 320x240 
effective resolution (i.e. fuzzier).


I'm trying to prepare some illustrations that will show how Nyquist works in images. That's proving 
to be really hard. Two-dimensional Nyquist is hard to visualize.


In the mean time, and in answer to your's & Eduardo's posts, I'm going to write an explanation 
instead of showing an explanation.


The Nyquist criterion is based on physics not biology. In physics, perceiving/measuring physical 
properties is based on moving energy from object to observer plus the time that takes. If energy 
doesn't move, then there is no measurement or observable result.


The interpretation of Nyquist at Wikipedia addresses 1-dimensional voltage (a signal). What is 
presented is limited to one dimension plus time.


However, over a 2-dimensional area (such as a display), the more general interpretation of 
resolution is based on the rate of change of energy density per unit of time. Higher energy (e.g. 
more light) makes images more resolvable. Higher density (e.g. more dots per square mm) makes images 
more resolvable. More time (e.g. longer observation) makes images more resolvable.


Anyone who thinks that Nyquist sampling is limited to signals is wrong. Nyquist sampling applies to 
2-dimensional areas, too. (Nyquist applies to 3-dimensions, also, but that's another story.)


Nyquist applies to anything/everything that's converted from analog to digital.


And for
my brain to percept "effectively" 640x480, I need 1280x960 from CCD to
LCD?
Then I may say that at image processing domain such a terms as "640x480"
or "4K" is all about real count of pixels 

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 07:43 PM, Anatoly wrote:

On Wed, 30 Sep 2020 19:21:59 -0400
"Mark Filipak (ffmpeg)"  wrote:


Nyquist [adjective]: 1, Reference to the Nyquist-Shannon sampling
theorem. 2, The principle [1] that, to most faithfully reproduce an
image at a given digital display's resolution, the samples must be
made at or above twice the display's resolution, both horizontally
& vertically [2].

Sorry, but this is wrong.
from
https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
"If a function x(t) contains no frequencies higher than B hertz, it is
completely determined by giving its ordinates at a series of points
spaced 1/(2B) seconds apart.
A sufficient sample-rate is therefore anything larger 2B samples per
second."
Let's say we have 640 horisontal dots (pixels) per line in NTSC system.

-snip-
Yes, yes, of course. You are correct, but this is different.

The source is not an NTSC analog signal. The source is analog streams of photons striking a CCD 
imager array, frame by frame, and applies to the image regardless whether the image is moving or 
stationary, and regardless of exposure time (which affects brightness, not resolution). The source 
is a 2-dimensional, lighted field of view in a camera or film scanner transferring light energy to 
produce charge in photo transistors over a spacial area. It's not temporal as is the case when 
sampling a changing analog voltage.


When sampling an analog voltage, resolution is the ability to resolve voltage value within a certain 
period of time (i.e. within a given channel bandwidth). When sampling a visual field of view 
however, resolution is the ability to resolve stationary edges that vary spacially, going from light 
to dark or dark to light. It's the same gaussian energy transfer issue (i.e. that transferring 
energy requires time) with the same signal-to-noise issues and the same handy half-power shorthand, 
but it applies to ... wait for it ... human eyes! Human eyes resolve edges only so good, even 
totally black abutting totally white. There is nothing you can do about that, and staring at the 
edge doesn't bring it into higher resolution. However, if the image source itself has fuzzy edges 
because it was sampled at lower than Nyquist, then the result in our brains is a double gaussian, 
the first from the CCD and the second from our eyes. It's that double gaussian that is avoided by 
spacially sampling at higher than 2x the display resolution.


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-01 Thread Mark Filipak (ffmpeg)

On 2020-10-01 14:49, Mark Filipak (ffmpeg) wrote:

On 10/01/2020 05:13 PM, Mark Filipak (ffmpeg) wrote:
On 10/01/2020 03:21 PM, Jim DeLaHunt wrote >> OK, then I think what you have — what you put in 
your text attachment "d-NTSC & d-PAL .txt" in
your previous message — is two single-line glossary entries, conjoined with entries from a table 
mapping H.262 Metadata Values to video types d-NTSC and d-PAL.

-snip-

I'll try again.


How's this look, Jim? Clear? Or muddled?

d-NTSC [noun]: The digital equivalent of NTSC. d-NTSC is distinguished
  by a frame having all 8, MPEG-PS binary metadata values below.
   'aspect_ratio_information' = 0010  [1]
    'frame_rate_code' = 0100  [1]
[… snip …]



It is an improvement that you are now stating the context, "MPEG-PS binary metadata values". You 
omitted that context before. But you continue to put #2 in the glossary entry, and I continue to be 
of the opinion that the glossary is the wrong place for the content.   The details of the table 
formatting of #2 is a side issue in this discussion.


What is #2?


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 05:13 PM, Mark Filipak (ffmpeg) wrote:

On 10/01/2020 03:21 PM, Jim DeLaHunt wrote >> OK, then I think what you have — what you put 
in your text attachment "d-NTSC & d-PAL .txt" in
your previous message — is two single-line glossary entries, conjoined with entries from a table 
mapping H.262 Metadata Values to video types d-NTSC and d-PAL.

-snip-

I'll try again.


How's this look, Jim? Clear? Or muddled?

d-NTSC [noun]: The digital equivalent of NTSC. d-NTSC is distinguished
  by a frame having all 8, MPEG-PS binary metadata values below.
   'aspect_ratio_information' = 0010  [1]
'frame_rate_code' = 0100  [1]
  'horizontal_size_value' = 0010 1101 [1]
'vertical_size_value' = 0001 1110 [1]
  'horizontal_size_extension' = 00[2]
'vertical_size_extension' = 00[2]
   'progressive_sequence' = 0 [2]
  'progressive_frame' = 0 [3]
  [1] From sequence_header
  [2] From sequence_extension
  [3] From picture_coding_extension

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 03:21 PM, Jim DeLaHunt wrote:
-snip-
OK, then I think what you have — what you put in your text attachment "d-NTSC & d-PAL .txt" in your 
previous message — is two single-line glossary entries, conjoined with entries from a table mapping 
H.262 Metadata Values to video types d-NTSC and d-PAL.


Well, that deserves an answer. There are two parts to each glossary entry: 1, A simple statement of 
what a thing is, and 2, a "distinguished by" identification so that readers can identify the thing. 
The table is the "distinguished by" part. I formatted it as a table to make it easy, or at least so 
I thought! :-)


For example, d-NTSC is distinguished via MPEG-PS binary metadata:
'progressive_sequence' == 0 & 'progressive_frame' == 0 & 'aspect_ratio_information' == 0010 & 
'frame_rate_code' == 0100 & 'horizontal_size_value' == 0010 1101  & 'horizontal_size_extension' 
== 00 & 'vertical_size_value' == 0001 1110  & 'vertical_size_extension' == 00.


That's the logic. Putting the table into a different glossary entry wouldn't work, but obviously, 
the way I'm doing it now is a FAIL.


I'll try again.

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 02:01 PM, Phil Rhodes via ffmpeg-user wrote:

  I don't know who's in charge of this glossary project, but can I please 
propose something on the difference between colourspace, subsampling and 
luminance encoding. And all the other things people constantly confuse.


No one's in charge. I've taken the initiative to begin (and conduct and finish and whatever it 
takes) the effort [1]. Based on the evidence, I'm not alone, but no one's in charge.


Regarding your concerns, Phil, I believe I have a lock on subsampling & luminance encoding (or, at 
least, the structures, but not the processes) and I would post glossary entries if I could, but 
they're very large and have large texie pix diagrams and are formatted to 148 columns of text and 
therefore don't fit into email format, and I would probably incur the ire of the list maintainers if 
I were to attach such large files. Sorry,


Regarding colorspace, such documentation exists, at least in name -- literally, names only to the 
best of my knowledge -- but the details of the data structures are, at best: buried in code 
algorithms without explicit structural documentation, or, at worst: completely lacking and subject 
to trial-and-error hacking, even by the developers.


[1] There are 3 ways to take leadership: #1, be appointed by some authority, or #2, be elected by 
some constituency, or #3, start leading. I have tried #1 and #2 and have not been successful due to 
wrangling, so I am pursuing route #3. If that rankles some folks, the fault is entirely mine.


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 01:03 PM, Jim DeLaHunt wrote:

On 2020-10-01 06:27, Mark Filipak (ffmpeg) wrote:


On 09/30/2020 11:56 PM, Jim DeLaHunt wrote:

On 2020-09-30 20:36, Mark Filipak (ffmpeg) wrote:


Continuing with relatively non controversial entries:

d-NTSC [noun]: 1, The digital equivalent of NTSC distinguished by
  binary metadata:
  720 samples/row: 'horizontal_size_value' = 0010 1101 
   'horizontal_size_extension' = 00
  480 rows: 'vertical_size_value' = 0001 1110 
    'vertical_size_extension' = 00
  4:3 DAR: 'aspect_ratio_information' = 0010
  30/1.001 FPS: 'frame_rate_code' = 0100
  'progressive_sequence' = 0 & 'progressive_frame' = 0

d-PAL [noun]: 1, The digital equivalent of PAL distinguished by binary
  metadata:
  720 samples/row: 'horizontal_size_value' = 0010 1101 
   'horizontal_size_extension' = 00
  576 rows: 'vertical_size_value' = 0010 0100 
    'vertical_size_extension' = 00
  4:3 DAR: 'aspect_ratio_information' = 0010
  25 FPS: 'frame_rate_code' = 0011
  'progressive_sequence' = 0 & 'progressive_frame' = 0 



It seems to me that these are no longer glossary entries — or, only the first line of each is a 
glossary entry. ...


…The sentence is a statement followed by a list of metadata that distinguishes 
the subject...
Do you have any suggestions? Should I just forget this glossary idea?



What makes sense to me is a glossary which includes the entries:

d-NTSC [noun]: 1, The digital equivalent of NTSC

d-PAL [noun]: 1, The digital equivalent of PAL

Then a table of XYZ metadata entries which have been found in the wild:


Actually, not in the wild. They are from H.262.


[Display the following table with fixed-width font]


Actually, Jim, what you sent is not in fixed-width font. :-)
So, you favor a formal table? I don't, but I guess that could go without 
saying, eh?
I format in plain text at 148 columns. I've found 70 columns to be too restricting and promotes 
crypticism (...is there such a word?). Personally, I don't think formal tables are needed, but if 
you do, then I'll make a formal table. But first, take a look at the current version, attached.


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
d-NTSC [noun]: The digital equivalent of NTSC. d-NTSC is distinguished via 
MPEG-PS binary metadata:
  'progressive_sequence' = 0  + 'progressive_frame' = 0 
 ...is a scan frame
  'aspect_ratio_information' = 0010   +   'frame_rate_code' = 
0100   ...4:3 DAR + 30/1.001 FPS
 'horizontal_size_value' = 0010 1101  + 'horizontal_size_extension' = 
00 ...720 samples/row
   'vertical_size_value' = 0001 1110  +   'vertical_size_extension' = 
00 ...480 rows

d-PAL [noun]: The digital equivalent of PAL. d-PAL is distinguished via MPEG-PS 
binary metadata:
  'progressive_sequence' = 0  + 'progressive_frame' = 0 
 ...is a scan frame
  'aspect_ratio_information' = 0010   +   'frame_rate_code' = 
0011   ...4:3 DAR + 25 FPS
 'horizontal_size_value' = 0010 1101  + 'horizontal_size_extension' = 
00 ...720 samples/row
   'vertical_size_value' = 0010 0100  +   'vertical_size_extension' = 
00 ...576 rows
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 12:16 PM, Greg Oliver wrote:

On Wed, Sep 30, 2020 at 6:25 PM Mark Filipak (ffmpeg) 
wrote:

-snip-

Mark,

Normally I would absolutely defend your queries as they are technical and
lower level, but I would almost have to side with Bouke from post
(
bwdif filter question
)

You are trying to get free editing for your book now.


I have no book. I intend to have no book. I'm a retired engineer and don't need book proceeds. I 
intend to give everything to the ffmpeg project (and anyone else who finds it useful) for free and 
unconditionally. It is all public domain. By simply posting it, I'm making it all public domain.



 I do not agree with
that..  There are many good contributors and inquisitors (you included),
but (IMHO) you cannot solicit things like this that are grammatical rather
than technical.   I think a lot of the developers are also in the same boat
as you (sometimes) try to re-define things that are common language (even
if not accurate technically).


I'm working on a glossary, not a dictionary. I have no desire to re-define 
common language.


eg - your definition if interlaced versus interweaved..  No matter if you
are right or wrong, the concept and understanding of a majority will
prevail - no exceptions.


We shall see, eh? If there's power in (better?) terms, then they will prevail. If not, then they 
will die. For what it's worth, I've never written the word "interweaved".


Certainly, to cite just one realm, the current nomenclature is quite confused regarding pre-decoding 
streams v. post-decoding processing. The H.xxx folks leave interpretation to "context". But relying 
on context relies on understanding, and it is understanding that is lacking. Which would you shoot 
first? The chicken or the egg? -- Buy this concept or I shoot the dog.



Please (for me at least) keep your posts here related to ffmpeg and not
trying to change the nomenclature of what exists.  We are all using the
same software, so whatever the software uses for terminology (as this list
is exactly related to), please do not interfere with that.


My experience is that the entire video field, not just ffmpeg, is grossly underspecified. That hurts 
users and developers -- a lot of time is wasted and a lot of feelings are hurt. Based on my 47 years 
of engineering experience, the first things that need to be fixed is to unequivocally and 
unambiguously define all the terms & structures. To me, that's the low hanging fruit. Then comes the 
processes, but once the terms & structures are nailed down, I think we'll all discover that 
documenting the processes will be a snap.



Take that up directly with developers and let them sort it out.


I would/could never stop them from contributing. But it should be acknowledged that the developers 
have a developer's perspective. The developer view is like looking out at the world through a pinhole.



On a side note - I have yet seen one of your definitions of a technology
been held up when a developer chimes in - no hard feelings, just that
industry terminology is hard to trump :)


Oh, believe me, you've seen nothing yet. I ponder terminology and anguish over every word choice for 
a long, long time. I doggedly seek to manufacture terms that are intuitive and acceptable to all.


The developers have their opinions and have not been shy sharing it. To be honest, I don't see how 
this (my glossary) can even be an issue. I'm an ffmpeg user and so long as I'm courteous and focus 
on video issues, the developers should welcome me. If not, then I should be removed from the 
ffmpeg-user list.


Give this journey the time that it deserves. We all have the same destination in sight, just 
differing paths to get there. Perhaps there exists no single path, eh?


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 11:20 AM, Eduardo Alarcón wrote:

El jue., 1 oct. 2020 a las 12:09, Mark Filipak (ffmpeg) ()
escribió:


On 10/01/2020 10:38 AM, Eduardo Alarcón wrote:

-snip-

Can you suggest better wording? I'd like to see it.


Me too, this is not my native language so i can not suggest a better wording.


Oh, you are doing fine. Trust me on this, being a native English speaker isn't all that it's cracked 
up to be -- note the "cracked up" euphemism. :-)
I assume you're a native Spanish speaker. I think that Spanish is a very sensible and logical 
language. English started out that way but got wrecked by the principle that anyone should be 
allowed to do whatever they want.


-snip-

I think it should say that undersampling makes it look bad or blurry, ...


Do you think the following -- changed "appearance" to "sharpness" & added "from film" in 2 places -- 
is improved and satisfies your desires?


[1] The Nyquist principle applies to film sampling and to digital cameras, but, 
provided that
resolution is unchanged, not to transcoding (because the transcoder inputs 
are already
digital). As proved by the improved sharpness of SD media made from 2K flim 
samples, SD
mastering prior to the advent of 2K sampling (e.g. DVDs mastered from film 
before the advent
of HD) generally ignored the Nyquist principle and were undersampled. HDs 
sampled from film
at 2K and UHDs sampled from film at 4K are likewise undersampled.


Off topic, i find your questions helpful or interesting at least on this
list, there are concepts i know and things i don't that i had to look up


Is that "Off topic" in a user list dedicated to video processing? Really? Well, whatever the 
opinion, I thank you for your kind words.


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 10:38 AM, Eduardo Alarcón wrote:

Mostly the noun/adjective part, the part [1] about SD media and mastering,
seems to be anecdotal information more than a definition of what is the
Nyquist principle, you say that the images are undersampled, but what does
it mean? what is the impact, the images look blurry?, may be you defined
"undersampling" in other part


Thanks for your thoughts. They're important. Yes, I could write more. And, Yes, the note is 
anecdotal. I felt that the note introduces the idea that something can be undersampled and with a 
concrete example of something that is undersampled so that the concept becomes 'real'. Can you 
suggest better wording? I'd like to see it.


Regarding what undersampling means, it's a common term that can be looked up in a general dictionary 
rather than a dedicated glossary. That's just my opinion of course. Where do you think the line 
should be drawn?


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: Nyquist

2020-10-01 Thread Mark Filipak (ffmpeg)

On 10/01/2020 01:20 AM, Eduardo Alarcón wrote:

Nyquist is a noun, not an adjective, for Harry Nyquist. ...


Hi Eduardo, Thanks.

Well, technically, a noun used as an adjective: "Nyquist sampling", makes it an adjective, but no 
matter.


What if I narrow the scope to solely the sampling theory? thusly:

Nyquist sampling: The principle [1] that, to most faithfully reproduce
  an image at a given digital display's resolution, samples must be
  made at or above twice the display's resolution, both horizontally &
  vertically [2].
  [1] The Nyquist principle applies to film sampling and to digital
  cameras, but, provided that resolution is unchanged, not to
  transcoding (because the transcoder inputs are already digital).
  As proved by the improved appearance of SD media made from 2K
  samples, SD mastering prior to the advent of 2K sampling (e.g.
  DVDs mastered before the advent of HD) generally ignored the
  Nyquist principle and were undersampled. HDs sampled at 2K and
  UHDs sampled at 4K are likewise undersampled.
  [2] As a convenience, the Nyquist threshold is currently (in 2020)
  specified solely by horizontal sample count rounded up to whole
  kilo-samples (2K, 4K, 8K).
displayNyquist threshold
  UHD 16:9-2160:  3840 x 2160 8K
   4:3-2160:  2880 x 2160 8K
   HD 16:9-1080:  1920 x 1080 4K
   4:3-1080:  1440 x 1080 4K
   SD  16:9-576:  1024 x 576  4K
4:3-576:   768 x 576  2K
   16:9-480:   853 x 480  2K
4:3-480:   640 x 480  2K


... The Nyquist–Shannon
sampling theorem is applicable to analog to digital conversion of signals
(continuous to discrete), images are a type of signal.


Well, I thought that was what I wrote. What doesn't work for you?

The reason I wrote "both horizontally & vertically" was to resolve that, unlike sampling a 
1-dimensional (serial) signal, 2-dimensional sampling (e.g. from film) or within a camera, requires 
the Nyquist principle be applied in both dimensions. But perhaps that's not what you find lacking. 
Could you suggest different wording maybe?


--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-10-01 Thread Mark Filipak (ffmpeg)

On 09/30/2020 11:56 PM, Jim DeLaHunt wrote:

On 2020-09-30 20:36, Mark Filipak (ffmpeg) wrote:


Continuing with relatively non controversial entries:

d-NTSC [noun]: 1, The digital equivalent of NTSC distinguished by
  binary metadata:
  720 samples/row: 'horizontal_size_value' = 0010 1101 
   'horizontal_size_extension' = 00
  480 rows: 'vertical_size_value' = 0001 1110 
    'vertical_size_extension' = 00
  4:3 DAR: 'aspect_ratio_information' = 0010
  30/1.001 FPS: 'frame_rate_code' = 0100
  'progressive_sequence' = 0 & 'progressive_frame' = 0

d-PAL [noun]: 1, The digital equivalent of PAL distinguished by binary
  metadata:
  720 samples/row: 'horizontal_size_value' = 0010 1101 
   'horizontal_size_extension' = 00
  576 rows: 'vertical_size_value' = 0010 0100 
    'vertical_size_extension' = 00
  4:3 DAR: 'aspect_ratio_information' = 0010
  25 FPS: 'frame_rate_code' = 0011
  'progressive_sequence' = 0 & 'progressive_frame' = 0 



It seems to me that these are no longer glossary entries — or, only the first line of each is a 
glossary entry. ...


Each entry is just one sentence, so I guess you don't like the sentence 
spanning multiple lines (?)

The sentence is a statement followed by a list of metadata that distinguishes the subject... so that 
people can determine whether a particular video is a d-NTSC video or not a d-NTSC video for example. 
The main distinguishing feature is 'progressive_sequence' = 0 & 'progressive_frame' = 0 of course. 
The others narrow the scope to just a single species of video.


If a glossary entry requires explanation, then it's a fail. What fails? I guess I didn't anticipate 
such a total-failure mode.


Do you have any suggestions? Should I just forget this glossary idea?

... The rest seems to be a description of a data structure or representation. The entry 
doesn't say to what format or specification the representation applies. To an MPEG-2 video? To a the 
ISO file corresponding to a DVD?



--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Glossary: d-NTSC & d-PAL

2020-09-30 Thread Mark Filipak (ffmpeg)

Continuing with relatively non controversial entries:

d-NTSC [noun]: 1, The digital equivalent of NTSC distinguished by
  binary metadata:
  720 samples/row: 'horizontal_size_value' = 0010 1101 
   'horizontal_size_extension' = 00
  480 rows: 'vertical_size_value' = 0001 1110 
'vertical_size_extension' = 00
  4:3 DAR: 'aspect_ratio_information' = 0010
  30/1.001 FPS: 'frame_rate_code' = 0100
  'progressive_sequence' = 0 & 'progressive_frame' = 0

d-PAL [noun]: 1, The digital equivalent of PAL distinguished by binary
  metadata:
  720 samples/row: 'horizontal_size_value' = 0010 1101 
   'horizontal_size_extension' = 00
  576 rows: 'vertical_size_value' = 0010 0100 
'vertical_size_extension' = 00
  4:3 DAR: 'aspect_ratio_information' = 0010
  25 FPS: 'frame_rate_code' = 0011
  'progressive_sequence' = 0 & 'progressive_frame' = 0

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Glossary: Nyquist

2020-09-30 Thread Mark Filipak (ffmpeg)

Nyquist [adjective]: 1, Reference to the Nyquist–Shannon sampling
  theorem. 2, The principle [1] that, to most faithfully reproduce an
  image at a given digital display's resolution, the samples must be
  made at or above twice the display's resolution, both horizontally &
  vertically [2].
  [1] The Nyquist principle applies to film sampling and to digital
  cameras, but, provided that resolution is unchanged, not to
  transcoding (because the transcoder inputs are already digital).
  As proved by the improved appearance of SD media made from 2K
  samples, SD mastering prior to the advent of 2K sampling (e.g.
  DVDs mastered before the advent of HD) generally ignored the
  Nyquist principle and were undersampled. HDs sampled at 2K and
  UHDs sampled at 4K are likewise undersampled.
  [2] As a convenience, the Nyquist threshold is currently (in 2020)
  specified solely by horizontal sample count rounded up to whole
  kilo-samples (2K, 4K, 8K).
displayNyquist threshold
  UHD 16:9-2160:  3840 x 2160 8K
   4:3-2160:  2880 x 2160 8K
   HD 16:9-1080:  1920 x 1080 4K
   4:3-1080:  1440 x 1080 4K
   SD  16:9-576:  1024 x 576  4K
4:3-576:   768 x 576  2K
   16:9-480:   853 x 480  2K
4:3-480:   640 x 480  2K

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: DAR, PAR, and SAR

2020-09-30 Thread Mark Filipak (ffmpeg)

Revision: Shorter sentences, better consistency, no extra 'lesson' about how to 
minimize ratios.\
Formatted for email, plain text.

DAR (display aspect ratio [1]) [noun]: 1, The width-to-height ratio
  (W:H, e.g. 16:9, 4:3) for the intended display. DAR is distingushed
  by metadata: 'aspect_ratio_information', (also see "SAR", note [2]).
  2, H.262 §3.44: "The ratio of height divided by width (in spatial
  measurement units such as centimetres) of the intended display."
  [2].
  [1] It's mistakenly asserted by some that "DAR" is an acronym for
  "data aspect ratio" or "disc aspect ratio".
  [2] Criticism: H.262 claims that DAR is a "ratio", then wrongly
  defines it as a quotient (which it turns upside down): "height
  divided by width"; also H.262 §6.3.3 (i.e. "3 ÷ 4", "9 ÷ 16").

PAR (picture aspect ratio [1]) [noun]: 1, The horizontal-to-vertical
  size [3] ratio (H:V, e.g. 5:4, 3:2) for pictures. PAR is
  distingushed by metadata: 'horizontal_size' & 'vertical_size', [2]
  [4] (also see "SAR", note [2]).
  [1] It's mistakenly asserted by some that "PAR" is an acronym for
  "pixel aspect ratio".
  [2] PAR can also be calculated from DAR & SAR thusly: PAR = DAR/SAR.
  [3] Note that PAR is virtual (i.e. defined by dataset indexes, not
  by physical dimensions).
  [4] Criticism: H.262 doesn't define PAR, however, it does define a
  quotent that correlates with PAR, to wit: H.262 §6.3.3,
  aspect_ratio_information:
"SAR = DAR × horizontal_size/vertical_size".
  The foregoing implies that H.262 would have defined PAR as
  vertical_size/horizontal_size. Opinion: By defining DAR & SAR as
  quotients (which it turns upside down), and by implying that
  metadata: 'aspect_ratio_information', is also such a quotient
  (which it also turns upside down), H.262 causes much confusion
  that helps explain why so many Internet sites get DAR, PAR, and
  SAR wrong.

SAR (sample aspect ratio [1]) [noun]: 1, The physical horizontal-to-
  vertical spacing ratio (H:V) for samples [2][3]. SAR is
  distinguished as a computed value: DAR/SAR. 2, H.262 §3.114: "This
  specifies the relative distance between samples. It is defined (for
  the purposes of Rec. ITU-T H.262 | ISO/IEC 13818-2), as the vertical
  displacement of the lines of luminance samples in a frame divided by
  the horizontal displacement of the luminance samples [2]. Thus, its
  units are (metres per line) ÷ (metres per sample)." [7].
  [1] It's mistakenly asserted by some that "SAR" is an acronym for
  "storage aspect ratio".
  [2] A standardized set of picture sizes & aspects has been
  established:
 display DAR picture PARSAR = DAR/PAR
   16:9-2160:  3840 x 2160  16:9 : 3840 x 2160  16:9 :  1:1
4:3-2160:  2880 x 2160   4:3 : 2880 x 2160   4:3 :  1:1
   16:9-1080:  1920 x 1080  16:9 : 1920 x 1080  16:9 :  1:1
4:3-1080:  1440 x 1080   4:3 : 1440 x 1080   4:3 :  1:1
   16:9-576:   1024 x 576   16:9 :  720 x 5765:4 : 64:45
4:3-576:768 x 5764:3 :  720 x 5765:4 : 16:15
   16:9-480:853 x 480   16:9 :  720 x 4803:2 : 32:27
4:3-480:640 x 4804:3 :  720 x 4803:2 :  8:9  [4]
  [3] Ideally, SAR would also be the width-to-height ratio of the
  sampling aperture, but that is not mandatory.
  [4] Example: If a 35mm film area (0.906 x 0.680 inches) is to
  produce 345,600 samples (visual density) with 480 rows (vertical
  resolution), then each row must have 720 samples (horizontal
  resolution) [5] and sample spacing should be 32 µm horizontally
  by 36 µm vertically [6].
  [5] (345,600 samples)/(480 rows).
  [6] (0.906 in)(25400 µm/in)/720 by (0.680 in)(25400 µm/in)/480 = 32
  by 36 µm = 32:36 = 8:9 aspect ratio.
  [7] Criticism: H.262 claims that SAR is a "ratio", then, as it does
  with DAR, wrongly defines it as a quotient (which it turns
  upside down).

--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Glossary: DAR, PAR, and SAR

2020-09-30 Thread Mark Filipak (ffmpeg)

On 09/30/2020 06:08 PM, Jim DeLaHunt wrote:

On 2020-09-30 13:09, Mark Filipak (ffmpeg) wrote:
I seek your comments regarding the following glossary entries (that have been reformatted to fit 
email). Kindly take your time.


-Mark.

DAR (display aspect ratio [1]) [noun]: 1, … as a minimized, H:V, integer ratio 
(e.g.
  16:9, 4:3)…
(and similar wording for PAR and SAR):



Is the term "minimized aspect ratio" already used in this domain? If not, then the related 
mathematics term "reduced fraction" may be a better inspiration than "minimized".


Excellent! I'll go for it.


SAR [noun]:…
  [2] A standardized set of picture sizes & aspects has been
  established:
 display DAR picture PAR    SAR = DAR/PAR
    16:9-2160: 3840 x 2160  16:9 : 3840 x 2160  16:9 :  1:1
 4:3-2160: 2880 x 2160   4:3 : 2880 x 2160   4:3 :  1:1
    16:9-1080: 1920 x 1080  16:9 : 1920 x 1080  16:9 :  1:1
 4:3-1080: 1440 x 1080   4:3 : 1440 x 1080   4:3 :  1:1
 16:9-576: 1024 x 576   16:9 :  720 x 576    5:4 : 64:45
  4:3-576:  768 x 576    4:3 :  720 x 576    5:4 : 16:15
 16:9-480:  853 x 480   16:9 :  720 x 480    3:2 : 32:27
  4:3-480:  640 x 480    4:3 :  720 x 480    3:2 :  8:9  [3] 



The formatting of the email garbles the table [2] enough that I can't be sure what I'm reading. 
Maybe insert printable delimiters into each line?


Hmmm... It's a table: rows and columns, like a spread sheet. Does making the column headers more 
obvious work better?


  display DAR   picture PAR  SAR = DAR/PAR
===   ===   =
16:9-2160:  3840 x 2160  16:9  :  3840 x 2160  16:9  :   1:1
 4:3-2160:  2880 x 2160   4:3  :  2880 x 2160   4:3  :   1:1
16:9-1080:  1920 x 1080  16:9  :  1920 x 1080  16:9  :   1:1
 4:3-1080:  1440 x 1080   4:3  :  1440 x 1080   4:3  :   1:1
 16:9-576:  1024 x 576   16:9  :   720 x 5765:4  :  64:45
  4:3-576:   768 x 5764:3  :   720 x 5765:4  :  16:15
 16:9-480:   853 x 480   16:9  :   720 x 4803:2  :  32:27
  4:3-480:   640 x 4804:3  :   720 x 4803:2  :   8:9  [3]

Or is it the column centering that doesn't work?

--
What would you do if you woke up in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Glossary: DAR, PAR, and SAR

2020-09-30 Thread Mark Filipak (ffmpeg)
I seek your comments regarding the following glossary entries (that have been reformatted to fit 
email). Kindly take your time.


-Mark.

DAR (display aspect ratio [1]) [noun]: 1, The intended display's
  width-to-height aspect as a minimized, H:V, integer ratio (e.g.
  16:9, 4:3) distingushed by metadata: 'aspect_ratio_information'
  (also see "SAR", note [2]). 2, H.262 §3.44: "The ratio of height
  divided by width (in spatial measurement units such as centimetres)
  of the intended display" [2].
  [1] It's mistakenly asserted by some that "DAR" is an acronym for
  "data aspect ratio" or "disc aspect ratio".
  [2] Criticism: H.262 claims that DAR is a "ratio", then wrongly
  defines it as a quotient: "height divided by width"; also H.262
  §6.3.3 (i.e. "3 ÷ 4", "9 ÷ 16").

PAR (picture aspect ratio [1]) [noun]: 1, The metadata ratio:
  'horizontal_size':'vertical_size' [3], as a minimized, H:V, integer
  ratio (e.g. 5:4, 3:2) [2][4] (also see "SAR", note [2]).
  [1] It's mistakenly asserted by some that "PAR" is an acronym for
  "pixel aspect ratio".
  [2] PAR can also be calculated from DAR & SAR thusly: PAR = DAR/SAR.
  [3] Note that PAR is virtual (i.e. defined by dataset indexes, not
  physical dimensions).
  [4] Criticism: H.262 doesn't define PAR, however, it does define a
  quotent that correlates with PAR, to wit: H.262 §6.3.3,
  aspect_ratio_information:
"SAR = DAR × horizontal_size/vertical_size".
  The foregoing implies that H.262 would have defined PAR as
  vertical_size/horizontal_size. Opinion: By defining DAR & SAR as
  quotients that turn the standard ratio definitions on their
  heads, and by implying that metadata:
  'aspect_ratio_information', is also such a quotient that also
  turns the standard ratio definition on its head, H.262 causes
  much confusion that helps explain why so many Internet sites get
  DAR, PAR, and SAR wrong.

SAR [noun]: 1, Sample aspect ratio [1][2], the physical horizontal-to-
  vertical sample spacing [6] as a minimized, H:V, integer ratio [3].
  2, H.262 §3.114: "This specifies the relative distance between
  samples. It is defined (for the purposes of Rec. ITU-T H.262 |
  ISO/IEC 13818-2), as the vertical displacement of the lines of
  luminance samples in a frame divided by the horizontal displacement
  of the luminance samples [2]. Thus, its units are (metres per line)
  ÷ (metres per sample)." [7].
  [1] It's mistakenly asserted by some that "SAR" is an acronym for
  "storage aspect ratio".
  [2] A standardized set of picture sizes & aspects has been
  established:
 display DAR picture PARSAR = DAR/PAR
16:9-2160: 3840 x 2160  16:9 : 3840 x 2160  16:9 :  1:1
 4:3-2160: 2880 x 2160   4:3 : 2880 x 2160   4:3 :  1:1
16:9-1080: 1920 x 1080  16:9 : 1920 x 1080  16:9 :  1:1
 4:3-1080: 1440 x 1080   4:3 : 1440 x 1080   4:3 :  1:1
 16:9-576: 1024 x 576   16:9 :  720 x 5765:4 : 64:45
  4:3-576:  768 x 5764:3 :  720 x 5765:4 : 16:15
 16:9-480:  853 x 480   16:9 :  720 x 4803:2 : 32:27
  4:3-480:  640 x 4804:3 :  720 x 4803:2 :  8:9  [3]
  [3] Example: If a 35mm film area (0.906 x 0.680 inches) is to
  produce 345,600 samples (visual density) with 480 rows (vertical
  resolution), then each row must have 720 samples (horizontal
  resolution) [4] and sample spacing should be 32 µm horizontally
  by 36 µm vertically [5].
  [4] (345,600 samples)/(480 rows).
  [5] (0.906 in)(25400 µm/in)/720 by (0.680 in)(25400 µm/in)/480 = 32
  by 36 µm = 32:36 = 8:9 aspect ratio.
  [6] Ideally, SAR would also be the width-to-height ratio of the
  sampling aperture, but that is not mandatory.
  [7] Criticism: H.262 claims that SAR is a "ratio", then, as it does
  with DAR, (wrongly, in the opinion of many) defines it as a
  quotient.

--
What would you do if you woke up in a police state?
African-Americans wake up in a police state every day.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] should I shoot the dog?

2020-09-29 Thread Mark Filipak (ffmpeg)

On 09/29/2020 12:57 PM, Devin Heitmueller wrote:

On Tue, Sep 29, 2020 at 12:28 PM Mark Filipak (ffmpeg)
 wrote:

-snip-

I would encourage you stop trying to invent new terminology ...

-snip-

With due respect to you, I'm not trying to invent new terminology. I'm trying to create extended 
terminology that builds on the existing terminology. But we shall see, eh? If what I do is crap, 
then I'll be the first to throw it away. I've thrown away weeks of work in the past.



YCbCr420 sampleset:
A sampleset with sample-quads:
.---.---.
¦ S ¦ S ¦
:---:---:
¦ S ¦ S ¦
'---'---', reduced to 1/4 chrominance resolution:
.---.---. .---. .---.
¦ Y ¦ Y ¦ ¦   ¦ ¦   ¦
:---:---: ¦Cb ¦ ¦Cr ¦
¦ Y ¦ Y ¦ ¦   ¦ ¦   ¦
'---'---' '---' '---', distinguished by binary metadata:
'chroma_format' = 01. (See "Cb420 & Cr420 macroblocks", "Y macroblock".)

YCbCr422 sampleset:
A sampleset with sample-quads:
.---.---.
¦ S ¦ S ¦
:---:---:
¦ S ¦ S ¦
'---'---', reduced to 1/2 chrominance resolution:
.---.---. .---. .---.
¦ Y ¦ Y ¦ ¦Cb ¦ ¦Cr ¦
:---:---: :---: :---:
¦ Y ¦ Y ¦ ¦Cb ¦ ¦Cr ¦
'---'---' '---' '---', distinguished by binary metadata:
'chroma_format' = 10. (See "Cb422 & Cr422 macroblocks", "Y macroblock".)

YCbCr444 sampleset:
A sampleset with sample-quads:
.---.---.
¦ S ¦ S ¦
:---:---:
¦ S ¦ S ¦
'---'---', having full chrominance resolution:
.---.---. .---.---. .---.---.
¦ Y ¦ Y ¦ ¦Cb ¦Cb ¦ ¦Cr ¦Cr ¦
:---:---: :---:---: :---:---:
¦ Y ¦ Y ¦ ¦Cb ¦Cb ¦ ¦Cr ¦Cr ¦
'---'---' '---'---' '---'---', distinguished by binary metadata:
'chroma_format' = 11. (See "Cb444 & Cr444 macroblocks", "Y macroblock".)


The diagrams are probably fine, but probably not how I would draw them
given they blur the relationship between packed and planar.  Either
it's packed, in which case you should probably show 4:2:2 as YCbYCr,
or it's planer in which case the Cb/Cr samples should not be adjacent
per line (i.e. have all the Y lines followed by all the Cr/Cb lines).
You may wish to take into your account your newfound understanding of
packed vs. planar to redo these diagrams representing the data as
either one or the other.


Thank you, Devin. Yes, the diagrams are incomplete. And, yes, I will do diagrams that take planar v. 
packed into account. I will post them when completed. May I also say that I appreciate your 
attitude: That seekers are not stupid or trolls.


Regarding "adjacent per line", the references to "Cb444 & Cr444 macroblocks", "Y macroblock" make 
that clear, but I will revise the note to better indicate that the chroma subsamples are not adjacent.


Regarding "4:2:2 as YCbYCr" packed, I can't fully visualize it because, I think, there should be 4 Y 
samples, not 2. But don't explain it, though. Not yet. Wait until I post a diagram of it and then 
let me know what you think and how that diagram is wrong. :-)


I don't want to exploit your generosity. I'll do the grunt work.


I would probably also refrain from using the term "macroblock" to
describe the raw decoded video, as macroblocks are all about how the
pixels are organized in the compressed domain.  Once they are decoded
there is no notion of macroblocks in the resulting video frames.


Got it. Regarding "compressed domain" (in which macroblocks are sparse), that's what I initially 
thought, but H.262 pretty strongly implies that macroblocks also apply to raw video. That seems 
logical to me (as datasets prior to compression).


Unrelated: In the glossary, I seek to always have "distinguished by" clauses so that readers can be 
sure about when and where a particular definition applies.



... If the video frame is interlaced
however, the first chroma sample corresponds to the first two luma
samples on line 1 and the first two luma samples on line 3.  The first
chroma sample on the second line of chroma corresponds with the first
two luma samples on line 2 and the first two luma samples on line 4.


I have pictures of those, too. What do you think of the above pictures? Do you 
a, like them, or b,
loathe them, or c, find them unnecessary?


I would probably see if you can find drawings already out there.  For
example the Wikipedia article on YUV has some pretty good
representations for pixel arrangement in various pixel formats.  So
does the LinuxTV documentation.


Thanks for the tips.


This is known as "interlaced chroma" and a Google search will reveal
lots of c

Re: [FFmpeg-user] should I shoot the dog?

2020-09-29 Thread Mark Filipak (ffmpeg)

On 09/29/2020 11:44 AM, Devin Heitmueller wrote:

On Tue, Sep 29, 2020 at 11:29 AM Mark Filipak (ffmpeg)
 wrote:

Oh, dear, that's what "packed" means? ...very misleading name, eh? How are 
fields handled? Are the
pixels assumed to be unfielded (meaning so-called "progressive")?


So the topic of how interlaced video is handled in subsampled video is
something we could spend an hour on by itself.  In the Luma space, the
Y samples are organized in interleaved form (i.e. lines of
top/bottom/top/bottom). ...


Top/bottom/top/bottom, especially if full lines, seems like straightforward interlaced to me. Or do 
I misunderstand?



... Because of chroma subsampling and the fact
that multiple lines can share chroma samples, this gets tricky. ...


Our messages crossed in transit, but I'm going to assume that you've seen my "In macroblock 
format..." post (in this subject thread).



... In
the simple progressive case for 4:2:0, you'll have the first Chroma
sample corresponding to the first two luma samples on line 1 and the
first two luma samples on line 2. ...


I assume you meant to write "and the *next* two luma samples on line 2". That 'sounds' like what I'm 
calling sample-quads. The following is from the glossary I'm working on (reformatted to fit email).


YCbCr420 sampleset:
  A sampleset with sample-quads:
  .---.---.
  ¦ S ¦ S ¦
  :---:---:
  ¦ S ¦ S ¦
  '---'---', reduced to 1/4 chrominance resolution:
  .---.---. .---. .---.
  ¦ Y ¦ Y ¦ ¦   ¦ ¦   ¦
  :---:---: ¦Cb ¦ ¦Cr ¦
  ¦ Y ¦ Y ¦ ¦   ¦ ¦   ¦
  '---'---' '---' '---', distinguished by binary metadata:
  'chroma_format' = 01. (See "Cb420 & Cr420 macroblocks", "Y macroblock".)

YCbCr422 sampleset:
  A sampleset with sample-quads:
  .---.---.
  ¦ S ¦ S ¦
  :---:---:
  ¦ S ¦ S ¦
  '---'---', reduced to 1/2 chrominance resolution:
  .---.---. .---. .---.
  ¦ Y ¦ Y ¦ ¦Cb ¦ ¦Cr ¦
  :---:---: :---: :---:
  ¦ Y ¦ Y ¦ ¦Cb ¦ ¦Cr ¦
  '---'---' '---' '---', distinguished by binary metadata:
  'chroma_format' = 10. (See "Cb422 & Cr422 macroblocks", "Y macroblock".)

YCbCr444 sampleset:
  A sampleset with sample-quads:
  .---.---.
  ¦ S ¦ S ¦
  :---:---:
  ¦ S ¦ S ¦
  '---'---', having full chrominance resolution:
  .---.---. .---.---. .---.---.
  ¦ Y ¦ Y ¦ ¦Cb ¦Cb ¦ ¦Cr ¦Cr ¦
  :---:---: :---:---: :---:---:
  ¦ Y ¦ Y ¦ ¦Cb ¦Cb ¦ ¦Cr ¦Cr ¦
  '---'---' '---'---' '---'---', distinguished by binary metadata:
  'chroma_format' = 11. (See "Cb444 & Cr444 macroblocks", "Y macroblock".)


... If the video frame is interlaced
however, the first chroma sample corresponds to the first two luma
samples on line 1 and the first two luma samples on line 3.  The first
chroma sample on the second line of chroma corresponds with the first
two luma samples on line 2 and the first two luma samples on line 4.


I have pictures of those, too. What do you think of the above pictures? Do you a, like them, or b, 
loathe them, or c, find them unnecessary?



This is known as "interlaced chroma" and a Google search will reveal
lots of cases where it's done wrong and what the effects are.  This is
the article I usually refer people to:

https://hometheaterhifi.com/technical/technical-reviews/the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem/

The above article does a really good job explaining the behavior (far
better than I could do in the one paragraph above).


I've seen that produce mild combing. I'll read your reference.

--
--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] should I shoot the dog?

2020-09-29 Thread Mark Filipak (ffmpeg)

On 09/29/2020 11:09 AM, Dave Stevens wrote:

On Tue, 29 Sep 2020 10:48:42 -0400
"Mark Filipak (ffmpeg)"  wrote:


Hi Devin. Thanks much!

Your response came in while I was composing my previous message. I
see (below) that performance is a


Because it reverses the normal order of reading!

Why not top post?


Hi Dave,

Top posting is discouraged in the ffmpeg-user list. I personally loathe top posting and prefer an 
interleaved, call-and-response model. However, in the cited case, I felt that call-and-response 
would not have worked and would simply have been boring and "me too". In other words, I just wanted 
to acknowledge Devin's contribution and thank him one time, in one place.


--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] should I shoot the dog?

2020-09-29 Thread Mark Filipak (ffmpeg)

On 09/29/2020 10:46 AM, Michael Koch wrote:

Am 29.09.2020 um 16:26 schrieb Mark Filipak (ffmpeg):

On 09/29/2020 09:37 AM, Michael Koch wrote:

Am 29.09.2020 um 14:58 schrieb Mark Filipak (ffmpeg):

On 09/29/2020 04:06 AM, Michael Koch wrote:

Am 29.09.2020 um 04:28 schrieb Mark Filipak (ffmpeg):


I just want to understand the frame structures that ffmpeg creates, and that ffmpeg uses in 
processing and filtering. Are Y, Cb, Cr separate buffers? That would be logical. Or are the Y, 
Cb, Cr values combined and organized similarly to macroblocks? I've found some code that 
supports that. Or are the Y, Cb, Cr values thrown together, pixel-by-pixel. That would be 
logical, too.


As far as I understood it, that depends on the pixel format.
For example there are "packed" pixel formats rgb24, bgr24, argb, rgba, abgr, bgra,rgb48be, 
rgb48le, bgr48be, bgr48le.

And there are "planar" pixel formats gbrp, bgrp16be, bgrp16le.


Hi Michael,

"Packed" and "planar", eh? What evidence do you have? ...Share the candy!


As far as I know, this is not described in the official documentation. You can find it for 
example here:

https://video.stackexchange.com/questions/16374/ffmpeg-pixel-format-definitions


Thanks for that. It saved me some time. ...So, what does "planar" mean? What does 
"packed" mean?


Here is an example for a very small image with 3 x 2 pixels.
In (packed) RGB24 format:   RGBRGBRGBRGBRGBRGB


Oh, dear, that's what "packed" means? ...very misleading name, eh? How are fields handled? Are the 
pixels assumed to be unfielded (meaning so-called "progressive")?



In (planar) GBRP format: GGBBRR


What about fields?

In macroblock format, samples are 1st spacially divided vertically into by-16 slices, then spacially 
divided within slices into by-16 macroblocks, then, within macroblocks, divided by into (combined) 
colorant-field blocks: Ytop Ytop Ybottom Ybottom Cb Cr, and, within Cb Cr colorants, into field 
half-blocks, and finally, interleaved by 2 levels of interleaving. ...An overly complicated and (to 
me) ill-conceived set of datasets that illustrates (to me) that the video "engineers" of the Motion 
Pictures Expert Group are lightweight engineers and have hacked a "system".


It is structure to the field-level that I'm most interested in, but a deep dive 
would be fun.


--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] should I shoot the dog?

2020-09-29 Thread Mark Filipak (ffmpeg)

On 09/29/2020 09:20 AM, Devin Heitmueller wrote:

Hi Mark,


Hi Devin. Thanks much!

Your response came in while I was composing my previous message. I see (below) that performance is a 
major issue. That absolutely makes sense because, after accuracy, speed is the next most important 
objective (and for some use cases, may actually be more important).


I imagine that format-to-format conversion is probably the most optimized code in ffmpeg. Is there a 
function library dedicated solely to format conversion? I ask so that, in what I write, I can assure 
users that the issues are known and addressed.


For my modest purposes, a sketch of planar v. packed is probably all that's needed. I think you've 
made "planar" clear. Thank you for that. I can imagine that the structure of packed is 
multitudinous. Why is it called "packed"? How is it packed? Are the luma & chroma mixed in one 
buffer (analogous to blocks in macroblocks) or split into discrete buffers? How are they spacially 
structured? Is there any special sub structures (analogous to macroblocks in slices)? Are the sub 
structures, if any, format dependent?



So when you talk about the decoded frames, there is no concept of
macroblocks.  There are simple video frames with Y, Cb, Cr samples.
How those samples are organized and their sizes are determined by the
AVFrame format.


"Packed" and "planar", eh? What evidence do you have? ...Share the candy!

Now, I'm not talking about streams. I'm talking about after decoding. I'm 
talking about the buffers.
I would think that a single, consistent format would be used.


When dealing with typical consumer MPEG-2 or H.264 video, the decoded
frames will typically have what's referred to as "4:2:0 planar"
format.  This means that the individual Y/Cb/Cr samples are not
contiguous.  If you look at the underlying data that makes up the
frame as an array, you will typically have W*H Y values, followed by
W*H/4 Cb values, and then there will be W*H/4 Cr values.  Note that I
say "values" and not "bytes", as the size of each value may vary
depending on the pixel format.

Unfortunately there is no "single, consistent format" because of the
variety of different ways in which the video can be encoded, as well
as performance concerns.  Normalizing it to a single format can have a
huge performance cost, in particular if the original video is in a
different colorspace (e.g. the video is YUV and you want RGB).
Generally speaking you can set up the pipeline to always deliver you a
single format, and ffmpeg will automatically perform any
transformations necessary to achieve that (e.g. convert from packed to
planer, RGB to YUV, 8-bit to 10-bit, 4:2:2 to 4:2:0, etc).  However
this can have a severe performance cost and can result in quality loss
depending on the transforms required.

The codec will typically specify its output format, largely dependent
on the nature of the encoding, and then announce AVFrames that conform
to that format.  Since you're largely dealing with MPEG-2 and H.264
video, it's almost always going to be YUV 4:2:0 planar.  The filter
pipeline can then do conversion if needed, either because you told it
to convert it or because you specified some filter pipeline where the
individual filter didn't support what format it was being given.

See libavutil/pixfmt.h for a list of all the possible formats in which
AVFrames can be announced by a codec.

Devin


--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] should I shoot the dog?

2020-09-29 Thread Mark Filipak (ffmpeg)

On 09/29/2020 09:37 AM, Michael Koch wrote:

Am 29.09.2020 um 14:58 schrieb Mark Filipak (ffmpeg):

On 09/29/2020 04:06 AM, Michael Koch wrote:

Am 29.09.2020 um 04:28 schrieb Mark Filipak (ffmpeg):


I just want to understand the frame structures that ffmpeg creates, and that ffmpeg uses in 
processing and filtering. Are Y, Cb, Cr separate buffers? That would be logical. Or are the Y, 
Cb, Cr values combined and organized similarly to macroblocks? I've found some code that 
supports that. Or are the Y, Cb, Cr values thrown together, pixel-by-pixel. That would be 
logical, too.


As far as I understood it, that depends on the pixel format.
For example there are "packed" pixel formats rgb24, bgr24, argb, rgba, abgr, bgra,rgb48be, 
rgb48le, bgr48be, bgr48le.

And there are "planar" pixel formats gbrp, bgrp16be, bgrp16le.


Hi Michael,

"Packed" and "planar", eh? What evidence do you have? ...Share the candy!


As far as I know, this is not described in the official documentation. You can find it for example 
here:

https://video.stackexchange.com/questions/16374/ffmpeg-pixel-format-definitions


Thanks for that. It saved me some time. ...So, what does "planar" mean? What does 
"packed" mean?

Now, I'm not talking about streams. I'm talking about after decoding. I'm talking about the 
buffers. I would think that a single, consistent format would be used.

There is no single consistent format used internally. See Gyan's answer here:
http://ffmpeg.org/pipermail/ffmpeg-user/2020-September/050031.html


And thanks for that. So, ffmpeg really is a Tower of Babel, eh? That does not seem wise to me. That 
seems like a great way to generate bugs in addition to confusion.


Now, I imagine that converting to a lingua franca would blow up processing time, so it isn't done. 
However, if there are format-to-format regular expressions for conversions, may I suggest that those 
regular expressions be published? Also, if Y Cb & Cr are separate buffers, may I suggest that ffmpeg 
publish that?


In school, I learned that inputs and outputs should be fully characterized, not suggested, not 
implied, but fully characterized as structures. That takes time, and it takes review and perfection 
by informed people, but that time is worth the investment.


--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] should I shoot the dog?

2020-09-29 Thread Mark Filipak (ffmpeg)

On 09/29/2020 04:06 AM, Michael Koch wrote:

Am 29.09.2020 um 04:28 schrieb Mark Filipak (ffmpeg):


I just want to understand the frame structures that ffmpeg creates, and that ffmpeg uses in 
processing and filtering. Are Y, Cb, Cr separate buffers? That would be logical. Or are the Y, Cb, 
Cr values combined and organized similarly to macroblocks? I've found some code that supports 
that. Or are the Y, Cb, Cr values thrown together, pixel-by-pixel. That would be logical, too.


As far as I understood it, that depends on the pixel format.
For example there are "packed" pixel formats rgb24, bgr24, argb, rgba, abgr, bgra,rgb48be, rgb48le, 
bgr48be, bgr48le.

And there are "planar" pixel formats gbrp, bgrp16be, bgrp16le.


Hi Michael,

"Packed" and "planar", eh? What evidence do you have? ...Share the candy!

Now, I'm not talking about streams. I'm talking about after decoding. I'm talking about the buffers. 
I would think that a single, consistent format would be used.


? ? ? ? ?
So, why am I interested in ffmpeg's internal video buffer format? ...I've been here for about 1/2 
year now, watching the ffmpeg, slow motion train wreck. It seems to me that the ffmpeg patricians 
assume that everyone knows the formats just because the patricians do, and have documented based on 
that assumption. Because we plebians don't know the format, and we don't know that we don't know, 
the patricians get frustrated with us and become short tempered and then the word "troll" flies.


I'm just a simple engineer. To understand an architecture, all I need is the structures, preferably 
as pictures, and maybe a bit of the processing flow, preferably via flow diagrams (i.e. step '1', 
then step '2', then step '3', etc.) -- I'm a visual kinda guy -- but I usually don't need to know 
the processing.


Examining the source code doesn't work for me. 'C' code is just too cryptic and 
I'm too ignorant.

--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] should I shoot the dog?

2020-09-28 Thread Mark Filipak (ffmpeg)

I've spent 2 days studying frame.h, pixfmt.h, dpx.c, packet.h, and escape124.c.
I haven't learned a damn thing.

Despite their vagueness and ambiguity, reading and understanding H.222 & H.262 are dead easy by 
comparison [1].


I just want to understand the frame structures that ffmpeg creates, and that ffmpeg uses in 
processing and filtering. Are Y, Cb, Cr separate buffers? That would be logical. Or are the Y, Cb, 
Cr values combined and organized similarly to macroblocks? I've found some code that supports that. 
Or are the Y, Cb, Cr values thrown together, pixel-by-pixel. That would be logical, too.


I really can't understand how anyone can architect these things without making 
some pictures.

Can anyone here help me, or should I shoot the dog?

Notes:
[1] Reading and understanding H.222 & H.262 is slightly easier than 
self-administered appendectomy.

--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] AVFrame, AV_NUM_DATA_POINTERS

2020-09-28 Thread Mark Filipak (ffmpeg)

On 09/28/2020 03:49 PM, James Darnley wrote:

On 28/09/2020, Mark Filipak (ffmpeg)  wrote:

On 09/27/2020 03:31 PM, James Darnley wrote:

On 27/09/2020, Mark Filipak (ffmpeg)  wrote:

2, Are the width & height indexes in bytes or samples? If bytes, how are
8-bit v. 10-bit v. 12-bit
pixel formats handled at the index generation end?


Width and height are given in pixels.  How that relates to bytes in
memory depends on the pixel format.  Different planes can have
different sizes like in the extremely common yuv420p.


Ah-ha #1. I think you've answered another question. The planes that ffmpeg
refers to are the Y, Cb,
and Cr samples, is that correct?


If the pixel format is a YCbCr format, such as yuv420p, then yes.  If
it matters to you: I am not sure of the exact order of the planes.  It
is probably documented in the pixel format header.


Yes, I'm familiar with pixfmt.h
I find this surprising. But then, ffmpeg is full of surprises, eh?

I anticipated there would be a single ffmpeg video processing/pipeline format that decoders would 
provision. Many, differing pixel formats seems a point of complexity that promotes error.


Regarding the order of the planes, I suspect there is none. I've not examined the source code, but I 
suspect that 3 unique buffer pointers are supplied to the decoder. Also surprising is that the word 
"plane" is apparently used for both video and audio.



RGB is also available and maybe some other more niche ones.  Oh, alpha
channels too.  Again see the pixel format.


So, I'm going to make some statements that can be confirmed or refuted --
making statements rather
than asking questions is just part of my training, not arrogance. Statements
are usually clearer.
I'm trying to nail down the structures for integration into my glossary.

For YCbCr420, 8-bit, 720x576 (for example), the planes are separate and the
structures are:
Y: 2-dimensional, 720x576 byte array.
Cb: 2-dimensional, 180x144 byte array.
Cr: 2-dimensional, 180x144 byte array.


What do you mean by 2 dimensional?


Width x Height.


 IMO you should think of the planes
as a single block of memory each.  The first pixel will be the first
byte.  In your example the first plane in a yuv420p picture will be at
least 720*576 bytes long.  The two chroma planes will have 360x288
samples each with their own linesize.  I'm not sure how you got
180x144.  The subsampling is only a factor of 2 for 4:2:0.


I don't know what you mean. In 4:2:0 format, there are 1 each of Cb & Cr for 
every 4 Y.
180x144 = (720/2)x(576/2). ...Argh! Wrong! ...Duh?

Of course I should have written 360x288 -- my bad. 8-] ...brain fart! (How 
embarrassing.)


The linesize can make it larger than that.  The linesize also says how
many bytes are between the start of a row and the start of the next.

The same color space and subsampling could be expressed in a few
different ways.  Again it is the pixel format which says how the data
is laid out in memory.  You will probably have yuv420p


Specifically, the decoder's output is not in macroblock format, correct? The
reason I ask for
confirmation is that H.262 implies that even raw pictures are in macroblock
format, improbable as
that may seem.


An AVFrame might not come from a source that has macroblocks.  I have
no idea what H.262 says.


Okay, some architecture, okay? I'm interested in how ffmpeg programmatically represents frames 
during processing. (Frames are represented as (W/16)*(H/16) number of macroblocks in MPEG-PSs.)



  Byte order
(endianess) of larger samples depends on the pixel format (but it is
usually native).  The number of bytes used for a sample is given in
the pixel format.  The bits are in the low N bits.


Ah-ha #2. I think you've answered yet another question: The arrays are
bytes, not bits, correct? So,
going from 8-bit samples to 10-bit samples doubles the sizes of the arrays,
correct?


You cannot easily address bits in C and ffmpeg doesn't bother with bit
fields.  yuv420p10 will use 16-bit words with the samples in the low
10 bits and the high 6 are zero.  This does have the effect of
doubling the size of the memory buffers.

P.S.   When I say pixel format I mean the specific ffmpeg feature.


Understood.

Thanks again, James. I'm going to assume that Y, Cb, and Cr are buffered separately, i.e. that 
there's no frame struct per se.


I think that wraps it up vis-a-vis ffmpeg internal representation of video.

--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] frame.h error?

2020-09-28 Thread Mark Filipak (ffmpeg)

In frame.h, I think that this line:
  352  * but for planar audio with more channels that can fit in data,
should be:
  352  * but for planar audio with more channels than can fit in data,

How do I confirm it and make the correction?

Thanks!

--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] AVFrame, AV_NUM_DATA_POINTERS

2020-09-28 Thread Mark Filipak (ffmpeg)

On 09/27/2020 03:31 PM, James Darnley wrote:

On 27/09/2020, Mark Filipak (ffmpeg)  wrote:

  From https://www.ffmpeg.org/doxygen/trunk/frame_8h_source.html#l00309
typedef struct AVFrame {
#define AV_NUM_DATA_POINTERS 8
/**
* pointer to the picture/channel planes.
* This might be different from the first allocated byte
*
* Some decoders access areas outside 0,0 - width,height...

1, Are samples & lines actually indexed from zero? I ask because, if so,
then shouldn't the extents
should be 0,0 - (width-1),(height-1)? -- the descrepancy makes me unsure how
to interpret what I read.


Yes, from 0.  Everything in C is indexed from 0 because they are
pointer offsets.  Maybe that document should say what you suggest.


Thanks, James.


2, Are the width & height indexes in bytes or samples? If bytes, how are
8-bit v. 10-bit v. 12-bit
pixel formats handled at the index generation end?


Width and height are given in pixels.  How that relates to bytes in
memory depends on the pixel format.  Different planes can have
different sizes like in the extremely common yuv420p.


Ah-ha #1. I think you've answered another question. The planes that ffmpeg refers to are the Y, Cb, 
and Cr samples, is that correct?


So, I'm going to make some statements that can be confirmed or refuted -- making statements rather 
than asking questions is just part of my training, not arrogance. Statements are usually clearer. 
I'm trying to nail down the structures for integration into my glossary.


For YCbCr420, 8-bit, 720x576 (for example), the planes are separate and the 
structures are:
Y: 2-dimensional, 720x576 byte array.
Cb: 2-dimensional, 180x144 byte array.
Cr: 2-dimensional, 180x144 byte array.
Specifically, the decoder's output is not in macroblock format, correct? The reason I ask for 
confirmation is that H.262 implies that even raw pictures are in macroblock format, improbable as 
that may seem.



 Byte order
(endianess) of larger samples depends on the pixel format (but it is
usually native).  The number of bytes used for a sample is given in
the pixel format.  The bits are in the low N bits.


Ah-ha #2. I think you've answered yet another question: The arrays are bytes, not bits, correct? So, 
going from 8-bit samples to 10-bit samples doubles the sizes of the arrays, correct?


Thanks so much, James. Warm regards,
Mark.

--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] AVFrame, AV_NUM_DATA_POINTERS

2020-09-27 Thread Mark Filipak (ffmpeg)

From https://www.ffmpeg.org/doxygen/trunk/frame_8h_source.html#l00309
typedef struct AVFrame {
#define AV_NUM_DATA_POINTERS 8
/**
* pointer to the picture/channel planes.
* This might be different from the first allocated byte
*
* Some decoders access areas outside 0,0 - width,height...

1, Are samples & lines actually indexed from zero? I ask because, if so, then shouldn't the extents 
should be 0,0 - (width-1),(height-1)? -- the descrepancy makes me unsure how to interpret what I read.
2, Are the width & height indexes in bytes or samples? If bytes, how are 8-bit v. 10-bit v. 12-bit 
pixel formats handled at the index generation end?


Thanks!

--
The U.S. political problem? Amateurs are doing the street fighting.
The Princeps Senatus and the Tribunus Plebis need their own armies.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] MPEG-PS

2020-09-26 Thread Mark Filipak (ffmpeg)

On 09/26/2020 08:42 AM, Peter wrote:

Hi,

I have a file MPEG-PS, AVC264 with audio code G711u.

It does contain absolute timestamp in each frame i.e I can say when exactly each second of this 
video was shot.


I want to do the following:


I'm still exploring/learning the structures in program streams, but I'll give you my current notions 
and perhaps someone will confirm/refute what I write and we'll both learn, eh?



1. Extract absolute timestamps from the video


Absolute timestamps don't exist in an MPEG-PS. The best that can be determined is frame order and 
frame rate from which absolute timestamps can be calculated.



2. Convert the file to MP4 h264 with some more web friendlier audio codec i.e 
aac.


You want to remux video and transcode audio.


3. Play the files on web using Nginx and Video.js and be able to search by 
absolute timestamp.


I have no knowledge of these.

I am aware that most likely I will need to store absolute timestamp in separate files as I cannot 
put them in mp4.


Any help/feedback is welcome :-)

Thanks,

Peter

--
Ignorance can be cured. The cure is called "learning".
Arrogance can be cured. The cure is called "humbling".
Curing arrogant ignorance requires more.
It requires a personality transplant and is best accomplished after the subject has been removed 
from public office.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] chroma colour

2020-09-24 Thread Mark Filipak (ffmpeg)

On 09/24/2020 09:21 AM, Paul Bourke wrote:

Nice idea, what upscaling methods you use? Do you use swscale by any chance?


Not sure I understand. I don't upscale the movie/image, rather my code
that creates the remap filters just creates the maps 2,3,4 times
bigger than I eventually plan to use.


Hi, Paul. Can you tell me something about "the maps"? Are you referring to an ordinary array of 
cooked picture samples or do you mean something special that I'm unaware of?


Thanks!




And what filters for upscaling and later downscaling 
(bilinear/lanczos/spline/...) ?


Generally just bilinear.

--
Ignorance can be cured. The cure is called "learning".
Arrogance can be cured. The cure is called "humbling".
Curing arrogant ignorance requires more.
It requires a personality transplant and is best accomplished after the subject has been removed 
from public office.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffplay struggling with this station!

2020-09-23 Thread Mark Filipak (ffmpeg)

On 09/24/2020 12:52 AM, Edward Park wrote:

Hi,

I just realized that the station was public, so I just tried:
% ffplay -nodisp -vn 
"https://jrtv-live.ercdn.net/jrradio/englishradiovideo.m3u8”
no issues.

I did try without that buffer flag, but that had no effect. I’m going to try 
updating ffplay, and see if that helps.

Yeah also update the tls library before building and if that still doesn’t fix 
it it might be the connection speed?


Also, I’ve noticed that vlc had a 1000 ms “network cache”, and I wonder if that 
had anything to do with playing that station flawlessly.


That probably means something like it’s’ playing 1 second in the past, so if 
something happens and it can’t keep up in realtime there’s still 1 second to 
fix it before it skips.


That's exactly what it means, though I think the word "buffer" would be more 
appropriate.

cache [noun]: a temporary storage space or memory that allows fast access to 
data.

buffer [noun]: a storage device for temporarily holding data until the computer is ready to receive 
or process the data, as when a receiving unit has an operating speed lower than that of the unit 
feeding data to it.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-23 Thread Mark Filipak (ffmpeg)

On 09/23/2020 05:27 PM, Paul B Mahol wrote:

On Wed, Sep 23, 2020 at 04:26:27PM -0400, Mark Filipak (ffmpeg) wrote:

On 09/23/2020 03:53 PM, Carl Eugen Hoyos wrote:

Am Di., 22. Sept. 2020 um 00:47 Uhr schrieb 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)
:



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.


This is not true:

How can a frame contain just one field?


I did not ask for an example to see "how you can feed one field to a
filter". I asked how a frame can contain just one field. You have yet to
answer that. I think it's impossible. You may be referring to a frame that
is deinterlaced and cut in half (e.g. from 720x576 to 720x288), in which
case the frame contains no field.

You wrote: "(If you provide only one field, no FFmpeg deinterlacer will
produce useful output.)". Of course I agree with the "no...useful output"
part, however, how can a person "provide only one field"? That implies that
"provide only one field" is an option. I think that's impossible, so I asked
you how it was possible. I did not ask how to implement that impossibility
on the command line (which I think is likewise impossible). It is along
these lines that misunderstanding and confusion and novice angst ensues.

Am I nitpicking? I think not. You are an authority. When an authority uses
loose language, misunderstanding and confusion and angst must follow. But
MPEG and ffmpeg seems to be primed to require loose language. That needs to
end.


Try to read and follow separatefields, weave and doubleweave filters 
documentation.


Thank you, Paul. I do try to read them. Is there something specific to which 
you can point?
All inputs are accepted and appreciated. I'm sure we both endeavor to make 
ffmpeg better.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-23 Thread Mark Filipak (ffmpeg)

On 09/23/2020 03:53 PM, Carl Eugen Hoyos wrote:

Am Di., 22. Sept. 2020 um 00:47 Uhr schrieb 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)
:



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.


This is not true:

How can a frame contain just one field?


I did not ask for an example to see "how you can feed one field to a filter". I asked how a frame 
can contain just one field. You have yet to answer that. I think it's impossible. You may be 
referring to a frame that is deinterlaced and cut in half (e.g. from 720x576 to 720x288), in which 
case the frame contains no field.


You wrote: "(If you provide only one field, no FFmpeg deinterlacer will produce useful output.)". Of 
course I agree with the "no...useful output" part, however, how can a person "provide only one 
field"? That implies that "provide only one field" is an option. I think that's impossible, so I 
asked you how it was possible. I did not ask how to implement that impossibility on the command line 
(which I think is likewise impossible). It is along these lines that misunderstanding and confusion 
and novice angst ensues.


Am I nitpicking? I think not. You are an authority. When an authority uses loose language, 
misunderstanding and confusion and angst must follow. But MPEG and ffmpeg seems to be primed to 
require loose language. That needs to end.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-23 Thread Mark Filipak (ffmpeg)

On 09/23/2020 12:19 PM, Greg Oliver wrote:

On Tue, Sep 22, 2020 at 1:14 PM Mark Filipak (ffmpeg) 
wrote:

-snip-


He has repeatedly posted to either understand or define better
the internals of ffmpeg itself...


Thanks for the kind words.

Yaknow, I'm not special or a wizard. I suffer the same assumptions as everyone. As I work on my 
glossary, I'm amazed when I realize something that I had wrong, but had worked on steadily for weeks 
without actually seeing.


Let me give you an example. Last night I realized no matter whether a stream is frame or TFF 
(top_field_first) or BFF (bottom_field_first), that macroblock samples have exactly the same order; 
that it's the order that these samples are read out by the decoder that determines whether the 1st 
sample goes to line 1 or line 2, and whether the 4 luminance blocks are concurrent (aka "progressive").


In other words, TFF and BFF are not formats. They are access methods!!

That realization caused me to dump a raft of seemingly clever, seemingly insightful diagrams that 
had taken weeks of revisions to hone. I realized that those diagrams were crap and just reinforced 
concepts that seem reasonable and are universally accepted but that can't survive close scrutiny.


That kind of insight (which makes me think I'm stupid for not seeing it immediately) will be in the 
glossary. The existing stuff not only implies that fields exist -- fields do not exist (no such 
structure, at least not in streams) and it took me a month of learning how to parse macroblocks to 
discover that -- the existing stuff implies that TFF and BFF are differing formats, but they're not 
formats at all!


I contend that ordinary users can understand the differences between (hard) structure and (soft) 
description, and between a format and a method. I think ordinary users are so hungry to get real 
information that they're willing beg and plead and (nearly) debase themselves.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-22 Thread Mark Filipak (ffmpeg)

On 09/22/2020 04:20 AM, Edward Park wrote:


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


Ah okay I thought that was a bit weird, I assume it was a typo but I saw h.242 and 
thought two different types of "frames" were being mixed. Before saying 
anything if the side project you mentioned was a layman’s glossary type reference 
material, I think you should base it off of the definitions section instead of the 
bitstream definitions, just my $.02.


H.242 was indeed a typo ...Oh, wait! Doesn't (H.222+H.262)/2 = H.242?. :-)

I'm not sure what you mean by "definitions section", but I don't believe in "layman's" glossaries. I 
believe novices can comprehend structures at a codesmith's level if the structures are precisely 
represented. The novices who can't comprehend the structures need to learn. If they don't want to 
learn, then they're not really serious. This video processing stuff is for serious people. That 
written, what is not reasonable, IMHO, is to expect novices to learn codesmith-jargon and 
codesmith-shorthand. English has been around for a long time and it includes everything that is needed.


I would show you some of my mpegps parser documentation and some of my glossary stuff, but 90% of it 
is texipix diagrams and/or spreadsheet-style, plaintext tables that are formatted way wider than 70 
characters/line, so won't paste into email.


-snip-

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?


This was the main info I was trying to add, it's not a standard of any kind, 
quite the opposite, actually, since technically its declaration could be 
changed in a single commit, but I don't think that is a common occurrence. 
AVFrame is a struct that is used to abstract/implement all frames in the many 
different formats ffmpeg handles. it is noted that its size could change as 
fields are added to the struct.

There's documentation generated for it here: 
https://www.ffmpeg.org/doxygen/trunk/structAVFrame.html


Oh, Thank You! That's going to help me to communicate/discuss with the 
developers.


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


I thought ISO 13818-2 was basically the identical standard, and it gives pretty 
clear definitions imo, here are some excerpts. (Wall of text coming up… 
standards are very wordy by necessity)


--snip 13818-2 excerpts--

To me, that's all descriptions, not definitions. To me, it's vague and ambiguous. To me, it's sort 
of nebulous.


Standards don't need to be wordy. The *more* one writes, the greater the chance of mistakes and 
ambiguity. Write less, not more.


Novices aren't dumb, they're just ignorant. By your use of "struct" in your reply, I take it that 
you're a 'C' codesmith -- I write assy & other HLL & hardware description languages like VHDL & 
Verilog, but I've never written 'C'. I've employed 'C' codesmiths, therefore, I'm a bit conversant 
with 'C', but just a bit.


What I've noted is that codesmiths generally don't know how to write effective English. Writing well 
constructed English is difficult and time consuming at first, as difficult as learning how to 
effectively use any syntax that requires knowledge and experience. There are clear rules but most 
codesmiths don't know them, especially if English is their native language. They write like they 
speak: conversationally. And when others don't understand what's written, rather than revise 
smaller, the grammar-challenged revise longer thinking that yet-another-perspective is what's 
needed. That produces ambiguity because different perspectives promotes ambiguity. IMHO, there 
should solely be just one perspective: structure. Usage is the place for description but that's not 
(or shouldn't be) in the domain of a glossary.



So field pictures are decoded fields, and frame pictures are decoded frames? 
Not sure if I understand 100% but I think it’s pretty clear, “two field 
pictures comprise a coded frame.” IIRC field pictures aren’t decoded into 
separate fields because two frames in one packet makes something explode within 
FFmpeg


Well, packets are just how transports chop up a stream in order to send it, piecewise, via a 
packetized media. They don't matter. I think that, for mpegps, start at 'sequence_header_code' (i.e. 
x00 00 01 B3) and proceed from there, through the transport packet headers, throwing out the packet 
headers, until encountering the next 'sequence_header_code' or the 'sequence_end_code' (i.e. x00 00 
01 B7).


I don't know how frames are passed from the decoder to a filter inside ffmpeg. I don't know whether 
the frames are in the form of decoded samples in a macroblock structure or are just a glob of bytes. 
Considering the differences between 420 & 422 & 444, I think that the frames passed from the decoder 
must have some structure

Re: [FFmpeg-user] bwdif filter question

2020-09-22 Thread Mark Filipak (ffmpeg)

On 09/22/2020 05:59 AM, Nicolas George wrote:

Mark Filipak (ffmpeg) (12020-09-21):

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


Quoting yourself does not prove you right.


You are correct. That's why H.262 is in the definition. I'm not quoting myself. 
I'm quoting H.262.



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-21 Thread Mark Filipak (ffmpeg)

On 09/21/2020 06:54 PM, Bouke wrote:



On 22 Sep 2020, at 00:44, Mark Filipak (ffmpeg)  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


You calling me a troll doesn't make it so.

Anyone following this thread know from which direction the insults come.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-21 Thread 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)
:


On 09/21/2020 03:33 AM, Carl Eugen Hoyos wrote:



Am 21.09.2020 um 01:56 schrieb Mark Filipak (ffmpeg) :

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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-21 Thread 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

Re: [FFmpeg-user] bwdif filter question

2020-09-21 Thread 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) :

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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-21 Thread 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) :

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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-20 Thread 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) 
:

On 09/18/2020 03:01 PM, Carl Eugen Hoyos wrote:

Am 16.09.2020 um 15:58 schrieb Mark Himsley :

On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg)  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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-19 Thread Mark Filipak (ffmpeg)

On 09/18/2020 03:01 PM, Carl Eugen Hoyos wrote:

Am 16.09.2020 um 15:58 schrieb Mark Himsley :

On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg)  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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Video Glossary (was: bwdif filter question)

2020-09-16 Thread Mark Filipak (ffmpeg)

On 09/16/2020 09:58 AM, Mark Himsley wrote:

On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg)  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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] bwdif filter question

2020-09-14 Thread Mark Filipak (ffmpeg)

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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] bwdif filter question

2020-09-14 Thread 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
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "interlace"

2020-09-06 Thread Mark Filipak

On 09/06/2020 05:24 PM, Edward Park wrote:



I have great respect for you, Ted. Tell me: What is interlaced video?


Well that is unwarranted, possibly spiteful, even, to someone as insecure as me 
;)


Hahahaha... Ted I want you to do something for me. Take your right hand, put it over your left 
shoulder, extend it down your back, and, with an open palm, slap it against your back two or three 
times. This list is a better place with you in it.



That is the real question isn't it. Probably won't be very satisfying but I'll 
try to describe it. Probably not useful to say it's video that is interlaced 
(or to be interlaced) lines.


Well, that's interesting. Is interlaced *lines* a requirement for interlaced video? I would say so, 
but tell me: How does what is called interlaced video related to interlaced *lines*?



Video as in not film? When individual frames don't correspond to a single 
moment in time.


Well, there you go. That's what everyone says. But a video that is field-based (aka "interlaced", 
yuck!) can also portray a single moment in time. In fact, the vast majority of so-called 
"interlaced" video is actually concurrent. I'm sure you agree with that, eh? So, if "interlaced" is 
not really a good word for "in fields" or "composed of fields", then what is a good term?


Variables:
Frame-based v. field-based
Concurrent v. successive (or, if you prefer, pictures v. scans)

There are 4 combinations:
1, Frame-based pictures
2, Field-based pictures
3, Frame-based scans
4, Field-based scans

Number 1 seems reasonable. Agreed?
If a picture is an image that completely fills the frame, then number 2 is a contradiction in terms. 
Agreed? I use the term "half-picture" for the fields extracted from a frame. What do you think of that?

Number 3 is possible, but not desirable due to excessive combing. Agreed?
Number 4 applies to streams that were generated by scanning cameras (TV studios) to be viewed on 
scanning TVs (CRTs), so is not really applicable for new video, today. Nonetheless, they do exist, 
if only as legacy video. Agreed?


1, Frame-based pictures
2, Field-based half-pictures
3, Frame-based scans -- beware!
4, Field-based scans -- legacy

What do you think?


Regards,
Ted Park


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "interlace"

2020-09-06 Thread Mark Filipak

On 09/06/2020 04:16 PM, Edward Park wrote:

Hi,


In the case of "interlace":
"It's interlaced video" -- video in which the lines alternate (i.e. are interlaced) between two (or 
theoretically, more) fields (e.g. odd-even-odd-even...). That employs the past participle of the verb, 
"interlace", as an adjective to modify "video".

H.262 refers to "interlace video" when referring to hard telecine. But "interlace video" is a bit of a mutt. 
"Interlace" is clearly being used as an adjective, yet "interlace" is not a participle (past or present) -- 
"interlaced" is the past participle and "interlacing" is the present participle. What it would have to be is a verbal 
adjective (i.e. a verb used as an adjective). I may be wrong, but I don't think there exists such a thing as a verbal adjective.

That's more or less what a participle is.


A hard telecined video residing on a disc is clearly not interlaced. It is 
clearly deinterlaced (i.e. stored in fields). Since it is deinterlaced, it can 
be fed directly to a scanning TV (i.e. CRT) provided it is of the proper frame 
rate, or it can be interlaced -- a verb -- by a decoder as part of the decoding 
step.


Is it? Hard telecine is like telecining film and then recording it on a VCR, 
isn't it? And you don't need to deinterlace interlaced video to display it on 
an interlaced scanning TV. I think the confusion is when you deinterlace 
interlaced video, it is still interlaced video (or at least I think of it that 
way).

Regards,
Ted Park


"interlace [transitive verb]: 1. To connect by or as if by lacing together; interweave. 2. To 
intersperse; intermix: 'interlaced lies with truth'. [intransitive verb]: To intertwine."


The word "interlaced" is universally applied to scan fields. Scan fields are not interlaced. The 
lines are aggregated into odd and even fields (i.e. blocks at the macroblock level) but the rows 
("lines" if you will) are not interlaced. Scan fields are interleaved, but that is not interlacing. 
If anything, that is deinterlacing.


Given the historic misuse of "interlace", I will continue to use alternatives. The best alternative 
is "field-based". Next is "unweaved". Also acceptable is "interleaved" because that aptly describes 
the condition of the fields.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "interlace"

2020-09-06 Thread Mark Filipak

On 09/06/2020 03:33 PM, Carl Eugen Hoyos wrote:

Am So., 6. Sept. 2020 um 21:27 Uhr schrieb Mark Filipak
:


All of the ffmpeg documentation that uses the word "interlaced"
should be checked for accuracy.


Since real-world users are using this documentation it should only
be carefully changed.

Or in other words: We will certainly not change our definition of
"interlaced video" - many people seem to understand it.


Do they really? There are alternatives that are more appropriate.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "interlace"

2020-09-06 Thread Mark Filipak

On 09/06/2020 04:16 PM, Edward Park wrote:

Hi,


In the case of "interlace":
"It's interlaced video" -- video in which the lines alternate (i.e. are interlaced) between two (or 
theoretically, more) fields (e.g. odd-even-odd-even...). That employs the past participle of the verb, 
"interlace", as an adjective to modify "video".

H.262 refers to "interlace video" when referring to hard telecine. But "interlace video" is a bit of a mutt. 
"Interlace" is clearly being used as an adjective, yet "interlace" is not a participle (past or present) -- 
"interlaced" is the past participle and "interlacing" is the present participle. What it would have to be is a verbal 
adjective (i.e. a verb used as an adjective). I may be wrong, but I don't think there exists such a thing as a verbal adjective.

That's more or less what a participle is.


A hard telecined video residing on a disc is clearly not interlaced. It is 
clearly deinterlaced (i.e. stored in fields). Since it is deinterlaced, it can 
be fed directly to a scanning TV (i.e. CRT) provided it is of the proper frame 
rate, or it can be interlaced -- a verb -- by a decoder as part of the decoding 
step.


Is it? Hard telecine is like telecining film and then recording it on a VCR, 
isn't it? And you don't need to deinterlace interlaced video to display it on 
an interlaced scanning TV. I think the confusion is when you deinterlace 
interlaced video, it is still interlaced video (or at least I think of it that 
way).

Regards,
Ted Park


I have great respect for you, Ted. Tell me: What is interlaced video?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Question about macroblocks in soft telecined video

2020-09-06 Thread Mark Filipak

On 09/06/2020 03:31 PM, Carl Eugen Hoyos wrote:

Am So., 6. Sept. 2020 um 19:07 Uhr schrieb Mark Filipak


First, Carl Eugen, could you fix your email client so that it doesn't echo people's email addresses 
in the clear?


-snip-

So-called "progressive" video -- I prefer "concurrent" -- is contained in 
interlaced data structures
within the macroblocks. Hard telecined video (which may or may not be 
concurrent depending on
whether it comes from cinema or from TV) is contained in deinterlaced data 
within the macroblocks
that the decoder interlaces to make frames as part of the decoding process. My 
question has to do
with whether, for soft telecine, the fields in the chrominance blocks of 
undecoded macroblocks is
deinterlaced or interlaced.


As said before: I don't think this makes sense (not even for mpeg2 video).


I offered to post pictures but you didn't respond. I really like pictures. Pictures don't generally 
require explanations. Written text in lieu of pictures is counterproductive. The more that is 
written, the more that can be wrong or misunderstood. ffmpeg documentation doesn't have (avoids?) 
pictures. Why is that?

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "interlace"

2020-09-06 Thread Mark Filipak

On 09/06/2020 03:32 PM, Bouke wrote:



On 06 Sep 2020, at 21:26, Mark Filipak  
wrote:


Conclusion: Employing the past participle, "interlaced", to a field-based video 
stream is just plain wrong.


Can you just shut up / stop spreading nonsense?


How is it nonsense? The present participle, "interlaced", is being misapplied by people who exhibit 
poor language usage and it's unfortunately caught on. ffmpeg is unintentionally helping to spread 
the misapplication.


This controversy and prejudice in favor of poor usage is why I recommend that "interlace" be retired 
in favor of "interleave".

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] "interlace"

2020-09-06 Thread Mark Filipak
Admittedly, this is an anal-compulsive topic. But good documentation often requires anal compulsion. 
Good documentation definitely requires thorough knowledge of language usage.


The topic is use of the various forms of the word "interlace". But I'm going to use the word "build" 
as an example because it has more, and more varied cases.


"Let's build it" -- "build" as a verb.
"We will be building it" employs "build" as a present participle.
"Assemble the building crew" is the present participle used as an adjective (the crew is actively 
engaged in building something, so it is the "building crew" as opposed to some other "crew").

"It's a tall building" employs "build" as a verbal noun.
"Assemble the building's crew" is the verbal noun used as a possessive adjective (the crew is 
associated with "the building" as opposed to some other crew that's not associated with "the 
building") in the same way that "the cat's meow" uses the ordinary noun, "cat", as a possessive 
adjective.


In the case of "interlace":
"It's interlaced video" -- video in which the lines alternate (i.e. are interlaced) between two (or 
theoretically, more) fields (e.g. odd-even-odd-even...). That employs the past participle of the 
verb, "interlace", as an adjective to modify "video".


H.262 refers to "interlace video" when referring to hard telecine. But "interlace video" is a bit of 
a mutt. "Interlace" is clearly being used as an adjective, yet "interlace" is not a participle (past 
or present) -- "interlaced" is the past participle and "interlacing" is the present participle. What 
it would have to be is a verbal adjective (i.e. a verb used as an adjective). I may be wrong, but I 
don't think there exists such a thing as a verbal adjective.


A hard telecined video residing on a disc is clearly not interlaced. It is clearly deinterlaced 
(i.e. stored in fields). Since it is deinterlaced, it can be fed directly to a scanning TV (i.e. 
CRT) provided it is of the proper frame rate, or it can be interlaced -- a verb -- by a decoder as 
part of the decoding step.


Conclusion: Employing the past participle, "interlaced", to a field-based video stream is just plain 
wrong. All of the ffmpeg documentation that uses the word "interlaced" should be checked for accuracy.

--
Racism is like roaches. When you switch on the light, they scurry.
But if you don't switch on the light, you don't know they're there.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Question about macroblocks in soft telecined video

2020-09-06 Thread Mark Filipak

On 09/06/2020 12:07 PM, Carl Eugen Hoyos wrote:

Am So., 6. Sept. 2020 um 09:28 Uhr schrieb Mark Filipak
:

[...]


Soft telecined video is actually 23/1.001 frames per second of video
even though the metadata tells the decoder to produce 30/1.001 FPS.


On the FFmpeg user mailing list, "decoder" and "metadata" have
relatively strict meanings.


Your point is a 'lateral arabesque'. Argue the issues please. Don't bring up something unrelated in 
an attempt to discredit what I wrote.



Given these meanings, what you write
is simply wrong.
(Apart from the fact that telecined content does not necessarily
have a framerate of 24000/1001, ...


That's an ad homonym attack. I didn't say "telecined". I said "soft telecined". *Soft telecined* 
frames *do* have an FPS of 24/1.001.



... the whole point is that it can
have any framerate, in the case of ntsc crts any framerate smaller
than 3/1001.)


CRTs? What does the display device have to do with anything? (And NTSC CRTs definitely do have 
30/1.001 Hz frame rate. Solely 30/1.001 Hz frame rate. Otherwise, they're not NTSC.)



Of course, the metadata is the key to how the stream 'teaches' the
decoder how to telecine.


But since we don't want to telecine, this is irrelevant: We don't have
access to an ntsc crt. If you decide to telecine, this cannot be done
in the (FFmpeg) decoder, you need a (FFmpeg) video filter.


You continue to fail to understand the issue. I'm addressing undecoded video, not decoded video. Why 
am I addressing undecoded video? Because that's what's on a DVD or BD. You don't care about that 
because you (ffmpeg developers) get undecoded frames from the decoder. We (ffmpeg users) need to 
detect what's on discs because that's important.



MPV is smart enough to recognize 23/1.001 FPS data and to ignore
the metadata and to play at 23/1.001 FPS.



Ffmpeg can do the same thing (and thereby eliminate the need to
transcode)


Telecine and transcoding do not depend on each-other so this is
highly misleading.


They do depend on each other. Users transcode soft telecined video to get 24FPS because they think 
that's what they need to do. Instead, all they need to do is force 24/1.001 -- at least, that's what 
I think, but I'm unsure because ffmpeg is so poorly documented.



but the ffmpeg user has to tell ffmpeg to do it.


No, in general, this is not true.
(Command line and complete, uncut console output missing.)


I don't know how to respond to that. Console output doesn't have anything to do with adequate 
documentation. The issue isn't a command line mistake. The issue is: How does ffmpeg work?



A few random remarks:
You provided some definitions (actually claims) in your email without
explaining in which domain you believe they are valid. ...


The 'domain' is undecoded video as found on DVDs & BDs.


... They are not
valid in the general case (and not valid in most domains).
I believe you somewhere mention that you want to detect soft-
telecined content. This is trivial and is not related to macroblocks.


So-called "progressive" video -- I prefer "concurrent" -- is contained in interlaced data structures 
within the macroblocks. Hard telecined video (which may or may not be concurrent depending on 
whether it comes from cinema or from TV) is contained in deinterlaced data within the macroblocks 
that the decoder interlaces to make frames as part of the decoding process. My question has to do 
with whether, for soft telecine, the fields in the chrominance blocks of undecoded macroblocks is 
deinterlaced or interlaced.



Your definition of our different interpretations of "interlaced" is
completely backwards and wrong: ...


If you read H.222 and H.262 carefully, you will find that so-called "interlaced" video is not called 
"interlaced". It's called "interlace" (no "d"). It's called "interlace" because interlace is what 
the decoder does. If you read H.222 and H.262 carefully, you will find that the undecoded data is, 
in fact, deinterlaced (in other words: The undecoded data is in fields, not frames).


Interlaced frames is NOT what's found in undecoded video. What's found in undecoded video are 
deinterlaced fields. It is you who have it backwards. And that backwardness is what confused me and 
what confuses others.



... A digital video stream can be
encoded (!, not decoded as you imply) using encoding techniques
meant for interlaced content. The decoder has to detect this and
comply with it but this has no relevance for a user (it for many years
was very important for FFmpeg developers). For display, it is
very important to know if the actual content is interlaced or not.
Most video players take the first information to decide but this is
not valid in general (or, u

Re: [FFmpeg-user] Question about macroblocks in soft telecined video

2020-09-06 Thread Mark Filipak

On 09/06/2020 02:26 AM, Carl Eugen Hoyos wrote:

Am So., 6. Sept. 2020 um 06:20 Uhr schrieb Mark Filipak
:


I would guess that, for an undecoded video that's soft telecined (i.e. 
@24/1.001 FPS),
the interlace in the macroblocks is field-based (i.e. the same as if @30/1.001 
FPS),
not frame-based (i.e. the same as if @24 FPS).


This does not make sense.


Okay. I followed what I wrote with an example (below), so I'll go with the example because... 
examples are usually easier to understand than are abstractions.



Specifically, for YCbCr420, blocks 5 (Cb) & 6 (Cr) are deinterlaced into top & 
bottom
fields (in the top-half & bottom-half of the blocks) rather than being 
progressive.


This seems more difficult to understand but I don't think it makes sense either.


A YCbCr420 macroblock contains 6 blocks: blocks 1..4, which are 256 samples of Y (luminance) at full 
resolution, and blocks 5+6, which are each 64 samples of chrominance: Cb & Cr, at 1/4 resolution.


I'm happy to I explain.

For undecoded, frame-based (so-called "progressive") macroblocks, the Y-blocks (1..4) are 4-way 
interleaved in the stream (2x2 samples/quad, 4x4 quads/block, 2x1 blocks/field, and 1x2 
fields/frame) -- [1] -- and must be deinterleaved by the decoder to arrive at whole and unbroken 
(concurrent) frames. Staying with frame-based macroblock, the Cb & Cr blocks (5 & 6) are entirely 
uninterleaved because 64 samples (remember, 1/4 resolution) fit in 64 bytes.


[1] I reserve the word "interlace" for whole sample rows, only, not parts of sample rows. 
Frame-based macroblocks are never deinterlaced when they're encoded. Consequently, they don't have 
to be interlaced when they're decoded because they're already interlaced.


For undecoded, field-based (so-called "interlaced") macroblocks, in addition to the 4-way 
interleaves, the 2x2 quads between blocks 1 & 3 (and also between blocks 2 & 4) are deinterlaced in 
the stream and must be interlaced by the decoder to arrive at whole and unbroken frames. The 
equivalent deinterlace for chrominance is that the rows in top half of block 5 (Cb) are deinterlaced 
with the rows in the bottom half of block 5, and must be interlaced by the decoder. Likewise for 
block 6 (Cr).


You see, to you guys, all that's important is that frames come out of the decoder as whole, unbroken 
streams. But to anyone who examines disc files (VOBs), the stuff on the disc is all we have to work 
with when trying to figure out a strategy for identifying the nature of the source. And the nature 
of the source is important.


Okay, to proceed. Soft telecined video is actually 23/1.001 frames per second of video even though 
the metadata tells the decoder to produce 30/1.001 FPS. Of course, the metadata is the key to how 
the stream 'teaches' the decoder how to telecine. MPV is smart enough to recognize 23/1.001 FPS data 
and to ignore the metadata and to play at 23/1.001 FPS. Ffmpeg can do the same thing (and thereby 
eliminate the need to transcode), but the ffmpeg user has to tell ffmpeg to do it.


Okay, so what does this have to do with macroblocks? Well, I'm writing a video glossary and I want 
it to be complete. For example, think back to the controversy we've had regarding the meaning of 
"interlace". From your perspective, interlace is function that the decoder performs. From my 
perspective, interlace is a condition of the stream. From your perspective, it seems like I don't 
know what I'm talking about. From my perspective, it seems like ffmpeg developers are using sloppy 
nomenclature. We have both been right and wrong.


Studying macroblocks has shown me what your perspective is. To you, interlacing is what the decoder 
must do. Of course that's correct. To me (prior to studying macroblocks), interlacing was an 
architectural feature of the stream (program or transport), and saying that fields that are clearly 
deinterlaced in the stream are 'interlaced' just didn't make sense. Of course, your perspective is 
after decoding while my perspective is prior to decoding (because discs contain undecoded 
macroblocks!). I hope I've made myself clearly understood.


By the way, I have made pictures of all this stuff. Would you like to see them?

--
Racism is like roaches. When you switch on the light, they scurry.
But if you don't switch on the light, you don't know they're there.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Question about macroblocks in soft telecined video

2020-09-05 Thread Mark Filipak
I can't answer this for myself because I don't have the tools needed to probe into undecoded 
macroblocks (at least, I don't think I have the tools).


I would guess that, for an undecoded video that's soft telecined (i.e. @24/1.001 FPS), the interlace 
in the macroblocks is field-based (i.e. the same as if @30/1.001 FPS), not frame-based (i.e. the 
same as if @24 FPS). Specifically, for YCbCr420, blocks 5 (Cb) & 6 (Cr) are deinterlaced into top & 
bottom fields (in the top-half & bottom-half of the blocks) rather than being progressive.


Is my guess correct?

Thanks so much!
- Mark.
--
Racism is like roaches. When you switch on the light, they scurry.
But if you don't switch on the light, you don't know they're there.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] builds for Windows

2020-09-03 Thread Mark Filipak

On 09/03/2020 04:58 PM, Carl Zwanzig wrote:

On 9/3/2020 1:49 PM, Mark Filipak wrote:
I'm not sure but I think building ffmpeg is pretty time-consuming. If I obtain help figuring out 
how to do it -- dependencies have defeated me -- I can do Linux makes, perhaps on alternate days. 
If others do the same, the task can become distributed and less of an individual burden.


I'm up for that.

Mark- build environment makes a fair difference; I use MinGW-64 and it works fairly well, that is, 
no hairy problems that I recall :).


z!


When I submit "MinGW-64" to Synaptic, I get 11 hits, none of which are installed. Synaptic includes 
no way for me to copy the list, but here's the 'prime suspect'. :-)


'mingw-w64' 4.0.4-2

When I mark that for installation, 12 additional dependencies are marked (but, curiously, not 
'mingw-w64-tools' 4.0.4-2


In that past, installing 'mingw-w64' was not sufficient.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] builds for Windows

2020-09-03 Thread Mark Filipak

On 09/03/2020 01:42 AM, Gyan Doshi wrote:



On 02-09-2020 11:53 pm, Michael Koch wrote:

"ffmpeg.zeranoe.com will close on Sep 18, 2020, and all builds will be removed."

Any idea where we can get builds for Windows after this date?


I plan to provide 64-bit static builds starting the 18th. Will update doc with link once I make 
arrangements.


Gyan


Gyan,

I'm not sure but I think building ffmpeg is pretty time-consuming. If I obtain help figuring out how 
to do it -- dependencies have defeated me -- I can do Linux makes, perhaps on alternate days. If 
others do the same, the task can become distributed and less of an individual burden.


- Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] prores_ks vendor: apl0 or ap10 ?

2020-09-01 Thread Mark Filipak

On 09/01/2020 09:16 AM, Paul B Mahol wrote:

On 9/1/20, Phil Rhodes via ffmpeg-user  wrote:

  I don't know if you have the slightest idea how offensive you're being -
perhaps it's a language problem, so I'll give you the benefit of not much
doubt. Even so, you should know that what you're saying is the sort of thing
that would ordinarily get people thrown out of meetings or dismissed from
jobs. Really, you shouldn't do that.
And again, if you're putting it in the documentation, you are recommending
it. If you don't want to recommend it, fine, take it out of the
documentation.
What you're overlooking here is that I'm trying to help you, and yes, you do
very definitely need the help.


This is very offensive behavior from you. I'm simply stating fact that
you are not
telling the truth when saying that FFmpeg recommended to change
default vendor string
in encoded ProRes bitstream.


That's what you think you're saying. Paul, you have the manners of an angry 
rhinoceros.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Some questions about PTS

2020-08-28 Thread Mark Filipak
The PTS value below: 000-    000- 1000 1001 1000 111-, is for a particular case. It will 
vary for other videos. I hope that didn't confuse you.


On 08/28/2020 03:51 AM, Michael Koch wrote:

Hello all,

please comment if the following is right or wrong:

-- The timebase of a video (TB in setpts filter) is expressed in the unit [s] 
(seconds).
-- The framerate of a video (FR in setpts filter) is expressed in the unit 
[s^-1] (1/seconds).
-- In many cases the timebase is the reciprocal of the framerate, but this 
isn't always the case.
-- If the timebase is the reciprocal of the framerate, a stream can be delayed by x frames using 
setpts=PTS+x
-- In the more general case for arbitrary timebase and framerate, a stream can be delayed by x 
frames using setpts=PTS+x/(FR*TB)


I don't know enough yet to know whether this helps, but PTS in H.222 (§2.1.57) is: "A field that may 
be present in a PES packet header that indicates the time that a presentation unit is presented in 
the system target decoder." It's a 33 bit field in the PES HEADER EXTENSION, starting at bit 4,


[.4] PTS:  000-    000- 1000 1001 1000 111-

and must be divided by 90KHz in order to yield seconds. I've seen it solely in 
key frames.

I've computed PTS and the deltas between PTSs for several dozen professionally authored videos and 
they do not correlate to frames, even for CFR video. H.222 presents a decoding model and PTS seems 
to conform to that model, not to the frames in the stream. H.222 appears to be insufficiently 
documented to resolve the discrepancy. It remains mysterious but I hope to eventually resolve it.


- Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Some questions about PTS

2020-08-28 Thread Mark Filipak

On 08/28/2020 03:51 AM, Michael Koch wrote:

Hello all,

please comment if the following is right or wrong:

-- The timebase of a video (TB in setpts filter) is expressed in the unit [s] 
(seconds).
-- The framerate of a video (FR in setpts filter) is expressed in the unit 
[s^-1] (1/seconds).
-- In many cases the timebase is the reciprocal of the framerate, but this 
isn't always the case.
-- If the timebase is the reciprocal of the framerate, a stream can be delayed by x frames using 
setpts=PTS+x
-- In the more general case for arbitrary timebase and framerate, a stream can be delayed by x 
frames using setpts=PTS+x/(FR*TB)


I don't know enough yet to know whether this helps, but PTS in H.222 (§2.1.57) is: "A field that may 
be present in a PES packet header that indicates the time that a presentation unit is presented in 
the system target decoder." It's a 33 bit field in the PES HEADER EXTENSION, starting at bit 4,


[.4] PTS:  000-    000- 1000 1001 1000 111-

and must be divided by 90KHz in order to yield seconds. I've seen it solely in 
key frames.

I've computed PTS and the deltas between PTSs for several dozen professionally authored videos and 
they do not correlate to frames, even for CFR video. H.222 presents a decoding model and PTS seems 
to conform to that model, not to the frames in the stream. H.222 appears to be insufficiently 
documented to resolve the discrepancy. It remains mysterious but I hope to eventually resolve it.


- Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Some more thoughts on documentation

2020-08-23 Thread Mark Filipak

On 08/23/2020 04:27 PM, Carl Zwanzig wrote:

On 8/23/2020 12:30 PM, Mark Filipak wrote:
Developer preparation: Kindly add comments to the source code. The comments don't need to teach or 
explain. They just need to repeat the code's logic, but in English instead of Martian.


I think we'll have to disagree on that, most of the basic logic should be fairly clear to someone 
who knows the 'c' language.


That leaves me out. It's also not true even for 'C' programmers for many reasons involving poor 
choices of variable names, undocumented structures, strange methods, misunderstandings, etc., but I 
don't want to get into a debate. I'd rather submit some of what I've already done and see what folks 
think.


In other words, I'd rather do documentation than talk about documentation. Let's decide what works 
as we go, eh?


How do we start? Should I post stuff to this list? Or is there another, better 
way?

OTOH, there will be some cases they -do- need to be explained; there are 
always points in code which aren't obvious to the casual reader - could be some obscure part of the 
encoding, could be that it fails on some architectures but not on others, could be that a certain 
flag isn't appropriate, etc. But in general, most code out there isn't well commented, anyway. (Way 
back when, code wasn't considered well-commented if less than maybe 20-25% of the non-blank lines 
were comments.)


See also
https://ffmpeg.org/developer.html#Comments


That's written in Martian. I don't read Martian.


https://ffmpeg.org/developer.html#toc-Code-of-conduct


"Kumbaya". It's pertinence to writing documentation is what?


However that doesn't directly affect the user documentation.


Agreed.

- Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Some more thoughts on documentation

2020-08-23 Thread Mark Filipak

On 08/23/2020 02:07 PM, Carl Zwanzig wrote:
-snip-

Charlie's Rule of Technical Reading
It doesn't say what you think it says, nor what you remember it to have said, nor what you were told 
that it says, and certainly not what you want it to say, and if by chance you are its author, it 
doesn't say what you intended it to say. Then what does it say? It says what it says. So if you want 
to know what it says, stop trying to remember what it says, and don't ask anyone else. Go back and 
read it, and pay attention as though you were reading it for the first time.

--Charles E. Beck, P.E., Seattle, WA c2005


I like it!

I also like: "Don't tell, show!"

Lots of examples. Examples of increasing complexity that are selected to progressively illustrate a 
single principle without explicitly preaching.


Lots of pictures and diagrams.

Emphasis of scanability and hackability as much as on readability.

Only one idea per sentence, one subject per paragraph. Favor separate short sentences over compound 
sentences. Favor repeating names over using pronouns: "that", "this", "it", etc. If pronouns are 
used, employ references within the same sentence, not to previous sentences, not to future 
sentences, and certainly not to other paragraphs. Try hard to make the subject of a sentence a named 
item instead of a pronoun -- reserve pronouns for objects or object clauses.


Developer preparation: Kindly add comments to the source code. The comments don't need to teach or 
explain. They just need to repeat the code's logic, but in English instead of Martian.


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] A systematic effort for documentation? [was: Re: Why is format=rgb24 required after maskedmerge?]

2020-08-22 Thread Mark Filipak

On 08/21/2020 11:20 PM, Jim DeLaHunt wrote:
-snip-
There is a great need for a glossary. It should be structured so that each term has an anchor, 
allowing references from anywhere in the documentation to the glossary. My nomination for entries: 
"fps", "GOP", "PTS", "time base".

-snip-

I have been working on a glossary for a very long time that includes all those and much more, and in 
which each and every element of a program stream has a clear, unambiguous structure definition sans 
implied relations (e.g. 'this' implies 'that') and sans vague references to metadata (e.g. a frame 
is a thing that metadata defines as a frame). I've worked my way deeply into the streams and am 
currently resolving macroblock internals [1]. The problem I'm encountering is that in order to 
create clear, unambiguous definitions, I have had to create names for differing things that 
currently have the same names that differ based on 'context' (which sucks), and that I suspect will 
raise much controversy. For example, the word "frame" is applied to a great number of things that 
are not frames -- I have created several unique 'sample-sets' that cover the variant frames, fields, 
and scans. For example, the word "picture" is applied to so-called 'progressive' sample-sets, to 
hard telecined, concurrent "field pictures" (which I call "half-pictures"), and even to successive 
fields (which I call "scans"). In my effort, I've tried very hard to not change too much of the 
current nomenclature.


[1] I've discovered that "interlace" applies not to lines on a display, but to samples within blocks 
within macroblocks. There are several interlace schemes and I'm defining each of them via easy to 
understand diagrams that simultaneously show how they are stored and traversed in-buffer versus 
where they wind up in slices on the display. While attempting to understand what ffmpeg developers 
mean when they refer to "interlace", I now appreciate that looking at top-level metadata in stream 
headers is futile -- they are not directly related. Without a "look" into how blocks and macroblocks 
are structured, one will never understand what ffmpeg developers say regarding "interlace".


Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

2020-08-21 Thread Mark Filipak

On 08/21/2020 11:08 AM, Gyan Doshi wrote:

On 21-08-2020 07:12 pm, Mark Filipak wrote:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:

On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:
FFmpeg's documentation is very incomplete. I had a rough roadmap at the start of the year for 
plugging the gaps, but other events transpired.


I hope to start a systematic effort in September.


May I assist you?


Sure. Do you already have a set of tasks / actions in mind?


How about this? Until we get to know each other and you gauge my capabilities, I'll research and 
document whatever's important to you. I think that initially my most important role would be as an 
editor -- mostly grammar checking. I hope to also add some user perspective and I trust that you 
will not reject what I suggest without thinking about it.


This will be a long journey during which the path will unfold before us. I can 
be patient.

My experience has been to give users many, many examples having consistent structures with faith 
that they will see the important patterns. You know, humans are reported to be very good at seeing 
patterns.


Remember a while ago when I asked folks to post working ffmpeg command lines no matter the task or 
format? My request was rebuffed, but what I was trying to do was gain experience by looking for 
patterns -- Sort of a Krell mind boost. That's all I needed and I'm convinced that's all most people 
need.


Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

<    2   3   4   5   6   7   8   9   10   11   >