VLC playback of MPEG-TS file recorded from MythTV - no audio

[aebrett]

I'm trying to play an MPEG-TS recording (file was created from a Nova-T card in MythTV) using VLC for windows. The video displays fine, however, despite the fact that 2 audio channels are shown by VLC as present in the file, neither one results in any sound being heard on playback.

MPlayer for windows plays the file back, but to get sound on mplayer I have to override the default audio PID with "-aid 561" (the two audio PIDs in the file are 561 and 562, and mplayer selects 562 by default, for reasons unknown).

I've made a 10MB sample from the file available at http://www.brettweb.plus.com/test.mpg and the vlc debug output is below.
Note that I've changed the video output module from DirectX to Windows GDI, since DirectX seems to munge the colorspace.

I'd be very grateful for any suggestions - I'd much rather use VLC than mplayer (since that means I can potentially do clever things like stream recordings etc). Alternatively, if there's any other information that would be useful, I'd be happy to provide it - this is driving me up the wall!

Code: Select all

main debug: creating new input thread main debug: waiting for thread completion main debug: thread 4336 (input) created at priority 1 (src/input/input.c:230) main debug: `\\leh\eu\corp\home\abrett\1004_20060213092500a.mpg' gives access `' demux `' path `\\leh\eu\corp\home\abrett\1004_20060213092500a.mpg' main debug: creating demux: access='' demux='' path='\\leh\eu\corp\home\abrett\1004_20060213092500a.mpg' main debug: looking for access_demux module: 1 candidate main debug: creating access '' path='test.mpg' main debug: looking for access2 module: 5 candidates vcd debug: trying .cue file: \\leh\eu\corp\home\abrett\1004_20060213092500a.cue access_file debug: opening file `test.mpg' main debug: using access2 module "access_file" main debug: pre buffering main debug: received first data for our buffer main debug: prebuffering done 1408981 bytes in 0s - 1375958007 kbytes/s main debug: creating demux: access='' demux='' path='test.mpg' main debug: looking for demux2 module: 40 candidates main debug: using demux2 module "ts" main debug: looking for a subtitle file in \ ts debug: DEMUX_SET_GROUP 0 00000000 main debug: `test.mpg' successfully opened ts warning: lost synchro ts debug: skipping 96 bytes of garbage ts debug: pid[560] unknown ts debug: pid[562] unknown ts debug: pid[561] unknown ts debug: PATCallBack called ts debug: new PAT ts_id=1 version=0 current_next=1 ts debug: * number=1 pid=5888 ts debug: PMTCallBack called ts debug: new PMT program number=1 version=1 pid_pcr=2307 ts debug: * es pid=560 type=2 fcc=mpgv main debug: selecting program id=1 main debug: looking for decoder module: 26 candidates main debug: using decoder module "libmpeg2" main debug: thread 4760 (decoder) created at priority 0 (src/input/decoder.c:159) ts debug: * es pid=561 type=4 fcc=mpga main debug: looking for decoder module: 26 candidates main debug: using decoder module "mpeg_audio" main debug: thread 4252 (decoder) created at priority 2 (src/input/decoder.c:159) ts debug: * es pid=562 type=4 fcc=mpga ts debug: * es pid=563 type=6 dr->i_tag=0xe ts debug: * es pid=563 type=6 dr->i_tag=0x59 ts debug: * es pid=563 type=6 fcc=dvbs ts warning: first packet for pid=560 cc=0xe ts warning: first packet for pid=561 cc=0x8 ts warning: first packet for pid=562 cc=0xb libmpeg2 debug: 704x576 (display 704,576), aspect 576000, sar 12:11, 25.000 fps main debug: no usable vout present, spawning one ts warning: first packet for pid=563 cc=0x4 main debug: window size: 768x576 main debug: looking for video output module: 5 candidates main debug: waiting for thread completion main debug: Registering subpicture channel, ID: 2 main debug: Registering subpicture channel, ID: 3 main debug: Registering subpicture channel, ID: 4 main debug: Registering subpicture channel, ID: 5 wingdi debug: create: 004B06B4 wingdi warning: Created WinGDI window wingdi debug: create: 01A00B0E wingdi debug: create: 011A0BCE wingdi debug: GDI depth is 32 main debug: thread 3988 (GDI Event Thread) created at priority 0 (wingdi.c:296) main debug: using video output module "wingdi" main debug: waiting for thread completion main debug: got 1 direct buffer(s) main debug: picture in 704x576 (0,0,704x576), chroma I420, ar 4:3, sar 12:11 main debug: picture user 704x576 (0,0,704x576), chroma I420, ar 4:3, sar 12:11 main debug: picture out 704x576 (0,0,704x576), chroma RV32, ar 4:3, sar 12:11 main debug: looking for chroma module: 9 candidates main debug: using chroma module "i420_rgb_mmx" main debug: indirect render, mapping render pictures 0-7 to system pictures 1-8 main debug: thread 3720 (video output) created at priority 1 (src/video_output/video_output.c:416) ts debug: eof ? main debug: EOF reached main debug: waiting decoder fifos to empty <snip> main debug: waiting decoder fifos to empty main debug: decoded 106/108 pictures main debug: waiting decoder fifos to empty <snip> main debug: waiting decoder fifos to empty main debug: closing input ts debug: pid list: ts debug: - pid[0] seen main debug: unlocking module "libmpeg2" main debug: thread times: real 0m7.390814s, kernel 0m0.046875s, user 0m0.640625s main debug: thread 4760 joined (src/input/decoder.c:191) main debug: killing decoder fourcc `mpgv', 31 PES in FIFO ts debug: - pid[560] seen main debug: unlocking module "mpeg_audio" main debug: thread times: real 0m7.390814s, kernel 0m0.000000s, user 0m0.000000s main debug: thread 4252 joined (src/input/decoder.c:191) main debug: killing decoder fourcc `mpga', 0 PES in FIFO main debug: looking for decoder module: 26 candidates main debug: using decoder module "mpeg_audio" main debug: thread 4252 (decoder) created at priority 2 (src/input/decoder.c:159) ts debug: - pid[561] seen main debug: unlocking module "mpeg_audio" main debug: thread times: real 0m0.000000s, kernel 0m0.000000s, user 0m0.000000s main debug: thread 4252 joined (src/input/decoder.c:191) main debug: killing decoder fourcc `mpga', 1 PES in FIFO ts debug: - pid[562] seen main debug: Program doesn't contain anymore ES ts debug: - pid[563] seen ts debug: - pid[5888] seen ts debug: - pid[8191] seen main debug: unlocking module "ts" main debug: unlocking module "access_file" main debug: thread times: real 0m7.422065s, kernel 0m0.421875s, user 0m0.125000s main debug: thread 4336 joined (src/input/input.c:386) main debug: garbage collector destroying 1 vout main debug: unlocking module "i420_rgb_mmx" wingdi debug: CloseWindow wingdi debug: WinProc WM_DESTROY wingdi debug: WinProc WM_DESTROY wingdi debug: WinProc WM_DESTROY main debug: thread times: real 0m7.437690s, kernel 0m0.000000s, user 0m-1.#IND00s main debug: thread 3988 joined (wingdi.c:328) main debug: unlocking module "wingdi" main debug: thread times: real 0m7.422065s, kernel 0m1.156250s, user 0m2.046875s main debug: thread 3720 joined (src/video_output/video_output.c:456)

