On 10/03/2023 22:10, Marton Balint wrote:
On Mon, 6 Mar 2023, Nicolas Gaullier wrote:
[...]
Some weeks later now and no replies, maybe time to go on ?
I think the "case AV_CODEC_ID_DVVIDEO:" can be removed as discussed,
fate updated and that should be ok for everybody.
(Ideally, it could ha
On Mon, Mar 13, 2023 at 3:30 PM Marton Balint wrote:
>
>
>
> On Fri, 10 Mar 2023, Marton Balint wrote:
>
> >
> >
> > On Mon, 6 Mar 2023, Nicolas Gaullier wrote:
> >
> > The width is one thing; for whatever reason, there is a divergence
> > between DV100 on one hand and AVCI/XDCAMHD35 on
On Fri, 10 Mar 2023, Marton Balint wrote:
On Mon, 6 Mar 2023, Nicolas Gaullier wrote:
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
incl
On Mon, 6 Mar 2023, Nicolas Gaullier wrote:
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&avci does not, so curre
>>> 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&avci does not, so current code is fine >but maybe this
mån 2023-01-16 klockan 15:28 +0100 skrev Jerome Martinez:
> On 16/01/2023 14:50, Tomas Härdin wrote:
> > lör 2023-01-14 klockan 16:48 +0100 skrev Jerome Martinez:
> > > Before the patch:
> > > - stored values were rounded to upper 16 multiple also for
> > > formats
> > > not
> > > using macroblocks
>> 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&avci does not, so current code is fine but maybe this is an
On 16/01/2023 15:00, Nicolas Gaullier wrote:
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
On 16/01/2023 14:50, Tomas Härdin wrote:
lör 2023-01-14 klockan 16:48 +0100 skrev Jerome Martinez:
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
>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
lör 2023-01-14 klockan 16:48 +0100 skrev Jerome Martinez:
> 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
On Sun, Jan 15, 2023 at 03:24:37PM +0100, Jerome Martinez wrote:
> On 14/01/2023 21:04, Michael Niedermayer wrote:
> > On Sat, Jan 14, 2023 at 04:48:10PM +0100, Jerome Martinez wrote:
> > [...]
> > > +stored_height = (stored_height+15)/16*16;
> > If this is supposed to match the actual macr
On 14/01/2023 21:04, Michael Niedermayer wrote:
On Sat, Jan 14, 2023 at 04:48:10PM +0100, Jerome Martinez wrote:
[...]
+stored_height = (stored_height+15)/16*16;
If this is supposed to match the actual macroblocks, then this would
have to consider field pictures and interlacing as it di
On Sat, Jan 14, 2023 at 04:48:10PM +0100, Jerome Martinez wrote:
> 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 t
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 in
15 matches
Mail list logo
