[vlc-devel] VLC dying when transcoding and resizing stream

Kaarlo Räihä kaarlo.raiha at gmail.com
Fri May 11 11:35:32 CEST 2012


2012/5/11 Michael Ditum <mike at mikeditum.co.uk>

> Hi,
>
> I'm seeing a problem when using VLC to re-encode a video stream. The input
> stream is an MPEG-2 TS multicast stream of BBC One London (though I can get
> the same thing to happen with big_buck_bunny_720p_stereo.ogg so I don't
> think it's an input problem). I'm then converting it to h254 at 960x540
> with a video bitrate of 1800. Finally I'm streaming the converted stream to
> a multicast address. The command I'm using is...
>
> vlc -I dummy --verbose=3 --color udp://@239.72.0.0:1234':sout=#duplicate{dst="transcode{threads=2,width=960,height=540,fps=25,vcodec=h264,vb=1800,venc=x264{aud,profile=baseline,level=30,keyint=30,bframes=0,ref=1,nocabac},acodec=aac,ab=40}:standard{access=udp{port=1234,miface=lo},mux=ts,dst=239.51.88.6}"}'
>
> What I'm seeing is that the video will convert and stream fine for a
> little while (generally between 10 and 30 seconds, though every now and
> then it will last for a couple of minutes) and then die. The way it dies
> varies depending on the version of software I'm using.
>
> *VLC 2.0.0, with ffmpeg 0.10 and an x264 git snapshot from 2011-10-31*
> With this setup it will stream for a while and then the multicast output
> will stop, the CPU usage will drop considerably (implying that the actual
> transcoding has stopped) however if I leave it for a while I can see dvbpsi
> messages about XXX. When it dies I get the following type of messages:
>
> [0xb5205a88] access_output_udp access out debug: late packet for UDP input
> (870951)
> [0xb5205a88] access_output_udp access out debug: late packet for UDP input
> (867002)
> [0xb5205a88] access_output_udp access out debug: late packet for UDP input
> (863041)
> x264 [warning]: internal error (MV out of thread range)
> x264 [warning]: recovering by using intra mode
> [0xb5205a88] access_output_udp access out debug: packet has been sent too
> late (1019555)
> x264 [error]: Input picture width (960) is greater than stride (544)
> [0xb5205a88] access_output_udp access out debug: late packet for UDP input
> (859091)
> [0xb5205a88] access_output_udp access out debug: packet has been sent too
> late (1019234)
> [0xb5205a88] access_output_udp access out debug: packet has been sent too
> late (1015323)
> x264 [warning]: internal error (MV out of thread range)
> x264 [warning]: internal error (MV out of thread range)
> x264 [warning]: recovering by using intra mode
> x264 [warning]: internal error (MV out of thread range)
> x264 [warning]: recovering by using intra mode
> x264 [warning]: internal error (MV out of thread range)
> x264 [warning]: recovering by using intra mode
> x264 [warning]: internal error (MV out of thread range)
> x264 [warning]: recovering by using intra mode
> x264 [warning]: internal error (MV out of thread range)
> x264 [warning]: recovering by using intra mode
>
> *VLC master git, FFMPEG master git and x264 master git all from yesterday
> afternoon*
> With this setup it will stream for a while and then VLC will seg fault.
> You don't get a period where it stops transcoding but VLC is still running
> like you do with vlc 2.0.0.
>
> When it dies you get messages like the following:
> [0x80cc1a8] access_output_udp access out debug: packet has been sent too
> late (29413565)
> [0x80cc1a8] access_output_udp access out debug: packet has been sent too
> late (29406435)
> [0x80cc1a8] access_output_udp access out debug: packet has been sent too
> late (29399305)
> [0x80cc1a8] access_output_udp access out debug: packet has been sent too
> late (29392175)
> [0x80cc1a8] access_output_udp access out debug: packet has been sent too
> late (29385046)
> [0x80cc1a8] access_output_udp access out debug: packet has been sent too
> late (29377921)
> [0x80cc1a8] access_output_udp access out debug: packet has been sent too
> late (29370793)
> [0x80ccd58] main mux warning: late buffer for mux input (30373100)
> [0x80ccd58] main mux warning: late buffer for mux input (146514)
> [0x80ccd58] main mux warning: late buffer for mux input (130690)
> [0x80ccd58] main mux warning: late buffer for mux input (110274)
> [0x80ccd58] main mux warning: late buffer for mux input (140198)
> [0x80ccd58] main mux warning: late buffer for mux input (136323)
> [0x80ccd58] main mux warning: late buffer for mux input (133104)
>
> At times in this setup I'll also see the x264 errors "internal error (MV
> out of thread range) recovering by using intra mode" and "Input picture
> width (960) is greater than stride (544)", which I get relatively regularly
> with vlc 2.0.0. If I lower the width and height of the outputed video so
> the width is 544 (and the height is proportionate) then vlc will happily
> convert the video for hours on end.
>
> I've captured a number of log files:
> http://pastebin.com/NkhhEyFU is the output of the problem occuring using
> vlc 2.0.0.
> http://pastebin.com/Lsf3S04M is using the git versions and where it died
> almost straight away
>
> Does anyone know what could be causing this problem?
> Is this a mis-configuration from me or a bug in VLC / x264? (the seg fault
> seems like a bug to me)
> Is there any way of specifying this "stride" in x264 so it's larger?
> Is there anything extra I can do to provide extra debugging information to
> help fix this issue?
>

gdb backtrace is usually useful if the VLC crashes.


>
> Thanks in advance for all your help!
>
> Mike
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120511/61eeca1b/attachment.html>


More information about the vlc-devel mailing list