Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: add hls_flag option to write segments to temporary file until complete

[Steven Liu]

2017-02-05 23:09 GMT+08:00 Steven Liu :

>
>
> 2017-02-05 4:38 GMT+08:00 Bodecs Bela :
>
>>
>>
>> 2017.02.04. 20:45 keltezéssel, Hendrik Leppkes írta:
>>
>>> On Sat, Feb 4, 2017 at 6:55 PM, Aman Gupta  wrote:
>>>
 From: Aman Gupta 

 Adds a `-hls_flags +temp_file` which will write segment data to
 filename.tmp, and then rename to filename when the segment is complete.

 This patch is similar in spirit to one used in Plex's ffmpeg fork, and
 allows a transcoding webserver to ensure incomplete segment files are
 never served up accidentally.

>>> Wouldnt a segment only show up in the playlist when its finished? How
>>> can they be served accidentally?
>>>
>> the segment file names are predictable.
>> In live streaming enviroment somebody predicting the segment name may see
>> the program some seconds earlier than any other viewer by downloading
>> continously the unpublished segment. (with one segment duration seconds
>> earlier)
>> if the currently writed segment name is constant you may prohibit to
>> acces it in web server config
>>
>> - Hendrik
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
> will push after 24 hours
>

Pushed!



Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)

[Michael Niedermayer]

On Mon, Feb 06, 2017 at 10:51:30AM +0100, u-9...@aetey.se wrote:
> On Thu, Feb 02, 2017 at 05:19:16PM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 02, 2017 at 04:22:28PM +0100, u-9...@aetey.se wrote:
> > > On Thu, Feb 02, 2017 at 01:31:00PM +0100, Michael Niedermayer wrote:
> > patch applied
> > 
> > thx
> 
> Thanks Michael.
> 
> What about the other patches from that series?

> 
> The second one is purely cosmetic (looks useful to me but not much
> of concern)

I have no oppinion about // vs /**/ comments but in the absence of
a reason to change them my gut feeling leans toward leaving things
as they are for "git blame" simplification.

A reason would be consistency or the preferrance of the people
working on the code or maintaining it or the authors preferrance, ...


> while the third (tiny) one is about correcting an inverted
> explanation in a comment.

I think the 3rd depends on the 2nd

another point which was brought up by jb on IRC and in RL longer ago
was that ideally the author field in git should contain a name.

