Wont analyze any files

[teb]

Tried the initial version, but it doesnt work. Just says processing files for a few minutes and no graph pops up.

Some other comments:

1. Please add gop based plot view
2. HW dec accelleration
3. Paralell decoding if multiple files
4. Config menu, where one can point to the directory where ffprobe is located
5. Seperate log window, where one can see the ffprobe output in realtime

[fifonik]

Have you tried to follow troubleshooting steps? Anything in log?

1. Planned (probably after first stable release)
2. I do not plan to add the option in UI, however it will be possible to configure ffprobe commands using conf (as with FFMetrics). This way it will be possible to provide additional parameters to FFProbe and so if HW related options are supported -- one can use them. However, on my Ryzen 5700 system analisys are very fast -- 1h 40m file on HDD (not SSD) takes 13 seconds to be processed (~2 seconds on consecutive run when it is cached by OS).
3. Not sure if this is needed as how I explained above, processing is very fast.
4. Sorry, not planning to implement this. FFProbe should be in the program folder or in system path. If you have ffptobe somewhere but do not want to make it available in system path and duplicate it, you can always create link/junction.
5. Why? This is mess and slow. The file I mentioned above produces 13MB+ text output (format=compact, that is cvs with keys). No idea why anyone would like to see this in raw inside program (it make sense to output data to file so it can be analyzed in Excel, for example).

[teb]

Where can i find the troubleshooting steps? Checking the log results in a empty log. Analysing 1 mp4 asset, stops after 2 seconds with no output https://snipboard.io/EiroVT.jpg FFBitrateViewer.log

[fifonik]

https://github.com/fifonik/FFBitrateViewer#troubleshooting

[teb]

updated with log and picture

[fifonik]

Thanks for the info. I do not see anything suspisious in log/on screenshot other than incorrect framerate formatting ("1920x1080-24,p", should be no comma between 24 and p). This should not affect the graphs directly, but it is possible that there is the similar error with formatting double when data is supplied to OxyPlot. Will try to investigate tomorrow.

[fifonik]

BTW, what is your system regional settings?

[fifonik]

NVM, I've reproduced the issue by setting current culture to "fr-FR"

[teb]

No-nb = norway

[fifonik]

Just published beta 2 with the fixes. Could you check it please? Thanks.

[fifonik]

I'd like to add some details related to you suggestion about using HW acceleration.

Currently the program asks ffprobe to get packets, not frames. So no any frames decoded during the process. This is why the processing speed is so fast. If I understand correctly, the current bottleneck is reading data. Bigger file (uncompressed, for example) or slower drive -- slower processing speed. And I do not think that using HW acceleration (I'm talking about in-built in GPU/iGPU) can increase the reading speed at all.

[teb]

Beta2 works as intended! Thx! Some more thoughts:

1. I can clearly see that i'm IO bound. Parsing a mezzanine prores source uses 4% CPU on my 40 core system, but 200MB/s read on my RAID SSD storage pool.. Would be great with some progressbar or % done if its possible.
2. Coming back to GOP based view, that would be great as per frame isnt that interessting from a "bitrate" point of view.

[teb]

hi, adding 12 profiles/files of the same title, resulted in a spinner and not-responind. CPU is at 0%, disk IO is non-existant.. Seems that the rendering just choked up. Ill try to reproduce and run with debug. Attached is a pic

[teb]

Adding only 6 AVC profiles, doing 2 at a time did the trick..

1. Presentation is a bit off, 2 profiles seems to be ok, but the 4 others (lower bitrate) is wrongly presented
2. i also see a -value for bitrate on the highest profile
3. Also having bigger graphs result in a very sluggish app https://snipboard.io/OZbB2p.jpg https://snipboard.io/03amOR.jpg

[fifonik]

I can clearly see that i'm IO bound

In this case processing multiple files at once can only slows things down on HDD (random access slower then sequencial).

200MB/s read on my RAID SSD

I'd say it is a bit too low even for single SSD. I've just checked while FFBitrateView running and my slow HDD can do 150+ MB/s, fast - 250 MB/s, SSD -- 1.2+ GB/s.

Would be great with some progressbar or % done if its possible.

To do this I need to get total number of packets in stream. It is possible to add option -count_packets while receiving media info to do this: ffprobe -show_format -show_stream -count_packets file.mp4 Unfortunately, this slows things down (try this with and without the option). No miracles here, ffprobe have to read through all packets to count them. So by doing this I will just move the long process of unknown length from "processing" to "getting media info". Does not look like a good solution for me.

1. Presentation is a bit off, 2 profiles seems to be ok, but the 4 others (lower bitrate) is wrongly presented

Really strange. It is shown that the max for the 4th file is 3800, but I do not see any line on plot :(

2. i also see a -value for bitrate on the highest profile

Could you try to untick the "Adjust ..." checkbox? I believe it will fix the negative value. If this help I will probably need to have some information about this file:

ffprobe -hide_banner -threads 15 -show_format -show_streams file.mp4 > mediainfo.txt
ffprobe -hide_banner -threads 15 -print_format compact -select_streams v:0 -show_entries packet=dts_time,duration_time,pts_time,size,flags > packets.txt

[teb]

I can clearly see that i'm IO bound

In this case processing multiple files at once can only slows things down on HDD (random access slower then sequencial).

200MB/s read on my RAID SSD

I'd say it is a bit too low even for single SSD. I've just checked while FFBitrateView running and my slow HDD can do 150+ MB/s, fast - 250 MB/s, SSD -- 1.2+ GB/s.

True, while this is a rack server with a RAID card, running Vmware ;) I 100% agree that seq IOPS should be the bottleneck here if u dont do 12 paralell reads ;) Which this app doesnt do. Update: did a copy file from to same location, got 850MB/s, so its not IO bound.. gota be the app/cpu, lack of threading in ffprobe..

