headers
Bjorn Stahl | 1 Jul 2002 04:13
Picon

Re: SVCD subtitles ?

> so, no compression (RLE, etc) at all?
nope, just raw =)
(Perhaps there are ways of using compression aswell, there are still a few bits in the option byte that
are unknown)

> do you have sample files using this format?
> is someone interested in implementing this kind of sub support?
I've got some source if anyone is interested (both for extracting and encoding, just drop a mail. I just
have to make it a bit more readable first :-)
and subs generated from them did work and display on a kiss 1502 DVD player.

> maybe we should intorudece subtitle en/decoders... just like audio/video
> codecs. it seems that there are many of them:
> - ascii subs (10+ formats)
> - spu (dvd subs)
> - svcd subs
> - cvd subs
> - closed captions (text subs used on old DVDs, they are in the mpeg ES video
> streams - xine supports them)
that would IMO be a smart move though there are a few issues to be resolved if 
we want to go all the way implementing some formats .
(SSA http://www.eswat.demon.co.uk/substation.html for instance is heavily used
and quite complex with tons of effects and features)

> > The subs you get from tools like "I-author" are not real SVCD subtitles, they are CVD sub and I 
> > don't know anything else about them except for that they look similar to dvd subs but the RLE en
> > coding and command format is different.
> hmm. shouldn't be too hard to RE it, but the question: does it worth at all?

well, as a whole SVCD subtitles shouldn't exactly be top priority, I've seen very few "legitimate" SVCDs
(Continue reading)

Permalink | Reply | 0 comments |
headers
D Richard Felker III | 1 Jul 2002 02:35

Re: Re: encoding to huffyuv

On Mon, Jul 01, 2002 at 12:12:53AM +0200, Arpi wrote:
> > P.S. Please word wrap your emails. It's a lot of work reading them
> > (much less trying to quote them legibly) when they extend for 10 pages
> > horizontally.
> I've already implemented word wrapping (at reading) into my MUA, it works
> fine, except that it wordwraps inline patches too :(

Is there any chance you could hack the list software to just
auto-reject all mails with ultralong lines and send an automated error
message to the sender explaining that they need to fix their mailer?
That would probably get rid of lots of the lamer-mail on -users too.
:)

Rich
Permalink | Reply | 3 comments |
headers
Samuel Liddicott | 1 Jul 2002 09:24

Re: Re: Architect: follow mode

Arpi wrote:
> Hi,
>
>>> Afaik that was implemented a few weeks ago already.
> yes
>
>> Hmm, doesn't work for me; if I start mplayer with -dumpstream on an
>> asf
> ah
> i've fixed it for avi
> i didn't know that prob exists for asf too

It does as of CVS this morning.  Given that the problem is not supposed to
exist perhaps the problem is not to do with ftell() and observed length as I
was speculating but faking asf headers and such?  Perhaps it is only broken
on streaming (not 0 based time stamps) asf files.

Do you want a full bug report filed, or would that count as harrassment?

Sam
Permalink | Reply | 0 comments |
headers
Samuel Liddicott | 1 Jul 2002 14:30

Re: BUG report: Stuck wma->mpeg1 conversion with mencoder using cvs as of 10 minutes ago

I've uploaded this to MPlayer/incoming as:
mencodempeg.txt
mencodempeg.asf

Sam

Sam Liddicott wrote:
> Full system details at the end of this report
> 
> I have a section of a live wma8 stream which causes mencoder to get
> stuck at 100% cpu usage when converting to mpeg1video
> 
> I discovered this tracking down why http://www.byutv.org/byutv250.asx
> kept hanging when playing to dxr3
> 
> I recorded to disk and extracted a sample bad clip 2MB using
> mencoder -ovc copy -oac copy -endpos ......
> this bad clip is available at http://www.liddicott.com/bad2.asf
> 
> If you try and convert to mpeg1 (as happens when playing to dxr3)
> with: mencoder -ovc lavc -lavcopts vcodec=mpeg1video -o bb.avi
> bad2.asf 
> 
> Then after a while it stops outputting and "top" shows 100% cpu on
> mencoder 
> 
> It is worth noting that this wma8 stream is new-ish and has 0 length
> frames (mplayer was recently patched for this) and may well have
> other strange and new things in it.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Liddicott | 1 Jul 2002 14:42

Re: Architect: follow mode

D Richard Felker III wrote:
> On Sat, Jun 29, 2002 at 02:31:49PM +0100, Sam Liddicott wrote:
>>> The number 1000000000 isn't special; it just needs to be larger than
>>> the number of bytes already downloaded.
>>> 
>> Hmm; I don't know what your command line was trying to acheive; if
> 
> Thats because you didn't make it clear what you were trying to
> achieve.

Ah

> Read Arpi's response, he answers your question I think.

I think he was saying it ought to work.

