x264 [error]: Input picture width is greater than stride

[nfolken]

My setup: Xubuntu 12.04 running VLC 2.0.1 compiled with Blackmagic Decklink support (v9.5). The blackmagic capturing end appears to be working fine as I can see and capture video.

I am taking the input and transcoding it to H264 and AAC and then duplicating the output to create both a HLS stream for apple devices and a FLV (F4V?) stream for all other platforms. Both work great for a while, but after about an hour I get an error from the x264 encoder and vlc hangs. I broke it up into the two different outputs to get a better look at the errors.

HLS (HTTP Live Streaming)

Code: Select all

cvlc -v -I dummy decklink:// --decklink-card-index=0 --decklink-mode="ntsc" --decklink-video-connection="sdi" --decklink-audio-connection="embedded" --decklink-audio-channels=2 --decklink-audio-rate=48000 --sout-mono-downmix --sout='#transcode{threads=6,vcodec=h264,vb=336,width=512,height=288,fps=29.97,acodec=mp4a,ab=48,channels=1,samplerate=44100,audio-sync,venc=x264{profile=baseline,level=31},aenc=ffmpeg{aac-profile='low'}}:std{access=livehttp{seglen=5,delsegs=true,numsegs=10,index=/home/streaming/www/stream/stream.m3u8,index-url=http://xx.xx.xx.xx/stream/stream-########.ts},mux=ts{use-key-frames},dst=/home/streaming/www/stream/stream-########.ts}'

...where xx.xx.xx.xx is my IP. This will run just fine for about an hour, and then freezes after spitting out x4:

Code: Select all

x264 [error]: Input picture width (256) is greater than stride (0)

F4V (FLV with H264)

Code: Select all

cvlc -v -I dummy decklink:// --decklink-card-index=0 --decklink-mode="ntsc" --decklink-video-connection="sdi" --decklink-audio-connection="embedded" --decklink-audio-channels=2 --decklink-audio-rate=48000 --sout-mono-downmix --sout='#transcode{threads=6,vcodec=h264,vb=336,width=512,height=288,fps=29.97,acodec=mp4a,ab=48,channels=1,samplerate=44100,audio-sync,venc=x264{profile=baseline,level=31},aenc=ffmpeg{aac-profile='low'}}:std{access=http{mime=video/mp4},mux=ffmpeg{mux=flv},dst=:8080/stream.flv,caching=10000}'

This starts out by giving a few warnings:

Code: Select all

[flv @ 0x7fa2784e6a80] Codec for stream 0 does not use global headers but container format requires global headers [flv @ 0x7fa2784e6a80] Codec for stream 1 does not use global headers but container format requires global headers [0x7f8a9800efb8] main mux warning: late buffer for mux input (1373747)

with the last error reapeating dozens of times a second. Non-the-less, it works just fine for about an hour before also giving the same x264 error 4 times and the last one repeating a couple times a minute.

Code: Select all

x264 [error]: Input picture width (256) is greater than stride (0) [0x7fd7684f06e8] main decoder warning: decoder/packetizer fifo full (data not consumed quickly enough), resetting fifo!

I would like to clear up the warnings if I can, But I really want to fix the x264 error, as that seems to be the debilitating factor. Does anyone have even a clue as to where to start looking for a fix for this problem? Could it just be a setting I have wrong, is it a problem with x264, or a problem with my source (blackmagic card)?

[Jean-Baptiste Kempf]

Does it work with streaming of a file?

[nfolken]

Streaming an hour+ long movie completed without any errors. So I thought the problem was with the blackmagic input. To confirm, I tried setting up a FLV stream using the FLV1 codec with the blackmagic card as the input, but that went fine. So the problem seems to be with the combination of the blackmagic input and the x264 encoder. I'll repeat with a few other codecs to try and confirm this.

P.S. Sorry for taking so long on my reply

[Jean-Baptiste Kempf]

Try mp4v and ts.

[aegor]

same with qtcapture:

Code: Select all

