0.6, "Sony Bravia TV" profile, mp4 stuttering

[Illico]

It's likely that newer Bravia models are more capable with h264. For the older sets though, like my W5500, transcoding to mpeg seems to be the only somewhat sure way to get things working.

I'm afraid it's true (W5500 is a 2009 model)

Out of curiosity: Does transcoding fix your ratio issue? I've noticed my set to be way less picky with mpeg than it is with h264.

ratio issue is not fixed with transcoding for now...we need to implement the padding options.

[tvkdlna]

It's likely that newer Bravia models are more capable with h264. For the older sets though, like my W5500, transcoding to mpeg seems to be the only somewhat sure way to get things working.

I'm afraid it's true (W5500 is a 2009 model)

So, for the sake of stone age Sony equipment, do you vote for this change? I'd like to create the bitbucket ticket zip requested.

To be considered: Both "baseline" and "constrained baseline" are low-bandwidth h264 profiles, and transcoding them (even if they would work remuxed in new Bravias) creates negligible CPU cost. It's true that you should always remux rather than transcode, but for older Bravias remuxing just isn't an option in this case.

Edit: I just noticed zip already created the ticket. Damn the man is fast.

[Illico]

Well, ticket is opened, we'll work on this change.

[patters]

So you're only proposing to transcode H.264 that's at these 'baseline' oddball resolutions, right? (since the profile level implies a certain resolution) If so then that's fine by me. I'd object if it was all H.264. The TED talks was the one online feed that the V5500 couldn't play properly. The rest were ok.

[tvkdlna]

Turned out this wasn't the whole story.

Please test samples from this url: http://www.coveragefirst.com/portal/server.pt?open=17&objID=1084&DirMode=1&parentname=Dir&parentid=1&mode=2

They are of the "main" h264 profile, but won't play without stuttering in my W5500. How is it with newer Bravias?

'ffmpeg -i' of one of them:

  Code:

ffmpeg version N-31480-g8bc3a48, Copyright (c) 2000-2011 the FFmpeg developers
  built on Jul 14 2011 23:37:53 with gcc 4.4.2
  configuration: --enable-static --disable-shared --disable-ffplay --disable-ffserver --enable-memalign-hack --enable-libmp3lame --enable-librtmp --extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --arch=x86 --enable-runtime-cpudetect --enable-pthreads --target-os=mingw32 --cross-prefix=i686-mingw32- --pkg-config=pkg-config
  libavutil    51. 11. 0 / 51. 11. 0
  libavcodec   53.  8. 0 / 53.  8. 0
  libavformat  53.  6. 0 / 53.  6. 0
  libavdevice  53.  2. 0 / 53.  2. 0
  libavfilter   2. 25. 0 /  2. 25. 0
  libswscale    2.  0. 0 /  2.  0. 0

Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 50.00 (50/1)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Leadership_Team _v3.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42isomavc1
    creation_time   : 2011-06-03 14:31:34
    encoder         : HandBrake 0.9.5 2011010300
  Duration: 00:05:39.77, start: 0.000000, bitrate: 461 kb/s
    Stream #0.0(und): Video: h264 (Main), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 392 kb/s, 50 fps, 50tbr, 90k tbn, 180k tbc
    Metadata:
      creation_time   : 2011-06-03 14:31:34
    Stream #0.1(eng): Audio: aac, 44100 Hz, mono, s16, 62 kb/s
    Metadata:
      creation_time   : 2011-06-03 14:31:34
At least one output file must be specified

If I manually put it through the same ffmpeg procedure Serviio does:

  Code:

"C:\Program Files\Serviio\lib\ffmpeg.exe" -i "Leadership_Team _v3.mp4" -y -vcodec copy -vbsf h264_mp4toannexb -copyts -acodec ac3 -ab 384k -ac 1 -map 0:0 -map 0:1 -sn -f mpegts test.ts

the resulting 'test.ts' shows strange characteristics:

• Video: MPEG4 Video (H264) 640x368 119047.62fps [Video - AVC (H.264), Main Profile, Level 3.1, 640x368, 119047.619 fps (0100,e0,00)]
• Audio: Dolby AC3 44100Hz mono 384kbps [Audio - Dolby Digital, 44.1 kHz, 1 chn, 384.0 kbit/s (0101,bd,00)]

