lesto
Posts: 31
Joined: Mon Sep 12, 2011 4:12 pm

Re: confused about H264 encoding

Mon Oct 15, 2012 11:44 am

YUV only works for low resolution video, if i try resolution bigger than 160x120 i get dmesg saying that the webcam does not have enough bandwidth. (tried with and without external USB active hub)

So getting mjpg stream from the cam is the only way to get it working at decent resolution.

My final goal is to stream the image at the best resolution and framerate and almost live on intenet, where my maximum upload bandwidth is 50kB/s at best.

linuxstb
Posts: 77
Joined: Sat Jul 07, 2012 11:07 pm

Re: confused about H264 encoding

Mon Oct 15, 2012 8:20 pm

cocomic wrote:somehow related to this topic is what I'm aiming to achieve as well:
- transcode a http mpeg2 ts stream (coming through LAN from a Dreambox 500 HD, SD or HD) into a realtime x264 stream (but a lower bitrate, something between 4-500 kbps) to be able to watch the satellite broadcasts when I'm not at home. The final aim is to not have to remotely power-up my pc and do the above with VLC.
I have a similar aim (but transcoding from and to tvheadend's internal "htsp" streaming format), and am curious to know whether either of the following are at least theoretically possible in real-time:

1) SD MPEG-2 to lower bitrate (and possibly lower resolution) SD H264
2) HD H264 to lower bitrate SD H264

I've implemented a software MPEG-2 decoder, so using that and the example encoder should just about work (for relatively low bitrate SD MPEG-2 streams), but that would leave very little room for re-encoding the audio.

With today's 512MB announcement, I'm wondering if this will help enable simultaneous decoding and encoding, or if available RAM on the GPU isn't the limitation.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7098
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: confused about H264 encoding

Mon Oct 15, 2012 8:26 pm

linuxstb wrote: 1) SD MPEG-2 to lower bitrate (and possibly lower resolution) SD H264
2) HD H264 to lower bitrate SD H264

I've implemented a software MPEG-2 decoder, so using that and the example encoder should just about work (for relatively low bitrate SD MPEG-2 streams), but that would leave very little room for re-encoding the audio.
I would say yes to 1, and probably to 2 (depending on the HD stream). You would want to use a tunneled OpenMAX pipeline to decode and encode without requiring the decoded data on the ARM.
I wouldn't expect a memory problem, even on a 256M part.

However someone has to write and debug the OpenMAX pipeline, and whilst that is a small amount of code, it needs a good understanding of the spec, and is tricky to get right.

User avatar
kulve
Posts: 26
Joined: Mon Sep 24, 2012 7:05 pm
Location: Finland

Re: confused about H264 encoding

Tue Oct 16, 2012 6:39 am

linuxstb wrote: 2) HD H264 to lower bitrate SD H264
I was about to say that changing the resolution could be a heavy process but it seems that Broadcom actually provides some support for it in a form of OMX.broadcom.resize component.
linuxstb wrote: With today's 512MB announcement, I'm wondering if this will help enable simultaneous decoding and encoding, or if available RAM on the GPU isn't the limitation.
The extra memory doesn't increase the GPU performance at all.

But as Dom said, all that needs Broadcom specific OMX code which is not trivial to implement.

Richard_P
Posts: 39
Joined: Mon Jun 11, 2012 10:43 am

Re: confused about H264 encoding

Sat Oct 20, 2012 6:42 pm

linuxstb wrote:
cocomic wrote: I've implemented a software MPEG-2 decoder, so using that and the example encoder should just about work (for relatively low bitrate SD MPEG-2 streams), but that would leave very little room for re-encoding the audio.
Why do you want to re-encode the Audio? .. you're not going to save much bandwidth in the whole scheme of things.

cocomic
Posts: 3
Joined: Mon Oct 15, 2012 11:09 am

Re: confused about H264 encoding

Fri Oct 26, 2012 9:22 am

Richard_P wrote:
linuxstb wrote:
cocomic wrote: I've implemented a software MPEG-2 decoder, so using that and the example encoder should just about work (for relatively low bitrate SD MPEG-2 streams), but that would leave very little room for re-encoding the audio.
Why do you want to re-encode the Audio? .. you're not going to save much bandwidth in the whole scheme of things.
for limited 3G subscriptions, if I go down from standard 128kbps mp3 to 32kbps mp4a (or aac) it's almost 100kbps, around 45MB / hour of stream. Nevertheless, I agree that it's not a showstopper if I at least manage to just transcode in realtime the videostream.

cmason
Posts: 7
Joined: Thu Aug 09, 2012 4:38 am

Re: confused about H264 encoding

Wed Nov 07, 2012 7:40 am

dom wrote: However someone has to write and debug the OpenMAX pipeline, and whilst that is a small amount of code, it needs a good understanding of the spec, and is tricky to get right.
Any pointers to sample code about how to do decode and encode without displaying the video? I'd also like to be able to scale the video.

