[mythtv] anyone with mythtranscode issues, please read

[Paul Koster]

From: "Geoffrey Hausheer" <mythtv0368 at phracturedblue.com>

congrats :)

> As I have no interest in reading a whole months worth of mailing list
> postings, I'll just say that if you have had any mythtranscode issues
> that have not been resolved in the past month or so, and you'd like me to
> look into it, I'd recommend reiterating your problems either to this
> list, or in a personal mail to me.

I'll give a summary of two messages which I've posted before and can be
found here:
http://www.gossamer-threads.com/archive/MythTV_C2/Dev_F10/mythtranscode_MPEG2-%3EMPEG2__issues_P107556/

I included a patch to fix handling command line arguments. It fixes wrong
offsets in argc etc. and also adds a delete() for a corresponding new().

I also worked on other parts of mythtranscode, mainly the muxing, but that
hasn't lead to good results. So the problems I repeat below are still valid.

I did a number of tests transcoding a number of recordings without
cutlists and one transcoding with cutlist. The results:
- 4 files completed the transcoding without any problems (for details see
below)
- 1 file failed the transcoding because it encountered a block type of 0xba
indicating a pack header
- 2 files failed the transcoding because mythtranscode encountered a block
type of 0xf4 (I've not been able to find out what kind of object this is.
Something must be wrong in the input stream or in the demuxing, I could not
find it in the mpeg spec.)

For one of the files that completed the initial transcoding successfullly I
repeated it with a cutlist (cutting of the end of a show) and tested the
resulting file in a number of players:
- it seems that the cutlist works okay, except that the last (few) frame(s)
are still in there just at the end of the resulting file (this should be an
easy fix)
- the resulting file plays okay in the internal MythTV 'watch recording'
option without noticable problems
- the resulting file suffers from many artifacts at certain points
(unrelated to the cutpoints ) when playing in Windows Media Player with the
Elegard MPEG2 decoder (compared to the original)
- the resulting file suffers from minor artifacts at certain points
(unrelated to the cutpoints ) when playing in PowerDVD (compared to the
original)

For the 3 files that failed processing:
- the loop in mythtrans.cpp can't handle unknown object types and will get
into an endless loop because it does not increase framelen, etc.
- I tried to include support for type 0xba, but it seems that just skipping
12 (or 16?) bytes in the stream does not solve the problem as I've seen in
comparable demuxers.
- should program streams work or is it just luck that they worked and is the
current code still aimed at transport streams (as mentioned somewhere in a
very old thread)?

All recordings were made with my PVR 250 ivtv 0.19 576x576 MPEG2 Program
Stream 5000 kbps video, 384 kbps audio (mp2). To do the transcoding I used
mythtranscode -i filename.nuv .

After the initial testing above I dived into the code itself to see what
happened, especially with the artifacts introduced with the transcoded
stream (even without cutlists!):
- the muxer throws away the first audio frames
- the muxer drops the last video frames
- mythtranscode does the above again and again with as results that files
get smaller and smaller (it's not too hard to fix this actually), also
artifacts increase. Actually I think we should not throw away data too
easily, but only when there's only audio or video at a certain time).
- the way audio and video are muxed is completely unclear to me. I'd expect
that muxing is done using dts values, but these are not taken into account.
- generated streams cannot be processed again, because one of the errors
above occurs (or running out of buffers for example)
- some more that I do not remember by heart
Most of the problems seem to relate to the muxing and related buffering in
mythtranscode. If I've understood the code well, libavformat only writes the
packets and sets some header values but is not responsible for muxing.
Should we rely on a good library to do the muxing, including taking care of
the mpeg buffer model? (Somebody replied to my email in above link to
suggest the use of such a multiplexer.)

--
Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmdlineargs.patch
Type: application/octet-stream
Size: 4266 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20040308/9d8dcac6/cmdlineargs.obj