[Bug]: <stream is not FLV 1.1 compatible>

[Benman2785]

Describe the bug i can stream to my nginx with rtmp i can download and watch the flv with vlc - also when live when using AMF h264 instead of x264 with OBS i only get audio but no video output from jwplayer (swf) but i can download the saved flv and watch them via VLC or upload to youtube

have in mind that ruffle has not implemented flv playback yet - but given that RTMP Enhanced also supports h265 and AV1 it is given that they will implement all major 3 codecs - and it will be used for playback on some peoples website

To Reproduce Steps to reproduce the behavior: 1.) nginx + nginx-http-flv-module 2.) stream and watch livestream with player.swf from jwplayer 3.) you only hear audio but have no video

Setup (please complete the following information):

• OS: Win11
• Driver Version [24.1.1]
• GPU [RX 7700 XT]
• Which component has the issue [Encoder]

Debug Log (please upload or paste):

no log - as its intended but wrong

Expected behavior a stream that is flv 1.1 compatible // that plays in jwplayer on swf/flash

Screenshots If applicable, add screenshots to help explain your problem.

Additional context if needed i can provide an example - have the files on my server

[MikhailAMD]

The sample of FLV file would be welcome. Note, that the H.264 stream should be valid to H.264 spec. If an implementation of FLV or RTMP rely on some optional part of H.264 spec, it is more a container implementation problem. Though, it would be nice to understand the root cause. It would be helpful if you reproduce the problem with FFmpeg or alike so we could see what is missing or required, for example stream FLV file from FFmpeg. To clarify, does the pipeline looks like this: OBS streams to nginx + nginx-http-flv-module and it re-streams to jwplayer. If so can you try other players like VLC?

[Benman2785]

here you have your files: https://hoffmeister.li/streamdl/x264_CPU.flv https://hoffmeister.li/streamdl/h264_AMF.flv

here is the "JW Player" via Flash https://hoffmeister.li/tv/streamjw.html here is the swf https://hoffmeister.li/flash-games/jwplayer/player.swf

so x264 works fine but h264 does not

please keep notice that i later use Ruffle to show the swf - yet the media playback is only implemented for MP3 as of now

[DimkaTsv]

Weird... When i try to play it through normal players (not flash ones), everything is fine. But when i tried to check them through media analyzer, i saw peculiar difference (sorry for half-assed tool usage).

x264 CPU sample has such hierarchy:

FLV file
-- File Info
-- Audio Stream
-- -- AAC Raw
-- Video Stream
-- -- H.264/AVC

But when i try to check AVC AMF sample, it has completely different structure.

Elementary
-- H.264/AVC

I don't have capability to properly debug issue (random user and stuff). But i am providing information i noticed.

---

I also tried to transcode your CPU sample via VCEEnc (aka AMF based transcoder) and it produced similar to original sample result.

Try playing this one in your player? https://drive.google.com/file/d/1A2d-zehNnjxEtnFQKLbg4BL7XlBsXopD/view?usp=sharing If it plays properly, then maybe issue is on OBS side, rather than AMF?

---

I will also note, that when i used TranscodeHW AMF tool to test this source instead of VCEEnc, i encountered several problems or unexpected behaviours.

1. When i set CBR 6000, even with filler data being enabled, it doesn't produce 6000 bitrate result. But this problem is same for VCEEnc. It produces about 200 kbps bitrate result with total file size of around 600 KB , despite being set up to CBR/VBR 6000. I don't think it should've worked like this. Especially so in CBR case. [Maybe it is more of a RDNA3 thing? I did note that it started to reduce bitrates by a lot when nothing or almost nothing happens at screen, even with screen capture with seemingly CBR. Tested at both ReLive and OBS.]

2. TranscodeHW result used too high QP values unlike VCEEnc. Image was noticeably blocky, despite output being same size. Used TranscodeHW command was like this: %~dp0\TranscodeHW.exe -input %1 -output %~n1_processed%~x1 -codec AVC -RateControlMethod CBR -TargetBitrate 6000. Maybe i had done something wrong?

3. When i used -Usage HQ flag with -FillerDataEnable for Transcode HW, encode took suspiciously long time (down to 12 FPS from 700+) and video output was kinda broken to the extend that at least 2 of the players i have did not play video output from it (one of the players did interpret it properly, though). But i was unable to reproduce it by trying similar options in VCEEnc... Maybe something hidden going on? Here is output from this experiment: https://drive.google.com/file/d/1tWx1W3up6vfUTlDIQX_sVLY4jFSflmZw/view?usp=sharing

[Benman2785]

https://hoffmeister.li/tv/vcejw.html - here is https://drive.google.com/file/d/1A2d-zehNnjxEtnFQKLbg4BL7XlBsXopD/view?usp=sharing - again you only have audio but no video :/

