#Experimental FFmpeg Pipeline

1 messages · Page 1 of 1 (latest)

buoyant knoll
uneven spruce
#

hmm

# 
[h264_qsv @ 00000250c42dcec0] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters.```
#

the pipeline seems very simple though - there are no video filters being applied, but i do see a watermark as input for some reason

#

what stream mode are you using on the channel and how are you playing it

#

it's strange that there is no video pipeline in the command at all, but i also dont know what your settings are

uneven spruce
#

think i have a repro for 10-bit hevc

#

however my pipeline looks slightly different than yours

buoyant knoll
#

Which setting might you be referring to? I can provide them if that helps.

uneven spruce
#

yea, all of them. the ffmpeg settings

#

the qsv pipeline on the new pipeline is a little underdeveloped, so glad its getting some exposure

#

im pushing a couple fixes now as i sift through

buoyant knoll
#

I also had no luck with using HLS Direct. When I attempt to use that I just get a spinning circle but the stream never starts. Dont know if its related to this issue.

uneven spruce
#

yea - with the repro now i see a few things wrong on my end. definitely an issue with hevc 10-bit (so far)

buoyant knoll
#

Ah ok.. MOst of my media is hevc 10-bit too

uneven spruce
#

Will be good for testing!

uneven spruce
#

Can give 0.17.1 a go. Did some cursory testing on the 10bit hevc I have, but I’m sure there are other edge cases

#

Watermarks are a little washed out on hdr content

buoyant knoll
uneven spruce
#

That log looks like the experimental pipeline is disabled

#

Can tell by the filter labels

buoyant knoll
#

It is atm

uneven spruce
#

Oh, I made no changes to the original pipeline

#

I’m sure it’s pretty broken for qsv

buoyant knoll
#

I tried it with it enabled and had no luck so I disabled it again

uneven spruce
#

Ok, can you get a log for the new pipeline so I can see what’s breaking there

#

I’m not really planning on back porting fixes to the original pipeline

buoyant knoll
#

The logs I attached there were from 17.1

uneven spruce
#

Right… but the ffmpeg log was for the old pipeline , not the new one

buoyant knoll
#

I think I logged while I was using the new one too.. If not ill go back and collect new ones

uneven spruce
#

Maybe but it would be in a different file

buoyant knoll
#

Ill just collect new ones from the new version again

uneven spruce
#

K

#

The ffmpeg report files on the new pipeline have a naming scheme like “channel-number-transcode-date” and the old pipeline makes files like “raw-stream-ffmpeg-date”

buoyant knoll
#

Ok, got it

uneven spruce
#

I have a bug somewhere to clean those out periodically… they make a mess

buoyant knoll
uneven spruce
#

Nice, yea I noticed it was a little slow for me too, tho I was testing with 4k content

#

(Most of my hevc is 4k)

buoyant knoll
#

Ah.. Well those two dont work.

#

NIce

uneven spruce
#

I’ll check em out

buoyant knoll
#

Cool, ty 🙂

uneven spruce
#

I should probably make a couple closer examples to yours

buoyant knoll
#

If you need me to test anything else just let me know.

uneven spruce
#

Will do! Thanks - the qsv pipeline hasn’t gotten a lot of love so this is great

#

So first thing - I don’t see the actual errors in those. Those channels failed to start? I would expect much shorter logs with less output if so

buoyant knoll
#

On some of them I just get a spinning black circle

uneven spruce
#

Interesting hmm

buoyant knoll
uneven spruce
#

Can take a closer look later tonight, that’s definitely strange though

uneven spruce
#

I noticed that it’s not being any hwaccel in the pipeline

#

And not explicitly including the hw encoder

#

Not sure why yet

#

I’d expect it to decode on software (hevc 10bit on qsv) but then do the rest on hw and encode out on it (it does this on my machine in testing) so that’s interesting

buoyant knoll
#

Does this have anything to do with me not having a dedicated gpu in this pc? Im completely relying on the igpu.

uneven spruce
#

That shouldn’t affect anything, no

buoyant knoll
#

Ok, good.

uneven spruce
#

i'm wondering if it was spinning so long because its basically just doing everything on software (for some reason)

buoyant knoll
#

Im going to give 17.2 a shot and see how I fair.

buoyant knoll
#

I was just playing with the latest edge and its odd. Playing streams seems to be hit and miss even regardless of the Experimental Pipeline being enabled or not. Some streams play with it enabled and others dont.

uneven spruce
#

QSV is always gonna be hit or miss on the old DTV pipeline, even with some of the fixes i put in

#

i have some other minor changes i'll push to edge, mostly more logging

#

which might help me diagnose

#

but the bug fixed in 0.17.2 is definitely necessary

#

assuming youre using the edge from this morning (1 hour ago) that includes 0.17.2 fixes ... can you send a full ffmpeg command generated by the new pipeline

buoyant knoll
#

Yes, im using the most recent edge.. Sure Ill share the logs.

uneven spruce
#

can you also click into your transcode config and show all of those settings

buoyant knoll
uneven spruce
#

Perfect thanks

#

Very strange that it’s not attempting to use hw encoding

buoyant knoll
#

Yeah, ive been hearing more people here talking about have success using the new experimental pipline and didnt understand why it didnt remotely work for me.

uneven spruce
#

i dont think many are using QSV

buoyant knoll
#

I find that interesting since it alleviates you needing a dedicated gpu for your htpc.

uneven spruce
#

theyre still using their iGPUs, just most are running VAAPI, AFAIK

#

when using intel chips, that is

#

(because theyre running on linux)

buoyant knoll
#

Ah..

uneven spruce
#

latest edge should have more debug logging on the tunarr side - trying to diagnose why the system doesnt think you can use hw to encode, considering your settings are pretty standard (and i have very similar settings but have been running qsv streams w/ no issue)

#

of course it's still not totally 1:1 since i'm not testing this on windows (or with your exact content or ffmpeg) but in general i imagine it should behave pretty similarly, especially on the tunarr side when it comes to the logic to determine hw capabilities

#

one main difference is that on windows, there is no code to query what the igpu actually supports, so it uses some same defaults to determine whether to try and run on hardware, perhaps there is something wrong there

uneven spruce
#

i see what is going on - at least w/ the hw accel stuff

#

i overlooked the crucial log line in the tunarr logs: 2025-01-11T09:20:58.955Z [error]: Cannot detect VAAPI capabilities without a device

buoyant knoll
#

I just tested the last release. Im still experiencing issues with the majority of my streams. I uploaded a clean set of logs since the upgrade.

📎 17.2.logs.zip
uneven spruce
#

this is progress - it's actually attempting to use the hardware now

buoyant knoll
#

I just tested 17.3 and it looks like I had a lot less issues with starting streams/streams failing but still encountered a bunch that did. I attached the ffmpeg logs for some of the channels that failed on me.

📎 17.3.logs.zip
uneven spruce
#

i think that is specifically for the case of software decoded hevc -> hardware encoded h264 on qsv when we need to scale (on hardware)

buoyant knoll
#

Heres the logs for some of the failing streams as I mentioned earlier. Thanks!

📎 17.4_logs.zip
uneven spruce
#

Awesome, thanks I’ll take a look

uneven spruce
#

still going through them but added 2 new commits which hopefully address some of the errors in there

buoyant knoll
#

Awesome. I was going to wait for the next release but if you want me to try the latest edge let me know. 🙂

uneven spruce
#

no worries! i cut 0.17.5 with just those 2 changes, since there is a feature change upcoming which would bump it to 0.18.0. can try 0.17.5 at your convenience and LMK!

buoyant knoll
#

I just got done doing some testing with 17.5. It looks like I was able to successfully play all types of media/streams without any failing. The only issue Im seeing now is for some reason none of my fillers play. If I switch to a channel that has fillers playing I get Channel Offline. Same thing for shows that end and use fillers to transition to the next show. I attached the logs for one of the channels that had the issue. Aside from that everything seems to be working well. 👍

📎 ffmpeg-report-channel-16-concat-20250116-193006.zip
buoyant knoll
uneven spruce
#

Not sure what’s up with the filler - I haven’t touched anything even near there in a really long time. I confirmed with a contrived channel (8 hours of flex on repeat) that I’m getting filler content playing. Might have to add some logging there to see what’s up

#

As for the delay - I can look at that tmrw. I’m not on the computer that has qsv now so I can’t test

buoyant knoll
#

I think the filler issue started with 17.0. I thought the Channel Offline was due to the other issues I was having with playing h265. When I revert back to the last v16 everything works fine again. Again, just sharing what I find as I test. Thanks!

uneven spruce
#

Gotcha, I’ll check it out then. Still strange that I’m able to play the filler but I guess the bug may be more nuanced than my little contrived setup

#

The jump to 17.0 also didn’t really affect anything with scheduling, so definitely weird

buoyant knoll
#

Its interesting too. As soon as the fillers end the next scheduled show/movie starts just fine.

uneven spruce
#

And the channels definitely have filler lists assigned? Just double checking lol

buoyant knoll
#

Oh absolutely.

uneven spruce
#

How long are the filler blocks?

buoyant knoll
#

Wait.. wth?? Youre right. All my fillers are gone!

uneven spruce
#

Ahhhh yea I thiiiiink I know why that might’ve happened (it’s a bug)

#

But at least easily fixable on your end

buoyant knoll
#

Wow..

uneven spruce
#

Adding transcode configs I think broke some relations for channels in the db

buoyant knoll
#

I didnt think to check to see if they disappeared.

#

Yeah, so thats an easy fix. heh

uneven spruce
#

Yea makes sense, I wouldn’t expect them to disappear either!

buoyant knoll
#

The filler lists are there they are just misising from the flex section o nthe channels.

#

I just have to select them again for my channels

uneven spruce
#

Right totally - the associations didn’t make it along in the db migration

#

It’s a bug I made once with program associations when doing a migration… guessing I overlooked the filler lists

buoyant knoll
#

So really the only issue I have is the audio video sync with non h265 content.

uneven spruce
#

Cool, I can check that out tmrw morning once I’m back on my other pc

#

Hopefully it’s easy to reproduce

buoyant knoll
#

I just did some testing with 18.3 and still experiencing audio and video being noticeably out of sync. It appears to still be for non h265 content.

uneven spruce
#

h264 or something else? or just anything not h265?

#

also are all of your h265 files 10-bit? i wonder if it has to do w/ hardware decoding (qsv currently does software decoding for 10bit h264/hevc)

uneven spruce
#

think i got a repro here

uneven spruce
#

seems to be on the decoder side (or something w/ the filters) because switching to software encoding on my repro doesn't help at all

#

definitely seems qsv specific; exact command but tailored to vaapi works as expected

buoyant knoll
#

Thats awesome. Im glad you were able to reproduce on your side. Just let me know if you need me to test anything further on my side.

uneven spruce
#

will do! thanks!

uneven spruce
#

Ok so quick update … this doesn’t seem to happen to me consistently, seemingly even on the same file at the same timestamp. It’s quite strange. I have some ideas, implementing one now to see if it helps

#

I also havent found a completely foolproof way of fixing it, besides forcing decode to software (which I assume is why your h265 content is working bc iirc you said most of that is 10bit which will end up decoding on software)

uneven spruce
buoyant knoll
#

I just did a little channel surfing with 18.6. I'm still seeing very noticeable audio video sync issues with a good majority of media. I attached a clean set of ffmpeg logs from 18.6 and labeled which logs failed, worked and used which codec. If there's anything else I can test that may be of use to you feel free to let me know.

📎 18.6_ffmpeg_logs.zip
uneven spruce
#

bummer

#

i'll take a look at the logs

#

interestingly some of the out of sync logs are for hevc inputs this time, so definitely not limited to h264 like we thought before

#

also interestingly - it's reading from the file, so not a network connection issue or anything

uneven spruce
#

another thing i'd be curious for you to try is messing around with your bitrate / buffer size settings

#

e.g. make the buffer size larger than the target bitrate

buoyant knoll
#

Yeah, I was surprised to see it happening with the h265 media too. Again, I'm still using ver 16.13 on my htpc and playback on all media is perfect. I'm a bit surprised you haven't heard more feedback in regards to this. Am I the only person reporting this issue with the latest x64 builds?

uneven spruce
#

16.13 with the new or old pipeline enabled? I can look at the diff again but the main changes in these versions were totally unrelated to streaming, and especially quicksync

#

Depending on your answer… my guess at the moment is that 16.13 was erroneously using a software decoder on qsv

#

Don’t have the solid numbers but most users I’ve interacted with are either using vaapi on Linux with their Intel cpus, cuda on windows or Linux, or no hw accell at all

#

If you could grab some ffmpeg logs from 16.13 I can easily spot any differences. Definitely makes a difference on whether you’re using old or new pipeline too though

buoyant knoll
#

I wasn't using the new pipeline on 16.13 and it didn't even remotely work back then. But now, even disabling the new pipeline on these later builds it has more issues than when the new pipeline is enabled.. Basically any builds above 16.13 are unusable because I cant play a vast majority of media, with or without the new pipeline enabled. Does that makes sense? I can provide logs still from my 16.13 environment if you want to see them. Again, I just thought Id hear more people reporting this issue. I'm sure running tunarr on a windows pc using qsv would be somewhat common but maybe I'm wrong.

uneven spruce
#

So to be clear, no new pipeline enabled on 0.16.13 and it’s working ok? A log would be good. It’s starting to look like my theory about the decider being the issue is possibly correct

#

And yes, tbh I haven’t dealt with anybody using qsv until this. Not to say it’s unpopular, I just haven’t spoken with anybody using that setup

buoyant knoll
#

Correct, the new pipeline is not used in my 0.16.13. I'm trying to produce a ffmpeg log for you in 0.16.13 but when I enable ffmpeg logging to a file set to debug mode all my streams immediately fail to load afterwards even when turning it off again and restarting tunarr. I had to restore from a backup of to get it to work again. Tried it twice and got the same result. So those logs were the best I could get..

📎 ffmpeg-report-raw-stream-ffmpeg-20250125-211935.log 📎 tunarr.log
uneven spruce
#

All good, just wanted to see the command

#

When I was reproducing the sync issue, removing the hardware decode step seemed to help things a lot

buoyant knoll
#

Im still having audio/video sync issues with 0.18.7 when using Quicksync. When I test on another PC using the Nvidia CUDA some of the streams I had an issue with do play properly. But when using Quicksync most of the media will play now but a good deal are still out of sync.

📎 ffmpeg-report-channel-10-transcode-20250129-232749.log
uneven spruce
#

There haven’t been any additional changes related to this so it makes sense that you are still experiencing it. I will try to implement my other idea when I get a chance

uneven spruce
buoyant knoll
#

Ill get the logs for CUDA this evening. CUDA was having different issues than Quicksync. With CUDA some media just failed to start streaming at all.

#

The stuff that did play with CUDA worked perfect though

uneven spruce
#

bittersweet! i have CUDA hooked up for the live instance of Tunarr I run but i havent been testing with it as much recently

#

here's my plan for QSV

#

im messing around w/ the change i mentioned in #dev-chat a bit ago. in my tests (watching the mpegts stream on VLC) the audio seems nicely synced. i should watch some different content though

#

i'm gonna test a little more, push this up, see what you think. if even that doesn't work, im goingn to consider putting in an option to disable hardware decoding (not filtering or encoding) , since that seems to be the crux of the issue AFAICT

uneven spruce
#

this is actually so weird... im getting a consistent repro on some content but not others. so strange

buoyant knoll
#

Again, if you need me to pull logs on any specific media types on my end this evening just let me know.

uneven spruce
#

unfortunately i dont think there will be anything useful in the logs

buoyant knoll
#

Ah ok

uneven spruce
#

does the sync issue happen on every single piece of media you watch?

buoyant knoll
#

Nope

uneven spruce
#

oh

buoyant knoll
#

Id say about half

uneven spruce
#

is it instantaneous or over time?

buoyant knoll
#

But im sure it depends on what type of media is being streamed on what channel

#

Instant

uneven spruce
#

have you tried changing any of the audio encoder params at all?

#

i'm looking at two streams right now, one seems out of sync to me and one is in sync - running them on the same pipeline

#

the audio streams aren't too different, in fact the one that is in sync has more channels, higher bitrate, etc. both are EAC3

buoyant knoll
#

No, i have not changed the audio encoder parameters at all.

#

I can give that a shot a little later too

uneven spruce
#

yea, try one at a time, if possible. perhaps first the codec

buoyant knoll
#

Ok, will do

#

Actually I can test right now on this computer..

uneven spruce
#

im really sending myself for a loop playing the same clip over and over with different params lol. it's weird how the brain tries to make it work

#

esp if it's lip sync

buoyant knoll
#

hehe

#

Actually, no I cant really test on this computer.. I can only test with CUDA on this PC..

uneven spruce
#

hmm ok, no worries

#

i guess something that would be useful would be to keep collecting the logs for anything out of sync, that way i can compile a list of the potential inputs that are affecting things

#

also, i dont think the defaults do this, but i would try setting audio buffer size to double the configured bit rate, like we tend to do (to start) for video

buoyant knoll
#

Info for the media that was being streamed:

image.png
uneven spruce
#

so that log looks like it was for the first stream - you're totally certain the stream reinitialized after each change to settings?

#

just making sure!

buoyant knoll
#

I went into the channel and aplied the profile with the appropriate change then saved it each time I played it.

uneven spruce
#

right, just saying that existing streams are not killed off when that happens.

buoyant knoll
#

Okay..

uneven spruce
#

if you had stream 1 running, changed the profile and reconnected within 30s - 1m then the old stream is still running

buoyant knoll
#

Should I exit out of tunarr?

#

After switching?

uneven spruce
#

there is a button in the channels table that is enabled when there is an active session: "Stop Transcode Session"

Screenshot_2025-01-30_at_8.44.13_PM.png
buoyant knoll
#

Got ya

uneven spruce
#

that is enabled when there is an active session on the channel still

#

you can confirm that they are all dead by 1: checking TUNARR_IP/api/sessions and/or 2. ensuring there are no ffmpeg processes in task manager

buoyant knoll
#

Ok, will do

uneven spruce
#

it keeps the session active for a grace period in case of a quick disconnect / reconnect

buoyant knoll
#

ok.. let me give it another shot

uneven spruce
#

sg, just wanna cover all bases

#

i've been thinking about making that whole thing configurable

buoyant knoll
#

First attempt normal audio / video sync issue. 2nd attempt, after doubling buffer size looked like the sync issue got worse. 3rd attempt switching to the AC3 codec I got no sound whatsoever.

#

Made sure the stop the transcode session before switching to the next

uneven spruce
#

If you’re watching in a web browser you won’t get any sound with ac3 (not sure if that’s the case). I think windows may also be missing that codec, not totally certain though

#

Definitely surprised that doubling the audio buffer made things worse - I had an opposite experience earlier

#

What client are you testing in?

buoyant knoll
#

Im using 0.18.7. Maybe it wasnt worse but its still REALLY off.

uneven spruce
#

I mean where are you watching the stream

buoyant knoll
#

Via the web browser

#

Thats with the audio buffer doubled

#

Again when I switch the encoder to CUDA on this machine it plays perfectly in sync.

uneven spruce
#

even with the same content?

#

i havent been testing in the browser, fwiw, i can try that tmrw

#

the client is certainly part of the equation

#

i think i will also put in an option for you to try disabling the hw decodingn

#

On another note maybe a different approach is necessary. I’ve been focusing on audio parts of the pipeline but perhaps it has to do with video

buoyant knoll
#

Yes, with the same content.

#

I just setup a test channel that only runs content that is giving me issues..

#

I dont know if its possible to allow for use of the pipline the way it was in ver 0.16.13? In that version all my content playeed very well no matter what was playing. Though I dont know if that ship has sailed with all the new changes.

uneven spruce
#

I think the qsv pipeline on windows pretty much completely busted in that version…?

#

When it did it work it defaulted to not using the iGPU at all, which “worked”

#

What’s the audio sync like with qsv without the experimental pipeline enabled?

buoyant knoll
#

Without the experimental pipeline enabled a lot of stuff just doesnt even play at all.

#

All I know is 0.16.13 is what im using on my primary HTPC and it works pretty flawlessly with all my media (experimental pipeline disabled).

#

Its why Im stuck on that version. With the newer versions it doesnt matter if the experimental pipline is enabled or not.

uneven spruce
# buoyant knoll Without the experimental pipeline enabled a lot of stuff just doesnt even play a...

Makes sense - this was always the problem with qsv on the original DTV pipeline. Was just wondering about any content out of sync currently that does play.

I’ll take a look at the changes between that version and here. I haven’t touched the original pipeline in some time though, I’m treating it as deprecated. Not sure if you were using qsv on 0.16.13 either. Could definitely gather some log samples from that build for comparison though

#

The main change in 0.17.0 was the introduction of transcode configs; there were some bugs in reading those configs which afaik have all been fixed up in subsequent versions

buoyant knoll
#

Yes, I am using QSV in my 0.16.13 environment..

uneven spruce
#

Can you grab some ffmpeg logs from there?

buoyant knoll
#

Let me see what I have. For some odd reason when I enable ffmpeg logging I have issues. Dont ask me why...

#

Only in that version

uneven spruce
#

I really only need the generated command which would be in tunarr debug logs

buoyant knoll
#

Ah ok. I can get that

uneven spruce
#

Perfect I’ll check it out. And if there’s any chance you can get the same thing for the newest version with the experimental pipeline disabled for a 1:1 comparison that would be helpful

#

That log is pretty enormous, giving the command is near the bottom?

buoyant knoll
#

Ok, here is from 0.18.7 with the experimental pipeline disabled.

📎 tunarr.log
uneven spruce
#

ok here a few things i notice so far:

  • there are still errors starting streams in 0.16.13 on the old pipeline - this seems mainly due to tthe fact that it takes a long time to output 2 segments because it's using a lot of CPU-bound stuff (no hw decoding or scaling, etc).
  • the main difference between the old and new pipelines i see so far is that old is not using hw decoding, hw scaling, and interestingly both versions are setting -fps_mode cfr to output at a constant frame rate <-- with this being the most interesting and potentially important
#

can you retry on new pipeline with enabling the "normalize frame rate" option in your transcode config?

uneven spruce
#

after looking at your recording i'm realizing that my "repro" was not anywhere near as out of sync as yours. hoping the video sync + constant frame rate helps

buoyant knoll
#

Im going to test that out hopefully on my lunch break. Ill let you know how I make out.

#

Thanks again!

uneven spruce
#

sure thing! really hope we can figure this out!

buoyant knoll
#

Hope so! 🙂

buoyant knoll
uneven spruce
#

woof yea that's pretty awful

#

unfortunately i have no repro here. would be happy to test with a piece of sample media that you're having a problem with though, if you feel OK sending it over

buoyant knoll
#

Sure.. let me find something

#

Theres the video link for the clip I shared before. Its the full ep

uneven spruce
#

Nice, I’ll give it a shot tonight

buoyant knoll
#

Thanks again 🙂

uneven spruce
#

ok so some unfortunate news... i can't repro the audio sync issue at all with the file you sent over; at least not in the way i'm testing

#

i've taken one of the commands you had and apadted it to my linux env + used this file (ensured that there is a scale on hw and stuff) but it seems OK to me

#

some obvious differences between our setups though, so it's not 1:1

  1. im not testing on Windows (i can try getting this going though to see if it makes a difference)
  2. i'm not watching in the browser player (though i dont know how impactful that is since you are able to get audio synced right in that player via other methods)
  3. i'm outputting mpegts directly and piping it into my test client
#

for posterity, the command i'm using to test: ffmpeg7 -threads 4 -nostdin -hide_banner -nostats -loglevel error -fflags +genpts+discardcorrupt+igndts -hwaccel qsv -hwaccel_output_format qsv -qsv_device /dev/dri/renderD128 -init_hw_device qsv=hw:hw,child_device_type=vaapi -filter_hw_device hw -ss 257.401s -gpu_copy 1 -c:v h264_qsv -readrate 1.0 -readrate_initial_burst 45 -i ~/Downloads/History\'s\ Greatest\ Mysteries\ -\ S03E12\ -\ The\ Chicago\ Tylenol\ Murders\ \[AVC\]\ \[720p\].mkv -i http://localhost:8000/images/uploads/tunarr-guide.png -filter_complex "[0:0]vpp_qsv=w=1495:h=1080,setsar=1,hwdownload,format=nv12,pad=1920:1080:-1:-1:color=black[v];[0:1]aresample=async=1000:first_pts=0,apad=whole_dur=2528399ms[a];[1:0]scale=192:-1,format=yuva420p[wm];[v][wm]overlay=x=W-w-19:y=H-h-11:format=0:enable='between(t,0,20)'[vwm]" -map "[vwm]" -map "[a]" -muxdelay 0 -muxpreload 0 -flags cgop -movflags +faststart -t 2528399ms -video_track_timescale 90000 -b:v 10000k -maxrate:v 10000k -bufsize:v 1000k -c:v h264_qsv -low_power 0 -look_ahead 0 -c:a aac -b:a 192k -maxrate:a 192k -bufsize:a 50k -ar 48k -g 24 -keyint_min 96 -force_key_frames "expr:gte(t,n_forced*4)" -f mpegts pipe:1 | mpv -

uneven spruce
#

ok - imported ths into my plex, got it playing in a local build of tunarr... still no delay for me : (

#

here's a sample - a little weird but i think that's just an artifact of the screen recorder; when watching live it's pretty much perfect

buoyant knoll
#

Ok. Im sure using it in a Linux environment has something to do with it. So you tested it using vaapi correct?

uneven spruce
#

no i tested with qsv

#

i mean... its vaapi under the hood

#

but i used the qsv decoder/encoder/filters

buoyant knoll
#

Ah ok.. I see in the command now

uneven spruce
#

but yes that seems to be the last difference

buoyant knoll
#

Yeah, I dont understand what is going on. But its something definitely related to Qsv.

uneven spruce
#

i've been meaning to get a separate boot for windows on my intel based machine so this is a good motivator

#

oh yea for sure

buoyant knoll
#

As I mentioned before if I switch to CUDA it plays perfect.

uneven spruce
#

right, very strange

buoyant knoll
#

Which is why Id love to hear from someone who has the same setup as I do.

uneven spruce
#

and you had success on qsv on the old pipeline, where it wouldnt specify which hw device to use and didnt hw decoding

buoyant knoll
#

Yes

#

Works almost flawless on the old pipeline from v 0.16.13

uneven spruce
#

the old pipeline had a lot of other things wrong with it fwiw... not to mention it's gonna hit your CPU a lot harder

buoyant knoll
#

I monitor my htpc and it handles it with no issues

#

The worst thing I run into with version 0.16.13 is sometimes when fillers are playing between episodes it will skip back 20 seconds. The stream keeps going and doesnt terminate so its really no biggie. It has no issue playing any format I throw at it.

uneven spruce
#

im comparing the ffmpeg commands you shared from 0.16.13 and 0.18.7, on the old pipeline and the commands are identical

buoyant knoll
#

Crazy.. I get the same results on two different PCs too..

#

I think if we can confirm if this is happening to anyone else with a similar environment it would answer a lot.

uneven spruce
#

yea definitely

#

i sent a message to general, hopefully we can get a response

buoyant knoll
#

Yes, I saw that 👍

uneven spruce
#

whenever i have some time i'm gonna setup the 2nd boot partition on my intel machine for windows. just a PITA because windows install doesnt like when there's something else available to boot... it takes multiple restarts of the machine to install windows and w/ another boot partition it always seems to forget where it is

#

so i have to remove the other ssd ... it's a whole thing

#

neither here nor there though lol

buoyant knoll
#

Aye..

#

Sorry..

uneven spruce
#

no need to be sorry! ive been kicking the can down the road for months

#

my other windows "machine" is a bootcamp partition on my macbook 🙈 not ideal

buoyant knoll
#

I hear ya

uneven spruce
#

there arent any obvious errors w/ old pipeline on 0.18.7 from your logs, but my guess to what is happening is that tunarr times itself out waiting for segments to be ready

#

lots of this 2025-01-30T23:33:23.297Z [debug]: Still waiting for stream session to start. (num segments=0 < 2, playlist exists? false) {"sessionId":"d75fd52c-36a1-4c2d

#

that is very content dependent... so we'd need a direct comparison of the same media on old vs new that woulnt play

#

but yea like i said, just comparing the 2 commands shows no major differences. the old pipeline has been basically untouched, all my focus is on the new one

buoyant knoll
#

Do you want me to collect some fresh logs on some media that works in v16 that wont in the latest?

uneven spruce
#

if you're up to it! comparing the exact same programs would be great

buoyant knoll
#

Sure, ill get you some logs a little later as mentioned

uneven spruce
#

i see timeouts in the 0.16.13 logs as well: 2025-01-25T21:22:07.332Z [error]: Error starting stream after retrying {"sessionId":"65b2db69-c623-4856-a9be-8389b120cd5e","channel":"24044294-817e-4d76-bf60-13e57fc017e0","sessionType":"hls"} err: { "type": "Error", "message": "Stream not ready yet. Retry", "stack": Error: Stream not ready yet. Retry at retries (file:///C:/tunarr/bundle.js:187507:19) at async HlsSession.waitForStreamReady (file:///C:/tunarr/bundle.js:187465:7) at async HlsSession.waitForStreamReadyInternal (file:///C:/tunarr/bundle.js:185749:24) at async file:///C:/tunarr/bundle.js:185710:9 }

buoyant knoll
#

Not sure if they were logs when I was testing. I had some odd issues I ran into and had to restore the tunarr in the profile folder to resolve it

uneven spruce
#

still combing thru but it seems to happen w/ the hevc content - decoding it takes to long and it doesnt spit out any chunks within a reasonable time

#

gotcha, i'll start from the bottom of the file then

buoyant knoll
#

It runs like a rock if Im not in there making too many changes and I just leave it run its programming. If im playing around with the settings sometimes it gets a little temperamental and I have to restart or restore the folder.

buoyant knoll
uneven spruce
#

What do you mean by both environments? Like both old and new pipeline?

buoyant knoll
#

from my 0.18.7 and my 0.16.13. The tunarr log from 0.18.7 has the new pipeline enabled. The tunarr log from 0.16.13 does not have it enabled.

#

i have these different versions running on 2 different pc's.

uneven spruce
#

Gotcha - I thought we were comparing old pipeline at this point between 0.16.13 and 0.18.7

buoyant knoll
#

Oh shit.. I cn get you log with the old pipeline from 0.18.7

uneven spruce
#

We’ve confirmed that new pipeline has a sync issue but we’re also trying to figure out why you’re having playback issues on old pipeline in new version

buoyant knoll
#

Yeah, let m get the logs from 0.18.7 using the old pipeline

#

Fyi, the stream wouldnt even start.

uneven spruce
#

ok finally getting a chance to compare old pipelines between the 2 versions

#

the only difference in parameters is that the command on the new version includes a watermark

#

every other parameter and filter is exactly the same otherwise

buoyant knoll
#

Aside from knowing the command is almost identical im not really sure what that means for this issue?

uneven spruce
#

It suggests that there are no code changes between 0.16.13 and 0.18.7 that could affect playback on the old pipeline. If tunarr is generating identical commands between versions than the root cause must be something else

buoyant knoll
#

Such as?

uneven spruce
#

Hardware

#

These are different machines running each tunarr version, you said?

buoyant knoll
#

Ok, I was wondering that

uneven spruce
#

Also the newer version running with a watermark is going to be slower simply because old pipeline is not using any hardware acceleration to do that overlay

buoyant knoll
#

Heres the thing.. Any version 0.16.13 runs everything perfect no matter what pc im using. I run into the same issue as soon as I go above that. This is what is really confusing.

#

How do you explain that?

uneven spruce
#

I really don’t know

#

Does anything change if you disable the watermark on 0.18.7? Can you test on the same machine to reduce variables? It’s tough to do second hand debugging… I can’t get a solid repro on any of this unfortunately

#

I can only go off your reports and the logs. The latest logs from 0.18.7 show ffmpeg “doing work” and tunarr waiting for it to produce segments. Not sure what else I can say there. Again the commands are identical (save for the watermark)

buoyant knoll
#

Yeah.. I hear ya.

#

I mean if I need to end up switching to using the Linux build and getting another dedicated machine for it I guess thats an option..

#

Disabled the watermark and still experiencing the issue.

#

What I also dont understand is why when I disable the new pipeline does it not play media like it used to? It actually fails more trying to play my streams than the new pipeline.

#

And switching to CUDA media plays media that have the issue just fine.

uneven spruce
uneven spruce
#

It’s up to you how much you want to debug. I think there are still a lot of variables potentially in play: different hardware, wide version range, etc. the name of the game here is to find the most minimal set of changes to reproduce the issue.

Again, totally up to you, but if I were you, I’d setup an instance of 0.16.13 with a totally fresh db (you can specify the path) and do the same for 0.17.0. Same settings. Same ffmpeg version. Single channel with one piece of media that has been giving you trouble

buoyant knoll
#

Yeah, that sounds like a good plan. I dont mind doing that.

buoyant knoll
#

So I ran v17.0 and then the latest v18 build, qsv, new pipeline disabled with a brand new database as you suggested.... and they both worked perfect with media I was having issues with.

uneven spruce
#

🤔

buoyant knoll
#

I just copied over the db, channel-lineups and images folder from my working 0.16.13 to 0.18.7 on this test machine. It seems to be playing all media perfectly in sync so far. The only thing I noticed is I need to set all the fillers for each channel again but thats not a big deal. I wonder what was causing the sync issues though?

uneven spruce
#

Yea that is incredibly bizarre

#

Happy to take a look at the generated commands to see if something is different but I suspect that isn’t it

#

Wondering if there was some weird latent setting

#

Can we compare your settings.json between the non working and working versions

buoyant knoll
#

Im going to give this a try in a bit on my primary htpc. I guess Ill repeat what I did on this machine. Run the new version on it with a fresh db, test it and if it all looks good? Copy the original db, channel lineup and images over.

#

I wasnt expecting my original database to work after successfully testing with a band new one tbh.

uneven spruce
#

Super weird. New settings seem to have the experimental pipeline off fwiw

buoyant knoll
#

Yes, left it off.

uneven spruce
#

ohh... well you were only having sync issues on the new pipeline i thought? lol

#

the old pipeline just wasnt working

#

so the sync issue isn't actually fixed?

buoyant knoll
#

Its working with the new pipeline enabled too! 🙂

uneven spruce
#

whatttttt

buoyant knoll
#

I just tested it

uneven spruce
#

🤯

#

now im really confused lol

buoyant knoll
#

Something in my original setup seems to have been causing the issue.

#

Im going to do the same shortly on my primary htpc and see if I get the same result.

uneven spruce
buoyant knoll
#

Nope.. still seeing the audio sync issue on my primary htpc with the new pipeline enabled.

#

Brand new db, one channel and one know piece of media that has the issue. No watermarks, no fillers set. As minimal as possible.

#

I also just went back to my test machine. Maybe the new pipeline looked like it was working because I didnt give it enough time for the previous transcode to stop. I looks like I do have the sync issue still with the new pipeline enabled on my test pc too. 😦

uneven spruce
#

blegh

#

ok so the current state:

  • 0.18.7 old pipeline is now working as expected on test machine
  • 0.18.7 new pipeline still experienced av sync issue on test machine
#

have you tried 0.18.7 on your "prod" machine to see if it has the same issue (perhaps setting up a separate instance so it doesnt interfere with your existing DB there?

#

still really unsure about the av sync issue, i might have time to mess more with that today, if not it'll probably be tmrw. i have to get my windows env setup

buoyant knoll
#

0.18.7 old pipeline is now working as expected on test machine ✅
0.18.7 new pipeline still experienced av sync issue on test machine ✅
0.18.7 old pipeline is now working as expected on **prod **machine ✅
0.18.7 new pipeline still experienced av sync issue on prod machine ✅

The good part is the old pipeline works as it used to which allows me to play around with some of the newer features that have been added since 0.16.13.

uneven spruce
#

Awesome thanks for confirming. So it’s nice that we’re down to one issue: the av sync

buoyant knoll
#

Yeah, I just hope this is nothing related to my environment somehow..

#

Thanks again for all your help with this issue.

uneven spruce
#

Of course! Hopefully I can get a solid repro once I setup windows

queen sky
#

Sorry for jumping into conversation but is the experimental pipeline working on windows now? Has never worked for me. This is the log from trying a channel with it enabled - https://pastebin.com/wr5dPbsS

Pastebin
67gghj - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

uneven spruce
queen sky
#

feels like deja vu asking you again 🙂 , what settings should i use for the log?

uneven spruce
#

settings > ffmpeg > FFmpeg log method; set it to warning level

queen sky
uneven spruce
# 
Device creation failed: -1313558101.
[vist#0:0/h264 @ 0000014945b1bd40] [dec:h264_qsv @ 0000014949e6e680] No device available for decoder: device type qsv needed for codec h264_qsv.
[vist#0:0/h264 @ 0000014945b1bd40] [dec:h264_qsv @ 0000014949e6e680] Hardware device setup failed for decoder: Unknown error occurred
[fc#0 @ 0000014945b01280] Error binding an input stream to complex filtergraph input vpp_qsv:default.
Error binding filtergraph inputs/outputs: Unknown error occurred```
queen sky
#

