[Cin] Cin Digest, Vol 3, Issue 5

Thu Jan 3 15:44:15 CET 2019

https://www.youtube.com/watch?v=kXdCBwWy2TY
Reframe Rt I had already as a topic

Am Mi., 2. Jan. 2019 um 21:51 Uhr schrieb <
cin-request at lists.cinelerra-gg.org>:

> Send Cin mailing list submissions to
>         cin at lists.cinelerra-gg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.cinelerra-gg.org/mailman/listinfo/cin
> or, via email, send a message with subject or body 'help' to
>         cin-request at lists.cinelerra-gg.org
>
> You can reach the person managing the list at
>         cin-owner at lists.cinelerra-gg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cin digest..."
>
>
> Today's Topics:
>
>    1. Re: Cinx - 10-bit h264 and/or h265 (Terje J Hanssen)
>    2. Re: Ungrouping of video and audio clips after some edits (Xing Tu)
>    3. ReframeRT, Interpolate Video (Andrea paz)
>    4. Re: ReframeRT, Interpolate Video (Xing Tu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Jan 2019 19:46:55 +0000
> From: Terje J Hanssen <terje at nordland-teknikk.no>
> To: "cin at lists.cinelerra-gg.org" <cin at lists.cinelerra-gg.org>
> Subject: Re: [Cin] Cinx - 10-bit h264 and/or h265
> Message-ID: <ebc8550e-c8db-75c2-6ee9-96c5b5539eb4 at nordland-teknikk.no>
> Content-Type: text/plain; charset="utf-8"
>
> Is Cinelerra10bit (Cinx) based on 10-bit x264 or 10-bit x265?
> It is based on x265 BUT there is a enable flag in the build scripts for
> anyone doing there own build to use x264 instead.
>
> Thank you for clarifying and confirming that, which was what I initially
> thought.
>
> The confusion and uncorrected manual resulted in falsely believing that
> the maintainers of x264 included the possibility of having both 8/10 bit
> working without having to make a special compile.  We were fooled for a
> month or so and I had updated the manual and did not correct it
>
> Yes, I remember that (refer your previous mail 07.06.2018).
>
> But as Cinelerra (Cin) then is based on x264, I wonder if the following
> reference below is something that has been incorporated later in x264 and
> possibly yet change that "Cin" has the opportunity to work with both 8-bit
> and 10-bit x264?
>
> x264 supports both 8-bit and 10-bit outputs, and you don't have to do
> anything special.
> ffmpeg -h encoder=libx264
> ......
> Previously you had to compile x264 with --bit-depth=10, and then link your
> ffmpeg to either an 8-bit or 10-bit libx264, but that is now unnecessary.
> See Unify 8-bit and 10-bit CLI and libraries for more info.
>
> https://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with-libx264/13166#13166
> See Unify 8-bit and 10-bit CLI and libraries for more info.
>
> https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c5301e45522e57127db4
>
>
> Very interesting and promising signals regarding better help and
> documentation, if this succeed to make things easier for new users to start
> with and next continue with Cinelerra. It is known this has been an
> Achilles heel and has caused the impression of a steep learning curve.
>
> Terje
>
>
> Den 02.01.2019 18:02, skrev Phyllis Smith:
> Is Cinelerra10bit (Cinx) based on 10-bit x264 or 10-bit x265?
> It is based on x265 BUT there is a enable flag in the build scripts for
> anyone doing there own build to use x264 instead.
> The confusion and uncorrected manual resulted in falsely believing that
> the maintainers of x264 included the possibility of having both 8/10 bit
> working without having to make a special compile.  We were fooled for a
> month or so and I had updated the manual and did not correct it
>
> GG is doing a Leap15 cinx experiment right now so I can get the wording
> correct in the manual since we have not re-tested it in quite some time.
> And I will try to be consistent in the terminology as you suggested too.
>
> A single, updated manual for "Cinelerra-GG Infinity" sounds to be to the
> 'right time', and yes, I will report typos/faults/RFEs on areas I see the
> demand for more detailed explanations or procedures.
>
> In general a 'single manual' needs to fill the demand for a combined
> "Users Guide" beside a "Reference or Feature Guide", maybe also as a online
> html and pdf print. And especially the new "gui ease of use" with the new
> "Cinfinity plugins icon set" compared with the original default icons or KB
> shortcuts as a reference.
>  Issue #77 in MantisBT is planned to be used to get reviewers help on the
> manual.
>
> Maybe this is a possibility to create a more integrated Help-system for
> Cinelerra-GG Infinity?
>
> I.e a "Help" menu with
>
> - link to the online manual
> - context sensitive Help?
> - the "About" button
> Believe it or not we actually have 2 shortcut single letters left in the
> english alphabet for use on the main window.  One of these is "h" and we
> are saving it for Help !  The other letter is "p" which I think should be
> saved for "p-hyllis".
>
> P.S. gg's experiment was done faster than I could finish this email due to
> interruptions.  With CINX, you can ONLY create 10-bit output when you
> render.   gg/phyllis
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.cinelerra-gg.org/pipermail/cin/attachments/20190102/2de371fa/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 2 Jan 2019 11:50:18 -0800
> From: Xing Tu <xtu360 at gmail.com>
> To: "Cinelerra.GG" <cin at lists.cinelerra-gg.org>
> Subject: Re: [Cin] Ungrouping of video and audio clips after some
>         edits
> Message-ID:
>         <CABNAfr99=
> 5xsofjagvYH5nOirvFgNHM-28sjyyyKVL2DaOO9OA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> > I think that you are omitting the fact that all track streams must be
> independent.  If they are always bound in the way you seem to describe, it
> would not be possible to create arbitrary alignments.  This is essential,
> since the result must support all possible media placements.
>
> I think Good Guy made that clear in a previous message and it makes
> sense. However, when the video "stream" is *grouped* with the audio
> "stream", the only thing that's possible is moving them around (or
> performing the operations available in the middle click menu). It's
> counter-intuitve that when trying to extend or shorten the length of
> the video stream, the corresponding audio stream remains unaffected
> (and vice-versa) despite being grouped.
>
> > You can still get what you want by switching from Arrow mode (Drag and
> Drop) to Ibeam mode (Cut and Paste)...
>
> I can see how this would work, but it comes back to the original
> problem of having to perform multiple actions. In addition to what you
> said about having to keep in mind which tracks are (dis)armed, the
> user would also be required to count the number of frames they removed
> (or added when using the "drag all following edits" action) from the
> video stream and do the same for the audio stream. It's clear that
> this is inefficient.
>
> > The undo is specifically for "edit" operations and grouping is not
> considered an edit but the state at the time of the undo edit is reverted
> to the last commit for an editing operation - this is what you show in your
> video.
>
> That's what I thought after thinking for a bit... but can you explain
> why both groups were separated after the second "undo"?
>
> > There is no obvious way, but you can do a Ctrl-C from the terminal
> window where you started running cin and it will create a /tmp/cin...dmp
> file that contains the last 32 UNDO entries
>
> Okay, so that's why ctrl-c has to be done twice to exit. It'd
> certainly be useful if you guys can figure this one out.
>
> Thank you guys again, though. It's really appreciate from some dumb
> user that you guys are even working on this project and have made all
> the improvements so far.
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 2 Jan 2019 21:00:25 +0100
> From: Andrea paz <gamberucci.andrea at gmail.com>
> To: "Cinelerra.GG" <cin at lists.cinelerra-gg.org>
> Subject: [Cin] ReframeRT, Interpolate Video
> Message-ID:
>         <
> CANnPPRrj23g5F0HMJCJTt+5rYj-WgD+oOb5YeBAfCcLuykKEWg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I don't understand how these two plugins work. The explanations on
> manual-cv are not clear (for me, of course). Can someone who knows how
> to use them explain how they work?
> (it's used to make the new unified manual).
> GG/Phyllis you can't answer, it's just to make sure you don't waste
> your time :-)
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 2 Jan 2019 12:51:14 -0800
> From: Xing Tu <xtu360 at gmail.com>
> To: "Cinelerra.GG" <cin at lists.cinelerra-gg.org>
> Subject: Re: [Cin] ReframeRT, Interpolate Video
> Message-ID:
>         <CABNAfr-vykvMLfNQ8jrTmsBQtpxauFvCi+0kDB7=
> rCzeus-t1g at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> >From what I gather, ReframeRT is a way of interpreting the source
> footage and playing it back at a specified rate. The most common
> example would be to have 60fps source footage in a 30fps project
> (settings -> format -> frame rate) and setting it to play back at 1/2
> the speed -- set ReframeRT to 0.5. This would result in smooth slow
> motion as all the frames are played back, but there are 2 times the
> number of frames in the source compared to rate they are being played
> back at. It can also be used to correct footage.
> If, however, you want to achieve smooth slow motion with 30fps source
> footage, you can use Interpolate.
> Interpolate I think makes up frames that don't exist, like "frame
> blending" in premiere.
> This video might be of some help, as it shows you the features in
> action https://www.youtube.com/watch?v=1NvrfXOa8j0.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> Cin mailing list
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
>
> ------------------------------
>
> End of Cin Digest, Vol 3, Issue 5
> *********************************
>


-- 
Lg
Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20190103/44a7535b/attachment.html>