[FFmpeg-devel] [PATCH] fate: fix fate-vp8 dependencies

[James Almer]

Fix the demuxer dependencies in some of the tests and remove the vp8 decoder
dependency for the stream copy tests

Signed-off-by: James Almer 
---
 tests/fate/vpx.mak | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.mak
index f0bcfac..0212096 100644
--- a/tests/fate/vpx.mak
+++ b/tests/fate/vpx.mak
@@ -19,31 +19,31 @@ fate-vp60: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/ea-vp6/g36.vp6
 FATE_VP6-$(call DEMDEC, EA, VP6) += fate-vp61
 fate-vp61: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/ea-vp6/MovieSkirmishGondor.vp6 -t 4
 
-FATE_VP6-$(call DEMDEC, FLV, VP6A) += fate-vp6a
+FATE_VP6-$(call DEMDEC, MOV, VP6A) += fate-vp6a
 fate-vp6a: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/flash-vp6/300x180-Scr-f8-056alpha.mov
 
-FATE_VP6-$(call DEMDEC, FLV, VP6A) += fate-vp6a-skip_alpha
+FATE_VP6-$(call DEMDEC, MOV, VP6A) += fate-vp6a-skip_alpha
 fate-vp6a-skip_alpha: CMD = framecrc -flags +bitexact -skip_alpha 1 -i 
$(TARGET_SAMPLES)/flash-vp6/300x180-Scr-f8-056alpha.mov
 
 FATE_VP6-$(call DEMDEC, FLV, VP6F) += fate-vp6f
 fate-vp6f: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/flash-vp6/clip1024.flv
 
-FATE_VP8-$(call DEMDEC, FLV, VP8) += fate-vp8-alpha
+FATE_VP8-$(CONFIG_MATROSKA_DEMUXER) += fate-vp8-alpha
 fate-vp8-alpha: CMD = framecrc -i 
$(TARGET_SAMPLES)/vp8_alpha/vp8_video_with_alpha.webm -vcodec copy
 
-FATE_VP8-$(call DEMDEC, WEBM_DASH_MANIFEST, VP8) += fate-webm-dash-manifest
+FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += fate-webm-dash-manifest
 fate-webm-dash-manifest: CMD = run $(FFMPEG) -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_video1.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_video2.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_audio1.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_audio2.webm -c copy -map 0 -map 1 -map 2 -map 3 -f 
webm_dash_manifest -adaptation_sets "id=0,streams=0,1 id=1,streams=2,3" -
 
-FATE_VP8-$(call DEMDEC, WEBM_DASH_MANIFEST, VP8) += 
fate-webm-dash-manifest-unaligned-video-streams
+FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += 
fate-webm-dash-manifest-unaligned-video-streams
 fate-webm-dash-manifest-unaligned-video-streams: CMD = run $(FFMPEG) -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video3.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
 
-FATE_VP8-$(call DEMDEC, WEBM_DASH_MANIFEST, VP8) += 
fate-webm-dash-manifest-unaligned-audio-streams
+FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += 
fate-webm-dash-manifest-unaligned-audio-streams
 fate-webm-dash-manifest-unaligned-audio-streams: CMD = run $(FFMPEG) -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio3.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
 
-FATE_VP8-$(call DEMDEC, WEBM_DASH_MANIFEST, VP8) += 
fate-webm-dash-manifest-representations
+FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += 
fate-webm-dash-manifest-representations
 fate-webm-dash-manifest-representations: CMD = run $(FFMPEG) -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video4.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
 
-FATE_VP8-$(call DEMDEC, WEBM_DASH_MANIFEST, VP8) += 
fate-webm-dash-manifest-live
+FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += fate-webm-dash-manifest-live
 fate-webm-dash-manifest-live: CMD = run $(FFMPEG) -f webm_dash_manifest -live 
1 -i $(TARGET_SAMPLES)/vp8/dash_live_video_360.hdr -f webm_dash_manifest -live 
1 -i $(TARGET_SAMPLES)/vp8/dash_live_audio_171.hdr -c copy -map 0 -map 1 -f 
webm_dash_manifest -live 1 -adaptation_sets "id=0,streams=0 id=1,streams=1" 
-chunk_start_index 1 -chunk_duration_ms 5000 -time_shift_buffer_depth 7200 
-minimum_update_period 60 -debug_mode 1 -
 
 FATE_VP8-$(call DEMDEC, MATROSKA, VP8) += fate-vp8-2451
@@ -58,7 +58,7 @@ fate-vp7: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/vp7/potter-40.vp7
 VP8_SUITE = 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017
 
 define FATE_VP8_SUITE
-FATE_VP8-$(CONFIG_IVF_DEMUXER) += fate-vp8-test-vector$(2)-$(1)
+FATE_VP8-$(call DEMDEC, IVF, VP8) += fate-vp8-test-vector$(2)-$(1)
 fate-vp8-test-vector$(2)-$(1): CMD = framemd5 $(3) -i 
$(TARGET_SAMPLES)/vp8-test-vectors-r1/vp80-00-comprehensive-$(1).ivf
 fate-vp8-test-vector$(2)-$(1): REF = 
$(SRC_PATH)/tests/ref/fate/vp8-test-vector-$(1)
 endef
@@ -68,18 +68,18 @@ $(foreach N,$(VP8_SUITE),$(eval $(call 
FATE_VP8_SUITE,$(N),$(1),$(2
 
 # FIXME this file contains two frames with identical timestamps,
 # so ffmpeg drops one of them
-FATE_VP8-$(CONFIG_IVF_DEMUXER) += fate-vp8-sign-bias$(1)
+FATE_VP8-$(call DEMDEC, IVF, VP8) += fate-vp8-sign-bias$(1)
 

Re: [FFmpeg-devel] [PATCH 4/4] avformat: add an Ogg Video muxer

[Michael Niedermayer]

On Wed, Jul 06, 2016 at 08:25:27PM -0300, James Almer wrote:
> RFC 5334 recommendens this extension to go alongside the video/ogg
> mimetype for video files, with or without audio and subtitles [1].
> 
> [1] https://tools.ietf.org/html/rfc5334#section-10.2
> 
> Signed-off-by: James Almer 
> ---
> TODO: Version bump and changelog entry.
> 
>  configure|  1 +
>  libavformat/allformats.c |  1 +
>  libavformat/oggenc.c | 21 -
>  3 files changed, 22 insertions(+), 1 deletion(-)

should be ok

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/oggenc: make Vorbis audio the only default for ogg muxer

[Michael Niedermayer]

On Fri, Jul 08, 2016 at 12:08:14PM -0300, James Almer wrote:
> On 7/8/2016 4:22 AM, Michael Niedermayer wrote:
> > On Thu, Jul 07, 2016 at 11:02:30PM -0300, James Almer wrote:
> >> On 7/7/2016 10:55 PM, Michael Niedermayer wrote:
> >>> On Wed, Jul 06, 2016 at 08:25:26PM -0300, James Almer wrote:
>  While not enforced, RFC 5334 mentions that the .ogg extension should
>  be used for Vorbis audio files only.
> 
>  Signed-off-by: James Almer 
>  ---
>  This patch turns the ogg muxer into an audio only muxer to follow
>  the RFC's recommendation. The next patch in the set adds a new ogv
>  muxer to properly deal with video files.
> 
>  I doubt anyone out there tries to mux theora video using the .ogg
>  extension (even ffmpeg2theora seems to default to .ogv), so it's
>  unlikely it will affect people's normal workflow.
>  But if someone is against it then this patch can either be dropped
>  or changed to only remove flac from the defaults. That way video
>  can still be muxed.
> 
>  I personally prefer to apply this patch as is, though.
> 
>   libavformat/oggenc.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> >>>
> >>> breaks fate
> >>
> >> Yes, forgot to run fate for this set. It's caused by the fact the ogg
> >> muxer can't mux video streams anymore after this patch.
> >>
> >> I want to know if the actual change is acceptable first, then I'll
> >> resend the set with fate tests updated to use ogv muxer and similar
> >> changes.
> > 
> > making it impossible to mux video into .ogg seems a bit strange and
> > unexpected to me. Thats just my personal oppinion, iam not blocking
> > this ...
> 
> My intention is to remove the default behavior of trying to mux video
> into .ogg extension files, which as the RFC states is meant for Vorbis
> audio. Any combination of Video + Audio and/or Subtitles is meant to
> use the .ogv extension and video/ogg mimetype.
> 

> I couldn't find a way to remove that default behavior that doesn't
> forbid muxing video when using the Ogg Muxer altogether. If you know
> how then I'm happy to use it because my objective is not to remove
> functionality to the muxer, even if said funcionality will be
> available in the Ogv muxer, but to make sure it doesn't mux content it
> ideally shouldn't unless explicitly told.
> Ogg, Oga, Speex, Opus and now Ogv are all aliases to the same
> underlying muxer after all.

ff_ogg_muxer should implement query_codec()
this could through avformat_query_codec() check if a specific video
codec is supported

ffmpeg would probably need to be modified to check this
i think its around line 2050 in ffmpeg_opt.c
dont know if thats the only change needed


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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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/5] libmp3lame + mp3enc: removes decoder delay compensation

[Michael Niedermayer]

On Tue, Jul 12, 2016 at 04:19:53PM -0700, Jon Toohill wrote:
> initial_padding specifies only encoder delay, decoder delay is
> handled by start_skip_samples.
> ---
>  doc/APIchanges  | 4 
>  libavcodec/libmp3lame.c | 2 +-
>  libavcodec/version.h| 2 +-
>  libavformat/mp3enc.c| 4 ++--
>  4 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index d777dc0..ae450e1 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2016-07-12 - xxx - lavc 57.47.100 - libmp3lame.c
> +  Removed MP3 decoder delay from initial_padding in AVCodecContext.
> +  initial_padding only includes the encoder delay.
> +
>  2016-04-27 - xxx - lavu 55.23.100 - log.h
>Add a new function av_log_format_line2() which returns number of bytes
>written to the target buffer.
> diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
> index 5642264..198ac94 100644
> --- a/libavcodec/libmp3lame.c
> +++ b/libavcodec/libmp3lame.c
> @@ -137,7 +137,7 @@ static av_cold int mp3lame_encode_init(AVCodecContext 
> *avctx)
>  }
>  
>  /* get encoder delay */
> -avctx->initial_padding = lame_get_encoder_delay(s->gfp) + 528 + 1;
> +avctx->initial_padding = lame_get_encoder_delay(s->gfp);
>  ff_af_queue_init(avctx, >afq);
>  
>  avctx->frame_size  = lame_get_framesize(s->gfp);
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 0852b43..37a6e17 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -28,7 +28,7 @@
>  #include "libavutil/version.h"
>  
>  #define LIBAVCODEC_VERSION_MAJOR  57
> -#define LIBAVCODEC_VERSION_MINOR  46
> +#define LIBAVCODEC_VERSION_MINOR  47

master is at 50
release/3.1 is at 48

the issue described in the last patchset a moment ago
./ffmpeg -i  ~/videos/matrixbench_mpeg2.mpg  -acodec mp3 -vn -t 1 file.mp4

applies to teh new patch 1+2 too

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH 1/3] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters

[Michael Niedermayer]

On Tue, Jul 12, 2016 at 03:41:38PM -0700, Jon Toohill wrote:
> I'm having a hard time finding software that uses this via simple GitHub
> searches.

FFmpeg itself uses it


>
> I think this should be considered a bugfix, since the struct field states
> that it only represents encoder delay, not decoder delay. I'll send out an
> updated patchset that splits this into more patches, including
> documentation and another minor version bump.

heres a case that this patch breaks:
./ffmpeg -i  ~/videos/matrixbench_mpeg2.mpg  -acodec mp3 -vn -t 1 file.mp4
./ffprobe -show_packets -print_format compact file.mp4

this seems to require libmp3lame which is why it doesnt show up in fate

--- 3-old   2016-07-13 01:19:50.338105803 +0200
+++ 3-new   2016-07-13 01:18:59.354104729 +0200
@@ -1,43 +1,43 @@
-packet|codec_type=audio|stream_index=0|pts=-1105|pts_time=-0.023021|dts=-1105|dts_time=-0.023021|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=44|flags=K
-packet|codec_type=audio|stream_index=0|pts=47|pts_time=0.000979|dts=47|dts_time=0.000979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=428|flags=K
-packet|codec_type=audio|stream_index=0|pts=1199|pts_time=0.024979|dts=1199|dts_time=0.024979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=812|flags=K
-packet|codec_type=audio|stream_index=0|pts=2351|pts_time=0.048979|dts=2351|dts_time=0.048979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=1196|flags=K
-packet|codec_type=audio|stream_index=0|pts=3503|pts_time=0.072979|dts=3503|dts_time=0.072979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=1580|flags=K
-packet|codec_type=audio|stream_index=0|pts=4655|pts_time=0.096979|dts=4655|dts_time=0.096979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=1964|flags=K
-packet|codec_type=audio|stream_index=0|pts=5807|pts_time=0.120979|dts=5807|dts_time=0.120979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=2348|flags=K
-packet|codec_type=audio|stream_index=0|pts=6959|pts_time=0.144979|dts=6959|dts_time=0.144979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=2732|flags=K
-packet|codec_type=audio|stream_index=0|pts=8111|pts_time=0.168979|dts=8111|dts_time=0.168979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=3116|flags=K
-packet|codec_type=audio|stream_index=0|pts=9263|pts_time=0.192979|dts=9263|dts_time=0.192979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=3500|flags=K
-packet|codec_type=audio|stream_index=0|pts=10415|pts_time=0.216979|dts=10415|dts_time=0.216979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=3884|flags=K
-packet|codec_type=audio|stream_index=0|pts=11567|pts_time=0.240979|dts=11567|dts_time=0.240979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=4268|flags=K
-packet|codec_type=audio|stream_index=0|pts=12719|pts_time=0.264979|dts=12719|dts_time=0.264979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=4652|flags=K
-packet|codec_type=audio|stream_index=0|pts=13871|pts_time=0.288979|dts=13871|dts_time=0.288979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=5036|flags=K
-packet|codec_type=audio|stream_index=0|pts=15023|pts_time=0.312979|dts=15023|dts_time=0.312979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=5420|flags=K
-packet|codec_type=audio|stream_index=0|pts=16175|pts_time=0.336979|dts=16175|dts_time=0.336979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=5804|flags=K
-packet|codec_type=audio|stream_index=0|pts=17327|pts_time=0.360979|dts=17327|dts_time=0.360979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=6188|flags=K
-packet|codec_type=audio|stream_index=0|pts=18479|pts_time=0.384979|dts=18479|dts_time=0.384979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=6572|flags=K
-packet|codec_type=audio|stream_index=0|pts=19631|pts_time=0.408979|dts=19631|dts_time=0.408979|duration=1152|duration_time=0.024000|convergence_duration=N/A|convergence_duration_time=N/A|size=384|pos=6956|flags=K

[FFmpeg-devel] [PATCH 2/5] libmp3lame + mp3enc: removes decoder delay compensation

[Jon Toohill]

initial_padding specifies only encoder delay, decoder delay is
handled by start_skip_samples.
---
 doc/APIchanges  | 4 
 libavcodec/libmp3lame.c | 2 +-
 libavcodec/version.h| 2 +-
 libavformat/mp3enc.c| 4 ++--
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index d777dc0..ae450e1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2016-07-12 - xxx - lavc 57.47.100 - libmp3lame.c
+  Removed MP3 decoder delay from initial_padding in AVCodecContext.
+  initial_padding only includes the encoder delay.
+
 2016-04-27 - xxx - lavu 55.23.100 - log.h
   Add a new function av_log_format_line2() which returns number of bytes
   written to the target buffer.
diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index 5642264..198ac94 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -137,7 +137,7 @@ static av_cold int mp3lame_encode_init(AVCodecContext 
*avctx)
 }
 
 /* get encoder delay */
