Non-sense best effort timestamp

[gjdfgh]

Summary of the bug:

As you can see below, mp3 files which set skip_samples yield inconsistent best_effort_timestamp values for the first and second frames.

The first frame has a duration of 0.001066 seconds, but if you subtract the best effort timestamps of the second and first frame, you get 0.026122, a much higher value. Obviously the first frame's best_effort_timestamp is broken. It should have the same value as pkt_pts.

Also, I would argue that the first timestamp should be 0 (i.e. libavcodec shouldn't adjust the packet timestamp by the skip_samples amount), but that's a different issue.

How to reproduce:

% ffprobe test.mp3 -show_frames
[FRAME]
media_type=audio
key_frame=1
pkt_pts=353600
pkt_pts_time=0.025057
pkt_dts=353600
pkt_dts_time=0.025057
best_effort_timestamp=0
best_effort_timestamp_time=0.000000
pkt_duration=15040
pkt_duration_time=0.001066
pkt_pos=417
pkt_size=417
sample_fmt=s16p
nb_samples=47
channels=2
channel_layout=stereo
[/FRAME]
[FRAME]
media_type=audio
key_frame=1
pkt_pts=368640
pkt_pts_time=0.026122
pkt_dts=368640
pkt_dts_time=0.026122
best_effort_timestamp=368640
best_effort_timestamp_time=0.026122
pkt_duration=368640
pkt_duration_time=0.026122
pkt_pos=834
pkt_size=418
sample_fmt=s16p
nb_samples=1152
channels=2
channel_layout=stereo
[/FRAME]

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.