Re: [FFmpeg-user] Compression is a lot smaller

[pdr0]

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 interlaced

add
 -flags +ildct+ilme -x264opts tff=1






--
Sent from: http://www.ffmpeg-archive.org/
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

[Mark Filipak]

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 implicitly". This is such a classic FFmpeg project statement. The role of 
documentation is to explain, explicitly, at a suitable level of detail. What does "documented 
implicitly" even mean?


I think this thread points out is that FFmpeg documentation is inadequate. It is hard to prove a 
negative, but I suspect that the term "pixel format" is not actually defined in the FFmpeg 
documentation. I suspect that the statement, "Any filter can change pixel formats" is not stated 
either. Certainly the maskedmerge filter documentation[1] doesn't mention pixel formats at all, much 
less say what pixel formats the filter sets for its output.


I have attempted to improve the documentation, to make it explain explicitly instead of fail to 
document. I encountered a great deal of resistance to those patches, because they make the 
documentation more explicit, because they have more words, and because documentation has so little 
value in this project relative to executable code.


And yet "You are deeply confused about our filters". In other words, the documentation has failed to 
explain to you what FFmpeg does, the project has failed to write or welcome improved documentation, 
you do not understand how FFmpeg works — and somehow this is your fault.


[1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge


I have a theory, Jim. I think the developers don't document things (or comment their code) for 2 
reasons: 1, They want to be able to change methods and behaviors without having to maintain 
documentation, and 2, They want to make money doing consulting jobs for people who commit ffmpeg for 
their projects, then give up trying to write ffmpeg command lines.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Carl Eugen Hoyos]

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 wonder now who changed it...)
>
> commit 1a49a169eb74a978eb7b2a4f2caf3520b7741ee5
> Author: Anton Khirnov 
> Date:   2012-06-25 06:31:38 +0200
>
> lavfi: make filters less verbose.
>
> [...]
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index b550169468..dc828153f9 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -101,7 +101,7 @@ int avfilter_insert_filter(AVFilterLink *link, 
> AVFilterContext *filt,
>  int ret;
>  unsigned dstpad_idx = link->dstpad - link->dst->input_pads;
>
> -av_log(link->dst, AV_LOG_INFO, "auto-inserting filter '%s' "
> +av_log(link->dst, AV_LOG_VERBOSE, "auto-inserting filter '%s' "
> "between the filter '%s' and the filter '%s'\n",
> filt->name, link->src->name, link->dst->name);

How unsurprising.

Sorry for being right, Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[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 wonder now who changed it...)

commit 1a49a169eb74a978eb7b2a4f2caf3520b7741ee5
Author: Anton Khirnov 
Date:   2012-06-25 06:31:38 +0200

lavfi: make filters less verbose.

[...]
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index b550169468..dc828153f9 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -101,7 +101,7 @@ int avfilter_insert_filter(AVFilterLink *link, 
AVFilterContext *filt,
 int ret;
 unsigned dstpad_idx = link->dstpad - link->dst->input_pads;
 
-av_log(link->dst, AV_LOG_INFO, "auto-inserting filter '%s' "
+av_log(link->dst, AV_LOG_VERBOSE, "auto-inserting filter '%s' "
"between the filter '%s' and the filter '%s'\n",
filt->name, link->src->name, link->dst->name);
 
Restoring the verbosity would probably be a good idea. You may want to
review the rest of the changes in this patch.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

[Paul B Mahol]

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 instead of packed rgb, this is already documented
 implicitly.
>>> Wow, "documented implicitly". This is such a classic FFmpeg project
>>> statement. The role of documentation is to explain, explicitly, at a
>>> suitable level of detail. What does "documented implicitly" even mean?
>>>
>>> I think this thread points out is that FFmpeg documentation is
>>> inadequate. It is hard to prove a negative, but I suspect that the term
>>> "pixel format" is not actually defined in the FFmpeg documentation. I
>>> suspect that the statement, "Any filter can change pixel formats" is not
>>> stated either. Certainly the maskedmerge filter documentation[1] doesn't
>>> mention pixel formats at all, much less say what pixel formats the
>>> filter sets for its output.
>>>
>>> …And yet "You are deeply confused about our filters". In other words, the
>>> documentation has failed to explain to you what FFmpeg does, the project
>>> has failed to write or welcome improved documentation, you do not
>>> understand how FFmpeg works — and somehow this is your fault.
>> http://ffmpeg.org/ffmpeg-filters.html#toc-Filtergraph-syntax-1
>>
>> mention it explicitly:
>>
>> Libavfilter will automatically insert scale filters where format
>> conversion is required. It is possible to specify swscale flags for
>> those automatically inserted scalers by prepending sws_flags=flags; to
>> the filtergraph description.
>
>
> This continues to be a great example of the FFmpeg project's approach to
> documentation.
>
> 1. A sentence about a library adding functional processing steps ("scale
> filters") in buried in a section entitled "syntax", amid paragraphs
> about syntax.
>
> 2. the "scale filters" name alludes to changing pixel counts, and the
> linked-to filter documentation[2] talks about "(resize) the input video"
> and about "the input image format" (without defining that term); it does
> not have a parameter for pixel formats or document the pixel formats it
> uses or sets or changes.
>
> 3. this reference to "scale filters" is supposed to be responsive to a
> thread about pixel formats.
>
> 4. no acknowledgement that the documentation might actually be less than
> perfect. Is it so hard to concede, "you have a point, the docs could be
> better here"?
>
> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
> [2] http://ffmpeg.org/ffmpeg-filters.html#scale


Well than sentence needs to be completely rewritten since we have
audio support too.

>
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

[Jim DeLaHunt]

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
implicitly.

Wow, "documented implicitly". This is such a classic FFmpeg project
statement. The role of documentation is to explain, explicitly, at a
suitable level of detail. What does "documented implicitly" even mean?

I think this thread points out is that FFmpeg documentation is
inadequate. It is hard to prove a negative, but I suspect that the term
"pixel format" is not actually defined in the FFmpeg documentation. I
suspect that the statement, "Any filter can change pixel formats" is not
stated either. Certainly the maskedmerge filter documentation[1] doesn't
mention pixel formats at all, much less say what pixel formats the
filter sets for its output.

…And yet "You are deeply confused about our filters". In other words, the
documentation has failed to explain to you what FFmpeg does, the project
has failed to write or welcome improved documentation, you do not
understand how FFmpeg works — and somehow this is your fault.

http://ffmpeg.org/ffmpeg-filters.html#toc-Filtergraph-syntax-1

mention it explicitly:

Libavfilter will automatically insert scale filters where format
conversion is required. It is possible to specify swscale flags for
those automatically inserted scalers by prepending sws_flags=flags; to
the filtergraph description.



This continues to be a great example of the FFmpeg project's approach to 
documentation.


1. A sentence about a library adding functional processing steps ("scale 
filters") in buried in a section entitled "syntax", amid paragraphs 
about syntax.


2. the "scale filters" name alludes to changing pixel counts, and the 
linked-to filter documentation[2] talks about "(resize) the input video" 
and about "the input image format" (without defining that term); it does 
not have a parameter for pixel formats or document the pixel formats it 
uses or sets or changes.


3. this reference to "scale filters" is supposed to be responsive to a 
thread about pixel formats.


4. no acknowledgement that the documentation might actually be less than 
perfect. Is it so hard to concede, "you have a point, the docs could be 
better here"?


[1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
[2] http://ffmpeg.org/ffmpeg-filters.html#scale


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Carl Eugen Hoyos]

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 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...)

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Compression is a lot smaller

[Carl Eugen Hoyos]

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 does not), size is by itself
no useful metric for any modern video codec (modern: Anything
since the early nineties). The oldest "modern" video codec (from
1991) can easily produce significantly smaller files.
Only if you take file size and quality together can you get a metric
that may make sense. Note that only subjective blind tests are
really meaningful, everything automated (like SSIM and PSNR)
does not measure what the human eye sees - but is probably
better than no quality metric at all.
A particular quality setting at encoding time does not give you a
particular comparable quality of the output file.

And just to repeat what was already written:
FFmpeg does not compress in your command line, x264 does
the compression.

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Paul B Mahol]

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

 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

 rem  Create a mergemap file 600x300

 c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
 "format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"

 -frames 1 -y mergemap.png

 rem  Stitch two fisheye videos together to an equirectangular video,
 with merging at the border

 c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
 "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"

 -y out.mp4


 This works fine and the output video looks as expected. My question is
 why "format=rgb24" is required between "maskedmerge" and
 "format=yuv422p". Normally two consecutive format conversions should
 be unnecessary. But it doesn't work when I omit "format=rgb24". The
 colors become wrong.
>>> It seems that v360 and maskedmerge change the pixel format from rgb24 to
>>> the planar gbrp pixel format.
>>> But why isn't it possible to convert gbrp directly to yuv422p, without
>>> an intermediate conversion to rgb24? Is this a bug?
>>>
>>> I suggest to add to the documentation that v360 and maskedmerge (and
>>> possibly also other filters) change the pixel format to gbrp. As a user
>>> I was assuming that the pixel format remains the same, unless noted
>>> otherwise in the documentation.
>> 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.
>
> It would be very helpful to find in the documentation for each filter a
> list of the accepted input pixel formats, and it's also a useful
> information if a filter is capable of changing the pixel format. Or can
> all filters change the pixel format?
>
>> Your mergemap is produced in rgb24 pixel format and it only work with
>> rgb pixel formats otherwise you get wrong output from maskedmerge.
>
> OK, understood. I converted the mergemap to gbrp and now it works fine.
> In my opinion the whole thing is badly documented.

If input is in yuv422p that you want to be filtered than mergemap
needs to be in yuv422p too.

> On one hand, the filter does automatically change the first two inputs
> to a format that it accepts, in this case gbrp.
> On the other hand, the filter is unable to automatically change the
> third input to the same pixel format, which is the only pixel format
> that works.
>
> Do you agree that this is the correct workflow?
> 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.
It may be to spammy with unrelated messages from other components.

There is patch in preparation to disable all auto conversions in filtergraph,
than you are on your own to fix any issues if you enable such flag.

> 2. Insert a format conversion in the filter chain that converts the
> mergemap to the same pixel format as found in step 1.

That is useful only when you disable auto conversion with flag that
gonna be added (I hope soon) to lavfi.

>
> Michael
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Carl Eugen Hoyos]

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
> "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
> -y out.mp4
>
>
> This works fine and the output video looks as expected. My
> question is why "format=rgb24" is required

I believe it was already explained why it really is required in this case.

Also important to mention imo is that in general, the automatic pix_fmt
conversion cannot always succeed, the system as a whole is not and
cannot be clairvoyant.
Therefore, for a sufficiently complex filter-chain, you have to force
conversions with format because without it, the conversion decisions
may be wrong (or at least not optimal).

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

[Paul B Mahol]

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 implicitly". This is such a classic FFmpeg project
> statement. The role of documentation is to explain, explicitly, at a
> suitable level of detail. What does "documented implicitly" even mean?
>
> I think this thread points out is that FFmpeg documentation is
> inadequate. It is hard to prove a negative, but I suspect that the term
> "pixel format" is not actually defined in the FFmpeg documentation. I
> suspect that the statement, "Any filter can change pixel formats" is not
> stated either. Certainly the maskedmerge filter documentation[1] doesn't
> mention pixel formats at all, much less say what pixel formats the
> filter sets for its output.
>
> I have attempted to improve the documentation, to make it explain
> explicitly instead of fail to document. I encountered a great deal of
> resistance to those patches, because they make the documentation more
> explicit, because they have more words, and because documentation has so
> little value in this project relative to executable code.
>
> And yet "You are deeply confused about our filters". In other words, the
> documentation has failed to explain to you what FFmpeg does, the project
> has failed to write or welcome improved documentation, you do not
> understand how FFmpeg works — and somehow this is your fault.

http://ffmpeg.org/ffmpeg-filters.html#toc-Filtergraph-syntax-1

mention it explicitly:

Libavfilter will automatically insert scale filters where format
conversion is required. It is possible to specify swscale flags for
those automatically inserted scalers by prepending sws_flags=flags; to
the filtergraph description.

>
> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
>
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

[Jim DeLaHunt]

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 
statement. The role of documentation is to explain, explicitly, at a 
suitable level of detail. What does "documented implicitly" even mean?


I think this thread points out is that FFmpeg documentation is 
inadequate. It is hard to prove a negative, but I suspect that the term 
"pixel format" is not actually defined in the FFmpeg documentation. I 
suspect that the statement, "Any filter can change pixel formats" is not 
stated either. Certainly the maskedmerge filter documentation[1] doesn't 
mention pixel formats at all, much less say what pixel formats the 
filter sets for its output.


I have attempted to improve the documentation, to make it explain 
explicitly instead of fail to document. I encountered a great deal of 
resistance to those patches, because they make the documentation more 
explicit, because they have more words, and because documentation has so 
little value in this project relative to executable code.


And yet "You are deeply confused about our filters". In other words, the 
documentation has failed to explain to you what FFmpeg does, the project 
has failed to write or welcome improved documentation, you do not 
understand how FFmpeg works — and somehow this is your fault.


[1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] How to have a secure UDP BroadCast

[Carl Zwanzig]

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
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

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
c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
yellow.mp4

rem  Create a mergemap file 600x300

c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
"format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"

-frames 1 -y mergemap.png

rem  Stitch two fisheye videos together to an equirectangular video,
with merging at the border

c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
"[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"

-y out.mp4


This works fine and the output video looks as expected. My question is
why "format=rgb24" is required between "maskedmerge" and
"format=yuv422p". Normally two consecutive format conversions should
be unnecessary. But it doesn't work when I omit "format=rgb24". The
colors become wrong.

It seems that v360 and maskedmerge change the pixel format from rgb24 to
the planar gbrp pixel format.
But why isn't it possible to convert gbrp directly to yuv422p, without
an intermediate conversion to rgb24? Is this a bug?

I suggest to add to the documentation that v360 and maskedmerge (and
possibly also other filters) change the pixel format to gbrp. As a user
I was assuming that the pixel format remains the same, unless noted
otherwise in the documentation.

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.


It would be very helpful to find in the documentation for each filter a 
list of the accepted input pixel formats, and it's also a useful 
information if a filter is capable of changing the pixel format. Or can 
all filters change the pixel format?



Your mergemap is produced in rgb24 pixel format and it only work with
rgb pixel formats otherwise you get wrong output from maskedmerge.


OK, understood. I converted the mergemap to gbrp and now it works fine.
In my opinion the whole thing is badly documented.
On one hand, the filter does automatically change the first two inputs 
to a format that it accepts, in this case gbrp.
On the other hand, the filter is unable to automatically change the 
third input to the same pixel format, which is the only pixel format 
that works.


Do you agree that this is the correct workflow?
1. Insert a showinfo filter after maskedmerge and check the pixel format.
2. Insert a format conversion in the filter chain that converts the 
mergemap to the same pixel format as found in step 1.


Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] SSL/TLS support for proxy CLI

[Pan_1337]

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 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.
>
> Regards,
> Moritz
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[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
>> c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
>> yellow.mp4
>>
>> rem  Create a mergemap file 600x300
>>
>> c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
>> "format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"
>>
>> -frames 1 -y mergemap.png
>>
>> rem  Stitch two fisheye videos together to an equirectangular video,
>> with merging at the border
>>
>> c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
>> "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
>>
>> -y out.mp4
>>
>>
>> This works fine and the output video looks as expected. My question is
>> why "format=rgb24" is required between "maskedmerge" and
>> "format=yuv422p". Normally two consecutive format conversions should
>> be unnecessary. But it doesn't work when I omit "format=rgb24". The
>> colors become wrong.
>
> It seems that v360 and maskedmerge change the pixel format from rgb24 to
> the planar gbrp pixel format.
> But why isn't it possible to convert gbrp directly to yuv422p, without
> an intermediate conversion to rgb24? Is this a bug?
>
> I suggest to add to the documentation that v360 and maskedmerge (and
> possibly also other filters) change the pixel format to gbrp. As a user
> I was assuming that the pixel format remains the same, unless noted
> otherwise in the documentation.

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.
Your mergemap is produced in rgb24 pixel format and it only work with
rgb pixel formats otherwise you get wrong output from maskedmerge.
If it does not work with yuv444p pixel formats either than you have
bigger problem, otherwise it is giving bad output as yuv422p is
subsampled pixel format and thus you need to create different mergemap
equation per plane. As for 3rd and 2nd plane of yuv422p pixel format
have half of width and same height as first plane.

>
> Michael
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Latency in UDP to HLS Conversion

[KRISHNAKUMAR N K]

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 4.3 Copyright (c) 2000-2020 the FFmpeg developers  built
with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-36)  configuration:
--prefix=/root/ffmpeg-4.3/ffmpeg_build --pkg-config-flags=--static
--extra-cflags='-I/root/ffmpeg-4.3/ffmpeg_build/include
-I/usr/local/cuda/include'
--extra-ldflags='-L/root/ffmpeg-4.3/ffmpeg_build/lib
-L/usr/local/cuda/lib64' --extra-libs=-lpthread --extra-libs=-lm
--bindir=/root/ffmpeg-4.3/bin --enable-gpl --enable-libfdk_aac
--enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvpx
--enable-libx264 --enable-libx265 --enable-cuda --enable-cuvid
--enable-nvenc --enable-libnpp --enable-nonfree --enable-openssl  libavutil
 56. 51.100 / 56. 51.100  libavcodec 58. 91.100 / 58. 91.100
libavformat58. 45.100 / 58. 45.100  libavdevice58. 10.100 / 58.
10.100  libavfilter 7. 85.100 /  7. 85.100  libswscale  5.  7.100 /
 5.  7.100  libswresample   3.  7.100 /  3.  7.100  libpostproc55.
 7.100 / 55.  7.100*

Below is the ffmpeg command that i am using. Any help would be appreciated.






*ffmpeg -i "udp://230.1.1.15:1?fifo_size=1000&overrun_nonfatal=1
"
-analyzeduration 25M -probesize 50M -threads 0 -vsync 1 -filter_complex
"[i:0xd49]yadif[vout];[vout]split=4[out0][out1][out2][out3];[out0]setdar=16/9[v0];[out1]setdar=16/9[v1];[out2]setdar=16/9[v2];[out3]setdar=16/9[v3];[i:0xd4a]aresample=async=1:min_hard_comp=0.10:first_pts=0[aout];[aout]asplit=4[a0][a1][a2][a3]"
\-vcodec libx264 -s:v:0 256x144 -tune film -r:v:0 25 -b:v:0 10
-maxrate:v:0 10 -minrate:v:0 10 -bufsize:v:0 20 -acodec
libfdk_aac -ar:0 48000 -b:a:0 48000 -sc_threshold 0 -pix_fmt yuv420p -flags
+global_header+cgop -profile:v:0 baseline -level:v:0 3.0 -preset fast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v0] -map [a0] \-vcodec libx264
-s:v:1 512x288 -tune film -r:v:1 25 -b:v:1 20 -maxrate:v:1 20
-minrate:v:1 20 -bufsize:v:1 40 -acodec libfdk_aac -ar:1 48000
-b:a:1 48000 -sc_threshold 0 -pix_fmt yuv420p -flags +global_header+cgop
-profile:v:1 baseline -level:v:1 3.0 -preset fast -nal-hrd cbr -keyint_min
50 -g 50 -map [v1] -map [a1] \-vcodec libx264 -s:v:2 640x360 -tune film
-r:v:2 25 -b:v:2 70 -maxrate:v:2 70 -minrate:v:2 70
-bufsize:v:2 140 -acodec libfdk_aac -ar:2 48000 -b:a:2 48000
-sc_threshold 0 -pix_fmt yuv420p -flags +global_header+cgop -profile:v:2
main -level:v:2 3.1 -preset fast -nal-hrd cbr -keyint_min 50 -g 50 -map
[v2] -map [a2] \-vcodec libx264 -s:v:3 1280x720 -tune film -r:v:3 25 -b:v:3
100 -maxrate:v:3 100 -minrate:v:3 100 -bufsize:v:3 200
-acodec libfdk_aac -ar:3 48000 -b:a:3 48000 -sc_threshold 0 -pix_fmt
yuv420p -flags +global_header+cgop -profile:v:3 high -level:v:3 4.0 -preset
fast -nal-hrd cbr -keyint_min 50 -g 50 -map [v3] -map [a3] \-f hls
-var_stream_map "a:0,v:0,name:148k a:1,v:1,name:248k a:2,v:2,name:764k
a:3,v:3,name:1064k" -master_pl_name master.m3u8 -hls_list_size 3 -hls_time
6 -method PUT -ignore_io_errors 1 -hls_segment_filename
https://usr:p...@example.com:8043/httppush/media_%v_%03d.ts -hls_flags
delete_segments+independent_segments+discont_start
https://usr:p...@example.com:8043/httppush/playlist_%v.m3u8*

