Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Mplayer "a52: CRC check failed!" errors, any progr Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
PostPosted: Tue Jan 10, 2006 9:12 am Reply with quote
logistiker
 
Joined: 09 Jan 2006
Posts: 10




sonnik wrote:
Using which player? I did that method


I'm using mplayer as well. Here's what I do in channels.conf:

Code:
pbshd:537000000:QAM_256:49:52


Then I play it like this:

Code:
mplayer dvb://pbshd


My compiled version of mplayer is in a different spot than the package one with gentoo, so I specify a different path to the compiled version but you get the picture.
View user's profile Send private message
PostPosted: Tue Jan 10, 2006 10:04 am Reply with quote
sonnik
 
Joined: 11 Oct 2005
Posts: 49




dorphell wrote:
sonnik and the rest of you who are having similar issues:

If you just configure the 'troubled' stations to feed all PIDs, you will not have these issues.

...



See my post from Thu Oct 27, 2005 1:04 am in this thread, I tried that and it didn't work.

Can you 1) Tell us how you came to understanding that setting up 8192 (0x2000) would do so, if any differently from using 0 (0x0000) and 2) what mplayer command line you sucessfuly use - I think a couple of other users may have their problem fixed by this - and you mentioned it in another thread - but you never detailed the mplayer command line.

I'm sure the manifest of crc check fails arise from different issues, so the +4/-4 fix isn't a catch all, in fact, my experience shows that it can worsen the problems on stations not creating this particular problem.

If any of you are interested in the same test clip that Scott has, let me know and I'll PM you a download link. I just don't want to leave it here and get a nasty bandwidth bill as these files can be large...
View user's profile Send private message
PostPosted: Tue Jan 10, 2006 10:17 am Reply with quote
sonnik
 
Joined: 11 Oct 2005
Posts: 49




logistiker wrote:
Then I play it like this:

Code:
mplayer dvb://pbshd


Like I mentioned above, CRC errors arise from a number of different situations. This was actually because of an TS error that sources at my local Fox station. Almost as though the AC3 stream occassionally included duplicate AC3 headers. I have evidence of this as the local cable company's HD-DVR has trouble capturing audio on this particular station.

CRC errors can also arise from "noisy" signals or your system unable to decode an entire ATSC stream or single multicast virtual channel. For example, some systems may not be able to keep up with a 720p (60fps) stream, but able to keep up with a single 1080i (30fps) stream. CRC errors may arise in many of these scenarios.

If you're interested, like I mention, I can give you a link to the malformed stream. You can then compile two versions of mplayer ... one with the +4/-4 fix and one without. You'll definately see that the clip in question will only play with the +4/-4 fix.
View user's profile Send private message
PostPosted: Tue Jan 10, 2006 10:34 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




logistiker wrote:
I ran a few more tests according to some solutions on this forum. I noticed that the stream will play fine if you specify the video id and audio id in the channels.conf file. If you specify 8191:8192 and use aid/pid or tsprog, the video AND sound are screwed up even with the two patches made to the demux code. Is that the problem you're talking about when you say playing directly from the device?

No, I'm specifying the -aid and the -vid on the command line and I'm still having problems (but just with one station).

Quote:
Also, where do you get dtvstream?

Google tells me it's here

Quote:
You know common sense would dictate that adding a new option (container type) would be extremely low on the priority list until MAJOR bugs like the ones with dvb streams were fixed.

The few interactions I've had on the mplayer-dev list haven't been encouraging. mplayer/mencoder seems to be mostly intended for ripping, reencoding and playing DVD content. They're not too keen on using mplayer to watch TV and some of the major developers are vocally anti-HDTV. ATSC supports some interlaced formats which proves that it was "designed by idiots". They believe that interlacing should be done away with at all costs.

I don't think many of them have seen HDTV yet. I think once they find out that we idiots are watching over six hundred stations broadcasting 1080i in the U.S., they might consider supporting it more directly. Until then, use xine whenever you can.

Quote:
I have also dabbled a bit with getting mplayer to tune analog channels. It's fun when you find you have to use the v4l2 driver to tune (I have a dvico fusion 5 gold card) and you get the sound fine but only half the picture is shown and it's all screwed up too. Why can't they use the same code as tvtime? Tvtime works fine for me.

