No subject

storage devices as well. I wonder if anyone has tried setting up that
directory structure on a USB stick and dropping in a straight-from-broadcast
mpeg2 ts file (with the right stream types). The TV must be able to handle
mpeg2 ts without the time code bytes or it wouldn't be able to handle
broadcast streams. Of course it's possible that the tuner is doing some
manipulation before the main mpeg2 decoder sees the stream - stuff that the
DNLA/AVCHD bits don't do.

Cheers,
Steve

--0016e640d3fec3a769047a48209c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Dec 9, 2009 at 9:08 PM, Stephen Worthing=
ton <span dir=3D"ltr">&lt;<a href=3D"mailto:stephen_agent at jsw.gen.nz">steph=
en_agent at jsw.gen.nz</a>&gt;</span> wrote:<br><blockquote style=3D"border-le=
ft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: =
1ex;" class=3D"gmail_quote">
Now that I know more about transport streams, I think you are right.<br>
In order to store the streams MythTV is receiving, all it needs to do<br>
is to create new header packets referencing just the streams it wants<br>
and then copy only the packets with the PIDs referenced in those new<br>
headers. =A0Plus a few other packets that provide time/sync referencing.<br=
></blockquote><br>Actually it doesn&#39;t even have to do that. The &quot;h=
eader packets&quot; (PAT/PMT) are already there and can be dumped out as th=
ey are found. Since mpeg2 ts is designed for streaming those packets are re=
plicated periodically through the file, i.e. it doesn&#39;t matter what ord=
er they appear or anything like that and the only references/pointers are P=
IDs so nothing needs fixing when you strip unrelated streams out. The time =
sync stuff is in the PES streams themselves. All MythTV does is find the PM=
T so it knows which PIDs are related to the program (in mpeg-spec-speak, i.=
e. channel), and then just tell the driver to filter the stream for those P=
IDs. MPEG2 TS Packet Analyser on the file I mentioned before to get the lis=
t of PIDs in the file gives:<br>
PID - count - description<br>0 - 32629 - PAT<br>274 - 34958 - PMT<br>520 - =
8645718 - video<br>658 - 446727 - audio<br>1001 - 567669 - I&#39;m pretty s=
ure this is MHEG (I know there is MHEG data in the file and this is the onl=
y unaccounted for stream!)<br>
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></d=
iv></div>
The basic difference in the AVCHD format is only the 192 byte packets<br>
with extra time reference information in the 4 extra bytes. =A0All the<br>
rest of the AVCHD format for transport streams seems to be just<br>
restrictions on what you can put in them, such as only AC3 or PCM<br>
audio. </blockquote><div><br>From what I gather from Wikipedia AVCHD seems =
to specify a file layout for storage devices as well. I wonder if anyone ha=
s tried setting up that directory structure on a USB stick and dropping in =
a straight-from-broadcast mpeg2 ts file (with the right stream types). The =
TV must be able to handle mpeg2 ts without the time code bytes or it wouldn=
&#39;t be able to handle broadcast streams. Of course it&#39;s possible tha=
t the tuner is doing some manipulation before the main mpeg2 decoder sees t=
he stream - stuff that the DNLA/AVCHD bits don&#39;t do.<br>
<br>Cheers,<br>Steve<br></div></div><br>

--0016e640d3fec3a769047a48209c--