VLC, Aminet 120 and proprietary encoder

[NoAffinity]

Hopefully this is okay in this section. If not, mods please move and accept my apologies.

I have 3 pieces of encoding/decoding hardware: a PC w/ VLC (encoding and decoding), a proprietary MPEG-2 hardware encoder (w/ ASI and IP output, either RTP or UDP), and an Amino Aminet 120. I can send a UDP stream with VLC, receive it successfully with the Amino Aminet 120 (igmp://multicast address:port), and the resulting video looks awesome. I can send a UDP or RTP stream from my proprietary encoder to VLC succesfully, and the resulting video looks awesome. I cannot, however, send/receive a UDP or RTP stream from the encoder to the Aminet succesfully. I use the same syntax in Fresca (igmp://multicast address:port), and the result is a black screen. I can also stream from the encoder (RTP or UDP), receive with VLC and stream back out with VLC (UDP), and receive the stream succesfully with the Aminet.

My ultimate goal: to stream from the encoder to the Aminet.

So, is there a different syntax I should/could be using in Fresca? If I know the IP address that the Aminet has pulled dynamically, is there a better way to stream to it/interface with it. I have the remote and the keyboard for the Aminet, and outside of what's including in the box, that's about it. I have opened the unit, and there is no serial interface.

Any thoughts and insight are appreciated.

[DJ]

The source format and container is??

The destination wants to see what format and container??

[NoAffinity]

The source that works for VLC->Aminet and encoder->VLC is transport stream, which (correct me if I'm wrong), by definition is MPEG-2 video and MPEG-1 Layer II audio. I know for a fact this is what comes out of the encoder, and I am not transcoding with VLC (for VLC->Aminet), so I assume the same holds true there as well. The IP protocol is UDP.

[DJ]

1. There is no room for guessing about what your set top box does or doesn't do. You might check this out with the manufacture according to the model number. The options these days are h.264, MPEG2 and MPEG1. Also not all boxes use the MPEG TS container but many of them do. You will need to check the extension when taking it off the box assuming you are not naming the file and giving it an extension. VLC is quite forgiving in this regard but in most cases Hardware is not, nor is Direct Show.

2. The key word in your original post was "proprietary encoder". Generally when a manufacturer does this they have left the standards for a reason and many provide a tool to make it standard or a tool may be available from a third party but this may preclude streaming in real time.

3. When transcoding (required for streaming) the format and container must be specific and what is expected by the client. VLC only streams in standards forms.

[NoAffinity]

Thank you for your help, thus far, DJ. I understand this is not strictly a VLC question, but more of a question as to how to use VLC as a tool to achieve end results.

1. Sorry, it is an MPEG-2 hardware decoder.

2. The encoder is our product. It is a low-latency MPEG-2 hardware encoder (HD-SDI in, ASI/IP out). The output is standard MPEG-2 TS, MPEG-2 video, MPEG-1 Layer II audio. For IP, either UDP or RTP protocols are available, but for streaming to the Aminet, I am specifying UDP as this is what works when streaming from VLC. No middleware involved here.

3. I am not transcoding when streaming from VLC to the Aminet, unless streaming itself is considered transcoding (possibly an error of semantics/understanding on my part...). I simply stream via UDP, and do not establish any of the transcoding parameters (Windows' GUI), such as video codec, audio codec, etc.

So, now I am considering that I need to determine if/what any differences may be in the VLC output stream and the encoder's output stream.

You said "You will need to check the extension when taking it off the box assuming you are not naming the file and giving it an extension." Can you please expand on that?

[DJ]

MPEG TS is to carry the .ts or .tp extension and not .mpg or .mpeg

VLC was designed as a packet based player capable of streaming media files. In order to do this it likes to have control of the stream, so transcoding is required.

Also be aware that when transcoding TS files with Multiple Program Transport Streams only the selected program stream will be output even when the output is a TS file or stream. I don't believe the all ES option makes a difference here.

When you encounter issues with streaming files it is best to make a local transcode to file and check the transcode using messages. Messages can also be used during the transcode or while streaming.

[NoAffinity]

So, I have captured an IP stream from our encoder, using the 'Dump raw input' option. I did not name the file at all, simply checked the box to stream to a file, and this produced a file by the name of 'stream-demux.dump'. I then analyzed the file using TS Reader Lite, and it sees it as a valid transport stream, with MPEG-2 video on PID 68 and MPEG-1 Layer II audio on PID 69 (there is also a PCR PID). I then reproduced this test, with a stream from VLC to a second instance of VLC. The result is a valid TS stream with AC3 audio on PID 44, MPEG-2 video on PID 45, and a PCR PID. Could the problem with our encoder's stream be in the fact that the audio PID does not precede the video PID?

[DJ]

Not sure about your last question. Most of us have been taught to mux the video first and then audio and it does show up that way in the header info. Some decoders do care, like QuickTime that likes the audio first.

[NoAffinity]

Intereseting. Thanks for your help, DJ.

[gua76]

I'm getting the same problem with Aminet125 and a DVB-T encoder. I can see some services on Amino and some not, I don't know why. The service are all configured in the same way.

Any idea ?

Thanks.