Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
3rd September 2009, 00:27 | #542 | Link | |
Programmer (or just 教务长)
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,251
|
Thank you!
Quote:
|
|
3rd September 2009, 00:39 | #543 | Link |
Registered User
Join Date: Dec 2007
Posts: 215
|
@0xdeadbeef: I have another IFO/SUP (dvd) that doesn't work w/ the latest version (3.9.6). DVDSubEdit opens it and shows the subs. BDSup2Sub opens it and gives a "buffer offset error" when "seeking" to another frame. Will send it over PM.
|
6th September 2009, 21:09 | #544 | Link |
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
@deank:
I answered in your forum. In a nutshell: the IDX files in these samples are broken in several ways and I don't feel like adding workarounds for this. @avivahl: Ok, I analyzed that sample and I guess the problem is that in some of the frames, the odd lines are located first in the RLE buffer instead of 2nd as usual. Admittedly, BDSup2Sub currently can't cope with that inverted field order. It should be easy to add a workaround though. Hope to fix this within the next few days. I'm just too tired to do it right now and dunno if I will have time tomorrow. Last edited by 0xdeadbeef; 6th September 2009 at 22:54. |
9th September 2009, 19:57 | #548 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
Could you add support for none standard resolutions? (sup -> sub/IDX) For example 1920x800. It would be great if we could crop top margin.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
9th September 2009, 20:38 | #550 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
Quote:
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 9th September 2009 at 20:40. |
|
10th September 2009, 13:11 | #552 | Link |
Registered User
Join Date: Apr 2009
Posts: 102
|
Could you add support for two Graphics in a single Event for BDN XML input? This would be quite useful for animated subtitles, since with big images the Presentation Graphics buffer can overflow. Using two smaller images, which still cover the subtitles, avoids this.
References: http://forum.doom9.org/showpost.php?...2&postcount=81 http://forum.doom9.org/showpost.php?...9&postcount=91 Example: Code:
<?xml version="1.0" encoding="UTF-8"?> <BDN Version="0.93" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="BD-03-006-0093b BDN File Format.xsd"> <Description> <Name Title="Undefined" Content=""/> <Language Code="und"/> <Format VideoFormat="720p" FrameRate="23.976" DropFrame="false"/> <Events LastEventOutTC="00:00:53:19" FirstEventInTC="00:00:53:16" ContentInTC="00:00:00:00" ContentOutTC="00:01:02:12" NumberofEvents="3" Type="Graphic"/> </Description> <Events> <Event Forced="False" InTC="00:00:53:16" OutTC="00:00:53:17"> <Graphic Width="456" Height="75" X="139" Y="621">00001288_0.png</Graphic> <Graphic Width="405" Height="167" X="759" Y="176">00001288_1.png</Graphic> </Event> <Event Forced="False" InTC="00:00:53:17" OutTC="00:00:53:18"> <Graphic Width="456" Height="75" X="139" Y="621">00001289_0.png</Graphic> <Graphic Width="404" Height="167" X="759" Y="176">00001289_1.png</Graphic> </Event> <Event Forced="False" InTC="00:00:53:18" OutTC="00:00:53:19"> <Graphic Width="456" Height="75" X="139" Y="621">00001290_0.png</Graphic> <Graphic Width="404" Height="167" X="759" Y="176">00001290_1.png</Graphic> </Event> </Events> </BDN> |
10th September 2009, 19:17 | #553 | Link | ||
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Quote:
No! Long answer: I could add support for multiple pictures per frame to the BDN import, but internally, there will be (most probably) always only one picture due to the nature of the internal representation, to allow export to any other format and to not mess with the move/crop features. So when converting from XML to XML or whatever, all pictures of one frame will be merged to one. Besides, implementation for PNGs using an 8bit palette would be a little tricky and "keep palette" would be impossible for different palettes. Quote:
IMHO the wish for having two composition object per frame is based on wrong assumptions and the way I could implement it without breaking the whole program would create the very same BD-SUP stream. |
||
10th September 2009, 19:34 | #554 | Link | |
Registered User
Join Date: Apr 2009
Posts: 102
|
Quote:
(Wait, looking at it, it is not the PGS buffer, that overflows, but the Decoded Object buffer, sorry.) Last edited by ps auxw; 10th September 2009 at 19:42. |
|
10th September 2009, 19:47 | #556 | Link |
Registered User
Join Date: Apr 2009
Posts: 102
|
Maybe you have another way to explain that:
Since automatic splitting requires some ugly calculations, I'd be glad to get rid of it again, so another way to solve the problem would be more than welcome. |
10th September 2009, 22:21 | #557 | Link |
Registered User
Join Date: Jun 2008
Location: Kiev, Ukraine
Posts: 92
|
OK, can you help me? I got colorful and beautiful subs (xml+png). BDSup2Sub perfectly eats them. I can accept a little loss of quality in my subs. So, what settings do I need to set in your program to produce Blu-Ray standard compatible subs? I do something wrong and I receive flickering on big objects - especially from 00001288_0.png to 00001483_0.png
Here is a xml+png subtitles pack. http://rapidshare.com/files/278292300/Valkyria.zip.html Sorry for my English Last edited by Oleg Rode; 10th September 2009 at 22:42. |
11th September 2009, 00:25 | #558 | Link |
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Firstly, you should rethink the idea of "Blu-Ray standard compatible" (in bold print!) subtitles. It's the authoring tool that is responsible for creating BD compliant streams in the end and only the authoring tool can e.g. guarantee bandwidth limits.
Unfortunately, since some muddlehead decided to leave all the DTS/PTS info from the original multiplexed stream in the SUP files, instead of invalidating or removing it as its the case for HD-DVD and DVD subtitle formats, current free multiplexers seem to assume that the information in the SUP is always valid. Which is a bold assumption to say the least. This makes the BD-SUP (PGS) format an even more complex beast since in addition to the PGS bells and whistles, it also contains an awful amount of DTS and PTS time stamps which have to consider how long decoding of a composition object takes or how long it takes to render an object. While BDSUp2Sub tries to calculate all of these time stamps to my best knowledge, there is absolutely no checking done if e.g. the created PGS stream hits the bandwidth limits of a Blu-Ray or if there are too many frames to be rendered in a too short amount of time for the graphics processor of a standalone. I must admit that I somewhat doubt this is the case, but then again if you want to display a new 256 color near fullscreen picture every frame, chances are it is. Apart from this, BDSup2Sub was created to convert typical simple subtitles, not to create fancy animations. It creates the most primitive type of epoch, but doesn't make any use of more advanced PGS features as palette and cropping animations, multiple windows or multiple composition objects per window. All of these features are of course also used to save bandwidth and distribute it more efficiently. Anyway, chances are that the flickering you observe is caused by simpler causes. E.g. time gaps of a frame due to rounding errors when converting from/to the weird BDN time format. Yet it's also possible that the simple epoch format used by BDSup2Sub (and any other free tool creating BD-SUP format AFAIK) is just not the correct choice for animated subtitles. Which brings us back to the original request: as far as I can tell, the only benefit of two composition objects per epoch would be a slightly reduced decoding and rendering time. Since these times are typically pretty short, this could only lead to problems if you're really pushing the PGS format to its limits by e.g. using large palettes and updating images at very high frequency. E.g. the pixel decoding rate is 128e6 bit/s or 16 Million pixels per second. At 24p, this means that 667334 8bit pixels can be decoded per frame (if I didn't make any dumb calculation error). Unfortunately, this is quite a simplification though since also clearing of the screen buffer etc. has to be taken into account. Anyway, even if saving a little bit of time would really help in some cases, it surely wouldn't fix the issue itself. [EDIT] Ok, I had a look at the sample. The problem is most probably really the combination of fading and large images. Firstly, fading in/out is not supposed to be done this way in any subtitle format since this cost too much bandwidth and needs too many updates in a too short amount of time for the graphics processor. Instead only the palette should be updated. However AFAIK there is currently no free tool chain available that will create BD-SUPs with palette animations. Also it would be very difficult to reverse engineer a palette fade from analyzing images, especially if they are truecolor ARGB images. Instead the fade would have to be defined in the XML format (e.g. alpha start value, alpha end value, fade period). Yet I dunno if there are even keywords defined for this. Splitting the image into two composition objects would maybe really help in this case, yet the main problem is this brute force fading approach. Last edited by 0xdeadbeef; 11th September 2009 at 01:07. |
11th September 2009, 14:10 | #559 | Link | |
Programmer (or just 教务长)
Join Date: Oct 2008
Location: Valencia, Spain
Posts: 4,251
|
I posted a week ago in easySUP's thread, but I'll repost here again:
Quote:
|
|
11th September 2009, 16:42 | #560 | Link |
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Well, maybe there is no problem at all, but theoretically speaking: a software player running even at a not so fast PC will never have problems to render some subtitles in time. On a standalone things might look different.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|