Re: [Cin] Best practice to copy & paste track with changed speed

[Phyllis Smith]

(Probably IgorBeg could demonstrate this quite well) but here is a way.

Using a "bounce" track is a way GG explained how to do this and the steps
are something like this for a Video track:
- edit video track and change speed wherever
- add a new video track and move it down below the edited video track
- in Cut and Paste mode, highlight the whole video track, RMB click on new
video track to get the popup and highlight under the "Shared Track" column,
the Video track to use and click OK
- put in your masks where you want them on the main Video track
- add BoxBlur plugin to the second shared track

Here is streamable showing it works.  I personally could not follow these
directions to set it up myself but used what GG did.
https://streamable.com/jcqo8z

On Thu, Apr 23, 2020 at 3:23 PM deim31  wrote:

> Hi,
>
> I made small tutorial from mobile screen record. I changed speed and
> when I realized I wanted blur some region I tried this:
>
> try #1:
> 1) copy region from video to new video track
> 2) set mask for region
> 3) add blur effect
>
> But it doesn't work - what I copied is not what I pasted
>
> try #2:
> 1) copy whole track to new video track
> 2) and 3) is identical to #1
>
> But speed didn't copy => argh...
>
> try #3:
> 1) copy whole track to new video track before speed modification
> 2) gang edits and edit speed (copied to second track)
>
> This worked well.
>
> But there may be a bigger project where I realize I need to copy track
> with modified speed so my question is how to do it when I didn't planned
> edits well and need to copy region from track with changed speed.
>
> Thanks ;-)
> deim
>
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] wildest dreams: stream-copy and/or skipping avoidable pixel format conversions

[Phyllis Smith]

Simeon - important clarification concerning the following.  The code Andrew
references was removed from CV. IT HAS NOT BEEN REMOVED from the current
Cinelerra-GG, i.e. what you are using.  It does illustrate the use of a
second channel for the compressed data while maintaining the one channel
for the uncompressed data.  However, this code is of quite limited
applicability.   Phyllis/Bill

Hi Andrew,
> >
> > I think this was done in old Cinelerra for some DV variants and mjpeg
> (in mov and avi)
> >
> > In old CinelerraCV it was removed in commits
> >
> >
> https://github.com/cinelerra-gg/cinelerra-cv/commit/8364fc6af3eb9b105ecf0853f79885090b12005f
> >
> https://github.com/cinelerra-gg/cinelerra-cv/commit/0ff51f4c53e17ff33701e8cc1096de33a87313b9
> >
> > I remember this because I tested this (mis)feature, and found it working
> for
> > mjpeg avi (so i was not convinced by this reasoning and just keep my
> copy at commit before this :E)
> >
> >
> https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/guicast/bccmodels.h;h=28b58459fb74eabb72e3fbf74f371ea51786cd18;hb=HEAD
>
> This is a very interesting finding, and something I was not aware at all.
> So thanks for bringing this piece of history to my attention!
> ..
> Maybe Einar can give additional details concerning the circumstances of the
> removal?
>
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

[Cin] Best practice to copy & paste track with changed speed

[deim31]

Hi,

I made small tutorial from mobile screen record. I changed speed and 
when I realized I wanted blur some region I tried this:


try #1:
1) copy region from video to new video track
2) set mask for region
3) add blur effect

But it doesn't work - what I copied is not what I pasted

try #2:
1) copy whole track to new video track
2) and 3) is identical to #1

But speed didn't copy => argh...

try #3:
1) copy whole track to new video track before speed modification
2) gang edits and edit speed (copied to second track)

This worked well.

But there may be a bigger project where I realize I need to copy track 
with modified speed so my question is how to do it when I didn't planned 
edits well and need to copy region from track with changed speed.


Thanks ;-)
deim

--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Official CinGG channel on Youtube

[Sam]

Am 23.04.20 um 17:10 schrieb Rafa Mar Multimedia en Gnu\Linux:
It was a hazing. The channel was in German and I got in trouble, I 
wanted to log out and instead I left. Thank you.


Np, you're welcome Rafa. As long as it's working again everything's fine.



