Note the file "ChunMyung1.ts". This file was created by applying 'trick play'
to the original file, with a scale factor of 1 - i.e., by running:
testMPEG2TransportStreamTrickPlay ChunMyung.ts 0 1 ChunMyung1.ts
Because our 'trick play' works by using I-frames only, this file effectively
consists just of the i-frames from the original file. If you play this file in
VLC, you can see that the I-frames freeze starting at about the 10 second mark,
and do not resume until about the 1 minute mark. Does anyone know why?
For another illustration of this, note the file "ChunMyung1-30.ts". This file
was created by applying 'trick play' to the original file, with a scale factor of 1, but
starting at the 30 second mark - i.e., by running:
testMPEG2TransportStreamTrickPlay ChunMyung.ts 30 1 ChunMyung1-30.ts
If you play this file in VLC, you can see that the video is 'empty' until about
the 30 second mark (i.e., corresponding to about 1 minute into the original
video). Does anyone know why?
Hi, Ross.
I just check ChunMyung.ts and ChunMyung1-30.ts. The empty 30 seconds has
nothing to do with MPEG-TS container, it is caused by picture timing
information carried within SPS and SEI of H.264 encoding. This point is
that though testMPEG2TransportStreamTrickPlay picks I frames out, it
does not modify the associated timing information accordingly.
A feasible method to avoid this is to remove vui_parameters() (possibly
together with hrd_parameters()) in SPS and to remove SEI completely. It
seems that somebody has already done something very similar:
http://forum.doom9.org/showthread.php?t=152419
Regards
--
Peng
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
