[regression] AVCHD files choppy playback in MediaPlayer

[vidrep]

Played AVCHD (MTS, m2ts) video in MediaPlayer. Playback is very choppy and freezes. Close MediaPlayer. Pulse and activity monitor continue to show 100% on one core.

[diver]

Could you upload a short video (here or on Dropbox for example) in this format that reproduces the problem?

[vidrep]

My vacation movies are too large for upload. However, I can provide a download link to some sample clips in the same format as my camera that reproduce the same error. ​http://www.dvinfo.net/forum/avchd-format-discussion/73357-avchd-samples.html There are four m2ts sample clips here which are in the same aspect ratio and frame rate as my own. When I last tested AVCHD format on Haiku seven months ago, they played without stuttering or the 100% CPU loading I see now. However, since that time I have changed from a dual core Intel system to a dual core AMD.

[vidrep]

Intel based systems seem to handle this format much better than AMD. I went back to an Intel dual core system this week and I can get smooth playback with some tweaks to thread priority and by reducing window size to 50%. I could never get the AMD Athlon X 2 to do this. Surprisingly, 64 bit Haiku actually fared worse than 32 bit in playing these files despite using a newer ffmpeg version. Question: Are there internal settings in ffmpeg that can be tweaked to better handle HD formats, rather than leaving it up to the end user to play with Process Controller settings?

[anevilyak]

it should be noted that the A64X2 is, to my knowledge quite slow compared to a Core 2. Considering we don't support any hardware-assisted playback, this could simply be a matter of the CPU not being fast enough to handle it on its own.

[vidrep]

My Windows HTPC is based on a dual core socket 939 opteron. It couldn't handle AVCHD format until I installed the CoreAVC codec with support for CUDA and DXVA hardware acceleration. For sure it's a torture test for software decoding. The fact Haiku can do it in software (albeit with tweaks) says a lot about its potential. It would make a great demo.

[pulkomandy]

Changing priorities in process controller shouldn't be needed. The media kit and scheduler should figure this out on their own.

There are more ways to get this faster however, we are disabling SSE and compiling ffmpeg with -O2 instead of -O3 for the gcc2 version. This would already help a bit with making the software decoding faster, but it's not goingto happen as long as gcc2 is involved.

[vidrep]

Replying to pulkomandy:

Changing priorities in process controller shouldn't be needed. The media kit and scheduler should figure this out on their own.

There are more ways to get this faster however, we are disabling SSE and compiling ffmpeg with -O2 instead of -O3 for the gcc2 version. This would already help a bit with making the software decoding faster, but it's not goingto happen as long as gcc2 is involved

When I bought this PC for testing I only installed the gcc4 builds (32 and 64 bit). It would be interesting to see how the newest ffmpeg 2.4 build would fare without SSE disabled. Couldn't these unsupported builds could be a playground for such experiments?

[pulkomandy]

Sorry, I was not clear once again. The -O2 and SSE disable only apply to the gcc2 version, of course. The gcc4 version does not have these problems.

[vidrep]

Replying to pulkomandy:

Sorry, I was not clear once again. The -O2 and SSE disable only apply to the gcc2 version, of course. The gcc4 version does not have these problems.

No apology needed, since I should have specified the build that was used for these tests to begin with. From now on I'll make a greater effort to be more specific. I'll only be testing gcc4 builds from now on, except when I revisit my old tickets to follow up on their current validity. Thanks.

[vidrep]

I bought a Intel Core i5-660 PC for testing. AVCHD videos play smoothly on this PC using hrev48269 x86_gcc2. So, obviously smooth playback of this format in software is purely a function of CPU power. You can probably close this now as an invalid ticket. Thanks.

[forart.eu]

Well, I believe that GPU accelleration could help.

Intel's QuickSync:

​http://sourceforge.net/projects/qsdecoder/

...more to come...

[vidrep]

Any offloading from the CPU would help. Forget about playing 4K UHD videos in Haiku until we either get GPU acceleration or 12 core processors become mainstream. AVCHD requires a dual core E8500 minimum to play without stuttering.

[anevilyak]

I should also point out that nightly builds of Haiku currently have full kernel debugging enabled, which adds a non-trivial amount of overhead for a lot of operations, which will particularly impact a task that tries to use the system to the limit as this does. It'd be interesting to know how a build with KDEBUG_LEVEL set to 0 performs, though that would of course require building it yourself.