I will do everything in my power to promote Cinelerra GG.

When a thing is fun, people like to advertise it. I'm glad of that, thx :)
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] wildest dreams: stream-copy and/or skipping avoidable pixel format conversions

[Phyllis Smith]

Simeon,

WOW, thank you for your detailed analysis and taking the time to get your
information down in writing.  It is very much appreciated.  I have read
your email to Bill for discussion and he has some thoughts to relay.
Considerable thought has been put into your ideas already in the past. (I
am going to log this in our Feature/Bug Tracker because you never know if
someone will want to implement some parts of your ideas).

how cinelerra could improve performance considerably in cases where little
> (or rather: "nothing") is to be done to the input video frames.
>
> "trivial editing" with long and/or large files:  I could completely avoid
> reencoding of the video stream using the command line tool ffmpeg. FFmpeg
> works perfectly fine for single "trivial edits", but the command (and
> required filters) becomes admittedly complex as soon as multiple edits have
> to be made.
> ...
> So in my wildest dreams I dreamed of good old cinelerra learning how to do
> stream-copying (read up on ffmpeg's -c:v copy and -c:a copy if you are not
> familiar with that concept!). As stream-copying does not require to decode
> the input, the achievable speed is typically bound by the disk IO -- it can
> be as fast as your SSD-Raid at nearly negligible CPU cost.
>

Cinelerra could carry compressed AND uncompressed data in the vframe, but
you want to be able to see the video in the composer so the uncompressed
data is needed.  You would need a second uncompressed channel.  If you are
using an NLE, the compositor is needed to look at the video and this
obviously requires a decode operation.  It turns out that Cinelerra already
has Direct Copy BUT where it is applicable and feasible is a small set of
operations.

>
> Please note that stream-copying per definition only works if the packets
> from the input are not to be altered at all and the output stream has
> exactly the same encoding settings [1]. Only the container format would be
> allowed to be different, as long as it can carry the unmodified stream.
>
> Implementing this in cinelerra would definitely be a huge, nontrivial change.
> ...  a *real* challenge! ;)
>

A test that Bill uses in deciding whether or not to spend the time for
implementation is based on "developer time needed" versus "user time
saved".  In this case maybe 500 developer hours to implement stream copying
has to be balanced against the 2% of time that users would take advantage
of this feature.  That 2% is another guess based on the fact that the
majority of people using Cinelerra, are actually planning on doing a lot of
editing, not just a trivial amount.

>
> I profiled cinelerra-gg using operf during rendering when using an Intel
> UHD Graphics 630 GPU (gen9.5) for HW decoding and a Nvidia Quadro P2000
> (Pascal nvenc) for encoding.
>

Again, thanks for passing along the profiling information.  (Bill loves
this kind of stuff!)

>
> The most time-consuming parts appear to be:
>
> When setting format to YUV 8bit:
> 17.7664  BC_Xfer::xfer_yuv888_to_yuv420p(unsigned int, unsigned int)
> 13.1723  BC_Xfer::xfer_yuv444p_to_yuv888(unsigned int, unsigned int)
> 10.7678  __memmove_avx_unaligned_erms   [ in libc-2.31.so ]
> 10.7615  ff_hscale8to15_4_ssse3
>  8.5718  BC_Xfer::xfer_yuv888_to_bgr(unsigned int, unsigned int)
>  2.8518  ff_yuv2plane1_8_avx
>

About the above, Bill says "memmove is a tough act to follow" !!
And "bgr"s purpose is to draw the video on the Display -- got to have
this.

In any of the profile information provided, anything that has "ff" in it is
obviously ffmpeg which uses up a lot of time and most likely has been
fine-tuned to work as well as possible and it is very good and almost
always fast.  Cinelerra-GG takes full advantage of ffmpeg and so if it is
not as fast as it could be, it is so worth it.  Earlier versions of
Cinelerra, had their own implements and could be improved upon, others were
and still are exceptional work.

