VLC and D9034 / H.264

[nimaci]

Hi,

I am testing a D9034 MPEG-4 hardware encoder from Scientific Atlanta. It uses H.264 for encoding and MPEG-TS for transport (multicast streaming).

I never had a problem with VLC until now. When I try "vlc udp://@239.255.10.10:1234" it displays garbage for a while (10-20 seconds) and then it crashes (after many messages like "ffmpeg debug: concealing ...").

Here is the log from messages window:

main debug: CPU has capabilities 486 586 MMX 3DNow! MMXEXT SSE FPU
main debug: looking for memcpy module: 4 candidates
main debug: using memcpy module "memcpymmxext"
main debug: waiting for thread completion
main debug: thread 3624 (playlist) created at priority 0
(playlist/playlist.c:184)
main debug: waiting for thread completion
main debug: thread 3640 (preparser) created at priority 0
(playlist/playlist.c:210)
main debug: looking for interface module: 1 candidate
main debug: using interface module "hotkeys"
main debug: thread 3664 (interface) created at priority 0
(interface/interface.c:231)
main debug: adding playlist item ^Udp://@239.255.10.10:1234' (
udp://@239.255.10.10:1234 )
main debug: looking for interface module: 3 candidates
main debug: using interface module "wxwidgets"
main debug: thread 3696 (manager) created at priority 0
(interface/interface.c:216)
wxwidgets debug: Using last windows config
'(-1,0,0,1280,1024)(0,276,302,355,102)(2,640,205,418,587)(6,0,0,-1,150)'
wxwidgets debug: id=0 p=(276,302) s=(355,102)
wxwidgets debug: id=2 p=(640,205) s=(418,587)
wxwidgets debug: id=6 p=(0,0) s=(-1,150)
main debug: nothing requested, starting
main debug: creating new input thread
main debug: waiting for thread completion
main debug: creating statistics handler
main debug: thread 3824 (input) created at priority 1 (input/input.c:261)
main debug: ^Udp://@239.255.10.10:1234' gives access ^Udp' demux ' path
^@239.255.10.10:1234'
main debug: creating demux: access='udp' demux='' path='@239.255.10.10:1234'
main debug: looking for access_demux module: 0 candidates
main warning: no access_demux module matched "udp"
main debug: creating access 'udp' path='@239.255.10.10:1234'
main debug: looking for access2 module: 6 candidates
access_udp debug: opening server=:0 local=239.255.10.10:1234
main debug: net: connecting to '[]:0@[239.255.10.10]:1234'
main debug: looking for network module: 1 candidate
ipv6 debug: 239.255.10.10: Host or service not found
main debug: using network module "ipv6"
main debug: removing module "ipv6"
main debug: looking for network module: 1 candidate
ipv4 debug: resolving :1234...
ipv4 debug: resolving 239.255.10.10:1234...
ipv4 debug: Winsock best interface is 65539
ipv4 debug: using interface 0x1f067856
ipv4 debug: IP_ADD_MEMBERSHIP multicast request
main debug: using network module "ipv4"
main debug: removing module "ipv4"
main debug: using access2 module "access_udp"
main debug: pre buffering
access_udp debug: detected TS over raw UDP
main debug: creating demux: access='udp' demux='' path='@239.255.10.10:1234'
main debug: looking for demux2 module: 44 candidates
main debug: using demux2 module "ts"
main debug: looking for a subtitle file in C:\Program Files\VideoLAN\VLC\
ts debug: DEMUX_SET_GROUP 0 00000000
access_udp warning: unimplemented query in control
main debug: ^Udp://@239.255.10.10:1234' successfully opened
ts debug: pid[2048] unknown
ts debug: pid[8001] unknown
ts debug: pid[8021] unknown
ts debug: PATCallBack called
ts debug: new PAT ts_id=1 version=0 current_next=1
ts debug: * number=1 pid=8021
ts debug: PMTCallBack called
ts debug: new PMT program number=1 version=4 pid_pcr=2048
ts debug: * es pid=2048 type=27 fcc=h264
main debug: selecting program id=1
main debug: looking for decoder module: 27 candidates
ffmpeg debug: libavcodec initialized (interface 3344640 )
ffmpeg debug: postprocessing disabled
ffmpeg debug: ffmpeg codec (h264) started
main debug: using decoder module "ffmpeg"
main debug: looking for packetizer module: 17 candidates
main debug: using packetizer module "packetizer_h264"
main debug: thread 4044 (decoder) created at priority 0
(input/decoder.c:159)
ts debug: * es pid=8001 type=3 fcc=mpga
main debug: looking for decoder module: 27 candidates
main debug: using decoder module "mpeg_audio"
main debug: thread 4020 (decoder) created at priority 2
(input/decoder.c:159)
ts warning: first packet for pid=2048 cc=0x5
ts warning: first packet for pid=8001 cc=0xb
mpeg_audio debug: MPGA channels:2 samplerate:48000 bitrate:128
main debug: no aout present, spawning one
main debug: looking for audio output module: 3 candidates
aout_directx debug: OpenAudio
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
aout_directx debug: found device: Primary Sound Driver
aout_directx debug: found device: Vinyl AC'97 Audio (WAVE)
packetizer_h264 warning: waiting for SPS
aout_directx debug: device supports 2 channels
aout_directx debug: device supports 1 channel
aout_directx debug: creating DirectSoundThread
main debug: thread 4504 (DirectSound Notification Thread) created at
priority 15 (directx.c:372)
aout_directx debug: DirectSoundThread ready
main debug: using audio output module "aout_directx"
main debug: output 's16l' 48000 Hz Stereo frame=1 samples/4 bytes
main debug: mixer 'fl32' 48000 Hz Stereo frame=1 samples/8 bytes
main debug: filter(s) 'fl32'->'s16l' 48000 Hz->48000 Hz Stereo->Stereo
main debug: looking for audio filter module: 24 candidates
packetizer_h264 warning: waiting for SPS
main debug: using audio filter module "float32tos16"
main debug: found a filter for the whole conversion
main debug: looking for audio mixer module: 3 candidates
main debug: using audio mixer module "trivial_mixer"
main debug: input 'mpga' 48000 Hz Stereo frame=1152 samples/1161 bytes
main debug: filter(s) 'mpga'->'fl32' 48000 Hz->48000 Hz Stereo->Stereo
main debug: looking for audio filter module: 24 candidates
main debug: using audio filter module "mpgatofixed32"
main debug: found a filter for the whole conversion
main debug: filter(s) 'fl32'->'fl32' 52800 Hz->48000 Hz Stereo->Stereo
main debug: looking for audio filter module: 24 candidates
main debug: using audio filter module "bandlimited_resampler"
main debug: found a filter for the whole conversion
main warning: PTS is out of range (-34733), dropping buffer
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 warning: waiting for SPS
packetizer_h264 debug: found NAL_SPS
packetizer_h264 debug: found NAL_PPS
ffmpeg debug: concealing 1080 DC, 1080 AC, 1080 MV errors
(h264@00AC5F40)
ffmpeg warning: top block unavailable for requested intra mode at 1 0
(h264@00AC5F40)
ffmpeg warning: error while decoding MB 1 0
(h264@00AC5F40)
ffmpeg warning: illegal short term buffer state detected
(h264@00AC5F40)
ffmpeg debug: concealing 1080 DC, 1080 AC, 1080 MV errors
(h264@00AC5F40)
main debug: no usable vout present, spawning one
main debug: Registering subpicture channel, ID: 2
main debug: Registering subpicture channel, ID: 3
main debug: Registering subpicture channel, ID: 4
main debug: Registering subpicture channel, ID: 5
main debug: window size: 677x576
main debug: looking for video output module: 5 candidates
vout_directx debug: creating DirectXEventThread
main debug: waiting for thread completion
vout_directx debug: DirectXCreateWindow
vout_directx debug: created video sub-window
main debug: thread 4620 (DirectX Events Thread) created at priority 0
(directx.c:263)
vout_directx debug: DirectXEventThread running
vout_directx debug: DirectXInitDDraw
vout_directx debug: directx-device:
vout_directx debug: DirectXEnumCallback: Primary Display Driver, display
vout_directx debug: screen dimensions (0x0,1280x1024)
vout_directx debug: DirectDraw Capabilities: overlay=1 yuvoverlay=1
can_deinterlace_overlay=1 colorkey=1 stretch=1 bltfourcc=1
vout_directx debug: End DirectXInitDDraw
vout_directx debug: DirectXCreateDisplay
vout_directx debug: DirectXCreateClipper
vout_directx debug: disabling screen saver
main debug: using video output module "vout_directx"
vout_directx debug: NewPictureVec overlay:yes chroma:YV12
vout_directx debug: End NewPictureVec (failed)
vout_directx debug: NewPictureVec overlay:yes chroma:YV12
vout_directx debug: End NewPictureVec (failed)
vout_directx debug: NewPictureVec overlay:yes chroma:YUY2
vout_directx debug: YUV overlay created successfully
vout_directx debug: End NewPictureVec (succeeded)
main debug: got 1 direct buffer(s)
main debug: picture in 480x576 (0,0,480x576), chroma I420, ar 101647:86400,
sar 24:17
main debug: picture user 480x576 (0,0,480x576), chroma I420, ar
101647:86400, sar 24:17
main debug: picture out 480x576 (0,0,480x576), chroma YUY2, ar 101647:86400,
sar 24:17
main debug: looking for chroma module: 9 candidates
main debug: using chroma module "i420_yuy2_mmx"
main debug: indirect render, mapping render pictures 0-7 to system pictures
1-8
main debug: waiting for thread completion
main debug: thread 4652 (video output) created at priority 1
(video_output/video_output.c:421)
ffmpeg debug: concealing 828 DC, 828 AC, 828 MV errors
(h264@00AC5F40)
ffmpeg warning: left block unavailable for requested intra mode at 0 13
(h264@00AC5F40)
ffmpeg warning: error while decoding MB 0 12
(h264@00AC5F40)
ffmpeg debug: concealing 769 DC, 769 AC, 769 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 1075 DC, 1075 AC, 1075 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 577 DC, 577 AC, 577 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 872 DC, 872 AC, 872 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 292 DC, 292 AC, 292 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 832 DC, 832 AC, 832 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 780 DC, 780 AC, 780 MV errors
(h264@00AC5F40)
main warning: late picture skipped (-4698)
main warning: late picture skipped (-4351)
ffmpeg debug: concealing 892 DC, 892 AC, 892 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 829 DC, 829 AC, 829 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 813 DC, 813 AC, 813 MV errors
(h264@00AC5F40)
ffmpeg warning: left block unavailable for requested intra mode at 0 6
(h264@00AC5F40)
ffmpeg warning: error while decoding MB 0 6
(h264@00AC5F40)
ffmpeg debug: concealing 949 DC, 949 AC, 949 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 1065 DC, 1065 AC, 1065 MV errors
(h264@00AC5F40)
ffmpeg warning: top block unavailable for requested intra4x4 mode -1 at 4 0
(h264@00AC5F40)
ffmpeg warning: error while decoding MB 4 0
(h264@00AC5F40)
ffmpeg debug: concealing 1080 DC, 1080 AC, 1080 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 655 DC, 655 AC, 655 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 1070 DC, 1070 AC, 1070 MV errors
(h264@00AC5F40)
ffmpeg debug: concealing 1007 DC, 1007 AC, 1007 MV errors

