I’m unfortunately not as lucky, but I’m not sure it’s because of the Subtitle reason.
Log is attached, . Totally unqualified to make this call but I think it got into trouble with the following:
2018-02-11T21:47:17 MCEBuddy.AppWrapper.FFmpeg --> Please use -b:a or -b:v, -b is ambiguous
Here is the detailed log:
NFL Football (2002) - 2018-02-04 - Philadelphia Eagles vs. New England Patriots.ts-Profile Test-2018-02-11T18-19-59.9641097-05-00.log.zip (4.3 MB)
Any ideas?
thanks
BrianGGG
Completely unrelated to subtitles.
You have a defective recording video stream
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] start time for stream 0 is not set in estimate_timings_from_pts
2018-02-11T20:52:13 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000021729d1a240] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size
Because of this ffmpeg is choking and failing.
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:0 → #0:0 (h264 (native) → h264 (libx264))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Stream #0:1 → #0:1 (ac3 (native) → aac (libfdk_aac))
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Press [q] to stop, [?] for help
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Too many packets buffered for output stream 0:1.
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → [libfdk_aac @ 00000215284102e0] 2 frames left in the queue on closing
2018-02-11T21:47:23 MCEBuddy.AppWrapper.FFmpeg → Conversion failed!
I also noticed that you’ve removed handbrake from your encoder order so it doesn’t try to fallback to handbrake to try and encode it:
order=ffmpeg,mencoder
try adding handbrake after ffmpeg
The root cause however is a faulty recording device which is creating a non compliant video file. It could be due to bad device firmware or faulty drivers.
Thanks for looking at this. I have made so many changes to drivers, profiles, etc. since the video was recorded (to successfully do hardware encoding) that I’m not sure that I will be able to solve this mystery.
Which is fine because I haven’t seen anything like it in subsequent recordings…
A few questions here:
Is there anything useful about the error that I listed in my original post (“Please use -b:a or -b:v, -b is ambiguous”) or is this a red herring?
I removed Handbrake because it was the only way to ensure that FFMPEG would do hardware encoding on NVIDIA. Because I have one NVIDIA card with CUDA and one Intel card with QuickSync … the current order was causing a software encode from Handbrake.
I guess I’ll let Handbrake max out my CPU for a while to get this converted…
thanks
BrianGGG
No consequence, ffmpeg has various types of inputs styles, we’re using an older more compatible one
Got it, in the next release we’ll patch this also up so it won’t reorder the encoders if both of them support hardware encoding
Okay patched this up in today’s 2.4.9 beta build. Give it a whirl.
It’s quite possible that I didn’t understand what this patch would do, but I don’t think that this was successful. Two sample logs are below.
I left the default profiles intact when I installed the 2-12 beta, thinking that the algorithm would eventually choose FFMPEG since the ideal case is hardware encoding with my NVIDIA.
This was apparently not the case, as the logs show that both jobs used HandBrake … with no hardware acceleration.
Please let me know if my assumptions were incorrect about how this should have worked.
log.zip (230.2 KB)
thanks
BrianGGG
This patch was to preserve the user selected order of the encoder if more than one encoder supports hardware encoding. In your case both handbrake and ffmpeg support hardware encoding capabilities so it made sure it didn’t reorder your preference.
Your profile looked like:
order=handbrake,ffmpeg,mencoder
You asked MCEBuddy to use handbrake first and then ffmpeg and that’s exactly what it did.
I think what you meant to write was:
order=ffmpeg,handbrake,mencoder
Use ffmpeg (hardware) encoder first and if it fails then fall back to handbrake.
Thanks Goose. This solved the immediate problem. I changed the order, and I have verified that FFMPEG is being used for hardware encoding on my NVIDIA card (which was not the case in 2.4.8).
This brings me to a few questions/comments:
First…I think I misunderstood what was being done. Preserving the order allows me to force ffmpeg, but an even more flexible solution would be for MCEBuddy to come to a conclusion on which avenue to take based on configuration.
I’m suggesting that it would be ideal if MCEBuddy tried all hardware encoded routes first, followed by software. The original problem in 2.4.8 was that MCEB tried Handbrake hardware encoding, failed, then dropped back to Handbrake software. This was not ideal for my configuration.
Possibly a blue sky aspiration, but ideal case would have been to try handbrake hardware, fail, then drop back to ffmpeg hardware. If that failed, then go through the list again with software encoding.
Also, would you accept a feature request on the current Profile.Conf? It’s not ideal that I will have to change the order of every profile that uses handbrake for every beta and release that I install.
A possible alternative here would be to have the concept of a “User Profile file” in a User directory (rather than Program directory). This file would stay intact during upgrades, and it could serve two purposes:
Custom User Profiles could be created and maintained and would be shown in the menu with the system profiles.
Values in existing profiles could be overridden. This would allow changeable items (like parameters on ffmpeg) to get updated with new releases while maintaining user preferences like the converter order.
Just some thoughts, I have the advantage of having no concept of complexity.
Regards,
BrianGGG
Yes that’s on our next to do list, this is one a little more complex so it’ll take some time to work out.
Already there → System Settings
Thanks for the answers.
It’s great to know that the “Hardware first” ordering is on the roadmap.
Regarding the Custom Profile discussion above, I will put in a feature request because I think that the user profile is an “instead of” file rather than an “in addition to”. My suggestion is that if you have 10 profiles in the standard Profile configuration and two in the User profile, then MCEbuddy would show all 12 not just the two in the user profile. I think that would be much more valuable and flexible…
Thanks
BrianGGG
Do open a feature request, this one is tricky for only one reason. Folks sometimes don’t rename the profile, so now you’ve got two profiles, once from the master and one from the custom, we’ll have to figure out which one takes precedence.
I’ll open a separate request. My take on the duplicate issue is that you prefix a “USER_” on anything in the user file. That way “MP4 Normal” in the official Profile file will be separate from “USER MP4 Normal” in the User file.
