Anamorphic 16:9 SD-DV(D) widescreen to AV1.webm
I wanted to test AV1.webm rendering from anamorphic 16:9 SD-DV(D) widescreen sources, which have different SAR 64:45 than 1080i HDV SAR 4:3 It would be fine to get this SAR value verified and clarified vs Wikipedia's table which specifies different for PAL (16:9) 720x576 : SAR 5:4, PAR 64:45 https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm... This legacy 16:9 SD format was created and can be obtained among the following methods:: 1. DV camcorders with Widescreen feature, the right/true way and wrong/fake way https://www.videouniversity.com/articles/dv-formats-everything-you-need-to-k... 2. DV wide record or downconvert playback using a HD(V) camcorder with this feature 3. DVD video disc enhanced for 16:9 or a BD video disc with 16:9 SD content 4. Render/transcode i.e a HD(V) video file using a) Cin-GG b) FFmpeg I have used the two latter methods as follows: 4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi ffprobe -hide_banner dv07_05_wide_cingg.avi Input #0, avi, from 'dv07_05_wide_cingg.avi': Metadata: software : Lavf60.16.100 Duration: 00:06:58.04, start: 0.000000, bitrate: 30342 kb/s Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 28802 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s16, 1536 kb/s mediainfo dv07_05_wide_cingg.avi General Complete name : dv07_05_wide_cingg.avi Format : AVI Format/Info : Audio Video Interleave Commercial name : DV Format profile : OpenDML Format settings : BitmapInfoHeader / PcmWaveformat File size : 1.48 GiB Duration : 6 min 58 s Overall bit rate mode : Constant Overall bit rate : 30.3 Mb/s Frame rate : 25.000 FPS Writing application : Lavf60.16.100 Video ID : 0 Format : DV Codec ID : dvsd Codec ID/Hint : Sony Duration : 6 min 58 s Bit rate mode : Constant Bit rate : 24.4 Mb/s Width : 720 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Standard : PAL Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Bottom Field First Compression mode : Lossy Bits/(Pixel*Frame) : 2.357 Stream size : 1.40 GiB (95%) Audio ID : 1 Format : PCM Format settings : Little / Signed Codec ID : 1 Duration : 6 min 58 s Bit rate mode : Constant Bit rate : 1 536 kb/s Channel(s) : 2 channels Sampling rate : 48.0 kHz Bit depth : 16 bits Stream size : 76.6 MiB (5%) Alignment : Aligned on interleaves Interleave, duration : 208 ms (5.21 video frames) 4 b) FFmpeg transcode HDV to DV-wide ffmpeg -hide_banner -i hdv07_05.m2t -vf scale=720:576,setsar=64/45,setdar=16/9 -c:v dvvideo -c:a pcm_s16le dv07_05_wide.dv Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> dvvideo (native)) Stream #0:1 -> #0:1 (mp2 (native) -> pcm_s16le (native)) Stream #0:0: Video: dvvideo, yuv420p(tv, bt709, top coded first (swapped)), 720x576 [SAR 64:45 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s frame=10457 fps=356 q=-0.0 Lsize= 1440422kB time=00:06:58.28 bitrate=28210.6kbits/s dup=217 drop=0 speed=14.3x ffprobe -hide_banner dv07_05_wide.dv [dv @ 0x56036476e580] Estimating duration from bitrate, this may be inaccurate Input #0, dv, from 'dv07_05_wide.dv': Metadata: timecode : 00:00:00:00 Duration: 00:06:49.72, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s mediainfo dv07_05_wide.dv General Complete name : dv07_05_wide.dv Format : DV Commercial name : DVCAM File size : 1.37 GiB Duration : 6 min 49 s Overall bit rate mode : Constant Overall bit rate : 28.8 Mb/s Frame rate : 25.000 FPS Recorded date : 1970-01-01 00:00:00.000 Video Format : DV Commercial name : DVCAM Duration : 6 min 49 s Bit rate mode : Constant Bit rate : 24.4 Mb/s Width : 720 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Standard : PAL Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 2.357 Time code of first frame : 00:00:00:00 Time code source : Subcode time code Stream size : 1.17 GiB (85%) Audio ID : 0 Format : PCM Format settings : Big / Signed Duration : 6 min 49 s Bit rate mode : Constant Bit rate : 1 536 kb/s Channel(s) : 2 channels Sampling rate : 48.0 kHz Bit depth : 16 bits Stream size : 75.0 MiB (5%) --------------------------------- The HDV source has Scan order : Top Field First What would be right, Top or Bottom Field First for the output file (they differ)? Rendering next the AVI and DV files to AV1.webm displays correct 16:9 widescreen
пт, 12 янв. 2024 г., 01:44 Terje J. Hanssen via Cin < [email protected]>:
I wanted to test AV1.webm rendering from anamorphic 16:9 SD-DV(D) widescreen sources, which have different SAR 64:45 than 1080i HDV SAR 4:3
It would be fine to get this SAR value verified and clarified vs Wikipedia's table which specifies different for PAL (16:9) 720x576 : SAR 5:4, PAR 64:45
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm...
This legacy 16:9 SD format was created and can be obtained among the following methods::
1. DV camcorders with Widescreen feature, the right/true way and wrong/fake way
https://www.videouniversity.com/articles/dv-formats-everything-you-need-to-k... 2. DV wide record or downconvert playback using a HD(V) camcorder with this feature 3. DVD video disc enhanced for 16:9 or a BD video disc with 16:9 SD content 4. Render/transcode i.e a HD(V) video file using a) Cin-GG b) FFmpeg
I have used the two latter methods as follows:
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
ffprobe -hide_banner dv07_05_wide_cingg.avi Input #0, avi, from 'dv07_05_wide_cingg.avi': Metadata: software : Lavf60.16.100 Duration: 00:06:58.04, start: 0.000000, bitrate: 30342 kb/s Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 28802 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s16, 1536 kb/s
mediainfo dv07_05_wide_cingg.avi General Complete name : dv07_05_wide_cingg.avi Format : AVI Format/Info : Audio Video Interleave Commercial name : DV Format profile : OpenDML Format settings : BitmapInfoHeader / PcmWaveformat File size : 1.48 GiB Duration : 6 min 58 s Overall bit rate mode : Constant Overall bit rate : 30.3 Mb/s Frame rate : 25.000 FPS Writing application : Lavf60.16.100
Video ID : 0 Format : DV Codec ID : dvsd Codec ID/Hint : Sony Duration : 6 min 58 s Bit rate mode : Constant Bit rate : 24.4 Mb/s Width : 720 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Standard : PAL Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Bottom Field First Compression mode : Lossy Bits/(Pixel*Frame) : 2.357 Stream size : 1.40 GiB (95%)
Audio ID : 1 Format : PCM Format settings : Little / Signed Codec ID : 1 Duration : 6 min 58 s Bit rate mode : Constant Bit rate : 1 536 kb/s Channel(s) : 2 channels Sampling rate : 48.0 kHz Bit depth : 16 bits Stream size : 76.6 MiB (5%) Alignment : Aligned on interleaves Interleave, duration : 208 ms (5.21 video frames)
4 b) FFmpeg transcode HDV to DV-wide
ffmpeg -hide_banner -i hdv07_05.m2t -vf scale=720:576,setsar=64/45,setdar=16/9 -c:v dvvideo -c:a pcm_s16le dv07_05_wide.dv Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> dvvideo (native)) Stream #0:1 -> #0:1 (mp2 (native) -> pcm_s16le (native)) Stream #0:0: Video: dvvideo, yuv420p(tv, bt709, top coded first (swapped)), 720x576 [SAR 64:45 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s frame=10457 fps=356 q=-0.0 Lsize= 1440422kB time=00:06:58.28 bitrate=28210.6kbits/s dup=217 drop=0 speed=14.3x
ffprobe -hide_banner dv07_05_wide.dv [dv @ 0x56036476e580] Estimating duration from bitrate, this may be inaccurate Input #0, dv, from 'dv07_05_wide.dv': Metadata: timecode : 00:00:00:00 Duration: 00:06:49.72, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
mediainfo dv07_05_wide.dv General Complete name : dv07_05_wide.dv Format : DV Commercial name : DVCAM File size : 1.37 GiB Duration : 6 min 49 s Overall bit rate mode : Constant Overall bit rate : 28.8 Mb/s Frame rate : 25.000 FPS Recorded date : 1970-01-01 00:00:00.000
Video Format : DV Commercial name : DVCAM Duration : 6 min 49 s Bit rate mode : Constant Bit rate : 24.4 Mb/s Width : 720 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Standard : PAL Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 2.357 Time code of first frame : 00:00:00:00 Time code source : Subcode time code Stream size : 1.17 GiB (85%)
Audio ID : 0 Format : PCM Format settings : Big / Signed Duration : 6 min 49 s Bit rate mode : Constant Bit rate : 1 536 kb/s Channel(s) : 2 channels Sampling rate : 48.0 kHz Bit depth : 16 bits Stream size : 75.0 MiB (5%)
---------------------------------
The HDV source has Scan order : Top Field First What would be right, Top or Bottom Field First for the output file (they differ)?
If I read this random Avid-related post correctly - bottom? https://community.avid.com/forums/p/55996/312955.aspx from memory if you step around wrongly fielded file you get some jarring line motions different from usual interlace-on-progressive line artefacts ....
Rendering next the AVI and DV files to AV1.webm displays correct 16:9 widescreen
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
I wanted to test AV1.webm rendering from anamorphic 16:9 SD-DV(D) widescreen sources, which have different SAR 64:45 than 1080i HDV SAR 4:3
It would be fine to get this SAR value verified and clarified vs Wikipedia's table which specifies different for PAL (16:9) 720x576 : SAR 5:4, PAR 64:45 https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm...
Also, /pixel aspect ratio/ (/PAR/) is also known as /sample aspect ratio/ (abbreviated /SAR/) in some industrial standards (such as H.264 <https://en.wikipedia.org/wiki/Advanced_Video_Coding>^[2] <https://en.wikipedia.org/wiki/Pixel_aspect_ratio#cite_note-2> ) and output of programs (such as /ffmpeg <https://en.wikipedia.org/wiki/Ffmpeg>/ Note 3: "ffprobe shows PAR as SAR" <https://trac.ffmpeg.org/ticket/1776>. ffmpeg.org. Retrieved 2022-06-10.
This legacy 16:9 SD format was created and can be obtained among the following methods::
1. DV camcorders with Widescreen feature, the right/true way and wrong/fake way https://www.videouniversity.com/articles/dv-formats-everything-you-need-to-k... 2. DV wide record or downconvert playback using a HD(V) camcorder with this feature 3. DVD video disc enhanced for 16:9 or a BD video disc with 16:9 SD content 4. Render/transcode i.e a HD(V) video file using a) Cin-GG b) FFmpeg
I have used the two latter methods as follows:
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
ffprobe -hide_banner dv07_05_wide_cingg.avi Input #0, avi, from 'dv07_05_wide_cingg.avi': Metadata: software : Lavf60.16.100 Duration: 00:06:58.04, start: 0.000000, bitrate: 30342 kb/s Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 28802 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s16, 1536 kb/s
mediainfo dv07_05_wide_cingg.avi General Complete name : dv07_05_wide_cingg.avi Format : AVI Format/Info : Audio Video Interleave Commercial name : DV Format profile : OpenDML Format settings : BitmapInfoHeader / PcmWaveformat File size : 1.48 GiB Duration : 6 min 58 s Overall bit rate mode : Constant Overall bit rate : 30.3 Mb/s Frame rate : 25.000 FPS Writing application : Lavf60.16.100
Video ID : 0 Format : DV Codec ID : dvsd Codec ID/Hint : Sony Duration : 6 min 58 s Bit rate mode : Constant Bit rate : 24.4 Mb/s Width : 720 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Standard : PAL Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Bottom Field First Compression mode : Lossy Bits/(Pixel*Frame) : 2.357 Stream size : 1.40 GiB (95%)
Audio ID : 1 Format : PCM Format settings : Little / Signed Codec ID : 1 Duration : 6 min 58 s Bit rate mode : Constant Bit rate : 1 536 kb/s Channel(s) : 2 channels Sampling rate : 48.0 kHz Bit depth : 16 bits Stream size : 76.6 MiB (5%) Alignment : Aligned on interleaves Interleave, duration : 208 ms (5.21 video frames)
4 b) FFmpeg transcode HDV to DV-wide
ffmpeg -hide_banner -i hdv07_05.m2t -vf scale=720:576,setsar=64/45,setdar=16/9 -c:v dvvideo -c:a pcm_s16le dv07_05_wide.dv Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> dvvideo (native)) Stream #0:1 -> #0:1 (mp2 (native) -> pcm_s16le (native)) Stream #0:0: Video: dvvideo, yuv420p(tv, bt709, top coded first (swapped)), 720x576 [SAR 64:45 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s frame=10457 fps=356 q=-0.0 Lsize= 1440422kB time=00:06:58.28 bitrate=28210.6kbits/s dup=217 drop=0 speed=14.3x
ffprobe -hide_banner dv07_05_wide.dv [dv @ 0x56036476e580] Estimating duration from bitrate, this may be inaccurate Input #0, dv, from 'dv07_05_wide.dv': Metadata: timecode : 00:00:00:00 Duration: 00:06:49.72, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
mediainfo dv07_05_wide.dv General Complete name : dv07_05_wide.dv Format : DV Commercial name : DVCAM File size : 1.37 GiB Duration : 6 min 49 s Overall bit rate mode : Constant Overall bit rate : 28.8 Mb/s Frame rate : 25.000 FPS Recorded date : 1970-01-01 00:00:00.000
Video Format : DV Commercial name : DVCAM Duration : 6 min 49 s Bit rate mode : Constant Bit rate : 24.4 Mb/s Width : 720 pixels Height : 576 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Standard : PAL Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 2.357 Time code of first frame : 00:00:00:00 Time code source : Subcode time code Stream size : 1.17 GiB (85%)
Audio ID : 0 Format : PCM Format settings : Big / Signed Duration : 6 min 49 s Bit rate mode : Constant Bit rate : 1 536 kb/s Channel(s) : 2 channels Sampling rate : 48.0 kHz Bit depth : 16 bits Stream size : 75.0 MiB (5%)
---------------------------------
The HDV source has Scan order : Top Field First What would be right, Top or Bottom Field First for the output file (they differ)?
Rendering next the AVI and DV files to AV1.webm displays correct 16:9 widescreen
Also, pixel aspect ratio (PAR) is also known as sample aspect ratio (abbreviated SAR) in some industrial standards (such as H.264[2]) and output of programs (such as ffmpeg Note 3: "ffprobe shows PAR as SAR". ffmpeg.org. Retrieved 2022-06-10.
Yes, exactly. That is what confuses me. The theory is simple: DAR = PAR x SAR DAR and SAR are "frame aspect ratio," PAR is "pixel aspect ratio." It can be said that when SAR (let's imagine it as Width x Height pixels, although it can be expressed as a ratio) is different from DAR we have an anamorphic video and on the Compositor we see the deformed image. Then we intervene with PAR which enlarges or shrinks the pixel so that SAR is equal to DAR again. A possible first confusion is that SAR and DAR can be expressed as both Width x Height and aspect ratio. Another thing that can be confusing is that SAR is not about the Set Format window, but only about the Resource --> Assett --> Info --> Resize, or also Timeline --> RMB --> Resize Track or, further, the Scale plugin). I don't quite understand why ffmpeg and CinGG confuse the definitions of PAR and SAR. Maybe for simplicity of code? In fact, the CinGG workflow is not difficult: we choose the project properties, including the frame size with the "Aspect ratio" option of the Set Format window (which is tied to Width x Height). Then, depending on the sources, we can change W and H, using W Ratio and H Ratio to perform the calculations automatically. All without the need to recall the concepts of SAR, PAR and DAR. If we then consider that anamorphic pixels affect only a very small minority of cases, not putting the concept of PAR serves to consider W/H Ratio as just a simple multiplicative factor between the initial and project frame sizes. Does this explanation sound correct to you? I would appreciate your opinions, because I would like to change the manual.
Andrea, an explanation in the manual would be a good addition. I have read what you wrote and studied a little of what I could find online, and am still somewhat confused so am unable to determine if your explanation sounds correct. But it seems to fit. ...Phyllis On Fri, Jan 12, 2024 at 1:40 AM Andrea paz via Cin < [email protected]> wrote:
Also, pixel aspect ratio (PAR) is also known as sample aspect ratio (abbreviated SAR) in some industrial standards (such as H.264[2]) and output of programs (such as ffmpeg Note 3: "ffprobe shows PAR as SAR". ffmpeg.org. Retrieved 2022-06-10.
Yes, exactly. That is what confuses me. The theory is simple: DAR = PAR x SAR DAR and SAR are "frame aspect ratio," PAR is "pixel aspect ratio." It can be said that when SAR (let's imagine it as Width x Height pixels, although it can be expressed as a ratio) is different from DAR we have an anamorphic video and on the Compositor we see the deformed image. Then we intervene with PAR which enlarges or shrinks the pixel so that SAR is equal to DAR again. A possible first confusion is that SAR and DAR can be expressed as both Width x Height and aspect ratio. Another thing that can be confusing is that SAR is not about the Set Format window, but only about the Resource --> Assett --> Info --> Resize, or also Timeline --> RMB --> Resize Track or, further, the Scale plugin).
I don't quite understand why ffmpeg and CinGG confuse the definitions of PAR and SAR. Maybe for simplicity of code? In fact, the CinGG workflow is not difficult: we choose the project properties, including the frame size with the "Aspect ratio" option of the Set Format window (which is tied to Width x Height). Then, depending on the sources, we can change W and H, using W Ratio and H Ratio to perform the calculations automatically. All without the need to recall the concepts of SAR, PAR and DAR. If we then consider that anamorphic pixels affect only a very small minority of cases, not putting the concept of PAR serves to consider W/H Ratio as just a simple multiplicative factor between the initial and project frame sizes.
Does this explanation sound correct to you? I would appreciate your opinions, because I would like to change the manual. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 12.01.2024 09:40, skrev Andrea paz:
Also, pixel aspect ratio (PAR) is also known as sample aspect ratio (abbreviated SAR) in some industrial standards (such as H.264[2]) and output of programs (such as ffmpeg Note 3: "ffprobe shows PAR as SAR". ffmpeg.org. Retrieved 2022-06-10. Yes, exactly. That is what confuses me. The theory is simple: DAR = PAR x SAR DAR and SAR are "frame aspect ratio," PAR is "pixel aspect ratio." It can be said that when SAR (let's imagine it as Width x Height pixels, although it can be expressed as a ratio) is different from DAR we have an anamorphic video and on the Compositor we see the deformed image. Then we intervene with PAR which enlarges or shrinks the pixel so that SAR is equal to DAR again. A possible first confusion is that SAR and DAR can be expressed as both Width x Height and aspect ratio. Another thing that can be confusing is that SAR is not about the Set Format window, but only about the Resource --> Assett --> Info --> Resize, or also Timeline --> RMB --> Resize Track or, further, the Scale plugin).
I don't quite understand why ffmpeg and CinGG confuse the definitions of PAR and SAR. Maybe for simplicity of code? In fact, the CinGG workflow is not difficult: we choose the project properties, including the frame size with the "Aspect ratio" option of the Set Format window (which is tied to Width x Height). Then, depending on the sources, we can change W and H, using W Ratio and H Ratio to perform the calculations automatically. All without the need to recall the concepts of SAR, PAR and DAR. If we then consider that anamorphic pixels affect only a very small minority of cases, not putting the concept of PAR serves to consider W/H Ratio as just a simple multiplicative factor between the initial and project frame sizes.
Does this explanation sound correct to you? I would appreciate your opinions, because I would like to change the manual.
I have not much to add, but I think it would be useful to add a table with the actual DAR, SAR (and PAR?) values for the most common anamorphic video formats similar https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm... And what and when is manual input necessary in Cinelerra Set Format beyoind Preset and possibly also in the Project setting?
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right? Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ? mediainfo dv07_05_wide_cingg.dv | grep Display Display aspect ratio : 4:3 ffprobe -hide_banner dv07_05_wide_cingg.dv Input #0, dv, from 'dv07_05_wide_cingg.dv': Duration: 00:06:58.08, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
сб, 13 янв. 2024 г., 03:26 Terje J. Hanssen via Cin < [email protected]>:
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right?
Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ?
This is possible! I basically never used non-ffmpeg video encoders! I think we have 3 of them - raw dv, mpeg video and theora video. I'll check each of them.
mediainfo dv07_05_wide_cingg.dv | grep Display Display aspect ratio : 4:3
ffprobe -hide_banner dv07_05_wide_cingg.dv Input #0, dv, from 'dv07_05_wide_cingg.dv': Duration: 00:06:58.08, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
сб, 13 янв. 2024 г., 07:47 Andrew Randrianasulu <[email protected]>:
сб, 13 янв. 2024 г., 03:26 Terje J. Hanssen via Cin < [email protected]>:
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right?
Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ?
This is possible! I basically never used non-ffmpeg video encoders! I think we have 3 of them - raw dv, mpeg video and theora video.
I'll check each of them.
in cinelerra/fileogg.C I found this comment: ===== if( asset->aspect_ratio > 0 ) { // Cinelerra uses frame aspect ratio, theora uses pixel aspect ratio float pixel_aspect = asset->aspect_ratio / asset->width * asset->height; aratio_num = pixel_aspect * 1000000; aratio_den = 1000000; } else { aratio_num = 1000000; aratio_den = 1000000; } ===== strangely enough filedv seems to contain code to set is16x9 encoder flag ... not sure why it fails .... mpeg video also should honor aspect ratio, but not tested yet.
mediainfo dv07_05_wide_cingg.dv | grep Display Display aspect ratio : 4:3
ffprobe -hide_banner dv07_05_wide_cingg.dv Input #0, dv, from 'dv07_05_wide_cingg.dv': Duration: 00:06:58.08, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 13.01.2024 18:48, skrev Andrew Randrianasulu:
сб, 13 янв. 2024 г., 07:47 Andrew Randrianasulu <[email protected]>:
сб, 13 янв. 2024 г., 03:26 Terje J. Hanssen via Cin <[email protected]>:
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right?
Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ?
This is possible! I basically never used non-ffmpeg video encoders! I think we have 3 of them - raw dv, mpeg video and theora video.
I'll check each of them.
OOPS! As already mentioned, CinGG's FFmpeg-avi was saved/displayed 16:9 and the Raw DV was saved/displayed 4:3. BUT, in addition I discovered now that in both cases the images have been cropped around, that is cut off at both sides, top and bottom. That is, the 16:9 avi is displayed with correct geometry, while the 4:3 Raw DV is displayed stretched vertically. The latter get correct geometry if forced aspect 16:9 during VLC playback.. Actually, only my ffmpeg manual encoded DV-wide has got correct DAR 16:9 and also correct geometry. A visual tip is that this is easiest to discover and compare side by side using large file thumbnails with (Gnome) Filemanager.
in cinelerra/fileogg.C I found this comment: =====
if( asset->aspect_ratio > 0 ) { // Cinelerra uses frame aspect ratio, theora uses pixel aspect ratio float pixel_aspect = asset->aspect_ratio / asset->width * asset->height; aratio_num = pixel_aspect * 1000000; aratio_den = 1000000; } else { aratio_num = 1000000; aratio_den = 1000000; } =====
strangely enough filedv seems to contain code to set is16x9 encoder flag ... not sure why it fails ....
mpeg video also should honor aspect ratio, but not tested yet.
mediainfo dv07_05_wide_cingg.dv | grep Display Display aspect ratio : 4:3
ffprobe -hide_banner dv07_05_wide_cingg.dv Input #0, dv, from 'dv07_05_wide_cingg.dv': Duration: 00:06:58.08, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 14.01.2024 17:43, skrev Terje J. Hanssen:
Den 13.01.2024 18:48, skrev Andrew Randrianasulu:
сб, 13 янв. 2024 г., 07:47 Andrew Randrianasulu <[email protected]>:
сб, 13 янв. 2024 г., 03:26 Terje J. Hanssen via Cin <[email protected]>:
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right?
Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ?
This is possible! I basically never used non-ffmpeg video encoders! I think we have 3 of them - raw dv, mpeg video and theora video.
I'll check each of them.
OOPS! As already mentioned, CinGG's FFmpeg-avi was saved/displayed 16:9 and the Raw DV was saved/displayed 4:3. BUT, in addition I discovered now that in both cases the images have been cropped around, that is cut off at both sides, top and bottom. That is, the 16:9 avi is displayed with correct geometry, while the 4:3 Raw DV is displayed stretched vertically. The latter get correct geometry if forced aspect 16:9 during VLC playback..
Actually, only my ffmpeg manual encoded DV-wide has got correct DAR 16:9 and also correct geometry.
And kept the full image (un-cropped).
A visual tip is that this is easiest to discover and compare side by side using large file thumbnails with (Gnome) Filemanager.
in cinelerra/fileogg.C I found this comment: =====
if( asset->aspect_ratio > 0 ) { // Cinelerra uses frame aspect ratio, theora uses pixel aspect ratio float pixel_aspect = asset->aspect_ratio / asset->width * asset->height; aratio_num = pixel_aspect * 1000000; aratio_den = 1000000; } else { aratio_num = 1000000; aratio_den = 1000000; } =====
strangely enough filedv seems to contain code to set is16x9 encoder flag ... not sure why it fails ....
mpeg video also should honor aspect ratio, but not tested yet.
mediainfo dv07_05_wide_cingg.dv | grep Display Display aspect ratio : 4:3
ffprobe -hide_banner dv07_05_wide_cingg.dv Input #0, dv, from 'dv07_05_wide_cingg.dv': Duration: 00:06:58.08, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
вс, 14 янв. 2024 г., 19:51 Terje J. Hanssen <[email protected]>:
Den 14.01.2024 17:43, skrev Terje J. Hanssen:
Den 13.01.2024 18:48, skrev Andrew Randrianasulu:
сб, 13 янв. 2024 г., 07:47 Andrew Randrianasulu <[email protected]>:
сб, 13 янв. 2024 г., 03:26 Terje J. Hanssen via Cin < [email protected]>:
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right?
Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ?
This is possible! I basically never used non-ffmpeg video encoders! I think we have 3 of them - raw dv, mpeg video and theora video.
I'll check each of them.
OOPS! As already mentioned, CinGG's FFmpeg-avi was saved/displayed 16:9 and the Raw DV was saved/displayed 4:3. BUT, in addition I discovered now that in both cases the images have been cropped around, that is cut off at both sides, top and bottom.
I wonder how much was cropped? May be I misread you but you loaded HDV 1440*1080 clip and then rendered it into ffmpeg DV at 576i WITHOUT any scaling on top? That is, the 16:9 avi is displayed with correct geometry, while the 4:3 Raw
DV is displayed stretched vertically. The latter get correct geometry if forced aspect 16:9 during VLC playback..
Actually, only my ffmpeg manual encoded DV-wide has got correct DAR 16:9 and also correct geometry.
And kept the full image (un-cropped).
A visual tip is that this is easiest to discover and compare side by side using large file thumbnails with (Gnome) Filemanager.
in cinelerra/fileogg.C I found this comment: =====
if( asset->aspect_ratio > 0 ) { // Cinelerra uses frame aspect ratio, theora uses pixel aspect ratio float pixel_aspect = asset->aspect_ratio / asset->width * asset->height;
aratio_num = pixel_aspect * 1000000;
aratio_den = 1000000; } else {
aratio_num = 1000000;
aratio_den = 1000000; } =====
strangely enough filedv seems to contain code to set is16x9 encoder flag ... not sure why it fails ....
mpeg video also should honor aspect ratio, but not tested yet.
mediainfo dv07_05_wide_cingg.dv | grep Display Display aspect ratio : 4:3
ffprobe -hide_banner dv07_05_wide_cingg.dv Input #0, dv, from 'dv07_05_wide_cingg.dv': Duration: 00:06:58.08, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
@Terje J. Hanssen Could you provide a few seconds of raw DV and HDV video? I can't find any for testing.
вс, 14 янв. 2024 г., 22:50 Andrea paz <[email protected]>:
@Terje J. Hanssen Could you provide a few seconds of raw DV and HDV video? I can't find any for testing.
http://samples.mplayerhq.hu/V-codecs/ there should be dv samples, both raw and in avi. for hdv I looked in archive.org collections.
A convenience when doing these tests is to apply the "Downsample" filter to the timeline track and set it, in H and W, to at least the value 40. This will immediately show whether the pixel shape is square or rectangular, and, in the latter case, whether it is stretched vertically or horizontally. There is also to mention the "Auto aspect ratio" option in Set Format. It always returns the pixel (PAR) to the square shape by changing the DAR. If you leave the Auto checked box, every time we make a change it is reset to the square pixel. Auto, however, turns off if you set one of the presets and you have to re-enable it manually. Crop or sometimes pad (letterbox) is unavoidable when we impose a different aspect ratio from the starting one. I'm running tests with Terje's sample (thanks!) and getting the same results as him. I honestly don't understand the difference in rendering between CinGG and ffmpeg. In Cingg the initial SAR (actually the PAR) goes from 4:3 (=1.333) to 64:45 (=1.422). However, 1,422 is the correct value (for CinGG), to see Raffaella Traniello's guide: http://www.g-raffa.eu/Cinelerra/HOWTO/anamorphic.html I still have to make a new build with Andrew's last 2 patches (for DV 16:9) to see if anything changes.
Den 15.01.2024 17:03, skrev Andrea paz:
A convenience when doing these tests is to apply the "Downsample" filter to the timeline track and set it, in H and W, to at least the value 40. This will immediately show whether the pixel shape is square or rectangular, and, in the latter case, whether it is stretched vertically or horizontally. There is also to mention the "Auto aspect ratio" option in Set Format. It always returns the pixel (PAR) to the square shape by changing the DAR. If you leave the Auto checked box, every time we make a change it is reset to the square pixel. Auto, however, turns off if you set one of the presets and you have to re-enable it manually. Crop or sometimes pad (letterbox) is unavoidable when we impose a different aspect ratio from the starting one. I'm running tests with Terje's sample (thanks!) and getting the same results as him.
I honestly don't understand the difference in rendering between CinGG and ffmpeg. In Cingg the initial SAR (actually the PAR) goes from 4:3 (=1.333) to 64:45 (=1.422). However, 1,422 is the correct value (for CinGG), to see Raffaella Traniello's guide: http://www.g-raffa.eu/Cinelerra/HOWTO/anamorphic.html
Anamorphic 16/9 SD-DV(D) DAR=16/9 When H=576 px, the width needs to be displayed horizontal (unsqeezed) with Wd=576x16/9=1024 px (square) But the width needs to be stored (compressed, squeezed) within SD-DV(D)'s format Ws=720 px SAR=Wd/Ws=(576x16/9)/720=64/45=1.4222 PAR=DAR/SAR=(16/9)/(64/45)=5/4=1.25 Conversion of anamorphic video into non-anamorphic video http://www.miraizon.com/support/info_aspectratio.html Pixel aspect ratios of common video formats https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm...
I still have to make a new build with Andrew's last 2 patches (for DV 16:9) to see if anything changes.
I would like to submit changes to the manual that relate to aspect ratio. The first two parts concern additions or changes to existing parts. The third part is completely new (to be put in the appendices?). This third part is barely mentioned and lacks revision and completion. @Terje, would you like to review and improve it? @All, everyone can contribute to improve these three parts because they are complicated but important. I attach the txt.
Andrea, I will have to study this but first glance looks good to me, but I know so little about it. I agree that the 3rd part would work well in the Appendix. Maybe Auxilliary Programs renamed to Auxiliary Information? On Mon, Jan 15, 2024 at 12:04 PM Andrea paz via Cin < [email protected]> wrote:
I would like to submit changes to the manual that relate to aspect ratio. The first two parts concern additions or changes to existing parts. The third part is completely new (to be put in the appendices?). This third part is barely mentioned and lacks revision and completion. @Terje, would you like to review and improve it? @All, everyone can contribute to improve these three parts because they are complicated but important. I attach the txt. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 15.01.2024 20:04, skrev Andrea paz:
I would like to submit changes to the manual that relate to aspect ratio. The first two parts concern additions or changes to existing parts. The third part is completely new (to be put in the appendices?). This third part is barely mentioned and lacks revision and completion. @Terje, would you like to review and improve it? @All, everyone can contribute to improve these three parts because they are complicated but important. I attach the txt.
@Andrea I have read through your text two times, besides related text in the current manual. To the pdf manual first, it seems to me that the following should be corrected(?) p 119 (776) The aspect ratio refers to the screen aspect ratio (SAR). should be(?) The aspect ratio refers to the Display aspect ratio (DAR). p 120 (776) Aspect ratio: sets the aspect ratio; this aspect ratio refers to the screen aspect ratio. should be(?) sets the aspect ratio; this aspect ratio refers to the display aspect ratio. To your new text I will just suggest to add/include a use case andr test example: * Down-convert/scale between two standard 16:9 anamorphic video formats: * HDV 1080i to DV 16:9
Den 14.01.2024 18:41, skrev Andrew Randrianasulu:
вс, 14 янв. 2024 г., 19:51 Terje J. Hanssen <[email protected]>:
Den 14.01.2024 17:43, skrev Terje J. Hanssen:
Den 13.01.2024 18:48, skrev Andrew Randrianasulu:
сб, 13 янв. 2024 г., 07:47 Andrew Randrianasulu <[email protected]>:
сб, 13 янв. 2024 г., 03:26 Terje J. Hanssen via Cin <[email protected]>:
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right?
Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ?
This is possible! I basically never used non-ffmpeg video encoders! I think we have 3 of them - raw dv, mpeg video and theora video.
I'll check each of them.
OOPS! As already mentioned, CinGG's FFmpeg-avi was saved/displayed 16:9 and the Raw DV was saved/displayed 4:3. BUT, in addition I discovered now that in both cases the images have been cropped around, that is cut off at both sides, top and bottom.
I wonder how much was cropped?
May be I misread you but you loaded HDV 1440*1080 clip and then rendered it into ffmpeg DV at 576i WITHOUT any scaling on top?
Yes, I loaded the anamorphic 16:9 HDV 1440x1080 clip and then rendered it using Set Format Preset PAL 576i (16:9)-DV(D) - without any scaling on top. According to my understanding this should down-convert the full source image to DVD 16:9 anamorphic format, which at playback should display upscaled 16:9 screen. That is, just as in my first post 4 b) FFmpeg transcode HDV to DV-wide ffmpeg -hide_banner -i hdv07_05.m2t -vf scale=720:576,setsar=64/45,setdar=16/9 -c:v dvvideo -c:a pcm_s16le dv07_05_wide.dv Gnome File properties and VLC Tools Codec info just say1440x1080 resolution for the HDV source and 720x576 for the CinGG rendered avi and dv output. I don't know if it possible to find out exactly, but Visually I espect and will estimate that the "middle part" 720x576 px symmetrical around the center of the source image is kept. That is cropped away * horizontally at each side: (1440-720)/2 = 360 px * vertically top and bottom: (1080-576)/2 = 252 px
That is, the 16:9 avi is displayed with correct geometry, while the 4:3 Raw DV is displayed stretched vertically. The latter get correct geometry if forced aspect 16:9 during VLC playback..
Actually, only my ffmpeg manual encoded DV-wide has got correct DAR 16:9 and also correct geometry.
And kept the full image (un-cropped).
A visual tip is that this is easiest to discover and compare side by side using large file thumbnails with (Gnome) Filemanager.
in cinelerra/fileogg.C I found this comment: =====
if( asset->aspect_ratio > 0 ) { // Cinelerra uses frame aspect ratio, theora uses pixel aspect ratio float pixel_aspect = asset->aspect_ratio / asset->width * asset->height; aratio_num = pixel_aspect * 1000000; aratio_den = 1000000; } else { aratio_num = 1000000; aratio_den = 1000000; } =====
strangely enough filedv seems to contain code to set is16x9 encoder flag ... not sure why it fails ....
mpeg video also should honor aspect ratio, but not tested yet.
mediainfo dv07_05_wide_cingg.dv | grep Display Display aspect ratio : 4:3
ffprobe -hide_banner dv07_05_wide_cingg.dv Input #0, dv, from 'dv07_05_wide_cingg.dv': Duration: 00:06:58.08, start: 0.000000, bitrate: 28800 kb/s Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 13.01.2024 05:47, skrev Andrew Randrianasulu:
сб, 13 янв. 2024 г., 03:26 Terje J. Hanssen via Cin <[email protected]>:
Den 11.01.2024 23:43, skrev Terje J. Hanssen:
.......
4 a) Cin-GG Loaded a PAL 1080i/50 HDV clip Set Format Preset: PAL 576i (16:9) - DV(D) File Render File Format: FFmepg - avi (NB! because plain Raw DV still causes DAR 4:3) Audio: Preset: avi_pcm_s16.avi Video: Compression: dv_pal.avi
For me it looks like the Set Format Preset: PAL 576i (16:9) - DV(D and/or the File Format: FFmpeg make up the correct DAR 16:9 here, right?
Because by Selecting the Format: *Raw DV *cause rendering to *DAR 4:3* as shown below ! This makes me wonder if it is only the FFmepg File formats that currently is fixed by patches? May also other non-FFmpeg formats be affected by anamorphic aspect ratios ?
This is possible! I basically never used non-ffmpeg video encoders! I think we have 3 of them - raw dv, mpeg video and theora video.
I'll check each of them.
What about DVD Render (16:9) and BD Render from HDV source? Are they for example quite independent of the Set Format Preset?
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith -
Terje J. Hanssen