Opened 11 years ago
Last modified 11 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 , 11 years ago
| Attachment: | ffmpeg-report_cannot_copy_video_with_seek.ts.log added |
|---|
comment:1 by , 11 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 , 11 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 , 11 years ago
Then please provide an original file that was cut with dd, please do not use FFmpeg to cut samples.
comment:4 by , 11 years ago
cannot_copy_video_with_seek_v2_cut_with_dd.ts uploaded to ftp://upload.ffmpeg.org/incoming
comment:5 by , 11 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 , 11 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 , 11 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