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:
- On a Wi-Fi the issue is quite evident.
- Using an Ethernet connection, or connecting directly to USB, the shuttering is less evident, but still present. Use x32.
- 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!
- 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)
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.