Re: [FFmpeg-devel] [PATCH] hlsenc: intialize only on ref_pkt and drop all packets

[Miroslav Slugeň]

Dne 12.2.2017 v 23:35 Michael Niedermayer napsal(a):

On Sun, Feb 12, 2017 at 07:31:43PM +0100, Miroslav Slugeň wrote:

This patch will fix cutting hls segments into exactly same length.
Because it will intialize only on first ref_packet, which is video
frame, not audio frame (old behavior)

It will also drop all packets without PTS, drop all packets before
initialization and drop all packets before first intialization
packet PTS.

Now it should be possible to create segments at exactly same length
if we use new -force_key_frames hls:time_in_seconds parameter.

This is required to support adaptive HLS.

--
Miroslav Slugeň










  hlsenc.c |   24 
  1 file changed, 20 insertions(+), 4 deletions(-)
7f784939c938c7697be2178647828a36815fc731  
0001-hlsenc-intialize-only-on-ref_pkt-and-drop-all-packet.patch
 From a59a7dbe6fdcab64c1402adb8f11cc31400f4516 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 19:25:54 +0100
Subject: [PATCH 1/1] hlsenc: intialize only on ref_pkt and drop all packets
  before initialized

---
  libavformat/hlsenc.c | 24 
  1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ad5205a..226dd89 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1278,10 +1278,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  oc = hls->avf;
  stream_index = pkt->stream_index;
  }
-if (hls->start_pts == AV_NOPTS_VALUE) {
-hls->start_pts = pkt->pts;
-hls->end_pts   = pkt->pts;
-}
  
  if (hls->has_video) {

  can_split = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
@@ -1292,6 +1288,11 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  is_ref_pkt = can_split = 0;
  
  if (is_ref_pkt) {

+if (hls->start_pts == AV_NOPTS_VALUE) {
+hls->start_pts = pkt->pts;
+hls->end_pts   = pkt->pts;
+}
+
  if (hls->new_start) {
  hls->new_start = 0;
  hls->duration = (double)(pkt->pts - hls->end_pts)
@@ -1371,6 +1372,21 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  }
  }
  
+if (pkt->pts == AV_NOPTS_VALUE) {

+av_log(s, AV_LOG_WARNING, "packet has no PTS, dropping packet from stream: 
%d\n", pkt->stream_index);
+return 0;
+}
+
+if (hls->start_pts == AV_NOPTS_VALUE) {
+av_log(s, AV_LOG_WARNING, "stream not initialized yet, dropping packet from 
stream: %d\n", pkt->stream_index);
+return 0;
+}
+
+if (pkt->pts + pkt->duration <= hls->start_pts) {
+av_log(s, AV_LOG_WARNING, "packet has PTS < START PTS (%"PRId64" < %"PRId64"), 
dropping packet from stream: %d\n", pkt->pts, hls->start_pts, pkt->stream_index);
+return 0;
+}

This triggers for subtitle streams, for example:

./ffmpeg -i matrixbench_mpeg2.mpg -i 
fate-suite/sub/MovText_capability_tester.mp4  -f hls  -hls_segment_filename  
/tmp/file.%d.ts -t 10   /tmp/file.m3u8


[...]



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Otherwise patch is ok? Should i just check that stream is subtitles and 
add exception for it?


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

Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

[Miroslav Slugeň]

Dne 12.2.2017 v 23:20 Philip Langdale napsal(a):

On Sun, 12 Feb 2017 22:43:41 +0100
Miroslav Slugeň  wrote:


Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a):

On 2/12/2017 10:25 PM, Miroslav Slugeň wrote:

This patch is for discussion only, not ready to commit yet and
maybe newer will be.

NVENC in current CUDA 8 SDK is setting wrong aspect ratio when
encoding resolution 720x576 and 720x480 and using AR 4:3 or 16:9
it will encode to h264 header that 15:11 and 20:11 is used. This
is very very very ugly way how to fix it. I hope someone in NVIDIA
will fix this soon, because all encoded streams are not displayed
correctly for example in videojs player.

nvenc.c had some compensation for this, which was somewhat recently
removed, because nvidia fixed something regarding it:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=829db8effd76b579ae9aca5ee8f85d3ade6af253
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I know that, i am monitoring all nvenc and cuvid changes in ffmpeg.

Fix is not working anymore in current drivers. What is working is if
you set aspect ratio 16000x9001 it will give you almost correct
output, but fixing this in h264 SPP is better solution.

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

If it's still happening, let's just restore the original workaround.
But I stopped being able to reproduce the problem locally, and I can't
reproduce it right now with a 720x576 sample.

Note that the SDK is completely irrelevant to playback behaviour. The
CUDA SDK doesn't include current cuvid/nvenc headers and the Video SDK
isn't required because we bundle/reimplement headers with ffmpeg.

You are likely not using a new enough driver release to have the fix in
it. I'm using 378.09 here.

--phil

I am using current STABLE drivers 375.26, because BETA drivers 378.09 
caused some crashes while encoding on NVENC.


I tested this on BETA drivers too and it is still same.

Original workaround is not working anymore :(

INPUT: Stream #0:0[0x401]: Video: mpeg2video (Main) ([2][0][0][0] / 
0x0002), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 
25 tbr, 90k tbn, 50 tbc


OUTPUT: Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), 
yuv420p(progressive), 720x576 [SAR 16:11 DAR 20:11], 25 fps, 25 tbr, 90k 
tbn, 50 tbc


COMMAND: ffmpeg -deint adaptive -hwaccel cuvid -c:v mpeg2_cuvid -i 
"in.ts" -y -c:v h264_nvenc -c:a copy -b:v 1M -preset hq -f mpegts "out.ts"


Also someone else is complaining about this issue: 
http://superuser.com/questions/1174097/ffmpegnvenc-encoding-strange-aspect-ratio


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

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

[Tobias Rapp]

On 06.02.2017 13:33, Tobias Rapp wrote:

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

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

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



Ping on the patch series.

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

Re: [FFmpeg-devel] [PATCH 1/2] AVFrame: add an opaque_ref field

[wm4]

On Sat, 11 Feb 2017 17:30:24 +0100
Michael Niedermayer  wrote:

> On Sat, Feb 11, 2017 at 02:17:36PM +0100, wm4 wrote:
> > This is an extended version of the AVFrame.opaque field, which can be
> > used to attach arbitrary user information to an AVFrame.
> > 
> > The usefulness of the opaque field is rather limited, because it can
> > store only up to 32 bits of information (or 64 bit on 64 bit systems).
> > It's not possible to set this field to a memory allocation, because
> > there is no way to deallocate it correctly.
> > 
> > The opaque_ref field circumvents this by letting the user set an
> > AVBuffer, which makes the user data refcounted.
> > 
> > Signed-off-by: Anton Khirnov 
> > 
> > Merges Libav commit 04f3bd349651.
> > ---
> >  doc/APIchanges  |  3 +++
> >  libavutil/frame.c   |  9 +
> >  libavutil/frame.h   | 11 +++
> >  libavutil/version.h |  2 +-
> >  4 files changed, 24 insertions(+), 1 deletion(-)
> > 
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 8bca71ef36..81e49c22b9 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2015-08-28
> >  
> >  API changes, most recent first:
> >  
> > +2017-02-11 - xxx - lavu 55.47.100 - frame.h
> > +  Add AVFrame.opaque_ref.
> > +
> >  2017-01-31 - xxx - lavu 55.46.100 / 55.20.0 - cpu.h
> >Add AV_CPU_FLAG_SSSE3SLOW.
> >  
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index a08e0c539d..2913982e91 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -379,6 +379,13 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >  FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
> >  
> > +av_buffer_unref(>opaque_ref);
> > +if (src->opaque_ref) {
> > +dst->opaque_ref = av_buffer_ref(src->opaque_ref);
> > +if (!dst->opaque_ref)
> > +return AVERROR(ENOMEM);
> > +}  
> 
> not just here but
> the error handling in the whole function is not optimal,
> ideally the destination frame should be left intact on error while
> this could leave a half copied, unref and left as is mix

Well, there's not much you can do. Side data in the function has the
same problem. I think if a caller expects consistency, he will have to
unref the destination frame if this function fails. And that should
still work even with this new field.

The alternative would be either unreffing the entire frame as part of
the failure path of this function (a bit too radical?), or carefully
backing up the frame and partially copying back the result on failure
(would be too much?). I thought about working on a byte-copied
temporary AVFrame, but that doesn't help with all the references.

So I left this unchanged.

> 
> > +
> >  return 0;
> >  }
> >  
> > @@ -513,6 +520,8 @@ void av_frame_unref(AVFrame *frame)
> >  
> >  av_buffer_unref(>hw_frames_ctx);
> >  
> > +av_buffer_unref(>opaque_ref);
> > +
> >  get_frame_defaults(frame);
> >  }
> >  
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index b4500923af..3023559beb 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -538,6 +538,17 @@ typedef struct AVFrame {
> >   * AVHWFramesContext describing the frame.
> >   */
> >  AVBufferRef *hw_frames_ctx;
> > +
> > +/**
> > + * AVBufferRef for free use by the API user. Libav will never check the
> > + * contents of the buffer ref. Libav calls av_buffer_unref() on it 
> > when  
> 
> wrong project name
> 
> [...]

Changed and pushed both patches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Takayuki 'January June' Suwa]

From: Takayuki 'January June' Suwa 

This adds "-profile[:v] profile_name"-style option.
---
 libavcodec/omx.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 16df50e..cfe2613 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
 int output_buf_size;
 
 int input_zerocopy;
+int profile;
 } OMXCodecContext;
 
 static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
@@ -523,6 +524,32 @@ static av_cold int omx_component_init(AVCodecContext 
*avctx, const char *role)
 CHECK(err);
 avc.nBFrames = 0;
 avc.nPFrames = avctx->gop_size - 1;
+switch (s->profile) {
+case FF_PROFILE_H264_BASELINE:
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+default:
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+case FF_PROFILE_UNKNOWN:
+switch (avctx->profile) {
+case FF_PROFILE_H264_BASELINE:
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+default:
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+}
+break;
+}
 err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, );
 CHECK(err);
 }
@@ -884,6 +911,10 @@ static const AVOption options[] = {
 { "omx_libname", "OpenMAX library name", OFFSET(libname), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "zerocopy", "Try to avoid copying input frames if possible", 
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "profile",  "Set the encoding profile", OFFSET(profile), 
AV_OPT_TYPE_INT,   { .i64 = FF_PROFILE_UNKNOWN },   FF_PROFILE_UNKNOWN, 
FF_PROFILE_H264_HIGH, VE, "profile" },
+{ "baseline", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile" },
+{ "main", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile" },
+{ "high", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, "profile" },
 { NULL }
 };
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] aacsbr: Associate SBR data with AAC elements on init

[Alex Converse]

On Thu, Feb 9, 2017 at 4:11 PM, Carl Eugen Hoyos  wrote:
>
> 2017-02-09 18:40 GMT+01:00 Alex Converse :
> > Quiets some log spam on pure upsampling mode.
>
> Please mention ticket #5163.
>

Done

> For the whole patchset, I suggest you push as soon as everybody
> agrees on the function prefixes.
>

Prefix changed. Patches 2 and 4 don't have any comments. Do they need
further review by anyone?

> Could you review my patch for ticket #1614?
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164080.html
> It seems to fix the second sample attached on trac, aac_broken.mp4.
>

It appears that your patch is decoding two channels "on top of each
other" creating the artifacts noted in the original review. There
isn't an easy change to make to that patch to fix this. The best way
to handle it is in positional channel orders to try to decode
everything we see then sniff out the channel order after the fact,
using the indexed channel configuration as more of a suggestion. That
may open the door to some truly crazy stuff, so it's probably best to
do some fuzzing and large scale testing on that sort of change before
landing it.

> Did you see ticket #5722?
>

It looks like it's probably a demuxer issue. I haven't looked at mov.c
in a long time.

[...]

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

Re: [FFmpeg-devel] [PATCH 2/9] ffmpeg: do packet ts rescaling in write_packet()

[wm4]

On Fri, 10 Feb 2017 22:43:26 +0100
Michael Niedermayer  wrote:

> On Fri, Feb 10, 2017 at 01:35:34PM +0100, wm4 wrote:
> > From: Anton Khirnov 
> > 
> > This will be useful in the following commit, after which the muxer
> > timebase is not always available when encoding.
> > 
> > This merges Libav commit 3e265ca. It was previously skipped.
> > 
> > There is a minor change with setting the mux_timebase field only after
> > the muxer's write_header function has been called, because it can
> > readjust the timebase.
> > 
> > Includes a minor merge fix by Mark Thompson.
> > 
> > Signed-off-by: wm4 
> > ---
> >  ffmpeg.c | 39 ++-
> >  ffmpeg.h |  2 ++
> >  2 files changed, 24 insertions(+), 17 deletions(-)  
> 
> Is this intended to result in no changes ?
> 
> ./ffmpeg -ss 15 -i ~/tickets/1332/Starship_Troopers.vob  -scodec dvbsub  
> -vcodec copy -t 4 -r 24000/1001 -an aaa.ts
> differs from before and after this patch
> 
> [...]

Is it different in a good or a bad way?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/4] aacsbr: Associate SBR data with AAC elements on init

[Alex Converse]

Quiets some log spam on pure upsampling mode.

Fixes ticket 5163.
---
 libavcodec/aacdec_template.c | 2 +-
 libavcodec/aacsbr.h  | 2 +-
 libavcodec/aacsbr_template.c | 3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index e230c87733..d980ae0e22 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -134,7 +134,7 @@ static av_cold int che_configure(AACContext *ac,
 if (!ac->che[type][id]) {
 if (!(ac->che[type][id] = av_mallocz(sizeof(ChannelElement
 return AVERROR(ENOMEM);
-AAC_RENAME(ff_aac_sbr_ctx_init)(ac, >che[type][id]->sbr);
+AAC_RENAME(ff_aac_sbr_ctx_init)(ac, >che[type][id]->sbr, type);
 }
 if (type != TYPE_CCE) {
 if (*channels >= MAX_CHANNELS - (type == TYPE_CPE || (type == 
TYPE_SCE && ac->oc[1].m4ac.ps == 1))) {
diff --git a/libavcodec/aacsbr.h b/libavcodec/aacsbr.h
index 88c4d8a916..dd8b66c7bb 100644
--- a/libavcodec/aacsbr.h
+++ b/libavcodec/aacsbr.h
@@ -81,7 +81,7 @@ static const int8_t vlc_sbr_lav[10] =
 /** Initialize SBR. */
 void AAC_RENAME(ff_aac_sbr_init)(void);
 /** Initialize one SBR context. */
-void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication 
*sbr);
+void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication 
*sbr, int id_aac);
 /** Close one SBR context. */
 void AAC_RENAME(ff_aac_sbr_ctx_close)(SpectralBandReplication *sbr);
 /** Decode one SBR element. */
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index 511054276a..f8aa4854df 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -81,11 +81,12 @@ static void sbr_turnoff(SpectralBandReplication *sbr) {
 memset(>spectrum_params, -1, sizeof(SpectrumParameters));
 }
 