[vidrep]

The latest revision hrev49132 no longer plays AVCHD format video without freezing and stuttering. I went back to hrev48269 and they play smoothly on the same PC. Apparently a regression somewhere.

[pulkomandy]

Can you reduce the revision range a bit?

[vidrep]

I went back to hrev48269 for verification, as it is specifically mentioned in the post where I requested closing the ticket. I'll try to narrow down the range to determine when the regression happened. Newer 64 bit builds also exhibit this same behaviour. So, it is not limited to just the x86_gcc2 versions.

[vidrep]

After spending several hours downloading and installing, I have narrowed down the revision range from hrev48462 to hrev48472. Every revision from 48269 through 48462 is working. Everything after is not working. Looking in the source activity, I see there were some changes to ffmeg between these two builds.

[pulkomandy]

It seems to be hrev48469: as mentionned in that commit, we have two ways of trying to guess the framerate, none of which are correct in all cases. ffmpeg added the actual framerate to its API in later versions, but we don't have it. So we must try to guess from other fields.

I think we should rework the ffmpeg decoder to not need the framerate, and rely on the timebase and presentation time to compute the accurate timing for each frame.

[vidrep]

Is there any chance that this will be looked at again before Beta 1?

[waddlesplash]

The thing to do is to make MediaPlayer build as GCC4-only, I suppose, and then use the new FFmpeg API to solve the problem.

[vidrep]

A current revision of ffmpeg would also take care of a variety of 4K UHD video playback issues as well (ticket #11527, #12065, and #12144). Mplayer and QMPlay2 use the most recent version and will handle the format, provided the CPU horsepower is also there.

[waddlesplash]

Yeah, and if you run MediaPlayer on a GCC4(Hybrid) or 64bit build, it should work too (if it doesn't then we have more problems...)

[vidrep]

No point in changing the status to beta 1 blocker on my account, since there are bigger issues to be resolved first such as Networking, launch daemon, and a variety of troublesome system lock ups.

[pulkomandy]

Yes, please stop adding tickets to beta1.

• Did this work on BeOS? NO
• Is this one of the extra features we added to our already too long R1 feature list? NO
• Are there workarounds? YES (2 apps available in the depot + 2 alternative versions of Haiku)

So it does not need to be in beta1.

[vidrep]

When you get back to investigating any ffmpeg related issues, I'd appreciate having this regression resolved if you have time. Thanks.

[vidrep]

hrev50818 x86_64 Tested the same file today and it plays perfectly on x86_64. x86_gcc2 still exhibits the same stuttering and freezing (due to ffmpeg 0.10.16??)

[pulkomandy]

The main problem is that gcc2 isn't very good at optimizing the code and the result is simply too slow to decode the video in realtime. However, there is an additional problem, which is that we don't handle that situation well. At some point, we start to "drop" frames. However, the codec still decodes them and wastes time doing so. And as a result, it never manages to catch up with the video replay, as it is always decoding old frames that have been dropped already. I don't know why or how this worked before, but it looks out of control of the ffmpeg decoder and more of a MediaPlayer/Media Kit issue.

[vidrep]

I installed hrev48468 x86_gcc2 on to a hard drive partition. The AVCHD file played "almost" perfectly, with only a couple of noticeable stutters during the entire clip. This is using an old dual pentium system. I have attached a file which contains the particulars of the PC, and a full terminal log of the video clip playback in Haiku MediaPlayer using hrev48468.

I have also attached a similar file with corresponding data for the same video clip on the most current nightly (hrev51082) for comparison purposes.

Whatever the configuration was, prior to hrev48469, it was certainly more acceptable than the current situation, which is not much better than a freeze frame. Hopefully an acceptable solution can be found. Thanks for looking into it further.

[waddlesplash]

I see high CPU usage and only a bit of stuttering with ​https://github.com/haikuports/haikuports/pull/2758. Probably the situation can't be improved beyond that without hardware decoding.

[vidrep]

Tested on hrev52058 x86_gcc2h and all of my AVCHD videos now play without any stuttering or freezing. However, when seeking ahead, there is a delay of several seconds with no audio. When the audio cuts back in, it is out of sync with the video. Let's close this as fixed, and I'll create a new ticket for the audio issue.