date:20200719

Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: mark the field flag if framerate > 30FPS

2020-07-19 Thread Marton Balint




On Sun, 19 Jul 2020, lance.lmw...@gmail.com wrote:


On Sat, Jul 18, 2020 at 08:38:16PM +0200, Marton Balint wrote:



On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:

> On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
> > 
> > 
> > On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
> > 
> > > On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:

> > > > > > > > On Fri, 17 Jul 2020, lance.lmw...@gmail.com wrote:
> > > > > > > From: Limin Wang 
> > > > > > In SMPTE ST 12-1: 2014 Sec 12.2, we need to mark the frame flag
> > > > if the frame rate > 30FPS to
> > > > > avoid interoperability issues. It will be used by the encoder to 
identify even or odd frames
> > > > > and correctly calculate the frame number of the SEI TC.
> > > > > > This feature looks like it belongs to
> > av_timecode_get_smpte_from_framenum
> > > > and not into decklink. Also checking previous timecode and guessing
> > > > something is a hack, especially since you have the exact source 
timecode.
> > > If I understand correctly, it's not hacky, for the framerate > 30, the 
source timecode will be
> > > frame pair(it's limited by 2bits limit of frame number ten digital. Below 
is one exmaple for 50fps
> > > if you tested with SDI with TC.
> > > 00:00:00:24
> > > 00:00:00:24
> > > 00:00:00:25
> > > 00:00:00:25
> > > 00:00:00:00
> > > 00:00:00:00
> > 
> > Have you actually tested this with a real SDI signal containing timecode?
> 
> Yes, have tested with SDI playback by decklink UltraStudio 4K mini with TC enabled.


I still don't understand how this works. Isn't timecode in the SDI signal
also contain the so called "field bit" flag to support 50fps timecode? And
if it does, then why can't you query it from decklink? Timecode in SDI
signal is also supposed to be an SMPTE 12M timecode, so all the bits you
need should be in it, you should not need to guess anything. Therefore it
makes little sense to me that the DeckLink API does not provide a proper
timecode as string, unless the original capture you made with your
UltraStudio and which you played back also has a faulty timecode.
What generated the signal which you captured with UltraStudio? Not ffmpeg I
hope...


It's auto-generated by configure of UltraStudio.


You mean using XLR timecode input selection? I would not trust that with 
50fps...



I have tested with bmdTimecodeFieldMark
flag, it's not set as expected for testing. I have no clue how to get the flag as the API 
provide the TC string is same for the frame pair. Maybe I miss something.


I'd try to generate SDI video with timecode by some other means. E.g. 
using MediaExpress / DaVinci Resolve and a native 1080p50 file.


Regards,
Marton






Regards,
Marton


> 
> > 
> > Thanks,

> > Marton
> > 
> > > > That's why I check the last TC to get the frame is even or odd.

> > > > Why not use av_timecode_get_smpte_from_framenum(), for it's
> > calculated by the string TC by one time,
> > > so it lacks the information whether it's odd or even frame.
> > > > > > > Regards,
> > > > Marton
> > > > > > > > ---
> > > > > libavdevice/decklink_common.h |  1 +
> > > > > libavdevice/decklink_dec.cpp  | 14 ++
> > > > > 2 files changed, 15 insertions(+)
> > > > > > diff --git a/libavdevice/decklink_common.h
> > > > b/libavdevice/decklink_common.h
> > > > > index bd68c7b..8ddc411 100644
> > > > > --- a/libavdevice/decklink_common.h
> > > > > +++ b/libavdevice/decklink_common.h
> > > > > @@ -151,6 +151,7 @@ struct decklink_ctx {
> > > > > int channels;
> > > > > int audio_depth;
> > > > > unsigned long tc_seen;// used with option wait_for_tc
> > > > > +uint32_t last_tc;
> > > > > };
> > > > > > typedef enum { DIRECTION_IN, DIRECTION_OUT}
> > > > decklink_direction_t;
> > > > > diff --git a/libavdevice/decklink_dec.cpp 
b/libavdevice/decklink_dec.cpp
> > > > > index dde68ff..a60c01b 100644
> > > > > --- a/libavdevice/decklink_dec.cpp
> > > > > +++ b/libavdevice/decklink_dec.cpp
> > > > > @@ -884,12 +884,26 @@ HRESULT 
decklink_input_callback::VideoInputFrameArrived(
> > > > > int metadata_len;
> > > > > uint8_t* packed_metadata;
> > > > > AVTimecode tcr;
> > > > > +AVRational rate = 
ctx->video_st->r_frame_rate;
> > > > > > if (av_timecode_init_from_string(&tcr,
> > > > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > > > > uint32_t tc_data = 
av_timecode_get_smpte_from_framenum(&tcr, 0);
> > > > > int size = sizeof(uint32_t) * 4;
> > > > > uint32_t *sd = (uint32_t 
*)av_packet_new_side_data(&pkt, AV_PKT_DATA_S12M_TIMECODE, size);
> > > > > > +/* set the field flag if frame rate
> > > > > 30FPS */
> > > > > +/* Refer to SMPTE ST 12-1:2014 Sec 12.2 
*/
> > > > > +if (av_cmp_q(rate, (AVRational) {30, 1})

Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode: add EQUAL_MULTI_ROWS support for slice structure

2020-07-19 Thread Linjie Fu

On Thu, Jun 18, 2020 at 1:36 PM Linjie Fu  wrote:
>
> On Tue, May 12, 2020 at 9:49 PM Linjie Fu  wrote:
> >
> > VA_ENC_SLICE_STRUCTURE_EQUAL_MULTI_ROWS is added to in the latest
> > libva (1.8.0) which matches the hardware behaviour:
> >
> > /** \brief Driver supports any number of rows per slice but they must be 
> > the same
> > *   for all slices except for the last one, which must be equal or 
> > smaller
> > *   to the previous slices. */
> >
> > And VA_ENC_SLICE_STRUCTURE_EQUAL_ROWS is kind of deprecated for iHD
> > since it's somehow introduced in [1] however misleading from what we
> > actually handle, and one row per slice would not get a good quality.
> >
> > Caps query support in driver is WIP, and this would fix the multi slice
> > encoding for VAEntrypointEncSliceLP.
> >
> > [1]
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/vaapi_encode.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index cb05ebd..234618a 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1888,6 +1888,9 @@ static av_cold int 
> > vaapi_encode_init_slice_structure(AVCodecContext *avctx)
> >  req_slices = avctx->slices;
> >  }
> >  if (slice_structure & VA_ENC_SLICE_STRUCTURE_ARBITRARY_ROWS ||
> > +#if VA_CHECK_VERSION(1, 8, 0)
> > +slice_structure & VA_ENC_SLICE_STRUCTURE_EQUAL_MULTI_ROWS ||
> > +#endif
> >  slice_structure & VA_ENC_SLICE_STRUCTURE_ARBITRARY_MACROBLOCKS) {
> >  ctx->nb_slices  = req_slices;
> >  ctx->slice_size = ctx->slice_block_rows / ctx->nb_slices;
> > --
> > 2.7.4
>
> Full support is provided in libva[1] and media-driver[2], and we've
> observed it works for multi slice encoding for AVC. (300+ cases)
>
> Prefer to apply this soon with commit message refined.
>
Applied, thx.
Prefer to apply the reset of this patch set soon to support tile encoding.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 3/3] libavcodec/jpeg2000dec: Support for PPM marker

2020-07-19 Thread Gautam Ramakrishnan

On Sun, Jul 19, 2020 at 12:05 PM Michael Niedermayer
 wrote:
>
> On Sat, Jul 18, 2020 at 06:46:22PM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan 
> >
> > This patch adds support for PPM marker for JPEG2000
> > decoder. It allows the samples p1_03.j2k and p1_05.j2k
> > to be decoded.
> > ---
> >  libavcodec/jpeg2000dec.c | 111 +++
> >  1 file changed, 101 insertions(+), 10 deletions(-)
> >
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index 5e9e97eb6a..e37f834afe 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/libavcodec/jpeg2000dec.c
> > @@ -71,6 +71,7 @@ typedef struct Jpeg2000POC {
> >  typedef struct Jpeg2000TilePart {
> >  uint8_t tile_index; // Tile index who refers the 
> > tile-part
> >  const uint8_t *tp_end;
> > +GetByteContext header_tpg;  // bit stream of header if PPM 
> > header is used
> >  GetByteContext tpg; // bit stream in tile-part
> >  } Jpeg2000TilePart;
> >
> > @@ -102,6 +103,13 @@ typedef struct Jpeg2000DecoderContext {
> >  uint8_t cbps[4];// bits per sample in particular components
> >  uint8_t sgnd[4];// if a component is signed
> >  uint8_t properties[4];
> > +
> > +uint8_t has_ppm;
> > +uint8_t *packed_headers; // contains packed headers. Used only 
> > along with PPM marker
> > +int packed_headers_size;
> > +GetByteContext  packed_headers_stream;
>
> > +uint8_t in_tile_headers;
>
> in_tile_headers could be moved into a seperate patch before the ppm addition
> it could also be used for other things than ppm
Yep, makes sense, I shall change this.
>
>
>
> > +
> >  int cdx[4], cdy[4];
> >  int precision;
> >  int ncomponents;
> > @@ -928,6 +936,31 @@ static int get_plt(Jpeg2000DecoderContext *s, int n)
> >  return 0;
> >  }
> >
> > +static int get_ppm(Jpeg2000DecoderContext *s, int n)
> > +{
> > +void *new;
> > +
> > +if (n < 3) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Invalid length for PPM data.\n");
> > +return AVERROR_INVALIDDATA;
> > +}
>
> > +s->has_ppm = 1;
>
> Is there a reason has_ppm is set before all error checks ?
> this leaves the possibility for has_ppm to be set but get_ppm failing
> it seems more consistant to me to only set it if get_ppm succeeded
I shall change this as well
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If the United States is serious about tackling the national security threats
> related to an insecure 5G network, it needs to rethink the extent to which it
> values corporate profits and government espionage over security.-Bruce 
> Schneier
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



-- 
-
Gautam |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: increase initial program date time precision

2020-07-19 Thread Steven Liu

Marton Balint  于2020年7月19日周日 上午6:04写道：
>
> Also query time only once, not for every variant stream, otherwise variant
> streams might get a slightly different initial program date time. And we can
> set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
> elsewhere.
>
> Signed-off-by: Marton Balint 
> ---
>  libavformat/hlsenc.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index df84e6487d..39ff1fa1e7 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2704,6 +2704,7 @@ static int hls_init(AVFormatContext *s)
>  char *p = NULL;
>  int http_base_proto = ff_is_http_proto(s->url);
>  int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> +double initial_program_date_time = av_gettime() / 100.0;
is it AV_TIME_BASE?
>
>  if (hls->use_localtime) {
>  pattern = get_default_pattern_localtime_fmt(s);
> @@ -2798,12 +2799,7 @@ static int hls_init(AVFormatContext *s)
>  vs->start_pts = AV_NOPTS_VALUE;
>  vs->end_pts   = AV_NOPTS_VALUE;
>  vs->current_segment_final_filename_fmt[0] = '\0';
> -
> -if (hls->flags & HLS_PROGRAM_DATE_TIME) {
> -time_t now0;
> -time(&now0);
> -vs->initial_prog_date_time = now0;
> -}
> +vs->initial_prog_date_time = initial_program_date_time;
>
>  for (j = 0; j < vs->nb_streams; j++) {
>  vs->has_video += vs->streams[j]->codecpar->codec_type == 
> AVMEDIA_TYPE_VIDEO;
> --
> 2.26.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] FFmpeg Committees results

2020-07-19 Thread Jean-Baptiste Kempf

Hello folks,

Here are the results of the Technical and Community committee elections.

Community committee:
--
https://vote.ffmpeg.org/cgi-bin/civs/results.pl?num_winners=5&id=E_8dc4c448379a9d54&algorithm=runoff

1. Jean-Baptiste Kempf (Condorcet winner: wins contests with all other choices)
2. Thilo Borgman loses to Jean-Baptiste Kempf by 17–12
3. James Almer loses to Jean-Baptiste Kempf by 21–7, loses to Thilo Borgman by
16–13
4. Carl Eugen Hoyos loses to Jean-Baptiste Kempf by 24–5, loses to James Almer
by 22–8
5. Dave Rice loses to Jean-Baptiste Kempf by 25–5, loses to Carl Eugen Hoyos
by 18–12

If one does withdraw, Steven Liu is the runner-up.

Technical committee:
---
https://vote.ffmpeg.org/cgi-bin/civs/results.pl?num_winners=5&id=E_2b68eda608ba4cea&algorithm=runoff

1. Michael Niedermayer (Condorcet winner: wins contests with all other choices)
2. James Almer loses to Michael Niedermayer by 18–12
3. Anton Khirnov loses to Michael Niedermayer by 17–13, loses to James Almer
by 16–12
4. Martin Storsjö loses to Michael Niedermayer by 19–8, loses to Anton Khirnov
by 13–11
5. Mark Thompson loses to Michael Niedermayer by 21–8, loses to Martin Storsjö
by 17–8

If ones does withdraw, Hendrik Leppkes is the runner-up.

Notes:
- It's interesting to see that every algorithm gives the same results for the
first 5 people, in both elections.
- 32 people voted for the CC, and 33 for the TC, making more than half of the
voters. A few emails are bouncing, so we're a bit shorter than 52.

Congratulations on the winners.

--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: increase initial program date time precision

2020-07-19 Thread Zhao Zhili



> On Jul 19, 2020, at 5:20 PM, Steven Liu  wrote:
> 
> Marton Balint  于2020年7月19日周日 上午6:04写道：
>> 
>> Also query time only once, not for every variant stream, otherwise variant
>> streams might get a slightly different initial program date time. And we can
>> set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
>> elsewhere.
>> 
>> Signed-off-by: Marton Balint 
>> ---
>> libavformat/hlsenc.c | 8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index df84e6487d..39ff1fa1e7 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -2704,6 +2704,7 @@ static int hls_init(AVFormatContext *s)
>> char *p = NULL;
>> int http_base_proto = ff_is_http_proto(s->url);
>> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
>> +double initial_program_date_time = av_gettime() / 100.0;
> is it AV_TIME_BASE?

According to the documentation of av_gettime, it's not related to AV_TIME_BASE.

/**
 * Get the current time in microseconds.
 */
int64_t av_gettime(void);

>> 
>> if (hls->use_localtime) {
>> pattern = get_default_pattern_localtime_fmt(s);
>> @@ -2798,12 +2799,7 @@ static int hls_init(AVFormatContext *s)
>> vs->start_pts = AV_NOPTS_VALUE;
>> vs->end_pts   = AV_NOPTS_VALUE;
>> vs->current_segment_final_filename_fmt[0] = '\0';
>> -
>> -if (hls->flags & HLS_PROGRAM_DATE_TIME) {
>> -time_t now0;
>> -time(&now0);
>> -vs->initial_prog_date_time = now0;
>> -}
>> +vs->initial_prog_date_time = initial_program_date_time;
>> 
>> for (j = 0; j < vs->nb_streams; j++) {
>> vs->has_video += vs->streams[j]->codecpar->codec_type == 
>> AVMEDIA_TYPE_VIDEO;
>> --
>> 2.26.2
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 2/3] libavcodec/jpeg2000dec: Support for Parameterless Markers

2020-07-19 Thread Carl Eugen Hoyos

Am Sa., 18. Juli 2020 um 15:16 Uhr schrieb :
>
> From: Gautam Ramakrishnan 
>
> The JPEG2000 standard reserves marker values 0xFF30
> to 0xFF3F to be used as parameterless markers. This
> patch adds support to decode codestream with such
> markers.

> This allows decoding of p0_02.j2k.

I wonder if sample aspect ratio should be set for samples
with subsampling in the only component.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change

2020-07-19 Thread Gautam Ramakrishnan

On Sun, Jul 19, 2020 at 12:09 AM Carl Eugen Hoyos  wrote:
>
> Am Di., 9. Juni 2020 um 20:25 Uhr schrieb Carl Eugen Hoyos 
> :
> >
> > Am Di., 9. Juni 2020 um 19:12 Uhr schrieb Gautam Ramakrishnan
> > :
> > >
> > > On Tue, Jun 9, 2020 at 10:24 PM Carl Eugen Hoyos  
> > > wrote:
> > > >
> > > > Am Di., 9. Juni 2020 um 14:07 Uhr schrieb :
> > > > >
> > > > > From: Gautam Ramakrishnan 
> > > > >
> > > > > This patch makes selection of pix_fmt similar to
> > > > > that in the native decoder. This makes samples such
> > > > > as p0_05.j2k and p1_03.j2k decodable by libopenjpeg.
> > > >
> > > > Since both files are not YUVA420P, I am not sure if this
> > > > patch is a good idea, in any case, the commit message
> > > > mentioning the two files as reasons for this patch is wrong.
> > > >
> > > I am not sure what file format this is then.
> >
> > I failed to find out so far, possibly Bayer, CMYK seems less
> > likely to me.
>
> I believe it is YCCK, two components (CC, if I am right) are
> subsampled.
In that case, does this patch make sense. I kinda just tried to replicate
the native decoder



-- 
-
Gautam |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC][GSoC][PATCH v1 6/6] ffplay: add av_packet_buffer_filter to filter packet buffer

2020-07-19 Thread Hongcheng Zhong

On Thu, 2020-07-16 at 18:11 +0200, Andreas Rheinhardt wrote:
> Hongcheng Zhong:
> > From: spartazhc 
> > 
> > hls_read_header will add all streams to s->internal->packet_buffer.
> > Use av_packet_buffer_filter to remove the AVPackets from other
> > streams that
> > are not needed, otherwise abr will allow them to be added to
> > ffplay's
> > packet_queue.
> > 
> > Signed-off-by: spartazhc 
> > ---
> >  fftools/ffplay.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> > index b17b75fa8f..832e97d910 100644
> > --- a/fftools/ffplay.c
> > +++ b/fftools/ffplay.c
> > @@ -3018,6 +3018,10 @@ static int read_thread(void *arg)
> >  
> >  /* clean packet list filled in hls_read_header if abr is
> > enabled */
> >  if (abr) {
> > +ret = av_packet_buffer_filter(ic, st_index);
> > +if (ret < 0) {
> > +av_log(NULL, AV_LOG_WARNING, "Failed to clean
> > av_packet\n");
> > +}
> >  is->abr_list = av_mallocz(sizeof(ABRList));
> >  ret = abr_init_list(is);
> >  if (ret < 0) {
> > 
> Do we need this new function at all? Can't we not just set
> AVStream.discard to AVDISCARD_ALL for the streams we don't want and
> modify av_read_frame() to make sure that it never outputs packets
> belonging to a stream that ought to be discarded?
> 
> - Andreas
> ___
I am not sure if it can be done elegantly. Currently in ffplay, all
stream packets will be added to packet list in ffplay's
read_thread avformat_find_stream_info (all these are before
AVDISCARD_ALL are set to streams). After this, ffplay will call
av_find_best_stream() to decide which stream to be reserved.

I tried to setup AVDISCARD flags after hls_read_header(), which will
prevent av_read_frame() to read other streams. But there are 2 problems

1. I can use variant's bandwidth only to determine which one is the
best stream, not av_find_best_stream(). It will cause problem if two
results are different, so I even need to disable av_find_best_stream().

2. Will cause warning "Could not find codec parameters for stream 2
(Video: h264, 1 reference frame ([27][0][0][0] / 0x001B), none):
unspecified size Consider increasing the value for the analyzeduration'
(0) and 'probesize' (500) options".

I have considered about it when I added this API. Adding an API is an
easy way to fix the problem, but not good enough.

Really need your advice here.

Regards,
Hongcheng

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: increase initial program date time precision

2020-07-19 Thread Steven Liu

Zhao Zhili  于2020年7月19日周日 下午6:26写道：
>
>
>
> > On Jul 19, 2020, at 5:20 PM, Steven Liu  wrote:
> >
> > Marton Balint  于2020年7月19日周日 上午6:04写道：
> >>
> >> Also query time only once, not for every variant stream, otherwise variant
> >> streams might get a slightly different initial program date time. And we 
> >> can
> >> set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
> >> elsewhere.
> >>
> >> Signed-off-by: Marton Balint 
> >> ---
> >> libavformat/hlsenc.c | 8 ++--
> >> 1 file changed, 2 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index df84e6487d..39ff1fa1e7 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -2704,6 +2704,7 @@ static int hls_init(AVFormatContext *s)
> >> char *p = NULL;
> >> int http_base_proto = ff_is_http_proto(s->url);
> >> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> >> +double initial_program_date_time = av_gettime() / 100.0;
> > is it AV_TIME_BASE?
>
> According to the documentation of av_gettime, it's not related to 
> AV_TIME_BASE.
>
> /**
>  * Get the current time in microseconds.
>  */
> int64_t av_gettime(void);
I saw
 /**
 * Internal time base represented as integer
 */

#define AV_TIME_BASE100
Do you mean cannot av_gettime() / AV_TIME_BASE?
>
> >>
> >> if (hls->use_localtime) {
> >> pattern = get_default_pattern_localtime_fmt(s);
> >> @@ -2798,12 +2799,7 @@ static int hls_init(AVFormatContext *s)
> >> vs->start_pts = AV_NOPTS_VALUE;
> >> vs->end_pts   = AV_NOPTS_VALUE;
> >> vs->current_segment_final_filename_fmt[0] = '\0';
> >> -
> >> -if (hls->flags & HLS_PROGRAM_DATE_TIME) {
> >> -time_t now0;
> >> -time(&now0);
> >> -vs->initial_prog_date_time = now0;
> >> -}
> >> +vs->initial_prog_date_time = initial_program_date_time;
> >>
> >> for (j = 0; j < vs->nb_streams; j++) {
> >> vs->has_video += vs->streams[j]->codecpar->codec_type == 
> >> AVMEDIA_TYPE_VIDEO;
> >> --
> >> 2.26.2
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

90 matches

Mail list logo