[mythtv] Mythtranscode .mpg => .mpg not .mpg => .nuv

[Cory Papenfuss]

> These aren't really a problem, though I'd certainly use -f on the
> stream at a minimim (or you could use -t, doesn't really make a
> difference).  All the above says is that the expected PTS doesn't
> match what was actualy found (actual on the left, expected on the
> right).  A new frame is inserted whenever actual-expected >
> 0.8*ptsIncrement (this is regardless of what options are used)
>
> If you specify neither -f nor -t, then nothing will be done about the
> above (the PTS will be exactly the same as the original (minus the
> fixed offset)).  Most standalone players will ignore the discrepency,
> and will play at a fixed 29.997 fps anyway.  If you specify either -f
> or -t, the pts will be set to the expected value.  The only thing -t
> (--no3to2) brings to the table is to remove any telecine flags, and
> remove all half-frames (this is just a flag, no data is removed),
> which will result in inserting an additional frame every ~6 frames
> during telecine sections).
>
 	So, essentially this is just a message saying that the PTS doesn't 
match what's expected based on the fps interval?  In order to play it 
"correctly," the player would have to present the frame in mid-otherframe 
if I'm understanding correctly.

> The interesting message would be 'Buiding P-frame' (which is actually
> an I-frame, but whatever) telling you a new frame was being inserted.
>
$ grep -i Building log.txt
Building P-Frame: 15
Building P-Frame: 12
Building P-Frame: 9
Building P-Frame: 6
Building P-Frame: 15
... blah blah... got 22 of them

> In your stream, the delta is varying, so this is just a not very clean
> stream.  but the largest delta I see is ~17.  this is
> 17/90000=0.18ms, you aren't going to notice any lipsync issues with
> that small of an offset.
>
> In the next version, I'll push that message up to a higher debug
> level.  It isn't very useful except when something goes wrong.
>
 	This was at no debug, but I agree.  If it's mostly harmless, then
just another case of too much info being bad... :)  FWIW, around some of 
the actual "Building" lines, I've got some much more serious jumps:
PTS discrepency: 1077926 != 1077915 on B-Type (10)
PTS discrepency: 1080942 != 1080918 on P-Type (11)
PTS discrepency: 1083932 != 1083921 on B-Type (12)
PTS discrepency: 1099504 != 1086924 on B-Type (13)
PTS discrepency: 1102564 != 1089927 on P-Type (14)
Building P-Frame: 15
PTS discrepency: 1105624 != 1107945 on B-Type (0)
PTS discrepency: 1108684 != 1110948 on B-Type (1)
PTS discrepency: 1111746 != 1113951 on I-Type (2)
PTS discrepency: 1114843 != 1116954 on B-Type (3)
PTS discrepency: 1117864 != 1119957 on B-Type (4)


-Cory

-- 

*************************************************************************
* Cory Papenfuss                                                        *
* Electrical Engineering candidate Ph.D. graduate student               *
* Virginia Polytechnic Institute and State University                   *
*************************************************************************