[mythtv] Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup)

[Piotr Oniszczuk]

> Wiadomość napisana przez Scott Theisen <scott.the.elm at gmail.com> w dniu 04.07.2022, o godz. 22:42:
> 
> On 7/4/22 12:42, Piotr Oniszczuk wrote:
>> 
>>> Wiadomość napisana przez Scott Theisen <scott.the.elm at gmail.com>
>>>  w dniu 04.07.2022, o godz. 03:38:
>>> 
>>> I have rebased onto the master branch my ffmpeg-cleanup 
>>> https://github.com/MythTV/mythtv/pull/416
>>>  pull request and Peter Bennett has pulled it into the devel/ffmpeg-resync branch for ease of testing.
>>> 
>>> Peter and I have tested it, but we would appreciate more testing before merging it into master.
>>> 
>>> Thanks,
>>> 
>>> Scott Theisen
>>> 
>> Scott,
>> 
>> I gave very brief testing of hw assisted decode on various hw in my testbed:
>>   
>> stateless v4l2_request API; h6 & rpi4; mpeg2/h264/hevc/vp8/vp9: OK
>> stateful v4l_m2m API; rpi4; h264: OK
>> vdpau API; ION2; h264: NOK; see (1)
>> vaapi API; intel n3450; mpeg2/hevc/vp8/vp9: OK; h264 NOK; see (2) 
>> 
>> 
>> (1): i'm observing issue with LiveTV staring in approx 2..3 per 5 starts with ffmpeg decode. Also some h264 test videos are failing do decode: hxxp://warped.inet2.org/h264-Sat_1080i_25fps.mkv
>> I'm not observing this with current master - so it looks like issue happens on ffmpeg-resync branch.
>> 
>> https://pastebin.com/fq6iSH7J
>>  is log from 2 LiveTV starts: 1st with expected vdpau and second where it goes with ffmpeg (probably as fallback from failed vdpau attempt).
>> 
>> (2):  issue seems similar to (1)
>> 
>> Let me know if I can do anything extra to chelp...
>> 
> 
> Piotr,
> 
> Since the issue is only with LiveTV, try the attached patch.  (The commit hash is against my ffmpeg-cleanup branch but that doesn't really matter.)
> 
> From your log:
> ```
> 2022-07-04 17:13:03.806788 W [mpegts @ 00007f229cb19780] Could not find codec parameters for stream 0 (Video: h264, none): unspecified size
> Consider increasing the value for the \'analyzeduration\' (60000000) and \'probesize\' (5000000) options
> 2022-07-04 17:13:03.807066 I AFD: Stream #0: ID: 0x281 Codec ID: h264 Type: Video(0x0) Bitrate: 0
> ...
> 2022-07-04 17:13:03.808502 I VDPAUDec: VDPAU does not support decoding \'h264 0x0\'
> 2022-07-04 17:13:03.808542 I AFD: Unavailable decoders: vdpau
> ...
> 2022-07-04 17:13:03.850283 I Duration: 00:00:02.52, start: 92891.733922, bitrate: 1979 kb/s
> ```
> 
> It appears the stream was too short to properly initialize the hardware decoder.  Comments in avformatdecoder.cpp mention it could be up to 5 seconds between keyframes.  That obviously depends on the encoder and the settings the broadcaster uses.  (If I remember correctly, ATSC in the US requires a keyframe every second so a picture can be displayed quickly.)
> 
> Restoring the checks for a fully initialized video codec parser for LiveTV should fix that by waiting 250ms at a time for more recorded stream to decode.

Perfect.
Applying patch fixes issue with LiveTV :-)


> 
> 
> Regarding your mkv sample, I can play it fine with ffmpeg decoding with it in my Videos directory.  So I would need a log from master and a log of it not working to try to determine what went wrong.  I would prefer logs where `--logpath=SOME_PATH` is in the command line so I can see the file and line numbers.

It looks i was wrong saying: .mkv sample plays ok in current master. 
.mkv sample fails on current master with vdpau/vaapi api
but plays ok with hw decoding on current master (and also on ffmpeg-resync) with: v4l2_request and v4l2_m2m api

So issue is rather no fmpeg-resync regression - but rather more general regression in current master :-(

If this will be helpful - pls find 2 logs:
-failing on n3450 vaapi; ffmpeg-resync : hxxp://warped.inet2.org/failing.log
-working on h6 v4l2_request; ffmpeg-resync: hxxp://warped.inet2.org/ok.log

btw:
i also discover current master fails hw decode on mesa/vaapi
hw decode ok but with black screen on mesa/vdpau
....but this is another issue

br