Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#581 closed defect (fixed)

matroskadec errors on blocks with zero data

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

Description

When the lacing mode is "no lacing", it is valid to have an empty block. Some subtitle tracks end up with these for some reason. The attached patch corrects this issue.

Attachments (1)

0001-matroskadec-Zero-length-in-the-no-lacing-case-is-val.patch (1.5 KB) - added by crwulff 5 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 5 years ago by cehoyos

  • Keywords mkv added; matroskadec removed

Do you have a sample?

comment:2 Changed 5 years ago by crwulff

I don't have an easy way to snip out the portion of the video that is causing problems it was muxed with a fairly old version of mkvmerge (and is over 4 gig). Slicing the clip with the current version of mkvmerge strips out the zero length blocks (they really aren't very useful.) Here's a couple segments from the mkvinfo dump. I can try to go build the referenced version of mkvmerge & libs if you really need a sample, but I don't know how involved that is going to be.

+ EBML head
|+ Doc type: matroska
|+ Doc type version: 1
|+ Doc type read version: 1
+ Segment, size 4685769202
|+ Seek head (subentries will be skipped)
|+ EbmlVoid? (size: 4025)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v0.7.7 + libmatroska v0.8.1
| + Writing application: mkvmerge v2.1.0 ('Another Place To Fall') built on Aug 19 2007 13:40:07
| + Duration: 6593.045s (01:49:53.045)
| + Date: Tue Dec 25 21:37:57 2007 UTC
| + Segment UID: 0xb2 0x9f 0xec 0xff 0x0e 0xf5 0xa6 0xf4 0x84 0xca 0xbb 0xd2 0x9c 0x09 0x89 0x68
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 0
| + MinCache?: 1
| + Timecode scale: 1
| + Max BlockAddition? ID: 0
| + Codec ID: V_MPEG4/ISO/AVC
| + Codec decode all: 1
| + CodecPrivate?, length 39 (h.264 profile: High @L5.1) hexdump 01 64 00 33 ff e1 00 18 67 64 00 33 ac 34 e2 c0
| + Default duration: 41.708ms (23.976 fps for a video track)
| + Language: eng
| + Video track
| + Pixel width: 1280
| + Pixel height: 720
| + Interlaced: 0
| + Display width: 16
| + Display height: 9
| + A track
| + Track number: 2
| + Track UID: 973961
| + Track type: audio
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 1
| + MinCache?: 0
| + Timecode scale: 1
| + Max BlockAddition? ID: 0
| + Codec ID: A_AC3
| + Codec decode all: 1
| + Default duration: 32.000ms (31.250 fps for a video track)
| + Language: eng
| + Audio track
| + Sampling frequency: 48000
| + Channels: 6
| + A track
| + Track number: 3
| + Track UID: 49478588
| + Track type: subtitles
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 0
| + MinCache?: 0

| + Timecode scale: 1
| + Max BlockAddition? ID: 0
| + Codec ID: S_TEXT/UTF8
| + Codec decode all: 1
| + Language: eng
|+ EbmlVoid? (size: 1024)
|+ Cluster

...

| + Block group
| + Block (track number 1, 1 frame(s), timecode 337.337s = 00:05:37.337)
| + Frame with size 16817 hexdump 00 00 41 ad 41 9a 5b 50 27 21 5f ea d5 c3 59 16
| + Reference block: -83.000000ms
| + Block group
| + Block (track number 3, 1 frame(s), timecode 337.337s = 00:05:37.337)
| + Frame with size 24 hexdump c2 b6 20 53 55 43 48 20 41 20 43 4f 4c 44 20 46
| + Block duration: 32.000000ms
| + Block group
| + Block (track number 3, 1 frame(s), timecode 337.370s = 00:05:37.370)
| + Frame with size 0 hexdump <------------- This is the frame that errors
| + Block duration: 3903.000000ms
| + Block group
| + Block (track number 2, 8 frame(s), timecode 337.408s = 00:05:37.408)
| + Frame with size 1536 hexdump 0b 77 eb d0 1c 30 e1 ff e0 ec 92 40 00 03 fe ff
| + Frame with size 1536 hexdump 0b 77 bd 9b 1c 30 e1 ff e0 ec 92 40 00 03 ff 0f
| + Frame with size 1536 hexdump 0b 77 ef aa 1c 30 e1 ff e0 ec 92 40 00 03 ff 0f
| + Frame with size 1536 hexdump 0b 77 4a 2b 1c 30 e1 ff e0 ec 92 40 00 03 ff 0f
| + Frame with size 1536 hexdump 0b 77 dd 00 1c 30 e1 ff dc ec 92 40 00 03 fe ff
| + Frame with size 1536 hexdump 0b 77 26 40 1c 30 e1 ff dc ec 92 40 00 03 fe ff
| + Frame with size 1536 hexdump 0b 77 75 6b 1c 30 e1 ff dc ec 92 40 00 03 fe ff
| + Frame with size 1536 hexdump 0b 77 00 f9 1c 30 e1 ff dc ec 92 40 00 03 fe ff

comment:3 follow-up: Changed 5 years ago by cehoyos

A similar patch by Ronald was committed, could you test if your problem is fixed now?

comment:4 in reply to: ↑ 3 Changed 5 years ago by crwulff

Replying to cehoyos:

A similar patch by Ronald was committed, could you test if your problem is fixed now?

Yes, the patch from Ronald does fix the problem for me as well. This ticket can probably be closed.

comment:5 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from new to closed

Thank you for testing!

comment:6 Changed 5 years ago by michael

For the record, i suspect that this change "fixed" it: (not ronalds which was based on hendriks)
commit 8689d87ac61a412b88326c4d31a8f3375926f869
Author: Hendrik Leppkes <h.leppkes@gmail.com>
AuthorDate?: Wed Jul 6 19:57:11 2011 +0200
Commit: Michael Niedermayer <michaelni@gmx.at>
CommitDate?: Sat Oct 29 15:57:26 2011 +0200

and the this caused the bug:
commit 5dd514af937ff4d74c3c263e4ca428b14b62d5f1
Author: Ami Fischman <fischman@chromium.org>
AuthorDate?: Wed Jun 29 13:54:49 2011 -0700
Commit: Ronald S. Bultje <rsbultje@gmail.com>
CommitDate?: Wed Jun 29 15:27:55 2011 -0700

Also iam not sure the issue is fully fixed, crwulff, doesnt your patch produce some 0 frame that is lost with the current code ? (i didnt check)

comment:7 Changed 5 years ago by crwulff

I'm not sure that the empty frames actually have any value. The newer matroska tools eliminate those zero length frames if I remux the stream anyway, so I assume they were just an unnecessary artifact that older versions didn't get rid of.

And yes, any patch that returned success and not invalid data would have fixed what I was seeing (handbrake saw that and assumed it was EOF and quietly stopped transcoding.)

Note: See TracTickets for help on using tickets.