-avctx->initial_padding = lame_get_encoder_delay(s->gfp) + 528 + 1;
+avctx->initial_padding = lame_get_encoder_delay(s->gfp);
 ff_af_queue_init(avctx, >afq);
 
 avctx->frame_size  = lame_get_framesize(s->gfp);
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 0852b43..37a6e17 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  57
-#define LIBAVCODEC_VERSION_MINOR  46
+#define LIBAVCODEC_VERSION_MINOR  47
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index de63401..3b77d29 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -249,10 +249,10 @@ static int mp3_write_xing(AVFormatContext *s)
 avio_w8(dyn_ctx, 0);  // unknown abr/minimal bitrate
 
 // encoder delay
-if (par->initial_padding - 528 - 1 >= 1 << 12) {
+if (par->initial_padding >= 1 << 12) {
 av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
 }
-avio_wb24(dyn_ctx, FFMAX(par->initial_padding - 528 - 1, 0)<<12);
+avio_wb24(dyn_ctx, par->initial_padding << 12);
 
 avio_w8(dyn_ctx,   0); // misc
 avio_w8(dyn_ctx,   0); // mp3gain
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 4/5] ffmpeg: copy trailing_padding when using -acodec copy

[Jon Toohill]

---
 ffmpeg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ffmpeg.c b/ffmpeg.c
index 652774f..442f818 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3001,6 +3001,7 @@ static int transcode_init(void)
 enc_ctx->audio_service_type = dec_ctx->audio_service_type;
 enc_ctx->block_align= dec_ctx->block_align;
 enc_ctx->initial_padding= dec_ctx->delay;
+enc_ctx->trailing_padding   = dec_ctx->trailing_padding;
 enc_ctx->profile= dec_ctx->profile;
 #if FF_API_AUDIOENC_DELAY
 enc_ctx->delay  = dec_ctx->delay;
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 5/5] lavf/mp3enc: write trailing_padding in Xing header

[Jon Toohill]

---
 libavformat/mp3enc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index 3b77d29..da70d13 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -248,11 +248,14 @@ static int mp3_write_xing(AVFormatContext *s)
 avio_w8(dyn_ctx, 0);  // unknown encoding flags
 avio_w8(dyn_ctx, 0);  // unknown abr/minimal bitrate
 
-// encoder delay
+// encoder delay/padding
 if (par->initial_padding >= 1 << 12) {
 av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
 }
-avio_wb24(dyn_ctx, par->initial_padding << 12);
+if (par->trailing_padding >= 1 << 12) {
+av_log(s, AV_LOG_WARNING, "Too many samples of trailing padding.\n");
+}
+avio_wb24(dyn_ctx, (par->initial_padding << 12) | (par->trailing_padding & 
0xFFF));
 
 avio_w8(dyn_ctx,   0); // misc
 avio_w8(dyn_ctx,   0); // mp3gain
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 3/5] lavc: show gapless info in stream summary

[Jon Toohill]

Also adds trailing_padding to AVCodecContext to match
AVCodecParameters so that it doesn't get lost when mapping
between them.
---
 doc/APIchanges   |  4 
 libavcodec/avcodec.h | 11 +++
 libavcodec/utils.c   | 40 +++-
 libavcodec/version.h |  2 +-
 4 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index ae450e1..6e92cd4 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2016-07-12 - xxx - lavc 57.48.100 - avcodec.h
+  Add trailing_padding to AVCodecContext to match the corresponding
+  field in AVCodecParameters.
+
 2016-07-12 - xxx - lavc 57.47.100 - libmp3lame.c
   Removed MP3 decoder delay from initial_padding in AVCodecContext.
   initial_padding only includes the encoder delay.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 0181eb1..700c9b8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3504,6 +3504,17 @@ typedef struct AVCodecContext {
 #define FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS 1
 #endif
 
+/**
+ * Audio only. The amount of padding (in samples) appended by the encoder 
to
+ * the end of the audio. I.e. this number of decoded samples must be
+ * discarded by the caller from the end of the stream to get the original
+ * audio without any trailing padding.
+ *
+ * - decoding: unused
+ * - encoding: unused
+ */
+int trailing_padding;
+
 } AVCodecContext;
 
 AVRational av_codec_get_pkt_timebase (const AVCodecContext *avctx);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 402a9d8..481e09c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3252,6 +3252,10 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 && enc->bits_per_raw_sample != 
av_get_bytes_per_sample(enc->sample_fmt) * 8)
 snprintf(buf + strlen(buf), buf_size - strlen(buf),
  " (%d bit)", enc->bits_per_raw_sample);
+if (enc->initial_padding || enc->trailing_padding) {
+snprintf(buf + strlen(buf), buf_size - strlen(buf),
+ ", delay %d, padding %d", enc->initial_padding, 
enc->trailing_padding);
+}
 break;
 case AVMEDIA_TYPE_DATA:
 if (av_log_get_level() >= AV_LOG_DEBUG) {
@@ -4097,14 +4101,15 @@ int avcodec_parameters_from_context(AVCodecParameters 
*par,
 par->video_delay = codec->has_b_frames;
 break;
 case AVMEDIA_TYPE_AUDIO:
-par->format  = codec->sample_fmt;
-par->channel_layout  = codec->channel_layout;
-par->channels= codec->channels;
-par->sample_rate = codec->sample_rate;
-par->block_align = codec->block_align;
-par->frame_size  = codec->frame_size;
-par->initial_padding = codec->initial_padding;
-par->seek_preroll= codec->seek_preroll;
+par->format   = codec->sample_fmt;
+par->channel_layout   = codec->channel_layout;
+par->channels = codec->channels;
+par->sample_rate  = codec->sample_rate;
+par->block_align  = codec->block_align;
+par->frame_size   = codec->frame_size;
+par->initial_padding  = codec->initial_padding;
+par->trailing_padding = codec->trailing_padding;
+par->seek_preroll = codec->seek_preroll;
 break;
 case AVMEDIA_TYPE_SUBTITLE:
 par->width  = codec->width;
@@ -4151,15 +4156,16 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
 codec->has_b_frames   = par->video_delay;
 break;
 case AVMEDIA_TYPE_AUDIO:
-codec->sample_fmt  = par->format;
-codec->channel_layout  = par->channel_layout;
-codec->channels= par->channels;
-codec->sample_rate = par->sample_rate;
-codec->block_align = par->block_align;
-codec->frame_size  = par->frame_size;
-codec->delay   =
-codec->initial_padding = par->initial_padding;
-codec->seek_preroll= par->seek_preroll;
+codec->sample_fmt   = par->format;
+codec->channel_layout   = par->channel_layout;
+codec->channels = par->channels;
+codec->sample_rate  = par->sample_rate;
+codec->block_align  = par->block_align;
+codec->frame_size   = par->frame_size;
+codec->delay=
+codec->initial_padding  = par->initial_padding;
+codec->trailing_padding = par->trailing_padding;
+codec->seek_preroll = par->seek_preroll;
 break;
 case AVMEDIA_TYPE_SUBTITLE:
 codec->width  = par->width;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 37a6e17..412fd01 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include 

[FFmpeg-devel] [PATCH 1/5] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters

[Jon Toohill]

---
 libavformat/mp3dec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 56c7f8c..345fa88 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -239,6 +239,8 @@ static void mp3_parse_info_tag(AVFormatContext *s, AVStream 
*st,
 
 mp3->start_pad = v>>12;
 mp3->  end_pad = v&4095;
+st->codecpar->initial_padding = mp3->start_pad;
+st->codecpar->trailing_padding = mp3->end_pad;
 st->start_skip_samples = mp3->start_pad + 528 + 1;
 if (mp3->frames) {
 st->first_discard_sample = -mp3->end_pad + 528 + 1 + mp3->frames * 
(int64_t)spf;
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 0/5] Pass Xing gapless metadata to users during mp3 parsing

[Jon Toohill]

These patches expose the encoder delay/padding parsed from an mp3's Xing header 
to users of lavc/lavf, and show gapless info in the stream summary string. They 
also change ffmpeg to pass Xing gapless metadata from input to output when 
using -acodec copy.

trailing_padding is still not set properly when encoding with libmp3lame, 
causing an encode/decode round trip to add trailing silence. This is not a 
regression from current behavior, and will be addressed in a separate patch set.

Jon Toohill (5):
  lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters
  libmp3lame + mp3enc: removes decoder delay compensation
  lavc: show gapless info in stream summary
  ffmpeg: copy trailing_padding when using -acodec copy
  lavf/mp3enc: write trailing_padding in Xing header

 doc/APIchanges  |  8 
 ffmpeg.c|  1 +
 libavcodec/avcodec.h| 11 +++
 libavcodec/libmp3lame.c |  2 +-
 libavcodec/utils.c  | 40 +++-
 libavcodec/version.h|  2 +-
 libavformat/mp3dec.c|  2 ++
 libavformat/mp3enc.c|  9 ++---
 8 files changed, 53 insertions(+), 22 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/oggparsevp8: fix pts calculation on pages ending with an invisible frame

[James Almer]

On 7/12/2016 7:52 PM, Moritz Barsnick wrote:
> On Tue, Jul 12, 2016 at 18:36:20 -0300, James Almer wrote:
>> +uint32_t invcnt = !((granule >> 30) & 3);
> 
> If it's just for storing a 0/1 (bool, basically), wouldn't you use the
> more unspecific type "int"? (Not sure whether it matters at all.)
> 
> Moritz

Yeah, int should suffice. I used uint32_t for alignment purposes
with the other variables, but then i added the comment and that
became superfluous i guess.

Changed locally.

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/oggparsevp8: fix pts calculation on pages ending with an invisible frame

[Moritz Barsnick]

On Tue, Jul 12, 2016 at 18:36:20 -0300, James Almer wrote:
> +uint32_t invcnt = !((granule >> 30) & 3);

If it's just for storing a 0/1 (bool, basically), wouldn't you use the
more unspecific type "int"? (Not sure whether it matters at all.)

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/oggenc: add vp8 muxing support

[Moritz Barsnick]

On Tue, Jul 12, 2016 at 18:36:22 -0300, James Almer wrote:
> +/** for VP8 granule */

Spurious asterisk. ;-)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters

[Jon Toohill]

I'm having a hard time finding software that uses this via simple GitHub
searches.

I think this should be considered a bugfix, since the struct field states
that it only represents encoder delay, not decoder delay. I'll send out an
updated patchset that splits this into more patches, including
documentation and another minor version bump.


Jon Toohill |  Google Play Music |  jtooh...@google.com |  (650) 215-0770

On Fri, Jun 17, 2016 at 5:32 PM, Michael Niedermayer  wrote:

> On Thu, Jun 16, 2016 at 11:16:05AM -0700, Jon Toohill wrote:
> > Also removes decoder delay compensation from libmp3lame and mp3enc.
> > initial_padding specifies only encoder delay, decoder delay is
> > handled by start_skip_samples.
> > ---
> >  libavcodec/libmp3lame.c | 2 +-
> >  libavformat/mp3dec.c| 2 ++
> >  libavformat/mp3enc.c| 9 ++---
> >  3 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
> > index 5642264..198ac94 100644
> > --- a/libavcodec/libmp3lame.c
> > +++ b/libavcodec/libmp3lame.c
> > @@ -137,7 +137,7 @@ static av_cold int
> mp3lame_encode_init(AVCodecContext *avctx)
> >  }
> >
> >  /* get encoder delay */
> > -avctx->initial_padding = lame_get_encoder_delay(s->gfp) + 528 + 1;
> > +avctx->initial_padding = lame_get_encoder_delay(s->gfp);
> >  ff_af_queue_init(avctx, >afq);
> >
> >  avctx->frame_size  = lame_get_framesize(s->gfp);
>
> you are changing a field of the public API
> changing public API without major version bumps is tricky, we dont want
> to break applications linkng to a newer lib
>
> is there software that uses this?
> software that would break if this is applied ? (or maybe it wuld fix
> some software usig it)
>
> If this is a bugfix it should be documented in APIChanges with
> minor version bumps, any available references to specifications
> should be added too
>
> Such bugfix should also be seperate of other unrelated changes
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
> ___
> 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] [PATCH] Avoid sending packets to network when multicast ttl is 0 in udp

