Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: set correct priv_data for feed stream

2014-11-05 Thread Michael Niedermayer 
On Thu, Nov 06, 2014 at 12:59:45AM +0100, Lukasz Marek wrote:
> new_output_stream creates a codec context with arbitraty picked codec.
> Later data is updated, but priv_data are left alone.
> There is a bit chance there is a mismatch between codecs.
> 
> Signed-off-by: Lukasz Marek 
> ---
>  ffmpeg_opt.c | 16 
>  libavformat/ffmdec.c |  6 --
>  2 files changed, 20 insertions(+), 2 deletions(-)

with this fate-lavf-ffm crashes

==10836== Invalid write of size 8
==10836==at 0x935442: decode_init (mpegaudiodec_template.c:419)
==10836==by 0xA69226: avcodec_open2 (utils.c:1614)
==10836==by 0x64CC5F: avformat_find_stream_info (utils.c:3053)
==10836==by 0x41C2D7: open_input_file (ffmpeg_opt.c:886)
==10836==by 0x42427A: open_files (ffmpeg_opt.c:2699)
==10836==by 0x4243F8: ffmpeg_parse_options (ffmpeg_opt.c:2736)
==10836==by 0x43762E: main (ffmpeg.c:3861)
==10836==  Address 0x10f072b0 is not stack'd, malloc'd or (recently) free'd
==10836==
==10836== Invalid write of size 8
==10836==at 0xDC67D0: avpriv_float_dsp_init (float_dsp.c:120)
==10836==by 0x93546B: decode_init (mpegaudiodec_template.c:421)
==10836==by 0xA69226: avcodec_open2 (utils.c:1614)
==10836==by 0x64CC5F: avformat_find_stream_info (utils.c:3053)
==10836==by 0x41C2D7: open_input_file (ffmpeg_opt.c:886)
==10836==by 0x42427A: open_files (ffmpeg_opt.c:2699)
==10836==by 0x4243F8: ffmpeg_parse_options (ffmpeg_opt.c:2736)
==10836==by 0x43762E: main (ffmpeg.c:3861)
==10836==  Address 0x10f072e8 is not stack'd, malloc'd or (recently) free'd
and pages more

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] FFserver bug?

2014-11-05 Thread Lukasz Marek 

On 05.11.2014 02:15, Lukasz Marek wrote:

On 31.10.2014 02:14, Sevan Gelici wrote:

Hi,

Two days ago i updated my linux system and also ffmpeg was updated.
When i
started to stream it was not working anymore. I am using ffserver. i
determined the problem which causes the problem thats the bitrate it
makes
like 50mb of it. i reinstalled the system a couple times because of some
tests and still i don't get it work. Can someone help me with this pls.


I fixed it on 2.3 release branch. I know this should be done on master
first, but I wanted to be close for the commit that introduced the problem.
There are some changes in later releases so cherry-pick would not be
enough tho, to fix it on previous release
Fix patches attached.


I see I was very tired yesterday :)
I sent updated patch for master branch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffmpeg_opt: set correct priv_data for feed stream

2014-11-05 Thread Lukasz Marek 
new_output_stream creates a codec context with arbitraty picked codec.
Later data is updated, but priv_data are left alone.
There is a bit chance there is a mismatch between codecs.

Signed-off-by: Lukasz Marek 
---
 ffmpeg_opt.c | 16 
 libavformat/ffmdec.c |  6 --
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 1757dcc..b495b87 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1643,12 +1643,28 @@ static int read_ffserver_streams(OptionsContext *o, 
AVFormatContext *s, const ch
 memcpy(st->info, ic->streams[i]->info, sizeof(*st->info));
 st->codec= avctx;
 avcodec_copy_context(st->codec, ic->streams[i]->codec);
+if (st->codec->priv_data) {
+av_opt_free(st->codec->priv_data);
+av_free(st->codec->priv_data);
+}
+st->codec->priv_data = ic->streams[i]->codec->priv_data;
+ic->streams[i]->codec->priv_data = NULL;
 
 if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO && !ost->stream_copy)
 choose_sample_fmt(st, codec);
 else if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO && 
!ost->stream_copy)
 choose_pixel_fmt(st, st->codec, codec, st->codec->pix_fmt);
 avcodec_copy_context(ost->enc_ctx, st->codec);
+if (ost->enc_ctx->priv_data) {
+av_opt_free(ost->enc_ctx->priv_data);
+av_free(ost->enc_ctx->priv_data);
+}
+ost->enc_ctx->priv_data = av_mallocz(codec->priv_data_size);
+if (ost->enc_ctx->priv_data) {
+*(const AVClass**)ost->enc_ctx->priv_data = codec->priv_class;
+av_opt_copy(ost->enc_ctx->priv_data, st->codec->priv_data);
+} else
+err = AVERROR(ENOMEM);
 }
 
 avformat_close_input(&ic);
diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c
index 448762b..3119720 100644
--- a/libavformat/ffmdec.c
+++ b/libavformat/ffmdec.c
@@ -237,6 +237,7 @@ static int ffm2_read_header(AVFormatContext *s)
 AVIOContext *pb = s->pb;
 AVCodecContext *codec;
 int ret;
