Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

2016-04-24 Thread Nicolas George 
Le sextidi 6 floréal, an CCXXIV, Andrey Utkin a écrit :
> Please look at my email in ffmpeg-devel
> '[PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"'
> it adds a check which allows to correctly handle both cases.

I will be able to look at this patch when it arrives, not before.

> The chunk which Nicolas proposes to drop makes good work for default
> (auto_convert=1) case and I wouldn't say that it shouldn't be there,
> that code just doesn't consider auto_convert=0 case.

I am not entirely convinced this is quite everything.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 2/2] avutil/log: added test case for av_log_format_line2

2016-04-24 Thread der_ghulbus 
From: Andreas Weis 

Signed-off-by: Andreas Weis 
---
 libavutil/log.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/libavutil/log.c b/libavutil/log.c
index 0efba7a..6d192b6 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -444,6 +444,17 @@ void avpriv_report_missing_feature(void *avc, const char 
*msg, ...)
 // LCOV_EXCL_START
 #include 
 
+int call_log_format_line2(const char *fmt, char *buffer, int buffer_size, ...)
+{
+va_list args;
+int ret;
+int print_prefix=1;
+va_start(args, buffer_size);
+ret = av_log_format_line2(NULL, AV_LOG_INFO, fmt, args, buffer, 
buffer_size, &print_prefix);
+va_end(args);
+return ret;
+}
+
 int main(int argc, char **argv)
 {
 int i;
@@ -458,6 +469,25 @@ int main(int argc, char **argv)
 }
 av_log(NULL, AV_LOG_PANIC, "\n");
 }
+{
+int result;
+char buffer[4];
+result = call_log_format_line2("foo", NULL, 0);
+if(result != 3) {
+printf("Test NULL buffer failed.\n");
+return 1;
+}
+result = call_log_format_line2("foo", buffer, 2);
+if(result != 3 || strncmp(buffer, "f", 2)) {
+printf("Test buffer too small failed.\n");
+return 1;
+}
+result = call_log_format_line2("foo", buffer, 4);
+if(result != 3 || strncmp(buffer, "foo", 4)) {
+printf("Test buffer sufficiently big failed.\n");
+return 1;
+}
+}
 return 0;
 }
 // LCOV_EXCL_STOP
-- 
2.5.0.windows.1

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

[FFmpeg-devel] [PATCH 1/2] avutil/log: added av_log_format_line2 which returns buffer length

2016-04-24 Thread der_ghulbus 
From: Andreas Weis 

The new function behaves the same as av_log_format_line, but also forwards
the return value from the underlying snprintf call. This will allow
callers to accurately determine the size requirements for the line buffer.

Signed-off-by: Andreas Weis 
---
 libavutil/log.c | 11 ++-
 libavutil/log.h | 17 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/libavutil/log.c b/libavutil/log.c
