FF/REW skipping and jumping so bad its unusable ( .TS file)

WD Legacy Products WD TV Live & Live Plus
41

That’s correct – Bill works for WD, as do folks like Guy.

And for the record I wasn’t evading the question – sorry, but I didn’t see it buried in the long discussion.  However, RG is essentially correct, although not specifically.  The forum designation is based not only on the number of posts someone makes, but the number of their own posts that have been marked as answers to someone’s question (by the original questioner) as well as the “kudos” other members have given them.

There is also another implication sometimes lost – while there is not a direct ratio here, there is an implication that someone who has posted as many times as someone like Tony, Rich or myself has also read at least an equal number (and most likely far more) posts themselves.  Thus the forum designation becomes a fairly reliable barometer of the level of participation that person has made to the community.

It’s certainly possible to read thousands of messages, post thousands more, and even get correct answers and kudos from hundreds of folks without being knowledgable about the workings of the thing you are talking about, but extremely unlikely.  As with any source, you need to consider all the information you can before you trust it, and folks here are welcome to draw their own conclusions.  I can only say this – I am seldom wrong when I post and I often have far greater insight than someone who has posted only a few hundred times, if that.  I am certainly willing to stand by my record (and am the first to admit it when I make an error).

1 Like
42

Re the first part of the question "I note you are posting in the capacity of “Honored Contributor”. Can you clarify for us what this represents?:

“None of the “titles” are meant to imply any connection with WD or Lithium”
“…except for Community Manager / Staff, etc.”
“For anyone without a WD logo, no connection is meant to be implied.”

Thanks Roofing Guy / TonyPh12345

@mkelley:
Just to be absolutely clear. Can you specifically address the 2nd part: “Do you have any relationship - directly or indirectly - with WD?”

43

The bottom line is that it’s still a container issue.  There’s nothing WD can really do about it.

If I add chapter timecodes to an .mkv file, you’d think that the chapter would actually start at that specific timecode.  But this doesn’t happen.  It starts at the first full reference frame closest to the chosen timecode.  The player needs a fully-formed place to start playing.

Yes, it’s a minor annoyance that if I’m watching a concert DVD I’ve ripped, that when I try to “select song” (i.e. go to a specific chapter)  I either get the last few seconds of the previous song, or it starts a little bit into the song I’m looking for.  The file physically can’t just start playing at the chosen timecode (without garbling up the screen until the first full reference frame), regardless of what the hard drive can do within the file.  Sure, the data that goes with that timecode can be read, but it isn’t enough information to create a full picture on the screen – and that’s the part that WD can’t do anything about.  To get a full picture, it has to find the closest full picture.

If it bothered me that much, I could

A) use a different container that uses more reference frames to begin with for storing the video stream

B) encode the file with many more reference frames

C) encode each chapter (song) as a separate file, and then append them all back together into the full concert

Video files generally don’t store the information that makes up every screen frame.  In essence, they mostly just store what’s changed from the last screen frame.  Without a “last” frame to go by, _ no player _ (whether hardware or software) can properly generate that frame.

VLC happens to give you a garbled screen at the chosen timecode; WDTV happens to give you the closest full screen to the chosen timecode.  If the WD devices gave a garbled screen, like VLC does, then people would just complain that FF/REV don’t work right because the screen gets garbled…

The reason DVDs and BluRays fast-forward and reverse smoothly, is because they use many keyframes.  But this leads to large file sizes.  The player is still only choosing the closest complete frame, but there’s more of them in the video stream.

People generally re-encode to get _ smaller _ file sizes.  Therefore, the encoders generally use far fewer keyframes, and these kinds of issues crop up.  But it’s all about how the file itself is encoded.

44

I have a similar problem with one of my files, but like mkelley said, for me it’s not a big deal either.  I can just recode the file and I’m on my way.  It’s the little things that bother me about the Live.  Things like the progress bar in the movie all of a sudden not working, so I wouldn’t know where in the movie I’m at when watching it.  Or, the way the Live renders photos in an inconsistent way (cropping especially).  But, those are my issues - and to me, they are big deals.  I’ll mention them in the forum evey now and again, yet I’ll still continue coming here because there are a couple of loyal users who will always answer my questions without the fluff.

