ffmpeg 3.4 and VDPAU problem with some h264 videos

[Peter Bennett]

Certain h264 mkv videos will not play on MythTV with the 3.4.1 ffmpeg version newly incorporated, when using VDPAU decoding. The log displays thousands of errors

2018-02-13 17:41:10.673987 E  AFD: video decode error: Invalid data found when processing input (0)

These videos play correctly with all other setups: Xvideo, OpenGL, Vaapi, OpenMax as well as Standard decoding coupled with VDPAU rendering.

Videos that fail

• ​http://warped.inet2.org/sample2.mkv
• ​http://warped.inet2.org/sample3.mkv

[warpme@…]

Peter, should I submit this as regression to upstream (ffmpeg bug tracker) or You already done this?

[Peter Bennett]

I have a fix for MythTV that will revert to software decoding when that error occurs. For best results set the number of CPUs for decoding to 4 on the vdpau playback profile.

I did not submit an upstream bug report to ffmpeg. I searched and did not find a report already there. I do not have an example other than MythTV that shows the problem. They will probably want that.

[warpme@…]

hmm. but if I can reproduce problem with mythffplay (which is ffplay essentially) - then I think this might be enough for ffmpeg guys. After all ffplay is simple player using ffmpeg libs and SDL2 painter....

[Peter Bennett <pbennett@…>]

In c9857a93f9bcfa2dfad39b0891f7f759a372504f/mythtv:

ffmpeg: Fix handling of stream changes and errors

If a stream cannot be decoded with hardware assist,
then try switching to software decoding.

If a stream cannot be software decoded, display an
error message to the user and stop playback.

Remove stream-change hacks for h264 that are no
longer necessary and are now causing a failure.

Fixes #13211
Fixes #13217
Fixes #13218
Fixes #13223

[warpme@…]

Peter, FYI With this commit attempt to play sample3 cause my FE to hang with black screen. HW is ION2. FE log attached:

See attached file ​https://code.mythtv.org/trac/attachment/ticket/13223/comment7.log

[Peter Bennett]

Is that where the log ends, i.e. the screen is blank and the last log message is "Clearing OpenGL painter cache." ?

Can you test: Change the playback profile. Set the decoder to "standard" and leave the renderer as VDPAU. See if it will play that way.

If it still does not play that way see if it will play on any other profile, for example Slim.

Let me know the results of the tests.

[warpme@…]

Peter,

Is that where the log ends, i.e. the screen is blank and the last log message is "Clearing OpenGL painter cache." ?

yes. this is last line. Pls see below another example of output when there was fall-back and fe hangs. It was for profile=standard; decoder=vdpau; renderer=vdpau; painter=OpenGL

Basically fe hangs with black screen as soon as I select vdpau decoder. Other playback profile settings doesn't matter. Also hang is only when painter is OpenGL. With Qt fall-back works OK.

2018-02-18 17:18:33.679553 I TV::TV(): Creating TV object
2018-02-18 17:18:33.721815 N Suspending idle timer
2018-02-18 17:18:33.722839 I TV::Init(): Created TvPlayWindow.
2018-02-18 17:18:33.797444 I TV::HandleStateChange(): Attempting to change from None to WatchingVideo
2018-02-18 17:18:34.058479 N AudioPlayer: Enabling Audio
2018-02-18 17:18:34.291357 I AFD: codec DTS has 6 channels
2018-02-18 17:18:34.291597 I AFD: Opened codec 0x685bc60, id(DTS) type(Audio)
2018-02-18 17:18:34.292510 I AFD: Opened codec 0x6682160, id(H264) type(Video)
2018-02-18 17:18:34.305615 I AOBase: Opening audio device \'iec958:CARD=Intel,DEV=0\' ch 2(6) sr 48000 sf signed 16 bit reenc 0
2018-02-18 17:18:34.308020 W ALSA: Requested 500000us got 341333 buffer time
2018-02-18 17:18:34.308227 W ALSA: Try to manually increase audio buffer with: echo 128 | sudo tee /proc/asound/card0/pcm1p/sub0/prealloc
2018-02-18 17:18:34.351959 I Clearing OpenGL painter cache.
2018-02-18 17:18:34.582097 I Changing to 1920x1080 23.971 Hz
2018-02-18 17:18:35.129826 I VDPAU: Created 2 output surfaces.
2018-02-18 17:18:35.129866 I VDPAU: Created VDPAU render device 1920x1080
2018-02-18 17:18:35.393102 I Player(1): Video timing method: USleep with busy wait
2018-02-18 17:18:35.394244 I TV::StartPlayer(): Created player.
2018-02-18 17:18:35.394329 I TV::HandleStateChange(): Changing from None to WatchingVideo
2018-02-18 17:18:35.395228 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.395558 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.395710 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.395768 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.395917 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.397919 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.398319 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.398737 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.398829 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.399414 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.399499 E AFD: video decode error: Invalid data found when processing input (0)
2018-02-18 17:18:35.399690 W AFD: Warning, audio codec 0x685bc60 id(DTS) type (Audio) already open, leaving it alone.
2018-02-18 17:18:35.399707 I AFD: codec DTS has 6 channels
2018-02-18 17:18:35.399726 I AFD: Opened codec 0x685bc60, id(DTS) type(Audio)
2018-02-18 17:18:35.406919 I TV::HandleStateChange(): Main UI disabled.
2018-02-18 17:18:35.406983 I VDPAU Painter: Clearing VDPAU painter cache.
2018-02-18 17:18:35.407056 I TV::StartTV(): Entering main playback loop.
2018-02-18 17:18:35.506721 I Clearing OpenGL painter cache.

