VideoHelp Forum
+ Reply to Thread
Results 1 to 3 of 3
Thread
  1. Hi there.

    I am a complete newbie to DVD authoring, and I am using DVDStyler. I have created it the way I want it, but when I go to make an iso, it fails on the second menu with an error about simplifying a subtitle. I don't actually have any subtitles for the videos, but I did read on someone else's post that a 'subtitle' could also mean text, and if the text is too long it could be a problem. However, I experimented with putting the same text on the first menu, but I made it even longer text, but it still managed to pass the 1st menu, before stopping in the same spot on the 2nd menu again.

    Here is the code that it shows when I try to create the iso.

    On my second menu page, I have buttons for 7 videos (each between 10 and 20 mins long), and I have a 'play all' button and a 'main menu' button, so there are nine buttons total. I also made the titles below each thumbnail a button with the same link to the videos as it's counterpart thumbnail. I wonder if that is just too much information for it to process. Do you think it would work if I made all the text just text rather than buttons?

    I would really aprreciate it if anyone can shed some light on this. Please bear in mind my lack of technical skills, as I might not know some of the terms others are familiar with on this forum. Thank you.

    DVDStyler v3.0.3
    Windows 10 (build 14393), 64-bit edition
    FFmpeg: libavformat 57.46.100, libavcodec 57.51.100, libavutil 55.28.100
    Prepare
    Cleaning temporary directory
    Search for transcoded files in cache
    ================================================== ===========================
    | Input size | Output duration | Bitrate | Estimated output size
    VMGM menu 1 | | | 8.0 MB/s | 0.1 MB
    Menu 1 | | | 8.0 MB/s | 0.1 MB
    Title 1
    mp4 | 173.6 MB | 11:08.478 sec | 5.5 MB/s | 468.4 MB
    Title 2
    mp4 | 578.9 MB | 10:46.379 sec | 5.5 MB/s | 452.9 MB
    Title 3
    mp4 | 231.4 MB | 21:55.526 sec | 5.5 MB/s | 921.8 MB
    Title 4
    mp4 | 927.8 MB | 14:43.849 sec | 5.5 MB/s | 619.3 MB
    Title 5
    mp4 | 228.1 MB | 22:18.909 sec | 5.5 MB/s | 938.2 MB
    Title 6
    mp4 | 575.0 MB | 10:15.448 sec | 5.5 MB/s | 431.2 MB
    Title 7
    mp4 | 980.7 MB | 15:18.784 sec | 5.5 MB/s | 643.8 MB
    Menu 1 | | | 8.0 MB/s | 0.1 MB
    Title 1
    mp4 | 4.2 MB | 0:05.672 sec | 5.5 MB/s | 4.0 MB
    Total | | 1:46:33.047 sec | | 4479.8 MB
    ================================================== ===========================
    Generating menu 1 of 3
    Create menu MPEG
    Frame count of menu: 15
    Multiplexing subpictures into mpeg
    Executing command: spumux -P -s 0 "C:\Users\Owner\Desktop\dvd-tmp\menu0-0.mpg_spumux.xml"
    DVDAuthor:pumux, version 0.7.1.
    Build options: gnugetopt iconv freetype fribidi fontconfig
    Send bug reports to <dvdauthor-users@lists.sourceforge.net>
    INFO: no default video format, must explicitly specify NTSC or PAL
    INFO: PNG had 1 colors
    INFO: PNG had 7 colors
    INFO: PNG had 4 colors
    INFO: Pickbuttongroups, success with 2 groups, useimg=1
    INFO: 0 bytes of data written
    INFO: 36864 bytes of data written
    INFO: 73728 bytes of data written
    INFO: 110592 bytes of data written
    INFO: 147456 bytes of data written
    INFO: Found EOF in .sub file.
    INFO: Max_sub_size=3986
    INFO: 188416 bytes of data written
    INFO: 1 subtitles added, 0 subtitles skipped, stream: 32, offset: 0.53
    Executing command: spumux -P -s 1 "C:\Users\Owner\Desktop\dvd-tmp\menu0-0.mpg_spumux.xml"
    DVDAuthor:pumux, version 0.7.1.
    Build options: gnugetopt iconv freetype fribidi fontconfig
    Send bug reports to <dvdauthor-users@lists.sourceforge.net>
    INFO: no default video format, must explicitly specify NTSC or PAL
    INFO: PNG had 1 colors
    INFO: PNG had 7 colors
    INFO: PNG had 4 colors
    INFO: Pickbuttongroups, success with 2 groups, useimg=1
    INFO: 0 bytes of data written
    INFO: 38912 bytes of data written
    INFO: 77824 bytes of data written
    INFO: 114688 bytes of data written
    INFO: 153600 bytes of data written
    INFO: Found EOF in .sub file.
    INFO: Max_sub_size=3002
    INFO: found existing substream ID 0x20 (DVD-Video 0)
    INFO: 190464 bytes of data written
    INFO: 1 subtitles added, 0 subtitles skipped, stream: 33, offset: 0.53
    Generating menu 2 of 3
    Create menu MPEG
    Frame count of menu: 15
    Multiplexing subpictures into mpeg
    Executing command: spumux -P -s 0 "C:\Users\Owner\Desktop\dvd-tmp\menu1-0.mpg_spumux.xml"
    DVDAuthor:pumux, version 0.7.1.
    Build options: gnugetopt iconv freetype fribidi fontconfig
    Send bug reports to <dvdauthor-users@lists.sourceforge.net>
    INFO: no default video format, must explicitly specify NTSC or PAL
    INFO: PNG had 1 colors
    INFO: PNG had 4 colors
    INFO: PNG had 4 colors
    INFO: Pickbuttongroups, success with 1 groups, useimg=1
    INFO: 0 bytes of data written
    INFO: 40960 bytes of data written
    INFO: 81920 bytes of data written
    INFO: 122880 bytes of data written
    INFO: 163840 bytes of data written
    INFO: Found EOF in .sub file.
    ERR: Encoded row takes more than 1440 bits. Please simplify subtitle.
    Failed
    Quote Quote  
  2. Hi again,

    I'm replying to my own question, lol. I went and changed all the text buttons on my 2nd menu so that they were just text and not buttons linking to the video, and it seems to have worked. It got to the preview stage when I chose to create and iso, but there were a few tweaks I wanted to make so I didn't go ahead. Anyway, hopefully someone else might find my question and answer helpful.
    Quote Quote  
  3. Far too goddamn old now EddyH's Avatar
    Join Date
    Jan 2003
    Location
    Soul sucking suburbia! But a different part since I last logged on.
    Search Comp PM
    Ah, what this would be, is a very technogeeky and somewhat annoying problem you've hit thanks to a strangeness in the DVD subtitle format born of the guys who came up with the standard not bothering to implement an otherwise very simple bit of safety-net coding.

    TLDR version - the subtitle images are compressed using a very simplistic scheme that suffers a crucial inefficiency when encoding very fine detail, where that particular section can gain 50 or 100% bloat per pixel for sections that change every second pixel, or every pixel (every third pixel being 1:1, and anything wider than four pixels still saving space), but the container for it still expects no more data per line than would be used by a non-compressed stream. Given that the standard was designed for displays where 720 pixel resolution was decidedly bleeding-edge, and the overscan area meant you could only really guarantee about 320-pixel-equivalent in terms of detail, this wasn't a big problem at the time (and in general tends to compress a ~500mb data load down by about 100x overall), but can manifest if you want to take advantage of modern narrow-overscan, pin-sharp screens. Unfortunately the only solution is to compromise on subpicture feature complexity and/or width, per-line in the horizontal direction (vertical is unaffected), or reposition vertically aligned elements so their most complex parts appear on mutually exclusive lines. If that affects semitransparent buttons produced by dithering, try using a flat block of a semitransparent (50% alpha) palette colour instead.

    The subtitles overlays on a DVD are essentially full-frame bitmap images (like a .bmp, or .gif, etc), using 4-colour (usually but not always three visible plus transparent, with one of the visible ones being black, hence you either get single-colour slightly smoothed subs with an outline, or two different colours on a blocked-out black background; where there's a reliable hardcoded extra-widescreen letterbox bar you might get three), 2-bit encoding (2 bits give 4 states: 00, 01, 10, 11; similarly 4 bits give the more familiar 16 colours, and so-on). Obviously, with 720 pixels across, that makes 1440 bits (180 bytes) per line, the limit given here, which is a sensible amount to be expected to read on every scanline on top of all the audio, video, and control data, and is in fact almost as much as a typical late-80s 16-bit home computer would have available for its entire video system, so for a late-90s VCR-replacement device it wasn't actually as stingy as it first appears. As it's full progressive resolution also, and is always full D1 resolution regardless of what the video is displayed at, that's 86400 bytes for NTSC and 103680 for PAL... which is why you don't tend to see any kind of subpicture animation, as full 480/30 or 576/25 update rate would consume almost 21mbits all by itself.

    But even those static frames, if updated an average of once per second whilst the subtitles keep rolling, would consume a fair old chunk, more than 800kbit/sec for PAL, which is greater than most audio tracks and about half that of LPCM. So we need to cram it down a bit more.

    I can't remember if the trick of defining the minimum rectangular active / changed area is used (which could reduce the rate massively for typical subtitles, if properly used, but isn't guaranteed to do much for menu screens), but the relevant thing here is compression. As in Zip, GIF, MPG etc. Particularly in this case, lossless RLE (run-length encoding) graphics compression.

    Now, if you consider the typical subpicture setup, you'll see it's not much like the video portion. It tends to be made of fairly regular shapes or letters, and moreover is dominated by single-colour blocks considerably larger than one pixel across, typically in order of (though this isn't super-important) transparent/background, black, primary fill/accent colour (first voice), and secondary colour (smoothing or second voice). Encoding all those big blocks as individual pixels is incredibly wasteful; if instead you could only individually define as few of them as absolutely necessary, and specify all the others as "block of size X, in colour Y", the amount of data required by most subpicture frames could be slashed to a few percent of the original.

    And this, in effect, is exactly what it does, although, as DVD video is still inherently line-based, it only encodes in the horizontal direction, left to right, one line at a time (which also helps avoid accidentally missing anywhere, and excessive microcontroller decoding load, although it's not quite as efficient). I forget the exact scheme used, but I think it allows defining a horizontal "run" of upto 63 pixels in a single 2-bit colour in something like 10 bits, a compression ratio of 12.6x; without even limiting the area in use (to certain lines, or certain rectangles), that cuts our minimum rate in PAL down from 800kbit/s to a much more manageable 63.5kbit/s, or 28 mbytes per hour instead of 360. As an actual ripped subtitle track is more like 5 to 10mb, even though the *useful*, more detailed parts of the image consume additional data as the runs are shorter and more frequent but compress to no more than maybe 4 or 5 bits less, we can assume there's a mixture factors, between active area limitation and the actual rate of change actually being somewhat slower when all the parts with no dialogue or signficiant SFX are considered.

    The most important point of the above for your own issue is that, as per most compression schemes, as the raw data becomes more complex, the size of the encoded data increases. Particularly, as the type of RLE used in DVD subpictures is VERY simplistic, in order to reduce how complex the decoder silicon needed to be, it's surprisingly easy to present it with a run of "useful" pixels that end up considerably larger in encoded form versus the original. IIRC, the pathological case is a line of continually changing pixels which cause it to use the code for "one pixel of colour X", which takes up 4 bits, so it consumes twice the space (2 thru 5 ?? pixels is maybe 6 bits, so the ratio is between 1.5x and 0.6x for other even moderately dense patterns, probably averaging out to 1.0 overall on typical material) - even if it's a run of, say, 10 alternating pixels (5 repeats of 2-pixel dither), which is something a lot of other schemes might handle by identifying the length of that section and encoding "X uncompressed pixels follow", or "repeat color pair YZ, X times" even if they don't do anything more complex, DVD still encodes those all separately. Neither does it do anything smart like acknowledge the usual depth of overscan and give the first pixel of the 720 (which it remains even when a 704 pixel video is shown) over to a simple 2-bit encode of e.g. 00 = normal line, 01 = left normal, right uncompressed, 10 = left uncompressed, right normal, 11 = whole line uncompressed, which would abandon all compression over the marked areas as encoding a full-fat 720 or 1440 bits would still actually be more efficient than trying to compress it (similarly the very last pixel could have allowed more colours per image by selecting from four different palettes for the next line... oh well, it does at least allow a master palette of 16 colours and a free choice of 4 for each SP track (...or each invidividual SP within a track? I forget...)). It just keeps on trucking with the RLE, regardless.

    This is why most on-screen elements you'll see drawn using subtitle / subpicture data is either fairly chunky, effectively rendering it as 360 pixel resolution but with the option of shifting some parts left or right by "half" a pixel (immediately cutting the potential maximum to 150% instead of 200 and making it much easier to sneak in at or below 100% overall), which maintains the illusion of full, smooth resolution by having 720-pixel resolution differences between lines, or even slightly more if the secondary accent colour is used for anti-aliasing (which does cost more data...). It also looks rather better over composite video cables, with less colour aliasing and the like; similarly, horizontal elements will tend to be at least 2 lines high, although still aligned to a 1-line grid (so, 240 or 288 elements but with 480 or 576-line precision), both to match that thickness and to reduce interlace flickering artefacts... or, if it's more intricate, it'll be limited in width, possibly to a little less than half the total scanline (either in one place, or spread out) in order to let the compression catch up with some nice long runs of featurelessnesss. The overscan border helps compensate for that, a bit. In extreme cases there might be a combination of the two (IE no features less than 2 pixels wide, and no more than ~65% of the scanline covered with detail).

    And what you will almost never, ever see is dithering in order to simulate semitransparency - each of the palette colours, as well as having a 24-bit (Y'CrCb) colour, also has 8 bits defined for degree of transparency (again, I forget if that is for the whole disc, per track, or per subpicture...). If you have a button you want to make partly or wholly translucent, you use a blocked-out area with a semitransparent colour that will envelope whatever underlying element needs to be tinted as part of the selection or other action. Only if you're really, really pushed for available colours, and know you can spare the horizontal data load, is it worth using spatial masking instead, seeing as the hardware gives you that "fancy" ability for free.

    So, essentially, you've fallen prey to the temptation to make your subtitles or menu buttons too intricate, with at least one line containing, at a rough estimate, more than about 300-350 colour transitions across its width. Try to make things slightly less detailed in the horizontal direction, or a bit narrower (same thing really, the difference is just in how spread out the information is), replace any dithering (or direct overlay of writing!) with semitransparent block colour if you can, and if you have multiple intricate buttons or pieces of fine-pitched text that are vertically aligned with each other, try to stagger them to reduce how much stuff appears on each scanline. Even if it's only by a little to, e.g. have each line of text in a two-line button actually dovetail with the other one's "whitespace".

    And really, I wish I'd realised about all that waybackwhen, as I've only learned the crucial part of it fairly recently whilst looking for something else. I've probably got some old projects of my own that refused to author correctly - until I had sufficiently jiggered things around at random and spread some out onto different menu pages etc - for the exact same reason.

    (I also wonder if there's any way to mess with the PGC commands so that instead of changing what subpicture from a track is made visible when you move around a menu screen, it actually changes the subpicture *track*... it wouldn't do anything for this particular problem, but it would maybe allow use of more non-simultaneous colours?)
    Last edited by EddyH; 20th Mar 2017 at 11:33. Reason: summarising it all into a single lede paragraph because it got a bit wikipedia to be honest
    -= She sez there's ants in the carpet, dirty little monsters! =-
    Back after a long time away, mainly because I now need to start making up vidcapped DVDRs for work and I haven't a clue where to start any more!
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!