>
> During rendering, two of eight cores were at 70-85% (according to htop). As
> none reached 100% alone, but the sum is above 100%, I'm not really sure
> whether rendering is currently CPU bound or rather memory bound. If someone
> knows a good tool how to discriminate between these two bounds, please tell
> me! In case this should be CPU bound, multithreading in this part of the
> code might help, as I have (more than) 6 idling CPU cores left on this
> machine ;)
>

The contention if most likely to be "logic bound", that is probably due to
locks; i.e. have to wait for something to happen before can proceed.  One
thing that is likely to help is "having the plugin stack use threads" -
that way the plugins would be queuing up in advance and ready to go.,
pipelined instead of demand pull.

>
> With RGBA 8bit transcoding (i.e. rendering a timeline consisting of a
> single "unmodified" input clip) of a FullHD 25p h264 video using HW
> accelerated cinelerra can take now only a quarter of the playback time (in
> ffmpeg notation: speed=4x).
>

Yes, the 

Re: [Cin] Official CinGG channel on Youtube

[Rafa Mar Multimedia en Gnu\Linux]

It was a hazing. The channel was in German and I got in trouble, I wanted
to log out and instead I left. Thank you.
I will do everything in my power to promote Cinelerra GG.

El jue., 23 abr. 2020 a las 16:09, Sam () escribió:

> I added you to the channel a few days ago, but unfortunately you were no
> longer in it. I added you again, you can now upload videos and manage the
> playlists.
>
> Sam
> Am 23.04.20 um 15:46 schrieb Rafa Mar Multimedia en Gnu\Linux:
>
> You have to go to youtube studio, from there to lists and in lists above
> there is a button that says create new list. It may be empty.
> This will open this new list for you.
> Now you give the ... look at the next image
>
> [image: image.png]
>
> [image: image.png]
> You copy the link and send it to my personal email, which is this
> rafamar.mm...@gmail.com
> And so I, without being a channel administrator, will be able to add
> videos to this list
> The video could be
> "Short & silent user tutorials"
> or
> "Short & Silent Rafa Mar tutorials"
> Although my name is not important to me, it can be useful in this case for
> organize the lists correctly.
>
> Then in configuring the channel you can make the playlists appear on the
> home page first. This is simple, you will see that there are arrows to the
> right of each content box to raise or lower their position.
>
>
>
>
> El jue., 23 abr. 2020 a las 14:39, Andrea paz (<
> gamberucci.and...@gmail.com>) escribió:
>
>> For an intervention by Sam (who is the only administrator) you have to
>> wait until the weekend. I can only create a new playlist while loading
>> a video. Besides, I don't know how to give you permission to upload
>> videos.  Any advice?
>> --
>> Cin mailing list
>> Cin@lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
>
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] wildest dreams: stream-copy and/or skipping avoidable pixel format conversions

[Andrew Randrianasulu]

В сообщении от Thursday 23 April 2020 13:36:30 Simeon Vc3b6lkel написал(а):
> Hi all,
> 
> coming back to cinelerra after a whole decade, I was really surprised
> finding now even hardware accelerated decoding and encoding implemented...
> Even though the landscape of cinelerra-forks seems to become increasingly
> confusing, THANK YOU, to all who contributed in the last years and of
> course especially to Adam, Einar and William for their tireless commitment!
> 
> 
> With this mail I want to put forward two ideas, or rather wildest dreams,
> how cinelerra could improve performance considerably in cases where little
> (or rather: "nothing") is to be done to the input video frames.
> 
> 
> 
> Motivation / Introduction
> 
> In the last weeks I had to deal a lot with "trivial editing" with long
> and/or large files: Chopping of a few seconds at the beginning or end,
> sometimes concatenating two or three takes, removing a constant offset
> between audio and video. As my videos had a constant group-of-pictures
> (GOP) length so I knew the position of keyframes and shifting the cuts
> around by half a GOP was no problem either, I could completely avoid
> reencoding of the video stream using the command line tool ffmpeg. FFmpeg
> works perfectly fine for single "trivial edits", but the command (and
> required filters) becomes admittedly complex as soon as multiple edits have
> to be made.
> 
> 
> 
> Stream copying
> 
> So in my wildest dreams I dreamed of good old cinelerra learning how to do
> stream-copying (read up on ffmpeg's -c:v copy and -c:a copy if you are not
> familiar with that concept!). As stream-copying does not require to decode
> the input, the achievable speed is typically bound by the disk IO -- it can
> be as fast as your SSD-Raid at nearly negligible CPU cost.
> 
> Please note that stream-copying per definition only works if the packets
> from the input are not to be altered at all and the output stream has
> exactly the same encoding settings [1]. Only the container format would be
> allowed to be different, as long as it can carry the unmodified stream.
> 
> Implementing this in cinelerra would definitely be a huge, nontrivial
> change. It would require at least detection of the input encoding settings
> and matching the output settings respectively, a shortcut around the whole
> 'decoding->camera->intermediate->projector->encoding' pipeline where no
> effects (in the wider sense!) are active and whole GOPs could be
> stream-copied and I haven't even looked up yet whether it could be feasible
> to adapt any of the current rendering/muxing backends to accept "already
> encoded" input (being forwarded through the shortcut).

