Project

General

Profile

Bug #336

Bug in MKV file

Added by mulder77 - almost 14 years ago. Updated over 12 years ago.

Status:
Rejected
Priority:
Urgent
Assignee:
Andreas Smas
Category:
Muxers
Target version:
2.13
Start date:
Due date:
% Done:

0%

Estimated time:
Found in version:
2.12
Affected Versions:

Description

I came up with this problem while 2.12 was still being developed.

With the final release version, I am not able to convert the recorded MKV file to a TS file anymore. This was a problem in 2.11 for HD recordings only, now also SD recordings are affected.

Conversion failure for HD:

ffmpeg -y -i Das-Erste-HD-Tagesschau.2010-12-03.14-00.mkv -vcodec copy -sameq -acodec copy -f mpegts Das-Erste-HD-Tagesschau.2010-12-03.14-00.ts

FFmpeg version SVN-r24044, Copyright (c) 2000-2010 the FFmpeg developers
built on Jul 21 2010 15:03:32 with gcc 4.5.0 20100716 (Red Hat 4.5.0-3)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --extra-version=rpmfusion --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avfilter-lavf --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
libavutil 50.20. 0 / 50.20. 0
libavcodec 52.79. 1 / 52.79. 1
libavformat 52.73. 0 / 52.73. 0
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 1.20. 1 / 1.20. 1
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0
[h264 0x27f0270] number of reference frames exceeds max (probably corrupt input), discarding one
Last message repeated 3 times
[matroska 0x27dd6c0] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska, from 'Das-Erste-HD-Tagesschau.2010-12-03.14-00.mkv':
Metadata:
title : Tagesschau
DATE_BROADCASTED: 2010-12-03 14:00:00
ORIGINAL_MEDIA_TYPE: TV
CONTENT_TYPE : News / Current affairs
TVCHANNEL : Das Erste HD
SUMMARY :
Duration: 00:15:59.84, start: 0.000000, bitrate: 960 kb/s
Stream #0.0(eng): Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 fps, 50 tbr, 1k tbn, 100 tbc
Stream #0.1(deu): Audio: mp2, 48000 Hz, 2 channels, s16, 256 kb/s
Stream #0.2(mis): Audio: mp2, 48000 Hz, 2 channels, s16, 256 kb/s
Stream #0.3(deu): Audio: ac3, 48000 Hz, stereo, s16, 448 kb/s
[mpegts 0x28a3e40] muxrate 1 bps, pcr every 100 pkts, sdt every 200, pat/pmt every 40 pkts
Output #0, mpegts, to 'Das-Erste-HD-Tagesschau.2010-12-03.14-00.ts':
Metadata:
encoder : Lavf52.73.0
Stream #0.0(eng): Video: libx264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], q=2-31, 90k tbn, 1k tbc
Stream #0.1(deu): Audio: mp2, 48000 Hz, 2 channels, 256 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
Press [q] to stop encoding
*[mpegts 0x28a3e40] st:0 error, non monotone timestamps 34200 >= 19800*
av_interleaved_write_frame(): Operation not permitted

Conversion failure for SD:

ffmpeg -y -i D-AS--VIERTE-Twilight-Zone---Unwahrscheinliche-Geschichten.2010-12-03.16-00.mkv -vcodec copy -sameq -acodec copy -f mpegts D-AS--VIERTE-Twilight-Zone---Unwahrscheinliche-Geschichten.2010-12-03.16-00.ts

FFmpeg version SVN-r24044, Copyright (c) 2000-2010 the FFmpeg developers
built on Jul 21 2010 15:03:32 with gcc 4.5.0 20100716 (Red Hat 4.5.0-3)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --extra-version=rpmfusion --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avfilter-lavf --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
libavutil 50.20. 0 / 50.20. 0
libavcodec 52.79. 1 / 52.79. 1
libavformat 52.73. 0 / 52.73. 0
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 1.20. 1 / 1.20. 1
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0
[matroska 0x9126c0] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska, from 'D-AS--VIERTE-Twilight-Zone---Unwahrscheinliche-Geschichten.2010-12-03.16-00.mkv':
Metadata:
title : Twilight Zone - Unwahrscheinliche Geschichten
DATE_BROADCASTED: 2010-12-03 16:00:00
ORIGINAL_MEDIA_TYPE: TV
CONTENT_TYPE : Movie / Drama
TVCHANNEL : D AS VIERTE
SUMMARY : Mitternachtssonne
Duration: 00:01:40.08, start: 0.000000, bitrate: 15575 kb/s
Stream #0.0(eng): Video: mpeg2video, yuv420p, 720x576 [PAR 16:15 DAR 4:3], 15000 kb/s, 25 fps, 25 tbr, 1k tbn, 50 tbc
Stream #0.1(deu): Audio: mp2, 48000 Hz, 2 channels, s16, 192 kb/s
Stream #0.2(deu): Audio: ac3, 48000 Hz, stereo, s16, 384 kb/s
[mpegts 0x9869a0] muxrate 1 bps, pcr every 100 pkts, sdt every 200, pat/pmt every 40 pkts
Output #0, mpegts, to 'D-AS--VIERTE-Twilight-Zone---Unwahrscheinliche-Geschichten.2010-12-03.16-00.ts':
Metadata:
encoder : Lavf52.73.0
Stream #0.0(eng): Video: mpeg2video, yuv420p, 720x576 [PAR 16:15 DAR 4:3], q=2-31, 15000 kb/s, 90k tbn, 1k tbc
Stream #0.1(deu): Audio: mp2, 48000 Hz, 2 channels, 192 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
Press [q] to stop encoding
[mpegts @ 0x9869a0] st:0 error, non monotone timestamps 10800 >= 10800
av_interleaved_write_frame(): Operation not permitted

