Jump to content


Photo

Air Video Server HD 2.1.0-beta3


  • Please log in to reply
97 replies to this topic

#61 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 06 March 2015 - 01:38 AM

Which CPU type exactly do you have? Can you check if you have latest Intel Drivers installed?



#62 macman104

macman104

    Advanced Member

  • Members
  • PipPipPip
  • 153 posts

Posted 06 March 2015 - 01:41 AM

I have an Intel i7-4770.

I did a check (search for driver updates through device manager) for both the Intel Graphics and the actual processor drivers and both report the drivers are up-to-date.

#63 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 06 March 2015 - 01:44 AM

It seems to have HD4600. I have computer with HD 4600 so I might be able to reproduce this. Would you be able to provide sample video? The video might actually be important here. If so, you can upload it here

 

https://www.mediafir...54ce133b8c0cb0b



#64 macman104

macman104

    Advanced Member

  • Members
  • PipPipPip
  • 153 posts

Posted 06 March 2015 - 01:50 AM

Ok, I've started the upload (H265 GStreamer Error). Sometimes it happens right when you load the video, other times, it takes between 5-20 seconds for the error to crop up.

#65 Sunrise

Sunrise

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts

Posted 06 March 2015 - 07:22 PM

Providing the x264 options is a bit tricky, because we don't specify them like in the command line.

I'm curious about the 10mbit/s quality issues. What exactly was wrong? Also, which generation intel CPU do you have?

 

Thanks for the encoder settings, they work great!

 

One question though, when I set the encoder settings in Handbrake, it instantly switches from "Veryfast" to "Medium" preset. Do you have an explanation for that? I thought you were using "Veryfast"? It seems Handbrake detects an option from your settings that is not supported for the "Veryfast" preset. Just curious though, please don't change it, because it could hurt the quality.

 

Regarding the QuickSync tests, I did them on an IvyBridge dual-core and there is a lot of blocking going on all over the place. It's very noticable when you compare it to a Handbrake encode of the same file with your provided settings.



#66 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 06 March 2015 - 08:30 PM

Veryfast is just a preset, which means it is a name for bunch of options. We take the preset as  base and then override some of them. 

 

I'm haven't noticed lot of blocking (probably depends on bitrate), but I only use HD4000 through VideoToobox (Apple drivers), most of my QuickSync tests are on HD4600. Still, the blocking, if it happens with high bitrate and appropriate presets is a bit disappointing. The benefit of QuickSync is that the encoding speed almost doesn't degrade with bitrate increase. So for streaming (not offline conversion) when your network can handle say 20mbit/s, you get very decent quality with low CPU load (we don't provide 20mbit/s for Air Video HD yet but will in future). Of course x264 at 20mbit/s would likely look even better, but encoding 1080p at 20mbit/s is very CPU intensive, while with QuickSync/VideoToolbox it can be easily done on an lower-end i3 or i5



#67 Sunrise

Sunrise

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts

Posted 06 March 2015 - 09:41 PM

Veryfast is just a preset, which means it is a name for bunch of options. We take the preset as  base and then override some of them. 

 

I'm haven't noticed lot of blocking (probably depends on bitrate), but I only use HD4000 through VideoToobox (Apple drivers), most of my QuickSync tests are on HD4600. Still, the blocking, if it happens with high bitrate and appropriate presets is a bit disappointing. The benefit of QuickSync is that the encoding speed almost doesn't degrade with bitrate increase. So for streaming (not offline conversion) when your network can handle say 20mbit/s, you get very decent quality with low CPU load (we don't provide 20mbit/s for Air Video HD yet but will in future). Of course x264 at 20mbit/s would likely look even better, but encoding 1080p at 20mbit/s is very CPU intensive, while with QuickSync/VideoToolbox it can be easily done on an lower-end i3 or i5

 

What I like the most about the current 10mbit preset is that it is extremely efficient and works very well already with a Nehalem i7 (i7 920) when doing live conversion, even on very demanding sources. Quality wise I can only see subtle differences when I look very closely with my CG246 (everything is just slightly a bit more blurry compared to the source, your deblock-settings of 1:0:0 do a good job here). No visible blocking, no block crawling, good grain retention. Even on a big screen TV it just looks perfect.

 

Since 10mbit uploads are getting a bit more common here, this preset also should work well outside (Remote WiFi) of an internal (W)LAN.

 

I certainly welcome more bitrate headroom though for internal (W)LAN.



#68 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 06 March 2015 - 11:27 PM

