On 12/06/2012 10:21 PM, Devin Heitmueller wrote:
On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik <matthew@xxxxxxxxxx> wrote:
I was able to do a bit of testing tonight and this is what I found.
A channel scan was unsuccessful:
http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)
Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to
crash and this messages to be logged in dmesg
http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt
This looks like a combination of a misconfiguration of GPIOs and
mplayer not properly handling an exception condition. You should
definitely bring this up with the mplayer developers since their app
shouldn't crash under this circumstance.
Sorry I misspoke. mplayer isn't crashing, however it can't read data
from the tuner and thus closes.
for completeness, mplayer output:
http://pyther.net/a/digivox_atsc/dec06/mplayer_channel_switch.txt
Audio is out-of-sync in mplayer. Using cache helps, but over time the audio
still goes out of sync.
http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt
This has nothing to do with the tuner. The tuner delivers the MPEG2
stream already compressed and synchronized. If you're playback is
out-of-sync, it's probably your ALSA drivers, PulseAudio, or mplayer
that is the culprit.
Ok that make sense, I'd bank it being on mplayer and how it reads the
stream.
Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to
generate a test.mpg
mplayer plays the file fine without audio-sync issues, but VLC and Xine
refuse to play it. (is this normal?)
What errors are VLC or Xine showing? Unless the stream is really
corrupt VLC and Xine should play it fine. And if the stream were
corrupt it wouldn't play with mplayer either? This sounds like bugs
in VLC and Xine.
I would agree with. I got the chance to test another mpeg from my other
tuner (that I know works well) and had the same issue.
The vlc errors consist of similar messages such as those below:
[0x7f0200c015a8] ts demux warning: lost synchro
[0x7f0200c015a8] ts demux debug: skipping 187 bytes of garbage
I had thought I was able to play previous captures in VLC. I was unable
to test my other card (that I know works well) last night. Now I see
this is not the case, and it separate issue.
There's definitely something going on in the tuner which is causing
the channel scan to fail (and probably the tuning failure in mplayer).
But all the stuff with actual playback causing segfaults, A/V sync
issues, and failures to play back in certain applications are all
userland problems that you would need to raise with the developers for
those respective projects.
Cheers,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