[Peter Bennett]

I tried this with OpenGL1, OpenGL2 and QT theme painter and I do not see the problem.

Please can you run with -v playback and capture the log.

Is it compiled with patches? maybe they cause a problem in conjuntion with recent changes?

If I cannot find the problem from the log, it will be helpful to get a backtrace, from a version compiled without patches and with debug symbols. I will also need the full version (mythutil --version).

[warpme@…]

Log for hanging FE

[warpme@…]

GDB trace for hanging fe

[warpme@…]

Peter, Pls find log and trace for hanging FE. Playback was for sample3.mkv. FE is current master without MiniMyth2 patches.

[Peter Bennett]

There is only 1 thread in your trace. There should be about 133 threads. Can you create it this way in gdb

set logging on
set pagination off
thread apply all bt full

That will create a file gdb.txt in the current directory with the full backtrace of all threads.

Please also tell me the version from running mythutil --version on the same build.

Thanks, and please keep up the testing, it is very helpful to ensure the quality of the next version.

[warpme@…]

New gdb trace file with all threads

[warpme@…]

argh - sorry. I looks I forgot about gdb commands.

mythutil reports: mythutil version: master [v30-Pre-512-g1278045] www.mythtv.org

[Peter Bennett]

This is the same. It looks like you did not attach the gdb.txt file that was created? You can see it has only "Thread 1" listed, no others.

The way to do it is - first remove any prior gdb.txt file, then run

gdb mythfrontend
run

Then when it is hung, press Ctrl-C Then use the commands:

set logging on
set pagination off
thread apply all bt full

Then attach the gdb.txt file to the ticket. It should have many threads listed and about 5000 lines.

[warpme@…]

gdb trace with all threads

[warpme@…]

Peter, sorry. I had broken gdb. Now should be OK (trace has 45 threads). FE log for trace3.txt is following: FE version is master [v30-Pre-513-g3810d2f]

see attached file ​https://code.mythtv.org/trac/attachment/ticket/13223/comment15.log

[warpme@…]

Peter,

FYI I just build latest mplayer (svn38018) together with external provided ffmpeg3.4.2 sources and sample3.mkv plays OK. This tells me that issue with sample3.mkv playback under myth is probably related to way either:

a\ how we are calling ffmpeg vdpau api

b\ integration of ffmpeg3.4 within mythtv

just data point...

[Peter Bennett]

One interesting fact - VDPAU on my system can play this VC1 video without failing over to software decode, but yours is failing over. Hoevere, even if I force mine to fail over I do not get the lockout.

The backtrace shows that there is a race condition where it is locking the OSD to check for end of recording while the video output is still being initialized.

I have created a patch. I am unable to recreate this error, so I cannot validate the patch. Please test this patch and let me know if it fixes the problem.

[Peter Bennett]

Proposed fix for lockout on VC1 video

[Peter Bennett]

One thing that I am not sure about - your log shows VC1 video which is your Blu Ray Rip - that is sample 4 from ticket 13225 not sample 3 from this ticket. Which is the one that really is giving the problem? If sample 4 VC1 file then this should really be reported on ticket 13225.