It may help with contacting one in the far future or with simply
refering to the author as in
who wrote the cinepack optimizations?
Author: addr-see-the-webs...@aetey.se 
is a bit cumbersome but its not mine to judge that. If you want
that in the author field, thats ok as far as iam concerned, i just
have difficulty imagening that being intended over a pronouncable
name (even if thats a pseudonym) before 

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/internal: Expand the documentation for FF_CODEC_CAP_INIT_THREADSAFE

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/internal.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index c92dba472a..a72f8628db 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -36,6 +36,15 @@
 /**
  * The codec does not modify any global variables in the init function,
  * allowing to call the init function without locking any global mutexes.
+ * If this is not set, the core code uses the lock manager registered with
+ * av_lockmgr_register() or the default fallback to protect codec init.
+ *
+ * Using a per codec lock is more efficient than using one for all codecs to
+ * provide thread saftey as the locking happens at finer granularity during
+ * one time initilization.
+ *
+ * @Note, with or without this flag the public codec init/decode/encode/... 
API is
+ * threadsafe.
  */
 #define FF_CODEC_CAP_INIT_THREADSAFE(1 << 0)
 /**
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] h264 bitstream corruption in videotoolbox encoder with a53cc=1

[Aman Gupta]

Last October, kernrj and I commited a series of patches to add a53cc
support to the videotoolbox encoder.

In using that feature over the past few months, I've discovered that the
generated streams can sometimes contain random/intermittent errors. This
only appears to occur on some Macs and not others.

These corrupted files cause errors when used with any of Apple's decoders,
including Safari, Quicktime, and mediastreamvalidator. The file can be
decoded with ffmpeg, although it prints out the following error when
encountering the corruption:

[NULL @ 0x7fbcce800600] sps_id 32 out of range
[h264 @ 0x7fbcd000] sps_id 32 out of range

Here are two sequential sample segments generated by the videotoolbox
encoder (when used with -f hls). They were generated one after the other
from the same source; the first is fine, but the second contains the
corruption.

https://s3.amazonaws.com/tmm1/stream57.ts
https://s3.amazonaws.com/tmm1/stream58.ts

I'd like to fix this bug, but have been stuck trying to narrow it down.
Hoping someone can point me in the right direction.

Aman
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [rfc] tasks for new ffmpeg developers

[James Almer]

On 2/6/2017 2:54 AM, Compn wrote:
> people new to the project join #ffmpeg-devel and ask us for help on how
> to start contributing to ffmpeg.
> 
> usually none of us have any cohesive answers. mostly suggestions are to
> review bugs or patches or code. nothing really concise or organized.
> 
> i've reviewed a few bugs and think these may be good starting points
> for new developers to try. they might also be useful for qualification
> tasks in the future? i dont know.
> 
> i'm not sure how to organize these, maybe a trac keyword? for now ,
> i'll just post them here. if you have comments, suggestions, or just
> want to tell me that my idea is bad, please speak up.
> 
> 
> these have specs / open source implementations:
> 
> https://trac.ffmpeg.org/ticket/5285
> Missing subtitle format. ISMT (xml based)
> 
> https://trac.ffmpeg.org/ticket/4728
> support DICOM format (medical jpg image)
> 
> https://trac.ffmpeg.org/ticket/1959
> Support codec2 (os audio codec)
> 
> https://trac.ffmpeg.org/ticket/2377
> Support lossless mp3HD (abandoned? lossless audio codec)

https://trac.ffmpeg.org/ticket/2439
allow to copy latm aac to raw aac without reencoding audio (Bitstream filter).

https://trac.ffmpeg.org/ticket/4169
Support BPG Image format

https://trac.ffmpeg.org/ticket/4490
Add a bitstream filter to strip the ATMOS substream from TrueHD

All of them can be done reusing existing code in libavcodec, or at least
have open source implementations.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov, matroskadec : Allow matroskadec & mov to share spherical parsing logic.

[Michael Niedermayer]

On Mon, Feb 06, 2017 at 09:59:58PM +, Aaron Colwell wrote:
> - Extracts common spherical metadata parsing logic.
> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
>   are accepted.

>  Makefile|5 ++-
>  matroskadec.c   |   39 ++--
>  mov.c   |   35 ++---
>  mov_spherical.c |   78 
> 
>  mov_spherical.h |   61 +++
>  5 files changed, 182 insertions(+), 36 deletions(-)
> ebec975d2645e6cde0902b8a966545617fc420dc  
> 0001-mov-matroskadec-Allow-matroskadec-mov-to-share-spher.patch
> From 218dfd7ca1924bc44a168b34ec3c07051823c2dc Mon Sep 17 00:00:00 2001
> From: Aaron Colwell 
> Date: Mon, 6 Feb 2017 13:48:58 -0800
> Subject: [PATCH] mov,matroskadec : Allow matroskadec & mov to share spherical
>  parsing logic.
> 
> - Extracts common spherical metadata parsing logic.
> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
>   are accepted.
> ---
>  libavformat/Makefile|  5 +--
>  libavformat/matroskadec.c   | 39 ---
>  libavformat/mov.c   | 35 +++-
>  libavformat/mov_spherical.c | 78 
> +
>  libavformat/mov_spherical.h | 61 +++
>  5 files changed, 182 insertions(+), 36 deletions(-)
>  create mode 100644 libavformat/mov_spherical.c
>  create mode 100644 libavformat/mov_spherical.h

breaks fate-h264-direct-bff
TESTh264-direct-bff
--- ./tests/ref/fate/h264-direct-bff2017-02-06 12:12:00.827925330 +0100
+++ tests/data/fate/h264-direct-bff 2017-02-07 01:54:38.584965163 +0100
@@ -1,16 +0,0 @@
-#tb 0: 1001/3
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 720x484
-#sar 0: 1/1
-0,  0,  0,1,   522720, 0x1ccad503
-0,  1,  1,1,   522720, 0xd266d6e8
-0,  2,  2,1,   522720, 0x535473b3
-0,  3,  3,1,   522720, 0xf8b53c53
-0,  4,  4,1,   522720, 0x4e4cc04b
-0,  5,  5,1,   522720, 0x20ea3515
-0,  6,  6,1,   522720, 0xb9c67e30
-0,  7,  7,1,   522720, 0x03d2e35a
-0,  8,  8,1,   522720, 0xae2e7896
-0,  9,  9,1,   522720, 0x6da37f41
-0, 12, 12,1,   522720, 0x7caf4954
Test h264-direct-bff failed. Look at tests/data/fate/h264-direct-bff.err for 
details.
make: *** [fate-h264-direct-bff] Error 1
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [rfc] tasks for new ffmpeg developers

[Compn]

On Mon, 06 Feb 2017 13:22:31 +, Kieran Kunhya 
wrote:

> On Mon, 6 Feb 2017 at 05:54 Compn  wrote:
> 
> > people new to the project join #ffmpeg-devel and ask us for help on how
> > to start contributing to ffmpeg.
> >
> 
> A simple one is work on making decoders threadsafe (pthread_once on static
> inits).

can you (or someone) come up with a simple starter howto and some
doc or description for what exactly needs to be done? maybe is there a
commit to a decoder showing what was done to make it threadsafe?

the howto would detail how to test for threadsafe , what tools to use,
what an unsafe thread does or looks like in valgrind or gdb etc?
showing devs to use AVOnce and list other ff/av functions to fix unsafe
code.

grep FF_CODEC_CAP_INIT_THREADSAFE * to get the list of codecs that are
thread safe. the rest need to be done, in order of useful codecs first?

i'm not saying we have to hold everyones hand, but a little
documentation, direction and clarity will go a LONG way in getting
things worked on. :)

i know the ffmpeg devs can do all of this in their sleep, backwards.
but if you take the time to write down the steps you take, just
once, maybe someone will read, learn and come to contribute.

i found these quick posts about threadsafe code, maybe they help
the curious. or maybe they arent applicable to ffmpeg at all.

https://insights.sei.cmu.edu/sei_blog/2014/10/thread-safety-analysis-in-c-and-c.html
http://www.thegeekstuff.com/2012/07/c-thread-safe-and-reentrant/
http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/

thank you
-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v2]

[Michael Niedermayer]

On Tue, Feb 07, 2017 at 06:28:11AM +0900, Takayuki 'January June' Suwa wrote:
> This adds "-profile[:v] profile_name"-style option IOW.
> 
> Thanks for reviewing my poor ugly patch, Mark...  and I get back to
> an original purpose - forcing OMX to use baseline profile.
> (eg. RasPiCam-to-Ustream webcasting w/o additional xcoding)
> ---
>  libavcodec/omx.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/libavcodec/omx.c b/libavcodec/omx.c
> index 16df50e..faa70ae 100644
> --- a/libavcodec/omx.c
> +++ b/libavcodec/omx.c
> @@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
>  int output_buf_size;
> 
>  int input_zerocopy;
> +int profile;
>  } OMXCodecContext;
> 
>  static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
> @@ -523,6 +524,20 @@ static av_cold int
> omx_component_init(AVCodecContext *avctx, const char *role)
>  CHECK(err);
>  avc.nBFrames = 0;
>  avc.nPFrames = avctx->gop_size - 1;
> +switch (s->profile) {
> +case FF_PROFILE_H264_BASELINE:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
> +break;
> +case FF_PROFILE_H264_MAIN:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileMain;
> +break;
> +case FF_PROFILE_H264_HIGH:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileHigh;
> +break;
> +}
>  err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, );
>  CHECK(err);
>  }
> @@ -884,6 +899,10 @@ static const AVOption options[] = {
>  { "omx_libname", "OpenMAX library name", OFFSET(libname),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
>  { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },

There are some extraneous newlines in the patch which cause git am
to fail
"error: corrupt patch at line 18"

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v2]

[Takayuki 'January June' Suwa]

This adds "-profile[:v] profile_name"-style option IOW.

Thanks for reviewing my poor ugly patch, Mark...  and I get back to an 
original purpose - forcing OMX to use baseline profile.

(eg. RasPiCam-to-Ustream webcasting w/o additional xcoding)
---
 libavcodec/omx.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 16df50e..faa70ae 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
 int output_buf_size;

 int input_zerocopy;
+int profile;
 } OMXCodecContext;

 static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
@@ -523,6 +524,20 @@ static av_cold int 
omx_component_init(AVCodecContext *avctx, const char *role)

 CHECK(err);
 avc.nBFrames = 0;
 avc.nPFrames = avctx->gop_size - 1;
+switch (s->profile) {
+case FF_PROFILE_H264_BASELINE:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+}
 err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, );
 CHECK(err);
 }
@@ -884,6 +899,10 @@ static const AVOption options[] = {
 { "omx_libname", "OpenMAX library name", OFFSET(libname), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "zerocopy", "Try to avoid copying input frames if possible", 
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "profile",  "Set the encoding profile", OFFSET(profile), 
AV_OPT_TYPE_INT,   { .i64 = 0 },0, 
FF_PROFILE_H264_HIGH, VE, "profile" },
+{ "baseline", "", 0, 
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, 
"profile" },
+{ "main", "", 0, 
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, 
"profile" },
+{ "high", "", 0, 
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, 
"profile" },

 { NULL }
 };
--
from GitHub
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add midequalizer filter

[Calvin Walton]

Hi, just a quick note below...

On Thu, 2017-02-02 at 14:40 +0100, Paul B Mahol wrote:
> 
> +++ b/doc/filters.texi
> @@ -9643,6 +9643,17 @@ Macroblock size. Default @code{16}.
>  Search parameter. Default @code{7}.
>  @end table
>  
> +@section midequalizer
> +
> +Apply Midway Image Equalization effect using two video streams.
> +
> +This filter accepts the following option:
> +
> +@table @option
> +@item planes
> +Set which planes to process. Default is @code{15}, which is all
> available planes.
> +@end table
> 

Speaking as a user, it would be great if you can include some
information in the docs about what this filter does, or why someone
would want to use it. Something as simple as:

"Midway Image Equalization adjusts a pair of images to have the same
histogram, while maintaining their dynamics as much as possible. It's
useful for e.g. matching exposures from a pair of stereo cameras"

would help here.

Some help on how to actually use it (maybe with an example) would be
great too. For example, if the filter works by having a reference input
and an input which gets modified, it would also be good to say which
input is which. Something along the lines of:

"This input has two inputs and two outputs. The first input is used as
a reference, it is passed through unchanged. The second input has its
contrast adjusted to match that of the first input and the result is
returned on the second output."

but of course adjusted to match what the code actually does!

I don't have any comments on the code itself.

Calvin.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[Clément Bœsch]

On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote:
[...]
> > No, code quality is not outside the scope of your patch.
> 
> Code quality is a subjective matter.
> 

I'm not going to fight with you: several developers consider your patch
does not pass the quality requirements of the project. It's arbitrary,
subjective, unfair, or even wrong if you want, but that's the current
policy of the project. Changing that policy is outside the scope of this
patch.

[...]
> > The use of the environment variable is not tolerable, this is a blocker.
> 
> It is explicitly specified that it is _not_ being used,

Then please drop the dead code.

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] Allow Data URI scheme for hls

[fairytale]

#EXT-X-KEY:METHOD=AES-128,URI="data:text/plain;charset=utf-8,abcdefgh12345678",IV=0x
video-js support this and as ffurl_connect support data uri, just allow it.
---
 libavformat/hls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3ae3c7cc5c..77917f0e44 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -617,8 +617,8 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 if (!proto_name)
 return AVERROR_INVALIDDATA;
 
-// only http(s) & file are allowed
-if (!av_strstart(proto_name, "http", NULL) && !av_strstart(proto_name, 
"file", NULL))
+// only http(s) & file & data are allowed
+if (!av_strstart(proto_name, "http", NULL) && !av_strstart(proto_name, 
"file", NULL) && !av_strstart(proto_name, "data", NULL))
 return AVERROR_INVALIDDATA;
 if (!strncmp(proto_name, url, strlen(proto_name)) && 
url[strlen(proto_name)] == ':')
 ;
-- 
2.11.0.windows.1


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskaenc: Add support for writing video projection.

[Aaron Colwell]

Given this insistence on using a separate type, the fact that the "tiled
equirect" is under specified, and folks don't actually care about the
"tiled equirect" case right now could I just add code to mux the 2 cases
that are already well specified? I could also send out a patch to fix the
demuxers so they reject the "tiled equirect" cases for now. This seems like
reasonable compromise to allow end-to-end preservation of non-controversial
use cases. That is really all I'm trying to do right now.

Aaron

On Sat, Feb 4, 2017 at 7:46 AM Vittorio Giovara 
wrote:

> On Fri, Feb 3, 2017 at 5:57 PM, Aaron Colwell  wrote:
> > I still think you don't understand what these fields do given what you
> say
> > here. Yes there is a little more math. At the end of the day all these
> > fields do is specify a the min & max for the latitude & longitude. This
> > essentially translates to adding scale factors and offsets in your
> shader or
> > something similar in your 3D geometry creation logic. I get it if
> > implementations don't want to do this small bit of extra work, but saying
> > this is a different type seems strange because you wouldn't do this when
> > talking about cropped 2D images.
>
> If I don't understand these fields, maybe the specification could do a
> better job at explaining what they are for ;)
>
> I am aware that the final projection is the same, but the actual
> problem is that if we don't introduce a new type we would be conveying
> a different semantics to a single projection type. In other words we
> require applications to behave differently according to two different
> fields (the projection type and the offset fields) rather than a
> single one. So yes, the projection is the same, the usecase is
> different, the app behaviour is different, the final processing is
> different -- I think that all this warrants a separate type.
>
> If I still didn't get my point across, let's try with an example: an
> application that does not support the tiled equirectangular
> projection, with a separate type it can immediately discern that it is
> an unsupported type and inform the user, with a single type, instead,
> it has to sort-of-implement the tiling and check for fields that
> should not matter. Another example: look at AVStereo3DType, there is a
> side-by-side and a side-by-side-quincunx : an application that does
> not support quincux can just abort and notify the user, if they were
> two separate fields, you could have applications that do not support
> quincunx but try to render the side-by-side part (which usually
> results in a garbage rendering).
>
> So I reiterate that in my opinion a separate enum value which
> "notifies" apps that they should check additional types is the way to
> go.
>
> >> It is too late to change the spec, but I do believe that the usecase
> >> is different enough to add a new type, in order to not overcomplicate
> >> the implementation.
> >
> >
> > It feels like you are just moving the problem to the demuxers and muxers
> > here. Adding a new type means all demuxers will have to contain logic to
> > generate these different types and all muxers will have to contain logic
> to
> > collapse these types back down to a single value.
>
> Yes, I would a 100% add more logic to the 2 muxers and 2 demuxers that
> implement this spec rather than the thousands applications that
> implement the ffmpeg api. Also the "different logic" is literally an
> "if" case, if not little else.
>
> > I don't really want to keep arguing about this. If folks really want
> > different types then I'll do it just because I want to get reading and
> > writing of metadata working end-to-end. I'd like to make a small request
> to
> > use the term "cropped equirectagular" instead of "tiled equirectangular"
> but
> > I don't feel to strongly about that.
>
> Please don't, "cropped" has entirely different meaning, and it's
> already confusing that you can do bitstream level cropping and surface
> cropping. If you really hate the term "tiled" you could use "bounded
> equirectangular" as it is used in the spec.
>
> > I suppose this is just a difference in style so I don't feel too strongly
> > about it. I was just trying to use unions & structs here to make it a
> little
> > clearer about which fields are expected to be valid and when. The fields
> > seemed to be disjoint sets so I was trying to use language features to
> > convey that.
> >
> > I'd also like to float a potential alternative solution. We could just
> > convey the projection private data as a size and byte array in this
> struct.
> > That would allow me to pass the metadata from demuxers to muxers so I can
> > achieve my goals, and allow actual parsing of the information to be
> deferred
> > until someone needs it. How do you feel about this compromise position?
>
> Again I don't see any advantage in using your proposal, it makes the
> code difficult to read and hard to debug. Binary metadata are
> 

Re: [FFmpeg-devel] Can BSF delay packets?

[Ronald S. Bultje]

Hi Aleksey,

On Mon, Feb 6, 2017 at 12:14 PM, Aleksey M  wrote:

> Ronald,
>
> I looked the vp9_superframe_bsf.c code, but it doesn't help: The only place
> which returns EAGAIN does output packet unref and frees input packet.
>
> I tried memset zero on output packet, av_packet_unref, setting out->size =
> 0 and out->side_data_elems = 0, tried to return EAGAIN or 0, nothing helps.
> In any case, "timestamps are not set", "stream is malformed", like the
> output packet is still used.


As frustrating as this may sound, vp9_superframe_bsf does what you're
asking for, so your best bet is to emulate what it's doing and figure out
why your code does not invoke the same code path.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/h264dec: use OFFSET macro

[Matthieu Bouron]

---
 libavcodec/h264dec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 41c0964392..da34be81cc 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1072,8 +1072,8 @@ static int h264_decode_frame(AVCodecContext *avctx, void 
*data,
 #define OFFSET(x) offsetof(H264Context, x)
 #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
 static const AVOption h264_options[] = {
-{"is_avc", "is avc", offsetof(H264Context, is_avc), AV_OPT_TYPE_BOOL, 
{.i64 = 0}, 0, 1, 0},
-{"nal_length_size", "nal_length_size", offsetof(H264Context, 
nal_length_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, 0},
+{ "is_avc", "is avc", OFFSET(is_avc), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, 
0 },
+{ "nal_length_size", "nal_length_size", OFFSET(nal_length_size), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, 0 },
 { "enable_er", "Enable error resilience on damaged frames (unsafe)", 
OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
 { NULL },
 };
-- 
2.11.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format

[Maksym Veremeyenko]

Hi,

Attached patch fixes chroma positioning during scaling interlaced 4:2:0.

On a first iteration default context value been overwritten by new value 
and not been update on next iterations for fields. This mean that 
vertical chroma position remain 128 for field#0 and field#1 instead of 
*64* and *192*.


Attached patch use local variable for storing this intermediate value of 
chroma vertical position not modifying default context value.


--
Maksym Veremeyenko

From 912ecf538b6b2f7a8df4afdfed2d34052162335c Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko 
Date: Mon, 6 Feb 2017 17:03:17 +0200
Subject: [PATCH] Fix chroma positioning for 4:2:0 pixel format

---
 libavfilter/vf_scale.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 22bee96..a7dfd3d 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -374,6 +374,7 @@ static int config_props(AVFilterLink *outlink)
 int i;
 
 for (i = 0; i < 3; i++) {
+int in_v_chr_pos = scale->in_v_chr_pos, out_v_chr_pos = 
scale->out_v_chr_pos;
 struct SwsContext **s = swscs[i];
 *s = sws_alloc_context();
 if (!*s)
@@ -406,17 +407,17 @@ static int config_props(AVFilterLink *outlink)
  * MPEG-2 chroma positions are used by convention
  * XXX: support other 4:2:0 pixel formats */
 if (inlink0->format == AV_PIX_FMT_YUV420P && scale->in_v_chr_pos 
== -513) {
-scale->in_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
+in_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
 }
 
 if (outlink->format == AV_PIX_FMT_YUV420P && scale->out_v_chr_pos 
== -513) {
-scale->out_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
+out_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
 }
 
 av_opt_set_int(*s, "src_h_chr_pos", scale->in_h_chr_pos, 0);