I think this was done in old Cinelerra for some DV variants and mjpeg (in mov 
and avi)

In old CinelerraCV it was removed in commits

https://github.com/cinelerra-gg/cinelerra-cv/commit/8364fc6af3eb9b105ecf0853f79885090b12005f
https://github.com/cinelerra-gg/cinelerra-cv/commit/0ff51f4c53e17ff33701e8cc1096de33a87313b9

I remember this because I tested this (mis)feature, and found it working for
mjpeg avi (so i was not convinced by this reasoning and just keep my copy at 
commit before this :E)

https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/guicast/bccmodels.h;h=28b58459fb74eabb72e3fbf74f371ea51786cd18;hb=HEAD

enum BC_CModel {
  27 BC_TRANSPARENCY = 0,
  28 BC_COMPRESSED   = 1,

[..]

I think this 'colormodel' define was used for this.
But now ffmpeg rule the world, so my idea was to just copy
packets/frames exactly as they come out of libavformat demuxers,
and carry them in some extended structure (in vframe ?), along with frame type 
(I, B, P). So at the encoding end  liavformat muxers will see same thing as  if 
they were connected directly...

But unfortunately this is also just 0.1% of road 
(no coding experiments were done by me on this front)


Thanks for your experiments and detailed thoughts!

> 
> Nevertheless, I wanted to share this vision, just in case someone should be
> on the look-out for a *real* challenge! ;)
> 
> 
> 
> Transcoding bottlenecks
> 
> Coming down to earth, I tested the hardware accelerated decoding and
> encoding in cinelerra-gg. This apparently works. Having shifted the heavy
> codec work away from the CPU, new bottlenecks appear, e.g. pixel format
> conversions and memory operations.
> 
> I profiled cinelerra-gg using operf during rendering when using an Intel
> UHD Graphics 630 GPU (gen9.5) for HW decoding and a Nvidia Quadro P2000
> (Pascal nvenc) for encoding.
> 
> The most time-consuming parts appear to be:
> 
> When setting format to YUV 8bit:
> 17.7664  BC_Xfer::xfer_yuv888_to_yuv420p(unsigned int, unsigned int)
> 13.1723  BC_Xfer::xfer_yuv444p_to_yuv888(unsigned int, unsigned int)
> 10.7678  __memmove_avx_unaligned_erms   [ in libc-2.31.so ]
> 10.7615  ff_hscale8to15_4_ssse3
>  8.5718  BC_Xfer::xfer_yuv888_to_bgr(unsigned int, unsigned int)
>  2.8518  ff_yuv2plane1_8_avx
> 
> 

[Cin] wildest dreams: stream-copy and/or skipping avoidable pixel format conversions

[Simeon Völkel]

Hi all,

coming back to cinelerra after a whole decade, I was really surprised
finding now even hardware accelerated decoding and encoding implemented...
Even though the landscape of cinelerra-forks seems to become increasingly
confusing, THANK YOU, to all who contributed in the last years and of
course especially to Adam, Einar and William for their tireless commitment!