Regards

*KrishnaKumar **N K *
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] libx265 a lot slower

[Moritz Barsnick]

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 need to
switch to a Jeep, because it can pull your trailer out of the mud", do
you buy a Jeep? ;-)

I'm trying to say: Try to understand the benefits and the
disadvantages, and check against your requirements.

Do you need less space? Are you willing to sacrifice encoding speed? Is
H.265 the right codec for your type of videos? As Mick Finn pointed
out, H.265 is more designed for higher resolutions and bit depths
(IIUC). Can your target players even decode H.265? (Does the Jeep even
fit into your parking spaces? Do your feet reach the pedals?)

There's no matter of "must", "need to" - just of considerations. I
believe whatever you read, implied some other details, or forgot to
tell about them.

BTW, if someone does magic hacking, or even more optimized GPUs emerge,
x265/H.265 *may* become "faster" than x264/H.264. It isn't right now.

> (what is not true, I did see 'only' a 2/3)

It depends on the material. I'm sure there are tons of comparisons out
there.

> and a few explained that you could not use h265
> everywhere, so you should evaluate if it was a good idea to switch.

Absolutely! Even if I could encode my material to H.265, I probably
wouldn't, except when targetting a very specific player (modern smart
phones?). My PVR/STB, my TV, ..., cannot decode it. Possibly even my PC
doesn't have enough compute/GPU power to decode it in full HD.