+enum AVCodecID codec_id;
 
 ffm->packet_size = avio_rb32(pb);
 if (ffm->packet_size != FFM_PACKET_SIZE) {
@@ -271,7 +272,8 @@ static int ffm2_read_header(AVFormatContext *s)
 avio_rb32(pb); /* total bitrate */
 break;
 case MKBETAG('C', 'O', 'M', 'M'):
-st = avformat_new_stream(s, NULL);
+codec_id = avio_rb32(pb);
+st = avformat_new_stream(s, avcodec_find_encoder(codec_id));
 if (!st) {
 ret = AVERROR(ENOMEM);
 goto fail;
@@ -281,7 +283,7 @@ static int ffm2_read_header(AVFormatContext *s)
 
 codec = st->codec;
 /* generic info */
-codec->codec_id = avio_rb32(pb);
+codec->codec_id = codec_id;
 codec->codec_type = avio_r8(pb);
 codec->bit_rate = avio_rb32(pb);
 codec->flags = avio_rb32(pb);
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] v4l2: setting device parameters early

2014-11-05 Thread Michael Niedermayer 
On Wed, Oct 22, 2014 at 04:12:31PM +0200, Giorgio Vazzana wrote:
> Hello,
> 
> this was probably wrong and has caused

i can revert it if you want ?


> https://trac.ffmpeg.org/ticket/3517 . Will investigate.
> 
> Giorgio Vazzana
> 
> 2014-01-05 17:17 GMT+01:00 Michael Niedermayer :
> > On Sun, Jan 05, 2014 at 12:33:42PM +0100, Federico Simoncelli wrote:
> >> Any feedback?
> >
> > looks good, thus applied
> >
> > thanks
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Observe your enemies, for they first find out your faults. -- Antisthenes
> >
> > ___
> > 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
> 

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

Re: [FFmpeg-devel] "OPW Qualification Task: Enable daemon mode for FFserver"

2014-11-05 Thread Nicolas George 
Le quintidi 15 brumaire, an CCXXIII, Binathi Bingi a écrit :
> I see, we need dup2() to redirect the output to logfile. Therefore, I put
> it back in the patch.
> 
> But, I am not sure if we should definitely use it, because I can't see any
> messages on the console as all are being redirected to log file
> For instance, when I run ffserver, I can't see the output like"FFserver
> started" or when I try to re-run while it is already running as daemon, I
> can't see the messages like "bind(port 8090): Address already in use"
> 
> So, I did ps -ux to see if ffserver was running as daemon, and it was.
> I am not sure if we should use dup2(), as it is redirecting messages from
> console.

I am not sure I understand exactly the scenario you are describing. Did you
set the logfile option for your tests?

> From 091aa564dc43bf18abd5dc596bf5350e92cad5dd Mon Sep 17 00:00:00 2001
> From: Binathi 
> Date: Tue, 4 Nov 2014 21:42:07 +0530
> Subject: [PATCH] Restore Daemon mode in FFserver

This is near the final form for inclusion, so even minor comments are
included. There are only two real issues: the tabs and the
config.logfilename test; the rest is mostly cosmetic.

> 
> Signed-off-by: Binathi Bingi 
> ---
>  doc/ffserver.conf |  5 +
>  doc/ffserver.texi |  7 ---
>  ffserver.c| 38 --
>  ffserver_config.c |  6 --
>  ffserver_config.h |  1 +
>  5 files changed, 50 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/ffserver.conf b/doc/ffserver.conf
> index b756961..8101f15 100644
> --- a/doc/ffserver.conf
> +++ b/doc/ffserver.conf
> @@ -25,6 +25,11 @@ MaxBandwidth 1000
>  # '-' is the standard output.
>  CustomLog -
>  
> +# Suppress NoDaemon and enable Daemon, if you want to launch ffserver in 
> daemon mode.
> +# If no option is specified, default option is NoDaemon.

> +#NoDaemon
> +Daemon

Please leave NoDaemon the default.

(I suspect you change it for your tests; in that case, maybe make a copy
that you can change and will not commit.)

> +
>  ##
>  # Definition of the live feeds. Each live feed contains one video
>  # and/or audio sequence coming from an ffmpeg encoder or another
> diff --git a/doc/ffserver.texi b/doc/ffserver.texi
> index 77273d2..5d5fc0f 100644
> --- a/doc/ffserver.texi
> +++ b/doc/ffserver.texi
> @@ -405,9 +405,10 @@ In case the commandline option @option{-d} is specified 
> this option is
>  ignored, and the log is written to standard output.
>  
>  @item NoDaemon
> -Set no-daemon mode. This option is currently ignored since now
> -@command{ffserver} will always work in no-daemon mode, and is
> -deprecated.
> +Set no-daemon mode. This is the default.
> +
> +@item Daemon

> +Set daemon mode. The default is NoDaemon

Final period.

>  @end table
>  
>  @section Feed section
> diff --git a/ffserver.c b/ffserver.c
> index ea2a2ae..eda3496 100644
> --- a/ffserver.c
> +++ b/ffserver.c
> @@ -3671,6 +3671,7 @@ static void handle_child_exit(int sig)
>  static void opt_debug(void)
>  {
>  config.debug = 1;
> +config.ffserver_daemon = 0;
>  snprintf(config.logfilename, sizeof(config.logfilename), "-");
>  }
>  
> @@ -3694,7 +3695,7 @@ int main(int argc, char **argv)
>  {
>  struct sigaction sigact = { { 0 } };
>  int ret = 0;
> -

> +int fd;

Leave the empty line. And possibly move fd along with ffserver_id and sid.

>  config.filename = av_strdup("/etc/ffserver.conf");
>  
>  parse_loglevel(argc, argv, options);
> @@ -3736,7 +3737,40 @@ int main(int argc, char **argv)
>  build_feed_streams();
>  
>  compute_bandwidth();

> -

Please leave the empty line.

> + if (config.ffserver_daemon) {

Here and in the following lines, you have tabs for indentation. Tabs can not
be committed to the official repository. The standard indentation is four
spaces for each level.

> + pid_t ffserver_id = 0;
> + pid_t sid = 0;
> +

> + ffserver_id = fork();
> +
> + if (ffserver_id < 0) {

This empty line, OTOH, can go :)

> + ret = AVERROR(errno);
> + av_log(NULL, AV_LOG_ERROR, "Impossible to start in 
> daemon mode: %s\n", av_err2str(ret));
> + exit(1);
> + }
> +
> + if (ffserver_id > 0)
> + exit(0);
> +
> + sid = setsid();
> + if (sid < 0)
> + exit(1);
> +
> + fd = open("/dev/null", O_RDWR);
> + 
> + if (fd != -1){  
> + dup2 (fd, 0);  
> + dup2 (fd, 2); 

> + while(!strcmp(config.logfilename,"-"))
> + dup2 (fd, 1);  

I am pretty sure this was not tested: config.logfilename can not change in
the loop, so if the program enters the loop, it will never stop.

> + } else {
> + ret = AVERROR(errno);
> +

Re: [FFmpeg-devel] [PATCH] ffmpeg: init sub2video.last_pts.

2014-11-05 Thread Michael Niedermayer 
On Sat, Nov 01, 2014 at 02:38:02PM +0100, Nicolas George wrote:
> Get the heartbeat working when the video has negative timestamps.
> 
> Fix trac ticket #4062.
> 
> Signed-off-by: Nicolas George 
> ---
>  ffmpeg_filter.c | 1 +
>  1 file changed, 1 insertion(+)

looks ok, applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


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

Re: [FFmpeg-devel] [PATCH] Enable mpcodecs without needing inline asm

2014-11-05 Thread Michael Niedermayer 
On Wed, Nov 05, 2014 at 07:39:19PM +0100, wm4 wrote:
> On Wed, 5 Nov 2014 18:06:42 +1100
> Matt Oliver  wrote:
> 
> > Currently the extra filters provided by mpcodecs require inline asm support
> > to compile. However these filters all provide non-asm alternatives that can
> > be used with the correct pre-processor guard.
> > 
> > Based on some recent discussions it appears that some of these filters are
> > still used but with the requirement for inline asm they cannot be used with
> > certain compilers (such as msvc). So while people still use/need these
> > filters i thought id make them available for msvc users.
> 
> Who's using these filters?

iam using them occasionally


> Who wants to use them on MSVC?

i dont use MSVC, so not me but
if i would be using MSVC, i would want to use these filters with MSVC


> 
> > The mpcodec filters use pre-processor defines such as HAVE_MMX for inline
> > asm, given both mplayer and ffmpeg have a HAVE_MMX_INLINE define specific
> > for inline asm then the preprocessors can be changed to the _INLINE
> > variants which makes inline asm code compile as appropriate.
> > 
> > This patch has 2 parts, the first changes the pre-processors in mpcodecs to
> > use the _INLINE variants. Logically this would appear to be the correct
> > pre-processor for inline asm to begin with, if anyone knows of why the
> > _INLINE variants werent/shouldnt be used then feel free to let me know.
> > 
> > The mpcodec patch will have to be pushed to upstream but assuming
> > everything is ok then the second patch just updates ffmpegs configure to
> > allow the mpcodecs filters without requiring inline asm.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] v4l2: support MPEG4 compressed streams

2014-11-05 Thread Michael Niedermayer 
On Wed, Nov 05, 2014 at 04:38:30PM +0400, Andrey Utkin wrote:
> ---
>  libavdevice/v4l2-common.c | 3 +++
>  1 file changed, 3 insertions(+)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] Enable mpcodecs without needing inline asm

2014-11-05 Thread wm4 
On Wed, 5 Nov 2014 18:06:42 +1100
Matt Oliver  wrote:

> Currently the extra filters provided by mpcodecs require inline asm support
> to compile. However these filters all provide non-asm alternatives that can
> be used with the correct pre-processor guard.
> 
> Based on some recent discussions it appears that some of these filters are
> still used but with the requirement for inline asm they cannot be used with
> certain compilers (such as msvc). So while people still use/need these
> filters i thought id make them available for msvc users.

Who's using these filters? Who wants to use them on MSVC?

> The mpcodec filters use pre-processor defines such as HAVE_MMX for inline
> asm, given both mplayer and ffmpeg have a HAVE_MMX_INLINE define specific
> for inline asm then the preprocessors can be changed to the _INLINE
> variants which makes inline asm code compile as appropriate.
> 
> This patch has 2 parts, the first changes the pre-processors in mpcodecs to
> use the _INLINE variants. Logically this would appear to be the correct
> pre-processor for inline asm to begin with, if anyone knows of why the
> _INLINE variants werent/shouldnt be used then feel free to let me know.
> 
> The mpcodec patch will have to be pushed to upstream but assuming
> everything is ok then the second patch just updates ffmpegs configure to
> allow the mpcodecs filters without requiring inline asm.

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

Re: [FFmpeg-devel] [PATCH] Enable mpcodecs without needing inline asm

2014-11-05 Thread Michael Niedermayer 
On Thu, Nov 06, 2014 at 12:43:35AM +1100, Matt Oliver wrote:
> >
> >
> > did you post this to mplayer-dev ?
> >
> 
> No not as yet, thought I would put it up here for feedback first. Also
> someone more familiar with mpcodecs in mplayer might know of other places
> that could benefit from a similar change.

ping me about a week or so afer you posted it to mplayer-dev incase
noone applies it and noone rejects it

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

[FFmpeg-devel] [PATCH] doc/examples: add avio_writing examples

2014-11-05 Thread Stefano Sabatini 
Show how to use the AVIO writing API.
---
 .gitignore  |   1 +
 configure   |   1 +
 doc/examples/Makefile   |   1 +
 doc/examples/avio_writing.c | 225 
 4 files changed, 228 insertions(+)
 create mode 100644 doc/examples/avio_writing.c

diff --git a/.gitignore b/.gitignore
index 793d33a..628ffb1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,7 @@
 /doc/avoptions_format.texi
 /doc/doxy/html/
 /doc/examples/avio_reading
+/doc/examples/avio_writing
 /doc/examples/decoding_encoding
 /doc/examples/demuxing_decoding
 /doc/examples/extract_mvs
diff --git a/configure b/configure
index 570878d..5b3a246 100755
--- a/configure
+++ b/configure
@@ -1310,6 +1310,7 @@ COMPONENT_LIST="
 
 EXAMPLE_LIST="
 avio_reading_example
+avio_writing_example
 decoding_encoding_example
 demuxing_decoding_example
 extract_mvs_example
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 07251fe..ad10b5b 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -12,6 +12,7 @@ CFLAGS := $(shell pkg-config --cflags $(FFMPEG_LIBS)) 
$(CFLAGS)
 LDLIBS := $(shell pkg-config --libs $(FFMPEG_LIBS)) $(LDLIBS)
 
 EXAMPLES=   avio_reading   \
+avio_writing   \
 decoding_encoding  \
 demuxing_decoding  \
 extract_mvs\
diff --git a/doc/examples/avio_writing.c b/doc/examples/avio_writing.c
new file mode 100644
index 000..27ef21a
--- /dev/null
+++ b/doc/examples/avio_writing.c
@@ -0,0 +1,225 @@
+/*
+ * Copyright (c) 2014 Stefano Sabatini
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * @file
+ * libavformat AVIOContext API example.
+ *
+ * Make libavformat demuxer access media content through a custom
+ * AVIOContext write callback.
+ * @example avio_writing.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct buffer_data {
+uint8_t *buf;
+size_t size;
+uint8_t *ptr;
+size_t room; ///< size left in the buffer
+};
+
+static void log_packet(const AVFormatContext *fmt_ctx, const AVPacket *pkt, 
const char *tag)
+{
+AVRational *time_base = &fmt_ctx->streams[pkt->stream_index]->time_base;
+
+printf("%s: pts:%s pts_time:%s dts:%s dts_time:%s duration:%s 
duration_time:%s stream_index:%d\n",
+   tag,
+   av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, time_base),
+   av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, time_base),
+   av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, time_base),
+   pkt->stream_index);
+}
+
+static int write_packet(void *opaque, uint8_t *buf, int buf_size)
+{
+struct buffer_data *bd = (struct buffer_data *)opaque;
+while (buf_size > bd->room) {
+int64_t offset = bd->ptr - bd->buf;
+bd->buf = av_realloc_f(bd->buf, 2, bd->size);
+if (!bd->buf)
+return AVERROR(ENOMEM);
+bd->size *= 2;
+bd->ptr = bd->buf + offset;
+bd->room = bd->size - offset;
+}
+printf("write packet pkt_size:%d used_buf_size:%zu buf_size:%zu 
buf_room:%zu\n", buf_size, bd->ptr-bd->buf, bd->size, bd->room);
+
+/* copy buffer data to buffer_data buffer */
+memcpy(bd->ptr, buf, buf_size);
+bd->ptr  += buf_size;
+bd->room -= buf_size;
+
+return buf_size;
+}
+
+int main(int argc, char *argv[])
+{
+AVFormatContext *ifmt_ctx = NULL;
+AVFormatContext *ofmt_ctx = NULL;
+AVIOContext *avio_ctx = NULL;
+uint8_t *avio_ctx_buffer = NULL;
+size_t avio_ctx_buffer_size = 4096;
+char *in_filename = NULL;
+char *out_filename = NULL;
+int i, ret = 0;
+struct buffer_data bd = { 0 };
+const size_t bd_buf_size = 1024;
+AVPacket pkt;
+
+if (argc != 3) {
+fprintf(stderr, "usage: %s input_file output_file\n"
+"

Re: [FFmpeg-devel] [PATCH 3/3] idet improvements: add repeated field detection

2014-11-05 Thread Michael Niedermayer 
On Tue, Nov 04, 2014 at 01:14:07PM -0800, Kevin Mitchell wrote:
> oops. fixed.

>  doc/filters.texi  |   19 +--
>  libavfilter/version.h |2 +-
>  libavfilter/vf_idet.c |   41 +++--
>  libavfilter/vf_idet.h |   10 ++
>  4 files changed, 67 insertions(+), 5 deletions(-)
> cc6dbbbe207484aa60d2651dceb31e73585f1222  
> 0001-avfilter-vf_idet-add-a-repeated-field-detection.patch
> From 7a8b181f88c8039c044d662fadbb92befeb8f163 Mon Sep 17 00:00:00 2001
> From: Kevin Mitchell 
> Date: Sun, 2 Nov 2014 04:49:34 -0800
> Subject: [PATCH] avfilter/vf_idet: add a repeated field detection
> 
> This can be useful for determining telecine.
> ---
>  doc/filters.texi  | 19 +--
>  libavfilter/version.h |  2 +-
>  libavfilter/vf_idet.c | 41 +++--
>  libavfilter/vf_idet.h | 10 ++
>  4 files changed, 67 insertions(+), 5 deletions(-)

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] Enable mpcodecs without needing inline asm

2014-11-05 Thread Matt Oliver 
>
>
> did you post this to mplayer-dev ?
>

No not as yet, thought I would put it up here for feedback first. Also
someone more familiar with mpcodecs in mplayer might know of other places
that could benefit from a similar change.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] v4l2: support MPEG4 compressed streams

2014-11-05 Thread Andrey Utkin 
---
 libavdevice/v4l2-common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
index 966b9a1..196c09b 100644
--- a/libavdevice/v4l2-common.c
+++ b/libavdevice/v4l2-common.c
@@ -46,6 +46,9 @@ const struct fmt_map ff_fmt_conversion_table[] = {
 #ifdef V4L2_PIX_FMT_H264
 { AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264},
 #endif
+#ifdef V4L2_PIX_FMT_MPEG4
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG4,V4L2_PIX_FMT_MPEG4   },
+#endif
 #ifdef V4L2_PIX_FMT_CPIA1
 { AV_PIX_FMT_NONE,AV_CODEC_ID_CPIA, V4L2_PIX_FMT_CPIA1   },
 #endif
-- 
1.8.5.5

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

Re: [FFmpeg-devel] doc/examples/muxing.c

2014-11-05 Thread JULIAN GARDNER 
>
> From: Stefano Sabatini 
>To: FFmpeg development discussions and patches  
>Sent: Wednesday, 5 November 2014, 12:23
>Subject: Re: [FFmpeg-devel] doc/examples/muxing.c
> 
>
>On date Tuesday 2014-11-04 17:39:22 +, JULIAN GARDNER encoded:
>> I have been working on a program which needs to do audio resampling, and 
>> used muxing.c as a base but now i am coming up against a problem.
>> 
>
>> Changing muxing.c so that the sound produced by the routine
>> get_audio_frame is not the same audio rate as the output causes an
>> assert in the write_audio_frame routine, normally the program
>> prodces the same audio rate that the output format is going to use,
>> so the resampler really does nothing.
>
>No the resampler is used to change sample format, in case the output
>format doesn't support the input format.


Yes but the sample_count stays the same as the input rate==output rate, so no 
errors crop up


>
>> 
>> Modifying the audio tmp_frame definition and the associated tables for the 
>> resampler was easy but i have 1 thing which im struggling to understand
>> 
>> line 310 muxing.c
>> 
>> if (frame) { 
>
>>         /* convert samples from native format to destination codec format, 
>> using the resampler */ 
>>         /* compute destination number of samples */ 
>
>>         dst_nb_samples = av_rescale_rnd(swr_get_delay(ost->swr_ctx, 
>> c->sample_rate) + frame->nb_samples, 
>>                                                                 
>> c->sample_rate, c->sample_rate, AV_ROUND_UP); 
>>         av_assert0(dst_nb_samples == frame->nb_samples); 
>
>This is suspect (the reason of this change is lost in the merges, so I
>can't help).


Anyone

>> 
>> 
>> line 335 muxing.c
>>         frame->pts = av_rescale_q(ost->samples_count, (AVRational){1, 
>> c->sample_rate}, c->time_base);
>> 
>> 
>
>> As the current code stands the input and output sample_rate is the
>> same, so this code really does nothing, but now i have it so that
>> the output is 44100 and the input is 48000, this code needs
>> changing, my initial thought was this will use the output sample
>> rate, but i still get the assert
>> 
>
>> Can someone who knows more about this fix the demo so that the input
>> sample rate != output sample rate
>
>How are you using the code? How can you force the code to change
>output sample rate? If you have a patch please share.


thats the problem i have patch 4 lines of code which forces the self produced 
sound to be different from the output stream

example
#define SAMPLE_RATE_OTHER( X)        (X==44100 ? 48000:44100)


routine open_audio

find the line
    ost->t  = 0;
change next 2 lines
    ost->tincr = 2 * M_PI * 110.0 / SAMPLE_RATE_OTHER(c->sample_rate);
    ost->tincr2 = 2 * M_PI * 110.0 / SAMPLE_RATE_OTHER(c->sample_rate) / 
SAMPLE_RATE_OTHER(c->sample_rate);

then find the line
    ost->tmp_frame = alloc_audio_frame(AV_SAMPLE_FMT_S16, c-:channel_layout,
                                               c->sample_rate, nb_samples); 

change to

    ost->tmp_frame = alloc_audio_frame(AV_SAMPLE_FMT_S16, c-:channel_layout,
                                               
SAMPLE_RATE_OTHER(c->sample_rate), nb_samples);


then 10 lines down
    av_opt_set_int          (ost->swr_ctx, "in_sample_rate",        
c->sample_rate, 0);change to 

    av_opt_set_int          (ost->swr_ctx, "in_sample_rate",        
SAMPLE_RATE_OTHER(c->sample_rate), 0);

     
This then states that the self produced audio frame will have a different 
sample_rate to that of the output format.


If you make these changes and nothing else you get the assert in 
write_audio_frame

As an example

  in    out values from assert

22050  44100  2304 1152    ASSERT
32000  44100  1588 1152    ASSERT

44100  44100  1152 1152    OK

48000  44100  1168 1152    ASSERT


22050  48000  2508 1152    ASSERT
32000  48000  1728 1152    ASSERT

44100  48000  1254 1152    ASSERT

48000  48000  1152 1152    OK


joolz

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

Re: [FFmpeg-devel] [PATCH 2/2] [RFC]lavf/ffm: update with more options.

2014-11-05 Thread Lukasz Marek 
On 5 November 2014 12:25, Stefano Sabatini  wrote:

> On date Monday 2014-11-03 00:54:01 +0100, Lukasz Marek encoded:
> > On 03.11.2014 00:40, Stefano Sabatini wrote:
> > >On date Sunday 2014-11-02 19:19:14 +0100, Lukasz Marek encoded:
> > >>TODO: bump micro
> > >>
> > >>Many common codec options are not via ffm protocol.
> > >>This commit adds common A/V encoding options to protocol.
> > >>
> > >>Signed-off-by: Lukasz Marek 
> > >>---
> > >>  libavformat/ffmdec.c | 78
> 
> > >>  libavformat/ffmenc.c | 60 
> > >>  2 files changed, 138 insertions(+)
> > >
> > >My idea was to let the protocol specify the option using the AVOption
> > >interface. This way you don't have to update the protocol every time a
> > >new option is added to libavcodec, *AND* you can support private codec
> > >options.
> >
> > >> (in near future I will add posibility to set them)
> > >
> > > I'm curious about that, since that was in my (much neglected) todo
> > > list. How do you plan to do that? The only way I see is to fiddle with
> > > FFM.
> > >
> >
> > To not spam other thread with offtopic I moved your question here.
> >
> > I'm not sure yet. In config I wanted to something like that:
> >
> > VideoCodec libx264
> > #common options:
> > AVOptionVideo flags +global_header
> > #private option
>
> > AVOptionVideo libx264:crf 23
>
> Why do you think the prefix with the name of the codec is needed?
>
> > In ffm my first idea was to serialize it as strings in separate section.
> > I haven't really thought about it yet. Maybe serializing common
> > options would be also good idea. And send only set values.
>
> My idea was to generalize the format and serialize the option
> key/values.


We have the same or similar idea. I am about half way to implement that for
private options. I just dont know if send values as strings or in binary
form where possible.
 I think sending both key and val as string is to most generic so probably
will do it this way first.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] [RFC]lavf/ffm: update with more options.

2014-11-05 Thread Stefano Sabatini 
On date Monday 2014-11-03 00:54:01 +0100, Lukasz Marek encoded:
> On 03.11.2014 00:40, Stefano Sabatini wrote:
> >On date Sunday 2014-11-02 19:19:14 +0100, Lukasz Marek encoded:
> >>TODO: bump micro
> >>
> >>Many common codec options are not via ffm protocol.
> >>This commit adds common A/V encoding options to protocol.
> >>
> >>Signed-off-by: Lukasz Marek 
> >>---
> >>  libavformat/ffmdec.c | 78 
> >> 
> >>  libavformat/ffmenc.c | 60 
> >>  2 files changed, 138 insertions(+)
> >
> >My idea was to let the protocol specify the option using the AVOption
> >interface. This way you don't have to update the protocol every time a
> >new option is added to libavcodec, *AND* you can support private codec
> >options.
> 
> >> (in near future I will add posibility to set them)
> >
> > I'm curious about that, since that was in my (much neglected) todo
> > list. How do you plan to do that? The only way I see is to fiddle with
> > FFM.
> >
> 
> To not spam other thread with offtopic I moved your question here.
> 
> I'm not sure yet. In config I wanted to something like that:
> 
> VideoCodec libx264
> #common options:
> AVOptionVideo flags +global_header
> #private option

> AVOptionVideo libx264:crf 23

Why do you think the prefix with the name of the codec is needed?

> In ffm my first idea was to serialize it as strings in separate section.
> I haven't really thought about it yet. Maybe serializing common
> options would be also good idea. And send only set values.

My idea was to generalize the format and serialize the option
key/values.
-- 
FFmpeg = Fiendish Faithless Minimalistic Plastic Extravagant Gadget
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] doc/examples/muxing.c

2014-11-05 Thread Stefano Sabatini 
On date Tuesday 2014-11-04 17:39:22 +, JULIAN GARDNER encoded:
> I have been working on a program which needs to do audio resampling, and used 
> muxing.c as a base but now i am coming up against a problem.
> 

> Changing muxing.c so that the sound produced by the routine
> get_audio_frame is not the same audio rate as the output causes an
> assert in the write_audio_frame routine, normally the program
> prodces the same audio rate that the output format is going to use,
> so the resampler really does nothing.

No the resampler is used to change sample format, in case the output
format doesn't support the input format.

> 
> Modifying the audio tmp_frame definition and the associated tables for the 
> resampler was easy but i have 1 thing which im struggling to understand
> 
> line 310 muxing.c
> 
> if (frame) { 

>         /* convert samples from native format to destination codec format, 
> using the resampler */ 
>         /* compute destination number of samples */ 

>         dst_nb_samples = av_rescale_rnd(swr_get_delay(ost->swr_ctx, 
> c->sample_rate) + frame->nb_samples, 
>                                                                 
> c->sample_rate, c->sample_rate, AV_ROUND_UP); 
>         av_assert0(dst_nb_samples == frame->nb_samples); 

This is suspect (the reason of this change is lost in the merges, so I
can't help).

> 
> 
> line 335 muxing.c
>         frame->pts = av_rescale_q(ost->samples_count, (AVRational){1, 
> c->sample_rate}, c->time_base);
> 
> 

> As the current code stands the input and output sample_rate is the
> same, so this code really does nothing, but now i have it so that
> the output is 44100 and the input is 48000, this code needs
> changing, my initial thought was this will use the output sample
> rate, but i still get the assert
> 

> Can someone who knows more about this fix the demo so that the input
> sample rate != output sample rate

How are you using the code? How can you force the code to change
output sample rate? If you have a patch please share.
-- 
FFmpeg = Fascinating and Faithful Mind-dumbing Powerful Elegant Geek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Enable mpcodecs without needing inline asm

2014-11-05 Thread Michael Niedermayer 
On Wed, Nov 05, 2014 at 06:06:42PM +1100, Matt Oliver wrote:
> Currently the extra filters provided by mpcodecs require inline asm support
> to compile. However these filters all provide non-asm alternatives that can
> be used with the correct pre-processor guard.
> 
> Based on some recent discussions it appears that some of these filters are
> still used but with the requirement for inline asm they cannot be used with
> certain compilers (such as msvc). So while people still use/need these
> filters i thought id make them available for msvc users.
> 
> The mpcodec filters use pre-processor defines such as HAVE_MMX for inline
> asm, given both mplayer and ffmpeg have a HAVE_MMX_INLINE define specific
> for inline asm then the preprocessors can be changed to the _INLINE
> variants which makes inline asm code compile as appropriate.
> 
> This patch has 2 parts, the first changes the pre-processors in mpcodecs to
> use the _INLINE variants. Logically this would appear to be the correct
> pre-processor for inline asm to begin with, if anyone knows of why the
> _INLINE variants werent/shouldnt be used then feel free to let me know.
> 
> The mpcodec patch will have to be pushed to upstream but assuming
> everything is ok then the second patch just updates ffmpegs configure to
> allow the mpcodecs filters without requiring inline asm.

did you post this to mplayer-dev ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] Discuss mp4 fragmented: TFDT::BaseMediaDecodeTime. TRUN::SampleDuration

2014-11-05 Thread Michael Niedermayer 
On Sun, Nov 02, 2014 at 06:16:58PM -0800, Alex Sukhanov wrote:
> *Hi ffmpeg-devel, I’m sending this mail in order to encourage some
> discussion about ISO BMFF specification and find out what people think
> about problems described below and if anybody else also have seen these
> problems.I’m software engineer and I write MP4 Muxer/Demuxer (It’s not
> FFmpeg code) which is then used to generate DASH streams (MP4 fragmented
> container). Some players reported playback issues so I had to provide some
> controversial patches in MP4 Muxer to make these players accepting streams
> generated by my Muxer. My current understanding is that these issues happen
> because people read ISO BMFF specification differently, so they expect
> different behavior.Below I would like to describe these issues and I would
> be glad to hear your opinion about that. The latest spec I have on hands is
> ISO/IEC 14496-12:2012. Fourth edition 2012-07-15, Corrected version
> 2012-09-15. TFDT::BaseMediaDecodeTimeISO BMFF standard defines
> TFDT::BaseMediaDecodeTime as is an integer equal to the sum of the decode
> durations of all earlier samples in the media:8.8.12 Track fragment decode
> timeThe Track Fragment Base Media Decode Time Box provides the absolute
> decode time, measured on the media timeline, of the first sample in decode
> order in the track fragment. This can be useful, for example, when
> performing random access in a file; it is not necessary to sum the sample
> durations of all preceding samples in previous fragments to find this value
> (where the sample durations are the deltas in the Decoding Time to Sample
> Box and the sample_durations in the preceding track
> runs)baseMediaDecodeTime is an integer equal to the sum of the decode
> durations of all earlier samples in the media, expressed in the media's
> timescale. It does not include the samples added in the enclosing track
> fragment.Player claims that TFDT::BaseMediaDecodeTime must be strictly
> equal to sum of all preceding sample decode durations. Most likely, Player
> side is absolutely right here, because specification just says
> “baseMediaDecodeTime is an integer equal to the sum of the decode durations
> of all earlier samples in the media” Unfortunately, strict following of the
> spec makes Transcoding/Muxing process much more complicated and flaky.
> Modern transcoding engines (for instance, YouTube and Vimeo) split video
> and chunks and transcode them in parallel. Parallel transcoding and frame
> rate conversion cause DTS/PTS fluctuation, so it becomes not trivial to
> follow TFDT::BaseMediaDecodTime and in most cases sample duration
> correction or sample dropping is required to follow this rule strictly. The
> most complicated thing is that in order to perform this correction for
> current fragment (MOOF+MDAT pair), we have to know DTS of first sample of
> the next fragment. We can not really get this information because of
> parallel processing, so we try to guess this value. We can do it for
> constant framerate, but for variable frame rate it’s a real issue. Frankly,
> current solution is flaky.Current TFDT::BaseMediaDecodeTime requirement
> also doesn’t address frame dropping and stream errors which may happen
> during live streaming/transcoding.What do you think about

> TFDT::BaseMediaDecodeTime?TRUN::SampleDurationMediaSourceExtensions
>  (MSE) specification authors think that
> TRUN::duraton in ISO BMFF spec is "sample duration". In another words
> TRUN::duration[n] = PTS[n+1] - PTS[n]. I always have been thinking that
> TRUN::duration is calculated as DTS[n+1] - DTS[n].In most cases delta DTS
> is equal to delta PTS, but because of timescale conversion rounding,
> DTS/PTS fluctuations caused by parallel processing and framerate
> conversion, it’s not true all the time. This mismatch causes holes on MSE
> playback timeline. Holes cause poor user experience.I went through ISO spec
> and I've seen that it is not clear. It explicitly says that STTS entries
> are decoding deltas:8.6.1.1 Time to Sample BoxesThe composition times (CT)
> and decoding times (DT) of samples are derived from the Time to Sample
> Boxes, of which there are two types. The decoding time is defined in the
> Decoding Time to Sample Box, giving time deltas between successive decoding
> times.8.6.1.2 Decoding Time to Sample BoxThe Decoding Time to Sample Box
> contains decode time delta's: DT(n+1) = DT(n) + STTS(n) where STTS(n) is
> the (uncompressed) table entry for sample n.As you can see, ISO spec is
> very clear about regular MP4 files. Unfortunately, it's not so clear about
> fragmented MP4 and atom TRUN:8.8.8 Track Fragment Run Box...The following
> flags are defined:...0x000100 sample-duration-present: indicates that each
> sample has its own duration, otherwise thedefault is usedI reviewed
> FFmpeg MOV Muxer code and it calculates TRUN::SampleDuration as DTS
> delta:http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat

Re: [FFmpeg-devel] Broken endian indication in pixfmt list

2014-11-05 Thread Michael Niedermayer 
On Wed, Nov 05, 2014 at 03:37:04AM +0100, wm4 wrote:
> On Wed, 5 Nov 2014 03:19:04 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Nov 05, 2014 at 02:59:45AM +0100, wm4 wrote:
> > > On Wed, 5 Nov 2014 02:44:12 +0100
> > > Michael Niedermayer  wrote:
> > > 
> > > > On Wed, Nov 05, 2014 at 02:13:29AM +0100, wm4 wrote:
> > > > > The header pixfmt.h contains the following comment in the pixel format
> > > > > list doxygen:
> > > > > 
> > > > >  * @note
> > > > >  * Make sure that all newly added big-endian formats have (pix_fmt & 
> > > > > 1) == 1
> > > > >  * and that all newly added little-endian formats have (pix_fmt & 1) 
> > > > > == 0.
> > > > >  * This allows simpler detection of big vs little-endian.
> > > > > 
> > > > 
> > > > > This is currently broken for the following formats: nv20le/be 
> > > > > gbrap16le/be
> > > > 
> > > > yes
> > > > 
> > > > 
> > > > > 
> > > > > Obviously, this can't be fixed until the next ABI bump. But more
> > > > 
> > > > can you post a patch which does make sure it gets fixed then?
> > > > and or that documentation corrected
> > > 
> > > As I said, I could write a patch that adds a proper flag, which the
> > > user can use to determine endian properties. I'd also adjust the
> > > documentation and inform the user that the old way doesn't work anymore.
> > 
> > iam fine with that but you might run into some obstacles
> > the flags are uint8_t and all used
> > adding a new field might require some care to ensure ABI compatibility
> > and might need accessor functions
> 
> I didn't realize that. It sort of ruins the idea.
> 

> I see two solutions without breaking ABI:
> - add a "flags2" member, which contains the flags; duplicate it, and
>   deprecate the old "flags" member
> - store the high bits of the "flags" member in a new "flags2" member,
>   and add an accessor which returns the full flags

these seem possible, yes
accessor(s) would be needed in the first case too though 


> 
> 
> There's also the deprecated av_pix_fmt_descriptors[] variable - if we
> care about this, extending AVPixFmtDescriptor is not possible without
> breaking ABI. And currently this symbol is actually exported.

yes, though there where changes previously already which changed it
see d2962e9f89cca6ff40f0c9d5ffc9c4397b8b1b26

also theres a potential hacky alternative, the last 2 chars of the
name could be checked for "le"/"be"


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH] Enable mpcodecs without needing inline asm

2014-11-05 Thread Carl Eugen Hoyos 
Matt Oliver  gmail.com> writes:

>  if anyone knows of why the _INLINE variants 
> werent/shouldnt be used then feel free to let me know.
  ^^

To keep the source code in sync with MPlayer iirc.

Carl Eugen

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

[FFmpeg-devel] Bypass video H264 IP UDP Multicast over FLV RTMP

2014-11-05 Thread Dang Duc Hung 
Hi

I’m using FFmpeg to convert UDP video to RTMP like that

ffmpeg -i "udp://x.x.x.x:xxx -vcodec copy -acodec aac -strict -2 -b:a 32k -ac 1 
-ar 32000 -f flv "rtmp://x.x.x.x/ app=testtv playpath=high"

And then convert RTMP output to HLS by Server

But when I use VLC player or other player to play link HLS, I only hear audio 
don’t see Video. 

Please give me some advise.

 

Best Regards

Đặng Đức Hưng

 

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