-av_opt_set_int(*s, "src_v_chr_pos", scale->in_v_chr_pos, 0);
+av_opt_set_int(*s, "src_v_chr_pos", in_v_chr_pos, 0);
 av_opt_set_int(*s, "dst_h_chr_pos", scale->out_h_chr_pos, 0);
-av_opt_set_int(*s, "dst_v_chr_pos", scale->out_v_chr_pos, 0);
+av_opt_set_int(*s, "dst_v_chr_pos", out_v_chr_pos, 0);
 
 if ((ret = sws_init_context(*s, NULL, NULL)) < 0)
 return ret;
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Can BSF delay packets?

[Ronald S. Bultje]

Hi,

On Mon, Feb 6, 2017 at 9:33 AM, wm4  wrote:

> On Mon, 6 Feb 2017 09:06:37 -0500
> "Ronald S. Bultje"  wrote:
>
> > Please don't top-post.
> >
> > I have to admit the new BSF API is super-confusing. I think you return
> > EAGAIN but you also have to deallocate the "out" AVPacket. See
> > http://git.videolan.org/?p=ffmpeg.git;a=blob;f=
> libavcodec/vp9_superframe_bsf.c;h=b686adbe1673f564d252a30cff11c5
> 895a9a3b55;hb=HEAD
> > as an example.
> >
> > The EAGAIN is handled here:
> > http://git.videolan.org/?p=ffmpeg.git;a=blob;f=
> libavcodec/bitstream_filter.c;h=02878e3bf3e9771f5921ce218771f0
> 41e19f2d59;hb=HEAD#l144
> > and the unref will zero the packet, which invokes this code:
> > http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;h=
> 07113107920a910d3b3094f01a1b3f8a58b11072;hb=HEAD#l5256
> > and then it will skip the packet and wait for the next.
>
> Internal and external APIs are rather different, I guess.
>
> > I'm not sure how to retrieve delayed packets though, it seems that's
> simply
> > not possible ATM, not in FFmpeg but also not in Libav - at least using
> the
> > av_bitstream_filter_filter() function... (?)
>
> That function is deprecated, and probably can't do everything the
> new "proper" API can (the send/receive ones).