[Guest]

Could you upload sample file to somewhere?

[Guest]

It's realtime streaming. The hardware encoder has video input (composite) and streams over ethernet directly MPEG-TS with H.264

[DJ]

All H.264 is experimental from any vendor! I have been seeing advertisements from chip manufactures offering H.264, But it does rather depend on whose software model the chip set was built on and we would only hope that the design is DSP based so it can be changed.

Compatibility is still an issue for many software vendors. For example Ateme, QuickTime, ffmpeg, VLC, Nero and CoreAVC are reasonably compatible. But Elcard, MainConcepts and others are not. There is a very long list at this point and many do not have compatibility with anything else. So the key word(s) here are "experimental" and still "testing".

The BBC and others are "testing" H.264 on some of the newer satellites in the EEC. Many users are experiencing difficulty in receiving these signals and truly wanting to experience HD as it develops. This may be the catalyst that begins to bring people together in a common compatible H.264

But basic compatibility is only a beginning as H.264 is not complete. So as this develops there will probably continue to be compatibility issues in some areas.

I did look at the model and specifications on the web. Unfortunately the specifications and or blurbs say nothing about a DSP, updates, the software model used or compatibility and to my surprise the unit is characterized as SD (Standard Definition) with MPEG 2 compatibility. This may indicate MainConcepts approach to H.264 but unfortunately this is not compatible with VLC. If I am correct, you would probably be able to play and capture, saving files using MainConcepts utilities in their encoding/decoding package under Direct Show. But I would most certainly query the vendor of the hardware regarding compatibility.