Ok, I've started the upload (H265 GStreamer Error). Sometimes it happens right when you load the video, other times, it takes between 5-20 seconds for the error to crop up.

 

So it looks like this is an intel bug when using QuickSync with multiple GPUs. I was able to reproduce it pretty consistently even with latest drivers.



#69 Sunrise

Sunrise

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts

Posted 08 March 2015 - 12:15 AM

Today I wanted to watch Batman Begins (Blu-Ray), which is ripped to my SSD. However, I quickly realized that something is wrong, since the movie did stutter constantly.

 

I tested other players (VLC and MPC-HC with LAVfilters) and it played fine. Then I looked up what's so specific about that movie that makes Air Video HD stutter. It's encoded in VC-1.

 

Then I remembered that you changed a regression in beta3 regarding WMV/VC-1 playback. I then checked whether there is particularly high CPU utilization, but it's between 65-85 percent, which should be fine. I then removed beta3 and installed beta2 and started the movie from the beginning again. It played perfectly fine now in Air Video HD, CPU utilization is a tiny bit better, about 65-80%.

 

I then also uninstaled VLC temporarily, so that Air Video HD falls back to LAV filters. Same result as with VLC, movie plays perfectly fine now.

 

I looked at the logs from both (beta2 and beta3) and it seems to confirm that beta3 uses the WMVideo decoders, while beta2 uses VLC (when installed), otherwise it uses LAV as a last resort. After that I uninstalled beta2 again and installed beta3.

 

I also tested with some other 1080p files lying around and they also stutter. With beta2 installed again, they play perfectly fine.

 

Now, the question is, is there something particularly wrong with the WMVideo decoders from Microsoft or the implementation in Air Video HD Server beta3? It doesn't seem to be caused by too high CPU load, because when I let Air Video HD continue to transcode while I am pausing the movie or other 1080p files, beta3 keeps stuttering, no matter what I do. And beta2 plays ALL of the VC-1 files perfectly fine.

 

Is there a way to troubleshoot this? If there would be some kind of a "force VLC decoders" option, I could probably narrow it down some more. Can you explain what is happening here?

 

This is on an i7 quad-core @3.8GHz (SMT active) with 8 threads active.



#70 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 08 March 2015 - 12:33 AM

Sunrise, I haven't made an announcement yet, but can you try this version and let me know if the problem is still there?

 

https://s3.amazonaws...D-2.1.0-x64.exe



#71 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 08 March 2015 - 12:37 AM

I looked at the commit logs and it should contain fix for VC1 through directshow. We generally prefer microsoft VC1 decoders since there are some issues with interlaced files with open source decoders.



#72 Sunrise

Sunrise

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts

Posted 08 March 2015 - 05:04 PM

Sunrise, I haven't made an announcement yet, but can you try this version and let me know if the problem is still there?

 

https://s3.amazonaws...D-2.1.0-x64.exe

 

Unfortunately, same problem here.

 

I made you three screenshots of the task manager, one from the very beginning of the movie, where there's only between 52-65% total CPU utilization and one after about 30 seconds, where there's even lower CPU in use. The third screenshot is when using beta2 (vlc decoders), which has even higher CPU utilization (sometimes peaks over 80% and stays 65-75% on average).

 

airvideo_2.1.0_vc1_stusu4k.png

 

airvideo_2.1.0_vc1_stemunk.png
 

airvideo_2.1.0_vc1_be33ubj.png

 

I am not sure what is going on.

 

Here' another one, where I transcode a H.264 file and CPU utilization is even higher, but it plays absolutely flawless.

 

airvideo_2.1.0_h264_tegu29.png



#73 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 08 March 2015 - 06:35 PM

What exactly do you mean by stuttering? Are there playback/decoding artifacts or are you having buffering issues? If there are actual artifacts I don't see how CPU utilization is relevant. There was a bug in beta 3 in decoder initialization which may have resulted in decoding problems. However If you have buffering issues that would mean decoder performance problem, but should show up in logs.



#74 Sunrise

Sunrise

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts

Posted 08 March 2015 - 06:50 PM

What exactly do you mean by stuttering? Are there playback/decoding artifacts or are you having buffering issues? If there are actual artifacts I don't see how CPU utilization is relevant. There was a bug in beta 3 in decoder initialization which may have resulted in decoding problems. However If you have buffering issues that would mean decoder performance problem, but should show up in logs.

 

Yes, it's the same symptom as buffering issues, no artifacting. Beta3 and 2.1.0 final are behaving in the same way. It looks like a decoder performance problem to me, I am just not sure why, I am on a quad-core @ 3.8GHz after all and the stream is progressive, no deinterlacing or frame rate doubling involved.

 

I have uploaded you all logs, one with beta2 and one with beta3:

Logs_2.1.0-beta3_ms_stutter.zip

Logs_2.1.0-beta2_vlc_OK.zip

 

In the transcoding.live.log, there is a mention of "(not accurate - transcoding throttled)", does that mean that the CPU is too slow to keep up with the transcoding? If that is the case, then the MS decoders really are extremely slow, is that the case? I can't remember that I had this problem before, though.



#75 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 08 March 2015 - 08:10 PM

I'm really not sure what is going on. In both cases the performance is good enough for smooth playback (by a decent margin), in fact the microsoft filters seem to perform better than vlc. is there any chance you could provide a sample file? If so I'll try to reproduce this locally. We can of course just revert and use VLC instead but I'd like to know what exactly is wrong. Also, are you sure this only happens with VC1? Does H264 perform normally when you force conversion?



#76 macman104

macman104

    Advanced Member

  • Members
  • PipPipPip
  • 153 posts

Posted 08 March 2015 - 08:24 PM

So it looks like this is an intel bug when using QuickSync with multiple GPUs. I was able to reproduce it pretty consistently even with latest drivers.

Has something changed that would have caused this to pop up then? When we first got the multiple display setup to get this to work (in this thread ~Feb 11), everything was working fine. Would something in the client update (or something else) have caused this degradation in behavior?

#77 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 08 March 2015 - 09:00 PM

Sunrise, transcoding throttled actually means the opposite. It means we have transcoded enough in advance that we need to throttle it down. When we do the computed transcoding speed is no longer accurate.



#78 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 08 March 2015 - 09:02 PM

Has something changed that would have caused this to pop up then? When we first got the multiple display setup to get this to work (in this thread ~Feb 11), everything was working fine. Would something in the client update (or something else) have caused this degradation in behavior?

 

This is server side only, client doesn't have anything to do with it. It's a very weird bug, it only happens for certain files and only under certain conditions. I've described it in detail on Intel forums. I think we should be able to recover from this error in next server update, although that's just a workaround. Ultimately it is still something that needs to be fixed by Intel.



#79 Sunrise

Sunrise

    Advanced Member

  • Members
  • PipPipPip
  • 116 posts

Posted 08 March 2015 - 10:48 PM

Sunrise, transcoding throttled actually means the opposite. It means we have transcoded enough in advance that we need to throttle it down. When we do the computed transcoding speed is no longer accurate.

 

Ok, then there is most definitely something wrong, since even though it says throttled in the logs, it still keeps stuttering on my iDevices. As you say, it really shouldn't even throttle when Air Video HD hasn't enough data transcoded, so maybe there is a bug somewhere and Air Video HD thinks there's enough data, but there really isn't, I don't know.

 

I'm really not sure what is going on. In both cases the performance is good enough for smooth playback (by a decent margin), in fact the microsoft filters seem to perform better than vlc. is there any chance you could provide a sample file? If so I'll try to reproduce this locally. We can of course just revert and use VLC instead but I'd like to know what exactly is wrong. Also, are you sure this only happens with VC1? Does H264 perform normally when you force conversion?

 

Yes, this only happens with VC1, at least the samples I have here exhibit the very same problem with all VC1 files. There are absolutely no problems with other formats/codecs and I tested quite a lot of them. However, I am not 100% sure whether other MS codecs like WMV9 (WMV3) are also affected by this.

 

I have uploaded you a sample of the Batman movie, it's called 00000_stuttering_2.1.0.m2ts.

 

Another movie I just found, Cloverfield on Blu-ray (also VC1) stutters in the very same way.



#80 admin

admin

    Administrator

  • Administrators
  • 2585 posts

Posted 09 March 2015 - 01:16 AM

Sunrise, thanks for the file. I was able to reproduce and fix this. This was not a performance problem (that would manifest differently - the video would play normally for small periods of time, and then stopp to rebuffer). It would also be noticeable in the log.

 

The problem here was caused by the fact that Microsoft VC1 decoder expects decoding instead of presentation timestamps in the input. We've been feeding it presentation timestamps (which is the normal thing to do), but as a result it gave output with wrong timestamps. That means frames out of order, which we have to ignore and which results in video that sort of stutters.

 

It seems that for last version I've only tested VC1 in Microsoft containers (and matroska), which only store DTS, so it worked fine. But for container such as MPEG TS which has properly timestamped stream it did not. It will in next update.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users