That doesn't matter as long as it's there and used by libavformat/utils.c
when calling av_read_frame().

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Can BSF delay packets?

[wm4]

On Mon, 6 Feb 2017 09:06:37 -0500
"Ronald S. Bultje"  wrote:

> Please don't top-post.
> 
> I have to admit the new BSF API is super-confusing. I think you return
> EAGAIN but you also have to deallocate the "out" AVPacket. See
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9_superframe_bsf.c;h=b686adbe1673f564d252a30cff11c5895a9a3b55;hb=HEAD
> as an example.
> 
> The EAGAIN is handled here:
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/bitstream_filter.c;h=02878e3bf3e9771f5921ce218771f041e19f2d59;hb=HEAD#l144
> and the unref will zero the packet, which invokes this code:
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;h=07113107920a910d3b3094f01a1b3f8a58b11072;hb=HEAD#l5256
> and then it will skip the packet and wait for the next.

Internal and external APIs are rather different, I guess.

> I'm not sure how to retrieve delayed packets though, it seems that's simply
> not possible ATM, not in FFmpeg but also not in Libav - at least using the
> av_bitstream_filter_filter() function... (?)

That function is deprecated, and probably can't do everything the
new "proper" API can (the send/receive ones).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Can BSF delay packets?

[Ronald S. Bultje]

