GNOME Bugzilla – Bug 626463
[matroskademux] "reading large block of size 14688496 not supported"
Last modified: 2010-09-06 12:54:08 UTC
I met strange .mkv file which my totem player cant handle. Here it is: http://dl.dropbox.com/u/9476941/%5BGod-Speed%20Subs%5D%20Seitokai%20Yakuindomo%2005%20%5B480p%5D%5B883AF6D6%5D.mkv Here is log which gives totem player: matroska-demux.c(5113): gst_matroska_demux_check_read_size (): /GstPlayBin2:play/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMatroskaDemux:matroskademux0: reading large block of size 14688496 not supported; file might be corrupt. MPlayer plays file correctly.
Same with webm files, not the difference multifilesrc != filesrc here: $ gst-launch multifilesrc location=file ! matroskademux ! fakesink ERROR: del elemento /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: No se pudo demultiplexar el flujo. Información adicional de depuración: matroska-demux.c(5397): gst_matroska_demux_check_read_size (): /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: reading large block of size 236549635 not supported; file might be corrupt. However gst-launch filesrc location=file ! matroskademux ! fakesink is fine.
Created attachment 167482 [details] [review] matroskademux: Allow block sizes up to 50MB instead of 10MB Fixes bug #626463.
(In reply to comment #2) > Created an attachment (id=167482) [details] [review] > matroskademux: Allow block sizes up to 50MB instead of 10MB > > Fixes bug #626463. This should fix it. 10MB blocks are not really too large I guess so let's increase the limit to 50MB... But maybe this check should be completely removed or increased even more... oppinions?
FWIW this patch only fixes the error, the file still doesn't play in totem and stays at 0 seconds.
In this particular case, the chunk in question is Attachment, and that may also be the case for the aforementioned webm case (of size 236549635 = 236M). I would keep the check, and 50M is already a lot, which is unlikely for any blockgroup etc. Any larger blocks are (as it says) likely corruption or something not quite vital. It seems not recommended trying to go for 236M (and maybe all the attachment tags that will ensue) (at least painful for embedded cases). On the other hand, where possible, it should not be considered fatal (and likewise so for other matroskademux error cases). I'll be having a look at that (and also what else is going on here).
(In reply to comment #5) > > On the other hand, where possible, it should not be considered fatal (and > likewise so for other matroskademux error cases). I'll be having a look at > that (and also what else is going on here). regarding the comment #1, have you noted that I use filesrc without error, but using multifilesrc, it does produce the large block error. Thanks for looking at it
(In reply to comment #6) > (In reply to comment #5) > > > > On the other hand, where possible, it should not be considered fatal (and > > likewise so for other matroskademux error cases). I'll be having a look at > > that (and also what else is going on here). > > regarding the comment #1, have you noted that I use filesrc without error, but > using multifilesrc, it does produce the large block error. Thanks for looking > at it That is (most likely) due to multifilesrc making matroskademux operate in push mode, and then it will also complain when it has to skip past large sized blocks, which I believe to make sense and to be fatal (as trying to skip past 236M e.g. http-wise may look more like hanging than anything else).
Following -base commit should finally have this file playing again (with or without subtitles): commit 9fdda29965dc368979251626730b8c9d1bb0da65 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Aug 11 10:27:35 2010 +0200 playbin2/playsink: update subtitle handling for streamsynchronizer Streamsynchronizer excepts to see stream-changed msg for all streams, but to arrange for this, video and subtitle streams need to be decoupled by means of queues (due to pad blocks that may occur). Fixes #626463.
Should I open another bug for `gst-launch multifilesrc location=%d ! matroskademux ! fakesink` error?
One might, but as noted above, I see no (general nice) way of handling/skipping 236M in streaming mode.
What's up with the patch? Should it be committed or not? (does it only apply for pull mode? Not sure if allowing 50MB chunks in push mode makes much sense)
I have some patches (pending) that tune matroskademux' error complaining a bit. In particular, a large block in push mode will be fatal (as is), and will be discarded with some warning in pull mode.
I met more files with same problem. I think patch fixing that bug will be actual.
Created attachment 168079 [details] [review] matroskademux: not so fatal error handling This is pending patch alluded to above that should make matroskademux complain a bit less. In particular, a too large block should be skipped (in pull mode). One might still tweak 10M to a limit that is both reasonable to read and parse in pull mode, and too much to skip in push mode (but 50M definitely seems an upper bound for that, and possibly less).
Comment on attachment 168079 [details] [review] matroskademux: not so fatal error handling Looks good :)
commit 4d9c1e99f208f67bbf10753c8b302ebcc4325e69 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Aug 16 16:05:41 2010 +0200 matroskademux: not so fatal error handling If some bits out of place in block(group) parsing, forego and move to next. Also skip large blocks in pull mode, but need to give up in push mode. Fixes #626463. Improves #620790.