>De : Nicolas Gaullier
>Envoyé : mardi 2 avril 2024 23:26
>Objet : [PATCH v3 0/1] avformat/demux: fix accurate probing of durations in
>mpegts/ps
>
>v3: rebased after ed9363052f4b8b8 applied tonight (add duration_probesize
>AVOption)
>
>Note: I have no o
=bt470bg:color_trc=
bt470bg:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo
Before:
color_range:unknown color_space:bt470bg ...
After:
color_range:tv color_space:bt709 ...
Signed-off-by: Nicolas Gaullier
---
libavfilter/vf_colorspace.c | 62 +
1 file
v4:
- remove dynamic color_range pass-through (which requires changing outlink
dynamically and is forbidden)
- nits style
- commit msg: simplified example (+ removed example for dynamic color_range
pass-through)
Nicolas Gaullier (1):
avfilter/vf_colorspace: use colorspace negotiation API
>De : ffmpeg-devel De la part de Niklas Haas
>Envoyé : jeudi 4 avril 2024 14:44
>
>> >> @@ -735,6 +736,9 @@ static int filter_frame(AVFilterLink *link, AVFrame
>> >> *in)
>> >> return res;
>> >> }
>> >>
>> >> +out->colorspace = s->out_csp;
>> >> +outlink->color_range =
>De : Nicolas Gaullier
>Envoyé : jeudi 4 avril 2024 14:02
>
>>The logic that is used in the other YUV negotiation aware filters is to just
>>set `out->colorspace = outlink->colorspace` and `out->color_range =
>>outlink->color_range`, sinc
>De : Niklas Haas
>Envoyé : jeudi 4 avril 2024 12:18
>> --- a/libavfilter/vf_colorspace.c
>> +++ b/libavfilter/vf_colorspace.c
>> @@ -433,8 +433,7 @@ static int create_filtergraph(AVFilterContext *ctx,
>> if (out->color_trc != s->out_trc) s->out_txchr = NULL;
>> if
th examples (see commit msg) behave the same way as 6.1 after this patch.
>
>Nicolas Gaullier (2):
> avfilter/vf_setparams: Add timeline support
> avfilter/vf_colorspace: Use colorspace negotiation API
Any chance to get this regression fixed for 7.0 one way or another?
For remembe
off-by: Nicolas Gaullier
---
libavformat/demux.c | 36 ++--
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 170 +-
tests/ref/fate/ts-opus-demux | 4 +-
3 files changed, 100 insertions(+), 110 deletions(-)
diff --git a/libavformat/demux.
last_vn=-1, so pmt is
forced/updated and results in demuxer context update), it is required to
preserve the info in codecpar at first.
Thanks to Michael for reporting the issue.
Nicolas Gaullier (1):
avformat/demux: Fix accurate probing of durations in mpegts/ps
libavformat/demux.c
$4 \" \" \$5}"
Before:
color_range:tv color_space:bt470bg
color_range:tv color_space:bt470bg
color_range:tv color_space:bt470bg
After:
color_range:unknown color_space:bt709
color_range:pc color_space:bt709
color_range:tv color_space:bt709
Signed-off-by: Nicolas Gaullier
This is helpful at least for test purposes.
Signed-off-by: Nicolas Gaullier
---
libavfilter/vf_setparams.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
index c96f4d314b..1b5eb70344 100644
--- a/libavfilter
.
Nicolas Gaullier (2):
avfilter/vf_setparams: Add timeline support
avfilter/vf_colorspace: Use colorspace negotiation API
libavfilter/vf_colorspace.c | 63 +
libavfilter/vf_setparams.c | 2 +-
2 files changed, 37 insertions(+), 28 deletions
This is helpful at least for test purposes.
---
libavfilter/vf_setparams.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
index c96f4d314b..1b5eb70344 100644
--- a/libavfilter/vf_setparams.c
+++
I thought the issue was fixed with b89ee26539 but it is not.
Note that I have introduced timeline support in vf_setparams in order to
make testing easier.
v2: fixed color_range pass-through
Nicolas Gaullier (2):
avfilter/vf_setparams: Add timeline support
avfilter/vf_colorspace: Use
/ {print \$4}"
Before:
color_range:tv
color_range:tv
color_range:tv
After:
color_range:unknown
color_range:pc
color_range:tv
Signed-off-by: Nicolas Gaullier
---
libavfilter/vf_colorspace.c | 64 +
1 file changed, 37 insertions(+), 27 deletions(-
iling to reach a video packet.
Even if a single audio stream duration is found but not the other
audio/video stream durations, there will be a retry, so at the end the
full user-overriden probesize will be used as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/APIchanges
iling to reach a video packet.
Even if a single audio stream duration is found but not the other
audio/video stream durations, there will be a retry, so at the end the
full user-overriden probesize will be used as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/APIchanges
ze-8 / 8 bytes
and the next-unique retry at filesize-16 / 8 bytes.
Thank you for your time,
Nicolas
Nicolas Gaullier (1):
avformat/demux: Add duration_probesize AVOption
doc/APIchanges | 3 +++
doc/formats.texi| 19 ++-
libavformat/avformat.h
>>Example:
>>ffmpeg -f lavfi -i testsrc -vf setparams=color_primaries=bt470bg:
>>color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale
>>,showinfo -f null -frames 1 -
>>
>>Before:
>> color_range:unknown color_space:unknown color_primaries:bt709 ...
>>After:
>> color_range:tv
>De : Nicolas Gaullier
>Envoyé : lundi 25 mars 2024 18:59
>
>Fixes a regression due to the fact that the colorspace filter does not use the
>new API introduced by 8c7934f73ab6c568acaa.
>The scale filter uses it since 45e09a30419cc2a7251e, and the setparams filter
>since
>De : Nicolas Gaullier
>Envoyé : lundi 11 mars 2024 15:01
>
>Mantissas are the last data in the channel subsegment and it appears it is
>sometimes missing a very few bits for the parsing to complete.
>This must not be confused with data corruption.
>In standard cond
---
libavcodec/h264_parser.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 94cfbc481e..6b721ec253 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -124,7 +124,16 @@ static int
ame sample modified to exhibit the issue (invalid NAL_AUDs + an available null
ending byte at 0x291F):
https://0x0.st/Xs9j.ts
I use this simple command line and then compare the xml, it seems quite clear:
ffprobe xxx.ts -show_packets -show_data -print_format xml
Nicolas Gaullier (1):
avcodec/h
ream duration is found but not the other
audio/video stream durations, there will be a retry, so at the end the
full user-overriden probesize will be used as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/demuxers.texi | 13 +
doc/formats.texi | 2 +-
libavformat/demux.c | 23
don't feel it is acceptable?
Any input welcome.
Nicolas Gaullier (1):
avformat/mpegts: Add duration_probesize AVOption
doc/demuxers.texi | 13 +
doc/formats.texi | 2 +-
libavformat/demux.c | 23 ++---
libavformat/mpegts.c | 104 +---
libavforma
when it is not specified:
the documentation states the output defaults to the same value as the
input, but it does not seem possible to implement currently.
Signed-off-by: Nicolas Gaullier
---
libavfilter/vf_colorspace.c | 62 +
1 file changed, 36 insertions
off-by: Nicolas Gaullier
---
libavformat/demux.c | 36 ++--
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 170 +-
tests/ref/fate/ts-opus-demux | 4 +-
3 files changed, 100 insertions(+), 110 deletions(-)
diff --git a/libavformat/demux.
quired to preserve the info in codecpar at first.
Thanks to Michael for reporting the issue.
Nicolas Gaullier (1):
avformat/demux: Fix accurate probing of durations in mpegts/ps
libavformat/demux.c | 36 ++--
tests/ref/fate/concat-demuxer-simple2-lavf-ts
>De : Nicolas Gaullier
>Envoyé : mardi 12 mars 2024 13:09
>Objet : [PATCH] doc/fate: advise on --assert-level=2
>
>diff --git a/doc/fate.texi b/doc/fate.texi index 2fa8c34c2d..17644ce65a 100644
>--- a/doc/fate.texi
>+++ b/doc/fate.texi
>@@ -79,6 +79,14 @@ Do
off-by: Nicolas Gaullier
---
libavformat/demux.c | 30 +---
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 170 +-
tests/ref/fate/ts-opus-demux | 4 +-
3 files changed, 93 insertions(+), 111 deletions(-)
diff --git a/libavformat/demux.
fter patch:
streams.stream.0.duration="2.08"
streams.stream.1.duration="1.20"
Nicolas Gaullier (1):
avformat/demux: Fix accurate probing of durations in mpegts/ps
libavformat/demux.c | 30 +---
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 170 ++
>De : Nicolas Gaullier
>Envoyé : lundi 4 mars 2024 18:32
>Objet : [PATCH v3 0/5] avcodec/parser: fix fetch_timestamp in a scenario with
>unaligned packets
>
>Updated from v2:
>patch 1: fix audio case where pts=AV_NOPTS_VALUE but dts exists (thanks to
>Michael)
>
Signed-off-by: Nicolas Gaullier
---
doc/fate.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index 2fa8c34c2d..17644ce65a 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -79,6 +79,14 @@ Do not put a '~' character in the samples path to indicate
Regression since 0b98f28c46a7e3e914c51debc461
Signed-off-by: Nicolas Gaullier
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 0fead78c58..9863e4f2d9 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
Ping ?
v3 "bis" rebased and wrapped lines in commit msg
Nicolas Gaullier (1):
avformat/demux: Add durationprobesize AVOption
doc/APIchanges | 3 +++
doc/formats.texi| 16 +++-
libavformat/avformat.h | 12
libavform
iling to reach a video packet.
Even if a single audio stream duration is found but not the other
audio/video stream durations, there will be a retry, so at the end the
full user-overriden probesize will be used as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/APIchanges
a tolerance: if 800 out of the 1024 mantissas have
been parsed, a simple warning is raised and the data is preserved.
Signed-off-by: Nicolas Gaullier
---
libavcodec/dolby_e.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
index 9c3f6006c2
t/oOvv.zip
Nicolas Gaullier (1):
avcodec/dolby_e: Add error recovery when parse_mantissas run out of
bits
libavcodec/dolby_e.c | 8
1 file changed, 8 insertions(+)
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
Signed-off-by: Nicolas Gaullier
---
doc/fate.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index 2fa8c34c2d..2fa7c70251 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -79,6 +79,13 @@ Do not put a '~' character in the samples path to indicate
In my personnal experience, when running fate, --assert-level=2 has a very
limited performance impact,
so I think it can be recommended without further attention.
Nicolas Gaullier (1):
doc/fate: advise on --assert-level=2
doc/fate.texi | 7 +++
1 file changed, 7 insertions(+)
--
2.30.2
iling to reach a video packet. Even if a single
audio stream duration is found but not the other audio/video stream durations,
there will be a retry, so at the end the full user-overriden probesize will be
used
as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/APIchanges
ks in apidoc between skip_estimate_duration_from_pts
and duration_probesize
Added version.h lost previously
Nicolas Gaullier (1):
avformat/demux: Add durationprobesize AVOption
doc/APIchanges | 3 +++
doc/formats.texi| 16 +++-
libavformat/avformat.h | 12 +
besize.
But we also have skip_estimate_duration_from_pts /
s->skip_estimate_duration_from_pts,
so there is nothing obvious.
Nicolas Gaullier (1):
avformat/demux: Add durationprobesize AVOption
doc/APIchanges | 3 +++
doc/formats.texi| 13 +
libavformat/a
iling to reach a video packet. Even if a single
audio stream duration is found but not the other audio/video stream durations,
there will be a retry, so at the end the full user-overriden probesize will be
used
as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/APIchanges
>De : Stefano Sabatini
>Envoyé : mercredi 7 février 2024 00:52
>
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h index
>> + * stream durations. Used by avformat_find_stream_info() for MPEG-TS/PS.
>
>let's clarify this: is there any reason why this should not be used with
>De : ffmpeg-devel De la part de Michael
>Niedermayer
>Envoyé : dimanche 3 mars 2024 23:07
>À : FFmpeg development discussions and patches
>Objet : Re: [FFmpeg-devel] [PATCH v2 1/5] avcodec/parser: merge packets from
>the same frame
>
>On Fri, Mar 01, 2024 at 02:39:19PM
Signed-off-by: Nicolas Gaullier
---
libavformat/demux.c | 25 ++-
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
tests/ref/fate/ts-demux | 8 +-
3 files changed, 106 insertions(+), 91 deletions(-)
diff --git
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 90461075fd..496ebbc231 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -144,14 +144,14 @@ int
Updated from v2:
patch 1: fix audio case where pts=AV_NOPTS_VALUE but dts exists (thanks to
Michael)
now pass fate with --assert-level=2
patch 5: add inline comments and moved a line to make it more easy to read
(thanks to James)
Thank you for this review
Nicolas Gaullier (5):
avcodec
Fix fetch_timestamp when the frame start is in a previous packet.
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 496ebbc231..3c22fdcc2f 100644
--- a/libavcodec
tch is required for the following patch which will fetch 'past'
timestamps from past cur_frames.
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index efc28b8918..90461075fd 100644
--- a/libavco
Signed-off-by: Nicolas Gaullier
---
libavcodec/h264_parser.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 94cfbc481e..6b721ec253 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
Signed-off-by: Nicolas Gaullier
---
libavformat/demux.c | 23 ++-
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
tests/ref/fate/ts-demux | 8 +-
3 files changed, 104 insertions(+), 91 deletions(-)
diff --git
Signed-off-by: Nicolas Gaullier
---
libavcodec/h264_parser.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 94cfbc481e..6b721ec253 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
tch is required for the following patch which will fetch 'past'
timestamps from past cur_frames.
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index efc28b8918..249f81d4bb 100644
--- a/libavco
Fix fetch_timestamp when the frame start is in a previous packet.
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index ede9e7e8b4..e4e9fbf48f 100644
--- a/libavcodec
t), there
would be a regression in the PTS/DTS values.
So any testing with corrupt streams beyond h264 is wellcome to see if other
parsers require a fix (say a hack).
For remembering, sample files and cover letter of the first version:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 249f81d4bb..ede9e7e8b4 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -143,14 +143,14 @@ int
>De : ffmpeg-devel De la part de Michael
>Niedermayer
>Envoyé : mercredi 21 février 2024 05:32
>On Tue, Feb 20, 2024 at 05:33:01PM +0100, Nicolas Gaullier wrote:
>> Fix fetch_timestamp when the frame start is in a previous packet.
>>
>> Signed-off-by: Nicolas G
---
libavcodec/h264_parser.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 94cfbc481e..6b721ec253 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -124,7 +124,16 @@ static int
>> Personally, I have not found a better solution as an mpegts fix, but if
>> anyone has a better code, of course my version can be dropped.
>> (I have not looked for a possible fix in the upper ffmpeg demux/parser
>> layers, but it would be certainly even more ugly, if possible at all).
>
>I
Signed-off-by: Nicolas Gaullier
---
libavformat/demux.c | 23 ++-
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
tests/ref/fate/ts-demux | 8 +-
3 files changed, 104 insertions(+), 91 deletions(-)
diff --git
ond patch is to make parse_packet duplicate the side_data when spliting
packets. It is not clear to me if this is required nor correct in a general
manner?
Nicolas Gaullier (2):
avcodec/parser: fix fetch_timestamp in a scenario with unaligned
packets
lavf/demux: duplicate side_d
Fix fetch_timestamp when the frame start is in a previous packet.
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index efc28b8918..853b5323b0 100644
--- a/libavcodec
>> If you think it would be better to have a related trac ticket, just
>> tell me, I can do this of course.
>> Nicolas
>>
>
>I think it's ok. I wish it were less ugly but I guess it can't be.
>
>Kieran
Yes, of course! I am really really sorry.
Personally, I have not found a better solution as an
ll
>=> Application provided invalid, non monotonically increasing dts...
>
>
>Nicolas Gaullier (1):
> avformat/mpegts: fix first NAL start code splited in two different
>packets
>
> libavformat/mpegts.c | 41 +++--
> 1 file changed, 39 insert
or build a patchset with the two patches.
Nicolas Gaullier (1):
avformat/demux: Add durationprobesize AVOption
libavformat/avformat.h | 8
libavformat/demux.c | 13 -
libavformat/options_table.h | 1 +
3 files changed, 17 insertions(+), 5 dele
he full user-overriden probesize will be used.
Signed-off-by: Nicolas Gaullier
---
libavformat/avformat.h | 8
libavformat/demux.c | 13 -
libavformat/options_table.h | 1 +
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavformat/avformat.h b/libavf
, having all durations is somewhat
recommanded for using concatdec, and even required when using
concatdec with streamcopy.
Signed-off-by: Nicolas Gaullier
---
libavformat/demux.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index
When PES are not aligned and a tiny nal-encoded frame is contained in a single
TS packet,
the first NAL startcode may be split by the PES boundary, making the packet
unworkable.
This patch shift the PES boundaries to avoid this.
Signed-off-by: Nicolas Gaullier
---
libavformat/mpegts.c | 41
ffmpeg -i input.ts -f null /dev/null
=> Application provided invalid, non monotonically increasing dts...
Nicolas Gaullier (1):
avformat/mpegts: fix first NAL start code splited in two different
packets
libavformat/mpegts.c | 41 +++--
1 file changed,
>On 2024-01-28 04:24 pm, Anton Khirnov wrote:
>> Quoting Gyan Doshi (2024-01-26 05:23:50)
>>>
>>> On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
Gyan Doshi:
>> On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
>> Gyan Doshi:
>>> Set up framework for non-PCM decoding in-place
Use same heuristic as in fftools.
Signed-off-by: Nicolas Gaullier
---
libavformat/concatdec.c | 17 +++-
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 40 ++-
2 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/libavformat/concatdec.c b
re packets are read but they are usually trimmed through
segment_time_metadata etc.
Nicolas Gaullier (1):
avformat/concatdec: fix seek with dts
libavformat/concatdec.c | 17 +++-
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 40 ++-
2 files changed, 54
>+#define IS_NONPCMSYNC_16(state) ((state & 0x00) ==
>NONPCMSYNC_16MARKER)
Is this single 32 bits marker enough to avoid a fake detection ?
Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
>fre 2023-03-10 klockan 10:17 +0100 skrev Nicolas Gaullier:
>> + if (i == c->nb_groups - 1
>> + && count * size1 > get_bits_left(>gb)
>> + && get_bits_left(>gb) >= 0
>> +
>At this point I'm inclined to keep the code separate/private to decklink.
>It's limited to AC-3 and only produces packets which are
>s16 little endian. At some point I think it would be worthwhile to have some
>common code that supports 20/24 bit, both endians, and other codecs like
,
a simple warning is raised and the data is preserved.
Signed-off-by: Nicolas Gaullier
---
libavcodec/dolby_e.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
index 921c33f3ba..a24edfcc93 100644
--- a/libavcodec/dolby_e.c
+++ b/libavcodec
very similar to all other
audio codecs,
so it does not seem that critical for simple maintenance.
Nicolas Gaullier (1):
avcodec/dolby_e: Add error recovery when parse_mantissas run out of
bits
libavcodec/dolby_e.c | 9 +
1 file changed, 9 inser
>+static int create_s337_payload(AVPacket *pkt, enum AVCodecID codec_id,
>+uint8_t **outbuf, int *outsize) {
This is very interesting in many other contexts.
My current patch serie is about demuxing s337 (targeting dolby_e) from wav
files, and it would be great
to be able to re-mux back to s337
---
doc/decoders.texi | 20
doc/demuxers.texi | 33 +
2 files changed, 53 insertions(+)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 5ba85cf9b1..750fb4bd7a 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -223,6 +223,26 @@
Following of
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230213180936.815-5-nicolas.gaullier@cji.paris/
from the serie
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8380
Should the version and changelog be updated too ?
Nicolas
Nicolas Gaullier (7):
avformat/s337m: Split
>>> The width is one thing; for whatever reason, there is a divergence between
>>> DV100 on one hand and AVCI/XDCAMHD35 on the other. In my understanding, in
>>> current practices, DV obey s337 (stored width includes scaling) but
>>> >xdcam does not, so current code is fine >but maybe this is
>This is why it is better to demand that these things be explicitly signalled.
>At the same time a lot of users expect ffmpeg to Just Work, but that is not
>always possible. Perhaps we should should put this in the manual and tell
>>spdif/s377m/dolby-e users to RTFM?
>
>> And another point here
>> ff_s337m_probe is very similar to s337m_probe: what mainly differs is
>> the input parameters.
>> The one little thing I added is the S337M_PROBE_GUARDBAND_MIN_BYTES.
>> Currently it is set to 0, so has no effect (and of course I can remove
>> it if someone object).
>> There is two things to
>I haven't worked enough with S377m to really know, but I do know it's a mess.
>Is there a way to differentiate "regular" packed 20-bit audio from S377m in
>wav?
>
>/Tomas
There is a relevant overview of S337m in this dolby paper:
Signed-off-by: Nicolas Gaullier
---
libavcodec/ac3dec.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
index 138b462abb..adf82b4a98 100644
--- a/libavcodec/ac3dec.h
+++ b/libavcodec/ac3dec.h
@@ -90,7 +90,6 @@ typedef struct AC3DecodeContext
>> +#if CONFIG_S337M_DEMUXER
>> + {"non_pcm_mode", "Chooses what to do with s337m",
>> OFFSET(non_pcm_mode), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, DEC,
>> "non_pcm_mode"},
>> + {"copy" , "Pass s337m through unchanged", 0,
>> AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 1, DEC, "non_pcm_mode"},
>>
> The logic here is a bit hairy and I don't have time atm to digest it, but is
> it entirely contained in S337m or would one need to read other specs too?
>
>/Tomas
ff_s337m_probe is very similar to s337m_probe: what mainly differs is the input
parameters.
The one little thing I added is the
>> @@ -56,6 +56,12 @@ static int s337m_get_offset_and_codec(void *avc,
>> avpriv_report_missing_feature(avc, "Data type %#x in
>> SMPTE 337M", data_type & 0x1F);
>> return AVERROR_PATCHWELCOME;
>> }
>> + if (container_word_bits &&
>> + !(container_word_bits ==
Test s337m probing in wav container.
Test dolby_e demuxing for 20 bits with program config '5.1+2'.
---
tests/Makefile | 1 +
tests/fate/audio.mak | 3 +++
tests/ref/fate/s337m-wav | 10 ++
3 files changed, 14 insertions(+)
create mode 100644 tests/ref/fate/s337m-wav
---
libavformat/wavdec.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index fd9ca89880..29192e48f0 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -793,14 +793,14 @@ smv_out:
size =
Add s337m probing and demuxing similarly to spdif.
Add 'non_pcm_mode' option to disable s337m demuxing (pass-through).
---
libavformat/wavdec.c | 47 +++-
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/libavformat/wavdec.c
Similar to ff_spdif_probe() with just an additional checking of
the bit resolution of the container as it may be 16 or 24 for s337m.
---
libavformat/s337m.c | 32
libavformat/s337m.h | 16
2 files changed, 48 insertions(+)
diff --git
Prepare the support of s337m in muxers other than raw (ex: wav).
For example, this forbids reading 16 bits DolbyE stream from a 24 bit wav file.
---
libavformat/s337m.c | 21 +++--
libavformat/s337m.h | 3 ++-
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git
Prepare use of s337m_get_packet from outside.
---
libavformat/s337m.c | 24
libavformat/s337m.h | 37 +
2 files changed, 57 insertions(+), 4 deletions(-)
create mode 100644 libavformat/s337m.h
diff --git a/libavformat/s337m.c
>> The width is one thing; for whatever reason, there is a divergence between
>> DV100 on one hand and AVCI/XDCAMHD35 on the other. In my understanding, in
>> current practices, DV obey s337 (stored width includes scaling) but
>> >xdcam does not, so current code is fine but maybe this is an
>>
>Before the patch:
>- stored values were rounded to upper 16 multiple also for formats not using
>macroblocks (should be st->codecpar->width and
>st->codecpar->height when not MPEG formats; note that I found no other
>muxer doing the rounding for AVC, only for MPEG-2 Video, but I find no reason
>Envoyé : mardi 13 septembre 2022 23:31
>Mantissas are the last data in the channel subsegment and it appears it is
>sometimes missing a very few bits for the parsing to complete.
>This should not be confused with data corruption.
>For 5.1+2@25fps, the occurence of this issue is pretty steady
>Envoyé : mardi 13 septembre 2022 23:31
>Mantissas are the last data in the channel subsegment and it appears it is
>sometimes missing a very few bits for the parsing to complete.
>This should not be confused with data corruption.
Here is a very short sample set with an audacity screen grab
1 - 100 of 277 matches
Mail list logo