A forum is a place where various opinions can be expressed with the assumption that healthy debate can come from it.  I’ve always said to my friends, “You can attack my opinion, but don’t attack me.”

The thing about forums that is negative, is the impersonal aspect.  I can write a sentence that is logical and completely fact-driven - yet someone takes it personally because they can’t see the expression on my face.  Maybe one day, forums will have Apple’s Facetime implemented.  Yet, now that I come to think of it, that won’t work either because then servers would have to be super fast to store all the video and archive it for posterity.  Then again, we could always use our Live and Live Plus boxes to stream the content…but, that’s another story…

Anyway, enough of my rambling.

I find this forum to be one of the fairest forums on the internet.  You should try the New York Post.  You want to read some psycho threads…the New York Post is the place to be for that.  I tell you, you’d get shivers down your spine from some of the user comments on there.  Nonetheless, everyone has a right to an opinion, and the right to express it freely without reason for provocation.

Like I said before, this is a pretty fair place to express ideas without the worry of people personally attacking you.  By the same token, if this forum does turn into one of those “I-have-a-bone-to-pick-so-I’m-picking-on-you” forums, I’d be hard-pressed in staying.  I have better things to do with my time than being belittled for expressing my opinion.

And thus this thread should now be renamed to “Forum Complaint and Grievances”.

45

brimstone wrote:

@mkelley:
Just to be absolutely clear. Can you specifically address the 2nd part: “Do you have any relationship - directly or indirectly - with WD?”

I’m not trying to be evasive but the word “relationship” can have many meanings.  I’ve never accepted any money from them nor performed any function for them in direct return for anything.  I consider Bill, the forum admin, to be a friend (and I would hope he thinks of me likewise) so that’s a “relationship”.  I have access to some channels that most people on this forum do not, but it does not confer upon me any official standing in any way whatsoever.  Does that at least answer your question?

Beyond that, Jackster’s reply (which was posted while I was typing this) says it all (actually, RG’s reply said it all when it comes to the technical side of this issue, so between the two of them I think this thread could safely end).

46

Actually, I shouldn’t have mixed colloquial-speak and technical jargon in the same post – it’s bad form and leads to confusion.

A “Reference Frame”, in terms of h.264, is a picture frame that the codec uses to generate future frames.  It can either be a keyframe, or a frame that has previously been generated during the playback process.  So, increasing “Reference Frames” in Handbrake, won’t necessarily generate any more keyframes in the video stream.  The numbers of keyframes being generated are the issue, whether I loosely called them “reference frames” (because the codec uses them as a reference for generating future frames) or not.  I’m not sure, off the top of my head, if/how you alter the number of I-frames (keyframes) that Handbrake generates for its streams.

And the fact that the decoder has to keep several “reference frames” in memory, is why adding too many reference frames can cause problems – the player might simply not be able to keep track of that many frames.

But the fact that the keyframes are spaced farther apart (and in some cases _ too _ far apart) is still the issue at hand, no matter what name I gave them when I was typing too quickly for my own good. :wink:

Although, just because the device is limited in what playback points it can choose, based on the video stream it’s playing, doesn’t mean that WD’s implementation within those limitations is stellar… from what I can gather it is still a little buggy and quirky, but nowhere near as bad as it was.

47

@mkelley:

“it does not confer upon me any official standing in any way whatsoever”

Excellent - we’ve now clearly established you have no authority whatsoever to be telling anyone on this thread what to do.

As to your latest comment “I think this thread could safely end”.

What!!!

48

Hi roofing guy, thanks for your comments. It’s good to be able to get back to a sensible discussion about the ssue itself.

I agree it’s best not to try and get too technical in the jargon lest we bog this thread down and lose sight of what we’re trying to achieve and even lose some posters, even if I’m sure there are a number of professional coders lurking here from various disciplines, apparently including both of us. Fortunately I believe the nature of this issue can be clarified without having to dive in too deep anyway. Read on and I’ll try my best to outline this in the time I can spare. I’ve also been coding (and living) long enough to know that no matter how good I reckon I am, it’s best not to stick one’s neck out too far because the world’s a big place and there’s always someone aound who can pop up and say they know more (LOL).

