Re: [Cin] HDV formats patch
Den 12.11.2020 13:57, skrev Andrew Randrianasulu: For cinelerra/defaultformats.h I de-capitalized "I" in presets, but I'm not sure about overall aesthetics of "P" vs "p" or how I added "(HDV)" to some presets (because I think those 720p presets can be used outside of HDV material?) Terje, can you try to pull cinGG sources from git, apply my patch (git apply PATCH from source tree) and build with "--with-single-user", so there will be no danger to your Cin isntallation and see if patch actually gives workable settings for your real footage? Here I reach my limit : Though I've worked with civil engineering, I'm not familiar with building, compiling and patching computer software :) Actually, almost five years ago, GG guided me step by step by email to compile my first Cin5.0 on openSUSE 42.1. Since then I've just installed pre-build rpm packages, included the current Cin-GG 5.1 on Leap 15.2. So to do it now, I will need the detailed command procedure, step by step again ;) From dialogs it seems Aspect Ratio at the bottom of format window IS Screen/Display aspect ration, and W/H ratio is about non-square pixels. But I wonder how it supposed to work for rendering back into HDV? If your pipeline set to 1440x1080, and you encode just with special flag set - all movements and graphics and text and masked effects you added must be somewhat scaled horizontally up and down? (because if Compositor shows 1920x1080 image, and you draw nice square with Sketcher there - how those pixels will be drawn on top of project size sized frame? Or you must have special overlay track set to 1920x1080 where you draw, and then just let Cin mix two?) NOTE: I don't think this will adds autodetect-on-load but at least having correct profiles somewhere might be 0.2 step in this direction. However, via a previous mail thread with url to a small hdv video clip, this file can be downloaded and tested: CinCV TNG] Setting up a Project https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q4/005613.html http://mvd.homevideo.free.fr/films_HDV/20081103140154.m2t mediainfo provides a longer detailed list, but here is a short list using ffprobe 20081103140154.m2t . Input #0, mpegts, from '20081103140154.m2t': Duration: 00:00:13.44, start: 1042.40, bitrate: 26598 kb/s Program 100 Stream #0:0[0x810]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, top first), 1440x1080 [SAR 4:3 DAR 16:9], 25000 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:1[0x814]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 384 kb/s I loaded this hdv file 20081103140154.m2t in my current Cin-GG, and noticed the Set Format window with Canvas size=1440x1080, W.Ratio=1, H.Ratio=1, Aspect Ratio= 4:3, Interlace mode=Bottom field first Attached screen shot below The video image aspect ratio seems be 4:3 in the compositor and player windows. Shouldn't Cin-GG with "FFmpeg First" button enabled, detect and set the same parameters like ffprobe detect above? In the past, Cin-CV did not auto-detect aspect ratio, and only applied Format aspect ratio on the output, not on the individual input files. https://cinelerra.skolelinux.narkive.com/kkJef8tW/cincvs-compositor-stretching-16-9 = Terje J. H -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] actually, added few more formats to theme.C
Den 12.11.2020 22:04, skrev Andrew Randrianasulu via Cin: В сообщении от Thursday 12 November 2020 21:41:47 Terje J. Hanssen via Cin написал(а): skip In case you have not seen it, the replies to my related mail request on the old CinCVS mail list might have some more information: https://www.mail-archive.com/cinelerra@skolelinux.no/msg05573.html Yes, I see https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05582.html this one not very encouraging: == Note that Cinelerra does two tasks: render and display. To render, Cinelerra treats the 1440:1080 as square pixels. This is not optimal if something you render has both horizontal and vertical extent, but is driven by only one parameter, like the radius of the radial grandient, a radial blur, or the 'feather' radius of the masks. Such things will turn into ellipses because: To display, Cinelerra simply stretches the available pixels to 16:9 ratio. -- Hannes = this question of you was left w/o answer, at least it was off-thread. https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05586.html == For captured HDV and SD DV footages it looks like Cinelerra automatically takes care of scaling. What doesn't look quite clear for me yet, is what has to be done in Cinelerra for in cam downconverted HDV to anamorphic DV? === I'll use search and try to read code a bit more. I think I found manual on how to mix DV and HDV in same project in Cinelerra, but it was involving manual scaling? http://www.g-raffa.eu/Cinelerra/HOWTO/anamorphic.html#_how_to_add_16_9_anamorphic_footage_to_your_standard_4_3_project ah, no, it has no specific mention of HDV in this section, but our problem is indeed those non-square pixels, and how to paint over them I found another, related mail thread (2016): [CinCV TNG] Create 16x9 video from 4x3 sources https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q2/004927.html Thanks, according to this thread same DVD disk may look different on different players/TV/monitors ... My friend said some of those display devices may have their own fine controls for scaling (on-screen menu?). But I only have this monitor (1440x900 it says IPS LED LG on front and "Manufacturer: GSM Model: 5b01 Serial#: 5886" in X.log) as my viewing device (I have older CRT monitors, Samsung SyncMaster 550b, but for now I prefer not to unplug vga cable too much - it sometimes loose red and blue signals, so I prefer not to strain it more) Ok I happend to search yet a couple of related mail topics from the past CinCVS, and complement them here as references: [CinCVS] 16:9 from 4:3 ?? https://cinelerra.skolelinux.narkive.com/modLKoWa/cincvs-16-9-from-4-3 [CinCVS] Compositor stretching 16:9 https://cinelerra.skolelinux.narkive.com/kkJef8tW/cincvs-compositor-stretching-16-9 Terje J. H Terje J. H [skip] -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] UPD: Re: DNxHR presets
В сообщении от Thursday 12 November 2020 23:53:40 MatN via Cin написал(а): > On Thu, 12 Nov 2020 21:41:20 +0100 (CET), MatN via Cin wrote: > > >On Wed, 11 Nov 2020 23:47:17 +0100, Andrea paz via Cin wrote: > > > >>I think you need to copy Andrew's presets to ".../bin/ffmpeg/video" > >>after compilation. At least that's what I do. If you want to do it > >>before compiling then you have to copy the presets to > >>".../ffmpeg/video", which is in the main directory, without entering > >>"/bin". But I don't understand the code at all, sorry. > >>In this way DNxHR.mov. are also displayed. To me only the 420 appears > >>without other options. Since the 420 is not supported by DNxHR then > >>the render fails. For Andrew it works fine. > > > >@Andrea, > > > >Ok, got it. The .mov files need to be in the cinelerra5.1/ffmpeg/video > >directory, and the "make install" copies that ffmpeg directory to the bin > >directory (a "make clean" removes that and some other subdirectories of bin). > > > >Now if in the render window I choose file format ffmpeg.mov, then open the > >video options, I get the 7 extra options DnxHR options in the 'compression" > >dropdown. I presume you get this far too? > >Then if I select e.g. DNxHR_HQ, the Pixels dropdown has extra entries like > >yuv422p . Do you get this? > > I can render a file with DNxHR_HQ pixel yuv422p fine, but it expands > enormously. The source Jellyfish .MP4 file was 35 MB, the .mov file 787 Mb. > VLC's codec info on that file shows indeed dnxhr yuv422p . > > So what is the advantage of these DNxHR formats? According to this: https://www.mainconcept.com/fileadmin/user_upload/datasheets/DNxHD-DNxHR_SDK_DATASHEET.pdf The MainConcept VC-3 SDK Packages for Avid DNxHD and Avid DNxHR are software-only solutions which enable application developers to integrate with production tools like Avid Media Composer and Avid Interplay storage solutions or cameras which store media in either of these formats. Avid DNxHD and DNxHR are based on the SMPTE 2019-2006 (VC-3) specification. - so, basically standard codec for exchange with Big Boys (AVID, etc) Better to be put on fast storage. Try to play it back/forward, framestep, fastforward, and randomly hit various places on relatively long timeline, notice if there any difference in responsiveness with h264. > > MatN > > > > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] UPD: Re: DNxHR presets
The advantage of using mezzanine codecs (also called Intermediate codecs) is that it preserves all the information in the original file throughout the editing process. In addition, they are uncompressed codecs and therefore not stressful for the CPU. They are indispensable for high level works of Color Correction; denoise; mask and Chroma Key, where the compression artifacts do not allow good results. For only editing they are not necessary, and in fact proxies are often used. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] UPD: Re: DNxHR presets
No, I only have yuv420 available (which you shouldn't even have). So it's my problem, since it works normally for you and Andrew. @Andrew You can propose to integrate your presets for the next release. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] actually, added few more formats to theme.C
В сообщении от Thursday 12 November 2020 21:41:47 Terje J. Hanssen via Cin написал(а): > > Den 12.11.2020 12:00, skrev Andrew Randrianasulu via Cin: > > В сообщении от Thursday 12 November 2020 04:00:14 Terje J. Hanssen via Cin > > написал(а): > >> Firstly, I'm not a programmer, but as I'm retired and hope to spend some > >> time forward to learn Cin-GG to edit my hobby recorded and archived SD > >> and HDV. > >> > >> In general, the most user friendly would be if the automatic selected > >> Preset format fits correctly to each loaded standard video w/audio file > >> format. For unknown formats, PAL vs NTSC should preferably be choosed > >> based on the actual time zone (CGG manual page 416, above Figure 13.1). > >> > >> *) User custom verification and selection of presets or video technical > >> details, assume the user is skilled on the video format in use. > >> > >> > >> Den 11.11.2020 18:54, skrev Andrew Randrianasulu via Cin: > >>> В сообщении от Wednesday 11 November 2020 20:12:44 Terje J. Hanssen via > >>> Cin написал(а): > I will just add that the HDV format consist of three versions: > https://en.wikipedia.org/wiki/HDV#Specifications > > HDV 720p > 720p/60, 720p/30, 720p/24, 720p/50, 720p/25 > >>> but may be those can be already selected, just not as preset with HDV in > >>> name? > >> 720p/60 is the only 720p preset available. > >> *) Each details can be custom selected, although not ideally? > > Yes, I was reluctant to add ALL variations because they will make list > > longer. > > But I can do this. > > A sub-menu next for each of the three HDV groups seems to be even > better, though more complicated(?) For me, I don't know how to make sub-menus yet :D > > >> According to the Wikipedia HDV specifications: > >> 720p: Pixel aspect ratio 1.00 (PAR), Frame size in pixels 1280x720, > >> Frame aspect ratio 16:9 (DAR), MPEG2 Video compr. (profile & level: > >> MP@H-14/HL) > >> 1080i: Pixel aspect ratio 1.33 (PAR), Frame size in pixels 1440x1080, > >> Frame aspect ratio 16:9 (DAR), MPEG2 Video compr. (profile & level: > >> MP@H-14) > >> > >> From the Cin Preset Canvas size I noticed the following proportions can > >> be derived, in case they tell something . > >> 720p: W Ratio/H Ratio=0.8889/0.6667=1.33, Width/W > >> Ratio=1280/0.8889=1440, Height/H Ratio=720/0.6667=1080 > >> 1080i: W Ratio/H Ratio=1./1.=1.33, Width/W > >> Ratio=1920/1.=1440, Height/H Ratio=1080/1.000=1080 > >> > >> > HDV 1080i > 1080i/30 (29.97), 1080i/25 > > HDV 1080p > 1080p/30 (29.97), 1080p/24 (23.98), 1080p/25 > >>> Those seems to be more tricky, because I still not sure how they should > >>> show up in Compositor and Viewer. With correct-for-display aspect ratio? > >>> But then how masks/titles will work? > > I'm not sure about all other HD-video formats, but the HDV formats seems > to be supported HDTV formats (broadcast standards) and supported Blu-ray > video formats > 1280x720 (HD-1) HD ready or Standard HD > 1440x1080 (HD-2) and 1920x1080, (Full HD, FHD) > > https://en.wikipedia.org/wiki/High-definition_television#Display_resolutions > https://en.wikipedia.org/wiki/List_of_common_resolutions#Digital_TV_standards > https://en.wikipedia.org/wiki/High-definition_video#Common_high-definition_video_modes > https://en.wikipedia.org/wiki/Blu-ray#Video > > >> In case you have not seen it, the replies to my related mail request on > >> the old CinCVS mail list might have some more information: > >> https://www.mail-archive.com/cinelerra@skolelinux.no/msg05573.html > > Yes, I see > > > > https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05582.html > > > > this one not very encouraging: > > > > == > > Note that Cinelerra does two tasks: render and display. > > > > To render, Cinelerra treats the 1440:1080 as square pixels. This is not > > optimal if something you render has both horizontal and vertical extent, but > > is driven by only one parameter, like the radius of the radial grandient, a > > radial blur, or the 'feather' radius of the masks. Such things will turn > > into > > ellipses because: > > > > To display, Cinelerra simply stretches the available pixels to 16:9 ratio. > > > > -- Hannes > > = > > > > this question of you was left w/o answer, at least it was off-thread. > > https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05586.html > > > > == > > For captured HDV and SD DV footages it looks like Cinelerra automatically > > takes care of scaling. What doesn't look quite clear for me yet, is what > > has to be done in Cinelerra for in cam downconverted HDV to anamorphic DV? > > === > > > > > > I'll use search and try to read code a bit more. > > > > I think I found manual on how to mix DV and HDV in same project in > > Cinelerra, but it was involving manual scaling? > > > >
Re: [Cin] UPD: Re: DNxHR presets
On Thu, 12 Nov 2020 21:41:20 +0100 (CET), MatN via Cin wrote: >On Wed, 11 Nov 2020 23:47:17 +0100, Andrea paz via Cin wrote: > >>I think you need to copy Andrew's presets to ".../bin/ffmpeg/video" >>after compilation. At least that's what I do. If you want to do it >>before compiling then you have to copy the presets to >>".../ffmpeg/video", which is in the main directory, without entering >>"/bin". But I don't understand the code at all, sorry. >>In this way DNxHR.mov. are also displayed. To me only the 420 appears >>without other options. Since the 420 is not supported by DNxHR then >>the render fails. For Andrew it works fine. > >@Andrea, > >Ok, got it. The .mov files need to be in the cinelerra5.1/ffmpeg/video >directory, and the "make install" copies that ffmpeg directory to the bin >directory (a "make clean" removes that and some other subdirectories of bin). > >Now if in the render window I choose file format ffmpeg.mov, then open the >video options, I get the 7 extra options DnxHR options in the 'compression" >dropdown. I presume you get this far too? >Then if I select e.g. DNxHR_HQ, the Pixels dropdown has extra entries like >yuv422p . Do you get this? I can render a file with DNxHR_HQ pixel yuv422p fine, but it expands enormously. The source Jellyfish .MP4 file was 35 MB, the .mov file 787 Mb. VLC's codec info on that file shows indeed dnxhr yuv422p . So what is the advantage of these DNxHR formats? MatN -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] UPD: Re: DNxHR presets
On Wed, 11 Nov 2020 23:47:17 +0100, Andrea paz via Cin wrote: >I think you need to copy Andrew's presets to ".../bin/ffmpeg/video" >after compilation. At least that's what I do. If you want to do it >before compiling then you have to copy the presets to >".../ffmpeg/video", which is in the main directory, without entering >"/bin". But I don't understand the code at all, sorry. >In this way DNxHR.mov. are also displayed. To me only the 420 appears >without other options. Since the 420 is not supported by DNxHR then >the render fails. For Andrew it works fine. @Andrea, Ok, got it. The .mov files need to be in the cinelerra5.1/ffmpeg/video directory, and the "make install" copies that ffmpeg directory to the bin directory (a "make clean" removes that and some other subdirectories of bin). Now if in the render window I choose file format ffmpeg.mov, then open the video options, I get the 7 extra options DnxHR options in the 'compression" dropdown. I presume you get this far too? Then if I select e.g. DNxHR_HQ, the Pixels dropdown has extra entries like yuv422p . Do you get this? MatN -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] actually, added few more formats to theme.C
Den 12.11.2020 12:00, skrev Andrew Randrianasulu via Cin: В сообщении от Thursday 12 November 2020 04:00:14 Terje J. Hanssen via Cin написал(а): Firstly, I'm not a programmer, but as I'm retired and hope to spend some time forward to learn Cin-GG to edit my hobby recorded and archived SD and HDV. In general, the most user friendly would be if the automatic selected Preset format fits correctly to each loaded standard video w/audio file format. For unknown formats, PAL vs NTSC should preferably be choosed based on the actual time zone (CGG manual page 416, above Figure 13.1). *) User custom verification and selection of presets or video technical details, assume the user is skilled on the video format in use. Den 11.11.2020 18:54, skrev Andrew Randrianasulu via Cin: В сообщении от Wednesday 11 November 2020 20:12:44 Terje J. Hanssen via Cin написал(а): I will just add that the HDV format consist of three versions: https://en.wikipedia.org/wiki/HDV#Specifications HDV 720p 720p/60, 720p/30, 720p/24, 720p/50, 720p/25 but may be those can be already selected, just not as preset with HDV in name? 720p/60 is the only 720p preset available. *) Each details can be custom selected, although not ideally? Yes, I was reluctant to add ALL variations because they will make list longer. But I can do this. A sub-menu next for each of the three HDV groups seems to be even better, though more complicated(?) According to the Wikipedia HDV specifications: 720p: Pixel aspect ratio 1.00 (PAR), Frame size in pixels 1280x720, Frame aspect ratio 16:9 (DAR), MPEG2 Video compr. (profile & level: MP@H-14/HL) 1080i: Pixel aspect ratio 1.33 (PAR), Frame size in pixels 1440x1080, Frame aspect ratio 16:9 (DAR), MPEG2 Video compr. (profile & level: MP@H-14) From the Cin Preset Canvas size I noticed the following proportions can be derived, in case they tell something . 720p: W Ratio/H Ratio=0.8889/0.6667=1.33, Width/W Ratio=1280/0.8889=1440, Height/H Ratio=720/0.6667=1080 1080i: W Ratio/H Ratio=1./1.=1.33, Width/W Ratio=1920/1.=1440, Height/H Ratio=1080/1.000=1080 HDV 1080i 1080i/30 (29.97), 1080i/25 HDV 1080p 1080p/30 (29.97), 1080p/24 (23.98), 1080p/25 Those seems to be more tricky, because I still not sure how they should show up in Compositor and Viewer. With correct-for-display aspect ratio? But then how masks/titles will work? I'm not sure about all other HD-video formats, but the HDV formats seems to be supported HDTV formats (broadcast standards) and supported Blu-ray video formats 1280x720 (HD-1) HD ready or Standard HD 1440x1080 (HD-2) and 1920x1080, (Full HD, FHD) https://en.wikipedia.org/wiki/High-definition_television#Display_resolutions https://en.wikipedia.org/wiki/List_of_common_resolutions#Digital_TV_standards https://en.wikipedia.org/wiki/High-definition_video#Common_high-definition_video_modes https://en.wikipedia.org/wiki/Blu-ray#Video In case you have not seen it, the replies to my related mail request on the old CinCVS mail list might have some more information: https://www.mail-archive.com/cinelerra@skolelinux.no/msg05573.html Yes, I see https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05582.html this one not very encouraging: == Note that Cinelerra does two tasks: render and display. To render, Cinelerra treats the 1440:1080 as square pixels. This is not optimal if something you render has both horizontal and vertical extent, but is driven by only one parameter, like the radius of the radial grandient, a radial blur, or the 'feather' radius of the masks. Such things will turn into ellipses because: To display, Cinelerra simply stretches the available pixels to 16:9 ratio. -- Hannes = this question of you was left w/o answer, at least it was off-thread. https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05586.html == For captured HDV and SD DV footages it looks like Cinelerra automatically takes care of scaling. What doesn't look quite clear for me yet, is what has to be done in Cinelerra for in cam downconverted HDV to anamorphic DV? === I'll use search and try to read code a bit more. I think I found manual on how to mix DV and HDV in same project in Cinelerra, but it was involving manual scaling? http://www.g-raffa.eu/Cinelerra/HOWTO/anamorphic.html#_how_to_add_16_9_anamorphic_footage_to_your_standard_4_3_project ah, no, it has no specific mention of HDV in this section, but our problem is indeed those non-square pixels, and how to paint over them I found another, related mail thread (2016): [CinCV TNG] Create 16x9 video from 4x3 sources https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q2/004927.html Terje J. H This CinCVS Mail Archive is also searchable and contains several threads about that time new HDV format https://www.mail-archive.com/cinelerra@skolelinux.no/ Terje J. H At the same time I will also suggest to consistently use lower case "i" for all
[Cin] HDV formats patch
For cinelerra/defaultformats.h
I de-capitalized "I" in presets, but I'm not sure about overall aesthetics of
"P" vs "p" or how I added "(HDV)" to some presets (because I think those 720p
presets can be used outside of HDV material?)
Terje, can you try to pull cinGG sources from git, apply my patch
(git apply PATCH from source tree) and build with "--with-single-user", so
there will be no danger to your Cin isntallation and see if patch actually
gives workable settings for your real footage?
From dialogs it seems Aspect Ratio at the bottom of format window IS
Screen/Display aspect ration, and W/H ratio is about non-square pixels.
But I wonder how it supposed to work for rendering back into HDV?
If your pipeline set to 1440x1080, and you encode just with special flag set -
all movements and graphics and text and masked effects you added must be
somewhat scaled horizontally up and down? (because if Compositor shows
1920x1080 image, and you draw nice square with Sketcher there - how those
pixels will be drawn on top of project size sized frame? Or you must have
special overlay track set to 1920x1080 where you draw, and then just let Cin
mix two?)
NOTE: I don't think this will adds autodetect-on-load but at least having
correct profiles somewhere might be 0.2 step in this direction.
diff --git a/cinelerra-5.1/cinelerra/defaultformats.h b/cinelerra-5.1/cinelerra/defaultformats.h
index 61bd2165..9de780b2 100644
--- a/cinelerra-5.1/cinelerra/defaultformats.h
+++ b/cinelerra-5.1/cinelerra/defaultformats.h
@@ -39,19 +39,39 @@ struct formatpresets
};
static struct formatpresets format_presets[] = {
- { N_("1080P/60"), 2, 2, 48000, 1, 1, 6.0 / 1001,
+ { N_("1080P/60"), 2, 2, 48000, 1, 1, 60,
+ 1920,1080, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("1080P/59.94"), 2, 2, 48000, 1, 1, 6.0 / 1001,
+ 1920,1080, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("1080P/30"), 6, 6, 48000, 1, 1, 30,
+ 1920,1080, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("1080P/29.97"), 6, 6, 48000, 1, 1, 3.0 / 1001,
1920,1080, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
{ N_("1080P/24"), 6, 6, 48000, 1, 1, 24,
1920,1080, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
- { N_("1080I"), 2, 2, 48000, 1, 1, 3.0 / 1001,
+ { N_("1080P/23.976"), 6, 6, 48000, 1, 1, 24000.0 / 1001,
+ 1920,1080, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("1080i/29.97"), 2, 2, 48000, 1, 1, 3.0 / 1001,
1920,1080, 16,9, ILACE_MODE_BOTTOM_FIRST, BC_YUVA },
- { N_("720P/60"), 2, 2, 48000, 1, 1, 6.0 / 1001,
+ { N_("HDV 1080i/29.97"), 2, 2, 48000, 1, 1, 3.0 / 1001,
+ 1440,1080, 16,9, ILACE_MODE_TOP_FIRST, BC_YUVA },
+ { N_("HDV 1080i/25"), 2, 2, 48000, 1, 1, 25,
+ 1440,1080, 16,9, ILACE_MODE_TOP_FIRST, BC_YUVA },
+ { N_("(HDV) 720P/60"), 2, 2, 48000, 1, 1, 6.0 / 1001,
+ 1280,720, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("(HDV) 720P/50"), 2, 2, 48000, 1, 1, 50,
+ 1280,720, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("(HDV) 720P/29.97"), 2, 2, 48000, 1, 1, 3.0 / 1001,
+ 1280,720, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("(HDV) 720P/25"), 2, 2, 48000, 1, 1, 25,
+ 1280,720, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
+ { N_("(HDV) 720P/23.976"), 2, 2, 48000, 1, 1, 24000.0 / 1001,
1280,720, 16,9, ILACE_MODE_NOTINTERLACED, BC_YUVA },
- { N_("PAL 576I - DV(D)"), 2, 2, 48000, 1, 1, 25,
+ { N_("PAL 576i - DV(D)"), 2, 2, 48000, 1, 1, 25,
720,576, 4,3, ILACE_MODE_BOTTOM_FIRST, BC_YUVA },
{ N_("NTSC 480P - DV(D)"), 2, 2, 48000, 1, 1, 6.0 / 1001,
720,480, 4,3, ILACE_MODE_NOTINTERLACED, BC_YUVA },
- { N_("NTSC 480I - DV(D)"), 2, 2, 48000, 1, 1, 3.0 / 1001,
+ { N_("NTSC 480i - DV(D)"), 2, 2, 48000, 1, 1, 3.0 / 1001,
720,480, 4,3, ILACE_MODE_BOTTOM_FIRST, BC_YUVA },
{ N_("YouTube"), 1, 1, 48000, 1, 1, 3.0 / 1001,
424,318, 4,3, ILACE_MODE_NOTINTERLACED, BC_YUVA },
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
[Cin] Parch preventing compilation failure in thirdparty/x264
I was recompiling CinGG fot testing "--with-single-user" and found it will fail in x264 directory without some of my old reverts, performed by slackbuild. I have old (2.8) ffmpeg installed system-wide, and x264's configure script was not disabling this integration correctly (even if code was unconditionally adapted to new ffmpeg), so compilation fail. I just added one more parameter in x264 line of thirdparty/Makefile diff --git a/cinelerra-5.1/thirdparty/Makefile b/cinelerra-5.1/thirdparty/Makefile index 27f13c65..880d3128 100644 --- a/cinelerra-5.1/thirdparty/Makefile +++ b/cinelerra-5.1/thirdparty/Makefile @@ -249,7 +249,7 @@ tiff.cfg_params+= --enable-shared=no --disable-zstd $(call if_pkg,libwebp,\ --with-webp-lib-dir=$(call pkg_libs,libwebp))\ $(call if_npkg,libwebp,--disable-webp) twolame.cfg_params?=--enable-shared=no -x264.cfg_params?= --enable-static --enable-pic +x264.cfg_params?= --disable-swscale --enable-static --enable-pic x265.cfg_vars?=$(call cmake_config,source) x265.cfg_params?= -DENABLE_SHARED=no libvpx.cfg_params?= --enable-pic --disable-avx512 shold be applicable cleanly to latest git (commit 3325029f915f54fe7e14d7b2cb1d4b8f4dd8a640 ) I don't think many use such outdated ffmpeg, but this line should not hurt (because x264 in our case just feed via libavcodec API, and scaling can be done early) I rendered small fragment with non-default pixel format, and it appear to work: mediainfo /dev/shm/test.mp4 General Complete name: /dev/shm/test.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/avc1/mp41) File size: 1.16 MiB Duration : 15 s 382 ms Overall bit rate : 633 kb/s Writing application : Lavf58.45.100 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:4:4 Predictive@L3 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames: 4 frames Codec ID : avc1 Codec ID/Info: Advanced Video Coding Duration : 15 s 360 ms Bit rate : 499 kb/s Width: 720 pixels Height : 576 pixels Display aspect ratio : 4:3 Frame rate mode : Constant Frame rate : 25.000 FPS Standard : PAL Color space : YUV Chroma subsampling : 4:4:4 Bit depth: 8 bits Scan type: Progressive Bits/(Pixel*Frame) : 0.048 Stream size : 936 KiB (79%) Writing library : x264 core 157 Encoding settings: cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=4 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=25 / keyint_min=13 / scenecut=40 / intra_refresh=0 / rc_lookahead=25 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 Color range : Limited Matrix coefficients : BT.601 Codec configuration box : avcC Audio ID : 2 Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Duration : 15 s 382 ms Bit rate mode: Constant Bit rate : 128 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate: 48.0 kHz Frame rate : 46.875 FPS (1024 SPF) Compression mode : Lossy Stream size : 240 KiB (20%) Language : Russian Default : Yes Alternate group : 1 mplayer also showing video and saying among other things: [swscaler @ 0x57740034]bicubic
Re: [Cin] actually, added few more formats to theme.C
В сообщении от Thursday 12 November 2020 04:00:14 Terje J. Hanssen via Cin написал(а): > Firstly, I'm not a programmer, but as I'm retired and hope to spend some > time forward to learn Cin-GG to edit my hobby recorded and archived SD > and HDV. > > In general, the most user friendly would be if the automatic selected > Preset format fits correctly to each loaded standard video w/audio file > format. For unknown formats, PAL vs NTSC should preferably be choosed > based on the actual time zone (CGG manual page 416, above Figure 13.1). > > *) User custom verification and selection of presets or video technical > details, assume the user is skilled on the video format in use. > > > Den 11.11.2020 18:54, skrev Andrew Randrianasulu via Cin: > > В сообщении от Wednesday 11 November 2020 20:12:44 Terje J. Hanssen via Cin > > написал(а): > >> I will just add that the HDV format consist of three versions: > >> https://en.wikipedia.org/wiki/HDV#Specifications > >> > >> HDV 720p > >> 720p/60, 720p/30, 720p/24, 720p/50, 720p/25 > > but may be those can be already selected, just not as preset with HDV in > > name? > > 720p/60 is the only 720p preset available. > *) Each details can be custom selected, although not ideally? Yes, I was reluctant to add ALL variations because they will make list longer. But I can do this. > > According to the Wikipedia HDV specifications: > 720p: Pixel aspect ratio 1.00 (PAR), Frame size in pixels 1280x720, > Frame aspect ratio 16:9 (DAR), MPEG2 Video compr. (profile & level: > MP@H-14/HL) > 1080i: Pixel aspect ratio 1.33 (PAR), Frame size in pixels 1440x1080, > Frame aspect ratio 16:9 (DAR), MPEG2 Video compr. (profile & level: > MP@H-14) > > From the Cin Preset Canvas size I noticed the following proportions can > be derived, in case they tell something . > 720p: W Ratio/H Ratio=0.8889/0.6667=1.33, Width/W > Ratio=1280/0.8889=1440, Height/H Ratio=720/0.6667=1080 > 1080i: W Ratio/H Ratio=1./1.=1.33, Width/W > Ratio=1920/1.=1440, Height/H Ratio=1080/1.000=1080 > > > >> HDV 1080i > >> 1080i/30 (29.97), 1080i/25 > >> > >> HDV 1080p > >> 1080p/30 (29.97), 1080p/24 (23.98), 1080p/25 > > Those seems to be more tricky, because I still not sure how they should > > show up in Compositor and Viewer. With correct-for-display aspect ratio? > > But then how masks/titles will work? > > In case you have not seen it, the replies to my related mail request on > the old CinCVS mail list might have some more information: > https://www.mail-archive.com/cinelerra@skolelinux.no/msg05573.html Yes, I see https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05582.html this one not very encouraging: == Note that Cinelerra does two tasks: render and display. To render, Cinelerra treats the 1440:1080 as square pixels. This is not optimal if something you render has both horizontal and vertical extent, but is driven by only one parameter, like the radius of the radial grandient, a radial blur, or the 'feather' radius of the masks. Such things will turn into ellipses because: To display, Cinelerra simply stretches the available pixels to 16:9 ratio. -- Hannes = this question of you was left w/o answer, at least it was off-thread. https://www.mail-archive.com/cinelerra%40skolelinux.no/msg05586.html == For captured HDV and SD DV footages it looks like Cinelerra automatically takes care of scaling. What doesn't look quite clear for me yet, is what has to be done in Cinelerra for in cam downconverted HDV to anamorphic DV? === I'll use search and try to read code a bit more. I think I found manual on how to mix DV and HDV in same project in Cinelerra, but it was involving manual scaling? http://www.g-raffa.eu/Cinelerra/HOWTO/anamorphic.html#_how_to_add_16_9_anamorphic_footage_to_your_standard_4_3_project ah, no, it has no specific mention of HDV in this section, but our problem is indeed those non-square pixels, and how to paint over them > > This CinCVS Mail Archive is also searchable and contains several threads > about that time new HDV format > https://www.mail-archive.com/cinelerra@skolelinux.no/ > > > Terje J. H > > > > > > >> At the same time I will also suggest to consistently use lower case "i" > >> for all interlaced HDV and HD formats like that on the SD formats. > >> Attached screen shots from the Set_Format_Preset menue. > > ok > >> Terje J. H > >> > >> > >> > >> > >> Den 01.11.2020 19:35, skrev Pierre autourduglobe via Cin: > >>> Yes it's clear > >>> HDV 1080i "Top field first" > >>> and DV "Bottom field first" > >>> > >>> In my case I can verify this with my old HDV camera HVR-Z1U, which can > >>> record and transfer either in HDV or DV (ntsc). > >>> > >>> Here is what mediainfo says about the material shot: > >>> > >>> > >>> An example of HDV material > >>> > >>> General > >>> ID : 255 (0xFF) > >>> Complete name
