Opened 9 years ago

Last modified 9 years ago

#4868 open defect

Unable to perform mpeg-ts lossless copy with seek

Reported by: bruno.chartier Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: mpegts h264
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Summary of the bug:

ffmpeg is unable to find frames in the video stream and produces an empty file.
The mpegts is produced by Fujitsu hardware encoder (MB86H46).
Tried a few versions of ffmpeg, a few from the last 6 months and an old one from 2010, on Mac and Linux with the same result.

How to reproduce:

sample file uploaded to ftp://upload.ffmpeg.org/incoming/cannot_copy_video_with_seek.ts

[xx]$ ~/perso/ffmpeg  -ss 5 -i cannot_copy_video_with_seek.ts -c:v copy -an -y trimmed.ts 
ffmpeg version 2.8-tessus Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --as=yasm --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzmq --enable-version3 --disable-ffplay --disable-indev=qtkit --disable-indev=x11grab_xcb
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mpegts, from 'cannot_copy_video_with_seek.ts':
  Duration: 00:00:11.67, start: 1.450000, bitrate: 6639 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 90k tbn, 120 tbc
Output #0, mpegts, to 'trimmed.ts':
  Metadata:
    encoder         : Lavf56.40.101
    Stream #0:0: Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 60 tbr, 90k tbn, 90k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
frame=    0 fps=0.0 q=-1.0 Lsize=       0kB time=00:00:00.00 bitrate=N/A    
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)

Attachments (1)

ffmpeg-report_cannot_copy_video_with_seek.ts.log (178.3 KB ) - added by bruno.chartier 9 years ago.
full debug report of mpegts seek+copy producing empty file

Download all attachments as: .zip

Change History (8)

by bruno.chartier, 9 years ago

full debug report of mpegts seek+copy producing empty file

comment:1 by Carl Eugen Hoyos, 9 years ago

Keywords: h264 added; ss copy seek removed
Version: git-master

Could you add the command line that recorded the stream you uploaded?

The stream does not contain a second I frame but uses intra-refresh afaict, the following workaround does not help:

$ ffmpeg -ss 1 -flags2 +showall -i cannot_copy_video_with_seek.ts -vcodec copy -an -f null -

comment:2 by bruno.chartier, 9 years ago

Thanks for looking into it Cehoyos,

Initial recording was not done using ffmpeg but rather the mpegts was recorded strait from the Fuji hw encoder. We've noticed it produces a single keyframe at the beginning.

comment:3 by Carl Eugen Hoyos, 9 years ago

Then please provide an original file that was cut with dd, please do not use FFmpeg to cut samples.

in reply to:  3 comment:4 by bruno.chartier, 9 years ago

cannot_copy_video_with_seek_v2_cut_with_dd.ts uploaded to ftp://upload.ffmpeg.org/incoming

comment:5 by Carl Eugen Hoyos, 9 years ago

Reproduced by developer: set
Status: newopen

Also reproducible (without seeking) if I remove the first frame, either from the transport or the raw video stream.

comment:6 by Carl Eugen Hoyos, 9 years ago

Afaict, the issue is not reproducible with test_recovery.h264 (our intra-only test stream), and the stream cannot be decoded with the reference decoder if the first frame is missing, so there may be an issue with the stream (so it cannot be remuxed without its first frame).

comment:7 by bruno.chartier, 9 years ago

Thanks Cehoyos. Anything I can do to help troubleshoot this further?

Meanwhile, the hardware encoder was configured to encode closed-GOP which so far lets ffmpeg do the seek and trim properly.

Note: See TracTickets for help on using tickets.