[FFmpeg-user] Request for advise on performance - transcoding on the fly

NokNok Developer developer at noknok.net
Mon May 2 21:14:38 CEST 2011


Im not all that familiar with XMBC, but its probably not buffering as 
you would think it to be, but more of each time XMBC goes back to 
request data, its getting a new filesize (as it is growing), so it needs 
to reseek to the end of the file to gather timestamp information, then 
reseek back to where it was, and it may be that its sucking down the 
whole thing from beginning again.

Best would to do an wireshark trap of the exchange and im sure you will 
see whats going on.

again, the issue is that the containers you are using are NOT live 
streamable.  They can be made to be, but in the form you are using it, 
they are not "natively".  XMBC is a normal media player, and it will see 
the size in the HTTP response, and say OK, so its 500,000 bytes, let me 
seek to the end, get the timestamp info so I know how long in time it 
is, then will attempt to seek back, and so on.



On 5/2/2011 9:18 AM, Charu Palkar wrote:
> Hi Shawn,
>
> But what about the buffering issue I see with XMBC with the same same
> transcoding.
>
> Any explaination for that ?
>
> Thanx
>
> Charu
> --
>
>
>
> ----- Original Message ----
> From: NokNok Developer<developer at noknok.net>
> To: ffmpeg-user at ffmpeg.org
> Sent: Sun, May 1, 2011 9:06:35 PM
> Subject: Re: [FFmpeg-user] Request for advise on performance - transcoding on
> the fly
>
> Neither of those streams you are doing are "live transport" streams.
>
> For example the WD LIVE stops because when it issues its 1st GET, it
> also gets the CURRENT size of the file, at that point in time, and then
> thats all it asks for.  You need to use a live streaming container/player.
>
> eg: HLS (Apple M3U8), or FLV with Flash Player, or ASF Streaming, etc. 
> There are other approaches, as to streaming in chunked http, etc.
>
> Shawn
>
> On 5/1/2011 7:27 PM, Charu Palkar wrote:
>> Hi,
>>
>> I am new to the forum and would like guidance.
>>
>> System :
>>        Server : Rackable
>>        CPU :  AMD Opteron  (2GHZ) Dual CPU
>>        RAM : 2 Gb
>>        Disk  : SATA  ( 250GB x 4 disks )  -  3 disks configured as RAID0
> (3Ware)
>>        Network :  1 Gig
>>        OS : Slackware - 13.1
>>
>> Command :
>>          ffmpeg -benchmark -i
>> /mnt/samba/share/test/Baraka.1992.BRrip.H264.AAC.ITS-ALI.mp4 -threads 4
> -target
>> ntsc-dvd -aspect 16:9 test.mpg
>>
>> NOTES :
>>          Only one CPU has 90% (sys + user),  others 4% (sys + user),  no wait on
>> I/O
>>          There is no swapping, initial page faults is 11 and remains constant
> for
>> the entire time
>>          Both files input and output are located on the RAID partition
>>          The time it takes to transcode is 20% higher than the run-time of the
>> media file
>>          Nothing else is running on the server
>>          ffmpeg - Built with ARCH=x86_64  CPU=opteron
>>
>> QUESTIONS :
>>          Q : What else can I do to speed up the transcoding  to take less time
>> than
>> run-time of media file ?
>>                    + To use for on-the-fly transcode with a media server.
>>
>>          Background : Installed media server  'serviio' and transcoding
>> on-the-fly-enabled. The following command is invoked.
>>
>>                              ffmpeg -i
>> /mnt/samba/share/test/Baraka.1992.BRrip.H264.AAC.ITS-ALI.mp4 -y -threads 4
>> -vcodec mpeg2video
>>                                        -sameq -r 23.976 -g 15 -copyts -acodec
> ac3
>> -ab 192k -ac 6 -map 0:0 -map 0:1 -sn -f mpegts
>>
>>    /mnt/samba/trans_tmp/Serviio/transcoding-temp-2-MPEG2TS.stf
>>
>>                              CPU Usage is 60% per core and no wait on I/O,
>> swapping.
>>
>>                              Viewing using WDTV Live  streaming stops after 31
>> secs consistently
>>                              Viewing using  XMBC on WinXP  stream starts
>> buffering
>> after  7 mins or 3 mins of play, takes about 8 to 10 seconds to catch up
>>                              Cabled network 100 MB connection on WinXP the
>> network
>> usage varies between  7% to 50%
>>
>>          Q : What can be done to make transcoding on-the-fly continuous ?
>>
>> Any and all help is greatly appreciated.
>>
>> Thanx
>>
>> Charu Palkar
>> --
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user


More information about the ffmpeg-user mailing list