2006-01-15, 18:32 | Link #241 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
Code:
<subtitle start="00:00:26.000" stop="00:00:30.000"> <text>Size : <font size="14">14</font>-<font size="16">16</font>-<font size="20">20</font>-<font size="26">26</font>-<font size="40">40</font>...</text> </subtitle> <subtitle start="00:00:58.000" stop="00:01:01.000"> <karaoke style="MusicLyrics"><k t="500"/><font color="#00AAFF">Multi-colors</font><k t="500"/> and <k t="500"/><font color="#00FFAA">Multi-lines</font><br/><k t="1500"/>Karaokeeeee!!!</karaoke> </subtitle>
__________________
Last edited by TheFluff; 2006-01-15 at 18:51. |
|
2006-01-15, 18:41 | Link #242 |
Aegisub dev
IT Support
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 38
|
Well, with the notorious exception of override tags, ASS/SSA are very easy to parse... I believe that XML just DOESN'T WORK for subtitles. This might be related to my reluctance to write an USF parser/writer into Aegisub.
|
2006-01-15, 19:59 | Link #243 | |
Senior Member
|
Quote:
|
|
2006-01-15, 20:26 | Link #244 | |
tsubasa o sagashite
|
Quote:
|
|
2006-01-16, 04:07 | Link #246 |
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Well fortunately you can just write your main script as SRT and have MP4box convert it. Basic formatting and font setting isn't too hard, but I suppose karaoke would be a bitch (If there was a player/parser that dealt with it correctly now). The only thing I've had an issue with so far in my limited time with TTXT is text positioning.
Again it boils down to lack of tools and general interest why TTXT is a bit of a mystery. Something like a basic SSA/ASS > TTXT conversion would be good if it would transpose such things as basic text positioning, text formatting, fonts etc. I doubt translating SSA/ASS karaoke would be of interest or even work, so I think that's a non issue right now. The main thing is getting to grips with TTXT. This is my TTXT script I used in my MP4 feature test. It displays nicely in GPAC's Osmo4 player, but is slightly off when using MPC's MP4 splitter. I would be inclined to trust GPAC's player more (nothing detrimental to Gabest), but since more people use MPC than Osmo4, I guess whether it looks right in MPC is more important. One thing to note, though I doubt it has much bearing, is that the video is anamorphic, and uses a SAR. Code:
<?xml version="1.0" encoding="UTF-8" ?> <!-- GPAC 3GPP Text Stream --> <TextStream version="1.0"> <TextStreamHeader width="800" height="40" layer="0" translation_x="0" translation_y="390"> <TextSampleDescription horizontalJustification="center" verticalJustification="center" backColor="00 00 00 00" verticalText="no" fillTextRegion="no" continuousKaraoke="no" scroll="None"> <FontTable> <FontTableEntry fontName="Sans-Serif" fontID="1"/> </FontTable> <TextBox top="0" left="0" bottom="0" right="0"/> <Style styles="Italic" fontSize="24" color="EB EB EB FF"/> </TextSampleDescription> </TextStreamHeader> <TextSample sampleTime="00:00:00.000" text=""> </TextSample> <TextSample sampleTime="00:00:12.095" text="'Chan? I feel you.'"> </TextSample> <TextSample sampleTime="00:00:13.347" text=""> </TextSample> <TextSample sampleTime="00:00:14.556" text="'He's coming?'"> </TextSample> <TextSample sampleTime="00:00:15.432" text=""> </TextSample> <TextSample sampleTime="00:00:18.894" text="'Amuro...'"> </TextSample> <TextSample sampleTime="00:00:19.561" text=""> </TextSample> <TextSample sampleTime="00:00:29.196" text="'You must remember the pain you suffered when Lalah was struck down!'"> </TextSample> <TextSample sampleTime="00:00:32.616" text=""> </TextSample> <TextSample sampleTime="00:00:48.298" text="'You're pathetic!'"> </TextSample> <TextSample sampleTime="00:00:49.383" text=""> </TextSample> <TextSample sampleTime="00:00:49.716" text="'Me?!'"> </TextSample> <TextSample sampleTime="00:00:50.300" text=""> </TextSample> <TextSample sampleTime="00:00:52.553" text="'Why won't you realize you're the one wasting your precious talents?!'"> </TextSample> <TextSample sampleTime="00:00:56.348" text=""> </TextSample> <TextSample sampleTime="00:00:58.892" text="'Same with you!'"> </TextSample> <TextSample sampleTime="00:00:59.685" text=""> </TextSample> </TextStream> Now using Haali's splitter (lol) And finally the internal MPC splitter. Oh, and as for blinking text. It's just damn annoying. |
2006-01-16, 04:09 | Link #247 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
I figured there'd be a wikipedia article on it, and I was right. When I say "banned" I was being a bit overly emphatic. Suffice it to say that if your webpage has a lot of "blink" tags, most people consider that in terrible taste.
__________________
|
|
2006-01-16, 19:33 | Link #248 |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
For interested people, I used the -nr parameter in my latest release of Sugar sugar Rune 03.
It might be a good idea for someone to compare with episode 2 (which did not use it). From my experience so far, with a strength of 100-200 there's very little visible difference, but a bitrate savings of up to 2% on a DVD-raw based anime source. For a really noisy source, it had much greater savings, nearly 10%... however it didn't really denoise well, so what would probably happen would be a series of filters before the encode that would already kill most of that noise anyway. In any case, as far as I can tell it looks like free bits to me, so there's no reason not to use it at low levels on all encodes (it doesn't seem to slow down encoding much at all).
__________________
|
2006-01-23, 11:10 | Link #249 |
翻訳家わなびぃ
Fansubber
|
It sounds like CoreAVC won't stay free. Sources 1, 2
TCPMP/CoreAVC combo gave the absolutely lowest system requirements for AVC playback that I've seen, so I was hoping that they'd make a good, viable, free solution to those people with limited resources and want things for free. Afterall, if you don't have money to upgrade your PC, why would you pay for some software just to watch fansubs? If you have money to upgrade, then you can use ffdshow just fine. And also buy R1 DVDs too. |
2006-01-23, 11:38 | Link #250 |
Senior Member
Join Date: Mar 2004
|
I'd pay for it just for the chance to be able to view h264 on my Dell Axim x51v PDA.
One of the reasons I bought it was for the convenience of watching a couple eps when I have downtime on the road - I was able to do this thanks to their program, TCPMP. Just my luck that a month after I buy it people start shifting to H264 releases, which causes my pda to choke. I am hoping that they can optimize coreavc more once they go to a paid model. |
2006-02-02, 09:54 | Link #252 | |
getting in comps' heads
|
Quote:
You can simply do an AVS script of one line: DirectShowSource("Filename.mkv") and open the file with virtualdub to be able to encode h264 -> divx, assuming you can play back h264 on your comp and have a divx/xvid encoder installed too. Yeah, old model, but still has a 400mhz proc and 64mb ram, plays back video at perfectly decent quality imho. Yeah, h264 would be better quality, but considering many low end desktops have trouble with it, playback on a pda seems a little out of reach. |
|
2006-02-05, 06:46 | Link #253 |
Junior Member
Join Date: Feb 2006
|
I thought PDAs and other portable media devices (e.g. PSP) were the main reason for using H.264 in the first place since hardware acceleration solves some of those performance problems.
On the desktop, the codec changes so often that a video encoded with today's version won't work on one from a week ago. I mean, I don't fear change. Hell, I upgrade all the software on my Linux desktop about once a month. But change more than once a month just to keep up with the changing face of a single format is a bit much to bear. And those of us who were previously using an Xbox to watch our anime are now stuck between a rock and a hard place. Playback even in cutting edge versions of XBMC is too choppy to be enjoyable, and the only road out is upgrading to a faster or different video playing device. Oh yes, and don't forget that only an extremely tiny number of digital video players can even play H.264 in the first place. What I think would float, and what would satisfy most people... is a site which takes all the H.264 encodes and transcodes them to XviD. Then you have the best of both worlds. Fansubbers who like H.264 don't have to listen to complaints about it and can happily sub only in H.264. And fans who don't like H.264 wouldn't then have to deal with it. Or at least we'd have something to do in the interim until the codecs get more stable. |
2006-02-05, 07:04 | Link #254 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
Since custum quants were added back in August or so, all improvements to x264 have been in the encoding algorithm itself, i.e. require no change in the decoders. Options like --nr or --no_fast_pskip or --bime --mixed refs... those are all options that modify how the encoder encodes the video, but do not require any further functionality on the part of the decoder.
__________________
|
|
2006-02-05, 07:25 | Link #255 | |
Junior Member
Join Date: Feb 2006
|
Quote:
I said: "the codec changes so often that a video encoded with today's version won't work on one from a week ago." These new options are exactly what cause the problem. As soon as someone encodes a video using a new feature of the codec, the rest of us all have to upgrade our software. It's not that the new features don't require me to update, because I've found in the recent months that I actually do have to update. I admit, this wouldn't be too big a problem at all if codecs all used the same codebase and all had the ability to auto-update. But the reality is that most if not all media players still require you to manually update their codecs from time to time. Certainly on the Xbox, whenever I have to update it, it's a half hour job to get the new versions of XBMC, update my config so that it works on the new version and upload the whole thing to the Xbox. I think a standalone web site which does all the gruntwork of converting H.264 to more mature formats would actually be a good idea, and would stop a lot of the bickering which is bound to ensue as more and more groups catch onto H.264. If nothing else, it takes a lot of the sting off people using non-upgradeable video players. I've heard many opinions voiced here and elsewhere that "anyone with a 900MHz CPU should be able to upgrade to H.264." Well, my Xbox ain't being upgraded without some kind of overclocking and liquid cooling. ;-) Last edited by Trejkaz; 2006-02-05 at 07:45. |
|
2006-02-05, 08:29 | Link #256 | |
Gendo died for your sins.
Fansubber
Join Date: Dec 2005
|
h264 plays on the Xbox just fine. I'm pretty sure it can just about decode ~400p (when I say that, I mean widescreen, so 640x480 would probably work fine [I'm not an expert]), maybe a bit more. I've seen plenty of h264 encodes on Usenet that are specifically designed to be Xbox compatible.
EDIT: Here's an example' Quote:
Now, a question for those who do keep up with xbox modding/playback etc... can CoreAVC be used as a decoder on the xbox, and if it can, what are the results? |
|
2006-02-05, 08:43 | Link #257 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
Options like --bime or --mixed refs do not use any new codec "features"... they essentially increase the amount of searching the codec does in the video to determine the optimal compression. It's like the difference between the search precision settings on xvid... changing them doesn't change the playback compatability. Like I said, no options have been added that would make YOU have to change your decoding software since about august. An august ffdshow build could play back encodes done today, with the latest x264. If you've had compatabilty problems, it's most likey has nothing to do with h264 at all... it's probably more likey an mp4 muxing issue, which is changing a bit lately. However even in that case, it's not because standards are changing, it's because programs like vlc had bugs that are only now being fixed.
__________________
|
|
2006-02-05, 09:17 | Link #258 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
What Quarkboy said. The MPEG specifications say nothing about how an encoder is supposed to behave (even if there is a reference encoder), they only specify what the resulting bitstream should look like. Hence, as long as the both the decoder and the encoder are fully MPEG4 Part 10-compliant, it won't matter which versions of them are used. The problem is that not all decoders/encoders implement the full AVC spec, or even do it correctly... On the encoding side, the only thing that x264 doesn't do yet is interlaced encoding, AFAIK (and noone uses that anyway). On the decoding side, it's pretty much the same with libavcodec (which is what XBMC and mplayer and ffdshow and about everything else open source uses for decoding) - the only unsupported feature is interlaced decoding (again, to the extent of my knowledge - I haven't looked at it much recently so I might remember wrong).
@Eeknay: That's interesting, but... no CABAC and no inloop deblocking? Ugh. 5.1 LC-AAC at that bitrate isn't likely to sound very nice, either... XviD+AC3 is probably a better alternative for quality with those limitations...
__________________
|
2006-02-05, 09:35 | Link #259 |
It's bacon!
Join Date: Nov 2003
Location: Up and to the Left
Age: 43
|
H.264
Take note that with TCPMP/CoreAVC, with some of the Arienai H.264 encodes for example, I've seen decoding processor usage on an Celeron 2.2GHz drop from ~85% /peak 100% (ffdshow), down to ~20% /peak 45% (TCPMP/CoreAVC). Generally meaning that with time given, there is the potential that you'll see with an lot of builds, whatever codec in this case, reach decoding speeds probably many times faster than what they are at now. ...at least in theory to that TCPMP/CoreAVC has shown such decoding speeds possible.
|
2006-02-05, 10:16 | Link #260 | |
Senior Member
|
Quote:
|
|
|
|