Re: [FFmpeg-user] Decimation with ppsrc=1 malfunctions
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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?
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?
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?
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?
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?
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
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?
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
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
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
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
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!
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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"
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"
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"
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"
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
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"
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"
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
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
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
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
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
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 ?
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
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
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
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
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?]
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?
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".