MP4 avc streaming (transcoding) support

[happy.neko]

Hi.

Anyone trying to add MP4 trancoding support to PS3MS? I think it'll be very useful for alternate media renderers like smartphones or tabltes (iPhones, iPads, androids etc) for a couple of reasons:

• better bandwidth utilization (these devices mostly wireless and mpeg2 with reasonable quality has very high bitrate)
• most of these devices have some sort of hardware acceleration for "native" formats, usually MP4 AVC/AAC. On the other hand decoding for mpeg-2 usually software only, requires additional apps and very power consuming. For example ipad 1 is not fast enough to play mpeg-2 720p without stuttering.

And that why I decided to implement mp4 streaming. I managed to add basic support, please check this dev branch https://github.com/Happy-Neko/ps3medias ... ng-support

I'm using modified AirPlayer.conf for testing purposes with AirAV (free) and AirPlayer ipad apps. There are some other DLNA players in AppStore but they are all almost identical: native playback for MP4s/MOVs and ffmpeg software decoding for anything else.

As you can see TranscodeVideo=MP4AVCAAC is new option used for mp4 transcoding with mencoder. And it works in the sense that resulting mencoder commandline, for ex.

Code: Select all

mencoder -ss 0 ~/test.mkv   -oac lavc -of lavf -lavfopts format=mp4 -ovc x264 -channels 2 -lavdopts debug=0:threads=2 -lavcopts autoaspect=1:vcodec=libx264:acodec=aac:abitrate=224:threads=2 -x264encopts preset=superfast:profile=baseline:bframes=0:nocabac:global_header:partitions=all:level=31 -subfont /usr/share/fonts/truetype/msttcorefonts/Arial.ttf -subfont-text-scale 3 -subfont-outline 1 -subfont-blur 1 -subpos 98   -subdelay 20000   -ofps 24000/1001   -lavdopts fast -mc 0 -noskip -af lavcresample=48000 -srate 48000 -o ~/mencoder-test.mp4

produces working mp4 files with good encoding speed (~60 fps for 720p on core2 CPU) if run separately. And files are playable on iPad. The problem lies on realtine streaming / buffering with PS3MS. After few second after playback start I see on debug.log

Code: Select all

[New I/O server worker #1-3] DEBUG Setting InputStream new position to: 9,223,372,036,854,773,760

with insane new stream position followed by buffer overflow error and streaming failure. Maybe someone with better PS3MS knowledge can look into this problem?

[Raptor399]

Nice attempt!

Without having delved into it, I would suspect the byte juggling code at the bottom of BufferedOutputFileImpl.java. In the past I have tried to avoid that by using the UnbufferedOutputFile.java, but that doesn't seem to work with the current code any more.

[happy.neko]

Without having delved into it, I would suspect the byte juggling code at the bottom of BufferedOutputFileImpl.java.

Here goes my hope for an easy fix. LOL
Looks like BufferedOutputFileImpl depends on mpeg transport stream structure for seeking, no way I'll be able to implement something like this for MP4 stream.

[Raptor399]

I never quite understood why PMS code needs to be involved in dealing with the formats being streamed.
Why not simply terminate the current stream or transcode, and fire up a fresh stream or transcode on the required seek position? It would probably take a couple of seconds (like when you start media from the beginning), but it would work 100% of the time and for any format being streamed.

It would make things much more straightforward and PMS code could just focus on passing on commands from the client to the transcoding engines without bothering about the transport itself.

[happy.neko]

I agree with you completely. The way it works now looks very overengineered and prone to bugs. I also don't understand what are the benefits of memory buffering over simple dumping stream to renderer and leaving buffering to it.

[SubJunk]

Yeah I've often wondered that myself, we should ask shagrath if there was a reason to make it like that, maybe he tried it and it didn't work as expected

[ExSport]

.... I also don't understand what are the benefits of memory buffering over simple dumping stream to renderer and leaving buffering to it.

HW has not so big buffer so more complex scenes will lag because server will not be able to feed renderer continuously with required data stream. Also it can happen when server will have some memory/cpu spikes so buffer can help in these cases. It is the same like with DVD burners. Every burner have small internal buffer but also burning software creates buffer in memory to not buffer underrun.
I think some small buffer is useful in these cases to overcome similar gaps. Without it it will stutter everytime when CPU will not catchup realtime transcoding for few complex scenes but for the rest all will be ok?
With seeking I aggree with all of you, but I think buffer is very usefull for many cases. Eg. when I am transcoding to 2 renderers at the same time, buffer is a must to catch both transcoding without any jerky parts.

[happy.neko]

If the server can't feed client due to CPU limitations it certainly can't feel buffer either. We can wrap input stream into BufferedInputStream or use temp files to provide additional protection against CPU utilization spikes but necessity of such approach is up to debate. My point was that I don't see the reason for PS3MS to operate on bitsream level like it does now. We should dump transcoded stream to client as-is and leave processing to it.

[ExSport]

If the server can't feed client due to CPU limitations it certainly can't feel buffer either...

It can easily in 99% of the time but some spikes like starting to play on another renderer, using rewind or fast forward on other renderer can overload whole server so another renderer will not be feeded by data due to no memory cache on server so no pre-transcoded data in memory.
I can see it many times in PMS GUI that one buffer is going down while another one is growing up but in few secs again both are growing so everyting plays without problem. Without precache, everytime when buffer will go down for a short time, it will stutter on renderer.
But maybe it is only my opinion