Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • VLC VLC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,415
    • Issues 3,415
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 166
    • Merge requests 166
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • VideoLAN
  • VLCVLC
  • Issues
  • #24957

Closed
Open
Created Jul 18, 2020 by Pierre Ynard@linkfanelDeveloper

YouTube lua script fails on very long lines

I believe that this issue has been causing occasional failures already: apparently the exact content of a YouTube page, in particular the configuration lines, is never the same from one access to another; and I can only surmise that it differs further depending on whether or not it's VLC accessing it. The main configuration line used by the YouTube lua script, containing ytplayer.config, is routinely over 100,000 characters long, and it's not even the longest line of the HTML page.

This example video has been failing most of the time for me in a rather reproducible way (not always though): https://www.youtube.com/watch?v=QK8mJJJvaes Debugging indicates that when arriving to the very long config line, vlc.readline() instead returns nil as if for EOF. An even more striking example would be https://www.youtube.com/get_video_info?video_id=QK8mJJJvaes&el=detailpage which is a normally supported API that contains all the configuration on a single line, now over 400,000 characters long: vlc.readline() returns nil straight away.

My testing leads me to believe that these inputs hit the hardcoded STREAM_LINE_MAX limit of 204,800 bytes used in stream_ReadLine() in src/input/stream.c. This limit looks like a safety check; however, what is its actual technical purpose, if any?

Furthermore, even if you mistakenly call stream_ReadLine() on a random binary stream, the chances of coming across a random 0x0a line feed within 204,800 bytes are pretty high; so hitting the limit would rather be a clue that what is being parsed is indeed text, with a deliberately very long line: in which case the expected behavior would definitely be to go on and parse it.

Obvious fixes would be to bump the limit, or simply do away with it if it serves no real purpose.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking

VideoLAN code repository instance