RG posted: “it’s a minor annoyance that if I’m watching a concert DVD I’ve ripped, that when I try to “select song” (i.e. go to a specific chapter) I either get the last few seconds of the previous song, or it starts a little bit into the song I’m looking for.”

Note this thread is about the erratic behaviour of the FF/REW buttons rather than the way chapter selection is handled. If you check the above posts and some of the links you’ll see people are not complaining about a jump of a “few seconds” but often several minutes, apparently at random as to the size and direction of the jump hence rendering the process incredibly frustrating and in the OP’s opinion unusable. My daughter gave up in tears the other day trying to navigate an MPG file. I wouldn’t be wasting my valuable time here if we were only talking a second or so.

RG posted: “It starts at the first full reference frame closest to the chosen timecode. The player needs a fully-formed place to start playing… The file physically can’t just start playing at the chosen timecode (without garbling up the screen until the first full reference frame), regardless of what the hard drive can do within the file.”

I understand what you’re talking about is the GOP length (representing the distance between the I-frames within the self-contained structure of I/P/B frames) in saying the WD needs to go back “to find the closest full picture”. While that might be the case if the information to allow a transitional frame build was not available (see below), even that doesn’t account for this wildly erratic behaviour IMO. From memory an average (closed) GOP size is something like 15 frames, but, at 25-30fps, even allowing for more complex video stream encoding, I don’t believe it would account for a jump forward or back of much more than a second at worst - and no-one would be complaining about that. The erratic jumps of several minutes (sometimes forwards, sometimes backwards) are not explained.

However, it’s good that you bring up the issue of why a software player like VLC can manage the same file formats - for it can handle that same FF/REW with far more elegance. I don’t see too much of what you call a “garbled screen” in doing so (perhaps more an issue with chapter selection?). Even if there was such an issue after a FF/REW on the WD, this would surely be FAR preferable to jumping minutes. To repeat a point made earlier (echoing others):

(1) In our experience, it’s not a matter of fine tuning but erratic jumps of up to several minutes. The behaviour is so bad that if you press FF, skip foward a few minutes then press PLAY, you can end up some minutes back in the file before you even pressed FF !!!

RG posted: “Video files generally don’t store the information that makes up every screen frame. In essence, they mostly just store what’s changed from the last screen frame. Without a “last” frame to go by, no player (whether hardware or software) can properly generate that frame.”

Following on from above, that’s exactly why I stressed point (2) in an earlier post:

(2) When you are skipping forward the time counter and displayed frame display correctly so it’s clearly something the device (and the hard disk read head and network or USB connection) is capable of doing - the problem occurs when you press PLAY and the counter and displayed frame are erratically reset.

I believe the WD DOES INDEED have the info required to TRANSITIONALLY build the frame as it is doing this very thing while displaying frames WHILE doing the FF/REW. That is, it knows where it’s been and can incrementally keep track of partial frame data (eg P or B-frames) as it moves through the file. This is actually a little different to the situation you raise with chapter select where the player will know nothing about the surrounding frames. Theoretically, I believe it means a FF/REW should be able to be spot on to within a single frame, however no-one is obviously demanding that here.

But either way, returning from a FF/REW by elegantly and smoothly building a transitional frame or even a quick and dirty coding option of jumping to the nearest “full reference frame” (as you put it) does not explain this wildly erratic behaviour IMO. For some unknown reason the PLAY can reset the frame pointer erratically elsewhere than the correct on-screen display. At least that is our unhappy experience (and other posters if you check other threads and forums).

So my “Bottom line” is: IMO it’s not a container issue at all but appears simply to refelect the software/firmware implementation.

Cheers.

49

mkelley wrote:

No, I believe in free and honest debate (which you, sir, do not seem to). 

 

Could not be further from the truth - absolutely delighted to keep debating this very serious issue.    It is rather concerning to see, on the other hand, something rather like a “censorship committee” attempting to close down the debate. 

mkelley wrote:

But the real bottom line here (and if you do read the thread you’ll see this) is that I have tried to shed reality upon the situation. 

 

