FFmpeg/tests/ref/lavf/ts
Graham Booker 60fcc19b90 avformat/mpegtsenc: Changed Video PES packet length to 0.
The rational for this is another issue that plex has exposed.  When it is
conducting a transcode of video to HLS for streaming, my father noticed
artifacts when played on his GoogleTV (NSZ-GT1).  He sent me a test file
and I reproduced it on my device of the same model.  It is important to
note that the artifacts were not present when streaming to VLC or QuickTime
Player.  I copied the command-line that plex used, and conducted all of the
following tests using FFmpeg git.

Transcode to HLS: artifacts on playback
Transcode to TS: playback is fine
Cat HLS segments into a single TS: playback is fine
Segment single TS file to segments: artifacts on playback
Segment single TS file to segments using Apple's HLS segmenter: playback is
fine

At this point I carefully examined the differences between Apple's HLS
segmenter output and FFmpeg's.  Among the considerable differences, I
noticed that the video PES packets always had a 0 length.  So I continued:

Transcode to HLS using FFmpeg with 0 length PES packets: playback is fine.
Segment single TS to segments with 0 length PES packets: playback is fine.

All failures mentioned are only on the GTV since it is the only player on
which I could reproduce artifacts.  I only tested the GTV, VLC, and
QuickTime Player though, so my test case is limited.  I do not know if
other players exhibit this issue.

Since it was useful last time, I have uploaded the test file as
hls_pes_packet_length.m4v along with its associated txt file which contains
the transcode command-line that was used.

Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2014-04-22 16:05:25 +02:00

4 lines
134 B
Plaintext

cca6bca512605bbde20b7aa5cccf4850 *./tests/data/lavf/lavf.ts
407020 ./tests/data/lavf/lavf.ts
./tests/data/lavf/lavf.ts CRC=0x71287e25