On 19/06/16 00:34, Andy Furniss wrote: > Mark Thompson wrote: >> >> So, I also went and built mesa with the encode patches and had a go. With >> the changes above, it does get to actually trying to encode, but that nuked >> my GPU to the point of requiring reboot. > > Same here, I need both patches then it does encode but there are issues. > >> With the linked patch you should be able to have a go too: if it works for >> you then I'm interested in what your setup is. If it nukes your GPU then, >> well, you had some warning at least. I think I'll wait until it's a bit >> more stable before pursuing this further. > > I am using an R9 285 Tonga GPU. This uses the amdgpu kernel driver and is > still not totally stable for uvd/vce. > > The instability revolves around powerplay (which IIRC isn't enabled by > default yet). I have test cases that will lock vce, but can avoid by not > letting powerplay vary clocks = force them high. > > What h/w is yours?
R7 360 (Bonaire, a Sea Island), so yours is one generation newer. I am therefore using radeonsi, though I believe the back-end parts talking to UVD/VCE here are actually in common between the two drivers so it shouldn't be relevant? > Below is output of a run that produces corrupt video - I guess this is due > to trying to use b frames > but may be totally wrong :-) Yeah. The attempt to use B frames when they aren't supported means the frame referencing is all messed up. When I tried with "-bf 0", it made a stream which decoded with no obvious artifacts (though somewhat weird, as noted previously). > The same input OK encoded with gstreamer vaapi. In theory my card should > do UHD, but there's a bug so I am limited smaller - older cards probably > wouldn't even do this res. > > The results are the same testing with normal SD input + format=nv12. I only tried 1080p, and it was happy. I believe that generation won't be able to do a bigger stream like the one you tested anyway. > Here's what it looks like - > > https://drive.google.com/file/d/0BxP5-S1t9VEEUDR4V01Rblp2dlk/view?usp=sharing > > andy [vce-tests]$ time ffm -loglevel debug -vaapi_device :0 -f rawvideo > -framerate 50 -s 2560x1440 -pix_fmt nv12 -i /mnt/ramdisk/ducks-2560x1440.nv12 > -vframes 20 -vf 'hwupload' -c:v h264_vaapi -profile:v 66 -b:v 40M -y > /mnt/ramdisk/out.mp4 Looks very similar to the streams I got, modulo the funniness around B frames. I guess that's reassuring that it's not wildly different with different GPUs, at least. On ref frames, it has max_ref_frames = 3 but only ever uses 1. Unsure what to read into that. On 19/06/16 00:43, Andy Furniss wrote: > Mark Thompson wrote: >> Ok, I tried a bit more (including a few power cycles), and it does work. >> The critical extra step is to disable B-frames (that should probably happen >> automatically for baseline profile). It then works with input uploaded from >> the CPU or from a decode on the GPU. >> >> For example: "./avconv -v 55 -y -vaapi_device /dev/dri/renderD129 -hwaccel >> vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf >> 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 66 -bf 0 -b 10M >> out.mp4". >> >> The bitstream it outputs does work in ffmpeg, but it's very weird. It has >> CABAC enabled (not allowed in baseline), and the POC seems to only advance >> on every second frame (as if they were actually fields of an interlaced >> stream, except it isn't). >> >> So, yeah. I think there is a lot more work to do before this is generally >> usable, but it is certainly working and I will keep testing it as more >> versions turn up. > > Ahh, good - I hadn't seen this mail before preparing/sending the other one :-( > > The cabac thing is interesting - I have previously noticed that mediainfo > showed gstreamer vaapi as constrained but yes for cabac - but it also said 2 > for ref frames when ffprobe called one. > > gstreamer omx files said no to cabac - I failed to find a way with > ffmpeg/ffprobe to see if cabac was off/on - is there one?? Not that I know of. I test this sort of thing by feeding streams into the reference decoder with trace enabled and reading the bitstream trace :/ > Also windows files get called as high, but I don't see any b frames > though the only windows files I have were made with a game recording app that > comes with the driver (raptr). It will be the driver (or something further out) writing the headers rather than the hardware, so I don't regard it as surprising that the labelling of the profile is confused. - Mark _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