> In none of the hits I saw anything about a performance hit. Especially
> not a hit up to a factor three.

They should. ;)

Cheers,
Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Compression is a lot smaller

[Moritz Barsnick]

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 uncompressed video on storage, especially with
modern resolutions and bit-depths. The storage just cannot handle it.

So the recorder has a HW chip which does compression on the fly.

> 454 -> 415
> 503 -> 230
> 490 -> 254
> 462 -> 157
> 497 -> 197
> 454 -> 174

Assuming the camera used the same settings for each recording:
Compression results (size reduction) depend on the content as well. The
Sony may be compressing nearly static videos inefficiently, while
ffmpeg/x264 optimized those well. At the same time, Sony may be
compressing videos with movement, shakiness, or even noise, quite well,
and ffmpeg cannot improve on that.

This is just speculation, but could be an explanation.

It might be interesting to look at the original and resulting
bandwidths as well (i.e. video size in relation to duration).

Cheers,
Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] UDP NVENC HEVC transcoding#

[Leonardo Pagotto]

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:
>
> What feeling is that? Faster, higher quality, just more efficient?
>
> > ffmpeg -vsync 0 -hwaccel cuvid -c:v h264_cuvid -resize 1280x720
> > -drop_second_field 1 -i udp://
> > 230.8.0.7:10008?buffer_size=300?fifo_size=100&overrun_nonfatal=1
> > -crf 30 -c:a -c:v hevc_nvenc -profile:v main -pass 2 -rc vbr -maxrate 3M
> -f
> > mpegts udp://239.210.210.7:1234?pkt_size=1316&localaddr=10.10.71.55
>
> I don't think this is a working command line.
> - "-c:a -c:v hevc_nvenc" is missing something.
> - "-pass 2" is for multipass encoding, right? Does that make sense with
> UDP to
>   UDP encoding?
>
> I don't know anything about cuvid on nvenc usage, so I can't actually
> help you with that. ;)
>
> (I also recommend chacking out presets before manually tweaking
> parameters, unless you already know what you want to achieve.)
>
> Moritz
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] SSL/TLS support for proxy CLI