One difficulty with using mplayer is that the developers take a strong stance against anything that doesn't fit their view of how things should be done. They won't support subtitle files that have CR/LF at the end of the lines because that's not the "native" Unix file format (I always thought Unix files were a series of bytes but I've only been using it for twenty years). They also won't support workarounds for drivers that they feel are broken no matter how simple they are. There's a good chance that your driver is one of them. Tvtime does include workarounds for broken drivers.

Quote:
Are there any other media players which can play/capture dvb and analog other than mplayer or am I stuck waiting until they get around to fixing these bugs?

Does mencoder capture it properly? If so you can play the captured files with xine.
View user's profile Send private message
PostPosted: Tue Jan 10, 2006 10:42 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




sonnik wrote:
CRC errors can also arise from "noisy" signals or your system unable to decode an entire ATSC stream or single multicast virtual channel. For example, some systems may not be able to keep up with a 720p (60fps) stream, but able to keep up with a single 1080i (30fps) stream. CRC errors may arise in many of these scenarios.

But this case shouldn't happen continuously. mplayer is constantly monitoring how well it's keeping up with the stream. If it falls behind, it will start dropping video frames to catch up but it will never drop audio frames. Displaying the video is much more CPU intensive than decoding the audio so skipping a few frames of video is a good tradeoff. Screwing up the audio is much more ugly than dropping video frames.

If mplayer decides it's dropping too many video frames, it will give you the "Your system is TOO SLOW" message.
View user's profile Send private message
PostPosted: Tue Jan 10, 2006 10:56 pm Reply with quote
logistiker
 
Joined: 09 Jan 2006
Posts: 10




Scott Larson wrote:
No, I'm specifying the -aid and the -vid on the command line and I'm still having problems (but just with one station).


How do you execute it with vid and aid and what do you put in the channels.conf? I can only get it to play properly most of the time if I set the vid and aid in channels.conf

Also, I have noticed that when I capture a stream, even with the +4/-4 patch, and try to play it back on any player other than mplayer, it won't play. I've tried it on numerous windows based media player like WMP, Zoom Player and even MyHD software and they all can't play it. I have also noticed that if I run the stream through ts2ps, then the MyHD software will play it as well but still nothing else. Is the output of an mplayer transport stream a real standard transport stream? When I try to run the TS through mpeg repair software, it says it can't find the pids and yet mplayer can find them? Is there something I'm missing?

Thanks for the link to dtvstream. Does it only work on pcHDTV cards?

Scott Larson wrote:
mplayer/mencoder seems to be mostly intended for ripping, reencoding and playing DVD content


How good does dvd playback/ripping really need to be? I almost never use the computer to watch DVDs and even more rarely to rip DVDs. Watching/Ripping dvb and analog streams are way more important.

Scott Larson wrote:
I don't think many of them have seen HDTV yet. I think once they find out that we idiots are watching over six hundred stations broadcasting 1080i in the U.S., they might consider supporting it more directly. Until then, use xine whenever you can.


Have you ever used xine to watch dvb or analog streams? I have yet to get to work. I don't believe it can dump streams either can it?

Scott Larson wrote:
One difficulty with using mplayer is that the developers take a strong stance against anything that doesn't fit their view of how things should be done.


Unfortunately I see no alternative player that can come close to mplayer on linux.

Scott Larson wrote:
One difficulty with using mplayer is that the developers take a strong stance against anything that doesn't fit their view of how things should be done. They won't support subtitle files that have CR/LF at the end of the lines because that's not the "native" Unix file format (I always thought Unix files were a series of bytes but I've only been using it for twenty years). They also won't support workarounds for drivers that they feel are broken no matter how simple they are.


I'm a programmer myself (web developer) and I'm quite aware with the fact that I have to support many different platforms and ways of using the software. IE really sucks but I'm still forced to program around it because 80-90% of the users on the internet still use the piece of crap. So although I like to design around standards, I still to face the fact that nothing is perfect and there are plenty of quirks that need to be designed around. It's unfortunate one of the best players if not the best mplayer/encoder for linux has to have such narrow-minded developers.

