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
Poor transcoding quality on capture devices
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.
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.
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
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
-
Spectre
Low quality
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.
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.
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: 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
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.
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.
New link
You're right. I put it online on my private box: http://erik.prutser.cx/crap/lowquality_pvr250.mpegI'm afraid I'm getting permission failures trying to download the sample.
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.
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
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.
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.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.
Markfm: are you with the vlc team btw?
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?
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
- Posts: 41
- Joined: 20 Feb 2004 00:52
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.
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.
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.
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
- Posts: 41
- Joined: 20 Feb 2004 00:52
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.
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.
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.
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.
-
Frater Kork
- Blank Cone
- Posts: 41
- Joined: 20 Feb 2004 00:52
Return to “VLC stream-output (sout)”
Who is online
Users browsing this forum: No registered users and 20 guests