Opened 12 years ago

Closed 12 years ago

#1138 closed defect (fixed)

Unable to chop mkv

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

Description

I tried to chop a clip from a mkv movie by using the -t and -ss switches (with vcodec, acodec and scodec, "copy").

The command is:

ffmpeg -y -t 0.69 -ss 3208.99 -i 'data/mnt/Les aventuriers (1967).Fra.x264.multisub.mkv/Les aventuriers (1967).Fra.x264.multisub.mkv' -acodec copy -vcodec copy -scodec copy /home/nik/out.mkv

This fails with the error:

[matroska @ 0x8fc92c0] pts < dts in stream 0
av_interleaved_write_frame(): Invalid argument

Then i tried to put the -ss switch *after* -i. That worked! but unfortunately the audio and video are out of sync in the generated clip.

Unfortunately i cannot upload the video because it's 2GB. I can give you the torrent hash if you want.

ffmpeg command output for the first case:

===========================================================
ffmpeg version 0.9.1.git Copyright (c) 2000-2012 the FFmpeg developers

built on Mar 25 2012 01:53:25 with gcc 4.5.2 20110127 (prerelease)
configuration: --enable-gpl --enable-shared
libavutil 51. 44.100 / 51. 44.100
libavcodec 54. 12.100 / 54. 12.100
libavformat 54. 2.100 / 54. 2.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 65.102 / 2. 65.102
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 7.100 / 0. 7.100
libpostproc 52. 0.100 / 52. 0.100

Input #0, matroska,webm, from 'data/mnt/Les aventuriers (1967).Fra.x264.multisub.mkv/Les aventuriers (1967).Fra.x264.multisub.mkv':

Metadata:

creation_time : 2010-01-04 15:47:39

Duration: 01:48:11.26, start: 0.000000, bitrate: 2996 kb/s

Chapter #0.0: start 0.000000, end 1003.240000
Metadata:

title : Chapter 1

Chapter #0.1: start 1003.240000, end 1433.520000
Metadata:

title : Chapter 2

Chapter #0.2: start 1433.520000, end 1857.600000
Metadata:

title : Chapter 3

Chapter #0.3: start 1857.600000, end 2567.720000
Metadata:

title : Chapter 4

Chapter #0.4: start 2567.720000, end 3335.720000
Metadata:

title : Chapter 5

Chapter #0.5: start 3335.720000, end 4157.200000
Metadata:

title : Chapter 6

Chapter #0.6: start 4157.200000, end 4413.240000
Metadata:

title : Chapter 7

Chapter #0.7: start 4413.240000, end 5327.960000
Metadata:

title : Chapter 8

Chapter #0.8: start 5327.960000, end 5858.040000
Metadata:

title : Chapter 9

Chapter #0.9: start 5858.040000, end 6491.264000
Metadata:

title : Chapter 10

Stream #0:0(eng): Video: h264 (High), yuv420p, 720x436 [SAR 64:45 DAR 256:109], 25 fps, 200 tbr, 1k tbn, 50 tbc (default)
Stream #0:1(fre): Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s (default)
Stream #0:2(eng): Subtitle: dvd_subtitle (default)
Stream #0:3(spa): Subtitle: text
Stream #0:4(por): Subtitle: text
Stream #0:5(cze): Subtitle: text
Stream #0:6(rum): Subtitle: dvd_subtitle

Output #0, matroska, to '/home/nik/out.mkv':

Metadata:

creation_time : 2010-01-04 15:47:39
encoder : Lavf54.2.100
Chapter #0.0: start 0.000000, end 0.690000
Metadata:

title : Chapter 5

Stream #0:0(eng): Video: h264, yuv420p, 720x436 [SAR 64:45 DAR 256:109], q=2-31, 25 fps, 1k tbn, 1k tbc (default)
Stream #0:1(fre): Audio: ac3, 48000 Hz, stereo, 192 kb/s (default)
Stream #0:2(eng): Subtitle: ssa (default)

Stream mapping:

Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Stream #0:2 -> #0:2 (copy)

Press [q] to stop, ? for help
[matroska @ 0x8fc92c0] pts < dts in stream 0
av_interleaved_write_frame(): Invalid argument

Attachments (2)

