[FFmpeg-user] 答复: Duration of source video and substracted audio different
张鹏程
zhangpengcheng at btime.com
Fri Dec 16 05:22:38 EET 2016
Thanks a lot! I think it's because the source video loss some frames. I draw the pts of all frames here https://flic.kr/p/Q2UDWj
________________________________________
发件人: ffmpeg-user <ffmpeg-user-bounces at ffmpeg.org> 代表 Moritz Barsnick <barsnick at gmx.net>
发送时间: 2016年12月15日 19:23
收件人: FFmpeg user discussions
主题: Re: [FFmpeg-user] Duration of source video and substracted audio different
On Thu, Dec 15, 2016 at 10:02:03 +0100, Carl Eugen Hoyos wrote:
> Consider using a script that first downloads all segments, then check
> if something is missing.
Yesterday, when looking into this report, I did exactly that: I
downloaded the segments using wget:
$ wget -Sv http://cdn.live.360.cn/huikan_news/vod-media/_XW_203286B417B7C6466B3B_20160627185953.m3u8
$ for u in `grep -F .ts ../_XW_203286B417B7C6466B3B_20160627185953.m3u8`; do wget -Sv "$u"; done
Then concatenated them in order (under the assumption that they don't overlap):
$ for f in $(grep -F .ts ../_XW_203286B417B7C6466B3B_20160627185953.m3u8 | perl -pe 's|.*/([^/]+)$|$1|'); do cat $f; done > _XW_203286B417B7C6466B3B_20160627185953.ts
This resulting MPEG-TS shows the same duration as the original HLS:
Duration: 00:06:52.07, start: 1.400000, bitrate: 673 kb/s
Using
$ ffmpeg -i _XW_203286B417B7C6466B3B_20160627185953.ts -vn -f null -
or
$ ffmpeg -i _XW_203286B417B7C6466B3B_20160627185953.ts -vn _XW_203286B417B7C6466B3B_20160627185953.wav
ffmpeg will seem to process 00:06:51.84:
size= 31904kB time=00:06:51.84 bitrate= 634.6kbits/s speed= 261x
and also copy this duration into other formats' metadata, such as M4A.
Yet the contained AAC stream is apparently shorter:
$ ffmpeg -i _XW_203286B417B7C6466B3B_20160627185953.ts -vn -c copy _XW_203286B417B7C6466B3B_20160627185953.aac
$ ffmpeg -i _XW_203286B417B7C6466B3B_20160627185953.aac -f null -
[...]
size=N/A time=00:06:10.40 bitrate=N/A speed= 426x
So the AAC stream is just shorter than the video, apparently??? Apparently not:
What's interesting is that the MPEG-TS has audio packets with actual
samples at the higher timestamps:
media_type=audio
best_effort_timestamp_time=413.218211
nb_samples=1024
And if you watch the resulting MPEG-TS, you will notice that the audio
plays for more that 06:10. Converting with "-loglevel verbose" shows a
lot of continuity check errors, perhaps they have to do with this?:
[mpegts @ 0xbc3d900] Continuity check failed for pid 17 expected 1 got 0
[...]
Moritz
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-user
mailing list