Streamcopy of private stream produces empty output

[Mark Sanders]

Summary of the bug:
How to reproduce:

% ffmpeg \
 -f mpegts -i file.ts \
 -map i:100 -map i:101 -map i:105 -map i:109 \
 -c:2 copy \
 -c:3 copy \
 -f mpegts file-out.ts

In the previous example the input file is a MPEG-TS (SPTS) with these elementary streams:

• 100: video stream
• 101: audio stream
• 105: teletext data
• 109: PES private data identified as "Data: bin_data ([6][0][0][0] / 0x0006)", so that's DVB Type '0x1b'

The processing is done, and the output has the corresponding 4 elementary streams. However the pid 259 (the new for the private data) is completly empty.

The expected behaviour is that the private data (bin_data) is streamcopied to the output.

Please, fix this error.
Thank you!

[Mark Sanders]

Hi,

Doesn't anyone know a solution to this problem?

I really need to streamcopy (aka transparent copy) of a "private data" (aka binary) of some substream inside a MPEG-TS. The FFmpeg processing is good to filter audio/video/teletext/subtitles, but it lacks support for forwarding the rest of streams when using MPEG-TS containers.

No solution at all?

[Gyan]

Try adding -copy_unknown.

[Mark Sanders]

Replying to Gyan:

Try adding -copy_unknown.

Hi Gyan,

% ffmpeg \
 -f mpegts -i file.ts -copy_unknown \
 -map i:100 -map i:101 -map i:105 -map i:109 \
 -c:2 copy \
 -c:3 copy \
 -f mpegts file-out.ts

It doesn't work!
For any reason I can't understand, the mpegts muxer doesn't write any data from streams with a type different than audio/video/teletext/subtitles.

Any idea to fix this problem?

[Mark Sanders]

Hi,

Futhermore, the parameter -copy_unknown only works with streams with type AVMEDIA_TYPE_UNKNOWN as you can see in the source code:
​https://github.com/FFmpeg/FFmpeg/blob/d702769213487923c0fb0abe4b61f4d9ebddb88b/fftools/ffmpeg_opt.c#L2294

But, the stream that I need to copy is detected as AVMEDIA_TYPE_DATA. But not writed in the output.

[Mark Sanders]

Hi,

I isolated the problem with the demuxer (mpegts). So the problem is not the muxer.

Here one command to reproduce the problem:

% ffmpeg \
 -f mpegts -i file.ts \
 -map i:109 \
 -codec copy \
 -f data file-out.raw

In this case the pid 109 is the one with the private data. And when executing it the "file-out.raw" is empty. So the problem is that the demuxer doesn't read "private data" streams.

The output is:

Input #0, mpegts, from 'file.ts':
  Duration: 00:10:27.88, start: 8592.918144, bitrate: 20857 kb/s
  Program 201
    Metadata:
      service_name    : Program 1
      service_provider: FFMPEG
    Stream #0:0[0x064]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 2
5 fps, 50 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x065](qaa): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
    Stream #0:2[0x069](eng,eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006)
    Stream #0:3[0x06d]: Data: bin_data ([6][0][0][0] / 0x0006)
File 'file-out.raw' already exists. Overwrite ? [y/N] y
Output #0, data, to 'file-out.raw':
  Metadata:
    encoder         : Lavf58.22.100
    Stream #0:0: Data: bin_data ([6][0][0][0] / 0x0006)
Stream mapping:
  Stream #0:3 -> #0:0 (copy)
Press [q] to stop, [?] for help
size=       0kB time=00:00:00.00 bitrate=N/A speed=   0x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)

[Carl Eugen Hoyos]

Please (test current FFmpeg git head and) provide the command line you tested together with the complete, uncut console output and provide a sample input file.

[Mark Sanders]

Replying to cehoyos:

Please (test current FFmpeg git head and) provide the command line you tested together with the complete, uncut console output and provide a sample input file.

Hi Cehoyos,

I feel isn't needed. I discovered the problem: this stream (the private one) isn't a PES stream. So, the "mpegts" demuxer simply discards it. Futhermore, the "mpegtsenc" muxer doesn't support non-PES streams.

So the only solution is: add support to both (demuxer and muxer) to support (optionally) non-PES streams.