./VLC \ -vvv \ qtcapture://0xfa1200000ac83420 --qtcapture-width=800 --qtcapture-heigh=600 \ --live-caching=500 \ --sout="#transcode:rtp" \ --sout-transcode-vcodec=x264 \ --sout-transcode-vb=400 \ --sout-transcode-acodec=mp3 \ --sout-transcode-ab=128 \ --sout-transcode-channels=1 \ --sout-transcode-samplerate=44100 \ --sout-transcode-threads=4 \ --sout-transcode-venc=x264 \ --sout-transcode-fps=25 \ --sout-x264-opengop \ --sout-x264-weightp=0 \ --no-sout-x264-weightb \ --sout-x264-lookahead=2 \ --sout-x264-keyint=25 \ --sout-x264-min-keyint=5 \ --sout-x264-vbv-bufsize=500 \ --sout-x264-vbv-maxrate=1000 \ --sout-x264-vbv-init=1 \ --sout-x264-subme=5 \ --sout-x264-ref=3 \ --sout-x264-b-adapt=1 \ --sout-x264-bpyramid=none \ --sout-ts-use-key-frames \ --sout-x264-preset=fast \ --no-sout-rtp-sap \ --no-sout-standard-sap \ --sout-rtp-proto=udp \ --sout-rtp-caching=80 \ --sout-rtp-dst=192.168.0.100 \ --sout-rtp-ttl=100 \ --sout-rtp-port=30000 \ --sout-rtp-mux=ts \ --sout-mux-caching=80 \ --sout-transcode-high-priority \ --no-drop-late-frames \ --no-skip-frames \ --ignore-config \ --sout-transcode-width=800 \ --sout-transcode-heigh=600 #--no-sout-transcode-audio-sync \ #--sout-keep \

Log fragment:

Code: Select all

[0x10404a6f0] main encoder debug: using encoder module "x264" [0x10404a6f0] main encoder debug: TIMER module_need() : 3.608 ms - Total 3.608 ms / 1 intvls (Avg 3.608 ms) [0x10394d440] main mux debug: adding a new input [0x10394d440] mux_ts mux debug: adding input codec=h264 pid=68 [0x10394d440] mux_ts mux debug: new PCR PID is 68 [0x10394f8a0] stream_out_transcode stream out debug: drift is too high, resetting master sync x264 [error]: Input picture width (400) is greater than stride (0) [0x10394f8a0] stream_out_transcode stream out debug: drift is too high, resetting master sync x264 [error]: Input picture width (400) is greater than stride (0) [0x10394f8a0] stream_out_transcode stream out debug: drift is too high, resetting master sync x264 [error]: Input picture width (400) is greater than stride (0) [0x10394f8a0] stream_out_transcode stream out debug: drift is too high, resetting master sync [0x10394d440] main mux warning: late buffer for mux input (349624) [0x10394d440] main mux warning: late buffer for mux input (376085) x264 [error]: Input picture width (400) is greater than stride (0) [0x10394f8a0] stream_out_transcode stream out debug: drift is too high, resetting master sync [0x1020b10f0] main decoder warning: decoder/packetizer fifo full (data not consumed quickly enough), resetting fifo!

It is the commit in x264 git from 05.06.2012 : [ccc03ec16125e0586231afbb06936bd0bf8c926d] | committer: Jason Garrett-Glaser

Code: Select all

@@ -241,6 +241,11 @@ int x264_frame_copy_picture( x264_t *h, x264_frame_t *dst, x264_picture_t *src ) plane += (height-1)*stride; stride = -stride; } + if( width > abs(stride) ) + { + x264_log( h, X264_LOG_ERROR, "Input picture width is greater than stride\n" ); + return -1; + } h->mc.plane_copy( dst->plane[i], dst->i_stride[i], plane, stride, width, height ); } return 0;

1. Where did the width of 400? UPD: 400 is the half of the sout-transcode-width
2. What a stride and why it is zero? UPD: stride is always zero
3. It seems, encoder is missing some of the information in the input ES. What?

UPD2: As in many cases in 2.0 branch, probably this is the scaler error.
after I removed this --qtcapture-width=1024 --qtcapture-heigh=768, and, of course, left this: --sout-transcode-width=800 --sout-transcode-heigh=600
the problem disappeared

[Rémi Denis-Courmont]

The stride is the length of each scan line inside memory, as opposed to the width which is the number of visible pixels in each scan line.

The stride cannot be smaller than the width, so long as both are expressed in the same unit (either pixels or bytes).

[nfolken]