index 4583519..0efba7a 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -284,10 +284,19 @@ static void format_line(void *avcl, int level, const char 
*fmt, va_list vl,
 void av_log_format_line(void *ptr, int level, const char *fmt, va_list vl,
 char *line, int line_size, int *print_prefix)
 {
+av_log_format_line2(ptr, level, fmt, vl, line, line_size, print_prefix);
+}
+
+int av_log_format_line2(void *ptr, int level, const char *fmt, va_list vl,
+char *line, int line_size, int *print_prefix)
+{
 AVBPrint part[4];
+int ret;
+
 format_line(ptr, level, fmt, vl, part, print_prefix, NULL);
-snprintf(line, line_size, "%s%s%s%s", part[0].str, part[1].str, 
part[2].str, part[3].str);
+ret = snprintf(line, line_size, "%s%s%s%s", part[0].str, part[1].str, 
part[2].str, part[3].str);
 av_bprint_finalize(part+3, NULL);
+return ret;
 }
 
 void av_log_default_callback(void* ptr, int level, const char* fmt, va_list vl)
diff --git a/libavutil/log.h b/libavutil/log.h
index 321748c..9b1d66f 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -317,6 +317,23 @@ AVClassCategory av_default_get_category(void *ptr);
 void av_log_format_line(void *ptr, int level, const char *fmt, va_list vl,
 char *line, int line_size, int *print_prefix);
 
+/**
+ * Format a line of log the same way as the default callback.
+ * @param line  buffer to receive the formatted line;
+ *  may be NULL if line_size is 0
+ * @param line_size size of the buffer; at most line_size-1 characters will
+ *  be written to the buffer, plus one null terminator
+ * @param print_prefix  used to store whether the prefix must be printed;
+ *  must point to a persistent integer initially set to 1
+ * @return Returns a negative value if an error occured, otherwise returns
+ * the number of characters that would have been written for a
+ * sufficiently large buffer, not including the terminating null
+ * character. If the return value is not less than line_size, it means
+ * that the log message was truncated to fit the buffer.
+ */
+int av_log_format_line2(void *ptr, int level, const char *fmt, va_list vl,
+char *line, int line_size, int *print_prefix);
+
 #if FF_API_DLOG
 /**
  * av_dlog macros
-- 
2.5.0.windows.1

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

Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

2016-04-24 Thread Michael Niedermayer 
On Sun, Apr 24, 2016 at 11:55:06AM -0700, Dave Yeo wrote:
> On 04/23/16 12:53 PM, Michael Niedermayer wrote:
> >On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote:
> >>>On 04/20/16 03:48 PM, Dmitriy Kuminov wrote:
>  >I do care about consistency, collaboration and prevention of artificial
>  >entropy growth.
> >>>
> >>>One option is to make ln_s a configure option, something like the
> >>>attached, which is a work in progress as out of tree builds are
> >>>broken when using cp -p. Almost seems a failure in the code that
> >>>decides whether symlinks work.
> >>>Dave
> >>>
> >this seems not working
> >
> >./configure
> >./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied
> >rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory
> >
> 
> It's the correct output (I get similar even before this patch) when
> $ln_s="cp -p" as it tries to touch a file in a symlinked directory
> and correctly fails.

there are no error messages before here, also the ln_s and ln_s_default
are not connected i think
set_default or similar is missing


> Did you run make && make install after configuring?
> Here's the version I'll post later in a new thread, please test.

this seems to apply only "in reverse"


> Dave


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


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-24 Thread Michael Niedermayer 
On Sun, Apr 24, 2016 at 11:27:32AM +0100, Mark Thompson wrote:
> On 24/04/16 03:53, Michael Niedermayer wrote:
> > 0x47 is expected to be at [0] but the affected files contain something
> > else sometimes in its place that starts with 0x80 and is 12 bytes long
> > it contains some counter or timestamp
> > without the code above it will almost always work but if the counter
> > contains a 0x47 in it resync can start at the wrong byte
> > 
> > I dont know what created these kind of files, so even if iam not
> > hit by a bus i think i am not too usefull here
> > i was hoping a bit my patch would lead to someone recognizing this ...
> 
> Sounds like an RTP header.  (You can certainly imagine a very sucky RTP 
> receiver not bothering to do anything with the headers and hoping it all 
> works out.)
> 
> Is it a 16-bit counter in the third and fourth bytes, and a 32-bit timestamp 
> in the fifth to eighth?  
> 
> (Alternatively, link me to the sample and I'll have a look at it.)

http://samples.ffmpeg.org/ts/01c56b0dc1.ts

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH v2] pgssubdec: fix subpicture output colorspace and range

2016-04-24 Thread Carl Eugen Hoyos 
Jan Ekström  gmail.com> writes:

> Fixes #4637

Thank you!

Patch applied, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

2016-04-24 Thread Andrey Utkin 
On Sun, Apr 24, 2016 at 05:26:33PM +0200, Nicolas George wrote:
> Le sextidi 6 floréal, an CCXXIV, Derek Buitenhuis a écrit :
> > Removing this causes failures when concatdec is used to concat two H.264
> > streams from an MP4 source, when remuxed, IIRC.
> > 
> > Example: https://trac.ffmpeg.org/raw-attachment/ticket/3108/examplefiles.zip
> > 
> > ./ffmpeg -f concat -i tickets/3108/concatfile.txt -codec copy out.mp4
> 
> That may be true, but the fix is incorrect, and should not have sneaked
> during a completely unrelated merge. For the sake of tracking changes, I
> want to revert this, and then look for a more correct fix.
> 
> I will look at this example.
> 
> (Note that I am not accusing you of dishonesty; I know the merges are
> a tremendous work, especially the evil plans, and I guess keeping track of
> the extra changes necessary to get everything working is hard.)

Please look at my email in ffmpeg-devel
'[PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"'
it adds a check which allows to correctly handle both cases.

The chunk which Nicolas proposes to drop makes good work for default
(auto_convert=1) case and I wouldn't say that it shouldn't be there,
that code just doesn't consider auto_convert=0 case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

2016-04-24 Thread Dave Yeo 

On 04/23/16 12:53 PM, Michael Niedermayer wrote:

On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote:

>On 04/20/16 03:48 PM, Dmitriy Kuminov wrote:

> >I do care about consistency, collaboration and prevention of artificial
> >entropy growth.

>
>One option is to make ln_s a configure option, something like the
>attached, which is a work in progress as out of tree builds are
>broken when using cp -p. Almost seems a failure in the code that
>decides whether symlinks work.
>Dave
>

this seems not working

./configure
./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied
rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory



It's the correct output (I get similar even before this patch) when 
$ln_s="cp -p" as it tries to touch a file in a symlinked directory and 
correctly fails.

Did you run make && make install after configuring?
Here's the version I'll post later in a new thread, please test.
Dave
From 5604d27e7af75a61c4ee249c753fd617aca3f8bd Mon Sep 17 00:00:00 2001
From: Dave Yeo 
Date: Sun, 24 Apr 2016 11:08:53 -0700
Subject: [PATCH] configure: Allow choice in choosing a symlink command

Signed-off-by: Dave Yeo 
---
 configure | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 52ae9c5..8801729 100755
--- a/configure
+++ b/configure
@@ -4789,12 +4789,12 @@ esac
 link_dest=$(mktemp -u $TMPDIR/dest_)
 link_name=$(mktemp -u $TMPDIR/name_)
 mkdir "$link_dest"
-$ln_s_default "$link_dest" "$link_name"
+$ln_s "$link_dest" "$link_name"
 touch "$link_dest/test_file"
 if [ "$source_path" != "." ] && ([ ! -d src ] || [ -L src ]) && [ -e "$link_name/test_file" ]; then
 # create link to source path
 [ -e src ] && rm src
-$ln_s_default "$source_path" src
+$ln_s "$source_path" src
 source_link=src
 else
 # creating directory links doesn't work
@@ -6409,7 +6409,7 @@ AR_O=$ar_o
 RANLIB=$ranlib
 STRIP=$strip
 CP=cp -p
-LN_S=$ln_s_default
+LN_S=$ln_s
 CPPFLAGS=$CPPFLAGS
 CFLAGS=$CFLAGS
 CXXFLAGS=$CXXFLAGS
-- 
2.0.0

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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

2016-04-24 Thread Derek Buitenhuis 
On 4/24/2016 4:26 PM, Nicolas George wrote:
> That may be true, but the fix is incorrect, and should not have sneaked
> during a completely unrelated merge. For the sake of tracking changes, I
> want to revert this, and then look for a more correct fix.

The fix was deemed OK at the time by a few others, but by no means am I
claiming it was correct. I'll go with your word on it, since you know
the code best here.

> I will look at this example.

All right.

> (Note that I am not accusing you of dishonesty; I know the merges are
> a tremendous work, especially the evil plans, and I guess keeping track of
> the extra changes necessary to get everything working is hard.)

Didn't think you were, and thanks.

That particular merge (codecpar) was a team effort, though. All the commits
and issues were tracked on a github fork and branch, which still exists.
I do not plan to remove that branch, in case of regressions like this, in
which it can provide insight sometimes.

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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

2016-04-24 Thread Nicolas George 
Le sextidi 6 floréal, an CCXXIV, Derek Buitenhuis a écrit :
> Removing this causes failures when concatdec is used to concat two H.264
> streams from an MP4 source, when remuxed, IIRC.
> 
> Example: https://trac.ffmpeg.org/raw-attachment/ticket/3108/examplefiles.zip
> 
> ./ffmpeg -f concat -i tickets/3108/concatfile.txt -codec copy out.mp4

That may be true, but the fix is incorrect, and should not have sneaked
during a completely unrelated merge. For the sake of tracking changes, I
want to revert this, and then look for a more correct fix.

I will look at this example.

(Note that I am not accusing you of dishonesty; I know the merges are
a tremendous work, especially the evil plans, and I guess keeping track of
the extra changes necessary to get everything working is hard.)

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

2016-04-24 Thread Derek Buitenhuis 
On 4/24/2016 3:39 PM, Nicolas George wrote:
> Clearing the extradata is not related to the codecpar change,
> and it breaks if auto_convert is disabled.
> 
> Fix trac ticket #5461.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavformat/concatdec.c | 5 -
>  1 file changed, 5 deletions(-)

Removing this causes failures when concatdec is used to concat two H.264
streams from an MP4 source, when remuxed, IIRC.

Example: https://trac.ffmpeg.org/raw-attachment/ticket/3108/examplefiles.zip

./ffmpeg -f concat -i tickets/3108/concatfile.txt -codec copy out.mp4

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

[FFmpeg-devel] [PATCH v2] pgssubdec: fix subpicture output colorspace and range

2016-04-24 Thread Jan Ekström 
Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.

Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.

BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).
They were additionally confirmed by manually calculating values.

Fixes #4637
---
 libavcodec/pgssubdec.c | 10 --
 libavutil/colorspace.h | 10 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/libavcodec/pgssubdec.c b/libavcodec/pgssubdec.c
index 07a2a78..133d08b 100644
--- a/libavcodec/pgssubdec.c
+++ b/libavcodec/pgssubdec.c
@@ -354,8 +354,14 @@ static int parse_palette_segment(AVCodecContext *avctx,
 cb= bytestream_get_byte(&buf);
 alpha = bytestream_get_byte(&buf);
 
-YUV_TO_RGB1(cb, cr);
-YUV_TO_RGB2(r, g, b, y);
+/* Default to BT.709 colorimetry. In case of <= 576 height use BT.601 
*/
+if (avctx->height <= 0 || avctx->height > 576) {
+YUV_TO_RGB1_CCIR_BT709(cb, cr);
+} else {
+YUV_TO_RGB1_CCIR(cb, cr);
+}
+
+YUV_TO_RGB2_CCIR(r, g, b, y);
 
 ff_dlog(avctx, "Color %d := (%d,%d,%d,%d)\n", color_id, r, g, b, 
alpha);
 
diff --git a/libavutil/colorspace.h b/libavutil/colorspace.h
index 826ffd5..7d3f711 100644
--- a/libavutil/colorspace.h
+++ b/libavutil/colorspace.h
@@ -41,6 +41,16 @@
 b_add = FIX(1.77200*255.0/224.0) * cb + ONE_HALF;\
 }
 