Scott Larson wrote:
Tvtime does include workarounds for broken drivers.


Do suppose the v4l2 library that tvtime could be interchanged with mplayer or would require lots of coding? I've dabbled with C code but I certainly wouldn't call myself an expert and I probably know even less about CPP.

Scott Larson wrote:
Does mencoder capture it properly? If so you can play the captured files with xine.


Doesn't mencoder use the same libraries as mplayer? I would assume it would have the same problems right? Also, I just want to capture the stream because encoding it would require lots of CPU power.

Also it looks like it's possible to capture a dvb stream with a combination of azap and cat? What's your experience with this?
View user's profile Send private message
PostPosted: Wed Jan 11, 2006 10:22 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




logistiker wrote:
How do you execute it with vid and aid and what do you put in the channels.conf? I can only get it to play properly most of the time if I set the vid and aid in channels.conf

I don't use channels.conf. I just specify the correct vid and aid for the program I want on the command line.

Quote:
Also, I have noticed that when I capture a stream, even with the +4/-4 patch, and try to play it back on any player other than mplayer, it won't play.

How are you capturing ATSC with mplayer? And why?

Quote:
Thanks for the link to dtvstream. Does it only work on pcHDTV cards?

Dunno.

Quote:
How good does dvd playback/ripping really need to be? I almost never use the computer to watch DVDs and even more rarely to rip DVDs. Watching/Ripping dvb and analog streams are way more important.

Well, many many many people copy DVD's to disk. Of course this is just for their convenience so they don't have to get up and put the DVD they legally purchased into the drive. Rolling Eyes

Quote:
Have you ever used xine to watch dvb or analog streams? I have yet to get to work. I don't believe it can dump streams either can it?

There's no such thing as an analog stream so I don't know what you're talking about here.

Quote:
Do suppose the v4l2 library that tvtime could be interchanged with mplayer or would require lots of coding? I've dabbled with C code but I certainly wouldn't call myself an expert and I probably know even less about CPP.

You may be able to look at the TVTime code and figure out a workaround for mplayer. There are lots of patches for mplayer/mencoder around that have been rejected by the developers.

Quote:
Doesn't mencoder use the same libraries as mplayer? I would assume it would have the same problems right?

Try it.

Quote:
Also, I just want to capture the stream because encoding it would require lots of CPU power.

Again I'm not sure what you're talking about here. You don't capture streams with mplayer/mencoder. I guess you could if you used -oac copy -ovc copy but it's the worst possible way.

Quote:
Also it looks like it's possible to capture a dvb stream with a combination of azap and cat? What's your experience with this?

I don't use the DVB drivers so I can't say.
View user's profile Send private message
PostPosted: Wed Jan 11, 2006 11:12 am Reply with quote
logistiker
 
Joined: 09 Jan 2006
Posts: 10




Scott Larson wrote:
I don't use channels.conf. I just specify the correct vid and aid for the program I want on the command line.


How do you specify it command line? I don't know of an option to specify the frequency and the type (8VSB or QAM_256) on the command line.

Scott Larson wrote:
How are you capturing ATSC with mplayer? And why?


You've never captured a stream with mplayer? You can capture anything if mplayer can play it. Just use the -dumpstream flag. I've captured ATSC and ASF with it so far and if I could get it to play v4l2, I could capture analog tv channels as well.

Scott Larson wrote:
There's no such thing as an analog stream so I don't know what you're talking about here.


Stream, channel. Maybe I should just say video. At any rate, to record any output coming out of mplayer, you use the -dumpstream flag whether the correct terminology for the output is a stream or not.

Scott Larson wrote:
I don't use the DVB drivers so I can't say.


As far as I knew the only way linux outputs hdtv is through what it calls DVB which is the application layer referring to both the DVB hdtv standard around the world and the ATSC standard in the US and Korea. Does pcHDTV have some special way of outputing hdtv that I don't know about?
View user's profile Send private message
PostPosted: Thu Jan 12, 2006 2:07 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