[DJ]

Trying to read between the lines on this one is not easy!

First MythTV is admittedly by the author a home brew! It appears that the assignment of PID is incorrect for the TS format. I believe this is changeable within VLC's Preferences (Input / Codecs, General) for the (DVB) TS format, but I also believe this would effect other TS files adversely. I have never tried this, so I can only assume it will work. For terrestrial transponder streams VLC picks the first stream (audio & video) PID out of the group of signals. To the best of my knowledge the PID is an assignment within the stream is for both audio and video for that stream (IE. PID 560, 561 & 562 are a group for program 1). So if you are finding it necessary to change the PID to gain audio, but there is no change in the video information, makes it fairly obvious that there is something wrong with the PVR or the interface to your card.

Another possibility is that the audio signals going from your card to the computer are reversed (pid 561 would be the left channel and pid 562 would be the right channel. if the signal is mono it is supposed to be the left channel only so as to allow for SAP broadcasts and is selectable if you right click on the player while playing the video and select it.

From the Messages file it appears that VLC is selecting the correct mpga audio tracks (PID 561 & 562 are both identified as mpga audio) but having problems with the header information as the first packet it encounters is corrupt.

There are other PVR front ends available for your device that are fully supported and range from free to under $20 that do create files to common standards and specifications, if you continue to have problems with MythTV.

The other comment you make regarding your Video card suggests that you are still going to have problems playing these files.

Once you get the audio to work. All digital video is follow audio for sync so the picture is now going to try to run on speed. Because of the rather high overhead of the TS format this will begin to tax your CPU as you have shut down the DirectX system. This depends greatly on the Bit Rate and resolution of the file, but I would suggest looking at your Task Manager (for CPU and Available Memory usage) and consider finding a real solution like updating DirectX (if it isn't current) or more likely replacing your Video card's drivers.

[The DJ]

@DJ can you please try not to give people WRONG information when you don't know the answer? I appreciate the many answers you try to give, but sometimes you are just making wild guesses and assumptions.

Seems there is an issue with the PCR or the PTS of the stream, rendering VLC unable to correctly synchronize the Audio and the Video.

[DJ]

@DJ can you please try not to give people WRONG information when you don't know the answer? I appreciate the many answers you try to give, but sometimes you are just making wild guesses and assumptions.

Seems there is an issue with the PCR or the PTS of the stream, rendering VLC unable to correctly synchronize the Audio and the Video.

It is my understanding that the DTS or PTS of the stream is optional. However the PCR is not. But this data is repeated with each packet as a part of the header for that packet. So shouldn't it be self correcting if this is truly the problem?



After finishing this post I had the thought that if you were referring to the initial header of the file as being wrong or corrupt with incorrect PCR information doesn't this leave the file unplayable in that the stream should never start decoding?

According to the original post there is playback of video with no sound using VLC and another player does play the file, even though the sound is in the wrong place, so this scenario also sounds unlikely.

[DJ]

Another possibility is that the audio signals going from your card to the computer are reversed (pid 561 would be the left channel and pid 562 would be the right channel. if the signal is mono it is supposed to be the left channel only so as to allow for SAP broadcasts and is selectable if you right click on the player while playing the video and select it.

After reviewing the TS specification this morning the above statement would not be correct. In fact while you may be able to do it, you would most likely end up with a time splay between the channels. Not a good thing! Each of the audio channels can contain any normal format from mono to multi-channel as such would contain all flags normal for that format. So the reversing of audio cables would have no effect on the end result.

Sorry for the stupid error!

[The DJ]

Correct. Most players (and even a lot of "cheap" hardware) synchronizes their video on the decoded audio stream and totally discard the PCR and audio PTS. VLC doesn't do this and is quite strict on this. This makes VLC such a good MPEG-TS player.

Serious hardware and software manufacturers don't test their materials against VLC for nothing

[aebrett]

Ah - I think I'm starting to understand what's going on here, and why some other programs recorded in MythTV play ok in VLC. Some recordings I have show the PCR PID as being the same as the video PID, which, since the video PID clearly can't be discarded, must presumably contain the PCR data, and VLC plays them ok.

Is there any way to force VLC (via cmdline option or similar) to synchronise on the audio stream, rather than trying to use a non-existent PCR? Alternatively, failing that, are there any tools which can rewrite the TS header to set the PCR PID to either the audio or video PID (and if this was done, would VLC then happily play it)?

[The DJ]

No there is no such option. You can try remuxing with something like ProjectX, which is a MPEG validator and remuxer.