With this mail I want to put forward two ideas, or rather wildest dreams,
how cinelerra could improve performance considerably in cases where little
(or rather: "nothing") is to be done to the input video frames.



Motivation / Introduction

In the last weeks I had to deal a lot with "trivial editing" with long
and/or large files: Chopping of a few seconds at the beginning or end,
sometimes concatenating two or three takes, removing a constant offset
between audio and video. As my videos had a constant group-of-pictures
(GOP) length so I knew the position of keyframes and shifting the cuts
around by half a GOP was no problem either, I could completely avoid
reencoding of the video stream using the command line tool ffmpeg. FFmpeg
works perfectly fine for single "trivial edits", but the command (and
required filters) becomes admittedly complex as soon as multiple edits have
to be made.



Stream copying

So in my wildest dreams I dreamed of good old cinelerra learning how to do
stream-copying (read up on ffmpeg's -c:v copy and -c:a copy if you are not
familiar with that concept!). As stream-copying does not require to decode
the input, the achievable speed is typically bound by the disk IO -- it can
be as fast as your SSD-Raid at nearly negligible CPU cost.

Please note that stream-copying per definition only works if the packets
from the input are not to be altered at all and the output stream has
exactly the same encoding settings [1]. Only the container format would be
allowed to be different, as long as it can carry the unmodified stream.

Implementing this in cinelerra would definitely be a huge, nontrivial
change. It would require at least detection of the input encoding settings
and matching the output settings respectively, a shortcut around the whole
'decoding->camera->intermediate->projector->encoding' pipeline where no
effects (in the wider sense!) are active and whole GOPs could be
stream-copied and I haven't even looked up yet whether it could be feasible
to adapt any of the current rendering/muxing backends to accept "already
encoded" input (being forwarded through the shortcut).

Nevertheless, I wanted to share this vision, just in case someone should be
on the look-out for a *real* challenge! ;)



Transcoding bottlenecks

Coming down to earth, I tested the hardware accelerated decoding and
encoding in cinelerra-gg. This apparently works. Having shifted the heavy
codec work away from the CPU, new bottlenecks appear, e.g. pixel format
conversions and memory operations.

I profiled cinelerra-gg using operf during rendering when using an Intel
UHD Graphics 630 GPU (gen9.5) for HW decoding and a Nvidia Quadro P2000
(Pascal nvenc) for encoding.

The most time-consuming parts appear to be:

When setting format to YUV 8bit:
17.7664  BC_Xfer::xfer_yuv888_to_yuv420p(unsigned int, unsigned int)
13.1723  BC_Xfer::xfer_yuv444p_to_yuv888(unsigned int, unsigned int)
10.7678  __memmove_avx_unaligned_erms   [ in libc-2.31.so ]
10.7615  ff_hscale8to15_4_ssse3
 8.5718  BC_Xfer::xfer_yuv888_to_bgr(unsigned int, unsigned int)
 2.8518  ff_yuv2plane1_8_avx

When setting format to RGB 8bit:
17.8958  yuv2rgb24_1_c
13.4321  __memmove_avx_unaligned_erms   [ in libc-2.31.so ]
10.9851  lumRangeToJpeg_c
10.2374  ff_hscale8to15_4_ssse3
 8.7581  ff_hscale14to15_4_ssse3
 7.5900  ff_rgb24ToY_avx
 7.1143  rgb24ToUV_half_c
 4.8434  chrRangeToJpeg_c
 4.7945  BC_Xfer::xfer_rgb888_to_bgr(unsigned int, unsigned int)
 2.0201  ff_yuv2plane1_8_avx

When setting format to RGBA 8bit:
16.3639  yuv2rgbx32_1_1_c
14.8711  __memmove_avx_unaligned_erms   [ in libc-2.31.so ]
10.0083  ff_hscale8to15_4_ssse3
 9.1448  lumRangeToJpeg_c
 8.7119  ff_rgbaToY_avx
 8.5619  ff_hscale14to15_4_ssse3
 8.2640  rgb32ToUV_half_c
 5.1650  BC_Xfer::xfer_rgbx_to_bgr(unsigned int, unsigned int)
 5.1056  chrRangeToJpeg_c
 1.9289  ff_yuv2plane1_8_avx

When setting format to RGB-Float:
15.7817  BC_Xfer::xfer_rgba_float_to_rgba16161616(unsigned int, unsigned int)
15.4870  BC_Xfer::xfer_rgba_to_rgba_float(unsigned int, unsigned int)
12.9261  rgb64LEToY_c
 7.4284  __memmove_avx_unaligned_erms   [ in libc-2.31.so ]
 6.6232  av_pix_fmt_desc_get
 6.0252  rgb64LEToUV_half_c
 3.7100  yuv2rgbx32_1_1_c
 2.9902  BC_Xfer::xfer_rgbx_float_to_bgr(unsigned int, unsigned int)
 2.1572  ff_hscale8to15_4_ssse3
 2.0333  lumRangeToJpeg_c
 1.8625  ff_hscale16to15_4_ssse3

During rendering, two of eight cores were at 70-85% (according to htop). As
none reached 100% alone, but the sum is above 100%, I'm not really sure
whether rendering is currently CPU bound or rather memory bound. If someone

Re: [Cin] Official CinGG channel on Youtube

[Sam]

I added you to the channel a few days ago, but unfortunately you were no 
longer in it. I added you again, you can now upload videos and manage 
the playlists.


Sam

Am 23.04.20 um 15:46 schrieb Rafa Mar Multimedia en Gnu\Linux:
You have to go to youtube studio, from there to lists and in lists 
above there is a button that says create new list. It may be empty.

This will open this new list for you.
Now you give the ... look at the next image

image.png

image.png
You copy the link and send it to my personal email, which is this
rafamar.mm...@gmail.com 
And so I, without being a channel administrator, will be able to add 
videos to this list

The video could be
"Short & silent user tutorials"
or
"Short & Silent Rafa Mar tutorials"
Although my name is not important to me, it can be useful in this case 
for organize the lists correctly.


Then in configuring the channel you can make the playlists appear on 
the home page first. This is simple, you will see that there are 
arrows to the right of each content box to raise or lower their position.





El jue., 23 abr. 2020 a las 14:39, Andrea paz 
(mailto:gamberucci.and...@gmail.com>>) 
escribió:


For an intervention by Sam (who is the only administrator) you have to
wait until the weekend. I can only create a new playlist while loading
a video. Besides, I don't know how to give you permission to upload
videos.  Any advice?
-- 
Cin mailing list

Cin@lists.cinelerra-gg.org 
https://lists.cinelerra-gg.org/mailman/listinfo/cin


-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Official CinGG channel on Youtube

[Rafa Mar Multimedia en Gnu\Linux]

You have to go to youtube studio, from there to lists and in lists above
there is a button that says create new list. It may be empty.
This will open this new list for you.
Now you give the ... look at the next image

[image: image.png]

[image: image.png]
You copy the link and send it to my personal email, which is this
rafamar.mm...@gmail.com
And so I, without being a channel administrator, will be able to add videos
to this list
The video could be
"Short & silent user tutorials"
or
"Short & Silent Rafa Mar tutorials"
Although my name is not important to me, it can be useful in this case for
organize the lists correctly.

Then in configuring the channel you can make the playlists appear on the
home page first. This is simple, you will see that there are arrows to the
right of each content box to raise or lower their position.




El jue., 23 abr. 2020 a las 14:39, Andrea paz ()
escribió:

> For an intervention by Sam (who is the only administrator) you have to
> wait until the weekend. I can only create a new playlist while loading
> a video. Besides, I don't know how to give you permission to upload
> videos.  Any advice?
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

[Cin] ffmpeg.git changes for mpegts muxer

[Andrew Randrianasulu]

Hi all!

Currently I have some fun (bug) with mesa git drivers and Blender 2.79b (and 
related items like LuxRender)
so I mostly read Cin list without saying much.

Still, there are some changes, possibly breaking ffmpeg.git patchset:

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/422f0a61367f068fb8b1b9ab8cc2eee1808c803c
avformat/mpegtsenc: use standard pids for m2ts

