On 12/28/23 07:47, Nicolas Gaullier wrote:
When ffmpeg's '-vf showinfo' and ffprobe's '-show_streams' disagree, which
should I trust?
You should usually trust both, but their meanings are different.
showinfo is a filter, so apply to a running filter graph, I don't think this
information could be very helpful for your use case.
show_streams will give you some start_time/duration using the same core
components (avformat_find_stream_info) as the concat demuxer, which actually
can help.
Another option is to use a kind of "plain raw dump" and guess
start_time/duration by yourself. This can be achieved with an ffmpeg -copyts -c copy -f
framecrc -
-continued below-
Thank you, Nicolas.
I ran this:
<windows script>
set SOURCE=h:\BDMV\STREAM\00306.m2ts
set TARGET=e:\00306.m2ts_framecrc.txt
ffmpeg -i %SOURCE% -copyts -c copy -f framecrc %TARGET%
</windows script>
Here's 00306.m2ts, packets 0..16, as reported by '-framecrc':
stream number ('0' is the video stream, '1' is the audio stream)
P ¦ DTS(P) PTS(P) T(P) B(P)/8 CRC(P) unknown
-- ¦ ------- ------- ---- ------ ---------- -------------
0: 0, 1044806, 1048560, 3753, 178583, 0x34cc62a3, S=1, 1
1: 0, 1048560, 1056067, 3753, 92709, 0xfa7b5edb, F=0x0, S=1, 1
2: 1, 1048560, 1048560, 960, 1084, 0xe54d2b6f, S=1, 1
3: 1, 1049520, 1049520, 960, 1084, 0xe54d2b6f, S=1, 1
4: 1, 1050480, 1050480, 960, 1084, 0xe54d2b6f, S=1, 1
5: 1, 1051440, 1051440, 960, 1084, 0xe54d2b6f, S=1, 1
6: 0, 1052313, 1052313, 3753, 145206, 0x10576cdb, F=0x0, S=1, 1
7: 1, 1052400, 1052400, 960, 1084, 0xe54d2b6f, S=1, 1
8: 1, 1053360, 1053360, 960, 1084, 0xe54d2b6f, S=1, 1
9: 1, 1054320, 1054320, 960, 1084, 0xe54d2b6f, S=1, 1
10: 1, 1055280, 1055280, 960, 1084, 0xe54d2b6f, S=1, 1
11: 0, 1056067, 1063575, 3753, 141288, 0xb70f376e, F=0x0, S=1, 1
12: 1, 1063920, 1063920, 960, 1084, 0xe54d2b6f, S=1, 1
13: 1, 1064880, 1064880, 960, 1084, 0xe54d2b6f, S=1, 1
14: 1, 1065840, 1065840, 960, 1084, 0xe54d2b6f, S=1, 1
15: 1, 1066800, 1066800, 960, 1084, 0xe54d2b6f, S=1, 1
16: 0, 1067328, 1067328, 3753, 146136, 0xc75a68fb, F=0x0, S=1, 1
T(P) for stream 0 is reported erroneously:
reported T(P) actual T(P) N(P)
P0 3753 3754 1
P1 3753 3753 1
P6 3753 3754 1
P11 3753 11261 3
So '-framecrc' & '-showinfo' agree but they disagree with '-show_streams'.
They may agree because they 'drink the same beer'.
This is all indeterminate without the ability to parse actual m2ts headers.
That is where the truth lies.
Note that in some cases, it might happen that the real "first pts" comes before
the ff reported start_time. And in that case, you will see mpv (based on ff) play your
file at a point that is earlier than the start_time reported by ff.
I've seen that.
So, be careful, these start_time/duration things are often much trickier than
they look like.
It seems you want to join segments without reencoding.
First, you have to take care of the available features of your output muxer :
an mp4 is more powerful to handle stream discontinuities than an mpegts format.
Umm... (No, I'm not going to comment on why that might be at this time).
And there are two things to consider:
- "timestamp joining" : care about start/end points;
I cut and trim solely on I-frames, preserving (doubling) the I-frame on both
sides of a cut.
but also, if your input audio/video is not aligned/locked (any usual compressed
audio codec), you will have to reencode audio at least if you want to avoid a
hole (or overlap) in the timeline.
So video packs and audio packs are not correlated, eh? Too bad.
- keyframes : open-gop is not editable with a straight stream copy if you don't
allow some overlap; and you would certainly experience some difficulties to
handle this overlap in a muxer
So many things, very dependent on your exact files and workflow.
At the end, if you encounter an issue, try to reproduce it on short segments to
document a case in trac, with a very exhaustive report and corresponding media
samples.
Will do.
-----
I have designed hundreds of hardware finite state machines (FSM).
Every one of them worked exactly as designed, zero bugs.
I was taught by Dr. John Battocletti at Ohio State University.
FSMs assure 100% coverage and 100% testability.
I have taught FSM methods to codesmiths in Silicon Valley.
The 'C' language has all the elements needed for FSM design.
I will help with FSM design in 'C' for free with anyone who asks.
OO FSM (object-oriented FSM) would be perfect for AV processing.
(The MPEG specifications utilize an informal form of FSM.)
I've been casually working on OOFFmepg for about a year.
OOFFmpeg could be implemented in 'C' using existing FFmpeg libraries.
Based on my experiences, I think OOFFmpeg could be made fairly quickly.
-----
Cheers -- Mark.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