Hi Aleksey,

On Mon, Feb 6, 2017 at 8:45 AM, Aleksey M  wrote:

> Hi Ronald.
>
> Thank you for replying!
>
> If I return 0 -- how the calling function determines that I've produced an
> output packet?
>
> What do I do to signal caller that I don't want to produce an output
> packet?


Please don't top-post.

I have to admit the new BSF API is super-confusing. I think you return
EAGAIN but you also have to deallocate the "out" AVPacket. See
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9_superframe_bsf.c;h=b686adbe1673f564d252a30cff11c5895a9a3b55;hb=HEAD
as an example.

The EAGAIN is handled here:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/bitstream_filter.c;h=02878e3bf3e9771f5921ce218771f041e19f2d59;hb=HEAD#l144
and the unref will zero the packet, which invokes this code:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;h=07113107920a910d3b3094f01a1b3f8a58b11072;hb=HEAD#l5256
and then it will skip the packet and wait for the next.

I'm not sure how to retrieve delayed packets though, it seems that's simply
not possible ATM, not in FFmpeg but also not in Libav - at least using the
av_bitstream_filter_filter() function... (?)

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Can BSF delay packets?

[Aleksey M]

Hi Ronald.

Thank you for replying!

If I return 0 -- how the calling function determines that I've produced an
output packet?

What do I do to signal caller that I don't want to produce an output packet?

On Mon, Feb 6, 2017 at 3:42 PM, Ronald S. Bultje  wrote:

> Hi Aleksey,
>
> On Mon, Feb 6, 2017 at 5:18 AM, Aleksey M  wrote:
>
> > Hi dear FFMPEG contributors,
> >
> > Does the bitstream filter (BSF) interface allow to delay packets?
> >
> > From Luca's description
> > https://blogs.gentoo.org/lu_zero/2016/03/21/bitstream-filtering/
> > it looks like it can produce any number of output packets or consume any
> > number of input packets.
> >
> > But any attempt to return AVERROR(EAGAIN) results in FFMPEG interrupting
> > processing saying 'Timestamps are unset in a packet...H.264 bitstream
> > malformed".
> >
> > Could anyone point me in the right direction? Or give a working example
> of
> > just delaying by a single packet?
> >
> > For example, should this filter consume all input packets without
> producing
> > output?
> >
> > AVPacket* in = NULL;
> > int result = ff_bsf_get_packet(ctx, );
> >
> > if (result < 0)
> > return result;
> >
> > av_packet_free();
> > return AVERROR(EAGAIN);
> >
> > But it interrupts processing.
>
>
> Just return 0, not EAGAIN. Delay is allowed, yes.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [rfc] tasks for new ffmpeg developers

