WDTV Live re-starts (resumes) ts-videos on wrong place

WD Legacy Products WD TV Live & Live Plus
1

Hi, I’m using the WDTV Live to play back (also) ts files recorded with a Sat-receiver with internal HDD and DVD-burner (since the recorder is far away from my TV). Those files are stored on a 2,5" HDD, connected to the WD, and run properly in play mode. But after Stop and Resume they continue on very other places than they were stopped what makes this kind of playback useless. This is only with the ts-files recorded with that receiver (Macrosystem Enterprise HD).  They are played correctly on my PC (with VLC or PowerDVD, also with FF/FR, resume wasn’t experienced since I couldn’t find it with those players).

I’m afraid something is wrong with those file-formats exported by the recorder though the ts-doctor scans them with “o.k.”

I’ve forwarded this problem to Macrosystem already, they’re telling the files were fully compatible with the standard.

Here is what Media Info tells about one of those files: 

ID : 255 (0xFF)
Vollständiger Name : H:\Madagaskar_(1_4).ts
Format : MPEG-TS
Dateigröße : 3,88 GiB
Dauer : 43min
Modus der Gesamtbitrate : variabel
Gesamte Bitrate : 12,9 Mbps

Video
ID : 6210 (0x1842)
Menü-ID : 100 (0x64)
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : Main@L4.0
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für ReFrame : 5 frames
Codec-ID : 27
Dauer : 43min
Bitraten-Modus : variabel
Bitrate : 11,5 Mbps
Breite : 1 280 Pixel
Höhe : 720 Pixel
Bildseitenverhältnis : 16:9
Bildwiederholungsrate : 50,000 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.250
Stream-Größe : 3,46 GiB (89%)
colour_primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
transfer_characteristics : BT.709-5, BT.1361
matrix_coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio #1
ID : 6220 (0x184C)
Menü-ID : 100 (0x64)
Format : AC-3
Format/Info : Audio Coding 3
Format_Settings_ModeExtension : CM (complete main)
Codec-ID : 129
Dauer : 43min
Bitraten-Modus : konstant
Bitrate : 256 Kbps
Kanäle : 2 Kanäle
Kanal-Positionen : Front: L R
Samplingrate : 48,0 KHz
BitDepth/String : 16 bits
Video Verzögerung : -1s 179ms
Stream-Größe : 78,8 MiB (2%)

Audio #2
ID : 6221 (0x184D)
Menü-ID : 100 (0x64)
Format : MPEG Audio
Format-Version : Version 1
Format-Profil : Layer 2
Codec-ID : 3
Dauer : 43min
Bitraten-Modus : konstant
Bitrate : 256 Kbps
Kanäle : 2 Kanäle
Samplingrate : 48,0 KHz
Video Verzögerung : -1s 258ms
Stream-Größe : 78,8 MiB (2%)

Audio #3
ID : 6222 (0x184E)
Menü-ID : 100 (0x64)
Format : MPEG Audio
Format-Version : Version 1
Format-Profil : Layer 2
Codec-ID : 3
Dauer : 43min
Bitraten-Modus : konstant
Bitrate : 256 Kbps
Kanäle : 2 Kanäle
Samplingrate : 48,0 KHz
Video Verzögerung : -1s 256ms
Stream-Größe : 78,8 MiB (2%)

Is there someone that can identify any failure or should I forward this to WD support?

Thanks for any support.

2

dbenn wrote:

Is there someone that can identify any failure or should I forward this to WD support?

Thanks for any support.

To my knowledge this is a known issue with some encoders.

What happens is that playback can only technically start at specific points within a file, called sequence headers, according to the video specs.  Usually with a commercially-mastered DVD these points are 1/2-second apart, so you don’t notice any issues when you try to resume playback – it starts within 15 frames of where you “expect” it to.

But several encoders (both hardware boxes and software) can create files that have far fewer index points (or even none).

The “symptom” folks complain about with files encoded this way, is that it either can’t FF/REW/Resume at all (if there’s only one header for the whole stream), or when you try to FF/REW or Pause/Stop/Resume, then playback starts in a different part of the file – which can be up to 20 minutes different from where it was “expected”.  Playback is just starting at the nearest sequence header, which is the way video sequences are supposed to be decoded.

The reason they play (and FF/REW/Pause/Stop/Resume) fine with VLC is that VLC was specifically written (and is advertised as) to play broken files, including files with missing header information.

The WDTVs don’t really have the processing power that a PC has, so they can only begin playback at a sequence header within the file, as per video specs.  If the headers are spaced far apart, then you get the errors you describe.

Sounds like that’s what you’re encountering.

3

Thanks RoofingGuy for this detailed replay.

If this is the root of my problems the question remains why the ts-Doctor will not find the incompatibilities, it is the same with the files repaired by ts-doctor. 

And: Can you see any of those failures in the Media-Info list I’ve sent?

Macrosystem maintains that the recorder simply exports the rough data stream without any change, so it should keep the standard. But I’d the same problems when storing those files to my PS3 (via network) and trying to play them with it!

I’ll try now what happens when I convert any ts-file to m2ts or mkv and see how the WD will handle them.

Let you know.

4

dbenn wrote:

Macrosystem maintains that the recorder simply exports the rough data stream without any change, so it should keep the standard.  

Right.

But I did over-simplify a little.  When a program stream has poor FF/REW and Pause/Resume precision, it’s almost always because the file has a long GOP (Group Of Pictures) length, and often combines many GOPs into one sequence.  This is the situation I described above with there being a lack of sequence headers within the file for better precision when picking a playback point.

When it’s a transport stream for a broadcast, someone could tune in at any time, so it wouldn’t do for them to have to wait 5 or 10 minutes for the next sequence header so that proper playback can begin.  The TS streams that are broadcast (and that get recorded) tend to have sufficient headers, and short GOPs.  But as I understand it, to save some room in the stream, many broadcasters don’t bother including very many End Of Sequence markers.  So, this ends up having the same effect.

If the player looks for an End Of Sequence, so that it can start at the next sequence, and the EOS markers are missing or spread very far apart, then it ends up skipping a whole bunch of sequence headers, having the same outward appearance as if the headers themselves were missing/spread too far apart.

Your recorder is faithfully recording the incoming stream… it’s the incoming stream that doesn’t seem to be fully MPEG-2 compliant.  But it’s good enough for the TV to play.

Can you see any of those failures in the Media-Info list I’ve sent?

The MediaInfo program is very good for finding a bunch of playback problems.  It’s often quite easy to see that a “won’t play” file is simply out of the range of what the processor in the WDTV can handle.  Especially with things like H.264 HP@4.2 encodes.  The chip will only decode HP@4.1 at best… it simply can’t decode 4.2 streams.  And it’s also good for seeing if an unsupported codec has been used.

But it doesn’t go through the file and look for sequence headers or EOS markers, so it can’t tell you if that problem is present.

I’m sure there are some tools for analyzing streams and checking the headers and markers, but I’ve never really looked for one.