Using Ubustream with MediaMVPs

[groover km]

Plus, you need to remove the space from "acode c" to make it "acodec" (I think).

[ubu]

Plus, you need to remove the space from "acode c" to make it "acodec" (I think).

For some reason, the forum software tries to be "helpful" and inserts that space. This has led to endless confusion. :eek: If you use

Code:

instead of [quote] it actually displays what you wanted instead of what it "thinks" you wanted.

eg:
[code]{channel} :sout=#transcode{vcodec=mp2v,vb=1024,scale=1,acodec=mp2a,ab=192,channels=2}:duplicate{dst=std{access =file,mux=ps,dst=^"{fullname}"^}}

BTW - did you sort out the problem you mentioned in the "Problem playing UbuStream with MediaMVP" thread? I was hoping "no news" meant "good news".

[groover km]

Hey, thanks for remembering! I upped the delay times for both to 10,000ms (without altering the vlc parms) and got much better results.

Using the default channel list, Research TV works just about every time, Kulaks works most of the time, but the AFTV channels (the ones I want - typical) don't come through although they work on the PC.

With the others working though, I know that it's working as it should. Maybe the others are just bandwidth/ congestion issues. I'll kepp trying.

Thanks!

[ubu]

Hey, thanks for remembering! I upped the delay times for both to 10,000ms (without altering the vlc parms) and got much better results.

In case you didn't see this post, you can up the delay times beyond the 10,000ms "limit" if need be.

Using the default channel list, Research TV works just about every time, Kulaks works most of the time, but the AFTV channels (the ones I want - typical) don't come through although they work on the PC.

The AFTV streams use H264 encoding and, even though they play fine with VLC, transcoding them to MPEG2 seems to produce the problem you describe. Various posts on the VLC forums lead me to believe this is an ffmpeg bug and that the VLC folks are working on fixing it. Keep your fingers crossed!

With the others working though, I know that it's working as it should. Maybe the others are just bandwidth/ congestion issues. I'll kepp tryingg.

I'm currently working on providing MVP support for UbuStream list mode (channel mode seems like it's too complicated for some people to set up) and I'm finding that all streams are definitely not equal (the AFTV problem is just one example). Since this will not rely on the External Recorder plugin (and its "one size fits all" approach") I'm hoping I may be able to get a better success rate for streams playing on the MVP (or at least give some message about why a stream won't play ).

BTW - I see from the "avatar" thread that you're another ex-pat brit living in the "land of the free". I'd already noticed your Sex Pistols avatar. We clearly have much in common.

[jbyram2]

I added a few bits to the first post. The "audio-sync" option tells VLC to add or delete frames as required to keep the audio and video synchronized.

I also found that a longer preplay delay helps the MVP wait for VLC to get started, so I added step 4).

[ubu]

I added a few bits to the first post.

Thanks for updating it. I've made this thread "sticky" so distraught MediaMVP users can see it at a glance.

[ubu]

I've found out one thing that was causing VLC to crash in channel mode when playing certain streams that would play normally in list mode.

The acodec=mp2a parm we've all been using appears to be "deprecated" (it's not listed in the VLC documentation, for instance). While it works for some streams, it causes VLC to crash when transcoding many others. If you use acodec=mpga instead, it fixes it. I now have all the links generated by the CNN, BBC and Google video DynSource mini-plugins working fine in timeshift mode. Also some favourites such as the NASA TV stream now play fine.

I am also working on finding resolutions to the following streams which play but don't transcode correctly:

• AFTV streams (H264 video - mpeg4a audio) which I think may be an ffmpeg bug.
  
• MOV streams (avc video - mpeg4a audio) - maybe also be an ffmpeg issue.
  
• Often, streams in containers (asx, wvx, etc.) have one or more problems. Some have two links in the container (often a "leader" video followed by the "actual" video). VLC loads them into a playlist and then executes the playlist, which works fine for playing but, for transcoding, only the first item in the playlist gets transcoded. Also, some containers are "nested" with links from one container to another container. This seems to confuse VLC.
  
• RealVideo streams will never be supported since VLC refuses to support it until the codec internals are made public (which is never). VLC does support some RealAudio streams but I haven't actually tried it.

I'm also having a few problems getting transcoded audio mp3 files to play with the GBPVR audio player, but that's another story.

[jbyram2]

acodec=mpga parm ... Could be a good idea.

I'll see how the MVP likes it. I havn't tried different codecs, since I knew that the mp2a and mp2v played on the MVP.

[ubu]

acodec=mpga parm ... Could be a good idea.

I'll see how the MVP likes it. I havn't tried different codecs, since I knew that the mp2a and mp2v played on the MVP.

It's hard to figure out from the VLC docs and forums but this is what I think is going on:

Both MPEG-1 and MPEG-2 video (mp1v, mp2v) support MPEG-1 Layer 1, Layer 2 or Layer 3 audio (mpga, mp2a, mp3). GB-PVR uses MPEG-2 video so probably allows any of the three audio formats. We've been using Layer 2 audio (which seems to be the standard for VCD/SVCD and broadcast audio and which appears to be the preferred format for GB-PVR). I can only assume that VLC has difficulty transcoding the audio in some streams to Layer 2 and that using Layer 1 (a less complex format) makes the transcoding simpler. And GB-PVR plays the resulting audio just fine.

I could be wrong.

[jbyram2]

My concern wasn't GB-PVR, but whether MVP could play it.

It does, and is much more stable. Sticky will be updated to show acodec=mpga.