On 3/29/2021 10:46 AM, James Almer wrote:
On 3/29/2021 10:20 AM, Nicolas George wrote:
James Almer (12021-03-29):
Can this be done? id3v2 attached pics for many formats are handled by
the
generic demux code in avformat_open_input() and not by the actual
demuxer.
And in demuxers like asf, it s
On 3/29/2021 10:20 AM, Nicolas George wrote:
James Almer (12021-03-29):
Can this be done? id3v2 attached pics for many formats are handled by the
generic demux code in avformat_open_input() and not by the actual demuxer.
And in demuxers like asf, it seems to be done in read_header().
Would seeki
James Almer (12021-03-29):
> Can this be done? id3v2 attached pics for many formats are handled by the
> generic demux code in avformat_open_input() and not by the actual demuxer.
> And in demuxers like asf, it seems to be done in read_header().
> Would seeking be able to fetch these pictures again
On 3/29/2021 9:57 AM, Nicolas George wrote:
James Almer (12021-03-29):
The idea for attached_pic afaik was that it's always available and easily
accessible to the user from the start, instead of just the one time the
demuxing process would return it in an av_read_frame() call.
The doxy for AV_DI
James Almer (12021-03-29):
> The idea for attached_pic afaik was that it's always available and easily
> accessible to the user from the start, instead of just the one time the
> demuxing process would return it in an av_read_frame() call.
> The doxy for AV_DISPOSITION_ATTACHED_PIC even mentions th
On 3/29/2021 6:46 AM, Andreas Rheinhardt wrote:
James Almer:
As a replacement for attached_pic, which is in turn deprecated and scheduled
for removal.
Signed-off-by: James Almer
---
TODO: APIChanges entry and version bump.
Decided to use the name apic for the field, since it's how id3v2 and o
On 3/29/2021 4:38 AM, Nicolas George wrote:
Lynne (12021-03-29):
Personally I don't really like 'apic'. Maybe 'pic_attachment' or
'attachment_pic'?
By the way, do we want it to be a field?
Attached pictures can be quite big. Do we want them to stay in AVStream
forever, even when the applicat
James Almer:
> As a replacement for attached_pic, which is in turn deprecated and scheduled
> for removal.
>
> Signed-off-by: James Almer
> ---
> TODO: APIChanges entry and version bump.
>
> Decided to use the name apic for the field, since it's how id3v2 and other
> formats call it.
>
> Also,
Lynne (12021-03-29):
> Personally I don't really like 'apic'. Maybe 'pic_attachment' or
> 'attachment_pic'?
By the way, do we want it to be a field?
Attached pictures can be quite big. Do we want them to stay in AVStream
forever, even when the application has already finished using them, or
does
Mar 28, 2021, 17:58 by jamr...@gmail.com:
> As a replacement for attached_pic, which is in turn deprecated and scheduled
> for removal.
>
> Signed-off-by: James Almer
> ---
> TODO: APIChanges entry and version bump.
>
> Decided to use the name apic for the field, since it's how id3v2 and other
>
On 3/28/2021 5:32 PM, Marton Balint wrote:
On Sun, 28 Mar 2021, James Almer wrote:
As a replacement for attached_pic, which is in turn deprecated and
scheduled
for removal.
Signed-off-by: James Almer
---
TODO: APIChanges entry and version bump.
Decided to use the name apic for the field,
On Sun, 28 Mar 2021, James Almer wrote:
As a replacement for attached_pic, which is in turn deprecated and scheduled
for removal.
Signed-off-by: James Almer
---
TODO: APIChanges entry and version bump.
Decided to use the name apic for the field, since it's how id3v2 and other
formats call i
As a replacement for attached_pic, which is in turn deprecated and scheduled
for removal.
Signed-off-by: James Almer
---
TODO: APIChanges entry and version bump.
Decided to use the name apic for the field, since it's how id3v2 and other
formats call it.
Also, in a fortunate coincidence, the fir
13 matches
Mail list logo