[warpme@…]

log for FE with patch

[warpme@…]

trace for FE with patch

[warpme@…]

Peter, Regarding Your comment #17 - sample3.mkv is H264 - not VC1. Probably You are referring to sample4.mkv - which is not for this ticket. Relevant to this ticket samples are only sample2.mkv and sample3.mkv.

Regarding Your comment #18: this is probably a little confusion. trace3 and log in command#15 were gathered for sample3.mkv.

Regarding Your patch: I added it, compile without any MiniMyth2 patches and try to play sample3.mkv.

Unfortunately issue is still the same.

FE log is attached fe-log2.txt.

GDB trace on hanging FE is attached trace4.txt.

Both gathered on v30-Pre-513-g3810d2f with patch applied.

[Peter Bennett]

Piotr, it looks like maybe you are running without the patch.

If the patch was applied the version would show as v30-Pre-513-g3810d2f-dirty. Your version is showing as v30-Pre-513-g3810d2f in the log, which indicates that it is not patched.

Anyway, this trace is different and indicates that the patch would not work. I will work another way to fix it.

[warpme@…]

Peter, log2/trace4 was for patched code. It is simply way I'm applying test patches: I do git checkout, patch code, configure, build, create PXE image, test. In this procedure git hash reported by myth is not reflecting patches I'm applying manually after git checkout...

[Peter Bennett]

Second attempt patch for freeze when playing

[Peter Bennett]

Please try this patch instead.

When you test, please use -v playback option to give better information in the log. If you are running with gdb:

gdb mythfrontend
run -v playback

[warpme@…]

Peter, with 20180221_ffmpeg_ticket_13223.patch it works! (I mean fallback to software decode). Thx for Your hard work.

BTW: I still believe we should have separate ticket for original issue reported in this ticket (I mean sample2/sample3 vdpau playback issue in ffmpeg3.4). After all fallback to software decode is (in case sample2/sample3) workaround - not root cause fix....

[Peter Bennett]

Replying to warpme@…:

Peter,

FYI I just build latest mplayer (svn38018) together with external provided ffmpeg3.4.2 sources and sample3.mkv plays OK.

Can you be sure that mplayer is using vdpau and is not using software decode or failing over to software decode as we are? You can look at top and see the cpu usage to find if it is using software decode. If you compare that to cpu usage of MythTV using vdpau hardware decode (h264 video that plays in MythTV using vdpau without failing over to software), you can verify if mplayer is really using hardware decode.

[warpme@…]

Eh my dear friend :-) I already verified this.

Here is output from player:

/root $ mplayer-svn -vo vdpau -vc ffh264vdpau /usr/local/share/sample3.mkv
MPlayer SVN-r38018-5.3.0 (C) 2000-2018 MPlayer Team

Playing /usr/local/share/sample3.mkv.
libavformat version 57.83.100 (external)
libavformat file format detected.
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (dca), -aid 0, -alang eng
VIDEO:  [H264]  1280x548  0bpp  24.000 fps    0.0 kbps ( 0.0 kbyte/s)
Could not find a UTF-8 locale,
character keys beyond Latin-1 will not be handled.
==========================================================================
Forced video codec: ffh264vdpau
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 57.107.100 (external)
Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU))
==========================================================================
Clip info:
 title: ABBA The Movie (1977)
 encoder: libebml v0.7.7 + libmatroska v0.8.1
 creation_time: 2008-01-17T09:06:58.000000Z
Load subtitles in /usr/local/share/
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 6 ch, floatle, 1536.0 kbit/16.67% (ratio: 192000->1152000)
Selected audio codec: [ffdca] afm: ffmpeg (FFmpeg DTS)
==========================================================================
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 2.34:1 - prescaling to correct movie aspect.
VO: [vdpau] 1280x548 => 1280x548 H.264 VDPAU acceleration
Movie-Aspect is 2.34:1 - prescaling to correct movie aspect.
VO: [vdpau] 1280x548 => 1280x548 H.264 VDPAU acceleration
A:  55.3 V:  55.3 A-V:  0.001 ct: -0.002   0/  0  1%  1%  3.9% 12 0

[Peter Bennett <pbennett@…>]

In 8c1fe4e7ac0b3c3e7fbd9953f34e06cbb1b7ab4c/mythtv:

