Andreas Rheinhardt (12020-05-01):
> I'd rather opt to only warn in such a case unless strict_std_compliance
> is >= FF_COMPLIANCE_STRICT. And maybe we should also discard all future
> packets from this stream until we get one with side data matching the
> CodecPrivate one?
It is not a matter of st
John Stebbins:
> On Fri, 2020-05-01 at 20:28 +0200, Nicolas George wrote:
>> John Stebbins (12020-05-01):
>>> Well, current code in aac_adtstoasc silently ignores any
>>> changes. It
>>> only generates extradata from the initial packet. It's not checked
>>> in
>>> subsequent packets.
>>>
>>> So t
Am Fr., 1. Mai 2020 um 21:13 Uhr schrieb John Stebbins
:
>
> On Fri, 2020-05-01 at 20:28 +0200, Nicolas George wrote:
> > John Stebbins (12020-05-01):
> > > Well, current code in aac_adtstoasc silently ignores any
> > > changes. It
> > > only generates extradata from the initial packet. It's not
On Fri, 2020-05-01 at 20:28 +0200, Nicolas George wrote:
> John Stebbins (12020-05-01):
> > Well, current code in aac_adtstoasc silently ignores any
> > changes. It
> > only generates extradata from the initial packet. It's not checked
> > in
> > subsequent packets.
> >
> > So this would have to
John Stebbins (12020-05-01):
> Well, current code in aac_adtstoasc silently ignores any changes. It
> only generates extradata from the initial packet. It's not checked in
> subsequent packets.
>
> So this would have to be "fixed" in aac_adtstoasc as well if you want
> to add error logging.
Pro
On Fri, 2020-05-01 at 20:10 +0200, Nicolas George wrote:
> John Stebbins (12020-05-01):
> > If the parameters change on the fly, some part of the audio stream
> > is
> > going to be unplayable. Either the part after the change will be
> > unplayable if you ignore extradata changes, or everything
>
On Fri, 2020-05-01 at 20:03 +0200, Andreas Rheinhardt wrote:
> John Stebbins:
> > On Fri, 2020-05-01 at 14:27 -0300, James Almer wrote:
> > > On 5/1/2020 2:09 PM, John Stebbins wrote:
> > > > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > > > data is
> > > > written plus extra
On Fri, 2020-05-01 at 19:55 +0200, Andreas Rheinhardt wrote:
> John Stebbins:
> > On Fri, 2020-05-01 at 19:22 +0200, Andreas Rheinhardt wrote:
> > > John Stebbins:
> > > > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > > > data is
> > > > written plus extra space is reserved fo
John Stebbins (12020-05-01):
> If the parameters change on the fly, some part of the audio stream is
> going to be unplayable. Either the part after the change will be
> unplayable if you ignore extradata changes, or everything preceeding
> the last extradata change will be unplayable if you rewr
On Fri, 2020-05-01 at 19:53 +0200, Nicolas George wrote:
> John Stebbins (12020-05-01):
> > The test case is a TS file with aac audio. It TS files, it is
> > certainly possible for stream parameters to change on the fly. But,
> > if
> > the extradata changes, there's really no way to handle it in
John Stebbins:
> On Fri, 2020-05-01 at 14:27 -0300, James Almer wrote:
>> On 5/1/2020 2:09 PM, John Stebbins wrote:
>>> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
>>> data is
>>> written plus extra space is reserved for the max possible size
>>> extradata.
>>> But when extradat
On Fri, 2020-05-01 at 14:27 -0300, James Almer wrote:
> On 5/1/2020 2:09 PM, John Stebbins wrote:
> > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > data is
> > written plus extra space is reserved for the max possible size
> > extradata.
> > But when extradata is written durin
John Stebbins:
> On Fri, 2020-05-01 at 19:22 +0200, Andreas Rheinhardt wrote:
>> John Stebbins:
>>> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
>>> data is
>>> written plus extra space is reserved for the max possible size
>>> extradata.
>>> But when extradata is written during
John Stebbins (12020-05-01):
> The test case is a TS file with aac audio. It TS files, it is
> certainly possible for stream parameters to change on the fly. But, if
> the extradata changes, there's really no way to handle it in mkv since
> this data is global in mkv. So perhaps a better solution
On Fri, 2020-05-01 at 19:22 +0200, Andreas Rheinhardt wrote:
> John Stebbins:
> > When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the
> > data is
> > written plus extra space is reserved for the max possible size
> > extradata.
> > But when extradata is written during mkv_write_header,
James Almer:
> On 5/1/2020 2:09 PM, John Stebbins wrote:
>> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
>> written plus extra space is reserved for the max possible size extradata.
>> But when extradata is written during mkv_write_header, no extra space is
>> reserved. S
On 5/1/2020 2:09 PM, John Stebbins wrote:
> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
> written plus extra space is reserved for the max possible size extradata.
> But when extradata is written during mkv_write_header, no extra space is
> reserved. So the side data upd
John Stebbins:
> When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
> written plus extra space is reserved for the max possible size extradata.
> But when extradata is written during mkv_write_header, no extra space is
> reserved. So the side data update overwrites whatever fol
When extra data is updated using AV_PKT_DATA_NEW_EXTRADATA, the data is
written plus extra space is reserved for the max possible size extradata.
But when extradata is written during mkv_write_header, no extra space is
reserved. So the side data update overwrites whatever follows the
extradata in t
19 matches
Mail list logo