Now, that's a high fps (actually made my W5500 reboot).

These samples seem to have some common features with my earlier stuttering samples:

• major_brand: mp42
• high (90k) tbn

Could there be something wrong with the Serviio ffmpeg procedure?

[patters]

The 2009 Bravias in general cannot play H.264 that doesn't confirm to AVCHD-specified resolutions, so that may be a better way to make the distinction between what will play natively and what needs transcoding, and since AVCHD is a standard the same behaviour may also apply to other devices. I have already created a ticket for this:
https://bitbucket.org/xnejp03/serviio/i ... resolution

So it may be that if Zip implements this basic form of resolution sorting we could apply it to all videos for the 2009 Bravias, and only to the OnlineTranscoding section for the 2010/2011 models.

However, in the case of that latest example I would say the problem lies with how it has been encoded (that crazy frame rate).

[tvkdlna]

The 2009 Bravias in general cannot play H.264 that doesn't confirm to AVCHD-specified resolutions [...]

Could you please download and test these two samples in V5500 with unmodified 0.6 profile:

• http://av.watch.impress.co.jp/docs/20050728/avc768.mp4
• http://av.watch.impress.co.jp/docs/20050728/avc384.mp4

Because this is bothering me: They work remuxed in my W5500. So there evidently is h264 material that's not conforming to AVCHD resolutions, but still works remuxed (at least in W5500).

If they don't work remuxed in V5500, I give up trying to find a remuxing solution to this (as it likely wouldn't apply to anything but my particular Bravia model), and go along with your idea of transcoding any non-conforming resolution.

[patters]

Yep both of those play remuxed on Bravia V5500. Strange - 384 is not even a valid AVCHD-SD resolution according to http://en.wikipedia.org/wiki/AVCHD

[tvkdlna]

Ok then, I'll keep digging.

So far I've found that in all my h264 samples that stutter, ffmpeg remux seems to do something bad to video stream fps. That is, after remux there is no fps whatsover. Here's an example:

  Code:

"C:\Program Files\Serviio\lib\ffmpeg.exe" -i "Leadership_Team _v3.mp4" -y -vcodec copy -vbsf h264_mp4toannexb -copyts -acodec ac3 -ab 384k -ac 1 -map 0:0 -map 0:1 -sn -f mpegts test.ts

Before remux:

  Code:

"C:\Program Files\Serviio\lib\ffmpeg.exe" -i "Leadership_Team _v3.mp4"
ffmpeg version N-31480-g8bc3a48, Copyright (c) 2000-2011 the FFmpeg developers
  built on Jul 14 2011 23:37:53 with gcc 4.4.2
  configuration: --enable-static --disable-shared --disable-ffplay --disable-ffserver --enable-memalign-hack --enable-libmp3lame --enable-librtmp --extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --arch=x86 --enable-runtime-cpudetect --enable-pthreads --target-os=mingw32 --cross-prefix=i686-mingw32- --pkg-config=pkg-config
  libavutil    51. 11. 0 / 51. 11. 0
  libavcodec   53.  8. 0 / 53.  8. 0
  libavformat  53.  6. 0 / 53.  6. 0
  libavdevice  53.  2. 0 / 53.  2. 0
  libavfilter   2. 25. 0 /  2. 25. 0
  libswscale    2.  0. 0 /  2.  0. 0

Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 50.00 (50/1)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Leadership_Team _v3.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42isomavc1
    creation_time   : 2011-06-03 14:31:34
    encoder         : HandBrake 0.9.5 2011010300
  Duration: 00:05:39.77, start: 0.000000, bitrate: 461 kb/s
    Stream #0.0(und): Video: h264 (Main), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 392 kb/s, 50 fps, 50tbr, 90k tbn, 180k tbc
    Metadata:
      creation_time   : 2011-06-03 14:31:34
    Stream #0.1(eng): Audio: aac, 44100 Hz, mono, s16, 62 kb/s
    Metadata:
      creation_time   : 2011-06-03 14:31:34