so far you need to use an old browser with flash installed - as ruffle has no video decoder built in (as of now)

[MikhailAMD]

here you have your files: https://hoffmeister.li/streamdl/x264_CPU.flv https://hoffmeister.li/streamdl/h264_AMF.flv

here is the "JW Player" via Flash https://hoffmeister.li/tv/streamjw.html here is the swf https://hoffmeister.li/flash-games/jwplayer/player.swf

so x264 works fine but h264 does not

please keep notice that i later use Ruffle to show the swf - yet the media playback is only implemented for MP3 as of now

The only problem/warning I see in the AMF FLV stream is that primary color in VUI header is set to zero. It was fixed but not yet in the public driver.

[MikhailAMD]

@DimkaTsv TranscodeHW command line gets bitrate in bits. 600Kbit is 600000 etc.

[DimkaTsv]

@DimkaTsv TranscodeHW command line gets bitrate in bits. 600Kbit is 600000 etc.

Oh, oops. My bad. But it still compresses to values way below 6000 kbit/s even if i use cbr 6'000'000 If you look at resulting file metadata (below), then bitrate of video thread will be reported as 5859, but overall bitrate in "General" section is only 782 kb/s. As well as file size being not around 15 MB, but 2 MB instead. Filler data was enabled.

Is there some frame skip/duplication going on by default? Because i saw that VCEEnc reports Others: skipframe:on deblock. And there is option to enabled it with flag --skip-frame, but this flag only allows you to enable this feature. There is no "force disable" option, and it does seem to be enabled all the time by default atm.

P.S. Sorry for going off topic there.

UPD: Created separate report.

---

again you only have audio but no video :/

so far you need to use an old browser with flash installed - as ruffle has no video decoder built in (as of now)

I am trying to understand description of the problem itself. @Benman2785 Correct me where if i will write something wrong... Your issue is down to:

1. Ruffle doesn't have video decoder, so you must use old browser with flash to see stream. Or, as alternative you used JW Player instead.
2. Now that you use JW Player, you try to watch stream of flv done through nginx-http-flv-module,
3. Issue is that if source file was made via OBS X.264 encoder, it plays fine, but if it was done via OBS AMF AVC (H.264) encoder, then there will be no video output, only audio.

Was i correct?

Had i understood (and rephrased) issue correctly?

[MikhailAMD]

@DimkaTsv Let's not mix up issues. For bitrate - please provide source, command line, driver version and HW in a separate topic.

[Benman2785]

@DimkaTsv

1. & 3. are correct for 2. = i stream via OBS on my own server that runs nginx with nginx-http-flv-moudle

for 1. i am working with ruffle team for 3. this is why i wrote you/AMD about it :)

if you want to see the problem yourself (with old browser and flash installed):

https://hoffmeister.li/tv/stream2.html = video and audio are fine (https://hoffmeister.li/tv/test2.flv) https://hoffmeister.li/tv/stream3.html = only audio is played (https://hoffmeister.li/tv/test3.flv)

[Benman2785]

has something moved in the time?

i will ask again after easter - enjoy the holidays

[Benman2785]

not fixed in 24.3.1

[DimkaTsv]

not fixed in 24.3.1

In 24.3.1 AMF runtime version didn't change compared to 24.2.1, so it was reasonable to assume that issue is not fixed.

[Benman2785]

did you atleast found the bug so that it can be fixed? :)

[MikhailAMD]

Few things to note:

1. AMF version changes when API is extended or with every major release. Even if version was not changed each released driver usually have some fixes or improvements, so it is worth to check the latest.
2. In the streams provided I see one problem in VUI header produced by AMF encoder: color_primaries are set to zero. This issue has been fixed recently.
3. Beside 2, the stream is fully compliant with H264 specs (as best as analyzer could tell).
4. Comparing the files here is the list of differences AMF vs x264: SPS:
   • profile_level 42 vs 32 - can be changed in AMF parameters
   • constraint_set5_flag 1 vs 0 - 1- that B slice types are not present in the coded video sequence.
   • log2_max_pic_order_cnt_lsb_minus4 1 vs 2 - should not matter
   • pic_width_in_mbs_minus1 119 vs 79 - different resolution 1920 v s1280
   • pic_height_in_map_units_minus1 67 v 44 - different resolution 1080 vs 720 VUI header:
   • aspect_ratio_idc 255 (Extended_SAR) vs 1 - see next two
   • sar_width 1 vs not present - AMF aspect is 1x1
   • sar_height 1 vs not present
   • video_format 0 (component) vs 5 (Unspecified video format)
   • colour_primaries 0 vs 1 - fixed
   • log2_max_mv_length_horizontal 16 vs 11 - different resolution
   • log2_max_mv_length_vertical 16 vs 11 - different resolution