[Kieran Kunhya]

On Mon, 6 Feb 2017 at 05:54 Compn  wrote:

> people new to the project join #ffmpeg-devel and ask us for help on how
> to start contributing to ffmpeg.
>

A simple one is work on making decoders threadsafe (pthread_once on static
inits).

Regards,
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Can BSF delay packets?

[Ronald S. Bultje]

Hi Aleksey,

On Mon, Feb 6, 2017 at 5:18 AM, Aleksey M  wrote:

> Hi dear FFMPEG contributors,
>
> Does the bitstream filter (BSF) interface allow to delay packets?
>
> From Luca's description
> https://blogs.gentoo.org/lu_zero/2016/03/21/bitstream-filtering/
> it looks like it can produce any number of output packets or consume any
> number of input packets.
>
> But any attempt to return AVERROR(EAGAIN) results in FFMPEG interrupting
> processing saying 'Timestamps are unset in a packet...H.264 bitstream
> malformed".
>
> Could anyone point me in the right direction? Or give a working example of
> just delaying by a single packet?
>
> For example, should this filter consume all input packets without producing
> output?
>
> AVPacket* in = NULL;
> int result = ff_bsf_get_packet(ctx, );
>
> if (result < 0)
> return result;
>
> av_packet_free();
> return AVERROR(EAGAIN);
>
> But it interrupts processing.


Just return 0, not EAGAIN. Delay is allowed, yes.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/3] avcodec: estimate output bitrate for uncompressed video codecs

[Tobias Rapp]

Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.

Signed-off-by: Tobias Rapp 
---
 libavcodec/r210enc.c | 15 +++
 libavcodec/rawenc.c  |  3 +++
 libavcodec/v210enc.c |  4 
 libavcodec/v308enc.c |  4 
 libavcodec/v408enc.c |  3 +++
 libavcodec/v410enc.c |  4 
 libavcodec/y41penc.c |  2 ++
 tests/ref/fate/v410enc   |  2 +-
 tests/ref/vsynth/vsynth1-bpp1|  2 +-
 tests/ref/vsynth/vsynth1-bpp15   |  2 +-
 tests/ref/vsynth/vsynth1-r210|  2 +-
 tests/ref/vsynth/vsynth1-rgb |  2 +-
 tests/ref/vsynth/vsynth1-v210|  2 +-
 tests/ref/vsynth/vsynth1-v210-10 |  2 +-
 tests/ref/vsynth/vsynth1-v308|  2 +-
 tests/ref/vsynth/vsynth1-v408|  2 +-
 tests/ref/vsynth/vsynth1-y41p|  2 +-
 tests/ref/vsynth/vsynth1-yuv |  2 +-
 tests/ref/vsynth/vsynth2-bpp1|  2 +-
 tests/ref/vsynth/vsynth2-bpp15   |  2 +-
 tests/ref/vsynth/vsynth2-r210|  2 +-
 tests/ref/vsynth/vsynth2-rgb |  2 +-
 tests/ref/vsynth/vsynth2-v210|  2 +-
 tests/ref/vsynth/vsynth2-v210-10 |  2 +-
 tests/ref/vsynth/vsynth2-v308|  2 +-
 tests/ref/vsynth/vsynth2-v408|  2 +-
 tests/ref/vsynth/vsynth2-y41p|  2 +-
 tests/ref/vsynth/vsynth2-yuv |  2 +-
 tests/ref/vsynth/vsynth3-bpp1|  2 +-
 tests/ref/vsynth/vsynth3-bpp15   |  2 +-
 tests/ref/vsynth/vsynth3-r210|  2 +-
 tests/ref/vsynth/vsynth3-rgb |  2 +-
 tests/ref/vsynth/vsynth3-v210|  2 +-
 tests/ref/vsynth/vsynth3-v210-10 |  2 +-
 tests/ref/vsynth/vsynth3-v308|  2 +-
 tests/ref/vsynth/vsynth3-v408|  2 +-
 tests/ref/vsynth/vsynth3-yuv |  2 +-
 tests/ref/vsynth/vsynth_lena-bpp1|  2 +-
 tests/ref/vsynth/vsynth_lena-bpp15   |  2 +-
 tests/ref/vsynth/vsynth_lena-r210|  2 +-
 tests/ref/vsynth/vsynth_lena-rgb |  2 +-
 tests/ref/vsynth/vsynth_lena-v210|  2 +-
 tests/ref/vsynth/vsynth_lena-v210-10 |  2 +-
 tests/ref/vsynth/vsynth_lena-v308|  2 +-
 tests/ref/vsynth/vsynth_lena-v408|  2 +-
 tests/ref/vsynth/vsynth_lena-y41p|  2 +-
 tests/ref/vsynth/vsynth_lena-yuv |  2 +-
 47 files changed, 75 insertions(+), 40 deletions(-)

diff --git a/libavcodec/r210enc.c b/libavcodec/r210enc.c
index 65b3c06..f6b387f 100644
--- a/libavcodec/r210enc.c
+++ b/libavcodec/r210enc.c
@@ -24,6 +24,18 @@
 #include "internal.h"
 #include "bytestream.h"
 
