Opened 6 years ago
Closed 6 years ago
#7091 closed defect (fixed)
Sega FILM demuxer doesn't pass through any packets for stream copy
Reported by: | Misty De Meo | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
FFmpeg produces an empty file when trying to copy a stream using -c:v copy
from a .CPK file using the segafilm demuxer. FFmpeg does successfully demux the stream when decoding video or audio; it only fails when copying the streams verbatim.
With debug enabled, I can see that each packet is producing a "cur_dts is invalid" message.
How to reproduce:
% ffmpeg -i input.cpk -c:v copy output.mov ffmpeg version git master built on March 18, 2018
The verbose logs for the input and output streams show no packets being muxed:
Input file #0 (/Users/vlcice/Games/Lunar files/Lunar Silver Star Story translation/FMVs/Cinepak/AN000.CPK): Input stream #0:0 (video): 2515 packets read (16913460 bytes); Input stream #0:1 (audio): 431 packets read (9518248 bytes); Total: 2946 packets (26431708 bytes) demuxed Output file #0 (/tmp/copy.mov): Output stream #0:0 (video): 0 packets muxed (0 bytes); Total: 0 packets (0 bytes) muxed
Attachments (2)
Change History (8)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Sure thing. I've attached the complete, uncut console output from a verbose log along with a test pattern file that reproduces the bug. The command line I tested was:
ffmpeg -i test.cpk -c:v copy -v debug copy.mov
comment:3 by , 6 years ago
Despite the first frame being a keyframe, the packet isn't marked as such. If this is a typical valid file, then it's a bug in the demuxer code which marks keyframe status.
You can use ffmpeg -i test.cpk -c copy -copyinkf out.mov
to stop ffmpeg from seeking a keyframe to start copying from. This should yield the entire stream in the output.
comment:5 by , 6 years ago
Thanks! I see after that there's a second bug which means invalid timestamp/duration data is set; I'll submit a patch for that as well.
comment:6 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
To make this a valid ticket please provide the command line you tested together with the complete, uncut console output.