Opened 4 years ago

Closed 4 years ago

#8439 closed defect (invalid)

audio_frame_queue: Incorrect dequeued timestamps

Reported by: Lastique Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

The ff_af_queue_add/ff_af_queue_remove functions do not reproduce the timestamps that the user provides in AVFrame::pts. Effectively, the af_queue introduces a negative offset in the timestamps produced in AVPacket::pts.

For example, aacenc encoder has a delay of 1024 samples. If the user provides AVFrame::pts = 0 in the first frame sent to the encoder then the first packet received from the encoder will have AVPacket::pts = -1024.

Encoders should produce encoded timestamps equivalent to the timestamps that were passed by the users in decoded frames.

This problem was found when using ffmpeg through C API, I'm not sure it can be shown from CLI.

Attachments (1)

ffmpeg_ticket_8439.c (2.7 KB ) - added by Lastique 4 years ago.
A test case that demonstrates the problem

Download all attachments as: .zip

Change History (9)

comment:1 by Carl Eugen Hoyos, 4 years ago

Version: 4.2unspecified

Is the issue reproducible with current FFmpeg git head?
Please provide a simplified testcase that allows to reproduce.

comment:2 by Carl Eugen Hoyos, 4 years ago

Resolution: needs_more_info
Status: newclosed

by Lastique, 4 years ago

Attachment: ffmpeg_ticket_8439.c added

A test case that demonstrates the problem

comment:3 by Lastique, 4 years ago

Version: unspecified4.2

I've attached a test case that demonstrates the problem. The test output is:

Input pts: 0, output pts: -2048
Input pts: 1024, output pts: -1024
Input pts: 2048, output pts: 0
Input pts: 3072, output pts: 1024
Input pts: 4096, output pts: 2048

The expected output should list the same values for input and output timestamps.

comment:4 by Lastique, 4 years ago

Resolution: needs_more_info
Status: closedreopened

comment:5 by mkver, 4 years ago

Resolution: invalid
Status: reopenedclosed

This is just normal encoder delay.

comment:6 by Carl Eugen Hoyos, 4 years ago

Version: 4.2unspecified

comment:7 by Lastique, 4 years ago

Resolution: invalid
Status: closedreopened

No. The delay is indicated by avcodec_receive_packet returning AVERROR(EAGAIN) and no packet. Subsequent calls returning packets are expected to return timestamps that were passed on input.

As it is, the encoder does not introduce a delay but a negative offset in timestamps.

in reply to:  7 comment:8 by Marton Balint, 4 years ago

Resolution: invalid
Status: reopenedclosed

Replying to Lastique:

No. The delay is indicated by avcodec_receive_packet returning AVERROR(EAGAIN) and no packet. Subsequent calls returning packets are expected to return timestamps that were passed on input.

As it is, the encoder does not introduce a delay but a negative offset in timestamps.

You misunderstand, it is indeed encoder delay, or audio priming is another name for it:

https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html

Note: See TracTickets for help on using tickets.