[Moritz Barsnick]

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.

Regards,
Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] UDP NVENC HEVC transcoding#

[Moritz Barsnick]

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 -vsync 0 -hwaccel cuvid -c:v h264_cuvid -resize 1280x720
> -drop_second_field 1 -i udp://
> 230.8.0.7:10008?buffer_size=300?fifo_size=100&overrun_nonfatal=1
> -crf 30 -c:a -c:v hevc_nvenc -profile:v main -pass 2 -rc vbr -maxrate 3M -f
> mpegts udp://239.210.210.7:1234?pkt_size=1316&localaddr=10.10.71.55

I don't think this is a working command line.
- "-c:a -c:v hevc_nvenc" is missing something.
- "-pass 2" is for multipass encoding, right? Does that make sense with UDP to
  UDP encoding?

I don't know anything about cuvid on nvenc usage, so I can't actually
help you with that. ;)

(I also recommend chacking out presets before manually tweaking
parameters, unless you already know what you want to achieve.)

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] How to have a secure UDP BroadCast

[Moritz Barsnick]

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 the original
> question?

The original question mentions "broadcast", but in the sense which we
understand? There's neither "-broadcast" on the command line, nor does
the UDP URI specify a broadcast IPv4 address - it's a unicast command
line.

Perhaps the original poster meant "broadcast" in the sense of
"sending"?

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] How to have a secure UDP BroadCast

