Created attachment 528362 [details] emerge --info Looks like HandBrake is broken as of v1.1.0. I normally call it through a script that invokes HandBrakeCLI, but I also tried starting an encode through the GUI. The file I'm looking at right now is H.264 video and E-AC3 audio; I'm looking to transcode it to lower-bitrate H.264 video and HE-AAC audio, and to switch container format from .mkv to .m4v. A typical invocation might look something like this: HandBrakeCLI --input "Silicon Valley - S05E05 - Facial Recognition.mkv" --output "Silicon Valley - S05E05 - Facial Recognition.m4v" --preset "High Profile" --crop=0:0:0:0 --encoder x264 --x264-preset medium --quality 21 --cfr --rate 23.976 --audio 1 --mixdown 5point1 --aencoder fdk_haac --arate 64 This has worked for years with earlier versions of HandBrake (and I still have v1.0.7 installed on a FreeNAS box), but it fails with v1.1.0: [mp4 @ 0x7f0a85576e40] Tag avc1 incompatible with output codec id '28' ([33][0][0][0]) ERROR: muxavformat: avformat_write_header failed! With the GUI, I also tried AAC-LC and AC3 audio for output; they also failed to encode. If I mask HandBrake and roll back to 1.0.7, my script works again.
What flags do you have for ffmpeg?
(In reply to Ian Whyman (thev00d00) from comment #1) > What flags do you have for ffmpeg? I'm also having this issue. I've since downgraded back to 1.0.7 for functionality, but if this helps, MY flags for ffmpeg: media-video/ffmpeg-3.3.6:0/55.57.57::gentoo USE="X alsa bluray bzip2 encode fdk gpl hardcoded-tables iconv mp3 network opengl postproc pulseaudio sdl threads truetype vorbis x264 xcb xvid zlib (-altivec) -amr -amrenc -bs2b -cdio -celt -chromaprint -chromium -cpudetection -debug -doc -flite -fontconfig -frei0r -fribidi -gcrypt -gme -gmp -gnutls -gsm -iec61883 -ieee1394 -jack -jpeg2k -kvazaar -ladspa -libass -libcaca -libilbc -librtmp -libsoxr -libv4l -lzma (-mipsdspr1) (-mipsdspr2) (-mipsfpu) (-mmal) -modplug -nvenc -openal -openh264 -openssl -opus -oss -pic -rubberband -samba -schroedinger -snappy -sofalizer -speex -ssh -static-libs {-test} -theora -twolame -v4l -vaapi -vdpau -vpx -wavpack -webp -x265 -zeromq -zimg -zvbi" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="mmx mmxext sse sse2 -3dnow -3dnowext -aes -avx -avx2 -fma3 -fma4 -sse3 -sse4_1 -sse4_2 -ssse3 -xop" FFTOOLS="aviocat cws2fws ffescape ffeval ffhash fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart sidxindex trasher"
I upgraded ffmpeg to unstable. Handbrake 1.1.0 works fine now. Bug only applies to ffmpeg 3.3.6
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7d9e2ecbba97b1e1db4b7238c2c1d106a6eb0388 commit 7d9e2ecbba97b1e1db4b7238c2c1d106a6eb0388 Author: Ian Whyman <thev00d00@gentoo.org> AuthorDate: 2018-05-05 13:29:49 +0000 Commit: Ian Whyman <thev00d00@gentoo.org> CommitDate: 2018-05-05 13:30:14 +0000 media-video/handbrake: Bump ffmpeg/libav deps. Update live ebuild with changes from 1.1.0. Closes: https://bugs.gentoo.org/653932 Package-Manager: Portage-2.3.31, Repoman-2.3.9 .../{handbrake-1.1.0.ebuild => handbrake-1.1.0-r1.ebuild} | 4 ++-- media-video/handbrake/handbrake-9999.ebuild | 14 ++++++++------ 2 files changed, 10 insertions(+), 8 deletions(-)
I've just run into something similar and had to add the keyword ~amd64 for ffmpeg, suggesting that the ebuild should demand the same keyword for ffmpeg as for the handbrake atom itself? (Since I already had handbrake ~amd64). Applying this keyword also gives me the same ffmpeg upgrade of 3.3.6 -> 3.4.2 and the same happy result (:
Apologies, I see that the ebuild has been updated with the dependency as I guessed at above. The question I have now is probably silly, but when would that change become available to users, or is it already? Just curious, knowing so little about ebuilds myself.
:/ ignore me, I can read at https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/handbrake/handbrake-1.1.0-r1.ebuild. Apologies for the stupidity and spam.
