generic-library/ffmpeg
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
5dd5985e05
ffmpeg/tests/ref/fate/ffprobe_json

600 lines
18 KiB
Plaintext
Raw Normal View History

tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
{
"packets_and_frames": [
{
"type": "packet",
"codec_type": "audio",
"stream_index": 0,
"pts": 0,
"pts_time": "0.000000",
"dts": 0,
"dts_time": "0.000000",
"duration": 1024,
"duration_time": "0.023220",
"size": "2048",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "572",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "572",
fate: update fate for 1a490df12fd9 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2012-12-15 12:41:24 +01:00
"pkt_size": "2048",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"sample_fmt": "s16",
"nb_samples": 1024,
lavc: do not init frame with guessed layout. It is breaking support from files with unknown layout.
2013-03-14 19:15:12 +01:00
"channels": 1
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "230400",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "2647",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "2647",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "30000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "233068",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "233068",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"codec_type": "audio",
"stream_index": 0,
"pts": 1024,
"pts_time": "0.023220",
"dts": 1024,
"dts_time": "0.023220",
"duration": 1024,
"duration_time": "0.023220",
"size": "2048",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "263073",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "263073",
fate: update fate for 1a490df12fd9 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2012-12-15 12:41:24 +01:00
"pkt_size": "2048",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"sample_fmt": "s16",
"nb_samples": 1024,
lavc: do not init frame with guessed layout. It is breaking support from files with unknown layout.
2013-03-14 19:15:12 +01:00
"channels": 1
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"pts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"dts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "230400",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "265151",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_pts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_dts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "265151",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"pts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"dts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "30000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "495575",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_pts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_dts": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "495575",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"codec_type": "audio",
"stream_index": 0,
"pts": 2048,
"pts_time": "0.046440",
"dts": 2048,
"dts_time": "0.046440",
"duration": 1024,
"duration_time": "0.023220",
"size": "2048",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "525580",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "525580",
fate: update fate for 1a490df12fd9 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2012-12-15 12:41:24 +01:00
"pkt_size": "2048",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"sample_fmt": "s16",
"nb_samples": 1024,
lavc: do not init frame with guessed layout. It is breaking support from files with unknown layout.
2013-03-14 19:15:12 +01:00
"channels": 1
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"codec_type": "audio",
"stream_index": 0,
"pts": 3072,
"pts_time": "0.069660",
"dts": 3072,
"dts_time": "0.069660",
"duration": 1024,
"duration_time": "0.023220",
"size": "2048",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "527651",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "527651",
fate: update fate for 1a490df12fd9 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2012-12-15 12:41:24 +01:00
"pkt_size": "2048",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"sample_fmt": "s16",
"nb_samples": 1024,
lavc: do not init frame with guessed layout. It is breaking support from files with unknown layout.
2013-03-14 19:15:12 +01:00
"channels": 1
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"pts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"dts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "230400",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "529729",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_pts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_dts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "529729",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"pts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"dts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "30000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "760153",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_pts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_dts": 4096,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "760153",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"codec_type": "audio",
"stream_index": 0,
"pts": 4096,
"pts_time": "0.092880",
"dts": 4096,
"dts_time": "0.092880",
"duration": 1024,
"duration_time": "0.023220",
"size": "2048",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "790158",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "790158",
fate: update fate for 1a490df12fd9 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2012-12-15 12:41:24 +01:00
"pkt_size": "2048",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"sample_fmt": "s16",
"nb_samples": 1024,
lavc: do not init frame with guessed layout. It is breaking support from files with unknown layout.
2013-03-14 19:15:12 +01:00
"channels": 1
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"codec_type": "audio",
"stream_index": 0,
"pts": 5120,
"pts_time": "0.116100",
"dts": 5120,
"dts_time": "0.116100",
"duration": 1024,
"duration_time": "0.023220",
"size": "2048",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "792229",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "792229",
fate: update fate for 1a490df12fd9 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2012-12-15 12:41:24 +01:00
"pkt_size": "2048",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"sample_fmt": "s16",
"nb_samples": 1024,
lavc: do not init frame with guessed layout. It is breaking support from files with unknown layout.
2013-03-14 19:15:12 +01:00
"channels": 1
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"pts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"dts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "230400",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "794307",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_pts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_dts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "794307",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"type": "packet",
"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>
2012-10-01 23:51:35 +02:00
"pts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"dts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"duration_time": "0.040000",
"size": "30000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pos": "1024731",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"flags": "K"
},
{
"type": "frame",
"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>
2012-10-01 23:51:35 +02:00
"pkt_pts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_dts": 6144,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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>
2012-10-01 23:51:35 +02:00
"pkt_duration": 2048,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"pkt_duration_time": "0.040000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"pkt_pos": "1024731",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
ffprobe: remove deprecated frame "reference" field
2013-03-16 01:22:45 +01:00
"repeat_pict": 0
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
}
],
"streams": [
{
"index": 0,
"codec_name": "pcm_s16le",
"codec_type": "audio",
"codec_time_base": "1/44100",
nut: put nut PCM audio tags in front of avi tags. This fixes correctly storing and identifying PCM in nut. Based on patch by Luca Barbato Found-by: durandal_1707 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2012-11-28 01:32:22 +01:00
"codec_tag_string": "PSD[16]",
"codec_tag": "0x10445350",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"sample_fmt": "s16",
"sample_rate": "44100",
"channels": 1,
"bits_per_sample": 16,
"r_frame_rate": "0/0",
"avg_frame_rate": "0/0",
"time_base": "1/44100",
"start_pts": 0,
"start_time": "0.000000",
"bit_rate": "705600",
"nb_read_frames": "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.
2012-09-26 12:30:08 +02:00
"nb_read_packets": "6",
"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
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
},
"tags": {
"E": "mc²"
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.
2012-09-26 12:30:08 +02:00
}
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"index": 1,
"codec_name": "rawvideo",
"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>
2012-10-01 23:51:35 +02:00
"codec_time_base": "1/51200",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
"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>
2012-10-01 23:51:35 +02:00
"avg_frame_rate": "25/1",
"time_base": "1/51200",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"start_pts": 0,
"start_time": "0.000000",
"nb_read_frames": "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.
2012-09-26 12:30:08 +02:00
"nb_read_packets": "4",
"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
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
},
"tags": {
"title": "foobar",
"duration_ts": "field-and-tags-conflict-attempt"
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.
2012-09-26 12:30:08 +02:00
}
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
},
{
"index": 2,
"codec_name": "rawvideo",
"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>
2012-10-01 23:51:35 +02:00
"codec_time_base": "1/51200",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"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,
"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>
2012-10-01 23:51:35 +02:00
"avg_frame_rate": "25/1",
"time_base": "1/51200",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"start_pts": 0,
"start_time": "0.000000",
"nb_read_frames": "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.
2012-09-26 12:30:08 +02:00
"nb_read_packets": "4",
"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
2012-09-17 21:08:46 +02:00
}
],
"format": {
"filename": "tests/data/ffprobe-test.nut",
"nb_streams": 3,
ffprobe: add -show_programs option The option is used to sort the streams by program. Signed-off-by: Florent Tribouilloy <florent.tribouilloy@smartjog.com> Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
2013-07-25 12:55:40 +02:00
"nb_programs": 0,
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"format_name": "nut",
"start_time": "0.000000",
nutdec: Implement duration parsing for indexed nuts Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2013-05-02 18:44:22 +02:00
"duration": "0.120000",
fate/ffprobe: add some stream metadata.
2012-09-27 09:49:56 +02:00
"size": "1054812",
nutdec: Implement duration parsing for indexed nuts Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2013-05-02 18:44:22 +02:00
"bit_rate": "70320800",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"tags": {
"title": "ffprobe test file",
tests/fate-ffprobe: fix typo in metadata comment
2012-09-24 10:32:52 +02:00
"comment": "'A comment with CSV, XML & JSON special chars': <tag value=\"x\">",
tests: add fate-ffprobe test
2012-09-17 21:08:46 +02:00
"comment2": "I ♥ Üñîçød€"
}
}
}
Reference in New Issue Copy Permalink