ffmpeg: Fix hang when playing certain videos with ION and VDPAU

Fix deadlock when freeing OpenGL resources if video is re-initialized
due to a change from hardware assist to software decode.

Refs #13223

[Peter Bennett]

I am keeping this ticket open to look into why hardware assist is not working for certain videos.

[Peter Bennett]

log from comment 7

[Peter Bennett]

log file from comment 15

[dagnygren]

Any news on this from the ffmpeg side ?

It is still a huge problem here with the Finnish HD TV broadcasts as they keep changing the format now and then in the stream. The fallback to Software decode works, but the ION I am using is not really up to the task and the result is a very choppy playback.

[Peter Bennett]

For NVidia systems I am working on NVDEC as a replacement for VDPAU, since VDPAU is missing support for many of the latest standards. See #13357

[dagnygren]

Thanks for that! But will NVDEC work on my ancient ION hardware ?

I am just also confused that the playback will fall back to software when playing back recordings, but will work fluently when watching LiveTV from the same HD channel ?

And if it is the change in format of the stream that makes ffmpeg fail, what prevents us from reopening the ffmpeg VDPAU decoder using the new format when it fails as it seems to be perfectly cabable of doing the decoding if you start at the right point?

If there is anything I can do to help, please let me know.

[tlathm]

I'm curious as to the status of this one as well. Since upgrading to 30.0 I've run into a number of h264 videos that decode with no problem using xine but which need to revert to software in mythtv, which never happened to me in 29.1. A small example I was able to find is sample 7 under "3 Codecs, Framerates and Subtitles" here:

​https://kodi.wiki/view/Samples

That is:

​https://drive.google.com/file/d/0BwxFVkl63-lEbVptTVZ2NENURHM/view?usp=sharing

I'm aware of the issues with h265 etc, but was there a significant regression in h264 vdpau decoding support between 29.1 and 30.0? It sort of seems that way to me.

From what I'm seeing NVDEC may not even be supported on my GT 430 card. Thanks in advance.

[tlathm]

Something else I should clarify: When I have these issues it always appears to be from errors regarding avcodec_send_packet, for example:

2019-05-17 10:37:09.222935 E [14504/28060] Decoder avformatdecoder.cpp:3785 (ProcessVideoPacket?) - AFD: video avcodec_send_packet error: Invalid data found when processing input (-1094995529) gotpicture:0

[tlathm]

Here's a much better example. Again, in xine (Gentoo media-libs/xine-lib-1.2.9-r2 and media-video/ffmpeg-3.4.5) this uses vdpau just fine, but in mythtv falls back to software from those avcodec_send_packet errors:

​http://jell.yfish.us/media/jellyfish-60-mbps-hd-h264.mkv

Also note that just as a test, I had recompiled mythtv with SEQ_PKT_ERR_MAX increased from 10 to 500 and this still occurs, which tells me it's clearly failing every time.

[tlathm]

I just realized something potentially important that I neglected to mention: In my case this is on a 32 bit x86 frontend. I suppose it's possible that could be a factor.

[Peter Bennett]

I just tested this with MythTV version v30.0-51-ga32ec4bdea1. I do not see any issues with VDPAU Slim, using adapter card "NVIDIA Corporation GP108 [GeForce GT 1030]". Below are the results of "playback data" while playing these videos.

FPS_test_1080p50_L4.2.mkv

1920x1080@50.00fps
H.264 vdpau
CPUs from 1% to 10%

jellyfish-60-mbps-hd-h264.mkv

1020x1080@29.97fps
H.264 vdpau
CPUs from 0% to 6%

Send packet data errors you are seeing indicate that the decoder (in this case vdpau) thinks the data is invalid. I don't know why that would be the case.

[tlathm]

Thanks for testing that. Wow...that's frustrating. Now I'm wondering if this isn't a 32 bit x86 specific issue.

[tlathm]

I figured I'd at least summarize what I have, and have not figured out about these failures for future reference.

So far I haven't been able to correlate any specific similarities in the h264 videos that have this issue vs the ones that don't...for example the reported encoder, bit rates etc. I also have no idea why I'm experiencing this and you've not been able to reproduce it. I'm still waiting to see if others can reproduce the issue. Again, I'm on a 32 bit x86 system.

