Poor transcoding quality on capture devices

About encoding, codec settings, muxers and filter usage
Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

Poor transcoding quality on capture devices

Postby Prutser » 24 Jun 2004 18:00

Hi folks,

We've been streaming video for some months now and somehow it seems as if there's a rather significant difference in quality between files and capture devices when transcoding.

We've transcoded a high qualilty divx file to 768kbps MPEG1. The result is pretty impressive. With sound attached, we can stream this transcoded file using 1mbps and it looks stunning.

However, when we capture from a TV card (tried different onces, currently we're using a wintv pvr 250), transcode the signal to 768kbps and stream it, the result is rather poor. It doesn't come close to the transcoded divx file. I know it's not the TV card. Without transcoding, the picture is perfect.

Are we doing something wrong or are we missing something? Does this have to do with files and capture devices? Can files be transcoded better than realtime streams? Compression schemes normally achieve better compression on large data chunks than small ones. Could this be the case with vlc also?

regards,
Erik

markfm
Big Cone-huna
Big Cone-huna
Posts: 1536
Joined: 22 Feb 2004 17:42

Postby markfm » 24 Jun 2004 18:48

I've been getting really good video off of a framegrabber using DirectShow Input (other than for a memory leak, a separate issue from discussions of quality). 640x480, MPEG4, 768 kbps. It definitely takes a processor with some oomph to handle this resolution on the TX side -- we use a 3 GHz PIV, with VLC using 25 - 30% of the CPU. On the other hand, the quality is quite good -- I'm doing work with surveillance CCTV, and people do ask what software is being used because the quality is so good.

Could your live streaming be running at a sub-optimum resolution, say 320x240? If the PVR handles different resolutions, try notching it up.

Perhaps try the default mp4v CODEC for your TV streaming -- I haven't done any MPEG1.

Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

Postby Prutser » 24 Jun 2004 18:55

The card is capturing in 640x480 already. We tried different bitrates at the card as well. We run this on a 2.2GHz machine and it already eats about 90% cpu (w2k).

Too bad I can't make a recording to show the quality here. It's a subjective thing, but the first reaction over here is always "wow.. that looks so narrow-band!" :)

We tried all codecs. DIV3 appears superior to the others, but only very slightly so.

Erik

markfm
Big Cone-huna
Big Cone-huna
Posts: 1536
Joined: 22 Feb 2004 17:42

Postby markfm » 25 Jun 2004 21:40

It sounds like there's something bad going on there. On our system demo machine, the one with the Osprey and high-end CCTV camera, I run Win2K, 3 GHz, 640x480, 756 kbps mp4v at 30% CPU -- I would expect less than 45% CPU on your 2.2 GHz machine.

Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

Postby Prutser » 28 Jun 2004 09:38

30% on a 3GHz P4 with hyperthreading? Hmm.. ours is a celeron 2.2, I would think that's actually a significant difference.
Still, how can the quality be so poor? As long as it's not at 100%, there shouldn't be a problem?

Erik

Spectre

Low quality

Postby Spectre » 29 Jun 2004 10:15

To show a small sample clip of streaming video from the hauppauge pvr card.

I uploaded a small sample to the ftp site:
ftp://ftp.videolan.org/incoming/lowquality_pvr250.mpeg

The clip is encoded on the fly with DIV3 at 768kbps/MP3 at 128 kbps and streamed using udp with ts muxer.

IMHO the quality is not really acceptable for most people but judge it yourself if you like.

Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

Postby Prutser » 29 Jun 2004 10:41

For clarity: Spectre is a collegue of mine.

Markfm: I assume yours looks much better. Can you confirm that? Or perhaps even save a sample to file yourself and upload for comparison?

Important note: the quality is especially low when there's a lot of movement on the screen, that's why we captured a bit of MTV. With a screen like CNN that's pretty still most of the times, it looks a lot sharper.

Erik

markfm
Big Cone-huna
Big Cone-huna
Posts: 1536
Joined: 22 Feb 2004 17:42

Postby markfm » 29 Jun 2004 13:33

I'm afraid I'm getting permission failures trying to download the sample.

I can say, though, that my video quality has been pretty good, consistently, using the mp4v CODEC. It's a surveillance CCTV -- big lens, pan, tilt,... When the system is local I test against cars moving on a fairly high speed stretch of road that's in the area; multiple vehicles transiting the field of view fairly quickly with little in the way of artifacts.

I'll try again later on the sample.

The Celeron would make a bit of difference, I believe (though could be wrong). You're shifting a lot of data, doing FFTs, and the Celeron has both smaller cache and a slower front side bus.

Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

New link

Postby Prutser » 29 Jun 2004 13:41

I'm afraid I'm getting permission failures trying to download the sample.
You're right. I put it online on my private box: http://erik.prutser.cx/crap/lowquality_pvr250.mpeg

markfm
Big Cone-huna
Big Cone-huna
Posts: 1536
Joined: 22 Feb 2004 17:42

Postby markfm » 30 Jun 2004 01:20

That does look pretty nasty. A lot of blockiness.
I did notice that the file is at 720x576 resolution -- does the card itself normally output that format?
If you just open a local VLC viewer, a File -- Open Capture Device, do you get a clean video display?
For pure play, I use a test clip of a catamaran race that I pulled off the Web. There's a lot of motion, rocking, waves, etc. Even though the test clip was only shot 320x240, it looks a heck of a lot better than your sample, after I've done transcoding and streaming with mp4v video at 768 kbps.

(I run dual sessions, one server and one client, on my home PC. The client session is doing a UDP RX on 127.0.0.1. I'm expanding the client RX video window, basic drag operation, so that it is larger than your sample video's window -- it looks much better.)

