Bookmark changes between 5.1 and Stereo audio?

[/df]

I'm not sure if this is relevant, but if you set both -ss and -to as output options with ffmpeg it works as expected, i.e. the section copied starts at the 'ss' value and ends at the 'to' value. However, if you set -ss as an input option, the -to option acts like -t, i.e. the section copied starts at the 'ss' value with the 'to' value used as the duration.

Presumably the logic is that the output option -to is counting from an implicit output -ss 0, corresponding to the specified input -ss position?

For instance, assuming a stream with duration 1000s, input -ss 100, output -ss 150 -to 750, the result should be the section from 100+150=250s to 100+750=850s.

If MET's observation happens with input -ss/to options, that looks like a bug in ffmpeg.

 

[MymsMan]

Presumably the logic is that the output option -to is counting from an implicit output -ss 0, corresponding to the specified input -ss position?

For instance, assuming a stream with duration 1000s, input -ss 100, output -ss 150 -to 750, the result should be the section from 100+150=250s to 100+750=850s.

You are right, in some of my experiments I was surprised when my 'cropped' output turned out to longer than the original!
So I then adjusted the -to values and then ffmpeg complained that -to must be greater than -ss even though they were on different sides of -i and have different origins.
The correct solution was to use -t for an absolute duration for the output (I possibly could also have explicitly put -ss 0 after -i)

 

[florca]

Can you give an example of the ffmpeg command you were using and I will try and see where we were both going wrong.

Sorry it's taken a while to get back to this, but here is a (better) ffmpeg concat process which works for me - at the moment I've run everything on a Pi4B with

ffmpeg version 4.1.6-1~deb10u1+rpt1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 8 (Raspbian 8.3.0-6+rpi1)

as each operation runs much more speedily than on the Humax, but I think the same logic should apply when running there.
Step 1 - Copy (remux) the file, selecting only the Video and Primary Audio streams to re-base all of the timestamps:

ffmpeg -i "test3.ts" -c copy -async 1 -map 0:0 -map 0:1 -muxdelay 0 "test3.m2ts"

Step 2 - Generate cut points using the PTS audio channel transition logic (now with a zero based timestamp) posted previously (and also swap the file ext back to .ts)
Step 3 - run it through the ffmpeg concat demuxer as documented here. using a command:

ffmpeg -hide_banner -f concat -safe 0 -i concat.txt -async 1 -avoid_negative_ts 1 -muxdelay 0 -c copy test3.m2ts

with a concat.txt file of:

ffconcat version 1.0

file 'test3.ts'
inpoint 18.453333
outpoint 926.400000

file 'test3.ts'
inpoint 1170.453333
outpoint 1798.400000

file 'test3.ts'
inpoint 2042.410667
outpoint 2399.424000

file 'test3.ts'
inpoint 2643.413333
outpoint 3213.440000

Which from a Channel 4HD 5.1 recording with Stereo start / end sections and three Stereo ad-breaks produces a file with cuts perfectly syncronised with the programme idents and 5.1 audio throughout.
I know that this takes two ffmpeg passes (plus a full ffprobe to determine the audio transitions) but it runs much faster than the previous multiple individual -ss / -to cut sections followed by a concat "a1.ts | a2.ts.." step.
So far I've only tested this on a single input file, so needs shaking out more thoroughly, but seems like a decent way forward?

 

[florca]

Just tried running this on the Humax which produced an identical output file. For a 2GB HD recording with an initial length of 57 minutes, an output length of 41 minutes the run time for the copy and concat steps (sequential, not pipelined) was 14 minutes. This compares to 38 minutes using the initial approach, although 5 minutes of that was the ffprobe steps to determine whether we have >Stereo audio and produce the cut points file. So this method better than halves the run time on a Humax.
Doing the initial ffmpeg straight copy with -muxdelay 0 has sorted out the previous issue when using a concat.txt definition file, where the cut points weren't aligned with where the PTS timestamps said they should fall.
Now to rework the script to utilise this method...

 

[MymsMan]

Just tried running this on the Humax which produced an identical output file. For a 2GB HD recording with an initial length of 57 minutes, an output length of 41 minutes the run time for the copy and concat steps (sequential, not pipelined) was 14 minutes. This compares to 38 minutes using the initial approach, although 5 minutes of that was the ffprobe steps to determine whether we have >Stereo audio and produce the cut points file. So this method better than halves the run time on a Humax.
Doing the initial ffmpeg straight copy with -muxdelay 0 has sorted out the previous issue when using a concat.txt definition file, where the cut points weren't aligned with where the PTS timestamps said they should fall.
Now to rework the script to utilise this method...

I have been wondering if you could use ffmpeg instead of ffprobe to produce your detection information and produce the clean copy at the same time

 

[florca]

I have been wondering if you could use ffmpeg instead of ffprobe to produce your detection information and produce the clean copy at the same time

Looks like the answer is no. The -select_streams, -show_entries, -show_frames options are only available in ffprobe so far as I can tell...
EDIT...
Maybe not quite true... I think you could probably determine cut points using other ffmpeg filters and options, but the massive snag there is that these almost always involve a full stream decode / encode rather than copy / remux so the elapsed time, quality and processor load will all suffer very badly.