[Nicolas George]

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
Description: PGP signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] How to have a secure UDP BroadCast

[Alessandro Molon]

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 of latency like other authenticated protocols like RTMP or HLS.

Alex

-Original Message-
From: ffmpeg-user  On Behalf Of Dennis Mungai
Sent: 19 August 2020 10:05
To: FFmpeg user questions 
Subject: Re: [FFmpeg-user] How to have a secure UDP BroadCast

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-
> From: ffmpeg-user  On Behalf Of hassan 
> shatnawi
> Sent: 02 October 2017 09:12
> To: ffmpeg-user@ffmpeg.org
> Subject: [FFmpeg-user] How to have a secure UDP BroadCast
>
> Dears,
>
> How to have a secure connection with username and password while 
> broadcasting "UPD"
>
> I've use this command
>
> ffmpeg -f dshow -video_size 1280x720 -rtbufsize 702000K -framerate 30 
> -i video="Video (00-0 Pro Capture Quad HDMI)" -r 30 -threads 4 -vcodec
> libx264 -crf 0 -preset ultrafast -f mpegts "udp:// 
> username:password@192.168.1.12:"
>
> but it didn't work can you advice me plz.
>
> Thanks in advance.
>
> *Hassan Shatnawi*
> Software Developer
>
> *Software Development Department*
>
>
>
> *Haupshy Establishment for Electronics*
>
> Al Madina Al Monawara St. bld 31 | P.O.Box 6875 Amman 8, Jordan.
>
> *T: *+962 6 5820 927* | F: *+962 6 5820 926* | M: *+962 78 5792 096
>
> *E*: has...@haupshy.com *|* www.haupshy.com 
> ___
>