You mean like suggesting that most folks don’t  need to use FF/REW anyway.  OK that’s your own personal view, but as other posters have expressed, it’s a long way from reality.  In the spirity of democracy, can we please allow people to express their views without having them summarily dismissed.

50

Wooster wrote:

mkelley wrote:

No, I believe in free and honest debate (which you, sir, do not seem to). 

 

Could not be further from the truth - absolutely delighted to keep debating this very serious issue.    It is rather concerning to see, on the other hand, something rather like a “censorship committee” attempting to close down the debate. 

 

Nuclear warheads pointed at The United States is a very serious issue.  FF/REW not working on the Live is a minor inconvenience! :smiley:

51

Wooster wrote:You mean like suggesting that most folks don’t  need to use FF/REW anyway.  OK that’s your own personal view, but as other posters have expressed, it’s a long way from reality.  In the spirity of democracy, can we please allow people to express their views without having them summarily dismissed.

 

No, not at all.  I mean like telling you that it will NOT be addressed by WD and those of you holding your breath until you turn blue in a tantrum won’t change things.  THAT’S the reality I’ve presented to you and I’m sorry you hate to hear it but it’s true.

You can say it’s the most important thing in the world and we can argue about that until the cows come home but the one thing you *cannot* argue with is this last point…  WD will not fix this this year and most likely not even next year, and no screaming or crying on this thread will do anything to help (indeed, as someone far more reasonble has demonstrated, it’s unlikely WD even has the ABILITY to fix this issue).

So, debate the merits all you want, but just understand it’s pointless – you might was well be arguing how many angels can fit on the head of a pin (the answer, by the way, is three).

52

I get that the thread started off being about .ts files (as per the title), and has generalized to FF/RW in any container.

I have a Gen1 WDTV HD.  I don’t have a Live or a Live Plus so I have no experience in them, other than what comments I see others make.

But I still believe my .mkv comment about chaptering is valid, as it indicates the issues of GOP length.  Yes, when I try to jump to a chapter in an .mkv, it’s never more than 10 seconds off, but it’s still up to ten seconds off because the stream has a huge GOP.  The same with VLC.  If I use the slider to fast-forward or reverse, depending on the file, it can take up to 10 seconds of playback before I get a “true” picture without garbled pixels.  These issues are because of the GOP.  And the large GOP that causes chaptering inaccuracies, also causes FF/REV inaccuracies.

Yes, GOP lengths of 12-15 frames are somewhat standard on a purchased DVD or BluRay (which gives you about a half-second of accuracy).  But it’s possible to have an _ entire video stream _ be a single GOP.  There’s nothing in the standards that says you can’t do it that way.  The stream would play fine when you start it from the beginning, but you would _ never _ be able to get a mid-stream picture generated.  You would have a tiny file, that would play fine from the start, but couldn’t be searched or indexed.

I’m going to go out on a limb here and say that the my .mkv files that only end up with 10-seconds of “accuracy” or so, do not have 2 or 3 I-frames per second (GOP length of 12) but only have one I-frame per 10 seconds (GOP length of around 300).

There are many encoders that have used GOP lengths of above 300 (and, as I said, even entire streams as a single GOP).  Your average of 15 or so, is for DVD compliance… it’s not a standard of GOP lengths used in other video streams, or even of MPEG streams themselves.  Would a GOP of 18000 not be ten minutes?

Streaming over the internet, like YouTube, you want a very small GOP size, so that frames can be dropped if the bandwidth is too low, without losing the picture – often it’s only 2 or 3.  Playing from media like a DVD or a BluRay, you want a compromise between file size and frame-accuracy – you don’t want 10-minute jumps in FF/REV – so they’ve selected their standards.

But, for someone designing an encoder that they are intending for people to use to make small rips, played on a PC from a hard drive, there is no real reason for them to stick to a small GOP, or a DVD-compliant GOP.  I mean, think of how much room the actual chaptering information takes up… it’s almost nothing.  Now do a quick Google for pirated rips of BluRay discs… how many have retained the chapter structure?  Almost none.  Just about every byte counts, or so it seems.  How do you think you can get a 1080p movie down to 2 GB?  Sure, the 15GB files you see may still have a small GOP, but the GOP on the 2GB ones can’t possibly be 12 or 15 or 18.