[Benman2785]

both videos have the same resolution - so i am not sure about: sar_width 1 vs not present - AMF aspect is 1x1 sar_height 1 vs not present pic_width_in_mbs_minus1 119 vs 79 - different resolution 1920 v s1280 pic_height_in_map_units_minus1 67 v 44 - different resolution 1080 vs 720 log2_max_mv_length_horizontal 16 vs 11 - different resolution log2_max_mv_length_vertical 16 vs 11 - different resolution

[Benman2785]

here is a new file with 24.4.1 http://benmanshafen.de/streamdl/h264_AMF_2.flv

still doesnt work

[MikhailAMD]

I re-checked, colour_primaries fix is not in the public driver yet, but it was fixed and coming. Apologies, The rest for the new clip is the same as for test3.flv Even MediaInfo shows different resolutions for the files. I am only guessing but could the resolution mismatch between OBS and the server cause the problem?

[DimkaTsv]

I double Mikhail statement. Your AMF created file is 1920x1080, while CPU processed is 1280x720

CPU one also writes nominal bitrate in MediaInfo, but i don't think it should matter?

[Benman2785]

hehe the reason for this is because i made new files with "everything" as similar as possible:

http://benmanshafen.de/streamdl/h264_AMF.flv (24.3.1) http://benmanshafen.de/streamdl/h264_AMF_2.flv (24.4.1) http://benmanshafen.de/streamdl/x264_CPU.flv (x264 via OBS)

please look into x264_CPU.flv and h264_AMF.flv and try to find reasons why the x264_CPU works with https://hoffmeister.li/tv/streamjw_ruffle.html and why h264_AMF does not work (it only plays audio but no video)

maybe colour_primaries fix will help - but we will see :)

please be aware that ruffle as of yet does not support jw_player playback as it cant handle the video; sofar i use the old Adobe Flash in my old K-Meleon Browser to check // i try to convince the guys from ruffle to implement rtmp_enhanced into ruffle = to allow AV1 streaming on my own (nginx based) streaming server :)

EDIT: if you want to check a stream yourself: stream on my server as rtmp (/live) and try to playback stream with: https://hoffmeister.li/tv/streamjw_ruffle.html in a browser that supports old Adobe Flash (install the flash version 32.0.0.371 - this version doesnt have the kill-switch) - in my case i use K-Meleon (old Firefox basis) // you need to add my https certificate to exception and if you stream as x264 via CPU you will have audio and video but when you stream as h264 AMF you only have audio... // sometimes you have a "grey screen" within 2min

have in mind that my server records the streams that are uploaded to it //

[Benman2785]

are there any news on this issue?

[Benman2785]

is the fix ready and when will it release? :)

[MikhailAMD]

The latest driver 24.6.1 fixes colour_primaries issue. Beside that, it seems AMF produce valid stream.

[Benman2785]

thanks - i will test it this weekend :)

edit: tested - still not working, but randomly getting a grey screen with wrong dimensions

[Benman2785]

it still does not work :( here is the latest AMF video: https://hoffmeister.li/streamdl/h264_24.6.1.flv here you can see a test stream on flash with AMF: https://hoffmeister.li/streamdl/h264_24.6.1_on_flash.flv (beware - it gets loud at the end)

both are:

CBR 1080p@6000kbps AMF "Quality" "high" Max 4 B-Frames & 2s Keyframe Intervall

ProfileLevel=42 MaxNumRefFrames=4 CABACEnable=true EnablePreAnalysis=true RateControlPreanalysisEnable=true RateControlSkipFrameEnable=false EnforceHRD=true FillerDataEnable=true AdaptiveMiniGOP=true EnableVBAQ=true DeBlockingFilter=true HalfPixel=true QuarterPixel=true HighMotionQualityBoostEnable=true MaxConsecutiveBPictures=3 BPicturesPattern=3 BReferenceEnable=true PALookAheadBufferDepth=41 PAFrameSadEnable=true PAPerceptualAQMode=1 PATemporalAQMode=1 PACAQStrength=2 PAHighMotionQualityBoostMode=0

[Benman2785]

is there a way to manually force mime-type? like: "MimeType=video/mp4" or "mime-type=video/x-flv"

[Benman2785]

any new info here?

[Benman2785]

i dont want to start nagging - but its still not fixed (i guess - since i use the AFMF2-beta)

[Benman2785]

can anyone give me an update - because until 24.9.1 it still does not work. will try 24.10.1 now

[Benman2785]

as DimkaTsv showed (https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/460#issuecomment-1987107096 ): the file hiearchy is different - i suspect that this is the issue. is this because of OBS or is this because of AMF?