Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

2023-03-31 Thread Sebastian Ramacher 
Control: severity -1 important

On 2023-03-29 22:13:54 -0400, Antoine Beaupré wrote:
> On 2023-03-28 00:13:46, Francesco Poli wrote:
> > On Mon, 27 Mar 2023 00:03:20 -0400 (EDT) Unit 193 wrote:
> [...]
> >> And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
> >> is a workaround for the aforementioned throttling, to revert would mean to 
> >> make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
> >> utilize yt-dlp with the default quality option.
> >> 
> >> If we weren't so close to the freeze I'd say the right option would be to 
> >> simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
> >> an option anymore either.
> >
> > Why not?
> >
> > The [freeze policy] states that, even in full freeze, fixes for
> > important bugs are appropriate, as long as they can be done via unstable
> > (as it is currently the case for mpv).
> >
> > [freeze policy]: 
> >
> > I have just filed bug [#1033595], in order to request that the patches
> > you cited are applied to mpv.
> >
> > [#1033595]: 
> >
> > I hope this can be the way to go.
> 
> Considering that a bug was filed against mpv, shouldn't this one be
> downgraded? I don't quite see why yt-dlp should be kicked out of
> bookworm because mpv didn't catchup...

grave seems to be an exaggeration for this issue. Both packages still
work.

Cheers
-- 
Sebastian Ramacher

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

2023-03-29 Thread Antoine Beaupré 
On 2023-03-28 00:13:46, Francesco Poli wrote:
> On Mon, 27 Mar 2023 00:03:20 -0400 (EDT) Unit 193 wrote:
[...]
>> And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
>> is a workaround for the aforementioned throttling, to revert would mean to 
>> make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
>> utilize yt-dlp with the default quality option.
>> 
>> If we weren't so close to the freeze I'd say the right option would be to 
>> simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
>> an option anymore either.
>
> Why not?
>
> The [freeze policy] states that, even in full freeze, fixes for
> important bugs are appropriate, as long as they can be done via unstable
> (as it is currently the case for mpv).
>
> [freeze policy]: 
>
> I have just filed bug [#1033595], in order to request that the patches
> you cited are applied to mpv.
>
> [#1033595]: 
>
> I hope this can be the way to go.

Considering that a bug was filed against mpv, shouldn't this one be
downgraded? I don't quite see why yt-dlp should be kicked out of
bookworm because mpv didn't catchup...

a.
-- 
Never believe that a few caring people can't change the world. For,
indeed, that's all who ever have.
- Margaret Mead

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

2023-03-27 Thread Francesco Poli 
On Mon, 27 Mar 2023 00:03:20 -0400 (EDT) Unit 193 wrote:

[...]
> On Sun, 26 Mar 2023, Francesco Poli (wintermute) wrote:
[...]
> This actually "only" happens when you use bestvideo, other formats such as 
> '22' still work.
> 
> Eg, `mpv --ytdl-format=22 https://www.youtube.com/watch?v=RZAq-_gz_W8`

Does this require to examine which formats are available, by issuing
the command

  yt-dlp --list-formats https://www.youtube.com/watch?v=

for each video you want to play?

[...]
> > Please fix this issue as soon as possible, or revert to the previous
> > version (yt-dlp/2023.02.17-1), until this behavior has been properly
> > investigated and solved.
> 
> And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
> is a workaround for the aforementioned throttling, to revert would mean to 
> make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
> utilize yt-dlp with the default quality option.
> 
> If we weren't so close to the freeze I'd say the right option would be to 
> simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
> an option anymore either.

Why not?

The [freeze policy] states that, even in full freeze, fixes for
important bugs are appropriate, as long as they can be done via unstable
(as it is currently the case for mpv).

[freeze policy]: 

I have just filed bug [#1033595], in order to request that the patches
you cited are applied to mpv.

[#1033595]: 

I hope this can be the way to go.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp0CAov214DF.pgp
Description: PGP signature

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

2023-03-26 Thread Unit 193 

Severity: important

Howdy

On Sun, 26 Mar 2023, Francesco Poli (wintermute) wrote:


Package: yt-dlp
Version: 2023.03.04-1
Severity: grave
Justification: renders package unusable


This doesn't actually render the package unusuable, on the contrary it 
works around throttling.  Instead, it hinders compatibility with another 
package.



Hello and thanks for maintaining this useful package!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1, mpv
is no longer able to use yt-dlp to play YouTube videos:




This actually "only" happens when you use bestvideo, other formats such as 
'22' still work.


Eg, `mpv --ytdl-format=22 https://www.youtube.com/watch?v=RZAq-_gz_W8`


What's wrong?

Did yt-dlp change API? If this is the case, the new version of yt-dlp
Debian package should wait for an updated mpv Debian package, before
migrating to testing...


Not API, but yt-dlp made a change to solve widespread, severe 
throttling, to the point of being unusable really.  I saw one report that 
had it going at an average speed of 30kb/s.


mpv didn't cope well, but that has been fixed upstream in subsequent[0] 
commits[1].


[0]: 
https://github.com/mpv-player/mpv/commit/94c189dae76ba280d9883b16346c3dfb9720687e
[1]: 
https://github.com/mpv-player/mpv/commit/362256edbc4f95c63e69c1fa8c8dce9cc6c44288


Or is it a bug in yt-dlp that shows up only when yt-dlp is called by mpv
behind the scenes, and not when it is directly invoked from the user's
command line?


It's not really a bug in yt-dlp, but instead in mpv.


Please fix this issue as soon as possible, or revert to the previous
version (yt-dlp/2023.02.17-1), until this behavior has been properly
investigated and solved.


And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
is a workaround for the aforementioned throttling, to revert would mean to 
make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
utilize yt-dlp with the default quality option.


If we weren't so close to the freeze I'd say the right option would be to 
simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
an option anymore either.


So to sum up, at least for things I can do:

1. Break yt-dlp integration with mpv under the default options for one 
specific (granted, highly popular) site, but usable by itself and other 
tools.


2. Revert and break the ability to use yt-dlp to watch a video without
first downloading, for all tools.

Reverting also wouldn't cover backporting new releases to bookworm 
eventually either.




Thanks for your time and patience!



Regards,

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

2023-03-26 Thread Francesco Poli (wintermute) 
Package: yt-dlp
Version: 2023.03.04-1
Severity: grave
Justification: renders package unusable

Hello and thanks for maintaining this useful package!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1, mpv
is no longer able to use yt-dlp to play YouTube videos:

  $ mpv https://www.youtube.com/watch?v=...
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=251=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=audio%2Fwebm=yes=2393695=146.021=1565382960171852=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIgK694JvtFcYR2CD8XvmJn6i09Q9lraFGyVhAMcpRX-UICIQCCGeSN6JZGoxj5dZMwNp-qBqRmJ11_PZLZI2eZCTLkhg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-2393695;'
 has unknown duration.
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=248=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=video%2Fwebm=yes=8861743=146.000=1565383003479714=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIhAKRzV0x6RiHkG_vxxixrOMea0A9COXLNQKnMXZMH-JjoAiBflw-hlwAKQUe_kv1e7oI91GhJbXwXdDtknxSqJXSdVg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-8861743;'
 has unknown duration.
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  No video or audio streams selected.
  
  Exiting... (Errors when loading file)

Instead, if I manually download the YouTube video:

  $ yt-dlp -o test https://www.youtube.com/watch?v=...
  [youtube] Extracting URL: https://www.youtube.com/watch?v=...
  [youtube] ...: Downloading webpage
  [youtube] ...: Downloading android player API JSON
  [info] ...: Downloading 1 format(s): 248+251
  [dashsegments] Total fragments: 1
  [download] Destination: test.f248.webm
  [download] 100% of8.45MiB in 00:00:00 at 8.71MiB/s
  [dashsegments] Total fragments: 1
  [download] Destination: test.f251.webm
  [download] 100% of2.28MiB in 00:00:00 at 6.66MiB/s
  [Merger] Merging formats into "test.webm"
  Deleting original file test.f251.webm (pass -k to keep)
  Deleting original file test.f248.webm (pass -k to keep)

I obtain a 'test.webm' file, that can later be played with mpv:

  $ mpv test.webm
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (2%) A-V:  0.000
  
  Exiting... (Quit)


If I downgrade yt-dlp to version 2023.02.17-1, everything works again:

  $ mpv https://www.youtube.com/watch?v=...
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (3%) A-V:  0.000 Cache: 141s/15MB
  
  Exiting... (Quit)


What's wrong?

Did yt-dlp change API? If this is the case, the new version of yt-dlp
Debian package should wait for an updated mpv Debian package, before
migrating to testing...

Or is it a bug in yt-dlp that shows up only when yt-dlp is called by mpv
behind the scenes, and not when it is directly invoked from the user's
command line?

Please fix this issue as soon as possible, or revert to the previous
version (yt-dlp/2023.02.17-1), until this behavior has been properly
investigated and solved.

Thanks for your time and patience!


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (800, 'testing-security'), (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages yt-dlp depends on:
ii  python33.11.2-1
ii  python3-brotli 1.0.9-2+b6
ii  python3-certifi2022.9.24-1
ii  python3-mutagen