The specific decode errors causing this are as follows when I enable the playback and libav logging:

2019-05-19 14:02:44.177296 E [1497/1564] Decoder avformatdecoder.cpp:350 (myth_av_log) - [h264 @ 0xb7396c80] Failed setup for format vdpau: hwaccel in itialisation returned error.
2019-05-19 14:02:44.177320 E [1497/1564] Decoder avformatdecoder.cpp:350 (myth_av_log) - [h264 @ 0xb7396c80] decode_slice_header error
2019-05-19 14:02:44.177335 E [1497/1564] Decoder avformatdecoder.cpp:350 (myth_av_log) - [h264 @ 0xb7396c80] no frame!
2019-05-19 14:02:44.177363 E [1497/1564] Decoder avformatdecoder.cpp:3785 (ProcessVideoPacket) - AFD: video avcodec_send_packet error: Invalid data found when processing input (-1094995529) gotpicture:0

The -1094995529 is an AVERROR_INVALIDDATA error.

The most perplexing part of this is the fact that the underlying vdpau as well as the nVidia card obviously can decode these, as they decode perfectly with vdpau using xine. The primary difference appears to be the fact that xine-libs still uses the old avcodec_decode_video2 call as did MythTV 29.1, and not the new separate calls (including the avcodec_send_packet that fails in this case). I strongly suspect I'd have no problems with these using 29.1 but I'd have to downgrade to be sure.

Thanks for the help with this!

[Peter Bennett]

There is a newer version of ffmpeg in master version. If you feel inclined you could test it with master. Note that current master frontend will work with v30 backend. This is not guaranteed to be always the case.

[tlathm]

Thanks! I'm not sure if I can do that too readily with my current setup, but I might. Another interesting thing to note that I just tested today: The problem videos can be decoded with vdpau using the command line ffmpeg (in my case media-video/ffmpeg-3.4.5) without issues...using for example:

ffmpeg -hwaccel vdpau -i <filename> -f rawvideo -y /dev/null

Thanks again.

[tlathm]

A few more additions to this: What especially struck me about the ffmpeg test above is the fact that the ffmpeg utility is in fact using the same avcodec_send_packet function that's failing for me in MythTV 30.0 for these videos. That test was with the ffmpeg-3.4.5 that's installed on my frontend.

That gave me the idea to try a few other tests. I downloaded the ffmpeg source for both version 4.0.2 (as is used in MythTV 30.0) as well as the newest stable 4.1.3 version. In both I did a configure and "make examples" in order to test the hw_decode.c under docs/examples...for example:

hw_decode vdpau jellyfish-55-mbps-hd-h264.mkv out

That worked in both of those versions, and is also using avcodec_send_packet. Very odd. That would seem to rule out quite a bit. It seems as though there has to be something different about the raw data getting sent to that function in MythTV, though I can't imagine what.

Also note that I've now actually reverted to MythTV 29.1 and can confirm that all the problem videos play fine using vdpau decoding. At this point I'm just hoping that someone else will be able to duplicate this. If it happens to somehow be a 32-bit issue of some sort the odds might not be great.

[tlathm]

Another user on the mailing list confirmed that he was able to reproduce this fallback to software decoding, and this was also on 32bit. Specifically it was on two ASRock ION 330HT systems running 18.04 Ubuntu 32bit and 16.04 Ubuntu 32bit respectively.

[dagnygren]