Sam
Permalink | Reply | 0 comments |
headers
Samuel Liddicott | 1 Jul 2002 15:00

Re: Re: encoding to huffyuv

D Richard Felker III wrote:
> Is there any chance you could hack the list software to just
> auto-reject all mails with ultralong lines and send an automated error
> message to the sender explaining that they need to fix their mailer?

Might also trigger on inline patches

> That would probably get rid of lots of the lamer-mail on -users too.
> :-)

Well, there is perl Text::Format as well...
May as well make machines work for their living by filling in the ugly gaps
in users faces/(faeces)?.

Can the code below be plugged into the mailing lsit?

use Text::Format;

$format=new Text::Format;
$format->columns(72);
$text=$format->format($text);

Sam
Permalink | Reply | 2 comments |
headers
Samuel Liddicott | 1 Jul 2002 15:04

Re: Re: encoding to huffyuv

Samuel Liddicott wrote:
> D Richard Felker III wrote:
>> Is there any chance you could hack the list software to just
>> auto-reject all mails with ultralong lines and send an automated
>> error message to the sender explaining that they need to fix their
>> mailer? 
> 
> Might also trigger on inline patches
> 
>> That would probably get rid of lots of the lamer-mail on -users too.
>> :-)
> 
> Well, there is perl Text::Format as well...
> May as well make machines work for their living by filling in the
> ugly gaps in users faces/(faeces)?.
> 
> Can the code below be plugged into the mailing lsit?

doh!  Might also trigger on inline patches! <shakes head sadly at self>

Sam
Permalink | Reply | 0 comments |
headers
D Richard Felker III | 1 Jul 2002 15:49

Re: Re: encoding to huffyuv

On Mon, Jul 01, 2002 at 02:00:44PM +0100, Samuel Liddicott wrote:
> D Richard Felker III wrote:
> > Is there any chance you could hack the list software to just
> > auto-reject all mails with ultralong lines and send an automated error
> > message to the sender explaining that they need to fix their mailer?
> 
> Might also trigger on inline patches

IMO it'd be safe to reject email with NO lines or just 1 or 2 lines
meeting the 80 char max. And it should be 80, not 72, to allow for
quoting.

> > That would probably get rid of lots of the lamer-mail on -users too.
> > :-)
> 
> Well, there is perl Text::Format as well...
> May as well make machines work for their living by filling in the ugly gaps
> in users faces/(faeces)?.
> 
> Can the code below be plugged into the mailing lsit?
> 
> use Text::Format;
> 
> $format=new Text::Format;
> $format->columns(72);
> $text=$format->format($text);

I would think that could have quite a few unwanted side effects. IMO
it's better to teach users to follow internet standards by rejecting
broken mail rather than trying to fix it for them.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Lampe | 1 Jul 2002 17:41
Picon

[PATCH] qtrle decoder can read beyond end of input buffer

Hi!

--- qtrle.c-old Mon Jul  1 17:17:41 2002
+++ qtrle.c     Mon Jul  1 17:17:41 2002
 <at>  <at>  -61,7 +61,8  <at>  <at> 
    {
      pixel_ptr = row_ptr + ((encoded[stream_ptr++] - 1) * bytes_per_pixel);

-    while ((rle_code = (signed char)encoded[stream_ptr++]) != -1)
+    while (stream_ptr < encoded_size &&
+           (rle_code = (signed char)encoded[stream_ptr++]) != -1)
      {
        if (rle_code == 0)
          // there's another skip code in the stream

See http://cox.iwr.uni-heidelberg.de/~ug/films/stefan.mov for a file 
demonstrating the bug.

-Michael
Attachment (qtrle-patch): application/x-java-vm, 439 bytes
Permalink | Reply | 0 comments |
headers
Jonas Jermann | 1 Jul 2002 18:37
Picon
Gravatar

Re: [PATCH] manpage update?

Hi

On Sat, Jun 29, 2002 at 03:37:16PM +0200, Arpi wrote:
> >     - tried to simplify/improve -npp, [as]lang/[as]id,
> >       ao and more descriptions
> please also add note that -alang/-slang works only for DVD playback, from
> DVD device (already grabbed .vob file playback won't!) - so only with -dvd
> title or dvd://title
> 
> (it gets language info from the device)
ok

> >     - added and removed some GUI keyboard controls
> 
> about keys:
> 
> +s               take screenshot
> it's nonexistant, was removes some time ago from libvo
> 
> +m               mute sound
> it was master/pcm switch, not mute, and also removed some time ago 

hmm... I just trusted input.c, mplayer.c and some mails about it:
  { { 'm', 0 }, "mute" },
  { { 's', 0 }, "screenshot" },
But probably those and other entries are just there for a
future screenshot implementation, donno...

> there was mention of -afm help, there is no such option
> -afm expects integer number now
(Continue reading)

Permalink | Reply | 2 comments |

Gmane