logistiker wrote:
How do you specify it command line? I don't know of an option to specify the frequency and the type (8VSB or QAM_256) on the command line.

Oh, actually I added some code to mplayer to make the channel a command line option. I just copied the code from dtvsignal which is little more than an array and an ioctl()..

Quote:
You've never captured a stream with mplayer? You can capture anything if mplayer can play it. Just use the -dumpstream flag.

I've never had a reason to. mplayer is for playing streams, not duplicating them.

Quote:
I've captured ATSC and ASF with it so far and if I could get it to play v4l2, I could capture analog tv channels as well.

So you captured files you already had???

I use mencoder to capture analog since I'd much rather encode it into MPEG-4 immediately than having raw video files taking up space.

Quote:
As far as I knew the only way linux outputs hdtv is through what it calls DVB which is the application layer referring to both the DVB hdtv standard around the world and the ATSC standard in the US and Korea. Does pcHDTV have some special way of outputing hdtv that I don't know about?

The DVB drivers for ATSC are actually new. I've always used the original non-DVB drivers because they're simple (just a device and an ioctl call) and I don't need to fool an application into thinking an ATSC station is broadcasting in DVB-T. I'd also rather not have the kernel parsing MPEG-2 streams because a bad packet could potentially crash the system instead of just one process.
View user's profile Send private message
PostPosted: Sat Feb 25, 2006 4:57 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




I think I have pinpointed the cause of some of these AC3 errors. It has to do with the way the stations are encapsulating the AC3 inside the PES (Packetized Elementary Stream, part of MPEG) packets. The problem is with my local FOX and WB stations, like other people here have had problems with.

If you look at the mplayer-dev-eng mailing list for February you should be able to follow the thread.

Most of the stations align the start of an AC3 frame with the start of a PES packet. mplayer's TS demuxer looks at at the first bytes of the PES payload, sees the AC3 syncword, and decides the packet is ac3 audio. This works.

Some stations doesn't align the start on an AC3 frame to the start of a PES packet. I don't think the spec says they have to. When mplayer looks at the start of the PES payload, it finds a random bit of data from the middle of an AC3 frame. It dosen't know what this is and so tries to guess. If the first four bits happen to be 1000, it will decide that the packet has some screwed up DVD VOB file AC3 inside a TS stream non-standard format. mplayer will then cut off four bytes it thinks are this DVD VOB header, but really they are four bytes from the middle of an ac3 stream, and so this causes the CRC error.

There is a solution to solve the problem, which is to get mplayer to include the PMT (program mapping table, says what PID has video,audio etc. and their formats) in the data it requests from the DVB driver. To do this mplayer has an extension to the channels.conf file. You should do something like this:
Code:

KCPQ-DT:567000000:QAM_256:33:34+32:1

In my case KCPQ has video on PID 33, audio on 34, and the PMT is on 32. You'll have to figure out what the PIDs are for the PMT for each channel. Usually it's 1 less than the pid of the video.

You can also run mplayer on the entire QAM channel. If it gets every single PID, it will have the PAT and PMT. The output of getatsc is like this. I think maybe using a PID of 0x2000 in channels.conf will do the same thing. It seems that telling mplayer to scan the entire 40 Mbit/s QAM channel uses significantly more CPU, so you probably don't want to use this method.

I could fix the TS demuxer so it would stop misdetecting this DVD VOB format, but this would never be accepted into mplayer. As others have noted, the mplayer dev clique is extremely hostile to any outside developer. If I submit a patch, it will be bad because it was my idea and not theirs.
View user's profile Send private message
A52 errors solved!
PostPosted: Sat Feb 25, 2006 1:45 pm Reply with quote
maestro
 
Joined: 10 Jul 2004
Posts: 18




xyzzy wrote:

If you look at the mplayer-dev-eng mailing list for February you should be able to follow the thread.


Yay! The patch he posted worked!