+static av_cold int encode_init(AVCodecContext *avctx)
+{
+int aligned_width = FFALIGN(avctx->width,
+avctx->codec_id == AV_CODEC_ID_R10K ? 1 : 64);
+
+avctx->bits_per_coded_sample = 32;
+avctx->bit_rate = ff_guess_coded_bitrate(avctx) * aligned_width / 
avctx->width;
+avctx->bit_rate_tolerance = 0;
+
+return 0;
+}
+
 static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
 const AVFrame *pic, int *got_packet)
 {
@@ -73,6 +85,7 @@ AVCodec ff_r210_encoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("Uncompressed RGB 10-bit"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_R210,
+.init   = encode_init,
 .encode2= encode_frame,
 .pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_RGB48, 
AV_PIX_FMT_NONE },
 .capabilities   = AV_CODEC_CAP_INTRA_ONLY,
@@ -84,6 +97,7 @@ AVCodec ff_r10k_encoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("AJA Kona 10-bit RGB Codec"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_R10K,
+.init   = encode_init,
 .encode2= encode_frame,
 .pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_RGB48, 
AV_PIX_FMT_NONE },
 .capabilities   = AV_CODEC_CAP_INTRA_ONLY,
@@ -95,6 +109,7 @@ AVCodec ff_avrp_encoder = {
 .long_name  = NULL_IF_CONFIG_SMALL("Avid 1:1 10-bit RGB Packer"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_AVRP,
+.init   = encode_init,
 .encode2= encode_frame,
 .pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_RGB48, 
AV_PIX_FMT_NONE },
 .capabilities   = AV_CODEC_CAP_INTRA_ONLY,
diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index a2d5ccc..11c54e7 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -44,6 +44,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 avctx->bits_per_coded_sample = av_get_bits_per_pixel(desc);
 if(!avctx->codec_tag)
 avctx->codec_tag = avcodec_pix_fmt_to_codec_tag(avctx->pix_fmt);
+avctx->bit_rate = ff_guess_coded_bitrate(avctx);
+avctx->bit_rate_tolerance = 0;
+
 return 0;
 }
 
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index d3a8e26..1f47e93 100644
--- a/libavcodec/v210enc.c
+++ 

[FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

[Tobias Rapp]

Sets framerate field in output codec context if explicitly specified on
the command-line.

Signed-off-by: Tobias Rapp 
---
 ffmpeg_opt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 6a47d32..3b532da 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1535,6 +1535,8 @@ static OutputStream *new_video_stream(OptionsContext *o, 
AVFormatContext *oc, in
 av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n", 
frame_rate);
 exit_program(1);
 }
+if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
+video_enc->framerate = ost->frame_rate;
 if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
 av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce invalid 
output files\n");
 
-- 
2.7.4


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 2/3] avcodec: estimate output bitrate for ffv1/huffyuv codecs

[Tobias Rapp]

Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.

Signed-off-by: Tobias Rapp 
---
 libavcodec/ffv1enc.c   |  4 
 libavcodec/huffyuvenc.c|  4 
 libavcodec/internal.h  |  6 ++
 libavcodec/utils.c | 21 +
 tests/ref/vsynth/vsynth1-ffv1  |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth1-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth1-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth1-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth1-huffyuvbgra   |  2 +-
 tests/ref/vsynth/vsynth2-ffv1  |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth2-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth2-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth2-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth2-huffyuvbgra   |  2 +-
 tests/ref/vsynth/vsynth3-ffv1  |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth3-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth3-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth3-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth3-huffyuvbgra   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1  |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v0   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0  |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-rgb48 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff   |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff420p12 |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff422p10left |  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff444|  2 +-
 tests/ref/vsynth/vsynth_lena-ffvhuff444p16 |  2 +-
 tests/ref/vsynth/vsynth_lena-huffyuv   |  2 +-
 tests/ref/vsynth/vsynth_lena-huffyuvbgr24  |  2 +-
 tests/ref/vsynth/vsynth_lena-huffyuvbgra   |  2 +-
 64 files changed, 95 insertions(+), 60 deletions(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 35f54c6..7138cc0 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -894,6 +894,10 @@ slices_ok:
 }
 }
 
+// estimate bitrate assuming 40% compression
+avctx->bit_rate = ff_guess_coded_bitrate(avctx) * 2 / 5;
+avctx->bit_rate_tolerance = avctx->bit_rate;
+
 return 0;
 }
 
diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index 89639b7..8911408 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -446,6 +446,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 s->picture_number=0;
 
+// estimate bitrate assuming 60% compression
+avctx->bit_rate = ff_guess_coded_bitrate(avctx) * 3 / 5;
+avctx->bit_rate_tolerance = avctx->bit_rate;
+
 return 0;
 }
 static int encode_422_bitstream(HYuvContext *s, int offset, int count)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index c92dba4..a63793b 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -361,4 +361,10 @@ int ff_side_data_set_encoder_stats(AVPacket *pkt, int 
quality, int64_t *error, i
 int 

[FFmpeg-devel] Can BSF delay packets?

[Aleksey M]

Hi dear FFMPEG contributors,

Does the bitstream filter (BSF) interface allow to delay packets?

From Luca's description
https://blogs.gentoo.org/lu_zero/2016/03/21/bitstream-filtering/
it looks like it can produce any number of output packets or consume any
number of input packets.

But any attempt to return AVERROR(EAGAIN) results in FFMPEG interrupting
processing saying 'Timestamps are unset in a packet...H.264 bitstream
malformed".

Could anyone point me in the right direction? Or give a working example of
just delaying by a single packet?

For example, should this filter consume all input packets without producing
output?

AVPacket* in = NULL;
int result = ff_bsf_get_packet(ctx, );

if (result < 0)
return result;

av_packet_free();
return AVERROR(EAGAIN);

But it interrupts processing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)

[u-9iep]

On Thu, Feb 02, 2017 at 05:19:16PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 02, 2017 at 04:22:28PM +0100, u-9...@aetey.se wrote:
> > On Thu, Feb 02, 2017 at 01:31:00PM +0100, Michael Niedermayer wrote:
> patch applied
> 
> thx

Thanks Michael.

What about the other patches from that series?

The second one is purely cosmetic (looks useful to me but not much
of concern) while the third (tiny) one is about correcting an inverted
explanation in a comment.

This inversion makes the logic of course noticeably harder to grasp,
IOW it is an apparent commenting bug, ought to be fixed.

Regards,
Rune

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