My install was using the ubuntu version of ffmpeg, so I spent the last few days getting and building the latest stable releases of x264 and ffmpeg. Getting them to work when building vlc was a puzzle, but if anyone else wants to do the same thing, here is what I did: Followed this guide but added "--enable-pic --enable-shared" to each ./configure command. Then I compiled vlc, using the "--with-decklink-sdk=path/to/decklink/sdk/Linux" for Blackmagic decklink support.

Anyway, now I have the latest ffmpeg(2012-07-30), x264(r2 d9d2288), and vlc(2.0.3), and I am still getting the same 'Input picture width is greater than stride' error after 25 mins.

Per Jean-Baptiste Kempf's suggestion, I tried mp4v and ts, which ran fine for a little over an hour before giving a segfault. Not sure if its related if or I don't have some caching or bitrate set correctly.

Code: Select all

cvlc -vvv -I dummy decklink:// --decklink-card-index=0 --decklink-mode="ntsc" --decklink-video-connection="sdi" --decklink-audio-connection="embedded" --decklink-audio-channels=2 --decklink-audio-rate=48000 --sout-mono-downmix --sout='#transcode{threads=6,vcodec=mp4v,vb=2048,width=512,height=288,fps=29.97,acodec=mp4a,ab=48,channels=1,samplerate=44100,audio-sync}:std{access=http{mime=video/mp4},mux=ts,dst=:8080/stream.mp4}' --sout-mux-caching=3000 [0x7ff71c005cd8] main mux warning: late buffer for mux input (8187) (...There were a few of these at the start) ... [0x7ff71c007478] stream_out_transcode stream out debug: drift is too high, resetting master sync Segmentation fault (core dumped)

Per aegor's solution I ran my original setup of x264 HLS and F4V and tried removing the scaler from the equation. The decklink input only has 'decklink-mode' for changing capture resolution, but I can't remove that or it won't work at all. So instead I tried removing the transcoding width and height settings, but either that still didn't take the scaler out of the picture, or that isn't the problem.

[nfolken]

The error shows up in the code (that aegor posted) for me in /common/frame.c line 314. Wouldn't this check be done all the time? If so, why would it work for half an hour, and then suddenly stop? I'm not sure exactly what to look for, but one thing I have monitored is the RAM usage and I'm never getting close to using all of whats available.

[aegor]

nfolken,
In the blackmagick API, changing the parameters of the format and frame rate does not make sense. It is the instructions to your card, what video format used by camera, and they can't be other than those that you use in the source (camera). So, in your case, if you need the output size different from the size of a camera picture (NTSCp/PALp, 720p or 1080p) , scaling may not be bypassed. Simple try bypass all resizing options in the transcoding pipeline.

[nfolken]

Actually, the Blackmagic capture card does have a hardware up-down-cross converter for changing the resolution, but I don't think that feature is implemented in the VLC port. I agree that I need to set the capture card to match the source formatting, but out of curiosity, what do the options in your setup --qtcapture-width and --qtcapture-height do?
I did try to bypass resizing by leaving out width and height specifications in the transcoder, but still got the same error. If you suspect it is a scaler issue, is there another way to bypass it?

[goxy]

I have the same problem, on Windows, Ubuntu, Centos, using streaming from file or Decklink card. It doesn't matter if vlc is compiled from source or installed from rpm.
It seems it is a muxer bug, i saw similar 5-6 years old posts in this forum and nobody solve them.

[nfolken]

I thought I would check back in again on this issue, as there was a Blackmagic SDK update. I recompiled everything (vlc, x264, ffmpeg) but I am still getting the same error. It is the combination of capturing from the decklink card and encoding with x264 that gives me the error. Capturing from decklink and encoding with flv works fine, and capturing from screen:// and encoding with x264 works fine.

As to it possibly being a mux issue, I've tried muxing with ts and flv and I get the same problem with both.

[goxy]

In my case if live cashing is less then 1000 i have continuous "main mux warning: late buffer for mux input" messages after vlc is started.
If live cashing is more then 1000 i have one or two at beginning and afer that I have no messages until on linux 2-3 hours and on windows for about 15 hours. So in my case 720p 60fps 6Mbit/s stream with x264 windows is more stable.

As a workaround solution I build simple watchdog .net application to test upload datarate, and if there is no send packets my application will restart vlc.