xx.mkv (2.4 MB ) - added by carlrosmann 12 years ago.
dts-seek-offset-fix.diff (799 bytes ) - added by eelco 12 years ago.

Change History (13)

comment:1 by Carl Eugen Hoyos, 12 years ago

Keywords: av_interleaved_write_frame added

Please test current git head.

Is the problem reproducible with one of the three command lines:
ffmpeg -i input.mkv -vcodec copy -an -sn out.mkv
ffmpeg -i input.mkv -acodec copy -vn -sn out.mkv
ffmpeg -i input.mkv -scodec copy -vn -an out.mkv

Is the problem not reproducible without -ss?
Is the problem not reproducible if you cut the sample with dd and use a smaller value for -ss?

comment:2 by carlrosmann, 12 years ago

I'm using git head from 3 days ago.

The problem is reproducible with
ffmpeg -i input.mkv -vcodec copy -an -sn out.mkv

The problem isn't reproducible without -ss. (expected)

I've cut the first 10MB of the file. The problem is reproducible there. I will upload (but of course total duration is wrong).

Please note that there seem to be two problems.
If -ss is before -i there is the interleaved problem. If after there is off sync.

Last edited 12 years ago by carlrosmann (previous) (diff)

by carlrosmann, 12 years ago

Attachment: xx.mkv added

comment:3 by carlrosmann, 12 years ago

To repro

ffmpeg -t 1 -ss 1 -i xx.mkv -vcodec copy -an -sn out.mkv

(i hope)

comment:4 by Carl Eugen Hoyos, 12 years ago

Reproduced by developer: set
Status: newopen
Version: unspecifiedgit-master

Is seeking in the original sample possible with ffplay?
Does ffplay -ss 3208.99 file.mkv work as expected?

comment:5 by carlrosmann, 12 years ago

yes, ffplay works (that was expected).

The specific offset 3208.99 does not matter. It's a random number for a random clip chop. The problem happens with any value. For your testing convinience, just do -ss 1 on the attached file.

by eelco, 12 years ago

Attachment: dts-seek-offset-fix.diff added

comment:6 by eelco, 12 years ago

We ran into the same problem. It seems that the DTS is calculated from the input stream (not from the packet) but doesn't take into account the initial seek.

We created the following fix: https://github.com/tupil/FFmpeg/commit/bdbd883c2e10858b9be55457fe42c1629904087b (also attached)

It works for our use case and also seems to work for the file attached to this ticket, but since we're new to FFmpeg development, we're not sure if it's 100% correct.

comment:7 by carlrosmann, 12 years ago

Thank you!

It seems that lately many of the developers prefer to do whitespace cleanups, refactor the API, make cosmetic improvments, fix the grammar and add some decoders for some rare games that appeared in the 80s. It is very valuable to see some real patches that make ffmpeg actually work as advertised.

hope it gets review.

in reply to:  6 comment:8 by Carl Eugen Hoyos, 12 years ago

Replying to eelco:

https://github.com/tupil/FFmpeg/commits/

I believe you should *really* clarify the license of the source files you added.
While you may not be violating FFmpeg's copyrights (probably not), you may possibly violate the copyright of the Air Video Server authors.

Last edited 12 years ago by Carl Eugen Hoyos (previous) (diff)

in reply to:  7 ; comment:9 by Carl Eugen Hoyos, 12 years ago

Replying to carlrosmann:

It is very valuable to see some real patches that make ffmpeg actually work as advertised.

I am not arguing against the part that I cut but I am rather surprised about this statement from somebody who reported 1 (one) bug on this tracker.

hope it gets review.

Patches posted on ffmpeg-devel (esp. if they are so short) certainly get a review.

in reply to:  9 comment:10 by eelco, 12 years ago

Replying to cehoyos:

Replying to carlrosmann:

hope it gets review.

Patches posted on ffmpeg-devel (esp. if they are so short) certainly get a review.

I was a bit surprised that the trac is apparently a second class citizen when it comes to patch/code reviews, but I bit the bullet and subscribed and posted to ffmpeg-devel ;)

comment:11 by Michael Niedermayer, 12 years ago

Resolution: fixed
Status: openclosed
Note: See TracTickets for help on using tickets.