On Mon, Feb 06, 2017 at 07:57:25AM +0100, Clément Bœsch wrote:
> On Sun, Feb 05, 2017 at 12:24:30PM +0100, u-9...@aetey.se wrote:
> > Hello,
> > 
> > Here comes an amended patch, I think all the relevant points
> > in the discussion have been addressed:
> > 
> > - maintainability and code duplication:
> >   straightforward code templating to reduce duplication
> >   would hardly improve its quality, robustness and maintainability;
> >   a proper style improvement is aking to a rewrite of the concerned
> >   functions instead of the reuse of the previous well tested code;
> >   if to be done, this should be done separately
> > 
> >   * left as-is (further rewrite, outside the scope of the patch)
> > 
> 
> No, code quality is not outside the scope of your patch.

Code quality is a subjective matter.

I believe it is as good as it has to, considering

 - correctness  (do you see any errors?)
 - efficiency   (where it sucks?)
 - readability  (is there any regression? I believe the patch makes
 the decoder quite a bit more understandable)
 - robustness to partial modifications, i.e. constrained to one decoder
(if I tweak one function, I do not have to bother
 about the others, the interface is constrained
 to the calling API, no massive side effects which
 templating relies upon; what's wrong?)

What else?

Would you formulate it in a constructive/measurable way,
what is supposed to happen, to please you just enough?

> [...]
> > - use of environment variables to influence the behaviour of the
> >   libraries in ffmpeg is strongly discouraged
> > 
> >   * left disabled, as a reference/comment, being in certain situations
> > (like those which motivated the optimizations) the only feasible
> > solution
> > 
> 
> The use of the environment variable is not tolerable, this is a blocker.

It is explicitly specified that it is _not_ being used,
are you reading something else?

> [...]
> > Also added some comments with rationales.
> > 
> > I thank everyone for the feedback and hope this code can find its way
> > into upstream.
> > 
> 
> I'm sorry but there is no way it will reach upstream in this form.

As a matter of fact, before the posting I went out of my way and gave
it another try to refactor out the about twelve lines of code which are
duplicated between the ten functions (amounting to potentially reduce
the LOC count by about 10%). Unfortunately, the code was not written
from the beginning to suite for splitting.

This attempt did not lead to any pretty or better understandable/manageable
code, while introducing dependencies between the different decoding functions.

You or someone else here may be of course better qualified for such kind
of improvement, then feel free to propose the restructuring change, or why
not another way to do decoding three times faster on the same hardware.

Otherwise, if you just want to "avoid the duplication for any price" and
do not see a value in readability and maintainability (yes I want both,
a next change if any quite probably will be mine as well) then there is
of course no way to go past your block.

Regards,
Rune

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: fix is_keyframe for early Blocks

[wm4]

On Fri,  3 Feb 2017 14:42:44 -0800
Chris Cunningham  wrote:

> Blocks are marked as key frames whenever the "reference" field is
> zero. This breaks for non-keyframe Blocks with a reference timestamp
> of zero.
> 
> The likelihood of reference timestamp being zero is increased by a
> longstanding bug in muxing that encodes reference timestamp as the
> absolute time of the referenced frame (rather than relative to the
> current Block timestamp, as described in MKV spec).
> 
> Now using INT64_MIN to denote "no reference".
> 
> Reported to chromium at http://crbug.com/497889 (contains sample)
> ---
>  libavformat/matroskadec.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index e6737a70b2..7223e94b55 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -89,6 +89,7 @@ typedef const struct EbmlSyntax {
>  int list_elem_size;
>  int data_offset;
>  union {
> +int64_t i;
>  uint64_tu;
>  double  f;
>  const char *s;
> @@ -696,7 +697,7 @@ static const EbmlSyntax matroska_blockgroup[] = {
>  { MATROSKA_ID_SIMPLEBLOCK,EBML_BIN,  0, offsetof(MatroskaBlock, bin) 
> },
>  { MATROSKA_ID_BLOCKDURATION,  EBML_UINT, 0, offsetof(MatroskaBlock, 
> duration) },
>  { MATROSKA_ID_DISCARDPADDING, EBML_SINT, 0, offsetof(MatroskaBlock, 
> discard_padding) },
> -{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0, offsetof(MatroskaBlock, 
> reference) },
> +{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0, offsetof(MatroskaBlock, 
> reference), { .i = INT64_MIN } },
>  { MATROSKA_ID_CODECSTATE, EBML_NONE },
>  {  1, EBML_UINT, 0, offsetof(MatroskaBlock, 
> non_simple), { .u = 1 } },
>  { 0 }
> @@ -1071,6 +1072,9 @@ static int ebml_parse_nest(MatroskaDemuxContext 
> *matroska, EbmlSyntax *syntax,
>  
>  for (i = 0; syntax[i].id; i++)
>  switch (syntax[i].type) {
> +case EBML_SINT:
> +*(int64_t *) ((char *) data + syntax[i].data_offset) = 
> syntax[i].def.i;
> +break;
>  case EBML_UINT:
>  *(uint64_t *) ((char *) data + syntax[i].data_offset) = 
> syntax[i].def.u;
>  break;
> @@ -3361,7 +3365,7 @@ static int 
> matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
>  matroska->current_cluster_num_blocks = blocks_list->nb_elem;
>  i= blocks_list->nb_elem - 1;
>  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> -int is_keyframe = blocks[i].non_simple ? !blocks[i].reference : 
> -1;
> +int is_keyframe = blocks[i].non_simple ? blocks[i].reference == 
> INT64_MIN : -1;
>  uint8_t* additional = blocks[i].additional.size > 0 ?
>  blocks[i].additional.data : NULL;
>  if (!blocks[i].non_simple)
> @@ -3399,7 +3403,7 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
> *matroska)
>  blocks  = blocks_list->elem;
>  for (i = 0; i < blocks_list->nb_elem; i++)
>  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> -int is_keyframe = blocks[i].non_simple ? !blocks[i].reference : 
> -1;
> +int is_keyframe = blocks[i].non_simple ? blocks[i].reference == 
> INT64_MIN : -1;
>  res = matroska_parse_block(matroska, blocks[i].bin.data,
> blocks[i].bin.size, blocks[i].bin.pos,
> cluster.timecode, blocks[i].duration,

Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel