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

Michael Ditum mike at mikeditum.co.uk
Fri May 11 16:59:04 CEST 2012 

On 11 May 2012 10:35, Kaarlo Räihä <kaarlo.raiha at gmail.com> wrote:

> 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.
>

Ok, I've compiled vlc with -g3 and -O0 and run it through gdb. When it
crashes I get the following...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb788ab90 (LWP 16817)]
0xb749f24c in EncodeAudio (p_enc=0x8124900, p_aout_buf=0x961f3c8) at
encoder.c:1110
1110        i_out = avcodec_encode_audio( p_sys->p_context,
p_block->p_buffer,
in encoder.c
(gdb) where
#0  0xb749f24c in EncodeAudio (p_enc=0x8124900, p_aout_buf=0x961f3c8) at
encoder.c:1110
#1  0xb7c4d118 in transcode_audio_process (p_stream=0x80cf2a0,
id=0x80f2558, in=0x960e330, out=0xb788a22c) at audio.c:361
#2  0xb7c4b171 in Send (p_stream=0x80cf2a0, id=0x80f2558,
p_buffer=0x960e330) at transcode.c:656
#3  0xb7c693d1 in sout_StreamIdSend (s=0x80cf2a0, id=0x80f2558,
b=0x960e330) at ../../include/vlc_sout.h:225
#4  0xb7c692df in Send (p_stream=0x80c55a0, id=0x80fcbc8,
p_buffer=0x960e330) at duplicate.c:294
#5  0xb802ec1d in sout_InputSendBuffer (p_input=0x80f99b8,
p_buffer=0x960e330) at stream_output/stream_output.c:237
#6  0xb7fb8442 in DecoderPlaySout (p_dec=0x80f3ad8, p_sout_block=0x960e330)
at input/decoder.c:1671
#7  0xb7fb8819 in DecoderProcessSout (p_dec=0x80f3ad8, p_block=0x957e430)
at input/decoder.c:1793
#8  0xb7fb8edc in DecoderProcess (p_dec=0x80f3ad8, p_block=0x957e430) at
input/decoder.c:1994
#9  0xb7fb67d2 in DecoderThread (p_data=0x80f3ad8) at input/decoder.c:938
#10 0x4e93c5ab in start_thread () from /lib/libpthread.so.0
#11 0x4e892cfe in clone () from /lib/libc.so.6

The line it's failed on is

i_out = avcodec_encode_audio( p_sys->p_context, p_block->p_buffer,
                         p_block->i_buffer, p_samples );

and printing the vars gives me...

(gdb) p p_sys
$1 = (encoder_sys_t *) 0x812c548
(gdb) p p_block
$2 = (block_t *) 0x0

So p_block is a null pointer. It's created further up the function with...

        p_block = block_New( p_enc, p_sys->i_buffer_out );

but there's no check afterwards to see if it was created properly. I added
some extra printfs to the block_Alloc function and it's failing on the
malloc call with the text....

Couldn't alloc -6844316907737747320

Watching top whilst it's running, the memory usage was quickly rising...
when it got to about 3GB VIRT the process segfaulted.

So it looks like there's a memory leak somewhere. I'll try running it under
valgrind and see if I can find it.

Mike


>
>>
>> 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
>>
>>
>
> _______________________________________________
> 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/53c7fe82/attachment.html>

More information about the vlc-devel mailing list