The field dominance is an optional property in the MXF specifications. It shall
be assumed to be 1 (top field first) if not present.
Nicolas
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 7a4633f..7517285 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -152,6
septembre 2014 12:15
À : ffmpeg-devel@ffmpeg.org
Objet : Re: [FFmpeg-devel] MXF : default fied dominance is TFF
Gaullier Nicolas nicolas.gaullier at arkena.com writes:
case 0x3212:
descriptor-field_dominance = avio_r8(pb);
+descriptor-field_dominance_present = 1
>On Tue, 2016-03-29 at 22:29 +0200, NabFab wrote:
>> Hi,
>> Could you please tell me if ffmpeg is supporting AS-10 or AS-11 MXF
>> format according to AMWA specifications ?
>> Thank you
>
>Do you mean muxing or demuxing? I expect mxfdec should be perfectly capable of
>demuxing.
>
>It's been a
>Most broadcasters are now specifying mandatory loudness targets for source
>material, which is usually supplied as a target integrated loudness value and
>a target maximum true peak. Loudness normalization is easy for files with
>sufficient headroom for linear gain adjustments, difficult for
Attached patch fixes silence_start=0 meaning "no silence start"
Nicolas Gaullier
0003-avfilter-af_silencedetect-fix-silence_start-0-meanin.patch
Description: 0003-avfilter-af_silencedetect-fix-silence_start-0-meanin.patch
___
ffmpeg-devel mailing list
Hi!
Attached patch adds a "mono mode", I mean detection of silence in any of the
channels (instead of all of them simultaneously).
The channel number is detected and logged, and side metadata names are suffixed
with the channel number (NB: in non-mono mode, the logging and metadata remain
(email object fixed : sorry about that)
Attached patch fixes accuracy of silence_start.
The benefit is mostly noticeable when the silence starts at the very beginning
(ie. silence_start=0 exactly).
Nicolas Gaullier
___
ffmpeg-devel mailing list
(attachement + email object fixed : sorry about that x2)
Attached patch fixes accuracy of silence_start.
The benefit is mostly noticeable when the silence starts at the very beginning
(ie. silence_start=0 exactly).
Nicolas Gaullier
0002-avfilter-af_silencedetect-fix-silence_start-accuracy.patch
Attached patch fixes accuracy of silence_start.
The benefit is mostly noticeable when the silence starts at the very beginning
(ie. silence_start=0 exactly).
Nicolas Gaullier
0002-avfilter-af_silencedetect-fix-silence_start-accuracy.patch
Description:
Attached patch fixes missing log of "silence_end" when the silence continue
until the end of the stream.
Nicolas Gaullier
0004-avfilter-af_silencedetect-fix-missing-log-silence_en.patch
Description: 0004-avfilter-af_silencedetect-fix-missing-log-silence_en.patch
>this breaks fate
>
>If the changes are intended the reference must be updated by the patch causing
>the changes
Sorry, forgot... Now, I have some questions regarding fate tests:
1) I would like to update the fate test itself :
Currently, we have : silencedetect=d=-20dB
I am considering
The number of extra retries to get more than a single duration is currently
limited to 1 (see commit 77a0df4b5).
This patch raises this number of retries to 4 (amongst the overall 6 max
retries).
In my experience, the need for 2 extra retries is something commonplace.
3 extra retries is not far
Here, the "fix for ticket 6968" should be the header, so I think the format is
correct ? Everything behind ("Fix missing...") should be the body of the
commit message.
NB: thanks to you to have reported it previously, I was not aware of this
ticket when I started work on this issue!
Nicolas
>I believe there is an issue with your commit message:
>It should be something like:
>lavfi/silencedetect: Add mono mode
>
>In mono mode, silence is detected...
>(Note the two linebreaks, other differences are irrelevant.)
>
>Carl Eugen
Sorry, all my patches are missing an empty newline to
> +av_ts2timestr(duration_ts, _base));
^ this does not build,
and looks like a typo
Sorry, this is ugly, I had indeed replaced manually two occurrences
(s->time_base => _base) at the last minute just before sending
>> The number of extra retries to get more than a single duration is currently
>> limited to 1 (see commit 77a0df4b5).
>> This patch raises this number of retries to 4 (amongst the overall 6 max
>> retries).
>> In my experience, the need for 2 extra retries is something commonplace.
>> 3 extra
I have updated all the commit messages, and the typo in patch 6/8 is now clean
up - there was no other comment so far.
Please review
Nicolas Gaullier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
I have not received any comment yet on my patchset v3 ("add mono mode" new
feature + 4 fixes including a ticket), does it look good to you, could it be
committed ?
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225494.html
>Envoyé : mardi 23 juillet 2019 14:09
>When no IDR nor mmco_reset is found, prev_poc_lsb is undefined and shall not
>be assumed to be zero
>---
> libavcodec/h264_parse.c | 2 ++
> libavcodec/h264dec.c| 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
I have not received any feeback, do
>De : ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] De la part de
>Kieran Kunhya
>Envoyé : lundi 2 septembre 2019 18:12
>Objet : Re: [FFmpeg-devel] [PATCH 1/1] avcodec/h264: Fix poc_lsb in open gop
>context
>
>Patch seems good.
>
>Kieran
Can someone please apply the patch ?
Thanks
>> +FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) +=
>> +fate-dolby-e-wav
>> +fate-dolby-e-wav: CMD = dolbye2pcm16 -i
>> +$(TARGET_SAMPLES)/dolby_e/512.wav
>> +fate-dolby-e-wav: CMP = oneoff
>> +fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm
>
>This does a floaty comparison,
>Look at spdif in wav.
Indeed, I missed that, spdif and s337m are very similar technically, and it
means I have to rework my patch for the integration of s337m in wavdec, but I
still do not catch why another demuxer should be created : spdifdec.c is
actually quite similar to the existing
> > > MXF has a UL registered for Dolby-E:
> I also notice this UL is already in mxf.c, but added commented out by
> Baptiste back in 2006..
There are two ways for signalling dolby-E in MXF : channel status IF using an
AES3 descriptor, or the registered UL for Sound Essence Coding.
ARD/ZDF/HDF
>> +int avpriv_s337m_probe_stream(void *avc, AVIOContext *pb, AVStream **st,
>> int size);
>Sorry for not commenting earlier:
You're welcome, a few days is not that much, particularly in the middle of the
summer!
>This is to the best of my knowledge not acceptable (to have a public function
>Ah, so it's time and not phase? Renaming the #defines to make that clearer
>would be nice. Other than that, this isn't a huge issue
I assume the start of the packet to be synched with the start of "a" video
frame, I think there is no use case where pcm and video are not synced, at
least when
>> +if (pos < size - 9 && pos >= S337M_PROBE_GUARDBAND_MIN_BYTES)
>I think this 9 should be an 11 or 12..
Indeed, thank you, my mistake.
>This isn't quite what I meant by turning it into an integer test :) this will
>likely just be rounded to zero. I meant that things could likely be
>.. this won't compile if S377m is disabled. Just go with the old #if
>solution, sorry for causing confusion
My mistake but I think it is a good idea to get rid of some bulky #if... Do you
think a mixed usage of if and #if would be acceptable ? I think the following
would be the best :
if
>>On Thu, Oct 31, 2019 at 06:04:58PM +0100, Nicolas Gaullier wrote:
>> Allow the user to set or override the vbv size
>> ---
>> libavformat/mpegenc.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>This is not the "correct" way to handle this, because one mpeg container
>can
>> @@ -3562,12 +3562,14 @@ static int init_output_stream(OutputStream *ost,
>> char *error, int error_len)
>> int i;
>> for (i = 0; i < ist->st->nb_side_data; i++) {
>> AVPacketSideData *sd = >st->side_data[i];
>> +if (sd->type !=
>> #define LIBAVFORMAT_VERSION_MAJOR 58
>> -#define LIBAVFORMAT_VERSION_MINOR 35
>> +#define LIBAVFORMAT_VERSION_MINOR 36
>> #define LIBAVFORMAT_VERSION_MICRO 101
>>
>You forgot to reset micro.
>
>- Andreas
Sorry, I just checked the git log and now understand how micro versions works.
I will
> De : ffmpeg-devel De la part de Hendrik
> Leppkes
> Envoyé : lundi 24 février 2020 17:26
> À : FFmpeg development discussions and patches
> Objet : Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: Do not alter
> avctx->rc_buffer_size
>
> On Mon, Feb 24, 2020 at 5:13 PM Nicolas Gaullier
>
>Envoyé : vendredi 31 janvier 2020 09:59
>Objet : Re: [FFmpeg-devel] [PATCH v7 0/3] Fix mpeg1/2 stream copy
>
>I have not received any feedback yet on this latest version that does not
>affect the public API.
>The 3 patches are still available in patchwork:
>Envoyé : mercredi 15 janvier 2020 00:42
>À : ffmpeg-devel@ffmpeg.org
>Objet : [PATCH v7 0/3] Fix mpeg1/2 stream copy
>
>Modified with Anton feedback: no public amendment, the code from
>add_coded_side_data() is now duplicated from existing one in ffmpeg.c, but it
>is rather small.
>
>Nicolas
> De : ffmpeg-devel De la part de Michael
> Niedermayer
> Envoyé : vendredi 21 février 2020 12:54
> À : FFmpeg development discussions and patches
> Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded
> side data
>
> On Thu, Feb 20, 2020 at 11
> De : ffmpeg-devel De la part de Michael
> Niedermayer
> Envoyé : vendredi 7 février 2020 23:39
> À : FFmpeg development discussions and patches
> Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded
> side data
>
> On Wed, Jan 15, 2020 at 12:42:13AM +0100, Nicolas
> De : ffmpeg-devel De la part de James Almer
> Envoyé : vendredi 7 février 2020 23:48
> À : ffmpeg-devel@ffmpeg.org
> Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded
> side data
>
> On 2/7/2020 7:43 PM, James Almer wrote:
> > On 1/14/2020 8:42 PM, Nicolas Gaullier
>>
>> ---
>> libavformat/wavdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
>> 3571733817..d8a27c79cf 100644
>> --- a/libavformat/wavdec.c
>> +++ b/libavformat/wavdec.c
>> @@ -77,7 +77,7 @@ static void
>> Add s337m probing/reading similarly to spdif.
>> ---
>> libavformat/wavdec.c | 23 +++
>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
>> 575c667452..d030ed9f9d 100644
>> --- a/libavformat/wavdec.c
>>
>> >> Add s337m probing/reading similarly to spdif.
>> >> ---
>> >> libavformat/wavdec.c | 23 +++
>> >> 1 file changed, 19 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
>> >> 575c667452..d030ed9f9d 100644
>> >> ---
>> +if (container_word_bits && (container_word_bits+7)/8 !=
>> + (word_bits+7)/8) {
>
>Can it happen that word_bits is anything but 16 or 24 with a valid stream? If
>not then I'd check container_word_bits == word_bits && (word_bits == 16 ||
>word_bits == 24) or so
word_bits may be 20, and
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
>> 2796905e1f..ccb9576b84 100644
>> --- a/libavformat/wavdec.c
>> +++ b/libavformat/wavdec.c
>> @@ -78,7 +78,7 @@ static void set_spdif_s337m(AVFormatContext *s,
>> WAVDemuxContext *wav)
>> ret = AVERROR(ENOMEM);
>> if (CONFIG_SPDIF_DEMUXER && wav->spdif == 1)
>> return ff_spdif_read_packet(s, pkt);
>> -if (CONFIG_S337M_DEMUXER && wav->s337m == 1)
>> -return ff_s337m_read_packet(s, pkt);
>>
>> if (wav->smv_data_ofs > 0) {
>> int64_t audio_dts, video_dts; @@ -712,6
>> Test the new 'dolbyeprobe' AVOption.
>> Test dolby_e decoding for 24 bits with program config '5.1+2'
>> ---
>> tests/Makefile | 1 +
>> tests/fate-run.sh| 4
>> tests/fate/audio.mak | 5 +
>> 3 files changed, 10 insertions(+)
>>
>> diff --git a/tests/Makefile
>If the intention is to use this code from avformat_find_stream_info(),
>then why should it be public? The documentation is very unclear as to
>when/how an API user is supposed to call it.
>
>Anton Khirnov
Sorry about that, I should have explained this in the cover letter, or maybe
even in the
>Apart from what Anton wrote, it appears to me that not all patches in the
>series are necessary to fix the stream-copying.
>
>Carl Eugen
Precisely:
- 1/2/3 are working together : actual code from ffmpeg.c that is used for
stream encoding is now used for probing in libav, so it is "moved to
>Since you add an option in a later patch: Can you explain the
>reasoning for the whole patchset better?
>If DolbyE can be auto-detected (I assume so), this should be
>done and no further option should be needed.
>
>Carl Eugen
A common use case is stream copying : you want to be able to forward
> > >> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
> > >> 2796905e1f..ccb9576b84 100644
> >> --- a/libavformat/wavdec.c
> > >> +++ b/libavformat/wavdec.c
> > >> @@ -78,7 +78,7 @@ static void set_spdif_s337m(AVFormatContext *s,
> > >> WAVDemuxContext *wav)
> > >>
>> fre 2020-01-03 klockan 16:56 +0100 skrev Nicolas Gaullier:
>> > s337m_get_offset_and_codec does not make use of
>> > AVFormatContext: AVClass is enough for logging.
>> > Will facilitate further use from outside
>> > ---
>> > libavformat/s337m.c | 10 +-
>> > 1 file changed, 5
> De : Nicolas Gaullier
> Envoyé : jeudi 5 mars 2020 09:17
> À : ffmpeg-devel@ffmpeg.org
> Cc : Gaullier Nicolas
> Objet : [PATCH v8 0/4] Fix mpeg1/2 stream copy
>
> I have not received any feedback yet.
> I repost here with all 4 patches, maybe it is easier for the re
49 matches
Mail list logo