So, since no one has come out and shown a GOP size of 12 on a file with an apparent “accuracy” of 5 minutes, it’s only natural to assume they’ve been encoded with huge GOPs for tiny file sizes.  The same scene groups who think people don’t want chapters, apparently also think people don’t want frame-accuracy for FF/REV, but would rather have small file sizes.

As I said, my Gen1 has no problem with FF or Reverse or chaptering when I play a DVD .iso I’ve created, but when I started changing them to .mkv files because drive space was becoming a concern, my files lost accuracy – both when played on my WDTV and on my PC.  This tells me that handbrake does _ not _ use a GOP of 12-18.  If it was just the WDTV, then I could question Western Digital, but since the same .mkv file has the same “error” (although exhibited somewhat differently) when played through VLC, it’s obviously in the encoding of the file.

Again, it’s not a format issue.  One .mkv can FF/REW well with the slider in VLC, and another one can need a while to “fix” the picture.  It depends on what program did the encoding, and what GOP length was used – they _ don’t _ all use 12-18; not even close.

And, as far as FF/REV previewing goes, just because the decoder keeps a rough track of the B- and P- frames and generates a rough approximation of what the evolving video probably looks like, doesn’t mean it has the full frame information for the playback frame.  Again, I refer back to VLC.  While I’m actually scrolling with the slider bar to FF or REV, the picture is intact.  It only garbles when playback re-starts.

(And for the record, the only programs that I’ve noticed a selectable GOP length or GOP pattern, are DVD authoring programs, which need to ensure DVD compliance.)

53

This is pure speculation on my part because I don’t know much at all about media coding, but I wonder if it has more to do with how the logical seeking is taking place.

In the network protocols, when doing FF/RW, the WDTV is “Seeking.”   It requests a particular block of data that is disjointed from the stream, and that data is going to be of finite size.

If there are no suitable hop-in points in that block of data, it may be that it continues to SEEK using the same non-arbitrarily large offsets, instead of seeking closer in, or around the desired landing point.  

Also, Rewinding tends to suffer far worse in MKVs than FF’s, but that may be due to the fact that it has to go backwards from the desired point until it can find GOP start, and then go forward from there.  

Strangely enough, FF’ing and RW’ing a compressed media stream is INCREDIBLY complex, and RW is much more processor intensive than FF.

TiVo does it EXPERTLY, but there’s a major difference:   There’s only two codecs: (MP2 and MP4) it has to deal with, and no “Containerization” issues.  Plus, those two codecs will likely NEVER change for the next few decades because a change to the codecs would affect the broadcast standards.

54

TonyPh12345 wrote:

TiVo does it EXPERTLY, but there’s a major difference:   There’s only two codecs: (MP2 and MP4) it has to deal with, and no “Containerization” issues.  Plus, those two codecs will likely NEVER change for the next few decades because a change to the codecs would affect the broadcast standards.

There’s another difference as well… TiVo tends to use GOP lengths of 2-4 seconds.  :wink:

There’s some speculation that besides file size considerations, that was to prevent the TiVo MPEG stream from being written directly to a DVD without re-encoding.

55

Mike,

So you’ve taken it upon yourself to keep dishing us up a reality service - whether we want it or not?
Is that it?
How does suggesting this thread should now be closed form part of this service?
If you don’t want to help get this issue sorted that’s ok, just please don’t make it harder.
Of course if you want to help us we would all appreciate it.
How about coming onboard and giving us a hand?
Our family really want a fix to this transport issue.

56

Hi again RG,

Yes I’ve found that it affects a number of “supported” formats - refer one of my earlier posts as posted by others.

I think if you’re “only” finding a 10 second “error” with a chapter search on your MKV’s that’s not the same issue we’ve got - as a number of posters (me included) have found the error can be in minutes. And as you say, that 10 seconds is with a “huge GOP”. Also Chapter search may be more likely to be looking to nearest I-frame not having the chance to have built the incremental/transitional frames as I posted with FF/REW. Of course, it doesn’t mean all software implementations will be elegant enough to build/use the more accurate transitional frames after a FF/REW and as you rightly point out where they don’t it stands to reason the same “large GOP that causes chaptering inaccuracies” will also causes “FF/REV inaccuracies”.