I tried a second run, using mp2v as the video CODEC -- I do believe I get lower quality than the mp4v was producing, more blockiness though not as bad as you were showing. That's part of why I wonder if somehow you have a bad video resolution, something that the card itself is not really happy with.

Spectre

Postby Spectre » 30 Jun 2004 09:18

The card can output mpeg2 video with different resolutions, the standard is dvd format (so 720x576). You can change the bitrate that the hauppauge will output with. When we just open the capture device (with 2Mbit+ selected on the card properties) the output is near perfect, although some interlacing is showed, but no blocks.
Maybe we are asking to much of the codec that is used with this kind of input and a bitrate below 1Mbps? When we use a higher bitrate the blockiness dissapears.

Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

Postby Prutser » 30 Jun 2004 11:00

Maybe we are asking to much of the codec that is used with this kind of input and a bitrate below 1Mbps? When we use a higher bitrate the blockiness dissapears.
No, I don't think so. When we let vlc transcode an arbirary high-bitrate video file on disk to 1Mbps, it looks stunning. I refuse to see how that is different from transcoding from a TV card on the fly.

Markfm: are you with the vlc team btw?

markfm
Big Cone-huna
Big Cone-huna
Posts: 1536
Joined: 22 Feb 2004 17:42

Postby markfm » 30 Jun 2004 14:06

I'm not a VLC developer, more what you would call a power user. I've been working with video, and CODECs, for years, am a systems engineer by trade. I'm testing VLC for use in CCTV surveillance, as a replacement for some hard-wired CODECs. The image quality is there, latency is marginal, but looks useable, needs a bit more experimentation on my part. The only thing needing a fix is memory leak, and I hope/believe the right people have been looking into it (there've been a lot of hits on a specific thread that I opened for that one).

VLC can definitely handle a high bitrate source input, though it takes a processor with some horsepower. What I'm working with is an Osprey 210 framegrabber -- it's outputting 30 fps 640x480 color video, uncompressed YUV format (I believe -- haven't checked the color space setting in a while, since it works). If the PVC offers options of output format, either MPEG or raw, I would definitely go for raw as the format coming off the card. The other thing I would look at is whether there is an option to set your card for a 640x480 format, rather than the 720x576, just to see if there's some problem with the frames coming from the card compared to what the CODEC wants to work with.

(If your card supports it, even try knocking it all the way down to a 320x240, a step-by-step approach. Does 320x240 look OK (little blockiness)? Then bump to 640x480 and repeat)

Do you get significant improvement if you nudge the transcoding bitrate to 1 Mbps?

Frater Kork
Blank Cone
Blank Cone
Posts: 41
Joined: 20 Feb 2004 00:52

Postby Frater Kork » 01 Jul 2004 10:49

Hi guys!

Since I am doing simliar stuff with VLC and a PVR350 I have some comments.
The PVR 250/350 cards are mpeg2 hardware encoders only, they dont even show a raw device, sadly :/
The quality of the mpeg2 stream can of course be adjusted in all kinds of ways (resolution, bitrate, GOP size etc..) but the killer for transcoding that I have found is that the card will *not* do deinterlace on the output signal.

This means that any high motion video is that much harder to transcode properly, not only does the contrasting areas move rapidly - they are full of lines appearing and disappearing every other frame...

If VLC had the ability to perform prefiltering of the input signal before the transcode is applied (see virtualdub) it would make for a much cleaner output to the cost of some extra latency.

Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

Postby Prutser » 01 Jul 2004 12:56

The 250's interlacing is awful indeed! I can imagine it makes it much harder for compression, but can't it be switched off? It's a shame, because other than that the card is pretty good!

P.S.
Any recommendations besides the PVR 250/350?

markfm
Big Cone-huna
Big Cone-huna
Posts: 1536
Joined: 22 Feb 2004 17:42

Postby markfm » 01 Jul 2004 17:00

Just curious --
Have you tried cranking the PVR 250s bitrate high, say 6 to 8 mbps, using that as the base for the VLC transcode? From Spectre's comment it sounds like you need a high base bit rate in order to minimize your interlace artifacts. VLC should do better with a higher quality starting video.

Frater Kork
Blank Cone
Blank Cone
Posts: 41
Joined: 20 Feb 2004 00:52

Postby Frater Kork » 01 Jul 2004 17:14

Yup

Tested both high and low bitrate settings.
A kind of poor mans prefiltering is to capture the source data at a lower resolution that the source picture thus scrambling the interlacing artifacts into a fuzz, cant say it improves overall quality, but it gets rid of mpeg4 artifacting to some degree.

Prutser
Blank Cone
Blank Cone
Posts: 20
Joined: 11 Jun 2004 11:52
Location: The Netherlands

Postby Prutser » 01 Jul 2004 17:22

Which is also what we do now. We changed the resolution from 720x576 to 352x288. I'm not sure whether this really helps the interlacing, but at least it gives vlc 4 times more bandwidth for the compression (there are 4 times less pixels now).
The resulting stamp-sized picture looks a lot better than the poor 720x576 screen. Even when you scale it to full-screen (and set vlc to blending!), regardless of its resultion, it looks less ugly as before.

Better of course would be to make the card stop interlacing the image! Not sure if this is possible. :roll:

Frater Kork
Blank Cone
Blank Cone
Posts: 41
Joined: 20 Feb 2004 00:52

Postby Frater Kork » 01 Jul 2004 17:44

Umm, not totally sure but I think it just grabs the separate fields from the video source and turns it into mpeg2, thus it does not really perform any interlacing as much as just passing on original interlacing.


Return to “VLC stream-output (sout)”

Who is online

Users browsing this forum: No registered users and 22 guests