History

#1

Updated by mulder77 - almost 14 years ago

Addendum:

Andreas Öman wrote regarding this problem this back in Sep10.

"Yes, I just haven't fixed it yet.
I assume the issue is that some players expects that auto packets
arrives before the video packets in the MKV file."

#2

Updated by Andreas Smas almost 14 years ago

  • Target version changed from 3.0 to 2.13
#3

Updated by Andreas Smas almost 14 years ago

  • Category changed from General to PVR / DVR
#4

Updated by Nathan McAullay almost 14 years ago

Hi there, I have implemented the post-processing comskip as described at your homepage. The problem above presents itself most of the time when the ffmpeg conversion takes place (mkv to mpeg). Let me know if there is anything I can provide to assist in the squashing of this bug. Cheers, Nathan

#5

Updated by Nathan McAullay almost 14 years ago

Hi there, not sure if it is related, but xbmc has trouble skipping according to comskip generated EDL files when viewing the tvheadend MKV file. The MPEG file that is derived from the MKV (to put into comskip) plays absolutely fine and auto skips based on the cut list in the same EDL. If you think it is related, and need a log file, please let me know. Otherwise, i can log a new bug?

#6

Updated by Nathan McAullay almost 14 years ago

Hi again, sorry to bombard... i have asked a question on the xbmc forum, and there was a response about a potential problem in the tvheadend generated mkv file.
http://forum.xbmc.org/showthread.php?t=93042&highlight=mkv+comskip+tvheadend
Not sure if any fixes have occured to tvheadend that may sort out this problem (since the ppa build of opdenkamp at https://launchpad.net/~lars-opdenkamp/+archive/xbmc-pvr)

#7

Updated by Markus Bonet over 13 years ago

As an update, I'd like to share that I now have more problems with SD recordings since I had to replace my motherboard (now using Asus E35M1-M Pro).
I have this monotone timestamps error message quiet often now.

Some observations:

- Never checked it before, but I have entries from the kernel/driver: [65817.153586] cx880/2-mpeg: general errors: 0x00000100

- Idle scanning/mux detection seems to have influence. Since I disabled those features, half of the recordings are ok, the others still fail to convert in ffmpeg

- I updated the driver from the homepage and overwrote the drivers which come with my kernel (F14 x86_64), I also updated the firmware to 1.26.90.0 (I am using a Hauppauge WinTV Nova-HD-S2)

Andreas, any confirmation from your statement in Sep10? Do you think this is something you can work on?
I will create an forum thread to exchange experience with the trouble I encountered with the card/mainboard but I am still hoping for an solution from you.

#8

Updated by Hein Rigolo about 13 years ago

  • Category changed from PVR / DVR to Muxers
  • Found in version set to 2.12
#9

Updated by Nathan McAullay over 12 years ago

Hi all, i've come back for another go with TVHeadend (a year later). Many problems i was seeing a year ago have been fixed, but this one still appears. I've got TVHeadend running wonderfully on a QNap NAS (http://forum.qnap.com/viewtopic.php?f=276&t=54068&start=90), no problems with EPG overlaps, or missed recordings. The only problem i can see is that when a recording is underway, and I choose to watch it using XBMC (openelec, ion pvr build), the skip/advance function is noticably slower. Skipping ahead 30 seconds on a completed TVHeadend recording is instant, but on a recording that is still underway, a 30 second skip can take 5 seconds. Skipping 10 minutes can take minutes. Resuming the playback to the bookmark can take ages also. I'm not sure if this is fixable, but definately points to this issue. I see this is the only "urgent" issue in the 2.13 list. I'd be keen to assist in testing any fixes (if i can - the qnap qpkg is compiled and maintained by a chap called virtualdj - not me). Cheers Nathan

#10

Updated by Hein Rigolo over 12 years ago

This has to do with the way mkv is structured. Only when a recording is completely finished it is possible to add information to the recording that helps in locating a specific time in the file. So this can not be solved ....

Hein

#11

Updated by Nathan McAullay over 12 years ago

Thanks for the response. So, just to confirm that I'm interpreting this correctly, a tvheadend backend that is currently recording (into a mkv file) will always cause skip/rewind issues to any frontend playing that recording in progress? Is that why mythtv records to mpeg? If so, has anyone implemented recording into a format other than mkv in tvheadend? Cheers Nathan

#12

Updated by Hein Rigolo over 12 years ago

yes, there is a patch floating around that implements recording to mpeg2 format.
see https://github.com/andoma/tvheadend/pull/38 for more information

#13

Updated by Markus Bonet over 12 years ago

Hi, I just found that some work has been done on this topic.
Great work, thanks so far.

I did some quick recording tests and it looks like SD recordings can be processed (with ProjextX or Avidemux) w/o any problems as it was already with TS files converted from MKV via ffmpeg.

HD recordings to TS look good as well, mplayer plays them just fine.
But was anyone successful in processing such recording with Avidemux?

Thanks
Markus

#14

Updated by Adam Sutton over 12 years ago

  • Status changed from New to Rejected

Going to close this, simply because its old and MKV issues have had significant work so "may" be fixed.

But also the muxer code is all being reworked anyway, so this should hopefully be redundant. But if not re-submit.

Adam

Also available in: Atom PDF