-av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, 
SpectralBandReplication *sbr)
+av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, 
SpectralBandReplication *sbr, int id_aac)
 {
 if(sbr->mdct.mdct_bits)
 return;
 sbr->kx[0] = sbr->kx[1];
+sbr->id_aac = id_aac;
 sbr_turnoff(sbr);
 sbr->data[0].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE 
- (1280 - 128);
 sbr->data[1].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE 
- (1280 - 128);
-- 
2.11.0.483.g087da7b7c-goog

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

[FFmpeg-devel] [PATCH v2 1/4] aac_latm: Allow unaligned AudioSpecificConfig

[Alex Converse]

Fixes ticket 4730
---
 libavcodec/aacdec.c  | 26 --
 libavcodec/aacdec_template.c | 82 
 libavcodec/mpeg4audio.c  | 76 ++--
 libavcodec/mpeg4audio.h  | 12 ++-
 4 files changed, 120 insertions(+), 76 deletions(-)

diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ee9b4eb45f..709ac7cdf8 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -284,9 +284,10 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 AACContext *ac= >aac_ctx;
 AVCodecContext *avctx = ac->avctx;
 MPEG4AudioConfig m4ac = { 0 };
+GetBitContext gbc;
 int config_start_bit  = get_bits_count(gb);
 int sync_extension= 0;
-int bits_consumed, esize;
+int bits_consumed, esize, i;
 
 if (asclen) {
 sync_extension = 1;
@@ -294,19 +295,19 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 } else
 asclen = get_bits_left(gb);
 
-if (config_start_bit % 8) {
-avpriv_request_sample(latmctx->aac_ctx.avctx,
-  "Non-byte-aligned audio-specific config");
-return AVERROR_PATCHWELCOME;
-}
 if (asclen <= 0)
 return AVERROR_INVALIDDATA;
-bits_consumed = decode_audio_specific_config(NULL, avctx, ,
- gb->buffer + (config_start_bit / 8),
- asclen, sync_extension);
 
-if (bits_consumed < 0)
+init_get_bits(, gb->buffer, config_start_bit + asclen);
+skip_bits_long(, config_start_bit);
+
+bits_consumed = decode_audio_specific_config_gb(NULL, avctx, ,
+, config_start_bit,
+sync_extension);
+
+if (bits_consumed < config_start_bit)
 return AVERROR_INVALIDDATA;
+bits_consumed -= config_start_bit;
 
 if (!latmctx->initialized ||
 ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
@@ -329,7 +330,10 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 }
 
 avctx->extradata_size = esize;
-memcpy(avctx->extradata, gb->buffer + (config_start_bit/8), esize);
+gbc = *gb;
+for (i = 0; i < esize; i++) {
+  avctx->extradata[i] = get_bits(, 8);
+}
 memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 }
 skip_bits_long(gb, bits_consumed);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 83e9fb55ba..e230c87733 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -715,6 +715,13 @@ static void decode_channel_map(uint8_t layout_map[][3],
 }
 }
 