[Moritz Barsnick]

On Tue, Jul 12, 2016 at 18:31:36 +0430, Omid Ghaffarinia wrote:

Your mailer has broken the patch by inserting line breaks. You should
try attaching the patch as a file, or directly using "git send-email".

> Bug is due to kernel handling multicast ttl 0 differently (as noted in
> kernel code net/ipv4/route.c:2191 see:

ffmpeg is not a Linux-only tool/library, so comments should point out
which "kernel" more precisely (and possibly which versions this applies
to). Admitted, the link to github contains the string "linux". ;-)

Furthermore: Please explain what the actual bug (i.e. misbehavior) is,
and what this fix changes (or how it fixes it). 

Are you allowing ffmpeg to work when the user is making use of the
kernel hack?

What does this patch achieve on non-Linux operating systems?

(Sorry for the stupid questions, all this isn't obvious to me, and I do
have at least some understanding of network stuff.)

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

Re: [FFmpeg-devel] [PATCH 2/2] refine the method option describe of hlsenc doc

[Moritz Barsnick]

On Tue, Jul 12, 2016 at 21:36:54 +0800, Steven Liu wrote:
> resend the patch, delete the trailing whitespace and check patch by
> ./tools/patcheck

I reviewed the older patch (sorry!), but the grammar comments still
apply.

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

Re: [FFmpeg-devel] [PATCH 2/2] refine the method option describe of hlsenc doc

[Moritz Barsnick]

On Tue, Jul 12, 2016 at 11:55:39 +0800, Steven Liu wrote:

Grammar:

> +@item method
> +Use HTTP method to operation the hls files,

-> "Use the given HTTP method to create the hls files."
Or something like this. I couldn't figure it out from the code: How
about listing the allowed methods?

> +This example will upload all the mpegts segment files to HTTP server use 
> HTTP PUT method,
> +and update the m3u8 files every refresh times use HTTP PUT method.

-> "This example will upload all the mpegts segment files to the HTTP
   server using the HTTP PUT method, and update the m3u8 files every
   @code{refresh} times using the same method."

> +Note the HTTP server must support the PUT method and upload files.
-> "Note that the HTTP server must support the given method for
   uploading files."

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

Re: [FFmpeg-devel] [PATCH] news: make an annoucement about the future of ffserver

[Lou Logan]

On Mon, 11 Jul 2016 23:20:13 +0100, Rostislav Pehlivanov wrote:

> Removed the "in a clean way", it was unnencessary anyway as the "new APIs"
> were already implied to be nicer earlier.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  src/index | 9 +
>  1 file changed, 9 insertions(+)

LGTM and pushed and tweeted.

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

[FFmpeg-devel] [PATCH 3/3] avformat/oggenc: add vp8 muxing support

[James Almer]

Addresses ticket #5687

Signed-off-by: James Almer 
---
AVFMT_TS_NONSTRICT is added to flags because invisible vp8 frames don't
increase the pts

 libavformat/oggenc.c| 94 +
 tests/fate/avformat.mak |  1 +
 tests/lavf-regression.sh|  4 ++
 tests/ref/lavf-fate/ogg_vp8 |  3 ++
 4 files changed, 94 insertions(+), 8 deletions(-)
 create mode 100644 tests/ref/lavf-fate/ogg_vp8

diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 952261b..230dbf1 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -54,6 +54,8 @@ typedef struct OGGStreamContext {
 int kfgshift;
 int64_t last_kf_pts;
 int vrev;
+/** for VP8 granule */
+int isvp8;
 int eos;
 unsigned page_count; ///< number of page buffered
 OGGPage page; ///< current page
@@ -146,7 +148,8 @@ static int ogg_write_page(AVFormatContext *s, OGGPage 
*page, int extra_flags)
 
 static int ogg_key_granule(OGGStreamContext *oggstream, int64_t granule)
 {
-return oggstream->kfgshift && !(granule & ((1kfgshift && !(granule & ((1isvp8&& !((granule >> 3) & 0x07ff));
 }
 
 static int64_t ogg_granule_to_timestamp(OGGStreamContext *oggstream, int64_t 
granule)
@@ -154,6 +157,8 @@ static int64_t ogg_granule_to_timestamp(OGGStreamContext 
*oggstream, int64_t gra
 if (oggstream->kfgshift)
 return (granule>>oggstream->kfgshift) +
 (granule & ((1isvp8)
+return granule >> 32;
 else
 return granule;
 }
@@ -219,11 +224,11 @@ static int ogg_buffer_data(AVFormatContext *s, AVStream 
*st,
 int i, segments, len, flush = 0;
 
 // Handles VFR by flushing page because this frame needs to have a 
timestamp
-// For theora, keyframes also need to have a timestamp to correctly mark
+// For theora and VP8, keyframes also need to have a timestamp to 
correctly mark
 // them as such, otherwise seeking will not work correctly at the very
 // least with old libogg versions.
 // Do not try to flush header packets though, that will create broken 
files.
-if (st->codecpar->codec_id == AV_CODEC_ID_THEORA && !header &&
+if ((st->codecpar->codec_id == AV_CODEC_ID_THEORA || 
st->codecpar->codec_id == AV_CODEC_ID_VP8) && !header &&
 (ogg_granule_to_timestamp(oggstream, granule) >
  ogg_granule_to_timestamp(oggstream, oggstream->last_granule) + 1 ||
  ogg_key_granule(oggstream, granule))) {
@@ -405,6 +410,57 @@ static int ogg_build_opus_headers(AVCodecParameters *par,
 return 0;
 }
 
+#define VP8_HEADER_SIZE 26
+
+static int ogg_build_vp8_headers(AVFormatContext *s, AVStream *st,
+ OGGStreamContext *oggstream, int bitexact)
+{
+AVCodecParameters *par = st->codecpar;
+uint8_t *p;
+
+/* first packet: VP8 header */
+p = av_mallocz(VP8_HEADER_SIZE);
+if (!p)
+return AVERROR(ENOMEM);
+oggstream->header[0] = p;
+oggstream->header_len[0] = VP8_HEADER_SIZE;
+bytestream_put_byte(, 0x4f); // HDRID
+bytestream_put_buffer(, "VP80", 4); // Identifier
+bytestream_put_byte(, 1); // HDRTYP
+bytestream_put_byte(, 1); // VMAJ
+bytestream_put_byte(, 0); // VMIN
+bytestream_put_be16(, par->width);
+bytestream_put_be16(, par->height);
+bytestream_put_be24(, par->sample_aspect_ratio.num);
+bytestream_put_be24(, par->sample_aspect_ratio.den);
+if (st->r_frame_rate.num > 0 && st->r_frame_rate.den > 0) {
+// OggVP8 requires pts to increase by 1 per visible frame, so use the 
least common
+// multiple framerate if available.
+av_log(s, AV_LOG_DEBUG, "Changing time base from %d/%d to %d/%d\n",
+   st->time_base.num, st->time_base.den,
+   st->r_frame_rate.den, st->r_frame_rate.num);
+avpriv_set_pts_info(st, 64, st->r_frame_rate.den, 
st->r_frame_rate.num);
+}
+bytestream_put_be32(, st->time_base.den);
+bytestream_put_be32(, st->time_base.num);
+
+/* optional second packet: VorbisComment */
+if (av_dict_get(st->metadata, "", NULL, AV_DICT_IGNORE_SUFFIX)) {
+p = ogg_write_vorbiscomment(7, bitexact, >header_len[1], 
>metadata, 0);
+if (!p)
+return AVERROR(ENOMEM);
+oggstream->header[1] = p;
+bytestream_put_byte(, 0x4f); // HDRID
+bytestream_put_buffer(, "VP80", 4); // Identifier
+bytestream_put_byte(, 2); // HDRTYP
+bytestream_put_byte(, 0x20);
+}
+
+oggstream->isvp8 = 1;
+
+return 0;
+}
+
 static void ogg_write_pages(AVFormatContext *s, int flush)
 {
 OGGContext *ogg = s->priv_data;
@@ -452,12 +508,14 @@ static int ogg_write_header(AVFormatContext *s)
 st->codecpar->codec_id != AV_CODEC_ID_THEORA &&
 st->codecpar->codec_id != AV_CODEC_ID_SPEEX  &&
 

[FFmpeg-devel] [PATCH 1/3] avformat/oggparsevp8: fix pts calculation on pages ending with an invisible frame

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/oggparsevp8.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/oggparsevp8.c b/libavformat/oggparsevp8.c
index d57419e..3ba5375 100644
--- a/libavformat/oggparsevp8.c
+++ b/libavformat/oggparsevp8.c
@@ -82,7 +82,11 @@ static uint64_t vp8_gptopts(AVFormatContext *s, int idx,
 struct ogg *ogg = s->priv_data;
 struct ogg_stream *os = ogg->streams + idx;
 
-uint64_t pts  = (granule >> 32);
+uint32_t invcnt = !((granule >> 30) & 3);
+// If page granule is that of an invisible vp8 frame, its pts will be
+// that of the end of the next visible frame. We substract 1 for those
+// to prevent messing up pts calculations.
+uint64_t pts  = (granule >> 32) - invcnt;
 uint32_t dist = (granule >>  3) & 0x07ff;
 
 if (!dist)
-- 
2.9.0

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

[FFmpeg-devel] [PATCH 2/3] avformat/oggenc: fix page duration calculation when granule differs from timestamp

[James Almer]

Signed-off-by: James Almer 
---
No changes from the previous standalone version, but i'm resending
it since it's needed by the next patch.

 libavformat/oggenc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 6940a7b..952261b 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -193,7 +193,7 @@ static int ogg_buffer_page(AVFormatContext *s, 
OGGStreamContext *oggstream)
 return AVERROR(ENOMEM);
 l->page = oggstream->page;
 
-oggstream->page.start_granule = oggstream->page.granule;
+oggstream->page.start_granule = ogg_granule_to_timestamp(oggstream, 
oggstream->page.granule);
 oggstream->page_count++;
 ogg_reset_cur_page(oggstream);
 
@@ -265,8 +265,8 @@ static int ogg_buffer_data(AVFormatContext *s, AVStream *st,
 
 int64_t start = av_rescale_q(page->start_granule, st->time_base,
  AV_TIME_BASE_Q);
-int64_t next  = av_rescale_q(page->granule, st->time_base,
- AV_TIME_BASE_Q);
+int64_t next  = av_rescale_q(ogg_granule_to_timestamp(oggstream, 
page->granule),
+ st->time_base, AV_TIME_BASE_Q);
 
 if (page->segments_count == 255) {
 ogg_buffer_page(s, oggstream);
-- 
2.9.0

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

Re: [FFmpeg-devel] [PATCH 4/5] af_hdcd: don't log full HDCD stats if HDCD was not detected

[Michael Niedermayer]

On Tue, Jul 12, 2016 at 12:54:09PM -0500, Burt P wrote:
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)

applied

thanks

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer

[Marton Balint]

On Tue, 12 Jul 2016, Nicolas George wrote:


Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit :

The fifo muxer never returns EAGAIN. It silently drops the packets in
non-blocking mode on a full queue. This behaviour is useful for the tee
muxer case, when you don't want one slow/unreliable (network) output to
block reading the input, therefore blocking fast outputs (disk) as well.


Wait a minute. This is way to specific to be the default behaviour, let
alone the only one.


As far as I know, in the current API, if the user gets a negative return
value from av_write_frame(), it should be handled as a fatal error. EAGAIN
is not handled/interpreted specially. The same is true for
av_write_trailer(), and calling av_write_trailer - regardless of the return
value - frees all private resources for the context as well, so you cannot
change the semantics of av_write_trailer to not free private data in case of
EAGAIN, because it would cause unfreed data for legacy users.


You are wrong. Returning EAGAIN so that the caller try again later is the
normal behaviour for muxers that support non-blocking operation. I grant you
that there are only between one and three of them, but still, that is how
they work.
And that is also how they are supposed to work, because that is how
non-blocking protocols work, and also how non-blocking works outside FFmpeg.


Please point me to an application which uses ffmpeg non-blocking mode like 
it is supposed to be used. I don't see any muxers wich return EAGAIN, only 
protocols, and they only return EAGAIN if AVIO_FLAG_NONBLOCK is set. I 
wonder how that can work for av_write_trailer, because - as I mentioned 
earlier -, av_write_trailer must free private data, so you simply cannot 
call it multiple times.


Prove me wrong, but I have a feeling that the current AVIO_FLAG_NONBLOCK 
mode in ffmpeg was mostly tested for input, never for output, it does 
not work properly for output, and to be frank I don't want to get into 
fixing it, when our goals can be achieved without dealing with this 
problem.


Therefore I would like to keep the fifo muxer as Jan submitted it, without 
EAGAIN support. If there is a use case for non-blockingingness in a sense 
you use the phrase, then it can be added later.


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

Re: [FFmpeg-devel] [PATCH 1/5] af_hdcd: integrate() renamed hdcd_integrate() to be consistent with the other function names

[Michael Niedermayer]

On Tue, Jul 12, 2016 at 12:54:06PM -0500, Burt P wrote:
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

applied

thanks

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] libavcodec/libvpx: Add VPx alpha decode support

[James Almer]

On 7/12/2016 3:48 PM, Vignesh Venkatasubramanian wrote:
> VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
> ability to decode such files with alpha channel.
> 
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  libavcodec/libvpxdec.c  | 102 +---
>  tests/fate/vpx.mak  |   3 +
>  tests/ref/fate/vp8-alpha-decode | 125 
> 
>  3 files changed, 210 insertions(+), 20 deletions(-)
>  create mode 100644 tests/ref/fate/vp8-alpha-decode
> 

What's the first libvpx version that supports vp8a and vp9a?
Configure currently checks for 0.9.1 as the oldest supported
version for vp8 decoding, 0.9.7 for vp8 encoding, and 1.3.0 for
both vp9 components. We then use a bunch of ifdeffery to make
sure things compile with every version supported, so depending
on the answer to the above question this patch (and the one
adding vp9a enconding) may need to do the same, or it could be
a good reason to clean up things a bit and bump the minimum
required version for every component to for example 1.3.0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] refine the doc of hlsenc

[Michael Niedermayer]

On Tue, Jul 12, 2016 at 09:35:46PM +0800, Steven Liu wrote:
> resend the patch, delete the trailing whitespace and check patch by
> ./tools/patcheck
> 
> add the hls_flags round_durations, discont_start, omit_endlist flags
> describe
> 
> Signed-off-by: LiuQi 
> ---
>  doc/muxers.texi |   12 
>  1 files changed, 12 insertions(+), 0 deletions(-)

I think a native english speaker should review this and the other
patch

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] libavcodec/libvpx: Add VPx alpha decode support

[James Almer]

On 7/12/2016 3:48 PM, Vignesh Venkatasubramanian wrote:
> VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
> ability to decode such files with alpha channel.
> 
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  libavcodec/libvpxdec.c  | 102 +---
>  tests/fate/vpx.mak  |   3 +
>  tests/ref/fate/vp8-alpha-decode | 125 
> 
>  3 files changed, 210 insertions(+), 20 deletions(-)
>  create mode 100644 tests/ref/fate/vp8-alpha-decode
> 

[...]

> diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.mak
> index f0bcfac..b29a71a 100644
> --- a/tests/fate/vpx.mak
> +++ b/tests/fate/vpx.mak
> @@ -31,6 +31,9 @@ fate-vp6f: CMD = framecrc -flags +bitexact -i 
> $(TARGET_SAMPLES)/flash-vp6/clip10
>  FATE_VP8-$(call DEMDEC, FLV, VP8) += fate-vp8-alpha
>  fate-vp8-alpha: CMD = framecrc -i 
> $(TARGET_SAMPLES)/vp8_alpha/vp8_video_with_alpha.webm -vcodec copy
>  
> +FATE_VP8-$(call DEMDEC, FLV, VP8) += fate-vp8-alpha-decode

This line states the tests depends on the internal vp8 decoder, when
in reality it needs libvpx's. It also states it needs the flv demuxer
when it's a webm file, but i see you just copied it from the test
above it which is wrong. I'll fix that in a moment.

In any case, we don't add tests for external library based components,
so this isn't needed.

> +fate-vp8-alpha-decode: CMD = framecrc -vcodec libvpx -i 
> $(TARGET_SAMPLES)/vp8_alpha/vp8_video_with_alpha.webm -vcodec rawvideo 
> -pix_fmt yuva420p -f rawvideo
> +
>  FATE_VP8-$(call DEMDEC, WEBM_DASH_MANIFEST, VP8) += fate-webm-dash-manifest
>  fate-webm-dash-manifest: CMD = run $(FFMPEG) -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_video1.webm -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_video2.webm -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_audio1.webm -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_audio2.webm -c copy -map 0 -map 1 -map 2 -map 3 -f 
> webm_dash_manifest -adaptation_sets "id=0,streams=0,1 id=1,streams=2,3" -
>  
> diff --git a/tests/ref/fate/vp8-alpha-decode b/tests/ref/fate/vp8-alpha-decode
> new file mode 100644
> index 000..40b28d2
> --- /dev/null
> +++ b/tests/ref/fate/vp8-alpha-decode
> @@ -0,0 +1,125 @@
> +#tb 0: 1/30
> +#media_type 0: video
> +#codec_id 0: rawvideo
> +#dimensions 0: 320x213
> +#sar 0: 1/1
> +0,  0,  0,1,   170560, 0x2a1293ad
> +0,  1,  1,1,   170560, 0x6c88cb4b
> +0,  2,  2,1,   170560, 0x27585dc5
> +0,  3,  3,1,   170560, 0x73cbe037
> +0,  4,  4,1,   170560, 0x4eca3cd5
> +0,  5,  5,1,   170560, 0xdfecde95
> +0,  6,  6,1,   170560, 0x38dfe631
> +0,  7,  7,1,   170560, 0xbbe546a1
> +0,  8,  8,1,   170560, 0xa78ffec3
> +0,  9,  9,1,   170560, 0x917923f7
> +0, 10, 10,1,   170560, 0x82927437
> +0, 11, 11,1,   170560, 0xe1bfa664
> +0, 12, 12,1,   170560, 0x1091e069
> +0, 13, 13,1,   170560, 0x96551722
> +0, 14, 14,1,   170560, 0x9a952c31
> +0, 15, 15,1,   170560, 0xb2e34dff
> +0, 16, 16,1,   170560, 0x09f77a76
> +0, 17, 17,1,   170560, 0xf6f5a3de
> +0, 18, 18,1,   170560, 0x6453bd09
> +0, 19, 19,1,   170560, 0x7d64c755
> +0, 20, 20,1,   170560, 0x1e11c29d
> +0, 21, 21,1,   170560, 0x57dca8ba
> +0, 22, 22,1,   170560, 0x594d982a
> +0, 23, 23,1,   170560, 0xd2017b7d
> +0, 24, 24,1,   170560, 0x46af60e2
> +0, 25, 25,1,   170560, 0x186b60bd
> +0, 26, 26,1,   170560, 0x9bd96210
> +0, 27, 27,1,   170560, 0x6efb7e78
> +0, 28, 28,1,   170560, 0xd0219673
> +0, 29, 29,1,   170560, 0x81bfc1c7
> +0, 30, 30,1,   170560, 0x61a30393
> +0, 31, 31,1,   170560, 0x6cfc30e0
> +0, 32, 32,1,   170560, 0x820557d8
> +0, 33, 33,1,   170560, 0xa4f88301
> +0, 34, 34,1,   170560, 0x072fb542
> +0, 35, 35,1,   170560, 0x8d3cd908
> +0, 36, 36,1,   170560, 0x776be292
> +0, 37, 37,1,   170560, 0x2074ca19
> +0, 38, 38,1,   170560, 0x3f5d8ab8
> +0, 39, 39,1,   170560, 0x393425b3
> +0, 40, 40,1,   170560, 0x8332948c
> +0, 41, 41,1,   170560, 0x151df7b7
> +0, 42, 42,1,   

Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding

[Vignesh Venkatasubramanian]

On Thu, Jul 7, 2016 at 12:02 PM, Ronald S. Bultje  wrote:
> Hi Vignesh,
>
> On Thu, Jul 7, 2016 at 2:44 PM, Vignesh Venkatasubramanian <
> vigneshv-at-google@ffmpeg.org> wrote:
>
>> On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian
>>  wrote:
>> > On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje 
>> wrote:
>> >> Hi,
>> >>
>> >> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
>> >> vigneshv-at-google@ffmpeg.org> wrote:
>> >>
>> >>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje 
>> >>> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje > >
>> >>> wrote:
>> >>> >
>> >>> >> Hi,
>> >>> >>
>> >>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
>> >>> >> vigneshv-at-google@ffmpeg.org> wrote:
>> >>> >>
>> >>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer 
>> >>> wrote:
>> >>> >>> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote:
>> >>> >>> >> Hi,
>> >>> >>> >>
>> >>> >>> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
>> >>> >>> jzern-at-google@ffmpeg.org>
>> >>> >>> >> wrote:
>> >>> >>> >>
>> >>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
>> >>> ceho...@ag.or.at>
>> >>> >>> >>> wrote:
>> >>> >>> > Do we have decoder support (for either vp8 or vp9) for these
>> >>> files?
>> >>> >>> 
>> >>> >>>  No, only encoding and muxing.
>> >>> >>> >>>
>> >>> >>> >>> Seems like a feature request, but no reason to block this one
>> if
>> >>> the
>> >>> >>> >>> vp8 one is here.
>> >>> >>> >>
>> >>> >>> >>
>> >>> >>> >> I'm not sure I have an opinion on this... But it feels strange
>> to
>> >>> allow
>> >>> >>> >> encoding of content we cannot decode. Being ffmpeg, how do we
>> >>> recommend
>> >>> >>> >> people handle the files created with this feature, if not by
>> using
>> >>> >>> ffmpeg
>> >>> >>> >> itself?
>> >>> >>>
>> >>> >>> One plausible reason is that Chrome can decode this. So it will be
>> >>> >>> useful for people who already have ffmpeg in their pipelines and
>> want
>> >>> >>> to create such files. And like James Almer mentioned, this isn't a
>> >>> >>> first. VP8 Alpha has been this way too.
>> >>> >>
>> >>> >>
>> >>> >> The fact that something is the way it is, does not prove that it is
>> >>> >> therefore right, or that we should therefore continue doing it that
>> way
>> >>> in
>> >>> >> other cases.
>> >>> >>
>> >>> >> So you're suggesting that it is perfectly fine for people to use
>> Chrome
>> >>> as
>> >>> >> decoder if FFmpeg is the encoder. What if people don't have Chrome
>> >>> >> installed? Or what if they want a way of UI-less batch-processing
>> such
>> >>> >> files, e.g. what if a service like Youtube/Vimeo wants to allow
>> upload
>> >>> of
>> >>> >> vp8a/vp9a files without invoking Chrome for decoding?
>> >>> >>
>> >>> >
>> >>> > Additional evidence in [1], [2].
>> >>> >
>> >>> > There absolutely seems to be interest in support for vp8a/vp9a
>> decoding
>> >>> > outside Chrome. I'm not saying you should implement it in all
>> multimedia
>> >>> > frameworks ever created in human history, but doing it in one of them
>> >>> (e.g.
>> >>> > ffmpeg, since it already supports encoding) certainly sounds helpful?
>> >>> >
>> >>>
>> >>> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg.
>> >>> I'm just saying that it shouldn't be a reason to block this patch. :)
>> >>> Sorry if i wasn't clear before.
>> >>
>> >>
>> >> I totally understand that you would think that, since it means you don't
>> >> have to do anything :).
>> >>
>> >> But there's an issue with this thinking. We're essentially already the
>> >> dumping ground for anything multimedia-related nowadays. After all, we
>> >> maintain it and keep it working (assuming basic tests), things couldn't
>> get
>> >> much easier than that, right? But is it actually useful to anyone? I
>> mean
>> >> not just useful for you, but useful to a wider set of people, at least
>> in
>> >> theory.
>> >>
>> >> If there's no decoder, I would claim that the wider utility of this
>> thing
>> >> is essentially zero. And that's somewhat of a concern.
>> >>
>> >> So, how do we get a decoder? vp8a suggests that just waiting for one to
>> >> spontaneously combust out of thin air just doesn't work. So I'm
>> suggesting
>> >> you provide us with one. It's ok if it uses libvpx instead of ffvp8/9.
>> >> Since vp8a encoding is already in, I won't ask for a vp8a decoder
>> either.
>> >> I'm just asking for a vp9a decoder. It might even be OK if it's
>> implemented
>> >> on top of ffmpeg instead of inside libavcodec (I'm not sure how others
>> feel
>> >> about this), i.e. just something that invokes libavformat to parse a
>> webm
>> >> file, create two decoders to get the yuv and a planes, and then merge
>> them
>> >> together into a yuva420p picture. I'm just asking for something _small_
>> and
>> >> _simple_ (i.e. not 

[FFmpeg-devel] [PATCH] libavcodec/libvpx: Add VPx alpha decode support

[Vignesh Venkatasubramanian]

VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
ability to decode such files with alpha channel.

Signed-off-by: Vignesh Venkatasubramanian 
---
 libavcodec/libvpxdec.c  | 102 +---
 tests/fate/vpx.mak  |   3 +
 tests/ref/fate/vp8-alpha-decode | 125 
 3 files changed, 210 insertions(+), 20 deletions(-)
 create mode 100644 tests/ref/fate/vp8-alpha-decode

diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index adbc6d0..677a8be 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -29,6 +29,7 @@
 
 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
 #include "avcodec.h"
 #include "internal.h"
 #include "libvpx.h"
@@ -36,10 +37,13 @@
 
 typedef struct VP8DecoderContext {
 struct vpx_codec_ctx decoder;
+struct vpx_codec_ctx decoder_alpha;
+int has_alpha_channel;
 } VP8Context;
 
 static av_cold int vpx_init(AVCodecContext *avctx,
-const struct vpx_codec_iface *iface)
+const struct vpx_codec_iface *iface,
+int is_alpha_decoder)
 {
 VP8Context *ctx = avctx->priv_data;
 struct vpx_codec_dec_cfg deccfg = {
@@ -50,7 +54,9 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_INFO, "%s\n", vpx_codec_version_str());
 av_log(avctx, AV_LOG_VERBOSE, "%s\n", vpx_codec_build_config());
 
-if (vpx_codec_dec_init(>decoder, iface, , 0) != VPX_CODEC_OK) {
+if (vpx_codec_dec_init(
+is_alpha_decoder ? >decoder_alpha : >decoder,
+iface, , 0) != VPX_CODEC_OK) {
 const char *error = vpx_codec_error(>decoder);
 av_log(avctx, AV_LOG_ERROR, "Failed to initialize decoder: %s\n",
error);
@@ -61,7 +67,8 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 }
 
 // returns 0 on success, AVERROR_INVALIDDATA otherwise
-static int set_pix_fmt(AVCodecContext *avctx, struct vpx_image *img)
+static int set_pix_fmt(AVCodecContext *avctx, struct vpx_image *img,
+   int has_alpha_channel)
 {
 #if VPX_IMAGE_ABI_VERSION >= 3
 static const enum AVColorSpace colorspaces[8] = {
@@ -82,7 +89,8 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img)
 case VPX_IMG_FMT_I420:
 if (avctx->codec_id == AV_CODEC_ID_VP9)
 avctx->profile = FF_PROFILE_VP9_0;
-avctx->pix_fmt = AV_PIX_FMT_YUV420P;
+avctx->pix_fmt =
+has_alpha_channel ? AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
 return 0;
 #if CONFIG_LIBVPX_VP9_DECODER
 case VPX_IMG_FMT_I422:
@@ -168,29 +176,70 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img)
 }
 }
 
+static int decode_frame(AVCodecContext *avctx, vpx_codec_ctx_t *decoder,
+uint8_t *data, uint32_t data_sz)
+{
+if (vpx_codec_decode(decoder, data, data_sz, NULL, 0) != VPX_CODEC_OK) {
+const char *error  = vpx_codec_error(decoder);
+const char *detail = vpx_codec_error_detail(decoder);
+
+av_log(avctx, AV_LOG_ERROR, "Failed to decode frame: %s\n", error);
+if (detail) {
+av_log(avctx, AV_LOG_ERROR, "  Additional information: %s\n",
+   detail);
+}
+return AVERROR_INVALIDDATA;
+}
+return 0;
+}
+
 static int vp8_decode(AVCodecContext *avctx,
   void *data, int *got_frame, AVPacket *avpkt)
 {
 VP8Context *ctx = avctx->priv_data;
 AVFrame *picture = data;
 const void *iter = NULL;
-struct vpx_image *img;
+const void *iter_alpha = NULL;
+struct vpx_image *img, *img_alpha;
 int ret;
+uint8_t *side_data = NULL;
+int side_data_size = 0;
 
-if (vpx_codec_decode(>decoder, avpkt->data, avpkt->size, NULL, 0) !=
-VPX_CODEC_OK) {
-const char *error  = vpx_codec_error(>decoder);
-const char *detail = vpx_codec_error_detail(>decoder);
+ret = decode_frame(avctx, >decoder, avpkt->data, avpkt->size);
+if (ret)
+return ret;
 
-av_log(avctx, AV_LOG_ERROR, "Failed to decode frame: %s\n", error);
-if (detail)
-av_log(avctx, AV_LOG_ERROR, "  Additional information: %s\n",
-   detail);
-return AVERROR_INVALIDDATA;
+side_data = av_packet_get_side_data(avpkt,
+AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL,
+_data_size);
+if (side_data_size > 1) {
+const uint64_t additional_id = AV_RB64(side_data);
+side_data += 8;
+side_data_size -= 8;
+if (additional_id == 1) {  // 1 stands for alpha channel data.
+if (!ctx->has_alpha_channel) {
+ctx->has_alpha_channel = 1;
+ret = vpx_init(
+avctx,
+(avctx->codec_id == 

Re: [FFmpeg-devel] [PATCH] libavcodec/libvpx: Add VPx alpha decode support

[Vignesh Venkatasubramanian]

On Mon, Jul 11, 2016 at 5:55 PM, James Zern
 wrote:
> On Thu, Jul 7, 2016 at 11:43 AM, Vignesh Venkatasubramanian
>  wrote:
>> VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
>> ability to decode such files with alpha channel.
>>
>> Signed-off-by: Vignesh Venkatasubramanian 
>> ---
>>  libavcodec/libvpxdec.c  | 111 ---
>>  tests/fate/vpx.mak  |   3 +
>>  tests/ref/fate/vp8-alpha-decode | 125 
>> 
>>  3 files changed, 219 insertions(+), 20 deletions(-)
>>  create mode 100644 tests/ref/fate/vp8-alpha-decode
>>
>> [...]
>> +static int vpx_codec_dec_init_wrapper(AVCodecContext *avctx,
>>
>
> maybe just decoder/dec_init?
>

have re-used vpx_init.

>> [...]
>> +static av_cold int vpx_init(AVCodecContext *avctx,
>> +const struct vpx_codec_iface *iface)
>> +{
>> +VP8Context *ctx = avctx->priv_data;
>
> just leave this extraction to the init wrapper.

done.

>
>> +return vpx_codec_dec_init_wrapper(avctx, ctx, iface, 0);
>
>> [...]
>> +static int vpx_codec_decode_wrapper(AVCodecContext *avctx,
>>
>
> maybe just decode / decode_frame?

done.

>
>> [...]
>> +side_data = av_packet_get_side_data(avpkt,
>> +
>> AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL,
>> +_data_size);
>> +if (side_data_size > 1) {
>> +uint64_t additional_id = AV_RB64(side_data);
>>
>
> could be const.

done.

>
>> +side_data += 8;
>> +side_data_size -= 8;
>>
>
> this adjustment could be within the if().

it's a bit better future-proof'ed this way. if we need to process
another additional_id later, it can just be an else-if.

>
>> [...]
>> -av_image_copy(picture->data, picture->linesize, (const uint8_t 
>> **)img->planes,
>> -  img->stride, avctx->pix_fmt, img->d_w, img->d_h);
>> +
>> +planes[0] = img->planes[VPX_PLANE_Y];
>> +planes[1] = img->planes[VPX_PLANE_U];
>> +planes[2] = img->planes[VPX_PLANE_V];
>> +planes[3] =
>> +ctx->has_alpha_channel ? img_alpha->planes[VPX_PLANE_Y] : NULL;
>> +linesizes[0] = img->stride[VPX_PLANE_Y];
>> +linesizes[1] = img->stride[VPX_PLANE_U];
>> +linesizes[2] = img->stride[VPX_PLANE_V];
>> +linesizes[3] =
>> +ctx->has_alpha_channel ? img_alpha->stride[VPX_PLANE_Y] : 0;
>> +av_image_copy(picture->data, picture->linesize, (const 
>> uint8_t**)planes,
>> +  linesizes, avctx->pix_fmt, img->d_w, img->d_h);
>>
>
> couldn't this just be 1 additional av_image_copy_plane()?

av_image_copy does some width computation [1] before calling
av_image_copy_plane. i didn't want to duplicate that computation here.
it just seemed cleaner this way. please let me know if you strongly
feel otherwise and i can change this.

[1] 
https://github.com/FFmpeg/FFmpeg/blob/eae2d89bf715bc3edff478174b43e1f388e768bf/libavutil/imgutils.c#L326

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

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

[FFmpeg-devel] [PATCH 2/5] af_hdcd: fewer false positives by ignoring code_counterC in HDCD detection

[Burt P]

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 73a0b93..48f87f6 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -1094,7 +1094,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 s->uses_peak_extend |= !!state->count_peak_extend;
 s->uses_transient_filter |= !!state->count_transient_filter;
 s->max_gain_adjustment = FFMIN(s->max_gain_adjustment, 
GAINTOFLOAT(state->max_gain));
-s->hdcd_detected |= state->code_counterC || state->code_counterB || 
state->code_counterA;
+s->hdcd_detected |= state->code_counterB || state->code_counterA;
 }
 
 av_frame_free();
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 3/5] af_hdcd: only hdcd_update_info() when something changes

[Burt P]

Only call hdcd_update_info() when the control code changes
instead of every frame, so the counters are more meaningful.

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 34 +-
 1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 48f87f6..4104935 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -835,7 +835,6 @@ typedef struct {
  * steps of 0.5, but no value below -6.0 dB should appear. */
 int gain_counts[16]; /* for cursiosity, mostly */
 int max_gain;
-int cb6, cb7; /* watch bits 6 and 7 of the control code, for curiosity */
 } hdcd_state_t;
 
 typedef struct HDCDContext {
@@ -879,8 +878,15 @@ static void hdcd_reset(hdcd_state_t *state, unsigned rate)
 state->count_transient_filter = 0;
 for(i = 0; i < 16; i++) state->gain_counts[i] = 0;
 state->max_gain = 0;
-state->cb6 = 0;
-state->cb7 = 0;
+}
+
+/* update the user info/counters */
+static void hdcd_update_info(hdcd_state_t *state)
+{
+if (state->control & 16) state->count_peak_extend++;
+if (state->control & 32) state->count_transient_filter++;
+state->gain_counts[state->control & 15]++;
+state->max_gain = FFMAX(state->max_gain, (state->control & 15));
 }
 
 static int hdcd_integrate(hdcd_state_t *state, int *flag, const int32_t 
*samples, int count, int stride)
@@ -913,6 +919,7 @@ static int hdcd_integrate(hdcd_state_t *state, int *flag, 
const int32_t *samples
 *flag = 1;
 state->code_counterB++;
 }
+if (*flag) hdcd_update_info(state);
 state->arg = 0;
 }
 if (bits == 0x7e0fa005 || bits == 0x7e0fa006) {
@@ -1011,18 +1018,6 @@ static int hdcd_envelope(int32_t *samples, int count, 
int stride, int gain, int
 return gain;
 }
 
-/* update the user info/flags */
-static void hdcd_update_info(hdcd_state_t *state)
-{
-if (state->control & 16) state->count_peak_extend++;
-if (state->control & 32) state->count_transient_filter++;
-state->gain_counts[state->control & 15]++;
-state->max_gain = FFMAX(state->max_gain, (state->control & 15));
-
-if (state->control & 64) state->cb6++;
-if (state->control & 128) state->cb7++;
-}
-
 static void hdcd_process(hdcd_state_t *state, int32_t *samples, int count, int 
stride)
 {
 int32_t *samples_end = samples + count * stride;
@@ -1031,8 +1026,6 @@ static void hdcd_process(hdcd_state_t *state, int32_t 
*samples, int count, int s
 int target_gain = (state->control & 15) << 7;
 int lead = 0;
 
-hdcd_update_info(state);
-
 while (count > lead) {
 int envelope_run;
 int run;
@@ -1049,7 +1042,6 @@ static void hdcd_process(hdcd_state_t *state, int32_t 
*samples, int count, int s
 lead = run - envelope_run;
 peak_extend = (state->control & 16);
 target_gain = (state->control & 15) << 7;
-hdcd_update_info(state);
 }
 if (lead > 0) {
 av_assert0(samples + lead * stride <= samples_end);
@@ -1157,10 +1149,10 @@ static av_cold void uninit(AVFilterContext *ctx)
 hdcd_state_t *state = >state[i];
 av_log(ctx, AV_LOG_VERBOSE, "Channel %d: counter A: %d, B: %d, C: 
%d\n", i, state->code_counterA,
 state->code_counterB, state->code_counterC);
-av_log(ctx, AV_LOG_VERBOSE, "Channel %d: c(pe): %d, c(tf): %d, cb6: 
%d, cb7: %d\n", i,
-state->count_peak_extend, state->count_transient_filter, 
state->cb6, state->cb7);
+av_log(ctx, AV_LOG_VERBOSE, "Channel %d: cpe: %d, ctf: %d\n", i,
+state->count_peak_extend, state->count_transient_filter);
 for (j = 0; j <= state->max_gain; j++) {
-av_log(ctx, AV_LOG_VERBOSE, "Channel %d: tg %0.1f - %d\n", i, 
GAINTOFLOAT(j), state->gain_counts[j]);
+av_log(ctx, AV_LOG_VERBOSE, "Channel %d: tg %0.1f: %d\n", i, 
GAINTOFLOAT(j), state->gain_counts[j]);
 }
 }
 
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 5/5] af_hdcd: detect and report encoding errors and oddities

[Burt P]

Count and report when a code is signaled but fails to match a known pattern.
For example try Līve - Secret Samadhi.

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 73 ---
 1 file changed, 58 insertions(+), 15 deletions(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 8acbdda..6f0db71 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -822,8 +822,11 @@ typedef struct {
 int running_gain;
 unsigned sustain, sustain_reset;
 int code_counterA;
+int code_counterA_almost; /* looks like an A code, but a bit expected to 
be 0 is 1 */
 int code_counterB;
+int code_counterB_checkfails; /* looks like a B code, but doesn't pass the 
XOR check */
 int code_counterC;
+int code_counterC_unmatched; /* told to look for a code, but didn't find 
one */
 
 /* For user information/stats, pulled up into HDCDContext
  * by filter_frame() */
@@ -835,6 +838,8 @@ typedef struct {
  * steps of 0.5, but no value below -6.0 dB should appear. */
 int gain_counts[16]; /* for cursiosity, mostly */
 int max_gain;
+
+AVFilterContext *fctx; /* filter context for logging errors */
 } hdcd_state_t;
 
 typedef struct HDCDContext {
@@ -843,6 +848,7 @@ typedef struct HDCDContext {
 
 /* User information/stats */
 int hdcd_detected;
+int det_errors;/* detectable errors */
 int uses_peak_extend;
 int uses_transient_filter; /* detected, but not implemented */
 float max_gain_adjustment; /* in dB, expected in the range -6.0 to 0.0 */
@@ -871,8 +877,11 @@ static void hdcd_reset(hdcd_state_t *state, unsigned rate)
 state->sustain_reset = rate * 10;
 
 state->code_counterA = 0;
+state->code_counterA_almost = 0;
 state->code_counterB = 0;
+state->code_counterB_checkfails = 0;
 state->code_counterC = 0;
+state->code_counterC_unmatched = 0;
 
 state->count_peak_extend = 0;
 state->count_transient_filter = 0;
@@ -909,15 +918,39 @@ static int hdcd_integrate(hdcd_state_t *state, int *flag, 
const int32_t *samples
 bits = (state->window ^ state->window >> 5 ^ state->window >> 23);
 
 if (state->arg) {
-if ((bits & 0xffc8) == 0x0fa00500) {
-state->control = (bits & 255) + (bits & 7);
-*flag = 1;
-state->code_counterA++;
-}
-if (((bits ^ (~bits >> 8 & 255)) & 0x00ff) == 0xa006) {
-state->control = bits >> 8 & 255;
-*flag = 1;
-state->code_counterB++;
+if ((bits & 0x0fa00500) == 0x0fa00500) {
+/* A: 8-bit code */
+if ((bits & 0xc8) == 0) {
+/*   [..pt ]
+ * 0x0fa005[..] -> 0b[00.. 0...], gain part doubled */
+state->control = (bits & 255) + (bits & 7);
+*flag = 1;
+state->code_counterA++;
+} else {
+/* one of bits 3, 6, or 7 was not 0 */
+state->code_counterA_almost++;
+av_log(state->fctx, AV_LOG_VERBOSE,
+"hdcd error: Control A almost: 0x%08x\n", bits);
+}
+} else if ((bits & 0xa006) == 0xa006) {
+/* B: 8-bit code, 8-bit XOR check */
+if (((bits ^ (~bits >> 8 & 255)) & 0x00ff) == 0xa006) {
+/*  check:   [..pt  ~(..pt )]
+ * 0xa006[] -> 0b[      ] */
+state->control = bits >> 8 & 255;
+*flag = 1;
+state->code_counterB++;
+} else {
+/* XOR check failed */
+state->code_counterB_checkfails++;
+av_log(state->fctx, AV_LOG_VERBOSE,
+"hdcd error: Control B check failed: 0x%08x\n", bits);
+}
+} else {
+/* told to look for a code, but didn't match one */
+state->code_counterC_unmatched++;
+av_log(state->fctx, AV_LOG_VERBOSE,
+"hdcd error: Unmatched code: 0x%08x\n", bits);
 }
 if (*flag) hdcd_update_info(state);
 state->arg = 0;
@@ -1079,6 +1112,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 out_data[n] = in_data[n];
 }
 
+s->det_errors = 0;
 for (c = 0; c < inlink->channels; c++) {
 hdcd_state_t *state = >state[c];
 hdcd_process(state, out_data + c, in->nb_samples, out->channels);
@@ -1087,6 +1121,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 s->uses_transient_filter |= !!state->count_transient_filter;
 s->max_gain_adjustment = FFMIN(s->max_gain_adjustment, 
GAINTOFLOAT(state->max_gain));
 s->hdcd_detected |= state->code_counterB || state->code_counterA;
+s->det_errors += state->code_counterA_almost
++ state->code_counterB_checkfails
++ 

[FFmpeg-devel] [PATCH 4/5] af_hdcd: don't log full HDCD stats if HDCD was not detected

[Burt P]

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 4104935..8acbdda 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -1157,13 +1157,15 @@ static av_cold void uninit(AVFilterContext *ctx)
 }
 
 /* log the HDCD decode information */
-av_log(ctx, AV_LOG_INFO,
-"HDCD detected: %s, peak_extend: %s, max_gain_adj: %0.1f dB, 
transient_filter: %s\n",
-(s->hdcd_detected) ? "yes" : "no",
-(s->uses_peak_extend) ? "enabled" : "never enabled",
-s->max_gain_adjustment,
-(s->uses_transient_filter) ? "detected" : "not detected"
-);
+if (s->hdcd_detected)
+av_log(ctx, AV_LOG_INFO,
+"HDCD detected: yes, peak_extend: %s, max_gain_adj: %0.1f dB, 
transient_filter: %s\n",
+(s->uses_peak_extend) ? "enabled" : "never enabled",
+s->max_gain_adjustment,
+(s->uses_transient_filter) ? "detected" : "not detected"
+);
+else
+av_log(ctx, AV_LOG_INFO, "HDCD detected: no\n");
 }
 
 static av_cold int init(AVFilterContext *ctx)
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 0/5] Split up HDCD filter patch

[Burt P]

This is the previous patch split into smaller patches, as requested.

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

Re: [FFmpeg-devel] [PATCH] avcodec/dirac_vlc: Fix avutil.h include

[Michael Niedermayer]

On Tue, Jul 12, 2016 at 01:15:07PM +0100, Rostislav Pehlivanov wrote:
> On 12 July 2016 at 12:53, Michael Niedermayer 
> wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/dirac_vlc.h |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/dirac_vlc.h b/libavcodec/dirac_vlc.h
> > index 523e9ca..42ae41b 100644
> > --- a/libavcodec/dirac_vlc.h
> > +++ b/libavcodec/dirac_vlc.h
> > @@ -22,7 +22,7 @@
> >  #ifndef AVCODEC_DIRAC_VLC_H
> >  #define AVCODEC_DIRAC_VLC_H
> >
> > -#include 
> > +#include "libavutil/avutil.h"
> >
> >  /* Can be 32 bits wide for some performance gain on some machines, but it
> > will
> >   * incorrectly decode very long coefficients (usually only 1 or 2 per
> > frame) */
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> No idea how we've missed that
> LGTM

applied

thanks

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

[FFmpeg-devel] [PATCH] Avoid sending packets to network when multicast ttl is 0 in udp

[Omid Ghaffarinia]

When using ffmpeg to start a local-only server (i.e. setting ttl=0)
using multicast ip (i.e. 224.1.1.1) you can see packets going to
network.
Bug is due to kernel handling multicast ttl 0 differently (as noted in
kernel code net/ipv4/route.c:2191 see:
https://github.com/torvalds/linux/blob/master/net/ipv4/route.c )
/* Special hack: user can direct multicasts
   and limited broadcast via necessary interface
   without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
   This hack is not just for fun, it allows
   vic,vat and friends to work.
   They bind socket to loopback, set ttl to zero
   and expect that it will work.
   From the viewpoint of routing cache they are broken,
   because we are not allowed to build multicast path
   with loopback source addr (look, routing cache
   cannot know, that ttl is zero, so that packet
   will not leave this host and route is valid).
   Luckily, this hack is good workaround.
 */


Signed-off-by: Omid Ghaffarinia 
---
 libavformat/sdp.c |2 +-
 libavformat/udp.c |   28 
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 01b564b..0401f7a 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -61,7 +61,7 @@ static void sdp_write_address(char *buff, int size,
const char *dest_addr,
 if (dest_addr) {
 if (!dest_type)
 dest_type = "IP4";
-if (ttl > 0 && !strcmp(dest_type, "IP4")) {
+if (ttl >= 0 && !strcmp(dest_type, "IP4")) {
 /* The TTL should only be specified for IPv4 multicast addresses,
  * not for IPv6. */
 av_strlcatf(buff, size, "c=IN %s %s/%d\r\n", dest_type,
dest_addr, ttl);
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 8699c1c..fe46ba5 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -176,6 +176,28 @@ static int udp_set_multicast_ttl(int sockfd, int mcastTTL,
 }
 }
 #endif
+if (mcastTTL == 0) {
+#ifdef IP_MULTICAST_IF
+if (addr->sa_family == AF_INET) {
+struct in_addr localhost_addr;
+inet_pton(AF_INET, "127.0.0.1", _addr);
+if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_IF,
_addr, sizeof(localhost_addr)) < 0) {
+log_net_error(NULL, AV_LOG_ERROR,
"setsockopt(IP_MULTICAST_IF)");
+return -1;
+}
+}
+#endif
+#if defined(IPPROTO_IPV6) && defined(IPV6_MULTICAST_IF)
+if (addr->sa_family == AF_INET6) {
+struct in6_addr localhost_addr;
+inet_pton(AF_INET6, "::1", _addr);
+if (setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_IF,
_addr, sizeof(localhost_addr)) < 0) {
+log_net_error(NULL, AV_LOG_ERROR,
"setsockopt(IPV6_MULTICAST_IF)");
+return -1;
+}
+}
+#endif
+}
 return 0;
 }

@@ -882,6 +904,12 @@ static int udp_open(URLContext *h, const char
*uri, int flags)
 }
 if (h->flags & AVIO_FLAG_READ) {
 /* input */
+if (s->ttl == 0) {
+if (s->dest_addr.ss_family == AF_INET)
+inet_pton(AF_INET, "127.0.0.1", &((struct
sockaddr_in *)>local_addr_storage)->sin_addr);
+else
+inet_pton(AF_INET6, "::1", &((struct sockaddr_in6
*)>local_addr_storage)->sin6_addr);
+}
 if (num_include_sources && num_exclude_sources) {
 av_log(h, AV_LOG_ERROR, "Simultaneously including and
excluding multicast sources is not supported\n");
 goto fail;
-- 
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] refine the doc of hlsenc

[Steven Liu]

resend the patch, delete the trailing whitespace and check patch by
./tools/patcheck

add the hls_flags round_durations, discont_start, omit_endlist flags
describe

Signed-off-by: LiuQi 
---
 doc/muxers.texi |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 15b63f4..bf5bc82 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -495,6 +495,18 @@ Will produce the playlist, @file{out.m3u8}, and a
single segment file,
 Segment files removed from the playlist are deleted after a period of time
 equal to the duration of the segment plus the duration of the playlist.

+@item hls_flags round_durations
+If this flag is set, the muxer will make the duration info form float
point to
+integer for playlist file segment info.
+
+@item hls_flags discont_starts
+If this flag is set, it will add the @code{#EXT-X-DISCONTINUITY} tag into
the
+playlist at the first segment infomation's front.
+
+@item hls_flags omit_endlist
+If this flag is set, it will not append the @code{EXT-X-ENDLIST} tag at
the end of
+the playlist.
+
 @item hls_flags split_by_time
 If this flags is set, allow segments to start on frames other than
keyframes.
 This improves behavior on some players when the time between keyframes is
-- 
1.7.1


0001-refine-the-doc-of-hlsenc.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix broken osx powerpc build

[Pavel Koshevoy]

On Jul 12, 2016 05:14, "Ronald S. Bultje"  wrote:
>
> Hi,
>
> On Mon, Jul 11, 2016 at 9:56 PM, Jing Yu 
> wrote:
>
> >  .macro movrel rd, sym, gp
> > +#ifdef __APPLE__
> > +ld  \rd, \sym@got(r2)
> > +#else
> >  ld  \rd, \sym@got(2)
> > +#endif
> >  .endm
>
>
> Does something like this work? (Looks a little more readable)
>
> #ifdef __APPLE__
> #define ARG_2 r2
> #else
> #define ARG_2 2
> #endif
>
> and then use ARG_2 instead of 2/r2.

It's not just r2, there is also r1, r12, etc... I've used R(n) macro instead

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

[FFmpeg-devel] [PATCH 2/2] refine the method option describe of hlsenc doc

[Steven Liu]

resend the patch, delete the trailing whitespace and check patch by
./tools/patcheck


Signed-off-by: LiuQi 
---
 doc/muxers.texi |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index bf5bc82..f6fc8e5 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -520,6 +520,15 @@ Emit @code{#EXT-X-PLAYLIST-TYPE:EVENT} in the m3u8
header. Forces
 @item hls_playlist_type vod
 Emit @code{#EXT-X-PLAYLIST-TYPE:VOD} in the m3u8 header. Forces
 @option{hls_list_size} to 0; the playlist must not change.
+
+@item method
+Use HTTP method to operation the hls files,
+@example
+ffmpeg -re -i in.ts -f hls -method PUT http://example.com/live/out.m3u8
+@end example
+This example will upload all the mpegts segment files to HTTP server use
HTTP PUT method,
+and update the m3u8 files every refresh times use HTTP PUT method.
+Note the HTTP server must support the PUT method and upload files.
 @end table

 @anchor{ico}
-- 
1.7.1


0002-refine-the-method-option-describe-of-hlsenc-doc.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dirac_vlc: Fix avutil.h include

[Rostislav Pehlivanov]

On 12 July 2016 at 12:53, Michael Niedermayer 
wrote:

> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dirac_vlc.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dirac_vlc.h b/libavcodec/dirac_vlc.h
> index 523e9ca..42ae41b 100644
> --- a/libavcodec/dirac_vlc.h
> +++ b/libavcodec/dirac_vlc.h
> @@ -22,7 +22,7 @@
>  #ifndef AVCODEC_DIRAC_VLC_H
>  #define AVCODEC_DIRAC_VLC_H
>
> -#include 
> +#include "libavutil/avutil.h"
>
>  /* Can be 32 bits wide for some performance gain on some machines, but it
> will
>   * incorrectly decode very long coefficients (usually only 1 or 2 per
> frame) */
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

No idea how we've missed that
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/vplayerdec: Stricter probing

[Carl Eugen Hoyos]

Clément Bœsch  pkh.me> writes:

> > A user provided a rawvideo frame that is detected as vplayer 
> > without attached patch.
> 
> can you show a hex dump of the first few bytes?

000 3530 3530 3530 3530 3530 3530 3530 3530
*
0f0 3530 3530 3530 3530 3530 3531 3532 3533
100 3534 3535 3536 3537 3537 3537 3537 3537
110 3537 3537 3537 3537 3537 3537 3537 3537
*
130 3537 3537 3537 3537 3537 3537 3538 3538
140 3539 3539 353a 353a 353a 353a 353a 353a
150 353a 353a 353a 353a 353a 353a 353a 353a
*
170 353a 353a 353a 353a 353a 353b 353b 353c
180 353e 3540 3543 3548 354c 354f 3553 3556
190 355a 355d 3560 3564 3567 356b 356e 3572
1a0 3575 3579 357c 3580 3583 3586 358a 358d
1b0 3591 3594 3598 359b 359f 35a4 35a8 35a9
1c0 35ad 35af 35b2 35b7 35bb 35be 35c2 35c5
1d0 35c9 35cc 35d0 35d3 35d7 35da 35de 35e1
1e0 35e5 35e8 35ec 35ef 35f3 35f6 35fa 35fd
1f0 3601 3604 3608 360b 360f 3613 3615 3616
200 3616 3616 3616 3616 3616 3616 3616 3616
*

[...]

> potentially simpler alternative: if you replace the original formats with
> "%*3d:%*2d:%*2d.%*2d%c" and "%*3d:%*2d:%*2d%c", does it work?

Please commit this, it looks simpler to me.

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

[FFmpeg-devel] [PATCH] avcodec/dirac_vlc: Fix avutil.h include

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/dirac_vlc.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dirac_vlc.h b/libavcodec/dirac_vlc.h
index 523e9ca..42ae41b 100644
--- a/libavcodec/dirac_vlc.h
+++ b/libavcodec/dirac_vlc.h
@@ -22,7 +22,7 @@
 #ifndef AVCODEC_DIRAC_VLC_H
 #define AVCODEC_DIRAC_VLC_H
 
-#include 
+#include "libavutil/avutil.h"
 
 /* Can be 32 bits wide for some performance gain on some machines, but it will
  * incorrectly decode very long coefficients (usually only 1 or 2 per frame) */
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH]lavf/vplayerdec: Stricter probing

[Clément Bœsch]

On Tue, Jul 12, 2016 at 12:37:39PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> A user provided a rawvideo frame that is detected as vplayer without attached 
> patch.
> 

can you show a hex dump of the first few bytes?

> Please comment, Carl Eugen

> From 493f24f3d0ba74353ed7742c34a3727c344535eb Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 12 Jul 2016 12:23:58 +0200
> Subject: [PATCH] lavf/vplayerdec: Stricter probing.
> 
> ---
>  libavformat/vplayerdec.c |   10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/vplayerdec.c b/libavformat/vplayerdec.c
> index 897c408..c530a47 100644
> --- a/libavformat/vplayerdec.c
> +++ b/libavformat/vplayerdec.c
> @@ -34,10 +34,16 @@ typedef struct {
>  static int vplayer_probe(AVProbeData *p)
>  {
>  char c;
> +unsigned hh, mm, ss, ms = 0;

we've had surprises with negative timestamps (which can happen), so i
wouldn't make these unsigned (also, you're using signed format string
code)

>  const unsigned char *ptr = p->buf;
>  
> -if ((sscanf(ptr, "%*d:%*d:%*d.%*d%c", ) == 1 ||
> - sscanf(ptr, "%*d:%*d:%*d%c", ) == 1) && strchr(": =", c))
> +if (   (sscanf(ptr, "%d:%d:%d.%d%c", , , , , ) == 5 ||
> +sscanf(ptr, "%d:%d:%d%c",, , ,  ) == 4)
> +&& strchr(": =", c)
> +&& hh < 1000
> +&& mm < 60
> +&& ss < 60
> +&& ms < 1000)

potentially simpler alternative: if you replace the original formats with
"%*3d:%*2d:%*2d.%*2d%c" and "%*3d:%*2d:%*2d%c", does it work?

otherwise I guess patch is fine

>  return AVPROBE_SCORE_MAX;
>  return 0;

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH]lavf/vplayerdec: Stricter probing

[Ronald S. Bultje]

Hi,

On Tue, Jul 12, 2016 at 6:37 AM, Carl Eugen Hoyos  wrote:

> Hi!
>
> A user provided a rawvideo frame that is detected as vplayer without
> attached
> patch.


The hh restriction seems random. But ok.

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

Re: [FFmpeg-devel] [PATCH] Fix broken osx powerpc build

[Ronald S. Bultje]

Hi,

On Mon, Jul 11, 2016 at 9:56 PM, Jing Yu 
wrote:

>  .macro movrel rd, sym, gp
> +#ifdef __APPLE__
> +ld  \rd, \sym@got(r2)
> +#else
>  ld  \rd, \sym@got(2)
> +#endif
>  .endm


Does something like this work? (Looks a little more readable)

#ifdef __APPLE__
#define ARG_2 r2
#else
#define ARG_2 2
#endif

and then use ARG_2 instead of 2/r2.

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

[FFmpeg-devel] [PATCH]lavf/vplayerdec: Stricter probing

[Carl Eugen Hoyos]

Hi!

A user provided a rawvideo frame that is detected as vplayer without attached 
patch.

Please comment, Carl Eugen
From 493f24f3d0ba74353ed7742c34a3727c344535eb Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 12 Jul 2016 12:23:58 +0200
Subject: [PATCH] lavf/vplayerdec: Stricter probing.

---
 libavformat/vplayerdec.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavformat/vplayerdec.c b/libavformat/vplayerdec.c
index 897c408..c530a47 100644
--- a/libavformat/vplayerdec.c
+++ b/libavformat/vplayerdec.c
@@ -34,10 +34,16 @@ typedef struct {
 static int vplayer_probe(AVProbeData *p)
 {
 char c;
+unsigned hh, mm, ss, ms = 0;
 const unsigned char *ptr = p->buf;
 
-if ((sscanf(ptr, "%*d:%*d:%*d.%*d%c", ) == 1 ||
- sscanf(ptr, "%*d:%*d:%*d%c", ) == 1) && strchr(": =", c))
+if (   (sscanf(ptr, "%d:%d:%d.%d%c", , , , , ) == 5 ||
+sscanf(ptr, "%d:%d:%d%c",, , ,  ) == 4)
+&& strchr(": =", c)
+&& hh < 1000
+&& mm < 60
+&& ss < 60
+&& ms < 1000)
 return AVPROBE_SCORE_MAX;
 return 0;
 }
-- 
1.7.10.4

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

Re: [FFmpeg-devel] MKV Header: Writing duration early

[Soft Works]

> There are two sides to this issue: change the muxer to write the value if it
> is known at the beginning and change the command-line tool to compute the
> value for their output.

> I suspect the muxer change would be reasonably easy.

> The change on the command-line tool, on the other hand, you would have to
> determine if the input duration is reliable, detect if filters may change
> the duration, take mapping from various files into account, etc. This is
> very hard.


Thanks Nicolas, that makes sense.


I had some hope that this kind of calculation would already be performed

anyway, while I haven't looked into that yet. I also haven't performed research

about other ffmpeg output formats, to see if there is an existing case

where duration is written early...


Before coding anything I'd like to get a feeling for what kind of solution

could be acceptable for the project.

Basically I suppose that whatever solution we could come up with, it should

be optional to make sure that there is no change to existing behaviour, right?


Since we would need some command-line parameter anyway, it could even

be a parameter like "-mkv_early_duration=01:30:10.010" to explicitly specify

the value. While this is not an intelligent solution, it's straightforward, but 
it

would require the parent application to parse the input file first in order to

determine the duration.


Another option would be a parameter like "-mkv_estimate_early_duration"

and see if there is some existing code we could build on. (I suppose ffserver

might have some code to estimate durations)


What do you think?


-softworkz





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

Re: [FFmpeg-devel] [PATCH] avformat/oggenc: always use the time base stored in the theora header

[Michael Niedermayer]

On Mon, Jul 11, 2016 at 10:25:23PM -0300, James Almer wrote:
> Fixes ticket #5704
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/oggenc.c | 8 
>  1 file changed, 8 insertions(+)

should be ok

thx

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

No great genius has ever existed without some touch of madness. -- 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] af_hdcd.c: only hdcd_update_info() when something changes, add error detection

[Michael Niedermayer]

On Mon, Jul 11, 2016 at 05:33:03PM -0500, Burt P. wrote:

> Only call hdcd_update_info() when the control code changes
> instead of every frame, so the counters are more meaningful.
> 

> Also, adds some basic error detection. After scanning through
> about 30 HDCD-encoded CD's I've found errors where a code
> is signaled, but then fails to match one of the patterns, so
> it is ignored. Often, it is very close to a code, differing
> by only one bit. I don't know enough to say whether it is
> using some unknown feature of HDCD that this filter doesn't
> know about, or if there was just an error in the encoding.
> I've added some comments so that it should be easier for
> others to examine.

are these 2 seperate changes ?
if so they should be in seperate patches/commits


> 
> An example with many errors is Līve - Secret Samadhi, if
> anyone wants to look into it.
> 
> Patch is attached.
> Any comments would be appreciated.

>  af_hdcd.c |  122 
> --
>  1 file changed, 79 insertions(+), 43 deletions(-)
> e787817ad5f053390d648e6bba66f9a2fd5d0e95  
> 0001-af_hdcd.c-only-hdcd_update_info-when-something-chang.patch
> From 63a2736dd8444fe64d8c5bc885d61979bfe93f6b Mon Sep 17 00:00:00 2001
> From: Burt P 
> Date: Mon, 11 Jul 2016 17:08:20 -0500
> Subject: [PATCH] af_hdcd.c: only hdcd_update_info() when something changes,
>  add error detection
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> * hdcd_update_info() when control code changes; counts are more meaningful
> * some encoding errors can be detected
> * fewer false positives by ignoring code_counterC in HDCD detection
> * integrate() renamed hdcd_integrate() to be consistent with the other 
> function names
> * some code comments
> 
> Try Līve - Secret Samadhi or John Mellencamp - Mr. Happy Go Lucky for error 
> detection.

[...]

> +av_log(0, AV_LOG_VERBOSE,
> +"hdcd error: Control A almost: 0x%08x\n", bits);

[...]

> +av_log(0, AV_LOG_VERBOSE,
> +"hdcd error: Unmatched code: 0x%08x\n", bits);

av_log() should have a non null context so that the messages can more
easily be associated with their source

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] MKV Header: Writing duration early

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Soft Works a écrit :
> Such circumstances are not really "special" or even rare.
> Especially in most trivial cases (like mkv to mkv) there is a known
> duration from the source that could be used.
> 
> No doubt, that it's not available in all cases. But it could be written in
> those cases where it's available.

There are two sides to this issue: change the muxer to write the value if it
is known at the beginning and change the command-line tool to compute the
value for their output.

I suspect the muxer change would be reasonably easy.

The change on the command-line tool, on the other hand, you would have to
determine if the input duration is reliable, detect if filters may change
the duration, take mapping from various files into account, etc. This is
very hard.

> Probably the actual question is: If I would submit a patch to do this,
> would it have a chance to be included?

If the patch is clean and the feature/size ratio is reasonable, of course.

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 1/2] refine the doc of hlsenc

[Michael Niedermayer]

On Tue, Jul 12, 2016 at 11:55:05AM +0800, Steven Liu wrote:
> add the hls_flags round_durations, discont_start, omit_endlist flags
> describe
> 
[...]

>  muxers.texi |   12 
>  1 file changed, 12 insertions(+)
> 2c76ab4a4f03f11a29c95ef2703d98b4ca31ca83  0001-refine-the-doc-of-hlsenc.patch
> From 7909967dd0206c75a844ff72a1e0c902517175df Mon Sep 17 00:00:00 2001
> From: Steven Liu 
> Date: Tue, 12 Jul 2016 10:19:45 +0800
> Subject: [PATCH 1/2] refine the doc of hlsenc
> 
> add the hls_flags round_durations, discont_start, omit_endlist flags describe
> 
> Signed-off-by: LiuQi 
> ---
>  doc/muxers.texi |   12 
>  1 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 15b63f4..bf5bc82 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -495,6 +495,18 @@ Will produce the playlist, @file{out.m3u8}, and a single 
> segment file,
>  Segment files removed from the playlist are deleted after a period of time
>  equal to the duration of the segment plus the duration of the playlist.
>  
> +@item hls_flags round_durations
> +If this flag is set, the muxer will make the duration info form float point 
> to
> +integer for playlist file segment info.
> +
> +@item hls_flags discont_starts
> +If this flag is set, it will add the @code{#EXT-X-DISCONTINUITY} tag into 
> the 
> +playlist at the first segment infomation's front.
> +
> +@item hls_flags omit_endlist

> +If this flag is set, it will not append the @code{EXT-X-ENDLIST} tag at the 
> end of  

trailing whitespace is forbidden in ffmpeg

[...]

-- 
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] MKV Header: Writing duration early

[Hendrik Leppkes]

On Tue, Jul 12, 2016 at 11:11 AM, Soft Works  wrote:
>
>> Unfortunately the duration is not available in all cases, so writing
>> it early would only work in a few special circumstances, so as a
>> generic solution its not going to work.
>
> Such circumstances are not really "special" or even rare.
> Especially in most trivial cases (like mkv to mkv) there is a known duration 
> from the source that could be used.
>

Perhaps this is the common case for you, but not for everyone. Having
a wrong duration is probably worse then having none.

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

Re: [FFmpeg-devel] MKV Header: Writing duration early

[Soft Works]

> Unfortunately the duration is not available in all cases, so writing
> it early would only work in a few special circumstances, so as a
> generic solution its not going to work.

Such circumstances are not really "special" or even rare.
Especially in most trivial cases (like mkv to mkv) there is a known duration 
from the source that could be used.

No doubt, that it's not available in all cases. But it could be written in 
those cases where it's available.

Probably the actual question is: If I would submit a patch to do this, would it 
have a chance to be included?




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

Re: [FFmpeg-devel] MKV Header: Writing duration early

[Hendrik Leppkes]

On Tue, Jul 12, 2016 at 10:11 AM, Soft Works  wrote:
> Now I'm wondering if this could be fixed by early writing the duration in 
> mkv_write_header if a duration is available at this time (usually taken from 
> the source stream)?
>

Unfortunately the duration is not available in all cases, so writing
it early would only work in a few special circumstances, so as a
generic solution its not going to work.

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

Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit :
> The fifo muxer never returns EAGAIN. It silently drops the packets in
> non-blocking mode on a full queue. This behaviour is useful for the tee
> muxer case, when you don't want one slow/unreliable (network) output to
> block reading the input, therefore blocking fast outputs (disk) as well.

Wait a minute. This is way to specific to be the default behaviour, let
alone the only one.

> As far as I know, in the current API, if the user gets a negative return
> value from av_write_frame(), it should be handled as a fatal error. EAGAIN
> is not handled/interpreted specially. The same is true for
> av_write_trailer(), and calling av_write_trailer - regardless of the return
> value - frees all private resources for the context as well, so you cannot
> change the semantics of av_write_trailer to not free private data in case of
> EAGAIN, because it would cause unfreed data for legacy users.

You are wrong. Returning EAGAIN so that the caller try again later is the
normal behaviour for muxers that support non-blocking operation. I grant you
that there are only between one and three of them, but still, that is how
they work.

And that is also how they are supposed to work, because that is how
non-blocking protocols work, and also how non-blocking works outside FFmpeg.

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 2/7] avformat/tee: Use ff_stream_encode_params_copy()

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Nicolas George a écrit :
> Le quartidi 24 messidor, an CCXXIV, Jan Sebechlebsky a écrit :
> > I think it is used in decoding only - the documentation of AVStream mentions
> > only decoding and I also tried to search references to that field if it is
> > not used in some of the muxers. If you think it should be copied too I will
> > add it.
> 
> If you have checked it was never used in muxers, then ok. But you may want
> to have a look at the "MKV Header: Writing duration early" mail that arrived
> a few minutes ago.

And remember to reply to the list.

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] MKV Header: Writing duration early

[Soft Works]

Hi,

we are using ffmpeg to transcode or remux mkv to mkv. The result is being 
streamed on-the-fly to an HTML5 client (streaming starts while ffmpeg is still 
running).

The problem here is that the client is unable to detect the duration because 
the duration is only written to the mkv at the end of the transcoding/remoxing 
process. I tracked this down in the source code and found that in 
matroskaenc.c, the duration is only written during mkv_write_trailer but not 
during mkv_write_header.


Now I'm wondering if this could be fixed by early writing the duration in 
mkv_write_header if a duration is available at this time (usually taken from 
the source stream)?


Thanks for any help,


softworkz

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