The closest there is to your requirements, ie:

(a). A container format with support for timestamps such as mpegts

(b). Capabilities similar to UDP

Would be Haivision's SRT, which FFmpeg supports if enabled on build time via 
--enable-libsrt.

SRT allows for optional encryption, whose details can be viewed via ffmpeg -h 
protocol=srt.

Note that depending on your application requirements, you'll need to ensure 
that your receiver can handle SRT input, OR use FFmpeg to handle SRT TX and Rx 
in the network segment where such content security is desired.

Hope that helps.

>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with 
subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] How to have a secure UDP BroadCast

[Dennis Mungai]

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-
> From: ffmpeg-user  On Behalf Of hassan
> shatnawi
> Sent: 02 October 2017 09:12
> To: ffmpeg-user@ffmpeg.org
> Subject: [FFmpeg-user] How to have a secure UDP BroadCast
>
> Dears,
>
> How to have a secure connection with username and password while
> broadcasting "UPD"
>
> I've use this command
>
> ffmpeg -f dshow -video_size 1280x720 -rtbufsize 702000K -framerate 30 -i
> video="Video (00-0 Pro Capture Quad HDMI)" -r 30 -threads 4 -vcodec
> libx264 -crf 0 -preset ultrafast -f mpegts "udp://
> username:password@192.168.1.12:"
>
> but it didn't work can you advice me plz.
>
> Thanks in advance.
>
> *Hassan Shatnawi*
> Software Developer
>
> *Software Development Department*
>
>
>
> *Haupshy Establishment for Electronics*
>
> Al Madina Al Monawara St. bld 31 | P.O.Box 6875 Amman 8, Jordan.
>
> *T: *+962 6 5820 927* | F: *+962 6 5820 926* | M: *+962 78 5792 096
>
> *E*: has...@haupshy.com *|* www.haupshy.com
> ___
>


