Bug #362
Wrong timestamp in mkv file
0%
Description
Yesterday, i wanted to watch a film I recorded monday. Film starts fine but after a while (47 min), it recomes unwatchable (slow motion, no sound, ...). The film is said to be recorded OK in tvheadend web interface. Both xbmc and vlc are completely lost by the timestamp as if timestamp do contain garbage (the slider in vlc goes back to beginning, the display of current timestamps contains garbage). I think the streams are OK as using trick mode I can see the fimlm images just the timestamp have sudddently gone crasy.
I will try to find time to cut down the film as it starts failing 4s before and 4s after min and send the result.
If I report it now it is because I would like to know if someone already experienced the pb or if someone knows how to recompute the timestamp for an mkv.
History
Updated by polini - almost 14 years ago
If I report it now it is because I would like to know if someone already experienced the pb or if someone knows how to recompute the timestamp for an mkv.
Try mkvmerge to correct the file. Perhaps it helps...
Updated by Eric Valette over 13 years ago
I'm eager to get this one fiexd because I discovered that all my film recorded on TF1 HD, France2 HD or M6HD do exhibit the same problem. The mkv is created and tvheadend reports no problem. The film starts playing normally but after a good amount of time (E.g 1h45 in the last one I checked), video starts playing at 1/10 of the normal speed as it I had a slow motion button.
I first tried the advice above and did a mkvmerge -o /videoRecords/Match-Point.mkv /videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv. The command finish without error and I can play the video part of the entire film correctly but loose sound at the place I was seeing the problem on video.
Here are the characteristic of the file:
ffprobe /videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv
Input #0, matroska,webm, from '/videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv':
Metadata:
title : Match Point
DATE_BROADCASTED: 2011-02-20 20:35:00
ORIGINAL_MEDIA_TYPE: TV
TVCHANNEL : France 2 HD
SUMMARY : Alors qu'il est sur le point d'épouser la soeur de son ami, un jeune professeur de tennis fait la connaissance de sa ravissante fiancée, une jeune Américaine venant juste d'arriver en Angleterre Critique : Sans aucun doute, le meilleur film de Woody Allen depuis plusieurs années. Un film noir à l'humour délectable et empli de cynisme
Duration: 02:12:27.42, start: 0.000000, bitrate: 384 kb/s
Stream #0.0(eng): Video: h264 (Main), yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 25 fps, 50 tbr, 1k tbn, 50 tbc (default)
Stream #0.1(qaa): Audio: eac3, 48000 Hz, 5.1, s16, 256 kb/s (default)
Stream #0.2(fra): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s (default)
Stream #0.3(fra): Subtitle: [0][0][0][0] / 0x0000 (default)
Unsupported codec (id=0) for input stream 3
Mind the strange qaa language that mkvmerge dislikes when using the gui. The fisrt audio stream is eac3 with spatial extension (look the 5.1) which is the audio stream I would like to get when remuxing via mkvmerge.
Here are the info reported via mkvmerge itself
mkvmerge -i /videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv
File '/videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv': container: Matroska
Track ID 1: video (V_MPEG4/ISO/AVC)
Track ID 2: audio (A_EAC3)
Track ID 3: audio (A_EAC3)
Track ID 4: subtitles (S_DVBSUB)
Global tags: 4 entries
mediainfo /videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv
General
Unique ID : 242740264354691518820267978654223599646 (0xB69E130AC245997F90183C3B9372881E)
Complete name : /videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv
Format : Matroska
File size : 5.35 GiB
Duration : 2h 12mn
Overall bit rate : 5 778 Kbps
Movie name : Match Point
Writing application : HTS Tvheadend git-cae47cf
Writing library : HTS Tvheadend Matroska muxer
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format settings, CABAC : No
Muxing mode : Container profile=[email protected]
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 12mn
Bit rate : 5 279 Kbps
Width : 1 440 pixels
Original width : 16 pixels
Height : 1 088 pixels
Original height : 32 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 0.500
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.135
Stream size : 4.88 GiB (91%)
Language : English
Audio #1
ID : 2
Format : E-AC-3
Format/Info : Audio Coding 3
Codec ID : A_EAC3
Duration : 2h 12mn
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -1s 118ms
Stream size : 243 MiB (4%)
Language : qaa
Audio #2
ID : 3
Format : E-AC-3
Format/Info : Audio Coding 3
Codec ID : A_EAC3
Duration : 2h 12mn
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -1s 76ms
Stream size : 121 MiB (2%)
Language : French
Text
ID : 4
Format : S_DVBSUB
Codec ID : S_DVBSUB
Language : French
Now when I tried to extract audio and video to remux them manually via mkvmerge I noticed something:
ffmpeg -i /videoRecords/France-2-HD-Match-Point.2011-02-20.20-35.mkv -map 0.1 -acodec copy /videoRecords/MatchPoint1.eac3
it start normally without issuing any error and then suddently I get a bunch of
[eac3 @ 0x1848280] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 627887700 >= -7962043860
mind the minus. The left part is the last non negative dts value and the right part keep decreasing. This error occurs exactly where the video error starts. Here are the maths:
full extracted file : 253371392 byte for 2h12. Size near the error (hit ^C) 222538752 = 1h45.
So I bet:
1) the eac3 audio stream is corrupted. The - sign in the dts error message is just an indication of the pb,
2) could well be an integer overflow
In addition, before I was recording in ts directly using vdr and never see such a problem.
I have no problem recording the ARTE HD channel but the stream characteristic are different:
video is the same type (although H264 video stream is CBR instead of VBR) but audio does not have eac3.
So I highly suspect a bug in the EAC3 stream as included in the mkv produced by tvheadend.
What can I do to help fixing this?
Updated by Andreas Smas over 13 years ago
- Category set to PVR / DVR
- Assignee set to Andreas Smas
- Target version set to 2.13
Updated by Hein Rigolo about 13 years ago
- Status changed from New to Need feedback
- Found in version set to 2.12-git
did the commits of 29-10-2011 solved this issue?
Updated by Eric Valette about 13 years ago
How could a fix posterior to a pb fix an already recorded file? So no it does not fix the timestamp problem. However, the problem did not happen recently even without the h264 stream generation fix.
Updated by Hein Rigolo about 13 years ago
- Status changed from Need feedback to Fixed
Fixing the timestamps in already recorded files can not be fixed from our side. So unfortunately those recordings are not usable anymore.
I will close this bug because you state that this issue did not happen recently.