At least one output file must be specified

After remux:

  Code:

"C:\Program Files\Serviio\lib\ffmpeg.exe" -i test.ts
ffmpeg version N-31480-g8bc3a48, Copyright (c) 2000-2011 the FFmpeg developers
  built on Jul 14 2011 23:37:53 with gcc 4.4.2
  configuration: --enable-static --disable-shared --disable-ffplay --disable-ffserver --enable-memalign-hack --enable-libmp3lame --enable-librtmp --extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --arch=x86 --enable-runtime-cpudetect --enable-pthreads --target-os=mingw32 --cross-prefix=i686-mingw32- --pkg-config=pkg-config
  libavutil    51. 11. 0 / 51. 11. 0
  libavcodec   53.  8. 0 / 53.  8. 0
  libavformat  53.  6. 0 / 53.  6. 0
  libavdevice  53.  2. 0 / 53.  2. 0
  libavfilter   2. 25. 0 /  2. 25. 0
  libswscale    2.  0. 0 /  2.  0. 0
[mpegts @ 01a29c60] max_analyze_duration 5000000 reached at 5014400

Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 50.00 (50/1)
Input #0, mpegts, from 'test.ts':
  Duration: 00:05:39.76, start: 1.400000, bitrate: 927 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0.0[0x100]: Video: h264 (Main), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 180k tbc
    Stream #0.1[0x101](eng): Audio: ac3, 44100 Hz, mono, s16, 384 kb/s
At least one output file must be specified

Notice that after remux, in stream #0.0; "50 fps" is missing. This likely is the reason why MPCHC reported these ridiculously high frame rates I mentioned earlier: in the lack of actual fps information, it's some kind of estimate based on god knows what. More importantly, this may also be the reason why Bravias stutter. Maybe they're in trouble without the h264 video stream fps information.

I also found this not to be the only case ffmpeg h264 remux is causing problems with mpegts, see: http://ffmpeg.org/pipermail/ffmpeg-user/2011-April/000514.html

There may actually be a bug in ffmpeg h264 remuxing and we may have to transcode because of it. Which could also mean that this case eventually has little or nothing to do with the video resolution.

To be noted: I'm not a guru when it comes to ffmpeg, I just google. Someone with actual expertise: please throw in better ideas, or better yet, a solution on how you make ffmpeg to maintain h264 video stream fps while remuxing to mpegts. If i knew that, I could confirm or rule out this missing fps being an issue.

[tvkdlna]

Here's some more:

http://ffmpeg-users.933282.n4.nabble.com/MPEGTS-no-PCR-when-muxing-H264-td2989848.html
http://ffmpeg-users.933282.n4.nabble.com/MPEG-TS-structure-td2133188.html

Be aware the the mpegts file output from ffmpeg is not very friendly to set top boxes. However, software decoders can usually play the .ts without a problem.

Seems that ffmpeg "vcodec copy" has always been more or less broken in the context of trying to produce mpegts from h264.

[patters]

I wonder if the same clips remuxed with TSMuxer play.

[tvkdlna]

Since I haven't been able to find any good information on this, I tried the brute force approach. I downloaded numerous mp4 samples from various sites and plainly tested how they work with W5500 and current 0.6 profile. See attached file "data.csv".

Based on the data, I found a likely candidate for the cause of the h264 stutter: mp42 codec. In most samples where mp42 was used, the output was stuttering. I don't know if this is an issue of ffmpeg or Bravias, but it's definitely there.

My conclusions:

1. This is not about the screen resolution. All the samples I tried worked - or didn't work - full screen, regardless of the resolution.
2. Overall support for h264 is somewhat dodgy in older Bravias. Albeit some of the material seems to work, most of the time there's issues.
3. The only way to make h264 work for sure is to transcode. After I forced transcode on the samples, everything worked like gravity.
4. At the very least mp42 codec should be detected and transcoded.

'ffmpeg -i' does give indication of the codec:

  Code:

...
  Metadata:
    major_brand     : mp42
...

but I guess matching it in the profile would require new functionality.

