Noisy shuttering in FF with some H.264 files and 2.02.32 SW

You can see  here what I mean for shuttering. This happens using Fast Forwarding and it is much less evident with previous SW (2.01.69). Herea sample of a file (recording generated on a Panasonic DIGA recorder) on which you can see the issue.

I would like to spot that:

  1. On a Wi-Fi the issue is quite evident.
  2. Using an Ethernet connection, or connecting directly to USB, the shuttering is less evident, but still present. Use x32.
  3. I cannot tell the problem does not exist in 2.01.69, but for low connections, 2.01.69 is much better in this respect!
  4. Surprising, on HD recordings (from the same recorder), the problem disappears

I hope that future release of  SW fix the problem.

When attempting to remux the video i get this error …

So, it’s not surprising the WDTV is having problems playing it. (also note: the sample you provided is not H.264 … it’s MPEG2)

invalid.jpg

Managed to fix it … i could remux it now, and also noticed in the MediaInfo Output the corrected GOP reference.

Video
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.266
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header

Personally, i have had i different thing happen to me … recorded a show on a digital set-top box … watched it on the WDTV … everything fine … except when trying to FF through the commercials … the video would start playing from the beginning of the file !  …  And yes the file plays fine on the Box that recorded it.

Same GOP error as reported above … once fixed, plays fine

(seems to be common these external recorders don’t create a valid compatible stream for other players)

I have tried to do the same operation using mkvmerge 7.3.0 (I have loaded the file and run MVKmerge), but I have not got any exception/warning …

To say I am a newbie of mkvmerge.

Anyhow, concerning the ‘issue’ I am highlighting, I understand that the ‘DR’ format of Panasonic is not so well digested by hardware WD decoding. Pretty happy it works quite well in 95% of case. What I want to highlight is that the the flickering is more evident with last version of sw and causes a poor FF.

PS:I understand WD is a little box doing a lot of appreciable work (and I do appreciate a lot its effectiveness).

ebr9999 wrote:

 

That’s odd…  the log shows no indication of any video tracks being muxed – only a single audio (MP3) track.

Normally you’d see something similar to:  

‘file.ts’ track 0: Using the output module for the format ‘AVC/h.264 (unframed)’.

The file ‘C:\temp\00021.mkv’ has been opened for writing.
‘file.ts’ track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1920/1080.

… and so on.

It appears that the new version doesn’t like the DR file (so basically it demux only audio) and so it does not select for demuxing (I suppose a validity check is done). The previous version instead allow for it, but it gives some errors.