Opened 5 weeks ago

Closed 4 weeks ago

#7091 closed defect (fixed)

Sega FILM demuxer doesn't pass through any packets for stream copy

Reported by: misty Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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
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/
  Output stream #0:0 (video): 0 packets muxed (0 bytes);
  Total: 0 packets (0 bytes) muxed

Attachments (2)

copy_log.txt (3.1 KB) - added by misty 5 weeks ago.
Verbose log from attempting to copy stream
test.cpk (72.7 KB) - added by misty 5 weeks ago.
Test pattern Sega FILM file

Download all attachments as: .zip

Change History (8)

comment:1 Changed 5 weeks ago by cehoyos

To make this a valid ticket please provide the command line you tested together with the complete, uncut console output.

Changed 5 weeks ago by misty

Verbose log from attempting to copy stream

Changed 5 weeks ago by misty

Test pattern Sega FILM file

comment:2 Changed 5 weeks ago by misty

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

comment:3 Changed 5 weeks ago by Gyan

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 to stop ffmpeg from seeking a keyframe to start copying from. This should yield the entire stream in the output.

comment:5 Changed 5 weeks ago by misty

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 Changed 4 weeks ago by Gyan

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.