CPU is an intel 8500t which has quick sync video unless its outdated

uneven spruce
#

should be fine, it tries to narrow the available devices down by vendor ID, using Intel's vendor ID

#

and it's looking for a Direct3D 11 display device (i.e. DirectX 11)

queen sky
uneven spruce
#

whoa

queen sky
#

will see if there are any intel video driver updates but i only updated to windows 11 recently so might have latest

uneven spruce
#

yeah, good to know. i may have to follow the guideline of the answer there about child_device_type in the ffmpeg command

#

more reason to get my Windows environment setup..

#

might need some additional, advanced transcode config settings in this area too, for QSV (perhaps device type, etc)

uneven spruce
#

ok, some bittersweet updates here

#

finally got my actual windows env setup

#

and i still can't get AV sync repro on new pipeline + QSV

#

oh wait! just tried with the piece of content you sent me... i think i got a repro!!

#

ok, now here's an even more interesting one... it seems like it's a sync thing with the hls output style, because copying the command verbatim and outputting 10s of it to a file keeps the audio in sync just fine

#

this is bizarre

uneven spruce
#

confirmed that the avsync issue exists on ETV as well - so at least we are not alone

#

pretty interesting stuff. the video is stalled for a second but the audio continues and then everything is out of sync

#

i dont think this is a decoder issue anymore, considering i can get a clean file when outputting mpegts directly

