The VideoLAN Forums

Drop the mux-part, and replace port=10002 with port-video=10002,port-audio=10004
And make sure dss can find that .sdp-file (and dst is the ip where dss is listening).

Should be working fine in just released 1.1.1 (not sure when binaries are ready to download, but it's tagged in git).

Did you check preferences -> all -> input/Codecs -> audio codecs for those options.

open messages-window and set verbosity to 2, then try that streaming and copy that verbose output on messages window here.

What you use to create that stream? vlc 1.1.0 has known bug with h264 streaming in ts-muxer which is fixed in nightly builds and next 1.1.1.

Similar commandline (with correct frequency etc for my dvb-c) works just fine for me for todays git version.

updated to 1.2.0
there is no streaming

run with -vvv and paste log output to here or some pastebin, as our telepathy skills are littlebit rusty these days.

Can you provide sample file of that recording? And what vlc version youre using?

File > Streaming creates sout-line with :sout, that means its applied only that one item, if you change that to --sout (so : -> -- ) it should work with your lua playlist.

add --extraintf=logger to place log-output to vlc-log.txt.

And you shouldn't need duplicate in that chain at all.

You need to post whole -vvv output, not just the parts that says 'error'

How have you tried that h264/rtp streaming that it doesn't work? if you mean h264 in ts-muxed on rtp-stream then yes, its known bug and fixed in 1.1.1

You should give your sout-chain so people could actually tell what to improve...

http://wiki.videolan.org/Documentation:Modules/logo is the place for logo-options, for transcoding, you also need to add soverlay-option to transcode-block, for example

Hi,

use dst=:8080/mystream.flv and remove mux=flv, or use mux=ffmpeg{mux=flv} as muxer

Hi,

Could you try current nightly (trunk-version) if this problem is still there? it doesn't still add aud-units to ts-stream, but should repeat sps/pps entries with h264.

asf-muxing issues with 1.1 is known issues atm. You should use mp4-container as it should be more standard for h264/aac.

libvpx encoding is really really slow, easily just 2-5fps. And I'm not sure how well ffmpeg-muxer supports webm in streaming (haven't really tested it with pre-encoded files or anything). And for other codecs, webm-container is defined to have vp80+vorbis in it, nothing else (iirc).

it's

yes,
You can add to the end if you just want to transcode in cli without gui.

Thats all I needed to hear, thank you for testing. This issues should be fixed on next nightly builds (branch is the upcoming 1.1).

Hi,

I'm working on this issues, could you try tomorrows nightlies (or build from git) if it's any better with quicktime? or test with quicktime following clip made with recent changes http://www.porogrammer.fi/~ileoo/new_provi.mp4 (11M file)

Hi,

This should be fixed in tomorrows nighlies.

Didn't spot any option that could cause that segfault. Seems that libavformat is crashing on mov_write_moov_tag for some reason.

this is muxing issue, you can work it around by using avformat-muxer (ffmpeg) eg transcode{yourstuff}:file{mux=ffmpeg{mux=mp4},dst=myoutput.mp4} . Difference is mux=ffmpeg{mux=mp4} instead of just mux=mp4. If you have tickets opened relating to this issue, please mention ticket numbers.