I agree GOP lengths can be larger but the issue can also get a little cloudy. Perhaps confusingly, I believe the term GOP length refers to the distance between I-frames rather than the length of the GOP structure itself with a distinction where there are multiple I-frames within the GOP structure. Also there are anchor frames, not all GOP’s are closed and there are obviously different encoding sequence parameters. Without diving in to this (LOL) perhaps I can make the point that the players obviously need to consider the ramifications for the user of each format they decide to support. I wouldn’t be trying to necessarily compare reported absolute GOP lengths on different formats/structures in isolation and drawing any conclusions as the other parameters are bound to muddy the water.

As an aside, I wonder if anyone knows of a good utility for analysing a file’s various GOP parameters? The mediaInfo version I’ve seen doesn’t do that from memory. Could be handy in future discussions.

***IMPORTANTLY*** Given your post, I’ve just again tested an MPG in VLC. I know these MPEG2 files cause an issue in our WDLive (boy do I - although it’s important to thoroughly test them as they can sometimes behave almost reasonably - well not abominably - for the first few tests or then again they may not, there’s a randomness to it I haven’t been able to crack, but watching them seriously is a royal pain). The version of VLC (0.8.6c) has a FF I can press to change the play speed to X times. Doing this and then clicking back to normal speed (to simulate a FF/PLAY test) is almost perfect to the second AND the picture upon each resume also looks perfect to me. No detectable issues at all AFAICS. Using the slider (elvator?) to scroll through a playing file also appears to work flawlessly. I can’t say whether VLC refreshes to the nearest I-frame or employs a smoother transitional method - but the files work nicely on it and don’t on our WDLive. That’s a pretty compelling test IMO.

I wonder why you experienced problems your end on this? Maybe something about the built in MKV decoder???

From memory, some time back I also tested a DVD rip with a straight video stream unwrap (following the same line of reasoning as you have posted with the standard GOP lengths) and found they had an issue on the WDLive.

Thanks for the feedback on your experiences (albeit with earlier model). It all helps.

57

Hi Tony,

Good thoughts. I’ve tested files on our WD Live on both the USB and via ethernet to try and test if it has anything to do with network packets but it seemed to make no difference. Is that what you meant?

Also, while you’re there. You previously posted about some discussion(?) with WD on this issue. Is there a link you can provide?

Thanks

58

With TiVo, I was referring to the digital storage (Digital cable and DirecTV) where they don’t do ANY modification ot the file, so the GOP length is whatever the broadcasters, cablecos, or sat head-ends used.  TiVo saves the digital stream as-is.

I’ve been trying to find that thread, but the Lithium search tool isn’t helping much.  

59

Technically, the issue is that random-access is limited to the sequence headers.  Since there is normally a sequence header for each GOP, random-access is still performed between sequences, but it appears to be between GOPs (and even if there were more than one I-frame in the GOP, it would still be between GOPs and not between I-frames).  Even back in the VCD days (before DVD and BluRay)  FF and REV could only occur between sequence headers.  You could just have one header in the stream, in theory (and often in practice), but hardware players would not be able to FF or REV at all.

So, it could be (now that I give it more than a moment’s thought) that the files that have such large jumps when trying to FF/REV, don’t necessarily have an unreasonably large GOP, but they could just have very few sequence headers encoded in the stream, with many reasonable GOPs between each header.

I actually have no clue how to peer into a MPEG stream and see where the sequence headers are.  It could simply be an issue that some software players will perform random-access between GOPs and not be limited to headers, but there you’re talking about seemingly infinite computational ability, compared to a hardware decoder that expects a certain IEEE standard.

60

Actually, there IS a pretty easy fix – the Live will do FF and RW quite well with MP4 files correctly authored (in those it works at least as well as Netflix).  I said this early on in this thread.

So just convert your stuff properly to that format and you’ll be fine.