Well. I don't know if it is the same problem, but I am running a 64-bit Zotac ION setup and also having trouble with some (a lot) x264 recordings. These played perfectly with hardware support using the Mythtv that used the old ffmpeg... I haven't tried your recordings though. Reverting to a working Mythtv seems to be undoable due to changes in the database :-(

PS! Had a look at the database scheme change between 1348 (for 0,29) and the current 1350 and noticed that there is very little change. One for HDHOMERUN device format (doesn't concern me) and then a deletion of a setting for AltClearSavedPosition? which I also could live without I think. Anyone having experience of just patching the database version down to 1348 to re-enable the working 0.29 frontend?

[Peter Bennett]

dagnygren - I don't know if this is the same problem, you have not described what you see. Please continue this conversation in the mailing list or forums, as this ticket is not the place to discuss database schema changes.

[Peter Bennett]

Closing this as it seems to be something particular to 32 bit systems, and I do not see any solution for that.

[dagnygren]

Well. I started the whole report through warpme... By using his minimyth2 and reporting the problem.... Which can bee seen from my earlier comments.

And it is NOT a 32-bit only problem.

It is a bug in the upgraded ffmpeg library that will feed broken data to VDPAU. Seems to be triggered by on the fly format change in the stream.

And the bug is still there. Your workaround is fine on the systems with a CPU to support software decoding, but not on a low-performance ION, which will stutter and eventually crash. The real bug in ffmpeg is still there.

[tlathm]

dagnygren: Sorry I hadn't looked at this ticket recently. If you want to post to the mythtv users mailing list I can help with reverting that database schema. I did so in order to revert to 29.1...don't want to clutter this ticket.

It's interesting that you're having issues on 64 bit. If there's any chance you could try any of the tests I did above, it's possible you may find what I did. In my case it doesn't appear to be caused by the newer version of ffmpeg, but rather something about the MythTV change that replaced the old ffmpeg calls to avcodec_decode_video2 with the two calls including avcodec_send_packet. In my case, much newer versions of ffmpeg that I compiled ARE able to decode the problem videos using their hw_decode as a test, which also uses those newer calls.

[Mark Kendall]

FYI - these files appear to play without issue on latest master following the render branch merge.

[tlathm]

Thanks for the reply Mark...just noticed this today. However note that apparently nobody's been able to reproduce this issues on 64 bit systems. So unless someone tests this on 32 bit x86 I'm not sure it would tell us much. It would be great if that were the case. I've been staying on 29.1 for now but I'd hate to do that indefinitely. Thanks again!

[Mark Kendall]

Replying to tlathm:

Thanks for the reply Mark...just noticed this today. However note that apparently nobody's been able to reproduce this issues on 64 bit systems. So unless someone tests this on 32 bit x86 I'm not sure it would tell us much. It would be great if that were the case. I've been staying on 29.1 for now but I'd hate to do that indefinitely. Thanks again!

Ah - missed the 32bit reference. I can't test on a 32bit system.

As discussed with warpme on irc, versions up to and including v30 used the old, deprecated VDPAU/FFmpeg API (some code was copied over from the previous FFmpeg versions to keep VDPAU decoding going).

V31/master now use the 'official' VDAPU FFmpeg API - and most of the decoding and rendering code is very different.

I can't do anything with this until someone actually does some testing on a problematic system (I think warpme has that in hand). That said - any fixes that may be required will not be backported.

[warpme]

Mark, I received 2 samples which are demonstrating problem on system with nvidia 340.108 and current master. Here are links:

​http://warped.inet2.org/sample_1080_slow_film.mkv

​http://warped.inet2.org/sample_1080_slow_fastdecode.mkv

may You pls try on Your nvidia 340 testbed?

[tlathm]

Replying to mark-kendall:

Replying to tlathm: Ah - missed the 32bit reference. I can't test on a 32bit system.

As discussed with warpme on irc, versions up to and including v30 used the old, deprecated VDPAU/FFmpeg API (some code was copied over from the previous FFmpeg versions to keep VDPAU decoding going).

V31/master now use the 'official' VDAPU FFmpeg API - and most of the decoding and rendering code is very different.

I can't do anything with this until someone actually does some testing on a problematic system (I think warpme has that in hand). That said - any fixes that may be required will not be backported.

Maybe you could clarify something about the above changes: Version 30 did in fact include changes that replaced the old avcodec_decode_video2 with the two calls including avcodec_send_packet. I thought that the former (avcodec_decode_video2) in fact was the old deprecated API you're saying was in v30(?). Are the above changes in V31/master something else over and above that? Thanks!

[Mark Kendall]

Replying to tlathm:

Replying to mark-kendall:

Maybe you could clarify something about the above changes: Version 30 did in fact include changes that replaced the old avcodec_decode_video2 with the two calls including avcodec_send_packet. I thought that the former (avcodec_decode_video2) in fact was the old deprecated API you're saying was in v30(?). Are the above changes in V31/master something else over and above that? Thanks!

The avcodec_decode_video2 change is not the API change I was referring to.

Previously FFmpeg's hardware acceleration was based around the use of AVCodecContext->hwaccel_context

This was replaced some time ago with the use of either AVCodecContext->hw_device_ctx or AVCodecContext->hw_frames_ctx.

The newer API is much more extensive and requires very different handling.