Would be great with some progressbar or % done if its possible.

To do this I need to get total number of packets in stream. It is possible to add option -count_packets while receiving media info to do this: ffprobe -show_format -show_stream -count_packets file.mp4 Unfortunately, this slows things down (try this with and without the option). No miracles here, ffprobe have to read through all packets to count them. So by doing this I will just move the long process of unknown length from "processing" to "getting media info". Does not look like a good solution for me.

I see that bitrate viewer manages to show the graph during decoding and guestimate the endtime. Isnt it using ffmpeg ? Wonder how it does it.

1. Presentation is a bit off, 2 profiles seems to be ok, but the 4 others (lower bitrate) is wrongly presented

Really strange. It is shown that the max for the 4th file is 3800, but I do not see any line on plot :(

Yea, really fishy.. Only correct for the top 2 profiles, the bottom 4 are all wrong.

2. i also see a -value for bitrate on the highest profile

Could you try to untick the "Adjust ..." checkbox? I believe it will fix the negative value. If this help I will probably need to have some information about this file: Did not fix it unfort..

ffprobe -hide_banner -threads 15 -show_format -show_streams file.mp4 > mediainfo.txt
ffprobe -hide_banner -threads 15 -print_format compact -select_streams v:0 -show_entries packet=dts_time,duration_time,pts_time,size,flags > packets.txt

packets.txt mediainfo.txt

[fifonik]

I see that bitrate viewer manages to show the graph during decoding and guestimate the endtime. Isnt it using ffmpeg ? Wonder how it does it.

Displaying something in process and estimate when process ends -- two different beasts. I can also display something in process and in fact it was implemented this way in the beginning. However, the implementation is complicated as I use packets instead of frames and packing are not in display order. Also, the whole process is fast and I decided to remove the complicated bit of code to simplify things. As for Bitrate Viewer -- they claim in their manual that they use ffmpeg. But I do not know details.

packets.txt mediainfo.txt

Weird. I see negative pts_time in packets.txt and start_time=0 for stream and file. From my opinion it should not be like that. However, as we have this, I have to think a way to deal with such data. Cannot think of good way to deal with it right now.

[fifonik]

Update: did a copy file from to same location, got 850MB/s, so its not IO bound.. gota be the app/cpu, lack of threading in ffprobe..

I saw 1.2+ GB/s in my system while ffprobe was running, so it might also be something with VM or HOST OS configuration.

[teb]

Update: did a copy file from to same location, got 850MB/s, so its not IO bound.. gota be the app/cpu, lack of threading in ffprobe..

I saw 1.2+ GB/s in my system while ffprobe was running, so it might also be something with VM or HOST OS configuration.

yepp. strange really.. i could see that 2 out of 40 cores were like 70% used, (decoding most probably). Is ffprobe multithreaded by default?

[fifonik]

Is ffprobe multithreaded by default?

I dunno. But I'm supplying -threads x where x is number of logical CPUs - 1 (should be 39 in your case -- check the log) You can try to run ffprobe command directly and check IO usage. It is possible that FFBitrateViewer limiting it somehow as I'm reading response from FFProbe in single thread.

[teb]

Is ffprobe multithreaded by default?

I dunno. But I'm supplying -threads x where x is number of logical CPUs - 1 (should be 39 in your case -- check the log) You can try to run ffprobe command directly and check IO usage. It is possible that FFBitrateViewer limiting it somehow as I'm reading response from FFProbe in single thread.

Tried with 20 threads.. They are barely used.. IO bound issue strangely enough..

[fifonik]

I tried -threads 1 and -threads 15 on my system and difference was huge. It is possible that ffprobe trying to use some resources that not available in ur VM or may be ur ffprobe compiled with different options.

[teb]

i used a 44gig mezzanine mov file (prores). I recon the pro-res decoder isnt that threaded..