[mythtv] Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup)
piotr.oniszczuk at gmail.com
Tue Jul 5 08:37:52 UTC 2022
> 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
>>> 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.
>>> Scott Theisen
>> 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.
>> 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...
> 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.
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
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
More information about the mythtv-dev