The closest there is to your requirements, ie:

(a). A container format with support for timestamps such as mpegts

(b). Capabilities similar to UDP

Would be Haivision's SRT, which FFmpeg supports if enabled on build time
via --enable-libsrt.

SRT allows for optional encryption, whose details can be viewed via ffmpeg
-h protocol=srt.

Note that depending on your application requirements, you'll need to ensure
that your receiver can handle SRT input, OR use FFmpeg to handle SRT TX and
Rx in the network segment where such content security is desired.

Hope that helps.

>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] How to have a secure UDP BroadCast

[Alessandro Molon]

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 09:12
To: ffmpeg-user@ffmpeg.org
Subject: [FFmpeg-user] How to have a secure UDP BroadCast

Dears,

How to have a secure connection with username and password while broadcasting 
"UPD"

I've use this command

ffmpeg -f dshow -video_size 1280x720 -rtbufsize 702000K -framerate 30 -i 
video="Video (00-0 Pro Capture Quad HDMI)" -r 30 -threads 4 -vcodec
libx264 -crf 0 -preset ultrafast -f mpegts 
"udp://username:password@192.168.1.12:"

but it didn't work can you advice me plz.

Thanks in advance.

*Hassan Shatnawi*
Software Developer

*Software Development Department*



*Haupshy Establishment for Electronics*

Al Madina Al Monawara St. bld 31 | P.O.Box 6875 Amman 8, Jordan.

*T: *+962 6 5820 927* | F: *+962 6 5820 926* | M: *+962 78 5792 096

*E*: has...@haupshy.com *|* www.haupshy.com 
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with 
subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

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


rem  Create a mergemap file 600x300

c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf 
"format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24" 
-frames 1 -y mergemap.png


rem  Stitch two fisheye videos together to an equirectangular video, 
with merging at the border


c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi 
"[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p" 
-y out.mp4



This works fine and the output video looks as expected. My question is 
why "format=rgb24" is required between "maskedmerge" and 
"format=yuv422p". Normally two consecutive format conversions should 
be unnecessary. But it doesn't work when I omit "format=rgb24". The 
colors become wrong.


It seems that v360 and maskedmerge change the pixel format from rgb24 to 
the planar gbrp pixel format.
But why isn't it possible to convert gbrp directly to yuv422p, without 
an intermediate conversion to rgb24? Is this a bug?


I suggest to add to the documentation that v360 and maskedmerge (and 
possibly also other filters) change the pixel format to gbrp. As a user 
I was assuming that the pixel format remains the same, unless noted 
otherwise in the documentation.


Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".