[DJ]

There is another possibility within VLC as I ran across this just a few moments ago.

H264 also worked but only if you catch the stream at its beginning. It give the following error otherwise:

[00000378] packetizer_h264 packetizer warning: waiting for SPS

But it will take a developer to offer an answer here.

[jockyw2001]

There is another possibility within VLC as I ran across this just a few moments ago.

H264 also worked but only if you catch the stream at its beginning. It give the following error otherwise:

[00000378] packetizer_h264 packetizer warning: waiting for SPS

But it will take a developer to offer an answer here.

DJ: where did you find that quote? I might have a similar issue.

I'm streaming H264+mpga in a TS container via http/tcp from VLC to Ffmpeg's Ffplay client. The problem is that most of the time ffplay reads a picture width and height equal to 0 from the h264 header. Only in rare cases the correct values are determined and playback is then usually fine. It really needs a developer to solve this I'm afraid. Anyone with similar problems?

[DJ]

I'm sorry to say I don't remember. It was in another forum and I believe a comment by a user regarding an H.263 issue. What I posted here was all that was there regarding your issue. But it did appear to be relevant!

[jockyw2001]

Thx DJ. Further to the issue I can say that the problem occurs less often if instead of mp3 I mux mpga audio with the h264 video. But it still occurs

[DJ]

