On 9/25/2017 2:43 PM, Paul wrote:
mike wrote:
On 9/24/2017 6:37 AM, NY wrote:
"mike" wrote in message
news
.wtv files seem to have fewer motion artifacts than
alternative compressed formats.
I'd have though that all off-air recordings, in DVR-MS, WTV and TS
formats, would be identical apart from the wrapper around the data. So
I'd have expected the same degree of motion and JPEG compression
artefacts.
I think the point is that .wtv files aren't compressed. That's why
they're
so huge. The off-air data just gets shoved onto the drive.
If you use some other storage format, it takes a lot of horsepower to get
the video onto the hard drive...and back off again.
I can record 4 channels and play a .wtv recording simultaneously with a
2.8GHZ dual core pentium. Virtually all the horsepower is consumed
by rendering the video.
The reduction in artifacts is due to the lack of compression.
I think the limit is the disk drive bandwidth. When the system is
busy, I sometimes see major pixellation on a scene change, but it
recovers quickly and the frame skip is pretty effective.
Only complaint I have is that I messed something up and can't seamlessly
skip forward any more.
You have a strange model of what .wtv is doing.
OK, let me use more words...
Additional compression by the tuner or computer is not required.
The bitrates/filesizes are much greater than what I've experienced
with other recording formats.
This is just a paste of the teaser description from a Google search.
This is what my OTA reception here would be using.
https://en.wikipedia.org/wiki/8VSB
Throughput.
In the 6 MHz (megahertz) channel used for broadcast ATSC, 8VSB
carries a symbol rate of 10.76 megabaud, a gross bit rate of 32 Mbit/s,
and a net bit rate of 19.39 Mbit/s of usable data.
Using FFMPEG (ffplay), let's dump a .wtv recorded on my Hauppauge
DTV card. This to me, looks more or less like the TV station packet
stream has been put in a file, without re-encoding. The total
bitrate of all streams staying within the 8VSB bounds. This would
amount to 7 to 8GB per hour.
...
WM/WMRVExpirationSpan: 9223372036854775807
WM/WMRVInBandRatingSystem: 255
WM/WMRVInBandRatingLevel: 255
WM/WMRVInBandRatingAttributes: 0
WM/WMRVWatched : false
WM/MediaThumbWidth: 352
WM/MediaThumbHeight: 198
WM/MediaThumbStride: 1056
WM/MediaThumbRet: 0
WM/MediaThumbRatingSystem: 255
WM/MediaThumbRatingLevel: 255
WM/MediaThumbRatingAttributes: 0
WM/MediaThumbAspectRatioX: 16
WM/MediaThumbAspectRatioY: 9
WM/MediaThumbTimeStamp: 4643469047485227351
Duration: 00:37:57.13, start: 1.405622, bitrate: 18047 kb/s
Stream #0:0[0x2f](eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384
kb/s
Stream #0:1[0x30](enm): Audio: ac3, 48000 Hz, stereo, fltp, 192
kb/s (visual impaired)
Stream #0:2[0x31](eng): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:3[0x32]: Video: mpeg2video, yuv420p(tv),
704x480, 16999 kb/s, 29.97 fps, 29.97 tbr,
704x1080
Isn't .wtv more than twice that?
10000k tbn, 59.94 tbc --- video
Stream #0:4[0x33]: Subtitle: eia_608
Stream #0:5[0xffffffff]: Video: mjpeg, yuvj420p(pc,
bt470bg/unknown/unknown),
200x113 [SAR 96:96 DAR 200:113], 90k tbr,
90k tbn, 90k tbc
Metadata:
title : TV Thumbnail
No codec could be found with id 1664495672
You'll notice the bitrate of 18047 (goodput) stays with the transport
19390 limit.
I don't think there is any monkey business going on here at all!
And note that, if I change channels, there is a *different*
stream lineup. WMC is *not* defining the mix of streams. It's
taking the raw feed from the MPEG transport stream and dumping
it right into the file. This is another local channel. There is
one fewer audio stream here, so the stream numbers end up different.
The thumbnail and subtitle streams have switched places.
Yep, that's annoying. I frequently have to choose a different audio
stream when I play a different recording with VLC.
Duration: 01:04:56.91, start: 1.447051, bitrate: 16153 kb/s
Stream #0:0[0xc](eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:1[0xd](enm): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
(hearing impaired)
Stream #0:2[0xe]: Video: mpeg2video, yuv420p(tv),
704x480, max. 24000 kb/s, 29.97 fps, 29.97 tbr,
10000k tbn, 59.94 tbc
Stream #0:3[0xffffffff]: Video: mjpeg, yuvj420p(pc,
bt470bg/unknown/unknown),
200x113 [SAR 96:96 DAR 200:113], 90k tbr,
90k tbn, 90k tbc
Metadata:
title : TV Thumbnail
Stream #0:4[0xf]: Subtitle: eia_608
No codec could be found with id 1664495672
*******
If you're seeing artifacts, your recording is damaged.
Try this experiment where no recording is involved...just streaming.
The content is a football game.
Watch it on a cable source. Pick a scene where the player
is running and the camera is following him. Watch the BACKGROUND.
Watch the same play over ATSC over-the-air TV.
Compare the backgrounds.
This is an extreme case, but highlights the issue.
There are a huge number of pixels changing per frame.
The difference is quite noticeable to me. I wouldn't
call it a deal breaker. If the costs of ATSC vs Cable
were reversed, I'd settle for cable TV.
What happens to seek/skip on damaged content ? Hmmm.
Can you "fix" damaged content by re-encoding ? I'm not convinced.
And there is lots of damaged content out there. Download some
Microsoft BUILD video, and note how many errors the playback sees.
Lots of content is damaged, before you even get it.
Maybe, but you're fixated on damage. That's not the issue.
All my recordings play fine and skip forward fine via MediaCenter.
Same recordings play fine on VLC, but the skip forward works perfectly
sometimes and has huge lags other times. It's not entirely random.
Mostly a fresh recording plays in VLC without the skip issues.
After the system sleeps and records more stuff, the lag appears.
But, I also have some .wtv files recorded before the rebuild
They all play without the skip lag.
Kinda sounds like a buffering issue.
Something is funky in the new setup and I have no idea how to debug it.
I'm amazed at the DTV card I bought, compared to the STB I've used
previously. I don't know what the techie difference is, but this card
is a beast in terms of it's ability to pull a flawless stream out
of the pixel salad my STB (Zinwell) recovers. And right now,
they're running off a 1:2 splitter, using exactly the
same OTA signal. And the theory says it only takes 2dB of
process gain, to move from "flaky" to "flawless". The
waterfall is very sharp, and not at all like analog
TV was.
I built a 4-channel variable attenuator and adjusted the signal
strength for each card. Signal amplitude was quite critical.
AS tuners got better I was able to retire the attenuator.
Another big problem is multipath. If you're recording multiple
channels across multiple tuners with one fixed antenna direction,
things get messy really fast.
The nice thing about analog, is you can be
so far out in fringe reception, the picture loses
sync and is snow, but you can still hear sound.
(That's how we used to get the news at the cottage.)
DTV won't do that. It would give a blue screen and
"Loss of Signal".
Paul