I've found:

http://www.khronos.org/files/openmax_il_spec_1_0.pdf
/opt/vc/src/hello_pi/hello_video
/opt/vc/src/hello_pi/hello_encode

I'm seeing references to ILCLIENT_T . I'm assuming this is some broadcom extension?

Are there other pieces I need to understand?

-c

kazu
Posts: 1
Joined: Sat Dec 08, 2012 12:37 pm

Re: confused about H264 encoding

Sat Dec 08, 2012 12:51 pm

I'm currently working on a cleaned-up C++ version for the encoding example that receives raw RGB24 from stdin and writes encoded version to stdout.

I noticed that there might be a problem with reading the output buffer. In my case the buffer seems to have a size of 64kb. But what happens when the resulting, encoded frame is larger than that? Wrapping the OMX_FillThisBuffer in a loop until OMX_BUFFERFLAG_ENDOFFRAME is set, fixed that problem for me:

Code: Select all

do {

	// fill result buffer with encoded frame
	ret = OMX_FillThisBuffer(ILC_GET_HANDLE(video_encode), out);
	if (ret != OMX_ErrorNone) { ... error handling ... }

	// flush encoded frame to output-stream
	unsigned int read = fwrite(out->pBuffer, 1, out->nFilledLen, stderr);
	if (read != out->nFilledLen) { ... error handling ... }

} while ( !(out->nFlags & OMX_BUFFERFLAG_ENDOFFRAME) );
This feature of the Raspberry is really cool. The resulting data can be used as-is with mkvmerge. I thought that mplayer had an option to handle it too.. I tried

Code: Select all

mplayer -demuxer h264es video.h264
but it didn't work. Perhaps I missed something.

Thx @ all contributors for this nice encoding feature ;)

User avatar
meltwater
Posts: 1015
Joined: Tue Oct 18, 2011 11:38 am

Re: confused about H264 encoding

Thu May 16, 2013 11:16 am

lesto wrote:yes!
I've also created a 06rpi.conf into /etc/ld.so.conf.d, witch contains "/opt/vc/lib", and then runned ldconfig.
so, easy step for everyone:
1. git clone https://github.com/raspberrypi/firmware.git
2. cd ./firmware/opt/vc/src/hello_pi
3. mkdir rpi-encode, and copy kulve's file
4. ./recompile into hello_pi
5. make into rpi-encode
6. if you get shared library error create a file .conf into /etc/ld.so.conf.d witch contains "/opt/vc/lib"
7. enjoy

kulve, now i'll start to study your code and find out out to encode directly to /dev/video0 , but i'm really noob on kernel and arm side, so any help is appreciated
Sorry to drag this from the depths, just wondering if the above is still the way to get this working?

Now the camera is out, it would be great to be able to use the hardware for encoding stuff afterwards (such as time-lapse shots etc). I did have a try with the above, but didn't get very far.
Not quite sure now to know it is using the hardware encoder either.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam

ramoncio
Posts: 1
Joined: Tue Apr 23, 2013 7:36 am

Re: confused about H264 encoding

Thu Jul 04, 2013 2:40 am

I have been trying raspbmc every few months, and finally vdr works properly with rpi, at least as a backend.
I have a Hauppauge WinTV HVR-900 usb tuner and a rpi model B with latest raspbmc installed.
All my channels (DVB-T MPEG2 SD PAL-B and HD h264 1080p) are streamed to network clients perfectly.
Recordings also work great, even in a nfs share.
I have tried to use the same raspbmc as xbmc frontend, but video is a bit jerky on HD channels, both with vnsi and with xvdr plugins, so at the moment I'll focus on using it as a vdr backend.

VDR is ready to transcode video on the fly using vdr-plugin-streamdev-server.
If you use a core2duo or higher you can transcode SD channels without buffering problems, but with rpi cpu it doesn't work - CPU goes bananas.

This is the script used by vdr-plugin-streamdev-server to transcode video:
http://projects.vdr-developer.org/git/v ... rnremux.sh
It has a few options, but basically it uses mencoder to encode the video on the fly using pipes.
Then you can watch the original streams in http://yr.vdr.ip.adr:3000/channels.html and you can watch the transcoded streams in http://yr.vdr.ip.adr:3000/EXT/channels.html
It would be great to get a working omx-externremux.sh or a omx-mencoder.
With h264 realtime encoding on the rpi, we could stream the tv SD channels everywhere from a home adsl 20Mb/1Mb connection, and watch it on any tablet/mobile/computer.
But openmax_il_spec_1_0.pdf looks way beyond my reach, we'll have to wait for now, but I hope it won't be long.

manabk
Posts: 14
Joined: Fri Sep 06, 2013 8:26 am

Re: confused about H264 encoding

Fri Sep 06, 2013 8:31 am

Has there been any progress with this?

Return to “General discussion”