[MPlayer-dev-eng] MP-G2 - new mpeg demuxer

[Arpi]

Hi,

> Ok, my fault. Sorry.

btw it's strange, my ts detection code is based on yours, but imho it's even
less restrictive, so it's even more possible to do false detection.
anyway i still doubt that any legal PS/PES stream will have 0x47 at every
188th byte...

> Do you plan to use your new demuxer only in G2 or in mplayer too?

I don't plan anything but it would be a good idea to patch mplayer to be
able to use g2's stream/demuxer layer. Maybe i'll make a modified 0_90
version for tetsing g2 demuxers.

> I read that G2 can detect a stream change; (ES -> P[E]S or viceversa, 
> right)? I'm curious, when does it happen? I've never seen a situation 
> like this.

Yes it's not so common, the only case i've seen is on multi-track VCD with
ES on first track on PS on the second.
The real reason for impelmenting this ability to handle misdetections well.
Imagine a badly cutted ('dd' is not an GOP-accurate mpeg editor :)) PS file,
which looks like PES or ES when you check the first few blocks.
Now my parser starts parsing it, if it begins with ES packets it will be
read as ES (so even broken PS packets will be recovered) but if it sees PS
headers it switch to PS parser until it lost sync and then resync again.
The parser is not optimized for stream type changes but it handls it as a
side-effect :)

Btw i've just finished merging demux_ts into demux_mpeg, so no more
redundant PES parser code. CUrrently it's a 2-in-1 demuxer, but I'm thinking
about moving TS detection into the ES/PS parser's sync loop so it will even
allow TS<->PS/PES<->ES transitions :)

Btw, did you know that the payload size field of the PES header is always
zero in TS streams?


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu