Native playback H264 Video freezes on high spec pro system Posted by Julia - 03 Jul :27

Transcription

1 Native playback H264 Video freezes on high spec pro system Posted by Julia - 03 Jul :27 I would like to be able to view 1080p video from my gopro Hero 2 within Lightworks without transcoding. After importing using a link when I try to play the first few frames are displayed but then the video freezes. The sound continues to play and the position indicator is updated. When play is stopped there is a wait during which LW hangs before finally showing the frame at which I have paused. I can edit the native video and export the results but this has to be done blind using only the single frame advance keys to judge my edit. I recently updated my system in part to fix this problem having experienced this problem since the beta days. If I transcode to any of the available options playback within LW is no problem on my new system. Is this a known problem and is there a fix. System spec Lightwork pro Fresh instal of windows 7 Latest quick time installed (see note) I5 processor 16GB ram Nevada graphics Benchmarks: Host => GPU 497fps, GPU => Host 509fps, Shading fps, Combined 230fps note Initially I installed LW before Quicktime but on reading here that it might be an issue I removed, downloaded and reinstalled LW this morning. Julia 1 / 5

2 Posted by Greg_E - 03 Jul :12 They are still working on the native h.264 support so it might take a little time until it works the way they want it to work. Posted by Julia - 03 Jul :21 I would be content to know that it was a know problem and that it would be eventually fixed. Is there a bug report somewhere I can follow? Posted by RWAV - 03 Jul :53 The difficulties with H264 decoding is not a bug, it's a challenge LW is wroking to solve as well as possible. Wikipedia has a quite comprehensive description of H264 at en.wikipedia.org/wiki/h.264/mpeg-4_avc In part it says: "Because H.264 encoding and decoding requires significant computing power in specific types of arithmetic operations, software implementations that run on general-purpose CPUs are typically less power efficient. However, the latest quad-core general-purpose x86 CPUs have sufficient computation power to perform real-time SD and HD encoding. The 2nd generation Intel Core i processors i3/i5/i7 (code named "Sandy Bridge") introduced at the January 2011 CES (Consumer Electronics Show) offer an on-chip hardware full HD H.264 encoder. The Intel marketing name for the on-chip H.264 encoder feature is "Intel Quick Sync Video"." 2 / 5

3 Posted by Greg_E - 03 Jul :20 I'm pretty sure h.264 decoding is listed in the known issues part of the readme. They do know about it and they are working on it. Trancoding to the free Cineform codec is popular (GoPro Cineform Studio) or transcoding to many of the other codecs in the pro version of Lightworks is also recommended. Posted by Julia - 04 Jul :03 Thanks guys, I have an Intel Quad i (3.3GHz) processor. Playback outside LW using quicktime or media player is faultless. I will continue to use these to sort my clips before trancoding the ones I plan to use. I would prefer a work flow than enables me to do everything from within the Editor. In the known issues - Performance issues working with H.264 files natively. This will be resolved in the update shortly Since my kit is towards the top of that available I wonder if there is any kit that could play HD H264 within LW? Looking at the system load during playback Lightworks around 25% - freezes Quicktime % - OK Media Player around 3% - OK I guess LW is compute bound on one core, Quicktime is using the processor perhaps dropping frames to keep up and Windows media player is using the acceleration H/W in the processor. 3 / 5

4 The colours within mediaplayer & LW are great whereas in quicktime they are washed out. Is this due to decoding shortcuts or just down to the settings? If I wait it will be fixed Posted by pantra - 05 Jul :19 I just upgraded to the Pro-version of Lightworks and was initially somewhat shocked that my h264-sources performed so badly. But I played around with some encoding settings and realized that the amount of intra-frames in my encodings seemed to have a huge impact on the playback performance inside Lightworks. So when I reduced the GOP size or even used intra-frame-only encoding, I got smooth h264-playback. My system isn't exactly a powerhouse (~4 years old DELL Precision m6300, T8100 CPU, 4GB RAM, NVIDIA Quadro FX 1600M, WIN7 x64), so I'm very pleased with the results now. And even though most of my sources are slightly below HD, I tried the intra-frame-treatment with some 720p files. And as long as I didn't let bitrates go through the roof, I got the same smooth results without any freezing. Posted by Greg_E - 06 Jul :20 I frame only requires less compute power because each frame is fully encoded, so the computer doesn't need to predict/compute where some elements are going to be. It is definitely high on the list since a lot of cameras use h.264 now. All that said there are still a lot of reasons to transcode, even with the old codec pack which worked really well with h.264 I had significant problems when I wanted to speed up or slow down a clip, or apply some of the effects or mix between two clips. For things like GoPro HD the sweet spot seemed to be Mpeg2 I frame at 50mbps, 100mbps showed no quality improvements and made hard drive performance difficult on my laptop. Now I would probably go with DNxHD down around 35mbps, or maybe Cineform from the free GoPro Cineform Studio (also at 35mbps). Something from a 5D that was recorded at 30+mbps would get DNxHD at a higher bit rate to keep as much quality as possible unless I was doing something quick that wasn't going to need a lot of processing. 4 / 5

5 Posted by pantra - 06 Jul :03 Greg_E wrote: I frame only requires less compute power because each frame is fully encoded, so the computer doesn't need to predict/compute where some elements are going to be. But even so, after doing some testing on this, it still feels like there's something fishy going on: I've been using ffmpeg to encode a few dozen ~1 minute clips with different encoding settings. Afterwards I imported them into Lightworks to see if a clip would play smoothly all the way or freeze after a few seconds. The weird part is that the moment I go beyond a GOP size of 10 frames or leave the option out completely, the encoded video always freezes when it is played back in Lightworks, even at bitrates as low as 1000k. But if I add this back in, I've so far been able to go as high as 6000k without any freezing (even when ffmpeg was encoding the next test-clip at the same time). My commandline looks something like this: ffmpeg.exe -i "input.avi" -vcodec libx264 -pix_fmt yuv422p -g 10 -b:v 6000k -preset slow -ab 192k "output.mp4" The important option here seems to be the "-g 10". But a video that has been encoded the following way freezes up immediately when played back: ffmpeg.exe -i "input.avi" -vcodec libx264 -pix_fmt yuv420p -b:v 1000k -preset slow -ab 192k "output.mp4" Is it just me or is this... weird? 5 / 5