Hmm! What happens if you move to an MOV container with MP4 (AAC) audio? This is more along VLC's lines an less along MainConcept's criteria. If this is possible!

Not saying either or both are right or wrong as I firmly believe all formats should be compatible with all containers, but I think we both know that's kinda idealistic.

[jockyw2001]

@DJ:
I forgot to mention that I'm streaming h264/mpga from VLC (win32) in a TS container via HTTP/TCP to my Sony PSP which is running a ported ffmpeg ffplay media player. The problem was that ffmpeg's av_find_stream_info() function could annoyingly often not recognize picture width and height from the stream. Playing files locally from the memorystick in either .avi or .mov containers was no problem.

But my problem is all history now
Here's my workaround in ffplay.c, which works since I know the picture dimensions of the transcoded stream coming from VLC. I'm simply setting the dimensions to the right value with avcodec_set_dimensions():

Code: Select all

// JW: fix for problem with av_find_stream_info() often not recognizing picture dimensions from h264 stream // .... // [h264 @ 0x08BE0310]non existing PPS referenced // [h264 @ 0x08BE0310]decode_slice_header error // [h264 @ 0x08BE0310]non existing PPS referenced // [h264 @ 0x08BE0310]decode_slice_header error // ffplay.c: after call av_find_stream_info, err=0 // ffplay.c: after call av_find_stream_info width=0, height=0 // ffplay.c: after call avcodec_set_dimensions width=480, height=272 // fprintf(stderr,"ffplay.c: after call av_find_stream_info width=%d, height=%d\n",ic->streams[i]->codec->width, ic->streams[i]->codec->height); if (transcode_use_avc_hw) { avcodec_set_dimensions(ic->streams[i]->codec, atoi(transcode_res_horiz), atoi(transcode_res_vert)); // JW fprintf(stderr,"ffplay.c: after call avcodec_set_dimensions width=%d, height=%d\n",ic->streams[i]->codec->width, ic->streams[i]->codec->height); }

In the stream I can now also use mp3 instead of mpga audio again w/o probs. Btw It could be that a more current version of ffmpeg libs will also solve the problem. As I noticed this on ffmpeg's svn:

Code: Select all

Revision 5505 - (view) (download) (as text) (annotate) - [select for diffs] Modified Tue Jun 20 19:46:09 2006 UTC (3 weeks, 2 days ago) by mru File length: 96733 byte(s) Diff to previous 5492 increase search limit in av_find_stream_info

Sometime I will verify that.

Thx for your time and your hint in the right direction!

[MBoufleur]

If you are still interested in samples from the Scientific Atlanta, we got one D9034-S here for testing purposes. We also tryed to multicast video from the encoder to VideoLan and got these error messages and greyish image.
We then captured the TS output from the D9034-S using a Dektec ASI capture card, and recorded the file. When we played the TS file, we still got the same results.

My guess is that this may be an incompatibility issue between Scientific Atlanta and VLC that may be solved some day.

The funny thing is, we also tested the MainConcept H.264 V2 stand alone encoder, and the same problem happens when we encode NTSC with interlace profile. If we use progressive 29.97fps (even though the source is interlaced), VLC decodes without a problem (but progressive output from interlaced telecined material is awfull).
Elecard MPEG Player, wich actually uses MainConcept codec for decoding H.264 files, decodes all without any problems.