omxplayer seems to play then hangs on

[jrowebster]

Hi,
I have a raspberry pi model b installed with the latest raspbian image. I try to play a rtmp stream with omxplayer but i get a black screen every time on my tv connected via hdmi to my pi. i have downloaded the stream with rtmpdump and tried to open it with omxplayer -o hdmi command but omxplayer just hanged on forever. this is the test file from the stream: https://www.dropbox.com/s/ql1migeac8spi2s/stream.flv?dl=0
can you please download it and try to play with omxplayer via hdmi?
mediainfo output _videocodecid: avc1 _audiocodecid : mp4a
omxplayer version
Build date: Sat, 22 Mar 2014 20:58:15 +0000
Version : 39e6342 [master]
thanks

[popcornmix]

ffmpeg refers to it as "constrained basline profile":

    Stream #0.0: Video: h264 (Constrained Baseline), yuv420p, 720x404 [PAR 404:405 DAR 16:9], PAR 254:255 DAR 3048:1717, 1k fps, 1k tbr, 1k tbn, 50 tbc (default)

That's not something I've seen before. I'll see if I can find out if it's supported by the hardware.

(Note: I've tried remuxing to mkv but that didn't help, so it's probably the codec rather than the container).

[jrowebster]

i have also purchased MPEG-2 and VC-1 license keys for pi but it didn't help. it would be great for people who wants to watch rtmp streams with that codec. thanks.

[popcornmix]

Looking at the data in the file, the decoder config starts like:
SendDecoderConfig: 42 01 42 00 20 ff e1 00 1a 67 42 e0 20 96 54 05 a1

And video frames start with:

Decode:    27134 00 00 69 fa 00 00 00 01 09 10 00 00 00 01 67 42
Decode:      648 00 00 02 84 00 00 00 01 09 30 00 00 01 21 9a 02
Decode:      616 00 00 02 64 00 00 00 01 09 30 00 00 01 21 9a 04
Decode:      506 00 00 01 f6 00 00 00 01 09 30 00 00 01 21 9a 06
Decode:      557 00 00 02 29 00 00 00 01 09 30 00 00 01 21 9a 08
Decode:     1085 00 00 04 39 00 00 00 01 09 30 00 00 01 21 9a 0a
Decode:     1761 00 00 06 dd 00 00 00 01 09 30 00 00 01 21 9a 0c
Decode:     2065 00 00 08 0d 00 00 00 01 09 30 00 00 01 21 9a 0e
Decode:     1707 00 00 06 a7 00 00 00 01 09 30 00 00 01 21 9a 10
Decode:     3770 00 00 0e b6 00 00 00 01 09 30 00 00 01 21 9a 12
Decode:     4699 00 00 12 57 00 00 00 01 09 30 00 00 01 21 9a 14
Decode:     3640 00 00 0e 34 00 00 00 01 09 30 00 00 01 21 9a 16
Decode:     3683 00 00 0e 5f 00 00 00 01 09 30 00 00 01 21 9a 18
Decode:     4101 00 00 10 01 00 00 00 01 09 30 00 00 01 21 9a 1a
Decode:     3491 00 00 0d 9f 00 00 00 01 09 30 00 00 01 21 9a 1c
Decode:     4144 00 00 10 2c 00 00 00 01 09 30 00 00 01 21 9a 1e
Decode:     4717 00 00 12 69 00 00 00 01 09 30 00 00 01 21 9a 20
Decode:     4153 00 00 10 35 00 00 00 01 09 30 00 00 01 21 9a 22

That's size followed by first 16 bytes, it looks a bit strange.

Looks like there's a 4 byte length code, and then a 00 00 00 01 start code.
Normally you get one or the other. I'm not sure if this is a valid stream.

I've found if I remove the first 4 bytes of each video frame, it does decode (with some corruption - possibly due to other unwanted length codes inside the packets)

[jrowebster]

you can test the stream with rtmpdump -r "rtmp://cp49989.live.edgefcs.net:1935/live/" -v -y "streamRM1@2564" -o /tmp/livevideo | omxplayer -o hdmi /tmp/livevideo command. so you say omxplayer can not do anything with that?

[deborah-c]

Baseline is not (as one might expect) a subset of main profile, but allows a number of (somewhat complicated) error recovery features to be turned on. Constrained baseline just means the intersection of baseline and main profiles, and won't cause problems in the least. The problem here appears to be container-related; I'll take a look shortly.

[popcornmix]

Can you try updating firmware (with rpi-update) and testing your stream?

[popcornmix]

This is believed to be fixed. Please reopen if there is still a problem.