The easy way, since there seems to be issues anyway, is to transcode all h264 material.

[tvkdlna]

1. This is not about the screen resolution. All the samples I tried worked - or didn't work - full screen, regardless of the resolution.
2. Overall support for h264 is somewhat dodgy in older Bravias. Albeit some of the material seems to work, most of the time there's issues.
3. The only way to make h264 work for sure is to transcode. After I forced transcode on the samples, everything worked like gravity.
4. At the very least mp42 codec should be detected and transcoded.

Oh, forgot this:

1. This is not about the h264 "baseline" profile either, although it first seemed to be the case. Larger survey presented stuttering samples of all h264 profiles, so matching "baseline" only solves part of the problem. https://bitbucket.org/xnejp03/serviio/issue/412/fix-stuttering-on-sony-devices-for should be changed to concern transcoding all h264 material, or at the very least everything encoded with mp42 codec.

I will try to come up with a profile proposal later.

[Illico]

See attached file "data.csv".

Good jobs.
When I have time,I'll look into my samples library and I'll search for mp42 codec.

So, until a release is made with this fix, is the interim solution to update the Bravia proile as per viewtopic.php?f=11&t=3303&start=10#p22035?

[tvkdlna]

So, until a release is made with this fix, is the interim solution to update the Bravia proile as per viewtopic.php?f=11&t=3303&start=10#p22035?

