Hacker News 의견들
  • 사람들이 기본적인 ffmpeg 사용법을 외우지 않으려 얼마나 노력하는지 놀라움
    사실 ffmpeg는 그렇게 어렵지 않고, 매뉴얼도 핵심 개념을 잘 설명함
    물론 기본 설정이 재인코딩을 유발하거나 스트림을 하나만 유지하는 등 위험 요소가 있지만, -c copy만 기억하면 대부분 문제없음
    이런 “위험 요소”를 숨기면 오히려 더 큰 문제를 만들 수 있음. 예를 들어 “ff convert video.mkv to mp4”는 단순 리먹스(remux)로 충분한데 전체 재인코딩을 해버림
    “ffmpeg extract audio from video.mp4”도 무조건 mp3로 재인코딩해서 품질이 떨어짐
    멀티미디어는 본질적으로 복잡한 영역이라 이 복잡성을 숨기면 사용자가 잘못된 개념을 배우게 됨
    단순화된 래퍼보다는 좋은 치트시트로 사용자에게 올바른 개념을 교육하는 게 맞다고 생각함

    • “그렇게 어렵지 않다”는 말은 조심해야 함. 사람마다 어려운 게 다름
      예전에 “가난한 사람은 왜 그냥 좋은 직업을 안 구하냐”는 식의 논쟁이 떠오름
      그래도 네 말이 동기부여를 위한 거라는 건 이해함
    • 나도 ffmpeg를 1년에 한 번쯤 쓰는데, 350년쯤 지나야 문법을 다 외울 수 있을 듯함
    • 자주 쓰는 사람에겐 쉽겠지만, 한두 달에 한 번 쓰는 나 같은 사람에겐 어렵게 느껴짐
      내가 원하는 건 대화형 스크립트임. “무엇을 하고 싶은지” 물어보고, 그에 맞는 명령어를 만들어주며 각 인자의 의미를 설명해주는 방식
    • “그렇게 어렵지 않다”는 말은 농담처럼 들림. ffmpeg엔 수천 개의 옵션이 있으니까
      옵션 목록 예시
    • 나도 Python 패키징 개념을 “그렇게 어렵지 않다”고 말하곤 하는데, ffmpeg 명령어는 거의 독자적인 언어처럼 느껴짐
      네가 말한 문제들은 버그 리포트나 기능 제안으로 해결할 수 있을 듯함
      품질 설정을 숨기는 건 사용자가 몰라도 되게 하려는 의도일 수도 있음
      단순 컨테이너 변환 시 재인코딩을 피하는 건 매핑 테이블로 처리 가능함
      나도 최근 오디오 추출과 썸네일 추가 작업을 하면서 이런 매핑 부재를 느꼈음
  • 영상을 gif로 변환할 때는 항상 palettegen 필터를 씀
    예시 명령어와 함께 10년 전의 관련 블로그 글을 참고함

    • 요즘은 “gif”라는 말이 잘못 쓰이는 경우가 많음. 실제로는 mp4가 더 효율적
      웹사이트에서 애니메이션 gif를 쓸 때 mp4로 바꾸면 더 작고 부드럽고 색상도 정확함
    • pngquant을 ffmpeg 필터로 통합하면 더 나은 팔레트를 만들 수 있을 듯함
      그렇게 되면 ffmpeg가 gifski 수준으로 올라올 수 있음
    • ffmpeg가 프레임별 팔레트 지원을 추가했는지 궁금함
      예전엔 gifski가 이 기능 덕분에 같은 파일 크기에서 더 좋은 품질을 냈음
    • gifski는 팔레트 인식이 잘 되어 있어서 좋은 대안임
    • 이런 설정이 기본값이 아닌 게 아쉬움
  • 이런 접근 방식이 마음에 듦. 리눅스 전체 CLI를 인간 친화적으로 만드는 OS가 있었으면 함
    tar, dd처럼 제각각인 명령 대신 자연어 기반의 일관된 CLI를 상상함
    예:

    zip my-folder into my-zip.tar with compression level 9  
    write my-iso ./zip.zip onto external hard drive  
    git delete commit 1a4db4c  
    convert ./video.mp4 and ./audio.mp3 into ./out.mp4  
    merge ./video.mp4 and ./audio.mp3 to ./out.mp4 without re-encoding
    

    자동완성과 다양한 표현을 지원하면 좋겠음. LLM까지는 필요 없음

    • 하지만 이런 자연어 명령은 모호성이 문제임
      “그 하드디스크 말고 다른 거!” “삭제하라니, 진짜 완전 삭제?” 같은 상황이 생김
    • 그런 접근이 싫다면 Windows나 macOS를 쓰면 됨.
      나는 Linux의 기술적 특성을 그대로 유지하는 걸 좋아함
    • 이런 아이디어를 실제로 구현한 helpme 스크립트가 있음
      예:
      helpme ffmpeg assemble all the .jpg files into an .mp4 timelapse video at 8fps
      helpme zip my-folder into my-zip.tar with compression level 9
      helpme git delete commit 1a4db4c
      
      원래 ffmpeg 래퍼로 시작했지만 지금은 범용 CLI 도우미로 발전함
  • AI 챗봇의 유일한 쓸모는 ffmpeg 명령어 작성
    대화로 필요한 명령을 완성하고, 자주 쓰는 건 .command 파일로 저장함

    • LLM은 자연어 파싱 면에서 놀라운 발전임
      문제는 위키백과와 몇 가지 데이터만으로 “지능”을 만들 수 있다고 착각한 점임
    • 비관적이긴 하지만, LLM은 사용자의 텍스트 설명을 명령어나 SQL로 변환하는 데 유용함
      단, 결과를 보여주고 사용자가 확인하며 배우는 튜터형 인터페이스여야 함
    • 예전 AI는 “영상 0:00~0:03 재생 후 역재생 반복” 같은 bounce 효과를 잘 못 다뤘음
    • 그래도 이런 인터페이스는 GPU 자원을 낭비하는 비효율의 예시 같음
      ffmpeg용 간단한 래퍼로 90%는 해결 가능하니까
  • ezff GitHub 저장소에 접근이 안 됨

    • 나도 404 오류가 뜸. npm 페이지 하단 링크가 문제인 듯함
    • 그래도 npm 코드 탭에서는 볼 수 있음
  • LLM을 써서 제안된 옵션을 보고 수정하는 게 좋을 듯함
    단, 패키지 이름 충돌이 있어서 다른 이름을 쓰는 게 나음
    “ezff”는 Python 라이브러리, “ez-ffmpeg”는 Rust용 라이브러리로 검색됨

  • LLM은 ffmpeg 인터페이스로 훌륭함
    자막 싱크 같은 문제로 2~3번 수정이 필요하긴 하지만, 복잡한 명령을 빠르게 생성할 수 있음

  • “20개의 일반 패턴으로 90%를 처리한다”는 설명이 궁금함
    AI가 말한 건지, 작성자가 직접 말한 건지 알고 싶음

  • npm? 매주 터지는 보안 사고를 보면, 그 혼돈을 내 개발 환경에 들이고 싶지 않음

  • AI가 가져올 패러다임 변화는 결국 “자연어로 컴퓨터에게 말하기”임
    “이 영화의 요리 장면을 gif로 만들어줘” 같은 명령이 현실이 됨
    지금의 명령어 기반 패러다임은 곧 사라질 운명임

    • 그래도 일관되고 검증된 도구의 가치는 여전히 있음
      이런 시도 자체를 폄하할 필요는 없음