+static inline void relative_align_get_bits(GetBitContext *gb,
+   int reference_position) {
+int n = (reference_position - get_bits_count(gb) & 7);
+if (n)
+skip_bits(gb, n);
+}
+
 /**
  * Decode program configuration element; reference: table 4.2.
  *
@@ -722,7 +729,7 @@ static void decode_channel_map(uint8_t layout_map[][3],
  */
 static int decode_pce(AVCodecContext *avctx, MPEG4AudioConfig *m4ac,
   uint8_t (*layout_map)[3],
-  GetBitContext *gb)
+  GetBitContext *gb, int byte_align_ref)
 {
 int num_front, num_side, num_back, num_lfe, num_assoc_data, num_cc;
 int sampling_index;
@@ -770,7 +777,7 @@ static int decode_pce(AVCodecContext *avctx, 
MPEG4AudioConfig *m4ac,
 decode_channel_map(layout_map + tags, AAC_CHANNEL_CC,gb, num_cc);
 tags += num_cc;
 
-align_get_bits(gb);
+relative_align_get_bits(gb, byte_align_ref);
 
 /* comment field, first byte is length */
 comment_len = get_bits(gb, 8) * 8;
@@ -792,6 +799,7 @@ static int decode_pce(AVCodecContext *avctx, 
MPEG4AudioConfig *m4ac,
  */
 static int decode_ga_specific_config(AACContext *ac, AVCodecContext *avctx,
  GetBitContext *gb,
+ int get_bit_alignment,
  MPEG4AudioConfig *m4ac,
  int channel_config)
 {
@@ -815,7 +823,7 @@ static int decode_ga_specific_config(AACContext *ac, 
AVCodecContext *avctx,
 
 if (channel_config == 0) {
 skip_bits(gb, 4);  // element_instance_tag
-tags = decode_pce(avctx, m4ac, layout_map, gb);
+tags = decode_pce(avctx, m4ac, layout_map, gb, get_bit_alignment);
 if (tags < 0)
 return tags;
 } else {
@@ -937,37 +945,25 @@ static int decode_eld_specific_config(AACContext *ac, 
AVCodecContext *avctx,
  * @param   ac  pointer to AACContext, may be null
  * @param   avctx   pointer to AVCCodecContext, used for logging
  * @param   m4acpointer to MPEG4AudioConfig, used for parsing
- * @param  

Re: [FFmpeg-devel] [PATCH] (for discussion): cuvid: allow to crop and resize in decoder

[wm4]

On Sun, 12 Feb 2017 21:07:40 +0100
Miroslav Slugeň  wrote:

> Dne 12.2.2017 v 20:59 Hendrik Leppkes napsal(a):
> > On Sun, Feb 12, 2017 at 8:51 PM, Miroslav Slugeň  
> > wrote:  
> >> This patch is for discussion only, not ready to commit yet.
> >>
> >> 1. Cuvid decoder actualy support scaling input to requested resolution
> >> without any performance penalty (like libnpp does), so this patch is proof
> >> of concept that it is working like expected.
> >>  
> > I don't think scaling is something a decoder should be doing, we don't
> > really want all sorts of video processing jumbled up into one
> > monolithic cuvid thing, but rather keep tasks separated.
> >
> > - Hendrik
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel  
> Yes, but when you transcoding from FHD or 4K to SD quality it could save 
> alotof GPU resources.
> 
> We have one example where "ONE" Quadro P5000 (2xNVENC) is downscaling 
> about 74 FHD streams to SD at realtime.
> 
> I know it is not something that is acceptable in current ffmpeg, maybe 
> libav could adopt this patch.

You mean the Libav project? They'd be even less likely to accept such a
patch.

Anyway, I don't think this would be slower than doing it in some sort
of separate cuda video filter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg: prefer cuvid decoders when use option -cuvid

[wm4]

On Sun, 12 Feb 2017 21:20:12 +
Mark Thompson  wrote:

> On 12/02/17 20:37, Miroslav Slugeň wrote:
> > This patch is for discussion only, not ready to commit yet and maybe newer 
> > will be.
> > 
> > We were facing issue when using -hwaccel cuvid we have to also specify 
> > input decoder like -c:v _cuvid for every input and input video format 
> > was sometimes mpeg2/h264/hevc. So this is my FIX/HACK to only specify 
> > -cuvid and ffmpeg will pick cuvid decoder for any supported input.
> > 
> > I don't know correct solution for this yet.  
> 
> Adding global variables to libraries to mess with their internals is not an 
> acceptable solution to anything.
> 
> The correct solution to this problem is to write a real cuvid hwaccel, which 
> works within the existing decoder to offer decoding of streams which it 
> supports without changing the behaviour at all in normal software cases 
> (compare the behaviour of cuvid (standalone decoder) with dxva2, vaapi or 
> vdpau (full hwaccels inside the normal decoder)).
> 
> An alternative solution for your specific case would be to disable the normal 
> H.264, MPEG-2, etc. decoders in your build, such that the cuvid decoder 
> appears first in the list and would always be picked for any given stream.  
> (This of course would also remove support for the wider set of streams which 
> the libavcodec decoders support, such as H.264 at higher big depths, though 
> given that your patch here also has that effect I assume you aren't 
> particularly concerned about that case.)

What's the problem with just specifying the correct decoder? Both API
and ffmpeg.c allow doing this.

Although what I don't like is that API users need to do not-so-clean
things to find the right decoder, e.g. relying on the naming
conventions, and assuming you can get the the cuda wrapper by
concatenating the codec and API names e.g. h264 -> "h264_cuda".
Maybe adding decoder and API fields to AVHWAccel would be nice.
Then ffmpeg.c could get an option to select codecs by API too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/fmvc: find Uninitialized variables for Coverity

[Steven Liu]

2017-02-13 7:43 GMT+08:00 Steven Liu :

> Initialized variables opcode to indent
>
> Signed-off-by: Steven Liu 
> ---
>  libavcodec/fmvc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/fmvc.c b/libavcodec/fmvc.c
> index 54bb6f9..5e54d33 100644
> --- a/libavcodec/fmvc.c
> +++ b/libavcodec/fmvc.c
> @@ -53,7 +53,7 @@ typedef struct FMVCContext {
>
>  static int decode_type2(GetByteContext *gb, PutByteContext *pb)
>  {
> -unsigned repeat = 0, first = 1, opcode;
> +unsigned repeat = 0, first = 1, opcode = 0;
>  int i, len, pos;
>
>  while (bytestream2_get_bytes_left(gb) > 0) {
> --
> 2.10.1.382.ga23ca1b.dirty
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


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

Re: [FFmpeg-devel] [PATCH v2 0/5] A native Opus encoder

[Rostislav Pehlivanov]

On 12 February 2017 at 11:33, Nicolas George  wrote:

> Le tridi 23 pluviôse, an CCXXV, Rostislav Pehlivanov a écrit :
> > This series of commits implements a native Opus encoder.
>
> That is wonderful news.
>
> I do not have the knowledge to review the patches themselves.
>
> But I think they are missing an essential, but fortunately rather easy,
> part: user documentation.
>
> Most importantly, I think it absolutely needs something to tell the user
> how it compares to the reference libopus encoder: does it yield better
> quality per bitrate? slightly lower quality but incredibly faster?
> sometimes better sometimes worst depending on options?
>
>
Hi,

For now it'll always yield worse than or equal quality than the reference
encoder.
The psychoacoustic system will change that, which is what I'm working on.
Thanks for the suggestion though, I'll be sure to write an entry to the
encoders
documentation and especially the wiki, even though the encoder has 1 option
right now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/fmvc: find Uninitialized variables for Coverity

[Steven Liu]

Initialized variables opcode to indent

Signed-off-by: Steven Liu 
---
 libavcodec/fmvc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/fmvc.c b/libavcodec/fmvc.c
index 54bb6f9..5e54d33 100644
--- a/libavcodec/fmvc.c
+++ b/libavcodec/fmvc.c
@@ -53,7 +53,7 @@ typedef struct FMVCContext {
 
 static int decode_type2(GetByteContext *gb, PutByteContext *pb)
 {
-unsigned repeat = 0, first = 1, opcode;
+unsigned repeat = 0, first = 1, opcode = 0;
 int i, len, pos;
 
 while (bytestream2_get_bytes_left(gb) > 0) {
-- 
2.10.1.382.ga23ca1b.dirty



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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix stream level metadata handling

[Steven Liu]

2017-02-12 9:36 GMT+08:00 Steven Liu :

>
>
> 2017-02-12 5:31 GMT+08:00 Bodecs Bela :
>
>> Dear All,
>>
>> hls-encoder currently does not provide stream level metadata to mpegts
>> muxer. This patch also fixes track #3848 bug.
>>
>> Please review this bug fix. Thank you in advance.
>>
>>
>> best regards,
>>
>> Bela Bodecs
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
>
> hls-encoder currenlty does not provide stream level metadata to mpegts
> muxer. This patch fixes track #3848 bug.
>
> Signed-off-by: Bela Bodecs 
> ---
>  libavformat/hlsenc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index bd1e684..a58ded9 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -446,6 +446,7 @@ static int hls_mux_init(AVFormatContext *s)
>  avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar);
>  st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
>  st->time_base = s->streams[i]->time_base;
> +av_dict_copy(>metadata, s->streams[i]->metadata, 0);
>  }
>  hls->start_pos = 0;
>  hls->new_start = 1;
> --
> 2.5.3.windows.1
>
>
>
>
> LGTM
>
>
>
>
>
> Thanks
>


applied!

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

Re: [FFmpeg-devel] [PATCH] hlsenc: intialize only on ref_pkt and drop all packets

[Michael Niedermayer]

On Sun, Feb 12, 2017 at 07:31:43PM +0100, Miroslav Slugeň wrote:
> This patch will fix cutting hls segments into exactly same length.
> Because it will intialize only on first ref_packet, which is video
> frame, not audio frame (old behavior)
> 
> It will also drop all packets without PTS, drop all packets before
> initialization and drop all packets before first intialization
> packet PTS.
> 
> Now it should be possible to create segments at exactly same length
> if we use new -force_key_frames hls:time_in_seconds parameter.
> 
> This is required to support adaptive HLS.
> 
> -- 
> Miroslav Slugeň
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

>  hlsenc.c |   24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 7f784939c938c7697be2178647828a36815fc731  
> 0001-hlsenc-intialize-only-on-ref_pkt-and-drop-all-packet.patch
> From a59a7dbe6fdcab64c1402adb8f11cc31400f4516 Mon Sep 17 00:00:00 2001
> From: Miroslav Slugen 
> Date: Sun, 12 Feb 2017 19:25:54 +0100
> Subject: [PATCH 1/1] hlsenc: intialize only on ref_pkt and drop all packets
>  before initialized
> 
> ---
>  libavformat/hlsenc.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index ad5205a..226dd89 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1278,10 +1278,6 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  oc = hls->avf;
>  stream_index = pkt->stream_index;
>  }
> -if (hls->start_pts == AV_NOPTS_VALUE) {
> -hls->start_pts = pkt->pts;
> -hls->end_pts   = pkt->pts;
> -}
>  
>  if (hls->has_video) {
>  can_split = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
> @@ -1292,6 +1288,11 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  is_ref_pkt = can_split = 0;
>  
>  if (is_ref_pkt) {
> +if (hls->start_pts == AV_NOPTS_VALUE) {
> +hls->start_pts = pkt->pts;
> +hls->end_pts   = pkt->pts;
> +}
> +
>  if (hls->new_start) {
>  hls->new_start = 0;
>  hls->duration = (double)(pkt->pts - hls->end_pts)
> @@ -1371,6 +1372,21 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  }
>  }
>  
> +if (pkt->pts == AV_NOPTS_VALUE) {
> +av_log(s, AV_LOG_WARNING, "packet has no PTS, dropping packet from 
> stream: %d\n", pkt->stream_index);
> +return 0;
> +}
> +
> +if (hls->start_pts == AV_NOPTS_VALUE) {
> +av_log(s, AV_LOG_WARNING, "stream not initialized yet, dropping 
> packet from stream: %d\n", pkt->stream_index);
> +return 0;
> +}
> +
> +if (pkt->pts + pkt->duration <= hls->start_pts) {
> +av_log(s, AV_LOG_WARNING, "packet has PTS < START PTS (%"PRId64" < 
> %"PRId64"), dropping packet from stream: %d\n", pkt->pts, hls->start_pts, 
> pkt->stream_index);
> +return 0;
> +}

This triggers for subtitle streams, for example:

./ffmpeg -i matrixbench_mpeg2.mpg -i 
fate-suite/sub/MovText_capability_tester.mp4  -f hls  -hls_segment_filename  
/tmp/file.%d.ts -t 10   /tmp/file.m3u8


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

[Timo Rothenpieler]

> I just tried your build with this cmd line:
> 
> ffmpeg -hwaccel cuvid -c:v h264_cuvid -i simpson_1920p_h264.mp4 -y -c:v
> hevc_nvenc -an -b:v 512K -qmin 5 -qmax 50 -preset slow
> out_1920p_1920p_hq.mp4
> 
> And everything works well, do you have not working example?
> 
> I have GTX 1060 3GB with current stable drivers.
> 
> M.

That's what it looks like for me:
https://bpaste.net/show/890855410dac

Happens on two independend machines, on both Windows using MSVC and
Linux with gcc.
Both machines are definitely nowehre near out of memory, on either
system or device memory.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

[Philip Langdale]

On Sun, 12 Feb 2017 22:43:41 +0100
Miroslav Slugeň  wrote:

> Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a):
> > On 2/12/2017 10:25 PM, Miroslav Slugeň wrote:  
> >> This patch is for discussion only, not ready to commit yet and
> >> maybe newer will be.
> >>
> >> NVENC in current CUDA 8 SDK is setting wrong aspect ratio when
> >> encoding resolution 720x576 and 720x480 and using AR 4:3 or 16:9
> >> it will encode to h264 header that 15:11 and 20:11 is used. This
> >> is very very very ugly way how to fix it. I hope someone in NVIDIA
> >> will fix this soon, because all encoded streams are not displayed
> >> correctly for example in videojs player.  
> > nvenc.c had some compensation for this, which was somewhat recently
> > removed, because nvidia fixed something regarding it:
> >
> > http://git.videolan.org/?p=ffmpeg.git;a=commit;h=829db8effd76b579ae9aca5ee8f85d3ade6af253
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel  
> I know that, i am monitoring all nvenc and cuvid changes in ffmpeg.
> 
> Fix is not working anymore in current drivers. What is working is if
> you set aspect ratio 16000x9001 it will give you almost correct
> output, but fixing this in h264 SPP is better solution.
> 
> M.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

If it's still happening, let's just restore the original workaround.
But I stopped being able to reproduce the problem locally, and I can't
reproduce it right now with a 720x576 sample.

Note that the SDK is completely irrelevant to playback behaviour. The
CUDA SDK doesn't include current cuvid/nvenc headers and the Video SDK
isn't required because we bundle/reimplement headers with ffmpeg.

You are likely not using a new enough driver release to have the fix in
it. I'm using 378.09 here.

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

Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

[Timo Rothenpieler]

On 2/12/2017 10:43 PM, Miroslav Slugeň wrote:
> Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a):
>> On 2/12/2017 10:25 PM, Miroslav Slugeň wrote:
>>> This patch is for discussion only, not ready to commit yet and maybe
>>> newer will be.
>>>
>>> NVENC in current CUDA 8 SDK is setting wrong aspect ratio when encoding
>>> resolution 720x576 and 720x480 and using AR 4:3 or 16:9 it will encode
>>> to h264 header that 15:11 and 20:11 is used. This is very very very ugly
>>> way how to fix it. I hope someone in NVIDIA will fix this soon, because
>>> all encoded streams are not displayed correctly for example in videojs
>>> player.
>> nvenc.c had some compensation for this, which was somewhat recently
>> removed, because nvidia fixed something regarding it:
>>
>> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=829db8effd76b579ae9aca5ee8f85d3ade6af253
> I know that, i am monitoring all nvenc and cuvid changes in ffmpeg.
> 
> Fix is not working anymore in current drivers. What is working is if you
> set aspect ratio 16000x9001 it will give you almost correct output, but
> fixing this in h264 SPP is better solution.
> 
> M.

Imo the best would be to contact nvidia about this potential bug.
Maybe a leftover from removing the old compensation logic?
Actually fixing the driver would definitely be the best solution here.

Adding some of the @nvidia.com people from this ML to CC, maybe they can
forward the issue to the right place.



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

Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

[Miroslav Slugeň]

Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a):

On 2/12/2017 10:25 PM, Miroslav Slugeň wrote:

This patch is for discussion only, not ready to commit yet and maybe
newer will be.

NVENC in current CUDA 8 SDK is setting wrong aspect ratio when encoding
resolution 720x576 and 720x480 and using AR 4:3 or 16:9 it will encode
to h264 header that 15:11 and 20:11 is used. This is very very very ugly
way how to fix it. I hope someone in NVIDIA will fix this soon, because
all encoded streams are not displayed correctly for example in videojs
player.

nvenc.c had some compensation for this, which was somewhat recently
removed, because nvidia fixed something regarding it:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=829db8effd76b579ae9aca5ee8f85d3ade6af253
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I know that, i am monitoring all nvenc and cuvid changes in ffmpeg.

Fix is not working anymore in current drivers. What is working is if you 
set aspect ratio 16000x9001 it will give you almost correct output, but 
fixing this in h264 SPP is better solution.


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

Re: [FFmpeg-devel] [PATCH v2] lavc/libzvbi: remove deprecated API usage

[Josh de Kock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/02/2017 15:28, Marton Balint wrote:
> 
> On Sun, 12 Feb 2017, Josh de Kock wrote:
> 
>> Hi Carl,
>> 
>> I'm not sure, 0.2.28 doesn't compile on my system. It has been
>> tested with the latest version 0.2.38.
> 
> I only checked the source code, and in 0.2.28 the function is
> already deprecated. So the original patch should be fine, I prefer
> that.
> 
> Regards, Marton

Applied without the last bit

Thanks,

- -- 
Josh

PGP fingerprint: A93A602D7A6D3C5388D792BCD052D40DDEF9703D
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYoNZHAAoJENBS1A3e+XA9j3YP/0EzW4l6ffB9Ty9Hw5/z1XmY
bXxexmgpKbYaAx3ZOGyKAI/dk1AV+wKVMZP+5SJdMcocUDRcU5IUaQoM/hM926Ml
3ypv5DuymsEzUe4vRPHFdRb2ggLsp+2muv0fYZQEFq1eYBjFwQ6ELT7OiYuLVkUS
2vRxCkuPF/jIlKY4NAu7X8feO3LOc6pXxkn/k1qW665PMyxR+RzCwXKgRsAnpBGy
PbPxniZgK75XfJPNkX2tnUh+3JNeEOFlIA52kOqKa1cxAMQ15EJhvTSvi6NsRbG2
m5b1wkJfG4uLipaawk4w4DwddI6r0/O0M4HN8DO7c3isPYujZhNT133ZGEBzE161
lmv4AeGJUbuIqXnoJaLVqinQDxTY+FsGXX/2f66fBBwgxSjZigm/Hn0JX55xhlu/
ETidTppUM5SQyC1NGXz2iDTPvApagW5NMn/SBpqaIfOOrZPJfTel9yesx2xBR83h
YuU9Q8AplC0967Udbkw175zMxKW3/moxcX1R6AMGLUOwz+O70QOuFWcTUOqA4Ron
tO0nzuf/MvPxSDIRaCsEH+PoCNmrRQ5NpomeqPQQF0amt3s0jYoMRrJsr5k6dATE
4zqDcMjjZCLn/GvORPp+NlaifM++OhQNYwvJXvw/4g5LBDzSO9B7XtfobatWHJks
7/l2XOOwh2mYSDc3dIPi
=rMSh
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

[Timo Rothenpieler]

On 2/12/2017 10:25 PM, Miroslav Slugeň wrote:
> This patch is for discussion only, not ready to commit yet and maybe
> newer will be.
> 
> NVENC in current CUDA 8 SDK is setting wrong aspect ratio when encoding
> resolution 720x576 and 720x480 and using AR 4:3 or 16:9 it will encode
> to h264 header that 15:11 and 20:11 is used. This is very very very ugly
> way how to fix it. I hope someone in NVIDIA will fix this soon, because
> all encoded streams are not displayed correctly for example in videojs
> player.

nvenc.c had some compensation for this, which was somewhat recently
removed, because nvidia fixed something regarding it:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=829db8effd76b579ae9aca5ee8f85d3ade6af253
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

[Miroslav Slugeň]

This patch is for discussion only, not ready to commit yet and maybe 
newer will be.


NVENC in current CUDA 8 SDK is setting wrong aspect ratio when encoding 
resolution 720x576 and 720x480 and using AR 4:3 or 16:9 it will encode 
to h264 header that 15:11 and 20:11 is used. This is very very very ugly 
way how to fix it. I hope someone in NVIDIA will fix this soon, because 
all encoded streams are not displayed correctly for example in videojs 
player.


Support for HEVC is currently broken.

--
Miroslav Slugeň
















>From 2300c38e381ee9bf4af96e6c0f6d05193738bcab Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 22:19:02 +0100
Subject: [PATCH 1/1] nvenc: fix wrong aspect ratio for 720x576 and 720x480
 resolutions

---
 libavcodec/nvenc.c|   4 +
 libavcodec/nvenc_ar.c | 414 ++
 2 files changed, 418 insertions(+)
 create mode 100644 libavcodec/nvenc_ar.c

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 7005465..87284b7 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -31,6 +31,8 @@
 #include "libavutil/pixdesc.h"
 #include "internal.h"
 
+#include "nvenc_ar.c"
+
 #define NVENC_CAP 0x30
 #define IS_CBR(rc) (rc == NV_ENC_PARAMS_RC_CBR ||   \
 rc == NV_ENC_PARAMS_RC_2_PASS_QUALITY ||\
@@ -1613,6 +1615,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (res < 0)
 goto error2;
 
+nvenc_sar_fix(avctx, pkt);
+
 av_free(slice_offsets);
 
 return 0;
diff --git a/libavcodec/nvenc_ar.c b/libavcodec/nvenc_ar.c
new file mode 100644
index 000..a45c7fb
--- /dev/null
+++ b/libavcodec/nvenc_ar.c
@@ -0,0 +1,414 @@
+
+typedef struct nal_unit {
+AVPacket *pkt;
+
+int reset;
+
+uint8_t *b;
+int bs;
+
+int nal_ref_idc;
+int nal_unit_type;
+
+int profile_idc;
+int level_idc;
+int seq_parameter_set_id;
+
+int chroma_format_idc;
+int residual_colour_transform_flag;
+int bit_depth_luma_minus8;
+int bit_depth_chroma_minus8;
+int qpprime_y_zero_transform_bypass_flag;
+int seq_scaling_matrix_present_flag;
+int seq_scaling_list_present_flag[8];
+int* scaling_list_4x4[6];
+int UseDefaultScalingMatrix4x4Flag[6];
+int* scaling_list_8x8[2];
+int UseDefaultScalingMatrix8x8Flag[2];
+
+
+int log2_max_frame_num_minus4;
+int pic_order_cnt_type;
+int log2_max_pic_order_cnt_lsb_minus4;
+int delta_pic_order_always_zero_flag;
+int offset_for_non_ref_pic;
+int offset_for_top_to_bottom_field;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int offset_for_ref_frame[256];
+int num_ref_frames;
+int gaps_in_frame_num_value_allowed_flag;
+int pic_width_in_mbs_minus1;
+int pic_height_in_map_units_minus1;
+int frame_mbs_only_flag;
+int mb_adaptive_frame_field_flag;
+int direct_8x8_inference_flag;
+int frame_cropping_flag;
+int frame_crop_left_offset;
+int frame_crop_right_offset;
+int frame_crop_top_offset;
+int frame_crop_bottom_offset;
+int vui_parameters_present_flag;
+
+struct {
+int aspect_ratio_info_present_flag;
+int aspect_ratio_idc;
+int sar_width;
+int sar_height;
+int overscan_info_present_flag;
+int overscan_appropriate_flag;
+int video_signal_type_present_flag;
+int video_format;
+int video_full_range_flag;
+int colour_description_present_flag;
+int colour_primaries;
+int transfer_characteristics;
+int matrix_coefficients;
+int chroma_loc_info_present_flag;
+int chroma_sample_loc_type_top_field;
+int chroma_sample_loc_type_bottom_field;
+int timing_info_present_flag;
+int num_units_in_tick;
+int time_scale;
+int fixed_frame_rate_flag;
+int nal_hrd_parameters_present_flag;
+int vcl_hrd_parameters_present_flag;
+int low_delay_hrd_flag;
+int pic_struct_present_flag;
+int bitstream_restriction_flag;
+int motion_vectors_over_pic_boundaries_flag;
+int max_bytes_per_pic_denom;
+int max_bits_per_mb_denom;
+int log2_max_mv_length_horizontal;
+int log2_max_mv_length_vertical;
+int num_reorder_frames;
+int max_dec_frame_buffering;
+} vui;
+
+} nal_unit;
+
+
+static int nal_unit_find (uint8_t* b, int bs, int* start, int* end) {
+int i;
+
+*start = 0;
+*end = 0;
+
+for (i = 0; i < bs; i++) {
+if ((i + 3 <= bs) && (b[i] == 0 && b[i + 1] == 0 && b[i + 2] == 0x01)) {
+i+= 3;
+goto found;
+}
+
+if ((i + 4 <= bs) && (b[i] == 0 && b[i + 1] == 0 && b[i + 2] == 0 && b[i + 3] == 0x01)) {
+i+= 4;
+goto found;
+}
+}
+
+goto not_found;
+
+found:
+*start = i;
+
+for (; i < bs; i++) {
+if (((i + 3 <= bs) && (b[i] == 0 && b[i + 1] == 0 && b[i + 2] == 0x01)) ||
+ 

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg: prefer cuvid decoders when use option -cuvid

[Mark Thompson]

On 12/02/17 20:37, Miroslav Slugeň wrote:
> This patch is for discussion only, not ready to commit yet and maybe newer 
> will be.
> 
> We were facing issue when using -hwaccel cuvid we have to also specify input 
> decoder like -c:v _cuvid for every input and input video format was 
> sometimes mpeg2/h264/hevc. So this is my FIX/HACK to only specify -cuvid and 
> ffmpeg will pick cuvid decoder for any supported input.
> 
> I don't know correct solution for this yet.

Adding global variables to libraries to mess with their internals is not an 
acceptable solution to anything.

The correct solution to this problem is to write a real cuvid hwaccel, which 
works within the existing decoder to offer decoding of streams which it 
supports without changing the behaviour at all in normal software cases 
(compare the behaviour of cuvid (standalone decoder) with dxva2, vaapi or vdpau 
(full hwaccels inside the normal decoder)).

An alternative solution for your specific case would be to disable the normal 
H.264, MPEG-2, etc. decoders in your build, such that the cuvid decoder appears 
first in the list and would always be picked for any given stream.  (This of 
course would also remove support for the wider set of streams which the 
libavcodec decoders support, such as H.264 at higher big depths, though given 
that your patch here also has that effect I assume you aren't particularly 
concerned about that case.)

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

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

[Timo Rothenpieler]

> I have seen those patches in mailing list. Have you tried it on QUADRO
> cards which are not limited to only 2 streams per system? It could be
> related to protection in NVIDIA drivers for NON-PRO cards.

It it definitely not related to that limitation, that fails way ealier
and with a somewhat proper error code.
We are currently suspecting that it's some weird initialization order
issue, or some value is not passed correctly, like frame dimensions, but
from all my poking, everything looks perfectly in order.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Ignore expired cookies

[Micah Galizia]

On Sun, Feb 12, 2017 at 6:28 AM, Nicolas George  wrote:
> Thanks for the patch. See remarks below.
>
> Le tridi 23 pluviôse, an CCXXV, Micah Galizia a écrit :
>> On some authenticated Neulion streams, they send a cookie from the past,
>> like so:
>>
>> Set-Cookie: nlqptid=""; Domain=.neulion.com; Expires=Thu, 01-Jan-1970
>> 00:00:10 GMT; Path=/
>>
>> As a result, the good cookie value is overwritten and authentication breaks
>> immediately. I realise disqualifying a cookie over the date might open a
>> can of worms when it comes to date formatting used by different systems,
>
> In principle, I would be in favour of correctly heeding all elements of
> the protocol, and only on top of that provide users the option of
> ignoring certain elements. Parsing the expires field certainly enters
> this frame.
>
>> but I added Neulions wrong format and the http standard format.
>
> In that case, maybe ignoring the whole cookie because the date is
> invalid would be a better idea.

Maybe a more permissive approach would be better. Iff we _can_ parse
the date format _AND_ it's expired then and only then ignore that
cookie. This would maintain compatibility with how it works now, but
correct the specific bug I'm observing.

> Did you test to see how real browsers handle it?

Browsers, no, but the Android video player, yes. They ignore the new
cookie value if it shows up with an expiry in the past (well, at least
an expiry date in 1970) and use the value it had already. Here is a
charles dump if you want to see:
https://dl.dropboxusercontent.com/u/83154919/snnow_full2.chls

>> Please let me know if this is acceptable. I've run it against fate and
>> there were no problems.
>
> That is good practice. Unfortunately, FATE tests almost nothing about
> network protocols. If you did not, you need to check with a few web
> servers that currently work.

I tested it against the neulion stream I have access to. I don't have
a whole lot else but hopefully if I minimize the situations in which
cookies are ignored it wont matter. I'll also try to find a few other
stream sources.

> Now reviewing details of the latest version of the patch:
>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index 944a6cf..24368aa 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -682,12 +682,46 @@ static int parse_icy(HTTPContext *s, const char *tag, 
>> const char *p)
>>
>>  static int parse_cookie(HTTPContext *s, const char *p, AVDictionary 
>> **cookies)
>>  {
>> -char *eql, *name;
>> +char *eql, *name, *expiry;
>>
>>  // duplicate the cookie name (dict will dupe the value)
>>  if (!(eql = strchr(p, '='))) return AVERROR(EINVAL);
>>  if (!(name = av_strndup(p, eql - p))) return AVERROR(ENOMEM);
>>
>> +// ensure the expiry is sane
>
>> +if ((expiry = strstr(eql, "Expires="))) {
>
> I believe this is not correct. First, AFAIK, all the structure elements
> in HTTP are case insensitive. Second, the string "Expires=" could
> legitimately be part of the cookie value itself.
>
> I suggest to parse the subfields of the set-cookie field correctly: it
> is a sequence of "key=value" pairs (with the "=value" part optional, but
> can be quoted) separated by semicolons and optional spaces. Furthermore,
> it would be useful for other fields too, such as content-type.
>
> I realize it is a little bit more work, but I think it is reasonable.

I think this was proposed last time I was adding cookies into the HLS
demuxer (years ago) but the problem is that you can't really pass
around complex data structures between demuxers (http, hls, etc).
AVOption was also quite restrictive last time I looked into doing
something more advanced like that.

One of the things Michael N. suggested back then was using a proper
cookie jar -- is there any reason I can't keep parsed cookies in an
in-memory global static variable scoped in http.c? Then we wouldn't
even need to pass the cookies as options around between demuxers
anymore since they'd have a perminant home in http.c, which should be
the only place they're used.

>> +struct tm tm_buf = {0};
>> +char *end;
>> +
>> +// get the start & the end of the expiry ('11 Feb 2017 09:41:35 
>> GMT')
>> +// this skips past the day of the week by finding the space 
>> following it
>
>> +expiry += 8 * sizeof(char);
>
> sizeof(char) = 1 by definition, thus writing it is always unnecessary,
> and rarely useful for readability.
>
>> +while (*expiry != ' ') expiry++;
>
> I suspect tabs and other whitespace-style characters could be present
> here.
>
> More importantly, this code will happily skip the end-of-string marker
> if there are no spaces at all, and that is a big no.
>
> Also, style nit for here and other places: the code base does not
> usually use single-line loops or conditions.
>
>> +expiry++;
>> +end = expiry+1;
>
>> +while (*end != ';') end++;
>
> Same problem here.
>
>> +
>> +// 

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

[Miroslav Slugeň]

Dne 12.2.2017 v 20:59 Timo Rothenpieler napsal(a):

On 2/12/2017 8:53 PM, Miroslav Slugeň wrote:

Dne 12.2.2017 v 20:25 Timo Rothenpieler napsal(a):

On 2/12/2017 8:18 PM, Miroslav Slugeň wrote:

This patch is for discussion only, not ready to commit yet.

We were facing issue when using -hwaccel cuvid, then we were unable to
use -filter_complex filters for video streams, this hack fixed it, but i
am sure that it is not ready to commit, because it is dirty/ugly fix.

This collides with the merges and is probably obsolete once they happen.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thx, i am glad that someone is working on fixing this issue. We need to
have it working year ago, so i created this patch.

I wasn't aware there is any kind of issue.
You can try https://github.com/BtbN/FFmpeg/tree/filter-merge if you want
to test the current state of the merges.

There is some very weird issue with cuvid->nvenc hwaccel transcoding,
which I wasn't able to figure out yet, as nvenc just reports being out
of memory when encoding a frame.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I have seen those patches in mailing list. Have you tried it on QUADRO 
cards which are not limited to only 2 streams per system? It could be 
related to protection in NVIDIA drivers for NON-PRO cards.


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

[FFmpeg-devel] [PATCH] (for discussion): ffmpeg: prefer cuvid decoders when use option -cuvid

[Miroslav Slugeň]

This patch is for discussion only, not ready to commit yet and maybe 
newer will be.


We were facing issue when using -hwaccel cuvid we have to also specify 
input decoder like -c:v _cuvid for every input and input video 
format was sometimes mpeg2/h264/hevc. So this is my FIX/HACK to only 
specify -cuvid and ffmpeg will pick cuvid decoder for any supported input.


I don't know correct solution for this yet.

--
Miroslav Slugeň















>From 08e448c036166b645a0364c0a2a6b2b1dbdd869d Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 21:32:45 +0100
Subject: [PATCH 1/1] ffmpeg: prefer cuvid decoders when use option -cuvid

---
 ffmpeg.c   |  8 +++
 ffmpeg_opt.c   |  2 ++
 libavcodec/allcodecs.c | 57 ++
 libavcodec/avcodec.h   |  2 ++
 4 files changed, 60 insertions(+), 9 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 06570c0..a47dcd2 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -4557,6 +4557,14 @@ int main(int argc, char **argv)
 argv++;
 }
 
+avcodec_cuvid = 0;
+for (i = 1; i < argc; i++) {
+if (!strcmp(argv[i], "-cuvid")) {
+avcodec_cuvid = 1;
+break;
+}
+}
+
 avcodec_register_all();
 #if CONFIG_AVDEVICE
 avdevice_register_all();
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 6a47d32..46e440c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3582,6 +3582,8 @@ const OptionDef options[] = {
 "audio bitrate (please use -b:a)", "bitrate" },
 { "b",OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,{ .func_arg = opt_bitrate },
 "video bitrate (please use -b:v)", "bitrate" },
+{ "cuvid",  OPT_BOOL | OPT_EXPERT,   { _cuvid },
+"enable cuvid acceleration for input" },
 { "hwaccel",  OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT |
   OPT_SPEC | OPT_INPUT,  { .off = OFFSET(hwaccels) },
 "use HW accelerated decoding", "hwaccel name" },
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 3680129..e613728 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -58,6 +58,36 @@
 av_register_codec_parser(_##x##_parser); \
 }
 
+int avcodec_cuvid = 0;
+
+static void avcodec_register_cuvid_h264(void) {
+REGISTER_DECODER(H264_CUVID,h264_cuvid);
+}
+static void avcodec_register_cuvid_hevc(void) {
+REGISTER_DECODER(HEVC_CUVID,   hevc_cuvid);
+}
+static void avcodec_register_cuvid_mjpeg(void) {
+REGISTER_DECODER(MJPEG_CUVID,  mjpeg_cuvid);
+}
+static void avcodec_register_cuvid_mpeg1(void) {
+REGISTER_DECODER(MPEG1_CUVID,  mpeg1_cuvid);
+}
+static void avcodec_register_cuvid_mpeg2(void) {
+REGISTER_DECODER(MPEG2_CUVID,  mpeg2_cuvid);
+}
+static void avcodec_register_cuvid_mpeg4(void) {
+REGISTER_DECODER(MPEG4_CUVID,  mpeg4_cuvid);
+}
+static void avcodec_register_cuvid_vc1(void) {
+REGISTER_DECODER(VC1_CUVID,vc1_cuvid);
+}
+static void avcodec_register_cuvid_vp8(void) {
+REGISTER_DECODER(VP8_CUVID,vp8_cuvid);
+}
+static void avcodec_register_cuvid_vp9(void) {
+REGISTER_DECODER(VP9_CUVID,vp9_cuvid);
+}
+
 void avcodec_register_all(void)
 {
 static int initialized;
@@ -202,6 +232,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (H263,  h263);
 REGISTER_DECODER(H263I, h263i);
 REGISTER_ENCDEC (H263P, h263p);
+if (avcodec_cuvid) avcodec_register_cuvid_h264();
 REGISTER_DECODER(H264,  h264);
 REGISTER_DECODER(H264_CRYSTALHD,h264_crystalhd);
 REGISTER_DECODER(H264_MEDIACODEC,   h264_mediacodec);
@@ -212,6 +243,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(H264_VDPAU,h264_vdpau);
 #endif
 REGISTER_ENCDEC (HAP,   hap);
+if (avcodec_cuvid) avcodec_register_cuvid_hevc();
 REGISTER_DECODER(HEVC,  hevc);
 REGISTER_DECODER(HEVC_QSV,  hevc_qsv);
 REGISTER_DECODER(HNM4_VIDEO,hnm4_video);
@@ -237,6 +269,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(MAGICYUV,  magicyuv);
 REGISTER_DECODER(MDEC,  mdec);
 REGISTER_DECODER(MIMIC, mimic);
+if (avcodec_cuvid) avcodec_register_cuvid_mjpeg();
 REGISTER_ENCDEC (MJPEG, mjpeg);
 REGISTER_DECODER(MJPEGB,mjpegb);
 REGISTER_DECODER(MMVIDEO,   mmvideo);
@@ -244,8 +277,11 @@ void avcodec_register_all(void)
 #if FF_API_XVMC
 REGISTER_DECODER(MPEG_XVMC, mpeg_xvmc);
 #endif /* FF_API_XVMC */
+avcodec_register_cuvid_mpeg1();
 REGISTER_ENCDEC (MPEG1VIDEO,mpeg1video);
+avcodec_register_cuvid_mpeg2();
 REGISTER_ENCDEC (MPEG2VIDEO,mpeg2video);
+avcodec_register_cuvid_mpeg4();
 REGISTER_ENCDEC 

[FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option v2

[Miroslav Slugeň]

Add drop_second_field for CUVID input. It is not enabled by default this 
time and will fix reporting correct frame_rate


--
Miroslav Slugeň













>From c5277c84eba2b1f7b6ee92cf7cb4a2df23a9b536 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 21:20:56 +0100
Subject: [PATCH 1/1] cuvid: add drop_second_field as input option v2

---
 libavcodec/cuvid.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 9b35476..a90552b 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -42,6 +42,7 @@ typedef struct CuvidContext
 
 char *cu_gpu;
 int nb_surfaces;
+int drop_second_field;
 
 AVBufferRef *hwdevice;
 AVBufferRef *hwframe;
@@ -248,7 +249,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
 cuinfo.DeinterlaceMode = ctx->deint_mode;
 }
 
-if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave)
+if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave && !ctx->drop_second_field)
 avctx->framerate = av_mul_q(avctx->framerate, (AVRational){2, 1});
 
 ctx->internal_error = CHECK_CU(ctx->cvdl->cuvidCreateDecoder(>cudecoder, ));
@@ -298,8 +299,10 @@ static int CUDAAPI cuvid_handle_picture_display(void *opaque, CUVIDPARSERDISPINF
 } else {
 parsed_frame.is_deinterlacing = 1;
 av_fifo_generic_write(ctx->frame_queue, _frame, sizeof(CuvidParsedFrame), NULL);
-parsed_frame.second_field = 1;
-av_fifo_generic_write(ctx->frame_queue, _frame, sizeof(CuvidParsedFrame), NULL);
+if (!ctx->drop_second_field) {
+parsed_frame.second_field = 1;
+av_fifo_generic_write(ctx->frame_queue, _frame, sizeof(CuvidParsedFrame), NULL);
+}
 }
 
 return 1;
@@ -930,6 +933,7 @@ static const AVOption options[] = {
 { "adaptive", "Adaptive deinterlacing",  0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Adaptive }, 0, 0, VD, "deint" },
 { "gpu",  "GPU to be used for decoding", OFFSET(cu_gpu), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
 { "surfaces", "Maximum surfaces to be used for decoding", OFFSET(nb_surfaces), AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, VD },
+{ "drop_second_field", "Drop second field when deinterlacing", OFFSET(drop_second_field), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
 { NULL }
 };
 
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

[Miroslav Slugeň]

Dne 12.2.2017 v 21:01 Timo Rothenpieler napsal(a):

On 2/12/2017 8:56 PM, Miroslav Slugeň wrote:

2. We should change it in libx264 and libx265

Changing it in nvenc now would be kind of an API break, as the behaviour
might change without someone expecting it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I don't think so, onlything is changed is when you forcing keyframes
with -forced_keyframes option it was not working in NVENC without
specifiing -force_idr 0 or 1, is there any other situation when some
parts of ffmpeg will force key frames and NVENC naturaly ignore them?

It's primarily a concern with API users which might set the pict_type.
Probably does not affect any notable amount of users.
Might as well remove -1 as a supported value from the option then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I checked libx264 and there is -1 option, so i think it should stay 
there also for future use (like automatic IDR/INTRA decisions). But it 
could be removed also.


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

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

[Timo Rothenpieler]

On 2/12/2017 8:56 PM, Miroslav Slugeň wrote:
>>> 2. We should change it in libx264 and libx265
>> Changing it in nvenc now would be kind of an API break, as the behaviour
>> might change without someone expecting it.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> I don't think so, onlything is changed is when you forcing keyframes
> with -forced_keyframes option it was not working in NVENC without
> specifiing -force_idr 0 or 1, is there any other situation when some
> parts of ffmpeg will force key frames and NVENC naturaly ignore them?

It's primarily a concern with API users which might set the pict_type.
Probably does not affect any notable amount of users.
Might as well remove -1 as a supported value from the option then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

[Miroslav Slugeň]

Dne 12.2.2017 v 20:56 Timo Rothenpieler napsal(a):

On 2/12/2017 8:35 PM, Miroslav Slugeň wrote:

Thx for comment,

cuvid can't output 50fps deinterlaced output, both frames are same, and
default behavior for yadif is to downcovert to half frame rate, so i
think is very clever to do the same here.

Also if we return in decoder that input is framerate/2 when
deinterlacing we should stay with that!

if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave)
 avctx->framerate = av_mul_q(avctx->framerate, (AVRational){2, 1});

That equation multiplies the framerate by two, as deinterlacing doubles
it from for example 25 to 50, producing two output frames for each input
frame with two fields.

Judging from the cuvid examples, extracting two frames per interlaced
frame is the intended way of using the decoder, and at least in Adaptive
mode the frames are definitely not the same.
Never gave bob to much of a look, maybe it doesn't support it there.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Sorry, my fault, you are true, than please ignore this patch.

I will prepare updated one.

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

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

[Timo Rothenpieler]

On 2/12/2017 8:53 PM, Miroslav Slugeň wrote:
> Dne 12.2.2017 v 20:25 Timo Rothenpieler napsal(a):
>> On 2/12/2017 8:18 PM, Miroslav Slugeň wrote:
>>> This patch is for discussion only, not ready to commit yet.
>>>
>>> We were facing issue when using -hwaccel cuvid, then we were unable to
>>> use -filter_complex filters for video streams, this hack fixed it, but i
>>> am sure that it is not ready to commit, because it is dirty/ugly fix.
>> This collides with the merges and is probably obsolete once they happen.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Thx, i am glad that someone is working on fixing this issue. We need to
> have it working year ago, so i created this patch.

I wasn't aware there is any kind of issue.
You can try https://github.com/BtbN/FFmpeg/tree/filter-merge if you want
to test the current state of the merges.

There is some very weird issue with cuvid->nvenc hwaccel transcoding,
which I wasn't able to figure out yet, as nvenc just reports being out
of memory when encoding a frame.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] (for discussion): cuvid: allow to crop and resize in decoder

[Hendrik Leppkes]

On Sun, Feb 12, 2017 at 8:51 PM, Miroslav Slugeň  wrote:
> This patch is for discussion only, not ready to commit yet.
>
> 1. Cuvid decoder actualy support scaling input to requested resolution
> without any performance penalty (like libnpp does), so this patch is proof
> of concept that it is working like expected.
>

I don't think scaling is something a decoder should be doing, we don't
really want all sorts of video processing jumbled up into one
monolithic cuvid thing, but rather keep tasks separated.

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

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

[Miroslav Slugeň]

Dne 12.2.2017 v 20:52 Timo Rothenpieler napsal(a):

On 2/12/2017 8:43 PM, Miroslav Slugeň wrote:

Dne 12.2.2017 v 20:29 Timo Rothenpieler napsal(a):

The current behavior is intended like it is.
On the default of -1, it does not care about I/IDR frame requests, in
mode 0 it will generate intra frames, and in mode 1 it will generate
full IDR frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This is not clever, because i checked both libx264 and libx265 and both
of them has same behavior like i proposed in patch.

Also explanation of this function is than wrong:
{ "forced-idr",   "If forcing keyframes, force them as IDR frames."}

There is nothing about disabled forcing keyframes at all.

So we have two options:
1. We should change it in NVENC
or
2. We should change it in libx264 and libx265

Changing it in nvenc now would be kind of an API break, as the behaviour
might change without someone expecting it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I don't think so, onlything is changed is when you forcing keyframes 
with -forced_keyframes option it was not working in NVENC without 
specifiing -force_idr 0 or 1, is there any other situation when some 
parts of ffmpeg will force key frames and NVENC naturaly ignore them?


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

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

[Timo Rothenpieler]

On 2/12/2017 8:35 PM, Miroslav Slugeň wrote:
> Thx for comment,
> 
> cuvid can't output 50fps deinterlaced output, both frames are same, and
> default behavior for yadif is to downcovert to half frame rate, so i
> think is very clever to do the same here.
> 
> Also if we return in decoder that input is framerate/2 when
> deinterlacing we should stay with that!
> 
> if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave)
> avctx->framerate = av_mul_q(avctx->framerate, (AVRational){2, 1});

That equation multiplies the framerate by two, as deinterlacing doubles
it from for example 25 to 50, producing two output frames for each input
frame with two fields.

Judging from the cuvid examples, extracting two frames per interlaced
frame is the intended way of using the decoder, and at least in Adaptive
mode the frames are definitely not the same.
Never gave bob to much of a look, maybe it doesn't support it there.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

[Hendrik Leppkes]

On Sun, Feb 12, 2017 at 8:35 PM, Miroslav Slugeň  wrote:
> Thx for comment,
>
> cuvid can't output 50fps deinterlaced output, both frames are same, and
> default behavior for yadif is to downcovert to half frame rate, so i think
> is very clever to do the same here.
>

Thats not true, cuvid can output full 50fps deinterlaced output with
distinct different frames.

Please don't top post on this mailing list.

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

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

[Miroslav Slugeň]

Dne 12.2.2017 v 20:25 Timo Rothenpieler napsal(a):

On 2/12/2017 8:18 PM, Miroslav Slugeň wrote:

This patch is for discussion only, not ready to commit yet.

We were facing issue when using -hwaccel cuvid, then we were unable to
use -filter_complex filters for video streams, this hack fixed it, but i
am sure that it is not ready to commit, because it is dirty/ugly fix.

This collides with the merges and is probably obsolete once they happen.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Thx, i am glad that someone is working on fixing this issue. We need to 
have it working year ago, so i created this patch.


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

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

[Timo Rothenpieler]

On 2/12/2017 8:43 PM, Miroslav Slugeň wrote:
> Dne 12.2.2017 v 20:29 Timo Rothenpieler napsal(a):
>> The current behavior is intended like it is.
>> On the default of -1, it does not care about I/IDR frame requests, in
>> mode 0 it will generate intra frames, and in mode 1 it will generate
>> full IDR frames.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> This is not clever, because i checked both libx264 and libx265 and both
> of them has same behavior like i proposed in patch.
> 
> Also explanation of this function is than wrong:
> { "forced-idr",   "If forcing keyframes, force them as IDR frames."}
> 
> There is nothing about disabled forcing keyframes at all.
> 
> So we have two options:
> 1. We should change it in NVENC
> or
> 2. We should change it in libx264 and libx265

Changing it in nvenc now would be kind of an API break, as the behaviour
might change without someone expecting it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

[Miroslav Slugeň]

Dne 12.2.2017 v 20:29 Timo Rothenpieler napsal(a):

The current behavior is intended like it is.
On the default of -1, it does not care about I/IDR frame requests, in
mode 0 it will generate intra frames, and in mode 1 it will generate
full IDR frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


This is not clever, because i checked both libx264 and libx265 and both 
of them has same behavior like i proposed in patch.


Also explanation of this function is than wrong:
{ "forced-idr",   "If forcing keyframes, force them as IDR frames."}

There is nothing about disabled forcing keyframes at all.

So we have two options:
1. We should change it in NVENC
or
2. We should change it in libx264 and libx265

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

Re: [FFmpeg-devel] [PATCH] nvenc: support dynamic aspect ratio change

[Miroslav Slugeň]

Dne 12.2.2017 v 20:27 Timo Rothenpieler napsal(a):

On 2/12/2017 7:53 PM, Miroslav Slugeň wrote:

If there is input like DVB-T streams it can change aspect ratio
on-the-fly, so nvenc should respect this change and change aspect ratio
in encoder.

Haven't tested yet, but seems like a good idea. Are there other
parameters that would make sense to support reconfiguration for?
Can think of stuff like bitrate and the like, but there is no proper
interface to support changing them at runtime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
In realtime only aspect ratio was most common, but inputs can change 
resolution and frame_rate, both could be also dynamicaly changed in encoder.


For example for resolution there is n MaxWidth & MaxHeight which could 
differ from actual encoding width and height, but i think this is not 
supported in current ffmpeg.


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

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

[Miroslav Slugeň]

Thx for comment,

cuvid can't output 50fps deinterlaced output, both frames are same, and 
default behavior for yadif is to downcovert to half frame rate, so i 
think is very clever to do the same here.


Also if we return in decoder that input is framerate/2 when 
deinterlacing we should stay with that!


if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave)
avctx->framerate = av_mul_q(avctx->framerate, (AVRational){2, 1});

Miroslav Slugeň
+420 724 825 885

Dne 12.2.2017 v 20:25 Timo Rothenpieler napsal(a):

It does make sense, the deinterlacers convert 50 interlaced fields to 50
progressive frames, like for example yadif can do as well.

And disabling that functionality by default seems strange to me, as it's
clearly the superior mode of operation.

On 2/12/2017 8:02 PM, Miroslav Slugeň wrote:

There is no need to copy second field if deinterlacing, it doesn't make
sense to use two times same image.



___
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


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

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

[Timo Rothenpieler]

The current behavior is intended like it is.
On the default of -1, it does not care about I/IDR frame requests, in
mode 0 it will generate intra frames, and in mode 1 it will generate
full IDR frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc: support dynamic aspect ratio change

[Timo Rothenpieler]

On 2/12/2017 7:53 PM, Miroslav Slugeň wrote:
> If there is input like DVB-T streams it can change aspect ratio
> on-the-fly, so nvenc should respect this change and change aspect ratio
> in encoder.

Haven't tested yet, but seems like a good idea. Are there other
parameters that would make sense to support reconfiguration for?
Can think of stuff like bitrate and the like, but there is no proper
interface to support changing them at runtime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

[Timo Rothenpieler]

On 2/12/2017 8:18 PM, Miroslav Slugeň wrote:
> This patch is for discussion only, not ready to commit yet.
> 
> We were facing issue when using -hwaccel cuvid, then we were unable to
> use -filter_complex filters for video streams, this hack fixed it, but i
> am sure that it is not ready to commit, because it is dirty/ugly fix.

This collides with the merges and is probably obsolete once they happen.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

[Timo Rothenpieler]

It does make sense, the deinterlacers convert 50 interlaced fields to 50
progressive frames, like for example yadif can do as well.

And disabling that functionality by default seems strange to me, as it's
clearly the superior mode of operation.

On 2/12/2017 8:02 PM, Miroslav Slugeň wrote:
> There is no need to copy second field if deinterlacing, it doesn't make
> sense to use two times same image.
> 
> 
> 
> ___
> 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] movenc: add support for track names in ISML manifests

[Michael Niedermayer]

On Sun, Feb 12, 2017 at 03:10:34PM +0200, Jan Ekstrom wrote:
> On Sat, Feb 11, 2017 at 1:21 AM, Jan Ekström  wrote:
> > ...
> >
> 
> Poked Martin about this last night, and his comment was:
> `<@wbs> JEEB: doesn't look harmful to me, so no objection`

ok, ill apply it

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

[FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

[Miroslav Slugeň]

This patch is for discussion only, not ready to commit yet.

We were facing issue when using -hwaccel cuvid, then we were unable to 
use -filter_complex filters for video streams, this hack fixed it, but i 
am sure that it is not ready to commit, because it is dirty/ugly fix.


--
Miroslav Slugeň













>From 569a2c69e799d5fed364fbe55de2a49e2bbeab06 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 20:15:13 +0100
Subject: [PATCH 1/1] ffmpeg_filter: initialize cuvid for filter_complex

---
 ffmpeg_filter.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index f13f523..1eb75b6 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -1026,6 +1026,26 @@ int configure_filtergraph(FilterGraph *fg)
 fg->graph->nb_threads = filter_complex_nbthreads;
 }
 
+#if CONFIG_CUVID
+if (!simple) {
+for (i = 0; i < fg->nb_outputs; i++) {
+OutputFilter *ofilter = fg->outputs[i];
+int source_index;
+if (!ofilter->ost || ofilter->ost->source_index >= 0)
+continue;
+if (fg->nb_inputs != 1)
+continue;
+for (source_index = nb_input_streams-1; source_index >= 0; source_index--)
+if (fg->inputs[0]->ist == input_streams[source_index])
+break;
+ofilter->ost->source_index = source_index;
+
+if (cuvid_transcode_init(ofilter->ost))
+exit_program(1);
+}
+}
+#endif
+
 if ((ret = avfilter_graph_parse2(fg->graph, graph_desc, , )) < 0)
 return ret;
 
-- 
2.1.4

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

[FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

[Miroslav Slugeň]

There is no need to copy second field if deinterlacing, it doesn't make 
sense to use two times same image.


--
Miroslav Slugeň












>From 73d8f9fa17c26125a5b03243284f67126c70d7a6 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 20:00:51 +0100
Subject: [PATCH 1/1] cuvid: add drop_second_field as input option and enable
 it by default

---
 libavcodec/cuvid.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 9b35476..a2e125d 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -42,6 +42,7 @@ typedef struct CuvidContext
 
 char *cu_gpu;
 int nb_surfaces;
+int drop_second_field;
 
 AVBufferRef *hwdevice;
 AVBufferRef *hwframe;
@@ -298,8 +299,10 @@ static int CUDAAPI cuvid_handle_picture_display(void *opaque, CUVIDPARSERDISPINF
 } else {
 parsed_frame.is_deinterlacing = 1;
 av_fifo_generic_write(ctx->frame_queue, _frame, sizeof(CuvidParsedFrame), NULL);
-parsed_frame.second_field = 1;
-av_fifo_generic_write(ctx->frame_queue, _frame, sizeof(CuvidParsedFrame), NULL);
+if (!ctx->drop_second_field) {
+parsed_frame.second_field = 1;
+av_fifo_generic_write(ctx->frame_queue, _frame, sizeof(CuvidParsedFrame), NULL);
+}
 }
 
 return 1;
@@ -930,6 +933,7 @@ static const AVOption options[] = {
 { "adaptive", "Adaptive deinterlacing",  0, AV_OPT_TYPE_CONST, { .i64 = cudaVideoDeinterlaceMode_Adaptive }, 0, 0, VD, "deint" },
 { "gpu",  "GPU to be used for decoding", OFFSET(cu_gpu), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VD },
 { "surfaces", "Maximum surfaces to be used for decoding", OFFSET(nb_surfaces), AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, VD },
+{ "drop_second_field", "Drop second field when deinterlacing", OFFSET(drop_second_field), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VD },
 { NULL }
 };
 
-- 
2.1.4

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

[FFmpeg-devel] [PATCH] nvenc: support dynamic aspect ratio change

[Miroslav Slugeň]

If there is input like DVB-T streams it can change aspect ratio 
on-the-fly, so nvenc should respect this change and change aspect ratio 
in encoder.


--
Miroslav Slugeň











>From d836780d56fb7d7a63d91a2af87a0f84743d95d6 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 19:51:57 +0100
Subject: [PATCH 1/1] nvenc: support dynamic aspect ratio change

---
 libavcodec/nvenc.c | 57 +++---
 1 file changed, 50 insertions(+), 7 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 7005465..dea9a1c 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -913,6 +913,20 @@ static av_cold int nvenc_setup_codec_config(AVCodecContext *avctx)
 return 0;
 }
 
+static void compute_dar(AVCodecContext *avctx, int *dw, int *dh) {
+int sw, sh;
+
+sw = avctx->width;
+sh = avctx->height;
+
+if (avctx->sample_aspect_ratio.num > 0 && avctx->sample_aspect_ratio.den > 0) {
+sw*= avctx->sample_aspect_ratio.num;
+sh*= avctx->sample_aspect_ratio.den;
+}
+
+av_reduce(dw, dh, sw, sh, 1024 * 1024);
+}
+
 static av_cold int nvenc_setup_encoder(AVCodecContext *avctx)
 {
 NvencContext *ctx = avctx->priv_data;
@@ -949,13 +963,7 @@ static av_cold int nvenc_setup_encoder(AVCodecContext *avctx)
 
 ctx->encode_config.version = NV_ENC_CONFIG_VER;
 
-dw = avctx->width;
-dh = avctx->height;
-if (avctx->sample_aspect_ratio.num > 0 && avctx->sample_aspect_ratio.den > 0) {
-dw*= avctx->sample_aspect_ratio.num;
-dh*= avctx->sample_aspect_ratio.den;
-}
-av_reduce(, , dw, dh, 1024 * 1024);
+compute_dar(avctx, , );
 ctx->init_encode_params.darHeight = dh;
 ctx->init_encode_params.darWidth = dw;
 
@@ -1644,6 +1652,39 @@ static int output_ready(AVCodecContext *avctx, int flush)
 return (nb_ready > 0) && (nb_ready + nb_pending >= ctx->async_depth);
 }
 
+static int reconfig_encoder(AVCodecContext *avctx, const AVFrame *frame)
+{
+NV_ENC_RECONFIGURE_PARAMS params = { 0 };
+NvencContext *ctx = avctx->priv_data;
+NV_ENCODE_API_FUNCTION_LIST *p_nvenc = >nvenc_dload_funcs.nvenc_funcs;
+NVENCSTATUS ret;
+int dw, dh;
+
+compute_dar(avctx, , );
+if (dw != ctx->init_encode_params.darWidth ||
+dh != ctx->init_encode_params.darHeight) {
+av_log(avctx, AV_LOG_VERBOSE,
+   "Aspect ratio change (DAR): %d:%d -> %d:%d\n",
+   ctx->init_encode_params.darWidth,
+   ctx->init_encode_params.darHeight, dw, dh);
+
+params.version = NV_ENC_RECONFIGURE_PARAMS_VER;
+params.reInitEncodeParams = ctx->init_encode_params;
+params.reInitEncodeParams.darHeight = dh;
+params.reInitEncodeParams.darWidth = dw;
+
+ret = p_nvenc->nvEncReconfigureEncoder(ctx->nvencoder, );
+if (ret != NV_ENC_SUCCESS) {
+nvenc_print_error(avctx, ret, "Failed to reconfigure nvenc on aspect ratio change");
+} else {
+ctx->init_encode_params.darHeight = dh;
+ctx->init_encode_params.darWidth = dw;
+}
+}
+
+return 0;
+}
+
 int ff_nvenc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
   const AVFrame *frame, int *got_packet)
 {
@@ -1659,6 +1700,8 @@ int ff_nvenc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
 pic_params.version = NV_ENC_PIC_PARAMS_VER;
 
 if (frame) {
+reconfig_encoder(avctx, frame);
+
 inSurf = get_free_frame(ctx);
 if (!inSurf) {
 av_log(avctx, AV_LOG_ERROR, "No free surfaces\n");
-- 
2.1.4

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

[FFmpeg-devel] [PATCH] hlsenc: intialize only on ref_pkt and drop all packets

[Miroslav Slugeň]

This patch will fix cutting hls segments into exactly same length. 
Because it will intialize only on first ref_packet, which is video 
frame, not audio frame (old behavior)


It will also drop all packets without PTS, drop all packets before 
initialization and drop all packets before first intialization packet PTS.


Now it should be possible to create segments at exactly same length if 
we use new -force_key_frames hls:time_in_seconds parameter.


This is required to support adaptive HLS.

--
Miroslav Slugeň










>From a59a7dbe6fdcab64c1402adb8f11cc31400f4516 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 19:25:54 +0100
Subject: [PATCH 1/1] hlsenc: intialize only on ref_pkt and drop all packets
 before initialized

---
 libavformat/hlsenc.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ad5205a..226dd89 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1278,10 +1278,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
 oc = hls->avf;
 stream_index = pkt->stream_index;
 }
-if (hls->start_pts == AV_NOPTS_VALUE) {
-hls->start_pts = pkt->pts;
-hls->end_pts   = pkt->pts;
-}
 
 if (hls->has_video) {
 can_split = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
@@ -1292,6 +1288,11 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
 is_ref_pkt = can_split = 0;
 
 if (is_ref_pkt) {
+if (hls->start_pts == AV_NOPTS_VALUE) {
+hls->start_pts = pkt->pts;
+hls->end_pts   = pkt->pts;
+}
+
 if (hls->new_start) {
 hls->new_start = 0;
 hls->duration = (double)(pkt->pts - hls->end_pts)
@@ -1371,6 +1372,21 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
+if (pkt->pts == AV_NOPTS_VALUE) {
+av_log(s, AV_LOG_WARNING, "packet has no PTS, dropping packet from stream: %d\n", pkt->stream_index);
+return 0;
+}
+
+if (hls->start_pts == AV_NOPTS_VALUE) {
+av_log(s, AV_LOG_WARNING, "stream not initialized yet, dropping packet from stream: %d\n", pkt->stream_index);
+return 0;
+}
+
+if (pkt->pts + pkt->duration <= hls->start_pts) {
+av_log(s, AV_LOG_WARNING, "packet has PTS < START PTS (%"PRId64" < %"PRId64"), dropping packet from stream: %d\n", pkt->pts, hls->start_pts, pkt->stream_index);
+return 0;
+}
+
 ret = ff_write_chained(oc, stream_index, pkt, s, 0);
 
 return ret;
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add ffmpeg-security alias members

[Michael Niedermayer]

On Sat, Feb 11, 2017 at 10:19:59PM +0100, Paul B Mahol wrote:
> On 2/10/17, Michael Niedermayer  wrote:
> > Iam listing the reason for each, this is mostly my oppinion and i didnt ask
> > most
> > if they agree with the listed reason to be listed with their name, so its
> > largly
> > my oppinion. Which is why i will remove the reasons before pushing i just
> > added them
> > to be transparent on this but as said its mostly my oppinion, i just talked
> > with ubitux and noone else ...
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  MAINTAINERS | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 80721e183d..39339d620d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -60,6 +60,11 @@ mailing lists   Baptiste
> > Coudurier, Lou Logan
> >  Google+ Paul B Mahol, Michael Niedermayer,
> > Alexander Strasser
> >  Twitter Lou Logan, Reynaldo H. Verdejo
> > Pinochet
> >  Launchpad   Timothy Gu
> > +ffmpeg-security Andreas Cadhalpun (keeping
> > debian/ubuntu packages secure, activly works on security)
> > +Carl Eugen Hoyos (keeping track of
> > every bug, testing, finding wrongly listed CVEs)
> > +Clement Boesch (fix security issues
> > in code i maintain)
> > +Michael Niedermayer (fixing most
> > reported issues)
> > +Reimar Doeffinger (root admin able
> > to fix issues on the server, occasional patch reviews)
> 
> I thought he is no longer active?

i saw him work on the server less than a month ago, i noticed because
he misspelled a password or something and that rang some bells ...

also our SSL certs are maintained by him and i think he maintains
the subversion setup, later is irrelevant for FFmpeg off course.

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

[FFmpeg-devel] [PATCH] ffmpeg: add new forced_keyframes option -hls:time

[Miroslav Slugeň]

If we are using copyts parameter it is not possible to inserting key 
frames same way as hlsenc requests, this will lead to different hls 
segments length.


-copyts is required for long period audio/video sync

Small modification to hlsenc.c is also required and will arrive in next 
patch.


--
Miroslav Slugeň









>From 90d0636ea6cd34c9b51e4b568bb9e8aa461fa615 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 19:08:27 +0100
Subject: [PATCH 1/1] ffmpeg: add new forced_keyframes option -hls:time for
 inserting keyframes exactly athlsenc position compatible with copyts

---
 ffmpeg.c | 19 +++
 ffmpeg.h |  4 
 2 files changed, 23 insertions(+)

diff --git a/ffmpeg.c b/ffmpeg.c
index 06570c0..6ba5771 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1237,6 +1237,20 @@ static void do_video_out(OutputFile *of,
 }
 
 ost->forced_keyframes_expr_const_values[FKF_N] += 1;
+} else if (ost->forced_keyframes_hls_interval) {
+if (in_picture->pts != AV_NOPTS_VALUE) {
+int64_t pts_out = av_rescale_q(in_picture->pts, enc->time_base, ost->st->time_base);
+
+if (ost->forced_keyframes_hls_start_pts == AV_NOPTS_VALUE) {
+ost->forced_keyframes_hls_start_pts = pts_out;
+}
+
+if (av_compare_ts(pts_out - ost->forced_keyframes_hls_start_pts, ost->st->time_base, ost->forced_keyframes_hls_end_pts, AV_TIME_BASE_Q) >= 0) {
+ost->forced_keyframes_hls_number++;
+ost->forced_keyframes_hls_end_pts+= ost->forced_keyframes_hls_interval;
+forced_keyframe = 1;
+}
+}
 } else if (   ost->forced_keyframes
&& !strncmp(ost->forced_keyframes, "source", 6)
&& in_picture->key_frame==1) {
@@ -3224,6 +3238,11 @@ static int init_output_stream_encode(OutputStream *ost)
 ost->forced_keyframes_expr_const_values[FKF_N_FORCED] = 0;
 ost->forced_keyframes_expr_const_values[FKF_PREV_FORCED_N] = NAN;
 ost->forced_keyframes_expr_const_values[FKF_PREV_FORCED_T] = NAN;
+} else if (!strncmp(ost->forced_keyframes, "hls:", 4)) {
+ost->forced_keyframes_hls_interval = atof(ost->forced_keyframes+4) * AV_TIME_BASE;
+ost->forced_keyframes_hls_number = 1;
+ost->forced_keyframes_hls_start_pts = AV_NOPTS_VALUE;
+ost->forced_keyframes_hls_end_pts = ost->forced_keyframes_hls_interval;
 
 // Don't parse the 'forced_keyframes' in case of 'keep-source-keyframes',
 // parse it only for static kf timings
diff --git a/ffmpeg.h b/ffmpeg.h
index 458bb8a..85a8f18 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -478,6 +478,10 @@ typedef struct OutputStream {
 char *forced_keyframes;
 AVExpr *forced_keyframes_pexpr;
 double forced_keyframes_expr_const_values[FKF_NB];
+int forced_keyframes_hls_interval;
+int64_t forced_keyframes_hls_number;
+int64_t forced_keyframes_hls_start_pts;
+int64_t forced_keyframes_hls_end_pts;
 
 /* audio only */
 int *audio_channels_map; /* list of the channels id to pick from the source stream */
-- 
2.1.4

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

[FFmpeg-devel] [PATCH] cuvid: don't overwrite deinterlace at progressive input

[Miroslav Slugeň]

If there is progressive input it will disable deinterlacing in cuvid for 
all future frames even those interlaced.


I suggest to backport this patch to stable, because deinterlacing of 
combined files (progressive+interlaced) is currently broken in cuvid.


--
Miroslav Slugeň








>From af263ad83ae555baa9cdab2f8b7c5f73ef51ff4d Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 18:44:10 +0100
Subject: [PATCH 1/1] cuvid: don't overwrite deinterlace at progressive input

---
 libavcodec/cuvid.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 9b35476..a99d7de 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -51,6 +51,7 @@ typedef struct CuvidContext
 AVFifoBuffer *frame_queue;
 
 int deint_mode;
+int deint_mode_current;
 int64_t prev_pts;
 
 int internal_error;
@@ -150,7 +151,11 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
 (AVRational){ format->display_aspect_ratio.x, format->display_aspect_ratio.y },
 (AVRational){ avctx->width, avctx->height }));
 
-if (!format->progressive_sequence && ctx->deint_mode == cudaVideoDeinterlaceMode_Weave)
+ctx->deint_mode_current = format->progressive_sequence
+  ? cudaVideoDeinterlaceMode_Weave
+  : ctx->deint_mode;
+
+if (!format->progressive_sequence && ctx->deint_mode_current == cudaVideoDeinterlaceMode_Weave)
 avctx->flags |= AV_CODEC_FLAG_INTERLACED_DCT;
 else
 avctx->flags &= ~AV_CODEC_FLAG_INTERLACED_DCT;
@@ -241,14 +246,9 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
 cuinfo.ulNumOutputSurfaces = 1;
 cuinfo.ulCreationFlags = cudaVideoCreate_PreferCUVID;
 cuinfo.bitDepthMinus8 = format->bit_depth_luma_minus8;
+cuinfo.DeinterlaceMode = ctx->deint_mode_current;
 
-if (format->progressive_sequence) {
-ctx->deint_mode = cuinfo.DeinterlaceMode = cudaVideoDeinterlaceMode_Weave;
-} else {
-cuinfo.DeinterlaceMode = ctx->deint_mode;
-}
-
-if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave)
+if (ctx->deint_mode_current != cudaVideoDeinterlaceMode_Weave)
 avctx->framerate = av_mul_q(avctx->framerate, (AVRational){2, 1});
 
 ctx->internal_error = CHECK_CU(ctx->cvdl->cuvidCreateDecoder(>cudecoder, ));
@@ -293,7 +293,7 @@ static int CUDAAPI cuvid_handle_picture_display(void *opaque, CUVIDPARSERDISPINF
 parsed_frame.dispinfo = *dispinfo;
 ctx->internal_error = 0;
 
-if (ctx->deint_mode == cudaVideoDeinterlaceMode_Weave) {
+if (ctx->deint_mode_current == cudaVideoDeinterlaceMode_Weave) {
 av_fifo_generic_write(ctx->frame_queue, _frame, sizeof(CuvidParsedFrame), NULL);
 } else {
 parsed_frame.is_deinterlacing = 1;
@@ -564,7 +564,7 @@ static int cuvid_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
 
 av_log(avctx, AV_LOG_TRACE, "cuvid_decode_frame\n");
 
-if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave) {
+if (ctx->deint_mode_current != cudaVideoDeinterlaceMode_Weave) {
 av_log(avctx, AV_LOG_ERROR, "Deinterlacing is not supported via the old API\n");
 return AVERROR(EINVAL);
 }
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH]ffmpeg: Check the return values of two functions

[wm4]

On Sun, 12 Feb 2017 16:52:21 +0100
wm4  wrote:

> On Sun, 12 Feb 2017 16:48:57 +0100
> Carl Eugen Hoyos  wrote:
> 
> > Hi!
> > 
> > Attached patch written yesterday silences warnings when compiling 
> > ffmpeg.c, don't know how useful it is, only fate-tested.
> > 
> > Please comment, Carl Eugen  
> 
> Conflicts with my merge patches.

Actually it doesn't - I was thinking of something else. Sorry.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

[Miroslav Slugeň]

There was error in forcing key frames. If IDR was set to -1 (default) 
forced key frame will be never propagated to encoder.


I also suggest to backport this patch to current stable version, because 
-forced_keyframe behavior in NVENC is actualy broken.



--
Miroslav Slugeň







>From 60a1efef9d4146f9ad38a779ebf05407c64e385d Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Sun, 12 Feb 2017 18:10:15 +0100
Subject: [PATCH 1/1] nvenc: fix wrong forced keyframe behavior

---
 libavcodec/nvenc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 7005465..20af109 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1687,9 +1687,10 @@ int ff_nvenc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
 pic_params.pictureStruct = NV_ENC_PIC_STRUCT_FRAME;
 }
 
-if (ctx->forced_idr >= 0 && frame->pict_type == AV_PICTURE_TYPE_I) {
-pic_params.encodePicFlags =
-ctx->forced_idr ? NV_ENC_PIC_FLAG_FORCEIDR : NV_ENC_PIC_FLAG_FORCEINTRA;
+if (frame->pict_type == AV_PICTURE_TYPE_I) {
+pic_params.encodePicFlags = ctx->forced_idr > 0
+? NV_ENC_PIC_FLAG_FORCEIDR
+: NV_ENC_PIC_FLAG_FORCEINTRA;
 } else {
 pic_params.encodePicFlags = 0;
 }
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH]ffmpeg: Check the return values of two functions

[Paul B Mahol]

On 2/12/17, Nicolas George  wrote:
> Le quartidi 24 pluviose, an CCXXV, Carl Eugen Hoyos a ecrit :
>> New patch attached, Carl Eugen
>
> Thanks. The new patch looks fine to me, of course.
>
> I have said my piece on the other considerations, I do not think the
> eventual decision is mine to make.
>
> Regards,
>
> --
>   Nicolas George
>


I do not see big need for this patch. It can be applied later
when merge work is finished.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]ffmpeg: Check the return values of two functions

[Nicolas George]

Le quartidi 24 pluviôse, an CCXXV, Carl Eugen Hoyos a écrit :
> New patch attached, Carl Eugen

Thanks. The new patch looks fine to me, of course.

I have said my piece on the other considerations, I do not think the
eventual decision is mine to make.

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]ffmpeg: Check the return values of two functions

[Carl Eugen Hoyos]

2017-02-12 17:12 GMT+01:00 Marton Balint :
>
> On Sun, 12 Feb 2017, Carl Eugen Hoyos wrote:
>
>> Attached patch written yesterday silences warnings when compiling
>> ffmpeg.c, don't know how useful it is, only fate-tested.
>
> Writing a warning about the failed filter functions is good, but ffmpeg has
> a -xerror option as well, so I guess the proper fix would be to propagate
> the error through the functions and fail the encoding process as well if
> -xerror is set.

I don't necessarily disagree but will not work on this.

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

Re: [FFmpeg-devel] [PATCH]ffmpeg: Check the return values of two functions

[Carl Eugen Hoyos]

2017-02-12 17:00 GMT+01:00 Nicolas George :
> Le quartidi 24 pluviôse, an CCXXV, Carl Eugen Hoyos a écrit :
>> Hi!
>>
>> Attached patch written yesterday silences warnings when compiling
>> ffmpeg.c, don't know how useful it is, only fate-tested.
>>
>> Please comment, Carl Eugen
>
>> From 525aff909aec50d4e1a49f289ff9069300a4b51f Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sun, 12 Feb 2017 16:41:21 +0100
>> Subject: [PATCH] ffmpeg: Check the return value of two functions declared
>>  "warn_unused_result".
>>
>> ---
>>  ffmpeg.c |   20 ++--
>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index 06570c0..9952da6 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -215,14 +215,18 @@ static void sub2video_copy_rect(uint8_t *dst, int 
>> dst_linesize, int w, int h,
>>  static void sub2video_push_ref(InputStream *ist, int64_t pts)
>>  {
>>  AVFrame *frame = ist->sub2video.frame;
>> -int i;
>> +int i, ret;
>>
>>  av_assert1(frame->data[0]);
>>  ist->sub2video.last_pts = frame->pts = pts;
>> -for (i = 0; i < ist->nb_filters; i++)
>> -av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
>> +for (i = 0; i < ist->nb_filters; i++) {
>
>> +ret = av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
>>   AV_BUFFERSRC_FLAG_KEEP_REF |
>>   AV_BUFFERSRC_FLAG_PUSH);
>
> When the changes are that small, I think it is better to fix the
> indentation at the same time rather than leave it like that or fix it in
> a separate commit.

Done.

>> +if (ret < 0)
>> +av_log(ist->filters[i]->filter, AV_LOG_ERROR,
>
>> +   "Failed to add a frame to the buffer source.\n");
>
> Please mention it is a "subtitle video frame" and include the error
> message itself (av_err2str(ret)).

Thank you, done twice.

New patch attached, Carl Eugen
From 267e5e9733a073b6a6f578a5eb2199d52e05248a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 12 Feb 2017 17:17:25 +0100
Subject: [PATCH] ffmpeg: Check the return value of two functions declared
 "warn_unused_result".

---
 ffmpeg.c |   26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 06570c0..36b8132 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -215,14 +215,19 @@ static void sub2video_copy_rect(uint8_t *dst, int dst_linesize, int w, int h,
 static void sub2video_push_ref(InputStream *ist, int64_t pts)
 {
 AVFrame *frame = ist->sub2video.frame;
-int i;
+int i, ret;
 
 av_assert1(frame->data[0]);
 ist->sub2video.last_pts = frame->pts = pts;
-for (i = 0; i < ist->nb_filters; i++)
-av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
- AV_BUFFERSRC_FLAG_KEEP_REF |
- AV_BUFFERSRC_FLAG_PUSH);
+for (i = 0; i < ist->nb_filters; i++) {
+ret = av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
+   AV_BUFFERSRC_FLAG_KEEP_REF |
+   AV_BUFFERSRC_FLAG_PUSH);
+if (ret < 0)
+av_log(ist->filters[i]->filter, AV_LOG_ERROR,
+   "Failed to add a subtitle video frame to the buffer source: %s\n",
+   av_err2str(ret));
+}
 }
 
 static void sub2video_update(InputStream *ist, AVSubtitle *sub)
@@ -290,12 +295,17 @@ static void sub2video_heartbeat(InputStream *ist, int64_t pts)
 
 static void sub2video_flush(InputStream *ist)
 {
-int i;
+int i, ret;
 
 if (ist->sub2video.end_pts < INT64_MAX)
 sub2video_update(ist, NULL);
-for (i = 0; i < ist->nb_filters; i++)
-av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
+for (i = 0; i < ist->nb_filters; i++) {
+ret = av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
+if (ret < 0)
+av_log(ist->filters[i]->filter, AV_LOG_ERROR,
+   "Failed to add a subtitle video frame to the buffer source: %s\n",
+   av_err2str(ret));
+}
 }
 
 /* end of sub2video hack */
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]ffmpeg: Check the return values of two functions

[Nicolas George]

Le quartidi 24 pluviôse, an CCXXV, Marton Balint a écrit :
> Writing a warning about the failed filter functions is good, but ffmpeg has
> a -xerror option as well, so I guess the proper fix would be to propagate
> the error through the functions and fail the encoding process as well if
> -xerror is set.

I hesitated to mention it in my review. Ideally, taking it into account
would be nice. But...

First, our code is not completely consistent in its respect for -xerror,
especially when it comes to filtering, unless I am mistaken. A re-read
of the various code paths would probably be necessary to make all that
consistent.

Second, the patch fixes an issue (annoying warnings) even without that.

So my opinion is that the patch can go in even without the -xerror
implementation. A comment /* TODO -xerror */ would do no harm, though.
And I see the implementation of -xerror elsewhere is really small; but a
bit of factoring would make it more elegant and consistent.

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]ffmpeg: Check the return values of two functions

[Marton Balint]

On Sun, 12 Feb 2017, Carl Eugen Hoyos wrote:


Hi!

Attached patch written yesterday silences warnings when compiling
ffmpeg.c, don't know how useful it is, only fate-tested.


Writing a warning about the failed filter functions is good, but ffmpeg 
has a -xerror option as well, so I guess the proper fix would be to 
propagate the error through the functions and fail the encoding process as 
well if -xerror is set.


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

Re: [FFmpeg-devel] [PATCH]ffmpeg: Check the return values of two functions

[Nicolas George]

Le quartidi 24 pluviôse, an CCXXV, Carl Eugen Hoyos a écrit :
> Hi!
> 
> Attached patch written yesterday silences warnings when compiling 
> ffmpeg.c, don't know how useful it is, only fate-tested.
> 
> Please comment, Carl Eugen

> From 525aff909aec50d4e1a49f289ff9069300a4b51f Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 12 Feb 2017 16:41:21 +0100
> Subject: [PATCH] ffmpeg: Check the return value of two functions declared
>  "warn_unused_result".
> 
> ---
>  ffmpeg.c |   20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 06570c0..9952da6 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -215,14 +215,18 @@ static void sub2video_copy_rect(uint8_t *dst, int 
> dst_linesize, int w, int h,
>  static void sub2video_push_ref(InputStream *ist, int64_t pts)
>  {
>  AVFrame *frame = ist->sub2video.frame;
> -int i;
> +int i, ret;
>  
>  av_assert1(frame->data[0]);
>  ist->sub2video.last_pts = frame->pts = pts;
> -for (i = 0; i < ist->nb_filters; i++)
> -av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
> +for (i = 0; i < ist->nb_filters; i++) {

> +ret = av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
>   AV_BUFFERSRC_FLAG_KEEP_REF |
>   AV_BUFFERSRC_FLAG_PUSH);

When the changes are that small, I think it is better to fix the
indentation at the same time rather than leave it like that or fix it in
a separate commit.

> +if (ret < 0)
> +av_log(ist->filters[i]->filter, AV_LOG_ERROR,

> +   "Failed to add a frame to the buffer source.\n");

Please mention it is a "subtitle video frame" and include the error
message itself (av_err2str(ret)).

> +}
>  }
>  
>  static void sub2video_update(InputStream *ist, AVSubtitle *sub)
> @@ -290,12 +294,16 @@ static void sub2video_heartbeat(InputStream *ist, 
> int64_t pts)
>  
>  static void sub2video_flush(InputStream *ist)
>  {
> -int i;
> +int i, ret;
>  
>  if (ist->sub2video.end_pts < INT64_MAX)
>  sub2video_update(ist, NULL);
> -for (i = 0; i < ist->nb_filters; i++)
> -av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
> +for (i = 0; i < ist->nb_filters; i++) {
> +ret = av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
> +if (ret < 0)
> +av_log(ist->filters[i]->filter, AV_LOG_ERROR,
> +   "Failed to add a frame to the buffer source.\n");

Same as above of course.

> +}
>  }
>  
>  /* end of sub2video hack */

Apart from that, the patch looks good to me in principle.

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]ffmpeg: Check the return values of two functions

[wm4]

On Sun, 12 Feb 2017 16:48:57 +0100
Carl Eugen Hoyos  wrote:

> Hi!
> 
> Attached patch written yesterday silences warnings when compiling 
> ffmpeg.c, don't know how useful it is, only fate-tested.
> 
> Please comment, Carl Eugen

Conflicts with my merge patches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]ffmpeg: Check the return values of two functions

[Carl Eugen Hoyos]

Hi!

Attached patch written yesterday silences warnings when compiling 
ffmpeg.c, don't know how useful it is, only fate-tested.

Please comment, Carl Eugen
From 525aff909aec50d4e1a49f289ff9069300a4b51f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 12 Feb 2017 16:41:21 +0100
Subject: [PATCH] ffmpeg: Check the return value of two functions declared
 "warn_unused_result".

---
 ffmpeg.c |   20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 06570c0..9952da6 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -215,14 +215,18 @@ static void sub2video_copy_rect(uint8_t *dst, int 
dst_linesize, int w, int h,
 static void sub2video_push_ref(InputStream *ist, int64_t pts)
 {
 AVFrame *frame = ist->sub2video.frame;
-int i;
+int i, ret;
 
 av_assert1(frame->data[0]);
 ist->sub2video.last_pts = frame->pts = pts;
-for (i = 0; i < ist->nb_filters; i++)
-av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
+for (i = 0; i < ist->nb_filters; i++) {
+ret = av_buffersrc_add_frame_flags(ist->filters[i]->filter, frame,
  AV_BUFFERSRC_FLAG_KEEP_REF |
  AV_BUFFERSRC_FLAG_PUSH);
+if (ret < 0)
+av_log(ist->filters[i]->filter, AV_LOG_ERROR,
+   "Failed to add a frame to the buffer source.\n");
+}
 }
 
 static void sub2video_update(InputStream *ist, AVSubtitle *sub)
@@ -290,12 +294,16 @@ static void sub2video_heartbeat(InputStream *ist, int64_t 
pts)
 
 static void sub2video_flush(InputStream *ist)
 {
-int i;
+int i, ret;
 
 if (ist->sub2video.end_pts < INT64_MAX)
 sub2video_update(ist, NULL);
-for (i = 0; i < ist->nb_filters; i++)
-av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
+for (i = 0; i < ist->nb_filters; i++) {
+ret = av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
+if (ret < 0)
+av_log(ist->filters[i]->filter, AV_LOG_ERROR,
+   "Failed to add a frame to the buffer source.\n");
+}
 }
 
 /* end of sub2video hack */
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH v2] lavc/libzvbi: remove deprecated API usage

[Marton Balint]

On Sun, 12 Feb 2017, Carl Eugen Hoyos wrote:


2017-02-12 15:35 GMT+01:00 Josh de Kock :

I'm not sure, 0.2.28 doesn't compile on my system. It has
been tested with the latest version 0.2.38.

Does the updated patch look better?


I prefer it if nobody wants to test old versions.


-vbi_decoder_delete(ctx->vbi);
-ctx->vbi = NULL;



+if (ctx->vbi) {


Is this unrelated?


Hmm, you are right, it seems this hunk is unneeded even in the original 
patch, because vbi_encoder_delete unregisters all handlers. Josh, could 
you remove this hunk then from the original patch?


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

Re: [FFmpeg-devel] [PATCH v2] lavc/libzvbi: remove deprecated API usage

[Marton Balint]

On Sun, 12 Feb 2017, Josh de Kock wrote:


Hi Carl,

I'm not sure, 0.2.28 doesn't compile on my system. It has been tested with the
latest version 0.2.38.


I only checked the source code, and in 0.2.28 the function is already 
deprecated. So the original patch should be fine, I prefer that.


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

Re: [FFmpeg-devel] [PATCH v2] lavc/libzvbi: remove deprecated API usage

[Carl Eugen Hoyos]

2017-02-12 15:35 GMT+01:00 Josh de Kock :
> I'm not sure, 0.2.28 doesn't compile on my system. It has
> been tested with the latest version 0.2.38.
>
> Does the updated patch look better?

I prefer it if nobody wants to test old versions.

> -vbi_decoder_delete(ctx->vbi);
> -ctx->vbi = NULL;

> +if (ctx->vbi) {

Is this unrelated?

> +#if VBI_VERSION >= 234 // 0.2.34
> +vbi_event_handler_unregister(ctx->vbi, handler, ctx);
> +#endif
> +vbi_decoder_delete(ctx->vbi);
> +ctx->vbi = NULL;
> +}

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

[FFmpeg-devel] [PATCH v2] lavc/libzvbi: remove deprecated API usage

[Josh de Kock]

Hi Carl,

I'm not sure, 0.2.28 doesn't compile on my system. It has been tested with the
latest version 0.2.38.

Does the updated patch look better?

Josh

Signed-off-by: Josh de Kock 
---
 libavcodec/libzvbi-teletextdec.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index d1f0a9f..290e89f 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -41,6 +41,7 @@
 #define BITMAP_CHAR_WIDTH  12
 #define BITMAP_CHAR_HEIGHT 10
 #define MAX_SLICES 64
+#define VBI_VERSION (VBI_VERSION_MAJOR * 1 + VBI_VERSION_MINOR * 100 + 
VBI_VERSION_MICRO)
 
 typedef struct TeletextPage
 {
@@ -395,7 +396,11 @@ static int teletext_decode_frame(AVCodecContext *avctx, 
void *data, int *data_si
 if (!ctx->vbi) {
 if (!(ctx->vbi = vbi_decoder_new()))
 return AVERROR(ENOMEM);
+#if VBI_VERSION >= 234 // 0.2.34
+if (!vbi_event_handler_register(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, 
ctx)) {
+#else
 if (!vbi_event_handler_add(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, 
ctx)) {
+#endif
 vbi_decoder_delete(ctx->vbi);
 ctx->vbi = NULL;
 return AVERROR(ENOMEM);
@@ -524,8 +529,14 @@ static int teletext_close_decoder(AVCodecContext *avctx)
 subtitle_rect_free(>pages[--ctx->nb_pages].sub_rect);
 av_freep(>pages);
 
-vbi_decoder_delete(ctx->vbi);
-ctx->vbi = NULL;
+if (ctx->vbi) {
+#if VBI_VERSION >= 234 // 0.2.34
+vbi_event_handler_unregister(ctx->vbi, handler, ctx);
+#endif
+vbi_decoder_delete(ctx->vbi);
+ctx->vbi = NULL;
+}
+
 ctx->pts = AV_NOPTS_VALUE;
 if (!(avctx->flags2 & AV_CODEC_FLAG2_RO_FLUSH_NOOP))
 ctx->readorder = 0;
-- 
2.10.1 (Apple Git-78)

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix stream level metadata handling

[Carl Eugen Hoyos]

2017-02-12 10:24 GMT+01:00 Steven Liu :
> 2017-02-12 17:17 GMT+08:00 Bodecs Bela :

>> Should I change the status of the track ticket or is there
>> somebody who is the maintainer of trac?

We do not track patch status there (if this was your question),
closing the ticket should happen once the patch gets committed.

> I saw the ticket has been passed three years, you can close it with check
>
> Hi Carl,
>   Can the tickets close with check?

As soon as you push the change.

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

Re: [FFmpeg-devel] [PATCH] movenc: add support for track names in ISML manifests

[Jan Ekstrom]

On Sat, Feb 11, 2017 at 1:21 AM, Jan Ekström  wrote:
> ...
>

Poked Martin about this last night, and his comment was:
`<@wbs> JEEB: doesn't look harmful to me, so no objection`

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

Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Make a pointer cast explicit to silence a warning

[Carl Eugen Hoyos]

2017-02-12 13:43 GMT+01:00 Marton Balint :
>
> On Sat, 11 Feb 2017, Carl Eugen Hoyos wrote:
>
>> Attached patch silences a warning, don't know what is preferred here.
>
> LGTM.

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 2/3] avdevice/iec61883: free packet on buffer allocation error

[Marton Balint]

On Thu, 9 Feb 2017, Marton Balint wrote:


Fixes Coverity CID 1396416.

Signed-off-by: Marton Balint 
---
libavdevice/iec61883.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/libavdevice/iec61883.c b/libavdevice/iec61883.c
index c45ae9a..721dca3 100644
--- a/libavdevice/iec61883.c
+++ b/libavdevice/iec61883.c
@@ -120,6 +120,7 @@ static int iec61883_callback(unsigned char *data, int 
length,

packet->buf = av_malloc(length);
if (!packet->buf) {
+av_free(packet);
ret = -1;
goto exit;
}
--


Ping...

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/fifo: assert on disallowed message type and state combinations

[Marton Balint]

On Thu, 9 Feb 2017, Marton Balint wrote:


Fixes Coverity CID 1396277.

Signed-off-by: Marton Balint 
---
libavformat/fifo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 8f525e5..2cbe5c5 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -19,6 +19,7 @@
 * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
 */

+#include "libavutil/avassert.h"
#include "libavutil/opt.h"
#include "libavutil/time.h"
#include "libavutil/thread.h"
@@ -207,7 +208,7 @@ static int fifo_thread_write_trailer(FifoThreadContext *ctx)

static int fifo_thread_dispatch_message(FifoThreadContext *ctx, FifoMessage 
*msg)
{
-int ret;
+int ret = AVERROR(EINVAL);

if (!ctx->header_written) {
ret = fifo_thread_write_header(ctx);
@@ -217,6 +218,7 @@ static int fifo_thread_dispatch_message(FifoThreadContext 
*ctx, FifoMessage *msg

switch(msg->type) {
case FIFO_WRITE_HEADER:
+av_assert0(ret >= 0);
return ret;
case FIFO_WRITE_PACKET:
return fifo_thread_write_packet(ctx, >pkt);
@@ -224,6 +226,7 @@ static int fifo_thread_dispatch_message(FifoThreadContext 
*ctx, FifoMessage *msg
return fifo_thread_flush_output(ctx);
}

+av_assert0(0);
return AVERROR(EINVAL);
}



Ping...

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

Re: [FFmpeg-devel] [PATCH] lavc/libzvbi: remove deprecated API usage

[Marton Balint]

On Sat, 11 Feb 2017, Josh de Kock wrote:


Signed-off-by: Josh de Kock 
---
libavcodec/libzvbi-teletextdec.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index d1f0a9f..2ed4a82 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -395,7 +395,7 @@ static int teletext_decode_frame(AVCodecContext *avctx, 
void *data, int *data_si
if (!ctx->vbi) {
if (!(ctx->vbi = vbi_decoder_new()))
return AVERROR(ENOMEM);
-if (!vbi_event_handler_add(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, 
ctx)) {
+if (!vbi_event_handler_register(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, 
ctx)) {
vbi_decoder_delete(ctx->vbi);
ctx->vbi = NULL;
return AVERROR(ENOMEM);
@@ -524,8 +524,12 @@ static int teletext_close_decoder(AVCodecContext *avctx)
subtitle_rect_free(>pages[--ctx->nb_pages].sub_rect);
av_freep(>pages);

-vbi_decoder_delete(ctx->vbi);
-ctx->vbi = NULL;
+if (ctx->vbi) {
+vbi_event_handler_unregister(ctx->vbi, handler, ctx);
+vbi_decoder_delete(ctx->vbi);
+ctx->vbi = NULL;
+}
+
ctx->pts = AV_NOPTS_VALUE;
if (!(avctx->flags2 & AV_CODEC_FLAG2_RO_FLUSH_NOOP))
ctx->readorder = 0;
--


LGTM if tested.

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

Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Make a pointer cast explicit to silence a warning

[Marton Balint]

On Sat, 11 Feb 2017, Carl Eugen Hoyos wrote:


Hi!

Attached patch silences a warning, don't know what is preferred here.



LGTM.

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

Re: [FFmpeg-devel] [PATCH] avformat/mpl2dec: skip BOM when probing

[Paul B Mahol]

On 2/12/17, Clement Boesch  wrote:
> On Sun, Feb 12, 2017 at 12:51:11PM +0100, Paul B Mahol wrote:
>> On 2/11/17, Clement Boesch  wrote:
>> > On Sat, Feb 11, 2017 at 11:56:07AM +0100, Paul B Mahol wrote:
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> >>  libavformat/mpl2dec.c | 8 
>> >>  1 file changed, 8 insertions(+)
>> >>
>> >> diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
>> >> index 59589d5..0e30cb0 100644
>> >> --- a/libavformat/mpl2dec.c
>> >> +++ b/libavformat/mpl2dec.c
>> >> @@ -23,6 +23,8 @@
>> >>   * MPL2 subtitles format demuxer
>> >>   */
>> >>
>> >> +#include "libavutil/intreadwrite.h"
>> >> +
>> >>  #include "avformat.h"
>> >>  #include "internal.h"
>> >>  #include "subtitles.h"
>> >> @@ -39,6 +41,9 @@ static int mpl2_probe(AVProbeData *p)
>> >>  const unsigned char *ptr = p->buf;
>> >>  const unsigned char *ptr_end = ptr + p->buf_size;
>> >>
>> >> +if (AV_RB24(ptr) == 0xefbbbf)
>> >> +ptr += 3;
>> >> +
>> >>  for (i = 0; i < 2; i++) {
>> >>  if (sscanf(ptr, "[%"SCNd64"][%"SCNd64"]%c", , , )
>> >> !=
>> >> 3 &&
>> >>  sscanf(ptr, "[%"SCNd64"][]%c",  ,   )
>> >> !=
>> >> 2)
>> >> @@ -94,6 +99,9 @@ static int mpl2_read_header(AVFormatContext *s)
>> >>  if (!len)
>> >>  break;
>> >>
>> >> +if (AV_RB24(p) == 0xefbbbf)
>> >> +p += 3;
>> >> +
>> >
>> > The BOM is supposed to be at the beginning of the file, not at every
>> > line.
>> > The check should be outside the while loop.
>> >
>> > --
>> > Clement B.
>> >
>>
>> Removed check which was there, it appears to still work.
>
> Doesn't it skip the first event? Or maybe your libc skips it in sscanf?

Ah, first even is indeed skipped.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mpl2dec: skip BOM when probing

[Clément Bœsch]

On Sun, Feb 12, 2017 at 12:51:11PM +0100, Paul B Mahol wrote:
> On 2/11/17, Clement Boesch  wrote:
> > On Sat, Feb 11, 2017 at 11:56:07AM +0100, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavformat/mpl2dec.c | 8 
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
> >> index 59589d5..0e30cb0 100644
> >> --- a/libavformat/mpl2dec.c
> >> +++ b/libavformat/mpl2dec.c
> >> @@ -23,6 +23,8 @@
> >>   * MPL2 subtitles format demuxer
> >>   */
> >>
> >> +#include "libavutil/intreadwrite.h"
> >> +
> >>  #include "avformat.h"
> >>  #include "internal.h"
> >>  #include "subtitles.h"
> >> @@ -39,6 +41,9 @@ static int mpl2_probe(AVProbeData *p)
> >>  const unsigned char *ptr = p->buf;
> >>  const unsigned char *ptr_end = ptr + p->buf_size;
> >>
> >> +if (AV_RB24(ptr) == 0xefbbbf)
> >> +ptr += 3;
> >> +
> >>  for (i = 0; i < 2; i++) {
> >>  if (sscanf(ptr, "[%"SCNd64"][%"SCNd64"]%c", , , ) !=
> >> 3 &&
> >>  sscanf(ptr, "[%"SCNd64"][]%c",  ,   ) !=
> >> 2)
> >> @@ -94,6 +99,9 @@ static int mpl2_read_header(AVFormatContext *s)
> >>  if (!len)
> >>  break;
> >>
> >> +if (AV_RB24(p) == 0xefbbbf)
> >> +p += 3;
> >> +
> >
> > The BOM is supposed to be at the beginning of the file, not at every line.
> > The check should be outside the while loop.
> >
> > --
> > Clement B.
> >
> 
> Removed check which was there, it appears to still work.

Doesn't it skip the first event? Or maybe your libc skips it in sscanf?

-- 
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] avformat/mpl2dec: skip BOM when probing

[Paul B Mahol]

On 2/11/17, Clement Boesch  wrote:
> On Sat, Feb 11, 2017 at 11:56:07AM +0100, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavformat/mpl2dec.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
>> index 59589d5..0e30cb0 100644
>> --- a/libavformat/mpl2dec.c
>> +++ b/libavformat/mpl2dec.c
>> @@ -23,6 +23,8 @@
>>   * MPL2 subtitles format demuxer
>>   */
>>
>> +#include "libavutil/intreadwrite.h"
>> +
>>  #include "avformat.h"
>>  #include "internal.h"
>>  #include "subtitles.h"
>> @@ -39,6 +41,9 @@ static int mpl2_probe(AVProbeData *p)
>>  const unsigned char *ptr = p->buf;
>>  const unsigned char *ptr_end = ptr + p->buf_size;
>>
>> +if (AV_RB24(ptr) == 0xefbbbf)
>> +ptr += 3;
>> +
>>  for (i = 0; i < 2; i++) {
>>  if (sscanf(ptr, "[%"SCNd64"][%"SCNd64"]%c", , , ) !=
>> 3 &&
>>  sscanf(ptr, "[%"SCNd64"][]%c",  ,   ) !=
>> 2)
>> @@ -94,6 +99,9 @@ static int mpl2_read_header(AVFormatContext *s)
>>  if (!len)
>>  break;
>>
>> +if (AV_RB24(p) == 0xefbbbf)
>> +p += 3;
>> +
>
> The BOM is supposed to be at the beginning of the file, not at every line.
> The check should be outside the while loop.
>
> --
> Clement B.
>

Removed check which was there, it appears to still work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 0/5] A native Opus encoder

[Nicolas George]

Le tridi 23 pluviôse, an CCXXV, Rostislav Pehlivanov a écrit :
> This series of commits implements a native Opus encoder.

That is wonderful news.

I do not have the knowledge to review the patches themselves.

But I think they are missing an essential, but fortunately rather easy,
part: user documentation.

Most importantly, I think it absolutely needs something to tell the user
how it compares to the reference libopus encoder: does it yield better
quality per bitrate? slightly lower quality but incredibly faster?
sometimes better sometimes worst depending on options?

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] Ignore expired cookies

[Nicolas George]

Thanks for the patch. See remarks below.

Le tridi 23 pluviôse, an CCXXV, Micah Galizia a écrit :
> On some authenticated Neulion streams, they send a cookie from the past,
> like so:
> 
> Set-Cookie: nlqptid=""; Domain=.neulion.com; Expires=Thu, 01-Jan-1970
> 00:00:10 GMT; Path=/
> 
> As a result, the good cookie value is overwritten and authentication breaks
> immediately. I realise disqualifying a cookie over the date might open a
> can of worms when it comes to date formatting used by different systems,

In principle, I would be in favour of correctly heeding all elements of
the protocol, and only on top of that provide users the option of
ignoring certain elements. Parsing the expires field certainly enters
this frame.

> but I added Neulions wrong format and the http standard format.

In that case, maybe ignoring the whole cookie because the date is
invalid would be a better idea.

Did you test to see how real browsers handle it?

> Please let me know if this is acceptable. I've run it against fate and
> there were no problems.

That is good practice. Unfortunately, FATE tests almost nothing about
network protocols. If you did not, you need to check with a few web
servers that currently work.


Now reviewing details of the latest version of the patch:

> diff --git a/libavformat/http.c b/libavformat/http.c
> index 944a6cf..24368aa 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -682,12 +682,46 @@ static int parse_icy(HTTPContext *s, const char *tag, 
> const char *p)
>  
>  static int parse_cookie(HTTPContext *s, const char *p, AVDictionary 
> **cookies)
>  {
> -char *eql, *name;
> +char *eql, *name, *expiry;
>  
>  // duplicate the cookie name (dict will dupe the value)
>  if (!(eql = strchr(p, '='))) return AVERROR(EINVAL);
>  if (!(name = av_strndup(p, eql - p))) return AVERROR(ENOMEM);
>  
> +// ensure the expiry is sane

> +if ((expiry = strstr(eql, "Expires="))) {

I believe this is not correct. First, AFAIK, all the structure elements
in HTTP are case insensitive. Second, the string "Expires=" could
legitimately be part of the cookie value itself.

I suggest to parse the subfields of the set-cookie field correctly: it
is a sequence of "key=value" pairs (with the "=value" part optional, but
can be quoted) separated by semicolons and optional spaces. Furthermore,
it would be useful for other fields too, such as content-type.

I realize it is a little bit more work, but I think it is reasonable.

> +struct tm tm_buf = {0};
> +char *end;
> +
> +// get the start & the end of the expiry ('11 Feb 2017 09:41:35 GMT')
> +// this skips past the day of the week by finding the space 
> following it

> +expiry += 8 * sizeof(char);

sizeof(char) = 1 by definition, thus writing it is always unnecessary,
and rarely useful for readability.

> +while (*expiry != ' ') expiry++;

I suspect tabs and other whitespace-style characters could be present
here.

More importantly, this code will happily skip the end-of-string marker
if there are no spaces at all, and that is a big no.

Also, style nit for here and other places: the code base does not
usually use single-line loops or conditions.

> +expiry++;
> +end = expiry+1;

> +while (*end != ';') end++;

Same problem here.

> +
> +// ensure the time is parsable
> +end = strptime(expiry, "%d %b %Y %H:%M:%S %Z", _buf);

strptime() is an XSI extension, and as such not portable enough for the
FFmpeg code base. You can look if av_small_strptime() can do the trick.

According to
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date
(which is more readable than
https://tools.ietf.org/html/rfc6265#section-5.1.1)
the correct date syntax starts with the abbreviated day name and a
comma, i.e. "%a,". I suspect the code that skips until a space above is
there to skip that component, but it should be part of the date parsing
itself.

Also, %Z is a non-standard GNU and BSD extension, not supported by
av_small_strptime(). Fortunately, still according to MDN, only "GMT" is
supported here.

> +
> +// ensure neulion's different format is parsable
> +if (!end) end = strptime(expiry, "%d-%b-%Y %H:%M:%S %Z", _buf);
> +
> +// if the expire is specified but unparsable, this cookie is invalid
> +if (!end) {
> +av_log(s, AV_LOG_ERROR, "Unable to parse expiry for cookie 
> '%s'\n", p);
> +av_free(name);
> +return AVERROR(EINVAL);
> +}
> +
> +// no cookies from the past (neulion)

> +if (mktime(_buf) < time(NULL)) {

Since only GMT is supported, I think you need to use av_timegm().

> +av_log(s, AV_LOG_ERROR, "Ignoring cookie from the past '%s'\n", 
> p);
> +av_free(name);
> +return AVERROR(EINVAL);

I think it does not need to be an error, but that depends on the general
policy to deal with this kind of cases.

> +}
> 

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix stream level metadata handling

[Steven Liu]

2017-02-12 17:17 GMT+08:00 Bodecs Bela :

>
>
> 2017.02.12. 2:36 keltezéssel, Steven Liu írta:
>
>> 2017-02-12 5:31 GMT+08:00 Bodecs Bela :
>>
>> Dear All,
>>>
>>> hls-encoder currently does not provide stream level metadata to mpegts
>>> muxer. This patch also fixes track #3848 bug.
>>>
>>> Please review this bug fix. Thank you in advance.
>>>
>>>
>>> best regards,
>>>
>>> Bela Bodecs
>>>
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>>>
>> hls-encoder currenlty does not provide stream level metadata to mpegts
>> muxer. This patch fixes track #3848 bug.
>>
>> Signed-off-by: Bela Bodecs 
>> ---
>>   libavformat/hlsenc.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index bd1e684..a58ded9 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -446,6 +446,7 @@ static int hls_mux_init(AVFormatContext *s)
>>   avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar);
>>   st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
>>   st->time_base = s->streams[i]->time_base;
>> +av_dict_copy(>metadata, s->streams[i]->metadata, 0);
>>   }
>>   hls->start_pos = 0;
>>   hls->new_start = 1;
>>
>
> Should I change the status of the track ticket or is there somebody who is
> the maintainer of trac?


I saw the ticket has been passed three years, you can close it with check

Hi Carl,
  Can the tickets close with check?

>
>
> bb
>
> ___
> 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] avformat/hlsenc: fix stream level metadata handling

[Bodecs Bela]

2017.02.12. 2:36 keltezéssel, Steven Liu írta:

2017-02-12 5:31 GMT+08:00 Bodecs Bela :


Dear All,

hls-encoder currently does not provide stream level metadata to mpegts
muxer. This patch also fixes track #3848 bug.

Please review this bug fix. Thank you in advance.


best regards,

Bela Bodecs


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




hls-encoder currenlty does not provide stream level metadata to mpegts
muxer. This patch fixes track #3848 bug.

Signed-off-by: Bela Bodecs 
---
  libavformat/hlsenc.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..a58ded9 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -446,6 +446,7 @@ static int hls_mux_init(AVFormatContext *s)
  avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar);
  st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
  st->time_base = s->streams[i]->time_base;
+av_dict_copy(>metadata, s->streams[i]->metadata, 0);
  }
  hls->start_pos = 0;
  hls->new_start = 1;


Should I change the status of the track ticket or is there somebody who 
is the maintainer of trac?


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