Here it is for posteriity:
Code:
Index: demux_ts.c
===================================================================
RCS file: /cvsroot/mplayer/main/libmpdemux/demux_ts.c,v
retrieving revision 1.44
diff -u -r1.44 demux_ts.c
--- demux_ts.c   9 Feb 2006 19:39:51 -0000   1.44
+++ demux_ts.c   22 Feb 2006 23:06:01 -0000
@@ -1317,10 +1317,20 @@
       }
       else if ((p[0] & 0xF0) == 0x80)
       {
+         int l, sub = 0;
          mp_msg(MSGT_DEMUX, MSGL_DBG2, "A52 WITH HEADER\n");
-         es->start   = p+4;
-         es->size    = packet_len - 4;
-         es->type    = AUDIO_A52;
+         es->type    = PES_PRIVATE1;
+         for(l = 0; l < packet_len - 1; l++)
+         {
+            if(p[l] == 0x0B && p[l+1] == 0x77)
+            {
+               es->type    = AUDIO_A52;
+               sub = (l == 4) ? 4 : 0;
+               break;
+            }
+         }
+         es->start   = p + sub;
+         es->size    = packet_len - sub;
          es->payload_size -= packet_len;
 
          return 1;
View user's profile Send private message
PostPosted: Sun Feb 26, 2006 9:55 am Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




Feel my pain. From my email message:
Quote:

After the 32-bit substream header, should there be a AC3 syncword that can be checked for? If the check is made more specific, there will be fewer false positives.


I'm sure this was given due consideration before the succinct response was given, "no."

Now look at that patch. It does exactly what I suggested, checks for the AC3 syncword after the 32-bit substream header, and only detects the DVD VOB format when it's found. Rolling Eyes
Like I said, this way it's their idea and not mine.
View user's profile Send private message
Demux Patch Works!
PostPosted: Sun Feb 26, 2006 4:06 pm Reply with quote
logistiker
 
Joined: 09 Jan 2006
Posts: 10




If you have to convince them it's their idea to get the damn thing patched then so be it. Smile I've patched my mplayer with this patch and compiled it. I don't get any CRC errors anymore with it. The only problem I see now is when I bring up PBS HD, the sound doesn't play sometimes and I have to close mplayer and reopen it a few times before I can finally get the sound to play with the stream. Anyone else experienced this problem with PBS HD?

pbshd:669000000:QAM_256:36:37:2

No sound:

/usr/lib/mplayer/bin/mplayer -framedrop -ni dvb://pbshd
MPlayer 1.0pre7try2-3.4.4 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon MP/XP Thoroughbred (Family: 6, Stepping: 1)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE


Failed to open /dev/rtc: No such device (it should be readable by the user.)
Playing dvb://pbshd.
code taken from dvbstream for mplayer v0.4pre1 - (C) Dave Chapman 2001
Released under the GPL.
Latest version available from http://www.linuxstb.org/
dvb_tune Freq: 669000000
Win32 LoadLibrary failed to load: avisynth.dll, /usr/lib/win32/avisynth.dll, /usr/local/lib/win32/avisynth.dll
TS file format detected.
DEMUX OPEN, AUDIO_ID: -1, VIDEO_ID: -1, SUBTITLE_ID: -1,
PROBING UP TO 2000000, PROG: 0
VIDEO MPEG2(pid=36)NO AUDIO! NO SUBS (yet)! PROGRAM N. 0
Opened TS demuxer, audio: ffffffff(pid -1), video: 10000002(pid 36)...POS=46060
VIDEO: MPEG2 1920x1088 (aspect 3) 29.970 fps 13900.0 kbps (1737.5 kbyte/s)
vo: X11 running at 1280x1024 with depth 24 and 32 bpp (":0.0" => local display)
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 1920 x 1088 (preferred csp: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
VDecoder init failed Sad
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG-1 or 2 (libmpeg2))
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 1920 x 1088 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1920x1088 => 1934x1088 Planar YV12
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
V:28016.4 143/143 43% 19% 0.0% 0 0
Exiting... (Quit)


With sound:


/usr/lib/mplayer/bin/mplayer -framedrop -ni dvb://pbshd
MPlayer 1.0pre7try2-3.4.4 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon MP/XP Thoroughbred (Family: 6, Stepping: 1)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE


Failed to open /dev/rtc: No such device (it should be readable by the user.)
Playing dvb://pbshd.
code taken from dvbstream for mplayer v0.4pre1 - (C) Dave Chapman 2001
Released under the GPL.
Latest version available from http://www.linuxstb.org/
dvb_tune Freq: 669000000
Win32 LoadLibrary failed to load: avisynth.dll, /usr/lib/win32/avisynth.dll, /usr/local/lib/win32/avisynth.dll
TS file format detected.
DEMUX OPEN, AUDIO_ID: -1, VIDEO_ID: -1, SUBTITLE_ID: -1,
PROBING UP TO 2000000, PROG: 0
VIDEO MPEG2(pid=36)AUDIO A52(pid=37) NO SUBS (yet)! PROGRAM N. 0
Opened TS demuxer, audio: 2000(pid 37), video: 10000002(pid 36)...POS=68996
VIDEO: MPEG2 1920x1088 (aspect 3) 29.970 fps 13900.0 kbps (1737.5 kbyte/s)
==========================================================================
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
AC3: 2.0 (stereo) 48000 Hz 320.0 kbit/s
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 320.0 kbit/20.83% (ratio: 40000->192000)
Selected audio codec: [a52] afm:liba52 (AC3-liba52)
==========================================================================
vo: X11 running at 1280x1024 with depth 24 and 32 bpp (":0.0" => local display)
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 1920 x 1088 (preferred csp: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
VDecoder init failed Sad
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG-1 or 2 (libmpeg2))
==========================================================================
Checking audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le...
AF_pre: 48000Hz/2ch/s16le
AO: [oss] 48000Hz 2ch s16le (2 bps)
Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le...
Starting playback...
VDec: vo config request - 1920 x 1088 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1920x1088 => 1934x1088 Planar YV12
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
A:28101.4 V:28101.5 A-V: -0.137 ct: -0.350 106/106 61% 43% 8.4% 24 0
Exiting... (Quit)
View user's profile Send private message
Re: Demux Patch Works!
PostPosted: Sun Feb 26, 2006 5:47 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




logistiker wrote:
If you have to convince them it's their idea to get the damn thing patched then so be it. Smile I've patched my mplayer with this patch and compiled it. I don't get any CRC errors anymore with it. The only problem I see now is when I bring up PBS HD, the sound doesn't play sometimes and


I'm pretty sure I know what's going on here too. At least, I have a very similar problem. There is a bug in the way mplayer checks for AC3 audio. I can fix it, but I know what will happen if I submit a patch.

Check this message I sent to the mplayer list.

The ATSC data is an MPEG TS (Transport Stream), which has tiny 188 byte packets. Inside these packets are MPEG PES packets, which are larger, usually about 5 KB for AC3 data. When mplayer does its AC3 auto-detection it only uses the first TS packet from each PES packet. This means the AC3 data mplayer is trying to auto-detect has about 170 bytes of AC3, then 4 kilobytes missing, then 170 bytes, then 4 kilobytes missing, and so on. This no longer looks anything like AC3 data, and so mplayer decides there is no audio.

One way to reduce this is to increase the -tsprobe value to a few megabytes. mplayer has an alternate way of guessing AC3 which is more or less random. If it probes enough data, then you have better random chance of it finding the magic bits its looking for.

Another thing would be change your channels.conf to something like this:
pbshd:669000000:QAM_256:36:37+35:2

Where 35 would be the PID of the PMT channel for pbs. I don't know what the value is for you. Try looking for a low bandwidth stream just before the A/V streams with dvbtraffic. If you give mplayer a full ATSC stream, you can also get it to print it out (it finds it from the PAT) if you turn on debugging info.
View user's profile Send private message
Re: Demux Patch Works!
PostPosted: Thu Mar 02, 2006 7:32 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




logistiker wrote:
If you have to convince them it's their idea to get the damn thing patched then so be it. Smile

That works really well. The couple of fixes I've submitted to solve bugs "didn't work" until the owner of that part of the code reworked it until it did basically the same thing. For some reason that "worked". Shocked
View user's profile Send private message
Mplayer "a52: CRC check failed!" errors, any progr
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 6 of 7  
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin