Cecil Westerhof-3 wrote
> yuv420p(top first)
Maybe partially related - your camera files are encoded interlaced TFF (the
content might not be) , but your commandline specifies progressive encoding.
This has other implications in the way other programs / players handle the
file if the content is
On 08/19/2020 01:43 PM, Jim DeLaHunt wrote:
On 2020-08-19 07:34, Paul B Mahol wrote:
You are deeply confused about our filters.
Any filter can change pixel formats to one that they accepts thus gbrp
is picked instead of packed rgb, this is already documented
implicitly.
Wow, "documented
Am Mi., 19. Aug. 2020 um 22:48 Uhr schrieb Nicolas George :
>
> Carl Eugen Hoyos (12020-08-19):
> > (I'd like to add that the extremely important information about automatic
> > scale filter insertion was originally shown with default verbosity, I always
> > wanted to restore this behaviour and
Carl Eugen Hoyos (12020-08-19):
> (I'd like to add that the extremely important information about automatic
> scale filter insertion was originally shown with default verbosity, I always
> wanted to restore this behaviour and wonder now who changed it...)
commit
On 8/19/20, Jim DeLaHunt wrote:
> On 2020-08-19 10:53, Paul B Mahol wrote:
>> On 8/19/20, Jim DeLaHunt wrote:
>>> On 2020-08-19 07:34, Paul B Mahol wrote:
You are deeply confused about our filters.
Any filter can change pixel formats to one that they accepts thus gbrp
is picked
On 2020-08-19 10:53, Paul B Mahol wrote:
On 8/19/20, Jim DeLaHunt wrote:
On 2020-08-19 07:34, Paul B Mahol wrote:
You are deeply confused about our filters.
Any filter can change pixel formats to one that they accepts thus gbrp
is picked instead of packed rgb, this is already documented
Am Mi., 19. Aug. 2020 um 19:59 Uhr schrieb Paul B Mahol :
> > 1. Insert a showinfo filter after maskedmerge and check the pixel format.
>
> Just use -v debug, it will show whenever scale/format filter is auto inserted.
Luckily, -v verbose is sufficient.
(I'd like to add that the extremely
Am Sa., 15. Aug. 2020 um 13:01 Uhr schrieb Cecil Westerhof :
>
> In the past the original file was between 4 to 13 times bigger as the
> compressed file.
As I tried to explain in the other thread:
Even neglecting the fact that you seem to believe your camera
does an uncompressed recording (it
On 8/19/20, Michael Koch wrote:
> Am 19.08.2020 um 16:34 schrieb Paul B Mahol:
>> On 8/19/20, Michael Koch wrote:
>>> Am 18.08.2020 um 14:35 schrieb Michael Koch:
Hello all,
I have a question about this script:
rem Create red and yellow videos 300x300
Am Di., 18. Aug. 2020 um 14:44 Uhr schrieb Michael Koch
:
> c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
>
On 8/19/20, Jim DeLaHunt wrote:
> On 2020-08-19 07:34, Paul B Mahol wrote:
>> You are deeply confused about our filters.
>> Any filter can change pixel formats to one that they accepts thus gbrp
>> is picked instead of packed rgb, this is already documented
>> implicitly.
>
> Wow, "documented
On 2020-08-19 07:34, Paul B Mahol wrote:
You are deeply confused about our filters.
Any filter can change pixel formats to one that they accepts thus gbrp
is picked instead of packed rgb, this is already documented
implicitly.
Wow, "documented implicitly". This is such a classic FFmpeg project
On 8/19/2020 5:22 AM, Moritz Barsnick wrote:
Perhaps the original poster meant "broadcast" in the sense of
"sending"?
I suspect that's the case- not broadcast in the networking sense.
z!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
Am 19.08.2020 um 16:34 schrieb Paul B Mahol:
On 8/19/20, Michael Koch wrote:
Am 18.08.2020 um 14:35 schrieb Michael Koch:
Hello all,
I have a question about this script:
rem Create red and yellow videos 300x300
c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y red.mp4
I would love to patch but I don't know the programming language.
śr., 19 sie 2020, 14:40 użytkownik Moritz Barsnick
napisał:
> On Tue, Aug 18, 2020 at 22:51:30 +0200, Pan_1337 wrote:
> > Hello, if this is not a problem for you and you find time I would be
> very
> > grateful if I added CLI
On 8/19/20, Michael Koch wrote:
> Am 18.08.2020 um 14:35 schrieb Michael Koch:
>> Hello all,
>>
>> I have a question about this script:
>>
>> rem Create red and yellow videos 300x300
>>
>> c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y red.mp4
>> c:\ffmpeg\ffmpeg -f lavfi -i
Hi Guys
I am converting UDP Input to Live HLS output and pushing the chunks to a
webdav server. Initial playback works fine, but the playback was delayed by
almost an hour, when we checked after 15 hours. I can also see that the cpu
load average is very less.
*ffmpeg :*
*ffmpeg version
On Mon, Aug 17, 2020 at 22:53:12 +0200, Cecil Westerhof wrote:
> Maybe I am just dumb and I use the wrong questions, but when I
> searched I got a lot of hits that explained I needed tot switch
> because the space needed would be halved
Well, if you're driving a compact, and someone writes "you
On Mon, Aug 17, 2020 at 13:54:33 +0200, Cecil Westerhof wrote:
> > The input doesn't look uncompressed to me.
>
> I do not have much knowledge of video formats, but this was really
> shot with a Sony. Maybe that the Sony compresses the video itself?
> It is a HDR-CX320.
You won't see use of
Thank you, Moritz
On Wed, Aug 19, 2020 at 9:32 AM Moritz Barsnick wrote:
> On Mon, Aug 17, 2020 at 11:21:38 -0300, Leonardo Pagotto wrote:
> > I'm transcoding/resizing some UDP live streams using CUVID and NVENC. It
> > works but I got the feeling could be better, this is the my command line:
>
On Tue, Aug 18, 2020 at 22:51:30 +0200, Pan_1337 wrote:
> Hello, if this is not a problem for you and you find time I would be very
> grateful if I added CLI support for the proxy in ffmpeg.
We would also be grateful if you added it. A patch to the ffmpeg-devel
mailing list would be welcomed.
On Mon, Aug 17, 2020 at 11:21:38 -0300, Leonardo Pagotto wrote:
> I'm transcoding/resizing some UDP live streams using CUVID and NVENC. It
> works but I got the feeling could be better, this is the my command line:
What feeling is that? Faster, higher quality, just more efficient?
> ffmpeg
On Wed, Aug 19, 2020 at 11:41:36 +0200, Nicolas George wrote:
> Dennis Mungai (12020-08-19):
> > (b). Capabilities similar to UDP
> >
> > Would be Haivision's SRT, which FFmpeg supports if enabled on build time
> > via --enable-libsrt.
>
> Does SRT support any kind of broadcast, like requested by
Dennis Mungai (12020-08-19):
> (b). Capabilities similar to UDP
>
> Would be Haivision's SRT, which FFmpeg supports if enabled on build time
> via --enable-libsrt.
Does SRT support any kind of broadcast, like requested by the original
question?
Regards,
--
Nicolas George
signature.asc
I would go for SRT as well.
It doesn't have a proper username/password method, but the passphrase mechanism
implement should suffice.
In addition to this it can also compensate a lot of network issues between
transmitter and receiver that couldn't be compensated by UDP, and doesn't add a
lot
On Wed, 19 Aug 2020, 11:53 Alessandro Molon,
wrote:
> You simply cannot. UDP delivery is not meant to do that.
>
> There are other protocols that support authentication
> If you provide a little bit more about what are your needs I can suggest
> some.
>
> Alex
>
> -Original Message-
>
You simply cannot. UDP delivery is not meant to do that.
There are other protocols that support authentication
If you provide a little bit more about what are your needs I can suggest some.
Alex
-Original Message-
From: ffmpeg-user On Behalf Of hassan shatnawi
Sent: 02 October 2017
Am 18.08.2020 um 14:35 schrieb Michael Koch:
Hello all,
I have a question about this script:
rem Create red and yellow videos 300x300
c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y red.mp4
c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
yellow.mp4
28 matches
Mail list logo