You can use the following profile. It transcodes, amongst other things, all mp4 material both local & online.

  Code:

   <Profile id="9" name="Sony Bravia TV" extendsProfileId="1">
      <!-- All models *except* 2011 series which need a separate profile -->
      <Detection>
         <UPnPSearch>
            <!-- 2009 models known to support UPnPSearch, and all 2010 models -->
            <FriendlyName>BRAVIA KDL-\d{2}(WE5|(E53|E55|V55|V56|W55|W57|Z55|Z57)\d0|[EHLNPB]X\d[01]\d) *</FriendlyName>
         </UPnPSearch>
         <HttpHeaders>
            <!-- 2008 models, and possibly older or different region 2009 firmwares which may not support UPnPSearch -->
            <X-AV-Client-Info>.*BRAVIA KDL-\d{2}(([A-Z](1|5|E1|R1|BR45|BR9|[1357]0\d{2}|4\d{3}))|(S55|S57|W51|Z51|Z58)\d0) *</X-AV-Client-Info>
         </HttpHeaders>
      </Detection>
      <DeviceDescription>
         <!-- act as WMP so that the TV doesn't show root categories -->
         <ModelName>Windows Media Player Sharing</ModelName>
         <ModelNumber>3.0</ModelNumber>
         <Manufacturer>Microsoft Corporation</Manufacturer>
      </DeviceDescription>
      <ContentDirectoryMessageBuilder>org.serviio.upnp.service.contentdirectory.SonyDLNAMessageBuilder</ContentDirectoryMessageBuilder>
      <ContentDirectoryDefinitionFilter>org.serviio.upnp.service.contentdirectory.definition.WMPContentDirectoryDefinitionFilter</ContentDirectoryDefinitionFilter>
      <MediaFormatProfiles>
         <!-- rename native mpeg2ts with h264/ac3 ac3 formats to those supported by the tv -->
         <MediaFormatProfile mime-type="video/vnd.dlna.mpeg-tts" name="AVC_TS_HD_24_AC3,AVC_TS_HD_50_AC3,AVC_TS_HD_60_AC3,AVC_TS_HD_EU">AVC_TS_MP_HD_AC3</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/vnd.dlna.mpeg-tts" name="AVC_TS_HD_24_AC3,AVC_TS_HD_50_AC3,AVC_TS_HD_60_AC3,AVC_TS_HD_EU">AVC_TS_MP_SD_AC3</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/vnd.dlna.mpeg-tts" name="AVC_TS_HD_24_AC3_T,AVC_TS_HD_50_AC3_T,AVC_TS_HD_60_AC3_T,AVC_TS_HD_EU_T">AVC_TS_MP_HD_AC3_T</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/vnd.dlna.mpeg-tts" name="AVC_TS_HD_24_AC3_T,AVC_TS_HD_50_AC3_T,AVC_TS_HD_60_AC3_T,AVC_TS_HD_EU_T">AVC_TS_MP_SD_AC3_T</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/vnd.dlna.mpeg-tts" name="AVC_TS_HD_24_AC3_T,AVC_TS_HD_50_AC3_T,AVC_TS_HD_60_AC3_T,AVC_TS_HD_EU_T">AVC_TS_HP_HD_MPEG1_L2_T</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/vnd.dlna.mpeg-tts" name="AVC_TS_HD_24_AC3_T,AVC_TS_HD_50_AC3_T,AVC_TS_HD_60_AC3_T,AVC_TS_HD_EU_T">AVC_TS_HP_SD_MPEG1_L2_T</MediaFormatProfile>
         <!-- rename transcoded mpeg2ts with h264 to one of the TV's supported profiles -->
         <MediaFormatProfile mime-type="video/mpeg" name="AVC_TS_HD_24_AC3_ISO,AVC_TS_HD_50_AC3_ISO,AVC_TS_HD_60_AC3_ISO,AVC_TS_HD_EU_ISO">AVC_TS_MP_HD_AC3_ISO</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/mpeg" name="AVC_TS_HD_24_AC3_ISO,AVC_TS_HD_50_AC3_ISO,AVC_TS_HD_60_AC3_ISO,AVC_TS_HD_EU_ISO">AVC_TS_MP_SD_AC3_ISO</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/mpeg" name="AVC_TS_HD_24_AC3_ISO,AVC_TS_HD_50_AC3_ISO,AVC_TS_HD_60_AC3_ISO,AVC_TS_HD_EU_ISO">AVC_TS_HP_HD_MPEG1_L2_ISO</MediaFormatProfile>
         <MediaFormatProfile mime-type="video/mpeg" name="AVC_TS_HD_24_AC3_ISO,AVC_TS_HD_50_AC3_ISO,AVC_TS_HD_60_AC3_ISO,AVC_TS_HD_EU_ISO">AVC_TS_HP_SD_MPEG1_L2_ISO</MediaFormatProfile>
      </MediaFormatProfiles>
      <Transcoding>
         <!-- For dvr-ms files force mpeg2video transcoding to fix monotone timestamps problems -->
         <Video targetContainer="mpegts" targetACodec="ac3" forceVTranscoding="true">
            <Matches container="asf" vCodec="mpeg2video" />
         </Video>
         <!-- Transcode all video on MPEG-TS stream with MPEG2VIDEO and ac3 audio transcoding -->
         <Video targetContainer="mpegts" targetVCodec="mpeg2video" maxVBitrate="17000" targetACodec="ac3" aBitrate="192">
            <Matches container="asf" />
            <Matches container="avi" />
            <Matches container="mp4" />
            <Matches container="matroska" />
            <Matches container="flv" />
            <Matches container="wtv" />
            <Matches container="ogg" />
         </Video>
         <Audio targetContainer="lpcm">
            <!-- To allow "pause" then "resume" functions and album art for TVs that support it - transcode to mp3 instead -->
            <Matches container="asf" />
            <Matches container="mp4" />
            <Matches container="ogg" />
            <Matches container="flac" />
         </Audio>
      </Transcoding>
      <OnlineTranscoding>
         <!-- Transcode all video on MPEG-TS stream with MPEG2VIDEO and ac3 audio transcoding -->
         <Video targetContainer="mpegts" targetVCodec="mpeg2video" maxVBitrate="17000" targetACodec="ac3" aBitrate="192">
            <Matches container="asf" />
            <Matches container="avi" />
            <Matches container="mp4" />
            <Matches container="matroska" />
            <Matches container="flv" />
            <Matches container="wtv" />
            <Matches container="ogg" />
         </Video>
      </OnlineTranscoding>
   </Profile>

To be noted: Needs some work in the MediaFormatProfiles section.

[tvkdlna]

I decided to get to the bottom of this and stubborn as I am, after 23 hours of testing I now have results. See attached file "data2.csv".

Stats derived from the data:

• total samples: 154