+#define YUV_TO_RGB1_CCIR_BT709(cb1, cr1)\
+{\
+cb = (cb1) - 128;\
+cr = (cr1) - 128;\
+r_add = FIX(1.5747*255.0/224.0) * cr + ONE_HALF;\
+g_add = - FIX(0.1873*255.0/224.0) * cb - FIX(0.4682*255.0/224.0) * cr + \
+ONE_HALF;\
+b_add = FIX(1.8556*255.0/224.0) * cb + ONE_HALF;\
+}
+
 #define YUV_TO_RGB2_CCIR(r, g, b, y1)\
 {\
 y = ((y1) - 16) * FIX(255.0/219.0);\
-- 
2.5.5

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

[FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

2016-04-24 Thread Nicolas George 
Clearing the extradata is not related to the codecpar change,
and it breaks if auto_convert is disabled.

Fix trac ticket #5461.

Signed-off-by: Nicolas George 
---
 libavformat/concatdec.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index e3418e1..b2bab55 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -182,11 +182,6 @@ static int copy_stream_props(AVStream *st, AVStream 
*source_st)
 }
 if ((ret = avcodec_parameters_copy(st->codecpar, source_st->codecpar)) < 0)
 return ret;
-/* We don't want to carry around MP4-style extradata, since we are usoign 
a bsf anyway. */
-if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
-av_freep(&st->codecpar->extradata);
-st->codecpar->extradata_size = 0;
-}
 st->r_frame_rate= source_st->r_frame_rate;
 st->avg_frame_rate  = source_st->avg_frame_rate;
 st->time_base   = source_st->time_base;
