-copyts does not work with concat demuxer

[Sesse]

Hi,

I'm having two NUT files that came out of a split; literally, at some point, my program just closed the file, opened a new one and continued to write packets with no pts gap or similar. I'd like to join them back together again. However, evidently I can't; when I join them using the concat filter, I get a three-hour gap in the middle. I've tried using -copyts, and that works fine if I only have one file the usual way:

> ffmpeg -copyts -i file:record-2017-11-05-13:00:24+0100-f67.nut -c copy osipcl2.nut 
[some churn]
> ffprobe -show_streams ./osipcl2.nut 2>&1 | grep start_pts
start_pts=1381844448                    
start_pts=552732979

However, when using the concat demuxer, it still messes with the pts:

> cat osipcl2.txt 
file 'file:record-2017-11-05-13:00:24+0100-f67.nut'
file 'file:record-2017-11-05-13:37:23+0100-f59.nut'
> ffmpeg -copyts -safe 0 -f concat -copyts -i osipcl2.txt -c copy osipcl2.nut
[more churn]
> ffprobe -show_streams ./osipcl2.nut 2>&1 | grep start_pts                  
start_pts=12000                         
start_pts=0

I suppose there's some other issue here with the three-hour extra gap, but just having it respect -copyts would solve that problem automatically for my part. The files should have the same timebase and stream layout and everything, so just blindly shoving packets from one to the other ought to work.

The two files are 1,4 GB and 34 MB respectively, so I thought I should't attach them, but ask if you need a copy :-)

[Sesse]

Replying to Sesse:

The two files are 1,4 GB and 34 MB respectively, so I thought I should't attach them, but ask if you need a copy :-)

Sorry, I mean 11 GB and 265 MB.

[Carl Eugen Hoyos]

To make this a valid ticket, please test current FFmpeg git head and provide the command line you tested together with the complete, uncut console output.

[Sesse]

The test was already with current git head (well, git head as of yesterday). I already gave the full command line. Here is the complete console output:

pannekake:..v/fyrrom/trøndisk2017-dag1> ffmpeg -copyts -safe 0 -f concat -copyts -i osipcl2.txt -c copy osipcl2.nut
ffmpeg version N-88681-gdd435c957a Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18) 20170516
  configuration: 
  libavutil      56.  0.100 / 56.  0.100
  libavcodec     58.  1.100 / 58.  1.100
  libavformat    58.  2.100 / 58.  2.100
  libavdevice    58.  0.100 / 58.  0.100
  libavfilter     7.  0.101 /  7.  0.101
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
[nut @ 0xc22a70e7a0] no index at the end
[nut @ 0xc22a70e7a0] read_timestamp failed.
    Last message repeated 5 times
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, concat, from 'osipcl2.txt':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p(tv, smpte170m/bt709/iec61966-2-1), 1280x720, 59.94 fps, 59.94 tbr, 120k tbn, 240k tbc
    Stream #0:1: Audio: pcm_s32le (PSD  / 0x20445350), 48000 Hz, stereo, s32, 3072 kb/s
File 'osipcl2.nut' already exists. Overwrite ? [y/N] y
Output #0, nut, to 'osipcl2.nut':
  Metadata:
    encoder         : Lavf58.2.100
    Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p(tv, smpte170m/bt709/iec61966-2-1), 1280x720, q=2-31, 59.94 fps, 59.94 tbr, 120k tbn, 120k tbc
    Stream #0:1: Audio: pcm_s32le (PSD  / 0x20445350), 48000 Hz, stereo, s32, 3072 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[nut @ 0xc22a7122a0] no index at the end36kB time=00:35:51.63 bitrate=40650.0kbits/s speed=34.4x    
[nut @ 0xc22a7122a0] read_timestamp failed.
    Last message repeated 7 times
[nut @ 0xc22a716320] Multiple keyframes with same PTS48:54.27 bitrate=6600.8kbits/s speed= 217x    
    Last message repeated 1 times
frame=135882 fps=2135 q=-1.0 Lsize=11338190kB time=03:49:44.37 bitrate=6738.2kbits/s speed= 217x    
video:10479240kB audio:850863kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.071385%

I think maybe the three-hour gap is because the second stream starts around that time pts-wise. So it's possible that it gets the timestamps from the second stream correct, but sets the first one to start at zero, and that's what's causing the gap.