• % of avc in total samples: 87,7
• % of avc with major problems: 15,6
• % of avc with major problems fixable with transcoding: 100,0
• % of avc with other issues: 80,0
• % of avc with other issues fixable by transcoding: 49,1

• % of avc/isom in total samples: 63,0
• % of avc/isom with major problems: 0,0
• % of avc/isom with major problems fixable with transcoding: N/A
• % of avc/isom with other issues: 97,9
• % of avc/isom with other issues fixable by transcoding: 50,5

• % of avc/mp42 in total samples: 19,5
• % of avc/mp42 with major problems: 53,3
• % of avc/mp42 with major problems fixable with transcoding: 100,0
• % of avc/mp42 with other issues: 36,7
• % of avc/mp42 with other issues fixable by transcoding: 45,5

• % of avc/others in total samples: 5,2
• % of avc/others with major problems: 62,5
• % of avc/others with major problems fixable with transcoding: 100,0
• % of avc/others with other issues: 25,0
• % of avc/others with other issues fixable by transcoding: 100,0

As I mentioned, I've been sitting with this 23 hours straight. Which means that someone please check my data & math. Not sure I'm thinking/seeing straight anymore.

But by the look of it, seems that it would make sense to a) transcode everything that's h264 or b) transcode everything that's h264 and not isom.

Now I need sleep.

Edit: Checked myself after few hours of sleep, now hopefully more relevant & sane figures. The recipe still seems to be that if it's h264 and especially if not isom, transcode it.

[tvkdlna]

Here's some more:

• total samples: 154

• % of non-avc in total samples: 12,3
• % of non-avc with major problems: 0,0
• % of non-avc with major problems fixable with transcoding: N/A *
• % of non-avc with other issues: 26,3
• % of non-avc with other issues fixable by transcoding: 80,0

• % of non-avc/isom in total samples: 1,9
• % of non-avc/isom with major problems: 0,0
• % of non-avc/isom with major problems fixable with transcoding: N/A
• % of non-avc/isom with other issues: 0,0
• % of non-avc/isom with other issues fixable by transcoding: N/A

• % of non-avc/mp42 in total samples: 7,1
• % of non-avc/mp42 with major problems: 0,0
• % of non-avc/mp42 with major problems fixable with transcoding: N/A *
• % of non-avc/mp42 with other issues: 0,0
• % of non-avc/mp42 with other issues fixable by transcoding: N/A

• % of non-avc/others in total samples: 3,2
• % of non-avc/others with major problems: 0,0
• % of non-avc/others with major problems fixable with transcoding: N/A
• % of non-avc/others with other issues: 0,0
• % of non-avc/others with other issues fixable by transcoding: N/A

* One non-avc sample (notchfirst.mp4) initially had no major problems, but developed them when transcoded.

Final conclusions:

1. If it's h264 and not isom: definitely transcode.
2. If it's h264 and isom: transcoding improves performance, but no major issues without it.
3. If it's not h264: current profile is sufficient.

There was also a single sighting of mpegts h264 that stutters (hbo-mpeg4sd-dish.ts). Don't know what to do about that and not sure it's wise to take action based on a single sample.

I rest my case for now.

[Illico]

tvkdlna : Do you disable library refresh during your test?
In fact, first time I used serviio (1 year), I had sometime movie stuttering and I discovered, it was due to the network and cpu loads during library refresh.
So now I manually set the library refresh and disabling the automatic update.

[tvkdlna]

tvkdlna : Do you disable library refresh during your test?
In fact, first time I used serviio (1 year), I had sometime movie stuttering and I discovered, it was due to the network and cpu loads during library refresh.
So now I manually set the library refresh and disabling the automatic update.

I did pay attention to both CPU and network loads, to eliminate the issues you mentioned. During testing the network was solely in the use of the test and CPU loads were consistently less than 50%, even with higher resolution transcoding and the library refresh normally on.

The Windows box I used in the test has 2x3GHz CPU and doesn't have much stuff in the library, mainly just the samples. My network is 1Gbit (although Bravia has only 100Mbit NIC).

I would dare to say that if it stuttered, it didn't do so because of the CPU or the network.