#

it also seems tied to content

#

it's the scale filter

#

wow yea, scaling at all makes the whole thing fall out of sync drastically

buoyant knoll
#

Well it makes me feel a little better you can now reproduce the results on your end and get a better perspective on what I was experiencing. Since doing a clean setup of Tunarr with a fresh new db, migrating my old db, channels back and leaving the new pipeline disabled its been running very well for me on the latest x64 build.

uneven spruce
#

yea the key to the old pipeline seems to be the fact that it doesn't utilize the hw scaling. that seems to be the single piece that reliably produces av sync issues for me

buoyant knoll
#

Ah..

uneven spruce
#

hw scaling + HLS output, specifically. hw scaling w/ normal unsegmented output works as expected

#

this explains why you were seeing it across content types, but not for everything (assuming you had some content that didn't need to be scaled)

buoyant knoll
#

Ah okay..

uneven spruce
#

also just curious, which version of ffmpeg are you using

buoyant knoll
#

Lemme see

uneven spruce
#

actually, just confirmed it's any filtering w/ the vpp_qsv filter. i can repro reliably just by adjusting the framerate on hardware w/o scaling

buoyant knoll
#

ffmpeg version 2024-10-24

#

So 7.1

uneven spruce
#

gonna run a test on an older version, just out of curiosity