[mythtv] mythtranscode --fifoinfo on master

Thu Dec 26 17:49:37 UTC 2019

Tim

A lot has changed internally with video buffers, frame sizing, alignment etc.

Essentially in latest master, we try and use the actual size of the
video frame, use some alignment for allocating memory to give
ourselves a little wiggle room with FFmpeg's 'quirks' and otherwise
ignore values such as 1088 (other than telling the display classes to
ignore the extra rows).

Previously the video frame size was rounded up to ensure the
dimensions were divisible by 16 - and in this way ensure memory
allocations were enough for FFmpeg (but causing sundry other
complexities).

So in your case, 1080p video is now properly marked as having a height of 1080.

I can think of 2 possible issues that you might be seeing:-

FFmpeg likes to do its own alignment internally - which becomes
problematic when we start to use libavfilter etc (and in particular
VAAPI filters). So previously FFmpeg would have been told the incoming
video was 1088 and been happy. Now it rounds up to 1088 and, at a
guess, decides that it needs to do some scaling and/or conversion
because 1080 != 1088. There is a similar problem with the VAAPI VPP
deinterlacing in libmythtv (that I haven't figured out how to solve
yet).

I suspect disabling the VAAPI deinterlacer may produce useful output
(though it may be going wrong elsewhere as well).

The other possibility is that memory allocations/alignment are not
what FFmpeg is expecting and hence the fifo transfers are corrupted.
(see line 887 onwards in mythtranscode/transcode.cpp). I maintained
existing behaviour when refactoring the allocations - though on
reflection it is possible that the call to GetAlignedBuffer at line
911 is throwing things out (as it adds a hardcoded extra 64bytes of
memory for each allocated frame).

Hopefully this helps - happy to make changes/fixes if needed - but to
be honest, I've had my eye on removing the fifo functionality (as I
assumed it was only used by the largely deceased nuvexport) and was
looking at just adding full FFmpeg functionality to transcode
directly.

regards
Mark

On Thu, 26 Dec 2019 at 16:39, Tim Pletcher <pletchtd at gmail.com> wrote:
>
> I have a script that I use to crop recording cutlist and transcode to h264 using VAAPI acceleration via ffmpeg.  Now that I have been running master, I noticed the behavior of mythtranscode --fifoinfo has changed.
>
> On v30-fixes, a recorded video from a 1920x1080 channel produces the following excerpted output:
> command: mythtranscode --chanid ' + chanid + ' --starttime ' + utc_start_time + ' --fifoinfo
>
> 2019-12-26 10:21:52.170921 N  Found video height of 1088. This is unusual and more than likely the video is actually 1080 so mythtranscode will treat it as such.
>
> 2019-12-26 10:21:52.224561 I  FifoVideoWidth 1920
>
> 2019-12-26 10:21:52.224567 I  FifoVideoHeight 1088
>
> 2019-12-26 10:21:52.224573 I  FifoVideoAspectRatio 1.77778
>
> 2019-12-26 10:21:52.224575 I  FifoVideoFrameRate 29.97
>
> 2019-12-26 10:21:52.224577 I  FifoAudioFormat raw
>
> 2019-12-26 10:21:52.224577 I  FifoAudioChannels 2
>
> 2019-12-26 10:21:52.224579 I  FifoAudioSampleRate 48000
>
>
> On master, the same command and recording produces:
>
> 2019-12-26 10:34:43.176749 I  FifoVideoWidth 1920
>
> 2019-12-26 10:34:43.176755 I  FifoVideoHeight 1080
>
> 2019-12-26 10:34:43.176761 I  FifoVideoAspectRatio 1.77778
>
> 2019-12-26 10:34:43.176764 I  FifoVideoFrameRate 29.97
>
> 2019-12-26 10:34:43.176765 I  FifoAudioFormat raw
>
> 2019-12-26 10:34:43.176767 I  FifoAudioChannels 2
>
> 2019-12-26 10:34:43.176768 I  FifoAudioSampleRate 48000
>
>
> Once I retrieve this information, I use mythtranscode to then pipe the video/audio to ffmpeg via a command like this:
> mythtranscode --passthrough --cleancut --honorcutlist --chanid ' + chanid + ' --starttime ' + utc_start_time + ' --fifodir ' +   args.output_dir
>
> The new behavior creates an issue because I parse the earlier reported Fifo information to structure the ffmpeg command in my script:
> Example:
> ffmpeg -y -init_hw_device vaapi=intel:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device intel -filter_hw_device intel -thread_queue_size 3072 -i audout -f rawvideo -s:v 1920x1088 -r 29.97 -thread_queue_size 3072 -i vidout -vf 'format=nv12|vaapi,hwupload,deinterlace_vaapi=mode=motion_compensated,deinterlace_vaapi=rate=field' -c:v h264_vaapi -b:v 4M -maxrate 6M  -c:a libfdk_aac -filter:a 'volume=1.5' -ac 2 -b:a 320k output.mp4
>
> The problem I am experiencing is that the -s:v aspect ratio parameter must be specified with rawvideo and a value of 1920x1080 as reported from master produces corrupted transcoded video output from ffmpeg (example: video) while using the 1920x1088 as reported from v30-fixes works fine.  If I take the original .ts recording and use ffmpeg to analyze the media information, it reports that the video as recorded by the backend is truly 1920x1080.
>
> Is the fifo stream produced from mythtranscode actually 1920x1088 despite reporting 1920x1080 possibly due to some sort of mod16 rather than mod8 encoding?
>
> -Tim
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org