Chiebot-Mirror
/
FFmpeg
mirror of https://github.com/FFmpeg/FFmpeg.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
45162 Commits
37 Branches
400 Tags
465 MiB
Tag: Branch: Tree: f7c46d251c
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'f7c46d251c'
${ noResults }
FFmpeg/tests/ref/fate/ffprobe_ini

614 lines
9.7 KiB
Raw Normal View History Unescape

tests: add fate-ffprobe test
12 years ago
# ffprobe output
[packets_and_frames.packet.0]
codec_type=audio
stream_index=0
pts=0
pts_time=0.000000
dts=0
dts_time=0.000000
duration=1024
duration_time=0.023220
convergence_duration=N/A
convergence_duration_time=N/A
size=2048
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=487
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.0]
media_type=audio
key_frame=1
pkt_pts=0
pkt_pts_time=0.000000
pkt_dts=0
pkt_dts_time=0.000000
pkt_duration=1024
pkt_duration_time=0.023220
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=487
tests: add fate-ffprobe test
12 years ago
sample_fmt=s16
nb_samples=1024
channels=1
channel_layout=unknown
[packets_and_frames.packet.1]
codec_type=video
stream_index=1
pts=0
pts_time=0.000000
dts=0
dts_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=230400
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=2562
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.1]
media_type=video
key_frame=1
pkt_pts=0
pkt_pts_time=0.000000
pkt_dts=0
pkt_dts_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=2562
tests: add fate-ffprobe test
12 years ago
width=320
height=240
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[packets_and_frames.packet.2]
codec_type=video
stream_index=2
pts=0
pts_time=0.000000
dts=0
dts_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=30000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=232983
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.2]
media_type=video
key_frame=1
pkt_pts=0
pkt_pts_time=0.000000
pkt_dts=0
pkt_dts_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=232983
tests: add fate-ffprobe test
12 years ago
width=100
height=100
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[packets_and_frames.packet.3]
codec_type=audio
stream_index=0
pts=1024
pts_time=0.023220
dts=1024
dts_time=0.023220
duration=1024
duration_time=0.023220
convergence_duration=N/A
convergence_duration_time=N/A
size=2048
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=262988
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.3]
media_type=audio
key_frame=1
pkt_pts=1024
pkt_pts_time=0.023220
pkt_dts=1024
pkt_dts_time=0.023220
pkt_duration=1024
pkt_duration_time=0.023220
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=262988
tests: add fate-ffprobe test
12 years ago
sample_fmt=s16
nb_samples=1024
channels=1
channel_layout=unknown
[packets_and_frames.packet.4]
codec_type=video
stream_index=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pts=2048
tests: add fate-ffprobe test
12 years ago
pts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
dts=2048
tests: add fate-ffprobe test
12 years ago
dts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=230400
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=265066
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.4]
media_type=video
key_frame=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pts=2048
tests: add fate-ffprobe test
12 years ago
pkt_pts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_dts=2048
tests: add fate-ffprobe test
12 years ago
pkt_dts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=265066
tests: add fate-ffprobe test
12 years ago
width=320
height=240
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[packets_and_frames.packet.5]
codec_type=video
stream_index=2
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pts=2048
tests: add fate-ffprobe test
12 years ago
pts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
dts=2048
tests: add fate-ffprobe test
12 years ago
dts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=30000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=495490
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.5]
media_type=video
key_frame=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pts=2048
tests: add fate-ffprobe test
12 years ago
pkt_pts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_dts=2048
tests: add fate-ffprobe test
12 years ago
pkt_dts_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=495490
tests: add fate-ffprobe test
12 years ago
width=100
height=100
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[packets_and_frames.packet.6]
codec_type=audio
stream_index=0
pts=2048
pts_time=0.046440
dts=2048
dts_time=0.046440
duration=1024
duration_time=0.023220
convergence_duration=N/A
convergence_duration_time=N/A
size=2048
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=525495
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.6]
media_type=audio
key_frame=1
pkt_pts=2048
pkt_pts_time=0.046440
pkt_dts=2048
pkt_dts_time=0.046440
pkt_duration=1024
pkt_duration_time=0.023220
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=525495
tests: add fate-ffprobe test
12 years ago
sample_fmt=s16
nb_samples=1024
channels=1
channel_layout=unknown
[packets_and_frames.packet.7]
codec_type=audio
stream_index=0
pts=3072
pts_time=0.069660
dts=3072
dts_time=0.069660
duration=1024
duration_time=0.023220
convergence_duration=N/A
convergence_duration_time=N/A
size=2048
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=527566
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.7]
media_type=audio
key_frame=1
pkt_pts=3072
pkt_pts_time=0.069660
pkt_dts=3072
pkt_dts_time=0.069660
pkt_duration=1024
pkt_duration_time=0.023220
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=527566
tests: add fate-ffprobe test
12 years ago
sample_fmt=s16
nb_samples=1024
channels=1
channel_layout=unknown
[packets_and_frames.packet.8]
codec_type=video
stream_index=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pts=4096
tests: add fate-ffprobe test
12 years ago
pts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
dts=4096
tests: add fate-ffprobe test
12 years ago
dts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=230400
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=529644
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.8]
media_type=video
key_frame=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pts=4096
tests: add fate-ffprobe test
12 years ago
pkt_pts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_dts=4096
tests: add fate-ffprobe test
12 years ago
pkt_dts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=529644
tests: add fate-ffprobe test
12 years ago
width=320
height=240
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[packets_and_frames.packet.9]
codec_type=video
stream_index=2
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pts=4096
tests: add fate-ffprobe test
12 years ago
pts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
dts=4096
tests: add fate-ffprobe test
12 years ago
dts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=30000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=760068
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.9]
media_type=video
key_frame=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pts=4096
tests: add fate-ffprobe test
12 years ago
pkt_pts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_dts=4096
tests: add fate-ffprobe test
12 years ago
pkt_dts_time=0.080000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=760068
tests: add fate-ffprobe test
12 years ago
width=100
height=100
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[packets_and_frames.packet.10]
codec_type=audio
stream_index=0
pts=4096
pts_time=0.092880
dts=4096
dts_time=0.092880
duration=1024
duration_time=0.023220
convergence_duration=N/A
convergence_duration_time=N/A
size=2048
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=790073
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.10]
media_type=audio
key_frame=1
pkt_pts=4096
pkt_pts_time=0.092880
pkt_dts=4096
pkt_dts_time=0.092880
pkt_duration=1024
pkt_duration_time=0.023220
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=790073
tests: add fate-ffprobe test
12 years ago
sample_fmt=s16
nb_samples=1024
channels=1
channel_layout=unknown
[packets_and_frames.packet.11]
codec_type=audio
stream_index=0
pts=5120
pts_time=0.116100
dts=5120
dts_time=0.116100
duration=1024
duration_time=0.023220
convergence_duration=N/A
convergence_duration_time=N/A
size=2048
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=792144
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.11]
media_type=audio
key_frame=1
pkt_pts=5120
pkt_pts_time=0.116100
pkt_dts=5120
pkt_dts_time=0.116100
pkt_duration=1024
pkt_duration_time=0.023220
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=792144
tests: add fate-ffprobe test
12 years ago
sample_fmt=s16
nb_samples=1024
channels=1
channel_layout=unknown
[packets_and_frames.packet.12]
codec_type=video
stream_index=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pts=6144
tests: add fate-ffprobe test
12 years ago
pts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
dts=6144
tests: add fate-ffprobe test
12 years ago
dts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=230400
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=794222
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.12]
media_type=video
key_frame=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pts=6144
tests: add fate-ffprobe test
12 years ago
pkt_pts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_dts=6144
tests: add fate-ffprobe test
12 years ago
pkt_dts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=794222
tests: add fate-ffprobe test
12 years ago
width=320
height=240
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[packets_and_frames.packet.13]
codec_type=video
stream_index=2
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pts=6144
tests: add fate-ffprobe test
12 years ago
pts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
dts=6144
tests: add fate-ffprobe test
12 years ago
dts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=2048
tests: add fate-ffprobe test
12 years ago
duration_time=0.040000
convergence_duration=N/A
convergence_duration_time=N/A
size=30000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pos=1024646
tests: add fate-ffprobe test
12 years ago
flags=K
[packets_and_frames.frame.13]
media_type=video
key_frame=1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pts=6144
tests: add fate-ffprobe test
12 years ago
pkt_pts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_dts=6144
tests: add fate-ffprobe test
12 years ago
pkt_dts_time=0.120000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_duration=2048
tests: add fate-ffprobe test
12 years ago
pkt_duration_time=0.040000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
pkt_pos=1024646
tests: add fate-ffprobe test
12 years ago
width=100
height=100
pix_fmt=rgb24
sample_aspect_ratio=1\:1
pict_type=I
coded_picture_number=0
display_picture_number=0
interlaced_frame=0
top_field_first=0
repeat_pict=0
reference=0
[streams.stream.0]
index=0
codec_name=pcm_s16le
profile=unknown
codec_type=audio
codec_time_base=1/44100
codec_tag_string=[1][0][0][0]
codec_tag=0x0001
sample_fmt=s16
sample_rate=44100
channels=1
bits_per_sample=16
id=N/A
r_frame_rate=0/0
avg_frame_rate=0/0
time_base=1/44100
start_pts=0
start_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration_ts=527364
duration=11.958367
tests: add fate-ffprobe test
12 years ago
bit_rate=705600
nb_frames=N/A
nb_read_frames=6
nb_read_packets=6
ffprobe: extend disposition printing support This generalizes the previous work on disposition printing. Disposition flags are shown in a dedicated section, which should improve output intellegibility, extensibility and filtering operations. This breaks output syntax with the recently introduced disposition printing.
12 years ago
[streams.stream.0.disposition]
default=0
dub=0
original=0
comment=0
lyrics=0
karaoke=0
forced=0
hearing_impaired=0
visual_impaired=0
clean_effects=0
attached_pic=0
tests: add fate-ffprobe test
12 years ago
[streams.stream.1]
index=1
codec_name=rawvideo
profile=unknown
codec_type=video
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
codec_time_base=1/51200
tests: add fate-ffprobe test
12 years ago
codec_tag_string=RGB[24]
codec_tag=0x18424752
width=320
height=240
has_b_frames=0
sample_aspect_ratio=1\:1
display_aspect_ratio=4\:3
pix_fmt=rgb24
level=-99
timecode=N/A
id=N/A
r_frame_rate=25/1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
avg_frame_rate=25/1
time_base=1/51200
tests: add fate-ffprobe test
12 years ago
start_pts=0
start_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration_ts=612268
duration=11.958359
tests: add fate-ffprobe test
12 years ago
bit_rate=N/A
nb_frames=N/A
nb_read_frames=4
nb_read_packets=4
ffprobe: extend disposition printing support This generalizes the previous work on disposition printing. Disposition flags are shown in a dedicated section, which should improve output intellegibility, extensibility and filtering operations. This breaks output syntax with the recently introduced disposition printing.
12 years ago
[streams.stream.1.disposition]
default=0
dub=0
original=0
comment=0
lyrics=0
karaoke=0
forced=0
hearing_impaired=0
visual_impaired=0
clean_effects=0
attached_pic=0
tests: add fate-ffprobe test
12 years ago
[streams.stream.2]
index=2
codec_name=rawvideo
profile=unknown
codec_type=video
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
codec_time_base=1/51200
tests: add fate-ffprobe test
12 years ago
codec_tag_string=RGB[24]
codec_tag=0x18424752
width=100
height=100
has_b_frames=0
sample_aspect_ratio=1\:1
display_aspect_ratio=1\:1
pix_fmt=rgb24
level=-99
timecode=N/A
id=N/A
r_frame_rate=25/1
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
avg_frame_rate=25/1
time_base=1/51200
tests: add fate-ffprobe test
12 years ago
start_pts=0
start_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration_ts=612268
duration=11.958359
tests: add fate-ffprobe test
12 years ago
bit_rate=N/A
nb_frames=N/A
nb_read_frames=4
nb_read_packets=4
ffprobe: extend disposition printing support This generalizes the previous work on disposition printing. Disposition flags are shown in a dedicated section, which should improve output intellegibility, extensibility and filtering operations. This breaks output syntax with the recently introduced disposition printing.
12 years ago
[streams.stream.2.disposition]
default=0
dub=0
original=0
comment=0
lyrics=0
karaoke=0
forced=0
hearing_impaired=0
visual_impaired=0
clean_effects=0
attached_pic=0
tests: add fate-ffprobe test
12 years ago
[format]
filename=tests/data/ffprobe-test.nut
nb_streams=3
format_name=nut
start_time=0.000000
nutenc: choose for non audio streams a timebase with finer resolution. While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
12 years ago
duration=11.958367
size=1054727
bit_rate=705599
tests: add fate-ffprobe test
12 years ago
[format.tags]
title=ffprobe test file
tests/fate-ffprobe: fix typo in metadata comment
12 years ago
comment='A comment with CSV, XML & JSON special chars'\: <tag value\="x">
tests: add fate-ffprobe test
12 years ago
comment2=I ♥ Üñîçød€