[FFmpeg-user] Unresolved concatenation and subtitle problems

[Mark Filipak]

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.