and few others after that one
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/bcc19933af903cda7a824ee654bb0aedfad758de
avformat/mpegtsenc: only allow one program in m2ts mode

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/3958244c918e3cee921ace438965eb613c11176e
avformat/mpegtsenc: factorize determining stream_type

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/7f2649bb46e3dde691edfb03aeb42ba4ef183ab8
avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for 
m2ts
 
 Fixes ticket #2622.

Last one adds  this line to Changelog:

+- Support for muxing pcm and pgs in m2ts
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Official CinGG channel on Youtube

[Rafa Mar Multimedia en Gnu\Linux]

Thank you very much Andrea, I did not know this method on YouTube. I will
adapt my channel's videos to these names. If you look at them I put an
access to the cinelerra channel, I will also put them in the description.
Sam didn't add me back to the channel, so I can't put them right there, but
you can create a playlist and give me permission so I can add videos to it.
Something like "Short and silent tutorials" my name does not matter if it
comes out.

El jue., 23 abr. 2020 a las 11:42, Andrea paz ()
escribió:

> For the videos I have already uploaded I used the method considered
> std in Youtube. At the end of the title put:
>
> [short; silent (or text ENG, or sub ENG); by 'NAME']
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Official CinGG channel on Youtube

[Andrea paz]

For the videos I have already uploaded I used the method considered
std in Youtube. At the end of the title put:

[short; silent (or text ENG, or sub ENG); by 'NAME']
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Grafism pack

[Rafa Mar Multimedia en Gnu\Linux]

Thanks you very much. IgorBeg.
It is a gift for all people who want to use and to maintain a line of
letter style like on the GG website. Of course, you can modify to your
liking.

El jue., 23 abr. 2020 a las 9:01, Igor BEGHETTO ()
escribió:

> Very good work, RafaMar!
>
> IgorBeg
>
>
> Il 22/04/2020 11.56, Rafa Mar Multimedia en Gnu\Linux ha scritto:
> > In case any reader is interested, I attach the sources that Cinfinity
> > uses on the cinelerra website. And an image idea to put on the cover
> > of the YouTube channel's videos.
> > I attach the gimp file, in case someone wants to modify it.
> >
> > The n of cinfinity can be done by rotating the c 90 ° or mirroring the
> > r or the n itself by erasing its left part.
> >
> > Greetings and thanks for your excellent work.
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Official CinGG channel on Youtube

[Rafa Mar Multimedia en Gnu\Linux]

You are absolutely right Igor. I'm going to look at simplifying the name. I
think it is enough with:
"Silent Tutorials"
That it is a video is already known, and that it is short they see it in
duration.
Thank you very much, then when I have time for this I change it.

El jue., 23 abr. 2020 a las 9:00, Igor BEGHETTO ()
escribió:

> I saw your link with the videos, RafaMar. Seems to me good.
> I think that the words "Short and silente video tutorials" in the
> Titleof the web page are not needed. Title too long, I think.
> My personal opinion, of course.
>
> IgorBeg
>
>
> Il 23/04/2020 0.57, Rafa Mar Multimedia en Gnu\Linux ha scritto:
> > This type of videos is what I was referring to with my idea of
> > promoting and filling the channel for all people regardless of their
> > country and language.
> > https://www.youtube.com/playlist?list=PL5UVht3oXSIk1iKctcD6Gji9Jcn6BbIHv
> >
> --
> Cin mailing list
> Cin@lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Official CinGG channel on Youtube

[Igor BEGHETTO]

I saw your link with the videos, RafaMar. Seems to me good.
I think that the words "Short and silente video tutorials" in the 
Titleof the web page are not needed. Title too long, I think.

My personal opinion, of course.

IgorBeg


Il 23/04/2020 0.57, Rafa Mar Multimedia en Gnu\Linux ha scritto:
This type of videos is what I was referring to with my idea of 
promoting and filling the channel for all people regardless of their 
country and language.

https://www.youtube.com/playlist?list=PL5UVht3oXSIk1iKctcD6Gji9Jcn6BbIHv


--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin