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)
Change History (8)
by , 9 years ago
Attachment: | ffmpeg-report_cannot_copy_video_with_seek.ts.log added |
---|
comment:1 by , 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 , 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.
follow-up: 4 comment:3 by , 9 years ago
Then please provide an original file that was cut with dd
, please do not use FFmpeg to cut samples.
comment:4 by , 9 years ago
cannot_copy_video_with_seek_v2_cut_with_dd.ts
uploaded to ftp://upload.ffmpeg.org/incoming
comment:5 by , 9 years ago
Reproduced by developer: | set |
---|---|
Status: | new → open |
Also reproducible (without seeking) if I remove the first frame, either from the transport or the raw video stream.
comment:6 by , 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 , 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.
full debug report of mpegts seek+copy producing empty file