-- 
2.8.0.rc3

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

[FFmpeg-devel] Cannot compile ffmpeg-0.10.16

2016-04-24 Thread Karl Weber 
Hi,

please excuse me, that I bother you with this old version of ffmpeg, however, 
javafx 8 requires libavcodec53 and libavformat53 on linux systems, which, as 
far as I know, requires that I compile ffmpeg 0.10.16. (My linux distribution 
provides only more recent versions of these libraries.)

Unfortunately, I do not succeed in building these libraries. Maybe you can 
give me some help, or point me to some other place, where I can get it.

Make produces the following error message:

/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: 
libavutil/intfloat_readwrite.o: relocation R_X86_64_PC32 against undefined 
symbol `ldexp@@GLIBC_2.2.5' can not be used when making a shared object; 
recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: 
final link failed: Bad value
collect2: error: ld returned 1 exit status
make: *** [libavutil/libavutil.so.51] Fehler 1

I configured ffmpeg with

./configure --prefix=/opt/ffmpeg_freedom --disable-static --enable-shared --
enable-gpl --enable-version3 --enable-nonfree 

Trying the same with the additional option --enable-pic didn't change 
anything.

Thanks in advance for any help!

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

Re: [FFmpeg-devel] [PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"

2016-04-24 Thread Andrey Utkin 
On Sun, Apr 24, 2016 at 04:28:38PM +0300, Andrey Utkin wrote:
> Bug ticket: http://trac.ffmpeg.org/ticket/5461
> This fix enables back the ability to concat appropriately encoded
> (with "-x264opts stitchable=1") MP4 files in less time, without conversion to
> mpegts and back.
> ---8<---

s/mpegts/Annex B/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-24 Thread Mark Thompson 
On 24/04/16 03:53, Michael Niedermayer wrote:
> 0x47 is expected to be at [0] but the affected files contain something
> else sometimes in its place that starts with 0x80 and is 12 bytes long
> it contains some counter or timestamp
> without the code above it will almost always work but if the counter
> contains a 0x47 in it resync can start at the wrong byte
> 
> I dont know what created these kind of files, so even if iam not
> hit by a bus i think i am not too usefull here
> i was hoping a bit my patch would lead to someone recognizing this ...

Sounds like an RTP header.  (You can certainly imagine a very sucky RTP 
receiver not bothering to do anything with the headers and hoping it all works 
out.)

Is it a 16-bit counter in the third and fourth bytes, and a 32-bit timestamp in 
the fifth to eighth?  

(Alternatively, link me to the sample and I'll have a look at it.)

- Mark

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